この記事で主張したいこと
マイクロサービスアーキテクチャを選定する際には、以下のことを意識すること。
いきなり単独デプロイ可能なもっとも疎結合状態のマイクロサービスから開始しない。(アンチパターン)
段階的に徐々に疎結合にしていき、最終的に単独デプロイ可能な状態にする。
最終形にするまでの、大きなアーキテクチャロードマップは３種類。
徐々に、組織も段階的に拡大させながら疎結合にしていく。
最初のうちは、蜜結合状態なのは仕方がないこと。
この記事でのマイクロサービス化の際のトランザクション管理は、
代表的なサーガパターンを前提として書きます。
また、
もともとのモジュラーモノリス内部のモジュール間の連携は、同期的 という
仮定の下でのお話しになります。
前提知識
・モジュラーモノリス
・コンウェイの法則
・BASE（結果整合性）
マイクロサービスアーキテクチャを実現するためには、組織構造と照合させながら出ないとダメです。
各種、アーキテクチャの状態における、恩恵とデメリットを考慮しながら、
どのチームとどのチームとの間のコミュニケーションコストは高く付きやすいのか？
をアーキテクチャの図面から事前に予測することが求められます。
組織の拡大に伴う結果整合性は仕方ない
マイクロサービスアーキテクチャを取る必要があるような組織は、
それだけ利益がたっていて、ビジネス規模が大きな企業です。
それに伴い、アジリティを損なわないようにするには、
データの整合性をアトミックな整合性から結果整合性にする必要性があります。
それに伴い一時的な不整合のリスクはあるものの、
それを許容できる部分は結果整合性にすることで、マイクロサービスアーキテクチャの良さを引き出すことができます。
これは当然企業の情報伝達においても一緒です。
最早、大規模なエンタープライズ企業であるのも関わらず、
すべての情報伝達がアトミック整合性にしている企業は、今後生き残れないでしょう。
人員配置もアーキテクチャに影響する
コンウェイの法則をさらに拡張するとしたら、
実は人員配置が、組織のアーキテクチャ、ITアーキテクチャに対して、
プラスにもマイナスにも影響してしまいます。
今回は端折りますが、以下のアーキテクチャを考えた際には、
人員配置までアーキテクトが関わった方が良いでしょう。
アーキテクト思考のない人が考えた人員配置は、本来のアーキテクチャに対して、
マイナスの作用を及ぼしかねません。
Sagaについて軽く復習
モジュラーモノリスからマイクロサービスに分割する際に、
モノリスの頃は考えなくてよかった、ACID特性が担保できなくなる。
これがマイクロサービスに分割することを抑制する１つの要因です。
トランザクション管理をしてくれる方法は他にもありますが、
今回はその代表例であるサーガパターンについて触れます。
モノリスからマイクロサービスへ分割する準備
簡単のために、下図のようにモジュールが２つのモジュラーモノリスであるとします。
マイクロサービスに分割する前段階として、
ビジネスロジックが、疎結合になるように、
AとBとに明確にコンテキスト境界が定義されていること。
さらに、
２つのモジュールでは、物理的なDBは１つとして共有しているが、
Aの更新データと、Bの更新データとの間には、明確にスキーマ境界があること。
この２つが揃っていることが安全に、モジュールAとBを物理分割して、
マイクロサービスにするための必須条件です。
これができない、境界位置が不確実さが残るうちは、まだマイクロサービスとして分割するのはやめておきましょう。
モジュールAとBを物理的に分割しマイクロサービスへ
マイクロサービスでは、データベースも分割されるため、
ACID特性などのトランザクション管理の担保は、自前で用意しないとです。
そこで、以下の図のようにその調整役を用意します。
今回は、最もシンプルなオーケストレーション型のサーガを例にします。
もう１つコレオグラフィ型というものがりますが、
それはオーケストレーション型よりも複雑なため、一旦はオーケストレーション型から開始することをお勧めします。
オーケストレーションサーガは、分割された２つのマイクロサービスに対する、
トランザクションの順序管理 と 補償トランザクションの実行 だけに限定し、
ビジネスロジックを持たないように設計しましょう。
間違っても、次の仕様変更でサービスAとBどちらにビジネスロジックを配置させたらいいか？が不明だからと言って、適当にサーガにその処理を書かないでください。
これは明確にアンチパターンです。
まだ蜜結合状態なマイクロサービス
さて、オーケストレーションサーガから、２つのマイクロサービスに対しての
連携は同期通信であるため、図では、あえて実線 にしておきました。
この段階では、まだ代表的なマイクロサービスのBASE(結果整合性)特性ではなく、
アトミック整合性 かつ 同期通信のマイクロサービスです。
そのため、全然疎結合状態ではないです。
図のようなオーケストレーションパターンは、エピックサーガ と命名されており、
この段階では、単独でデプロイ可能なほど疎結合なマイクロサービスではないです。
つまり、マイクロサービスなんだけども、まだ疎結合になり切れていない、
モノリスの名残が残ったマイクロサービスとでも比喩しておきましょうか。
でも、これは確かに未成熟なマイクロサービスであるものの、マイクロサービスの導入期で致し方ないことです。
ここから徐々に進化させていくことが重要なんです。
エピックサーガの特徴については別記事で解説します。
そこで、次回の記事では、徐々に段階的にマイクロサービスを進化させていく手順を説明します。
それに伴う組織構造も照らし合わせながら考えましょう。