前回は、マイクロサービスについてUNIX のパイプ機能をアナロジーとして取り上げ説明しました。
今回は、マイクロサービス間の連携を支える “マイクロサービスにおけるパイプ機能” について考察してみたいと思います。
Dumb Pipe (土管) ?
マイクロサービスを提唱したJames Lewis氏が Martin Fowler氏と共に著した『Microservices』*1という記事の中で、「Smart endpoints and dumb pipes」*1というセクションを設けて、マイクロサービス間の連携について説明しています。
このセクションではまず、対極にある smart pipe を説明しています。smart pipe の例として ESB (エンタープライズ サービス バス) などのアプリケーション連携製品をあげています。
ここでいう ESB や連携製品とは、
- 中央集権的ですべての制御を中央のハブ サーバーで行う
- サービス間の通信は WS* 標準に基づく SOAP や BPEL などの複雑なプロトコルによる
- メッセージ ルーティング、データ変換などのメディエーション機能を果たす
- ビジネス ルールの適用
といった賢さ (機能) を持ったパイプであるとしています。
一方、マイクロサービスによる構築とは、
- 個々のマイクロサービスのコヒージョン (凝集度) *2 を高め
- マイクロサービス間の関係は疎結合 (decoupled)
とすることを目的としたものであり、そのためには “smart endpoints and dumb pipes (賢いエンドポイントと機能性の低いパイプ)” アプローチが好ましいとしています。
このアプローチは、具体的に以下を実現することです。
- 中央制御を排する
- マイクロサービス自身による自治制御 (コレオグラフィ) を行う
- マイクロサービス間の通信には、ライトウェイトなプロトコルを用いる
これは、従来のプラットフォーム製品が有していた機能をできる限りマイクロサービス側に移し、中央に君臨している連携プラットフォームの “くびき” を軽減し、マイクロサービスの自治の自由度を高めることを意味しています。
アプリケーション連携のソリューションを提供している側として、私も基本的にこのアプローチには賛成します。従来の方法論に基づく製品には以下の問題点があるからです。
中央制御
中央制御では、制御対象は中央のプラットフォーム (J2EE や .NET など) の強い影響下にあります。このような環境下では、サービスやアプリケーションも中央のフレームワーク (J2EE または .NET) にしたがったものとなります。このフレームワークに則っていないものは、何らかの特別な手段をこうじて制御下におくことを余儀なくされます。
マイクロサービスに限らずサプリケーションやサービスには、それぞれの機能を実現するにあたり、それに適した稼働環境や開発言語があり、中央のフレームワークに従わない（従い難い） ケースが少なくありません。
上の図は、典型的な中央制御による連携プラットフォームを示しています。
プロセス エンジン (代表的なものに BPEL エンジンがあります) がサービスやアプリケーションの呼び出しをコントロールします。
コンテナには、サービスやアプリケーションを実際に呼び出すためのコンポーネントが納められています。コンポーネントは呼び出すサービスのプロトコルをサポートするのですが、基本的には自身が存在しているコンテナ プラットフォームのフレームワークに従ったものです。フレームワークに則っていないサービスの呼び出しには特殊アダプターを用いるなどの何らかの手段が必要となってしまいます。
図をみただけでも、中央サーバーの上の複雑さが想像できます。このように複雑で処理負荷などが中央のサーバーに集中する方式では、中央のサーバーマシンに多大な投資が要求されます。
詳細については、『ハブ＆スポークの問題点』 *3を参照してください。
コレオグラフィ
アプリケーション連携におけるビジネス プロセス (連携フロー) を構築する際、”オーケストレーション” と “コレオグラフィ” という２つのアプローチがあります。
オーケストレーションは指揮者が中央にいて、全体 (サービスやアプリケーションの動き) を指揮する方式です。この方式は、中央制御のハブ&スポーク形態に適ったものです。
コレオグラフィでは、指揮者は存在せず、アプリケーションやサービスは誰かの指揮を受けず自律的に動きます。
コレオグラフィの方が自由度が高く、様々な業務形態に適合し易いビジネス プロセス (連携フロー) を構築できます。
詳細については、『コレオグラフィとオーケストレーション』 *4を参照してください。
複雑で処理負荷の重いプロトコル
SOA ではサービスの呼び出し (インボケーション) のプロトコルとして、SOAP + WSDL が生み出されてきました。その後、セキュリティなど多くの規格が WS-* として追加され、非常に複雑なプロトコルとなっています。
これは、サービスやアプリケーションの置き換えや変更を困難なものとし、ビジネス環境の変化に迅速に対応していくアジャイル性を損なう要因となります。
また、複雑なプロトコルを処理するためには、ハードウェアなどのシステム リソースのコスト増大を招きます。
Martin Fowler 氏らが訴える Smart endpoints and dumb pipes には上述のような意味があるのだと思います。
また、氏らがマイクロサービス間のプロトコルにメッセージングを推奨しています。メッセージングには多くの利点があるためです。
メッセージング を用いることの利点については、『メッセージング再入門 (前篇) — JMS を使用することの意味 —』 *5 を参照してください。
次回は、この Smart endpoints and dumb pipes のより具体的なアーキテクチャについて取り上げ、マイクロサービスの理解を深めてみたいと思います。
参考 (資料、文献、Webサイト など)
1. Smart endpoints and dumb pipes, Microservices
Smart endpoints and dumb pipes の詳細については、James Lewis氏が Martin Fowler氏と共に著した記事『Microservices』 を参照してください。
Microservices
2. コヒージョン (凝集度)
凝集度（コヒージョン、cohesion）とは、情報工学においてモジュール内のソースコードが特定の機能を提供すべく如何に協調しているかを表す度合いです。凝集度が高いモジュールは他との結合度が低いことが多く、逆に凝集度が低ければ結合度が高くなる傾向があります。詳細については、ウィキペディアの該当項目を参照してください。
ウィキペディア コヒージョン
3. ハブ＆スポークの問題点
当ブログ内の記事を参照してください。
ハブ＆スポークの問題点
4. コレオグラフィとオーケストレーション
当ブログ内の記事を参照してください。
コレオグラフィとオーケストレーション
5. メッセージングを使用することの意味
メッセージング プロトコルを用いることの利点については、当ブログ内の記事を参照してください。
メッセージング再入門 (前篇) — JMS を使用することの意味 —
Twitter