前置き
一番最初に、
同期通信ベースのモジュラーモノリスからエピックサーガへとマイクロサービス化をスタートした組織
という前提条件で、この組織が最終的に、
結果整合 かつ 非同期 かつ オーケストレーションとコレオグラフィのハイブリッド
になるまでの、進化的アーキテクチャの戦略ロードマップについての自分なりの考察をまとめたいと思い、この記事を書きました。
もちろん、モジュラーモノリスの段階で非同期にしているといったケースもあるため、
その場合には、以下のロードマップからは外れます。
その場合には、以下のようなロードマップをお勧めします。
これらの段階的に進化するアーキテクチャは、私の中では【学習する組織】を体現していると感じます。
①オーケストレーションを軸とする正統進化モデル
移行のロードマップのルートは、
エピック → おとぎ話(結果整合) → パラレル(非同期) → ハイブリッド
特徴
まずはオーケストレーションという単一のコンセプトの中で、「結果整合性」と「非同期通
信」という課題を一つずつ順番に解決していく、最も着実なアプローチです。
エピック → おとぎ話(結果整合)
比較図は以下の通りです。
DBやらキューなどは、この話題の本質からは不要なので図から端折りました。
おとぎ話になると、アトミック性から結果整合になり、補償トランザクションが片方向のみになります。
また、トランザクション境界もモノリシックさから解放されています。
おとぎ話(結果整合) → パラレル(非同期)
徐々に非同期でもいい所は、同期から非同期にしていきます。
図は、オーケストレーターとサービスCの間は、まだ同期通信であるため、
おとぎ話とパラレルのハイブリッド型であると言えます。
そして、そこからさらに疎結合化がうまく進めば、以下のパラレルサーガの構造になります。
こうなると、同期通信がないために、結合度合いは低い という状態です。
パラレル(非同期) → ハイブリッド
オーケストレーターへの負荷が高まっていて、このままではダウンしてしまい、
全てのサービスが止まりかねないといった背景がある場合は、一部のサーガの責務をサービスに担わせます。
比較図
メリット
一度に直面する技術的課題が一つに絞られるため、学習曲線が緩やかです。
チームはステップごとに新しい概念を段階的に習得できます。
サーガ責務が集約されているのでシンプル
サーガの責務がオーケストレーターという単一のコンポーネントに集約されており、
シンプルさを保った状態で、個々のサービスを進化させやすいです。
コレオグラフィ型にした場合には、そのサーガ責務が個々のサービスに分散実装されます。
可逆性の担保
わたしがこのモデルを最も好むのは、この可逆性です
一度コレオグラフィ型でロジックを各サービスに分散させてしまうと、後から再び中央集権的な制御（オーケストレーション型や、さらに厳格なアトミック整合）に戻したくなった場合、散らばったロジックを全てのサービスから回収し、また中央のオーケストレータに集めるという、極めて困難で高コストな再構築作業が必要になります。
一方で、このオーケストレーションを軸とする正統進化モデルであれば、プロセスのロジックはオーケストレーターに集約されたままです。
この中央の「コントローラ」 を維持しておくことで、将来的に、より厳格な整合性モデルに戻したり、プロセスを修正したりといった変更が、比較的容易になります。
結論として、システムの疎結合化を進めつつも、プロセスの制御ロジックは中央に保持しておくという、バランスの取れた中間状態を長い事キープしやすいです。
この状態を一度経由することが、アーキテクチャの変更の可逆性を担保し、将来の選択肢を狭めないための、安全な進化の道筋となるのです。
考慮点
ただし、
オーケストレーターの責務が大きくなる期間が比較的長く
コレオグラフィによる自律性
の恩恵を受けるのが最後
になります。
それまでは、各マイクロサービスを担当するチームは、自律して他の文脈と連携するスキルが付きにくいです。
また、各チーム同士は、コレオグラフィ型と比較して
厳格なコントラクトによる連携
（つまり、契約部分が変われば、もろに影響を受けるリスクがある）
が求められます。
技術的デメリット
パフォーマンスのボトルネック
全てのサービス間連携がオーケストレーターを経由するため、
この中央コンポーネント自体がシステム全体の性能ボトルネックになる可能性があります。
単一障害点
オーケストレーターが停止すると、関連する全てのビジネストランザクションが停止します。この中央集権的なリスクを長期間抱えることになります。
本来は、分散化したのなら、それぞれが自律して動き、アジリティを担保したいものです。
適合する組織
組織全体で、マイクロサービスや分散トランザクションの経験が浅い段階で、
リスクを最小限に抑えながら、一歩ずつ着実に学びたい組織に向いています。
段階的な教育・学習で堅実な進化を望む場合に最適です。
②同期的ハイブリッドモデル
移行のロードマップのルートは、
エピック → おとぎ話(結果整合) → 同期ハイブリッド(結果整合) → 非同期ハイブリッド
特徴
「同期通信」という制約の中で、先にコレオグラフィを導入し、
オーケストレーターの負荷分散とチームの自律性向上を試みる、バランスの取れたアプローチです。
エピック → おとぎ話(結果整合)
これは上記ですでに解説済なので省略します。
おとぎ話(結果整合) → 同期ハイブリッド(結果整合)
図にすると以下のような感じです。
サービスB-C間が、同期通信のコレオグラフィになってます。
同期ハイブリッド(結果整合) → 非同期ハイブリッド
ここから徐々に非同期にできるところを非同期にして疎結合化していき、
さらにここから、同期通信の所を非同期にできないか検討しながら、最終的に以下の構造になります。
利点
比較的早い段階で、チームがコレオグラフィの考え方に触れることができます。
ただ、非同期化という最も大きな技術的ハードルを、最後にまとめて乗り越えようとします。
考慮点
同期通信という制約下でのオーケストレーションとコレオグラフィのハイブリッド環境は、
2つの思考モデルを同時に管理する必要があり、一定以上の複雑さが伴います。
技術的デメリット
複雑な同期コールチェーン
同期通信のハイブリッド環境では、リクエストが複数のサービスを直列で呼び出すという
複雑なコールチェーンが生まれがちです。
そのためタイムアウトの管理や、障害時の原因切り分けが困難になります。
「ビッグバン」的な非同期化リスク
最終ステップで、ハイブリッドシステム全体を一度に非同期化するため、
変更範囲が広範かつ高リスクになります。
複数の通信パターンを同時に変更するのは非常に困難です。
なので、「ここは非同期にしても安全」という箇所から、
段階的に非同期にするというステップを踏みましょう。
一気にすべてのマイクロサービス間連携を同期から非同期というのは、
あまりにも危険すぎます。
適合する組織
エピックの時よりは、ある程度の技術的成熟度があり、チームの自律性を早期に高めたいが、非同期通信の導入には慎重な組織。
現実的な折衷案を取りながら進化したい場合に適しています。
③最速ハイブリッド化・アグレッシブモデル
移行のロードマップのルートは、
エピック → 同期ハイブリッド(アトミック) → 同期ハイブリッド(結果整合) → 非同期ハイブリッド
特徴
最も早い段階でコレオグラフィを導入し、オーケストレーターの密結合リスクを最初期から
回避しようとする、最も先進的なアプローチです。
エピック → 同期ハイブリッド(アトミック)
エピックの時点で、オーケストレーターが高負荷になることがわかってるような時、
このように同期かつアトミックなコレオグラフィの【伝言ゲームサーガ】
とエピックサーガのハイブリッド形式を取る。
トランザクション境界は、すべてを含む広い範囲であるため、
正直個人的には、このエピック → 同期ハイブリッド(アトミック)には、大した恩恵を感じない。
比較図
利点
オーケストレーターがボトルネックになるリスクを最速で低減できます。
これは①とは真逆な特性ですね！
チームの自律性を最大化する方向に、最初から舵を切ります。
考慮点
初期段階から複数の通信パターンと整合性モデルが混在するため、
アーキチャ全体を理解し、統制するための技術力が極めて高く要求されます。
技術的デメリット
初期の異常な複雑性
開発者は最初から複数の通信・整合性パターンを理解・実装する必要があり、
認知的な負荷が非常に高くなります。誤った実装をしてしまうリスクも他に比べて大きい。
分散デッドロックのリスク
同期的なコレオグラフィとオーケストレーションが混在する環境では、サービス間の呼び出し順序に起因する分散デッドロックが発生しやすくなります。
適合する組織
分散システムに関する深い知見と経験を持つメンバーが揃っており、
かつアーキテクチャガバナンスが強力に機能する、非常に成熟した組織。
まあ、あんまりそういう組織は多くでしょうね、、、💦
リスクを取ってでも最速で理想形を目指す場合に選択肢となります。
なぜ上記のロードマップが正しいのか
ベストプラクティスのような理想論だけを追うのではなく、各組織特有の
事業リスク 、技術的負債、チームの成長という現実的な制約を考慮に入れてロードマップを描かなくてはいけません。
わたしはその際のマクロなロードマップをTOCのアンビシャスターゲットツリー
で考えるようにしています。
では、そもそもなぜ上記のように段階的に行う必要があるのか？を見ていきましょう。
1. 「不確実性」を前提としたリスク管理
最初から正解のアーキテクチャは誰にも分からない、という現実を受け入れています。
ビジネスドメインの境界線は、事業の成長と共にコロコロ変化します。
最初に完璧な疎結合を目指すことは、間違った境界線でシステムを分割してしまうという大きなリスクを抱えています。
その手戻りコストは、密結合な状態から徐々に分離していくコストより、はるかに高くまります。
2. 可逆性の担保とビジネス継続性
「最初は同期通信（密結合）で始める」という選択は、
いざとなれば元に戻れる（可逆性）
という重要な安全弁を確保しています。
これは、技術的な挑戦よりも事業継続性 を優先する判断です。
クリティカルな処理の整合性を最初に担保し、ビジネスを安定稼働させながら、次のステップに進む余地を残しています。
そういう意味でも、「結果整合性の範囲をまずは探して、その後に非同期にしていく」
というこの判断はリスクがコントロールしやすいです。
3. アーキテクチャと組織の共進化
「学習する組織」とは、まさにこの段階的移行のプロセスを指していると思います。
大きくマイルストーンを区切ると、以下の3段階に分かれます。
各段階では、前段階で必ずADRを書き、アーキテクチャ移行後は、確実に効果検証を行うようにしましょう。
ステップ1（密結合）
チームはまず、ドメインのビジネスロジックそのものに集中して学びます。
ステップ2（結果整合性へ）
運用を通じて「どこまでなら整合性を緩めてもビジネス上問題ないか」という知見（暗黙知）を組織として獲得します。
ステップ3（疎結合・非同期へ）
獲得した知見を元に、自信を持って非同期化・疎結合化にリファクタリングします。
この段階では、チームの技術スキルもだいぶ向上しているはずです。
アーキテクチャが進化するプロセスと、組織が対象ドメインと技術を学習するプロセスが、
完全に連動して進んでいます。
これは、技術選定と組織能力を切り離して考えないコンウェイの法則を意識した考えです。
まとめ
今回提示したロードマップは、「単独でデプロイ可能」というマイクロサービスの理想形をゴールとして見据えつつも、そこに到達するまでの道のりを現実的かつ持続可能な形で描いた、わたしなりの進化的アーキテクチャの戦略です。
多くのマイクロサービス化で失敗した組織が陥りがちな、
サービス境界がまだ不明瞭にもかかわらず、
非同期かつ結果整合性 という理想形からのごり押しトップダウン導入
というアンチパターンを避けるため、是非とも参考にしてください。