(この記事は、Fiorano Software Global Blog *1 に投稿された “Microservices – The issue of Granularity: Atomic or Composite?” *2 の意訳です。)
マイクロサービスを開発する際には、常にその粒度について議論の対象となっています。
デベロッパ、ソリューション アーキテクト、アナリストは、サービスの最適なサイズを以下に定義するか議論を続けています。この議論は、多くの場合、次の２つの方法論に帰着します。
- 単一レベルのサービス
- ２段階レベルのサービス
単一レベル (“アトミック”) サービス
“アトミック” サービスは、下図に示すように、1 つのコード (ビジネス ロジック) ブロックとインタフェース (インプットおよびアウトプット) から構成されています。
通常のケースでは、インプットおよびアウトプットのインタフェース数は数個 (1 から 3個) となります。
アトミック サービスは、単体のプロセスとして実行されます。
２段階レベル (“コンポジット”) サービス
“コンポジット” サービスでは、内部に複数のサービスを含んだ ”アウター” ブロックとインタフェースから構成されています。
”アウター” ブロックの中では、複数のマイクロサービスが連携してコンポジット サービスのロジックを実現しています。
コンポジット サービスでは、デフォルトでは単体のプロセスと実行されますが、内部のマイクロサービスを個々のスレッドに分けて別個に実行させることができます。
コンポジット サービスのメリットには、ビジネス ロジックの実装にコンポーネント化 (モジュール化) の利点を得ることができる点が挙げられます。
コンポジット サービスを図式化したのが図 2 です。
アトミック サービスとコンポジット サービスの比較
アトミック サービスは非常にシンプルな実装です。それは、任意の開発言語で記述された小さな塊です。
マイクロサービスを実行させる環境に合わせて、スレッド モデル (シングル スレッド/マルチ スレッド) を用いることもできます。
一方、コンポジット サービスは、開発エンジニアに魅力的なものに映ります。コンポジット サービスを構成する内部の小さなサービスは、汎用的なロジックとしてあらかじめ用意しておくことができます。そして、大きなロジックを実現する様々なコンポジット サービスで再利用します。これは、ロジックの部品化という多くの利点を持つ方法です。
しかしながら、理論的には優れているのですは、実践方法としてはいくつか考慮すべき問題点もあります。
内部のマイクロサービス間の連携がパフォーマンス上の大きなオーバーヘッドとなってしまうケースがあるのです。また、コンポジット サービスの複雑なフレームワークを実現すること自体が、そもそも困難な方法なのです。例えば、2000年代初めに出てきた BPEL (Business Process Execution Language) は、コンポジット サービスと同様なアプローチに基づくものでしたが、ヘビーウェイトな実行時負荷という問題を抱えています。
また別の問題点に、デプロイメントの難しさがあります。現代のコンピューティング環境では、アプリケーションの “自動デプロイメント” 求められています、しかし、コンポジット サービスの自動デプロイメントの実現には非常な困難が伴ってしまいます。
.
フィオラノ ソフトウェアの数多くの実装経験から、現時点ではアトミック サービスによってマイクロサービス アーキテクチャの実装にはアトミック サービスを用いることを推奨します。
参考資料、文献、Webサイトなど
1. Fiorano Software Global Blog
Fiorano Software グローバル サイトのブログ
“Microservices – The issue of Granularity: Atomic or Composite?”
記事 “Microservices – The issue of Granularity: Atomic or Composite?”
Twitter