エンティティサービスはアンチパターン

マイクロサービスに基づいたアーキテクチャでは、異なるサービスを分離するのが重要だ。エンティティサービスはマイクロサービスで使われる一般的なパターンだが、Michael Nygard氏はマイクロサービスに関する短いブログ記事の中で、エンティティサービスは分離に反するアンチパターンだと書いている。

Release It!の著者であるNygard氏によれば、エンティティサービスはよく再発見される問題に対する解決策だ。氏はMicrosoftが公開したマイクロサービスについての本とSpringのチュートリアルのパターンの使い方の例に言及している。

氏にとって、アンチパターンとは悪化させるものだ。エンティティサービスがアンチパターンであると主張する中で、氏は巨大な一枚岩のアプリケーションを例に挙げている。このアプリケーションでは、複数のインスタンスがあり、ローカルでインプロセスですべての機能を提供する。

このアプリケーションをマイクロサービスに移行するため、Springのチュートリアルの例を使うと、いくつかの機能がサービスのひとつに残ることになる。しかし、氏によれば、ほとんどの機能がひとつ以上のエンティティで構成される集約を必要とするので、エンティティの間に依存関係ができる。例えば、すべてのサービスが関係するカートに価格を設定する場合だ。

このような依存関係は運用上の結合を生み出し、それが、性能や可用性、キャパシティに影響する、と氏は主張する。また、ひとつの変更が他のサービスに波及するような意味的な結合も生み出す。最悪の場合、異なるバージョンのサービスに対処しなければならないようになってしまう。

氏によれば、エンティティサービスを使ってマイクロサービスに移行する場合、以下のような結果になる。

• チームは自分たちのタイミングでデプロイできる。
• 意味的な結合によってチーム横断の交渉が必要になる。
• ほとんどのリクエストでエンティティサービスが呼び出される。それによって負荷が上がる。
• 全体の可用性が多くのサービスに結合する。

ここにおいて、エンティティサービスをアンチパターンとする条件が整った、と氏は考えている。

他のブログ記事で、Fourth.comのプリンシパルアーキテクトであるBen Morris氏は、Nygard氏の記事に言及してエンティティサービスが使われたマイクロサービスは一枚岩のアプリケーションよりも悪いと書いている。氏は自主性がマイクロサービスの重要な側面だが、サービスの粒度を小さくすると、より他のサービスに依存しやすくなり、自主性という重要な側面が失われる、という。多くのサービスが関係するので変更は難しくなる。異なる開発チームでメンテナンスをしていたらさらに難しくなる。小さなサービスが密結合しているリスクはひとつのサービスの障害が他に波及し、複数のプロセスを落としてしまうことだ。

Nygard氏の記事は大きな議論を呼び起こした。Microsoftの本の著者のひとりは、本の中でHTTP呼び出しによるマイクロサービスの結合について警告している、と書いている。また、マイクロサービスを自主的にするには正しいドメインモデルを持つことが重要だと指摘している。

Nygard氏は新しい記事でエンティティサービスの他の側面についても書く予定だ。