コレオグラフィーとオーケストレーションのパターン

マイクロサービスが連携してビジネスプロセスを完了する必要がある場合、基本的な連携パターンは 2 つあります。オーケストレーションでは、Step Functions のような中央のコーディネーターが各サービスに明示的な指示を出します。コレオグラフィーには中央のコーディネーターがなく、各サービスがイベントをリッスンして独立して反応します。どちらをいつ使用するか、また両者をどのように組み合わせるかを理解することは、SAA-C03 試験でも問われる重要なアーキテクチャスキルです。

オーケストレーションでは、中央サービス（オーケストレーター）が処理の順序を制御します。オーケストレーターは Service A を呼び出して応答を待ち、その後 Service B を呼び出すというように処理を進めます。オーケストレーターはプロセスの状態を完全に把握し、エラーと再試行を処理して、中間結果に基づく判断を行えます。AWS では、Step Functionsが標準的なオーケストレーターです。ワークフロー全体をステートマシンとして定義し、各ステップを実行します。

コレオグラフィーでは、サービスが中央のコーディネーターを介さず、イベントを通じて通信します。Service A がタスクを完了してイベント（例：OrderValidated）をイベントバスまたはトピックに発行します。Service B は OrderValidated イベントをリッスンして支払いを処理し、その後 PaymentCharged を発行します。Service C は PaymentCharged をリッスンして注文を発送します。各サービスは自律して疎結合されており、自分が消費および生成するイベントだけを認識し、他のサービスについては認識しません。

AWS では、Step Functionsが主要なオーケストレーションツールです。コレオグラフィーでは、主に Amazon EventBridge（内容に基づくフィルタリングでサービス間のイベントをルーティング）、Amazon SNS（単純なファンアウト）、Amazon SQS（サービス間のポイントツーポイントメッセージング）を使用します。パターンを組み合わせることもできます。境界づけられたコンテキスト間のドメイン横断的なコレオグラフィーには EventBridge を使用し、単一ドメイン内のステップのオーケストレーションには Step Functions を使用します。

オーケストレーションでは一元化された可視性が得られます。Step Functions の実行履歴には、ワークフローの現在位置、各ステップにかかった時間、失敗した処理が正確に表示されます。そのため、デバッグが容易です。コレオグラフィーでは、複数のサービスやイベントバスにまたがって可視性が分散します。1 つのビジネストランザクションを追跡するには、多数のサービスにまたがるログとイベントを関連付ける必要があります。そのため、コレオグラフィーシステムでは、エンドツーエンドの可視性を確保するために相関 IDと分散トレーシング（AWS X-Ray）を多用します。

コレオグラフィーは疎結合を実現します。既存のイベントをリッスンする新しいサービスを追加しても、既存のサービスを変更する必要はありません。たとえば、OrderPlaced イベントをリッスンする分析サービスを追加しても、注文サービスや支払いサービスへの影響はありません。オーケストレーションでは、オーケストレーターと呼び出し先のすべてのサービスの間により強い結合が生じます。新しいステップを追加するにはステートマシン定義の変更が必要ですが、個々のサービスは分離されたままです。

オーケストレーションでは、エラー処理が明示的になります。Step Functions の Catch ブロックでエラーの種類ごとにフォールバック状態を定義でき、ワークフロー全体の履歴に失敗のコンテキストが表示されます。コレオグラフィーでは、エラー処理が分散されます。各サービスが自身の障害を処理し、必要に応じて他のサービスが反応できる失敗イベントを発行する必要があります。サガ（ステップが失敗したときに作業を取り消す補償トランザクション）の実装は、オーケストレーションよりもコレオグラフィーの方がはるかに複雑です。

次のような場合はオーケストレーションを優先します。ビジネスプロセスに、成功または失敗の結果が明確な、直線的または分岐する一連の処理がある場合、運用やコンプライアンスのためにプロセスの状態を一元的に把握する必要がある場合、エラー処理に複雑な補償ロジックが含まれる場合、またはワークフローが長時間実行され、サービスの再起動後も継続する必要がある場合です。例として、注文処理、患者のオンボーディング、保険金請求処理など、開始、終了、監査要件が明確なワークフローが挙げられます。

次のような場合はコレオグラフィーを優先します。サービスを異なるチームが所有しており、緊密に連携させるべきでない場合、既存サービスを変更せずに新しいサービスを追加できる拡張性が必要な場合、イベントがコマンドではなく事実を表す場合（例：'OrderShipped' ではなく 'ShipOrder'）、または中央のボトルネックがないため最大限のスケーラビリティが必要な場合です。例として、分析データの取り込み、通知のファンアウト、監査ログなど、複数の独立したコンシューマーが同じイベントに反応するケースが挙げられます。

実際のAWSアーキテクチャのほとんどは、粒度の異なる複数のレベルで両方のパターンを使用します。よくあるハイブリッド構成では、EventBridgeによるコレオグラフィを使って境界づけられたコンテキストを疎結合にします（例：Orderドメインがイベントを発行し、Inventory、Payment、Shippingの各ドメインが独立して応答します）。一方、Paymentドメイン内では、Step Functionsによるオーケストレーションを使って、支払い処理の内部ステップ（請求、詐欺チェック、承認、決済）を調整します。これにより、ドメイン間は疎結合にしながら、内部プロセスの可視性と明確性を確保できます。

試験では、次のような手がかりに注目してください。コレオグラフィを示すキーワードは、「疎結合」、「サービスがイベントに反応する」、「各チームが独立したサービスを所有する」、「複数のコンシューマーへのファンアウト」、「既存のサービスを変更せずに新しいサービスを追加する」などです。オーケストレーションを示すキーワードは、「ステップを順番に調整する」、「ワークフローの状態を追跡する」、「補償処理によって部分的な障害に対処する」、「人による承認ステップ」、「エラーハンドリングを伴う長時間実行プロセス」などです。中央のコーディネーターが他のサービスを指示する問題文は、必ずオーケストレーションを示します。

このレッスンで学んだAWS Solutions Architect（SAA-C03）の概念を理解できているか確認しましょう。

このレッスンでは、オーケストレーションは中央のコーディネーター（Step Functions）を使って、明示的で可視性の高いワークフロー制御を行うこと、コレオグラフィはイベント（EventBridge）を使って疎結合と拡張性を実現すること、そして本番環境のアーキテクチャのほとんどは、粒度の異なる複数のレベルで両方のパターンを組み合わせることを学びました。次は、SAA-C03の試験形式と、ドメインの配点に基づく学習戦略について説明します。