マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。
マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。
「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか?
Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。
いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。
マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編)
ECサイトをマイクロサービスアーキテクチャで作ることを考えてみます。購入するときに会員登録するとポイント付与したり、サンキューメール送信したりします。
したがって、その会員登録時の処理としては、以下のようになるでしょう。
- 顧客管理サービスを呼び出し、会員として登録する。
- ポイントサービスを呼び出し、新規会員登録時のポイントを付与する。
- メール送信サービスを呼び出し、会員登録サンキューメールを送信する。
アプリケーションを新たに作る
ECサイトがそこそこヒットし、高齢者の利用者も増えてきましたが、サイトが使いにくいとか、こういう商品も扱って欲しいとかいう声を聴くようになりました。しかし、それ以外の利用者層には概ね好評です。
そこで、既存のECサイトとは別にシニア向けサイトを別に作ることにします。ここでも、会員登録する必要があるので、同じようにサービスを呼び出す必要があります。
ここでの問題は、新しく作ったサイト(アプリケーション)で、会員登録機能があれば、顧客管理サービス、ポイントサービス、メールサービスを呼び出すというきまりを忘れないようにしなきゃいけないことです。
これは事業が拡大していって、新しい開発者がどんどん増えていくときには結構難しい問題であることは、みなさんも経験あるかと思います。
会員登録時のルールが変わる
また、会員登録時にメールアドレスを登録しなきゃいけないことに障壁があって、会員登録数が伸び悩んでいることが分かったので、メールアドレスを任意にして、メールアドレスがない人にはダイレクトメールを発送することにします。
この場合、各サイト(アプリケーション)にそのロジックを追加し、DM発送サービスの呼び出しを忘れないように追加していかなくてはなりません。
オーケストレーションの問題のまとめ
というように、ロジックが呼び出し側に寄ると修正に範囲が多くなってしまうことが分かります。これが、モノリシックなアーキテクチャであれば同じチーム内で解決することなので、あまり大きな問題にならないかもしてませんが、マイクロサービスアーキテクチャでは、コンウェイの法則によりサービス・アプリケーションが異なれば、異なるチームが担当していることが多くなるので、多くのチームに影響を及ぼす修正は、より避けたくなるでしょう。
マイクロサービスアーキテクチャでECサイトを作る(コレオグラフィ編)
これを解決するために、イベントのpubsubによってサービス間の結合を疎にする方式が、コレオグラフィとして紹介されています。
各マイクロサービスが、イベントをサブスクライブしていて、新規会員登録イベントが発生したら、それを受け取り、それぞれ処理を行うというものです。
したがって、ECアプリケーション側の処理は、以下のようになります。
- 新規会員登録イベントをパブリッシュする。
- 新規会員登録イベントがサブスクライブしている各マイクロサービスで適切に処理されたら、その旨の通知を受け取る。
イベントの受け渡しの具体的なプロダクトとしては、書籍の中ではRabbitMQが挙げられていますが、上記のようなリアルタイム性が高く、リプライのメッセージも受け取れるようなメッセージングの仕組みであれば、他でも構築できると思います。
さて、オーケストレーションのときの課題は、コレオグラフィではどうなるのでしょうか?
アプリケーションを新たに作る
どのサービスを呼び出すかを、アプリケーション側は知らなくてよいので、同じように新規会員登録のイベントを作成しパブリッシュするだけです。
これならサービスの呼び忘れは発生しなさそうです。
会員登録時のルールが変わる
会員登録時にDMを送る変更はどうなるでしょうか?
これもシンプルです。DM発送サービスが新たに、新規会員登録イベントをサブスクライブするだけです。新規会員登録をもつサイト(アプリケーション)が何個あっても同じです。それらには影響を与えません。DM発送サービスが、新規会員登録イベントで、Eメールが設定されてないものを受け取り処理するだけです。
まとめ
というように、徐々に全体のシステム規模が大きくなっていくことが予想されるマイクロサービスアーキテクチャにおいては、その影響をできるだけ少ないサービス(チーム)に留めることが重要になってきて、コレオグラフィはその解決策のひとつになるかもしれません。