概要
マイクロサービス同士の結合や連携には、大きく分けて同期通信と非同期通信がある。
この時に両方の設計パターンのメリット・デメリットと、
その際の組織的な連携の心構えなどについて触れておきたいと思う。
なお、書籍チームトポロジーの用語が以下では当たり前のように使用されるため、気になる方は他の記事で用語を調べていただきたい。
組織的なマネジメント
基本的にコンウェイの法則の力学を意識して、
１つのマイクロサービスは、１つの組織が責任をもって運用するという
のが鉄則である。
そのマイクロサービスの中のサブコンポーネントに対しては、サブ組織を相似形で対応付けて運用していく。
図
とにもかくにも疎結合
マイクロサービスにしている時点で、
そのメリットを生かすためには、極力他のサービスと疎な関係性。
つまり、他のサービスを運用する組織とやり取りをすることなく、
変更したり、デプロイできることが望ましい。
他のサービスとは独立して運用されることが前提であるため、
以下のようなことは極力避けないとメリットを生かしきれない。
あるサービスに対する変更や障害が他のサービスにまで波紋する。
これは組織同士のコミュニケーションパス的には、
以下のように言い換えることができる。
あるサービスAに変更を加えようとした際に、
Aを担当する組織と、Bを担当する組織の間に変更の旨の
コミュニケーションが発生する。
このような状態は、サービスの境界付けられたコンテキストにより、
独立して運用したりデプロイしたりできるというマイクロサービスの
メリットを発揮できていない。
むしろ分ける意味は本当にあるのか？と疑ってみた方がいい。
どんな時に起こる？
では、上記のようなケースはどのようなときに起こるのか？
下図のように同期的な通信を行っていると、実質動的に密結合を起こしていることになる。
エピックサーガや伝言ゲームサーガパターンなどが、この代表例であるといってもいいかもしれない。
デメリット
確かにこのままでは、
他のサービスと密結合している
という、なんのためにサービスとして分けたんだという話にもなる。
しかし一方で以下のようなメリットも存在する。
メリット
マイクロサービスの独立性を強く担保させるためには、
データのリアルタイムな整合性はある程度犠牲にしなくてはならない。
しかしながら、エピックサーガや伝言ゲームサーガパターンに関しては
マイクロサービスでありながらも、アトミックな整合性を保てる。
これは密結合しているがゆえの恩恵ともいえる。
組織コミュニケーションパス
まず、サービスAとサービスBが連携しあっていると仮定する。
この時に同期的なやり取りがある場合には、チームトポロジー的にABは密な連携が必要であることを意味している。
同期通信になっている以上、イネイブリングチームやプラットフォームチームは、継続的にそれをサポートしてあげる必要がある。
これはコミュニケーションコストという面では、非同期に比べてかなりかかると思っている。
その一方で、
チーム同士が持っていて、共有しなくてはならない情報に対して、どうしても不整合リスクを抑えたい という場合にはこちらの方が適している。
ようは何が言いたいかというと、
ビジネスアーキテクチャ上ではどうしても机上の空論になってしまい、
情報の不整合リスクがどの程度ビジネスに対してマイナスの影響を与えるのかわからないといった場合に、
実際に実装していく中で、チーム間にどういったコミュニケーションが発生するのか？ どのくらいの時間、情報の不整合があっても許容できるのか？を
イネイブリングチームは意識した上で、ファシリテーションを行う。
はっきりいってイネイブリングチームには、想像以上に認知負荷がかかると思っている。
各チームのそれぞれの役割も念のため以下に記載する。
ストリームアラインドチーム
これへ対応するようにして、サービスチームAとチームBを置く。
素早くデリバリーするためにも、これらチームA、Bはチームトポロジーでいうところのストリームアラインドチームである必要がある。
コンプリケイテッド・サブシステムチーム
サービス内のサブコンポーネントはコンプリケイテッドサブシステムチームに担わせる。
この際に組織構造と対応付けるために、
そして、そのチームの責任範囲を瞬時に名前空間から把握できるようするために、
チームA.xとかチームB.yみたいな名前にしておくことをお勧めする。
イネイブリングチーム
サービスAとBの変更時の素早い情報連携を支援する形で、
イネイブリングチームはABを横断する形で連携のファシリを行う。
プラットフォームチーム
プラットフォームチームは、非機能的な部分の改善などによって、
サービスが更新された場合などの時に、AB間の連携を取るイメージだ。
私はサービスメッシュなどが整備されている場合には、そこを担当するのがこのチームだと捉えている。
通信的な障害が起きた際には、プラットフォームチームが率先してストリームアラインドチームをサポートしてあげる。
非同期の場合
では、逆に非同期の場合を見てみようと思う。
非同期の場合には、
情報の不整合リスクが同期通信の時よりも出てくる
代わりに、
コミュニケーションコストという面で見たら、だいぶ抑えられる。
各サービス間が、同期の時と違って、
メッセージを投げる側はキューに投げたら、返事を待たなくていい。
受け取る側は、好きな時にキューから受け取れる。
同期通信の時と違って、障害や変更影響が波紋することもない。
よって、チーム同士の対話の必要性は抑えられる。
一方で技術的にはこちらの非同期の方が学習コストも高いので、
そのコストを払うのか？ それともチーム同士の密なコミュニケーションコストを払うのか？
これら目に見えないコストの比較の上で、決定すると思っている。