Help us understand the problem. What is going on with this article?

マイクロサービスアーキテクチャにおけるオーケストレーションとコレオグラフィ

More than 3 years have passed since last update.

マイクロサービスアーキテクチャの4章にオーケストレーションとコレオグラフィという話があります。

book

マイクロサービスを使ってアプリケーションを組み立てる側の、サービスの呼び出し方の違いです。

「マイクロサービス的に作ってるよー」というシステムでも、ここに特に疑問を持たず、ふつうにWeb APIたちを呼び、受け取ったデータでHTMLをレンダリングするというオーケストレーション方式で作られているのが多いのではないでしょうか?

Sam Newmanは、それだと呼び出されるサービス側がドメインモデル貧血症になりがちで、呼び出す側にロジックが集まっていくことになると、書籍の中で述べています。

いったいどういうことでしょうか? 書籍中の例をちょっと変えて考えてみます。

マイクロサービスアーキテクチャでECサイトを作る(オーケストレーション編)

ECサイトをマイクロサービスアーキテクチャで作ることを考えてみます。購入するときに会員登録するとポイント付与したり、サンキューメール送信したりします。

したがって、その会員登録時の処理としては、以下のようになるでしょう。

  1. 顧客管理サービスを呼び出し、会員として登録する。
  2. ポイントサービスを呼び出し、新規会員登録時のポイントを付与する。
  3. メール送信サービスを呼び出し、会員登録サンキューメールを送信する。

オーケストレーション

アプリケーションを新たに作る

ECサイトがそこそこヒットし、高齢者の利用者も増えてきましたが、サイトが使いにくいとか、こういう商品も扱って欲しいとかいう声を聴くようになりました。しかし、それ以外の利用者層には概ね好評です。

そこで、既存のECサイトとは別にシニア向けサイトを別に作ることにします。ここでも、会員登録する必要があるので、同じようにサービスを呼び出す必要があります。

orche2.png

ここでの問題は、新しく作ったサイト(アプリケーション)で、会員登録機能があれば、顧客管理サービス、ポイントサービス、メールサービスを呼び出すというきまりを忘れないようにしなきゃいけないことです。
これは事業が拡大していって、新しい開発者がどんどん増えていくときには結構難しい問題であることは、みなさんも経験あるかと思います。

会員登録時のルールが変わる

また、会員登録時にメールアドレスを登録しなきゃいけないことに障壁があって、会員登録数が伸び悩んでいることが分かったので、メールアドレスを任意にして、メールアドレスがない人にはダイレクトメールを発送することにします。

この場合、各サイト(アプリケーション)にそのロジックを追加し、DM発送サービスの呼び出しを忘れないように追加していかなくてはなりません。

orche3.png

オーケストレーションの問題のまとめ

というように、ロジックが呼び出し側に寄ると修正に範囲が多くなってしまうことが分かります。これが、モノリシックなアーキテクチャであれば同じチーム内で解決することなので、あまり大きな問題にならないかもしてませんが、マイクロサービスアーキテクチャでは、コンウェイの法則によりサービス・アプリケーションが異なれば、異なるチームが担当していることが多くなるので、多くのチームに影響を及ぼす修正は、より避けたくなるでしょう。

マイクロサービスアーキテクチャでECサイトを作る(コレオグラフィ編)

これを解決するために、イベントのpubsubによってサービス間の結合を疎にする方式が、コレオグラフィとして紹介されています。

各マイクロサービスが、イベントをサブスクライブしていて、新規会員登録イベントが発生したら、それを受け取り、それぞれ処理を行うというものです。

bus1.png

したがって、ECアプリケーション側の処理は、以下のようになります。

  1. 新規会員登録イベントをパブリッシュする。
  2. 新規会員登録イベントがサブスクライブしている各マイクロサービスで適切に処理されたら、その旨の通知を受け取る。

イベントの受け渡しの具体的なプロダクトとしては、書籍の中ではRabbitMQが挙げられていますが、上記のようなリアルタイム性が高く、リプライのメッセージも受け取れるようなメッセージングの仕組みであれば、他でも構築できると思います。

さて、オーケストレーションのときの課題は、コレオグラフィではどうなるのでしょうか?

アプリケーションを新たに作る

どのサービスを呼び出すかを、アプリケーション側は知らなくてよいので、同じように新規会員登録のイベントを作成しパブリッシュするだけです。

bus2.png

これならサービスの呼び忘れは発生しなさそうです。

会員登録時のルールが変わる

会員登録時にDMを送る変更はどうなるでしょうか?

bus3.png

これもシンプルです。DM発送サービスが新たに、新規会員登録イベントをサブスクライブするだけです。新規会員登録をもつサイト(アプリケーション)が何個あっても同じです。それらには影響を与えません。DM発送サービスが、新規会員登録イベントで、Eメールが設定されてないものを受け取り処理するだけです。

まとめ

というように、徐々に全体のシステム規模が大きくなっていくことが予想されるマイクロサービスアーキテクチャにおいては、その影響をできるだけ少ないサービス(チーム)に留めることが重要になってきて、コレオグラフィはその解決策のひとつになるかもしれません。

kawasima
Clojure関連のことをブログがわりに書き綴ります。 ※ここでの発言はシステムエンジニアを代表するものであって、所属する組織は二の次です。
https://github.com/kawasima/
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした