オーケストレーションとコレオグラフィーの違いとは？マイクロサービス連携パターンをAWS実装例で比較する

マイクロサービスに移行してみたはいいが、「サービス間の連携はどう設計すればいいんだ？」という壁にぶつかるエンジニアは多い。

オンプレのモノリシックなシステムでは、関数呼び出しやトランザクションで処理の流れをシンプルに制御できた。しかしマイクロサービスでは、複数の独立したサービスが連携して一つのビジネス処理を完結させる必要がある。この連携の設計方針が「オーケストレーション」と「コレオグラフィー」だ。

この記事では、2つのパターンの違いをAWSの実装例（AWS Step Functions / Amazon EventBridge）を交えて解説し、現場でどちらを選ぶべきかの判断基準まで整理する。

なぜサービス連携の設計方針が重要なのか

マイクロサービスアーキテクチャでは、例えば「EC注文処理」ひとつとっても、在庫サービス・決済サービス・配送サービス・通知サービスなど複数のサービスが関与する。

これらをどう連携させるかによって、システムの疎結合度・障害耐性・デバッグのしやすさ・スケーラビリティが大きく変わる。選択を誤ると、マイクロサービスに移行したのにモノリスより複雑になった、という状況を招く。

マイクロサービスとモノリシックアーキテクチャの違いについてはこちらの記事で解説しているので、アーキテクチャの基礎から理解したい方はあわせて読んでほしい。

オーケストレーションとは？「指揮者モデル」で処理の流れを制御する

オーケストレーション（Orchestration）は、中央の指揮者（オーケストレーター）が各サービスを呼び出して処理の流れを管理するパターンだ。オーケストラの指揮者が各楽器奏者に「次はあなたの番」と指示を出すイメージに近い。

1. 仕組みと特徴

オーケストレーターは各ステップの実行順序・条件分岐・エラーハンドリングを一元管理する。個々のサービスはオーケストレーターからの指示を受けて処理を実行し、結果を返すだけでよい。処理フロー全体の「設計図」がオーケストレーターに集中しているため、フローの可視化が容易だ。

・中央集権型: 処理フローはオーケストレーターが把握している
・同期的な呼び出しが基本: オーケストレーターが各サービスのレスポンスを受け取ってから次の処理に進む（非同期呼び出しも可能）
・フロー可視化が容易: 処理の全体像がオーケストレーターのコードや定義に集約される
・デバッグしやすい: どのステップで失敗したかがオーケストレーターのログから把握できる

2. AWSでの実装例：AWS Step Functions

AWSでオーケストレーションを実装する代表的なサービスがAWS Step Functionsだ。ステートマシン（状態遷移図）としてビジネスフローを定義し、各ステートでLambda関数・ECSタスク・DynamoDB操作などを呼び出せる。

AWS Step Functionsの詳しい使い方はこちらの記事で解説しているが、ここでは注文処理フローの例を示す。

# Step Functions ステートマシン定義（抜粋）
# 注文処理フロー: 在庫確認 → 決済処理 → 配送指示 → 通知
{
  "Comment": "EC注文処理フロー",
  "StartAt": "在庫確認",
  "States": {
    "在庫確認": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789:function:check-inventory",
      "Next": "決済処理",
      "Catch": [{"ErrorEquals": ["在庫不足"], "Next": "在庫不足通知"}]
    },
    "決済処理": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789:function:process-payment",
      "Next": "配送指示"
    },
    "配送指示": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789:function:arrange-delivery",
      "Next": "完了通知"
    },
    "完了通知": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789:function:send-notification",
      "End": true
    },
    "在庫不足通知": {
      "Type": "Task",
      "Resource": "arn:aws:lambda:ap-northeast-1:123456789:function:notify-out-of-stock",
      "End": true
    }
  }
}

この例では「注文フローの全体設計」がStep Functionsの定義に集約されている。在庫不足の場合の分岐処理も定義内で完結しており、フロー全体がAWSコンソール上でグラフィカルに確認できる。オペレーターが処理の現在地を可視化できるのは、運用面での大きなメリットだ。

コレオグラフィーとは？「ダンサーモデル」でサービスが自律的に反応する

コレオグラフィー（Choreography）は、中央の指揮者を持たず、各サービスがイベントに反応して自律的に処理を実行するパターンだ。バレエのコレオグラフィー（振り付け）のように、各ダンサーが振り付けを覚えて自分のタイミングで動くイメージだ。

1. 仕組みと特徴

あるサービスが処理を完了するとイベントをパブリッシュし、そのイベントに関心を持つ別のサービスがサブスクライブして処理を続ける。サービス間に明示的な依存関係はなく、イベントバスやメッセージキューを介して間接的に連携する。

・分散自律型: 各サービスは「どのイベントが来たら何をするか」だけを知っている
・疎結合: サービス同士が直接通信せず、イベントを介して間接的に連携する
・高スケーラビリティ: 新サービスの追加が既存サービスへの変更なしにできる
・フロー把握が難しい: 全体の処理フローがコード上に明示されない

2. AWSでの実装例：Amazon EventBridge + SQS

コレオグラフィーでよく使われるAWSサービスがAmazon EventBridgeとAmazon SQSの組み合わせだ。

Amazon EventBridgeの詳しい使い方はこちらの記事で解説している。同じ注文処理フローをコレオグラフィーで実装すると以下のようになる。

# コレオグラフィーによる注文処理フローのイメージ（擬似コード）

# 1. 注文サービスが注文確定イベントをパブリッシュ
EventBridge.putEvent({
  "source": "order-service",
  "detail-type": "OrderPlaced",
  "detail": { "orderId": "ORD-001", "customerId": "USR-123" }
})

# 2. 在庫サービスが "OrderPlaced" を受け取り在庫確認を実行
#    完了後に次のイベントをパブリッシュ
EventBridge.putEvent({
  "source": "inventory-service",
  "detail-type": "InventoryReserved",
  "detail": { "orderId": "ORD-001" }
})

# 3. 決済サービスが "InventoryReserved" を受け取り決済処理
#    完了後にイベントをパブリッシュ
EventBridge.putEvent({
  "source": "payment-service",
  "detail-type": "PaymentCompleted",
  "detail": { "orderId": "ORD-001" }
})

# 4. "PaymentCompleted" を複数サービスが並行してサブスクライブ
#    配送サービス → 配送指示を開始
#    通知サービス → 注文完了メールを送信
#    ポイントサービス → ポイント付与処理を実行
#    ※いずれも既存サービスへの変更なく追加・削除できる

この設計では、配送サービスと通知サービスが同じ「PaymentCompleted」イベントを並行して処理できる。後から「ポイント付与サービス」を追加する場合も、既存サービスへの変更なく新サービスが同イベントをサブスクライブするだけでよい。

Amazon SQSによるメッセージキューの詳細もあわせて参考にしてほしい。

オーケストレーション vs コレオグラフィー 比較表

どちらを選ぶべきか？現場での判断基準

「どちらが優れているか」という問いに答えはない。ユースケースの性質によって使い分けるのが正解だ。

1. オーケストレーションが向くケース

・複数ステップに明確な順序がある処理（在庫確認→決済→配送という順序が崩れると困る）
・複雑な条件分岐・リトライロジックを一元管理したい場合
・処理の進捗や状態を可視化・監視する必要がある場合（Step Functionsのコンソールでどのステートにいるかリアルタイムで確認できる）
・ビジネスプロセスを非エンジニアにも説明する必要がある場合
・エラー時のロールバックを一箇所で管理したい場合

2. コレオグラフィーが向くケース

・処理の順序に厳密な依存がない場合（通知・ログ記録・分析は決済完了後に並行実行できる）
・将来的に新サービスを追加することが予想される場合
・高スループット・高スケーラビリティが求められる場合
・サービス間の独立性を最大化したい場合
・非同期でよい処理（リアルタイム性が不要）

3. 【判断の目安】問いかけで選ぶ

現場でよく使われる判断軸を紹介する。

「フロー全体の設計図が読み取れないと困る複雑な処理か？」→ Yes ならオーケストレーション
「サービスの追加・変更が頻繁に発生する予定か？」→ Yes ならコレオグラフィー
「処理の順序が厳密に定義されているか？」→ Yes ならオーケストレーション
「各処理が独立して実行されてよいか？」→ Yes ならコレオグラフィー
「障害発生時に全体フローを一箇所でリカバリしたいか？」→ Yes ならオーケストレーション

ハイブリッドパターン：組み合わせて使う

実務では、オーケストレーションとコレオグラフィーを組み合わせた設計が最も現実的だ。

例として、ECサイトの注文処理を考えてみる。

・注文確定フロー（在庫確認→決済→配送）: 順序と整合性が重要 → Step Functionsでオーケストレーション
・注文確定後の付随処理（ポイント付与・メール通知・分析データ送信）: 順序不問・並行可 → EventBridgeでコレオグラフィー

Step Functionsの最終ステートからEventBridgeにイベントをパブリッシュすることで、「中核フローはオーケストレーション、周辺の拡張処理はコレオグラフィー」というスッキリした設計になる。この組み合わせは、AWSアーキテクチャのベストプラクティスとして実際の設計レビューでも頻繁に推奨される構成だ。

なお、分散トランザクションの管理パターンとして有名なSagaパターンは、オーケストレーション版（Orchestration-based Saga）とコレオグラフィー版（Choreography-based Saga）の両方で実装できる。複数サービスにまたがる整合性の設計もあわせて押さえておくと設計の幅が広がる。

よくある誤解と落とし穴

【誤解1】「コレオグラフィーのほうが疎結合で優れている」

コレオグラフィーはサービス間の直接依存がないが、代わりに「イベントのスキーマ（形式）」に依存する。イベント定義が変わると影響範囲が広がりやすく、スキーマの管理（Amazon EventBridge Schema Registryなど）を怠ると、疎結合のはずが実は壊れやすい設計になる。「疎結合＝コレオグラフィー」という短絡思考には注意が必要だ。

【誤解2】「オーケストレーションは密結合でアンチパターン」

オーケストレーターが各サービスのAPIを直接呼び出す場合は密結合になりやすいが、Step FunctionsがLambda ARNを呼び出すパターンでは、Lambda関数自体はオーケストレーターの存在を知らない。適切に設計すれば、オーケストレーションでも個々のサービスの独立性は保てる。

【落とし穴】コレオグラフィーの「デバッグ地獄」

コレオグラフィーでは処理が複数サービスに分散するため、障害発生時に「どのサービスのどのイベント処理で失敗したか」を追うのが難しい。OpenTelemetryによる分散トレーシングなど、オブザーバビリティの仕組みをあらかじめ整備しておくことが欠かせない。コレオグラフィーを採用する場合は、監視・トレーシング設計もセットで検討することを強く勧める。

本記事のまとめ

「どちらが正解か」ではなく、「このフローの特性はどちらに向いているか」で判断することが重要だ。多くの現場では、複雑なビジネスフローの核部分にオーケストレーション、その周辺の拡張処理にコレオグラフィーを使うハイブリッドが最も現実的な解答となる。

設計の段階でこの選択を意識しておくことで、マイクロサービス移行後の「思ったより複雑になった」という後悔を防ぐことができる。