変更要約: 初版
2.5イベント駆動とメッセージング
サービス間を非同期に連携させるメッセージキュー（MQ）・ESB・API Gatewayの役割の違い、イベント駆動アーキテクチャによる疎結合な連携、そして非同期連携につきまとうメッセージの順序保証・重複配信・結果整合性の注意点を学びます。
マイクロサービス間の連携をすべて同期的なAPI呼び出しで実装すると、呼び出し先の応答が遅れた瞬間に呼び出し元も待たされ、障害が連鎖的に伝播するカスケード障害のリスクが高まります。この課題に対処する代表的な手段が非同期のメッセージングです。しかし非同期連携は「呼び出し元を待たせない」という利点と引き換えに、メッセージの順序が入れ替わる・重複して配信される・処理結果が即座には反映されない（結果整合性）という新たな注意点を持ち込みます。この節では、メッセージング基盤の使い分けと、非同期連携特有の落とし穴を学びます。
2.5.1MQ・ESB・API Gatewayの役割
- メッセージキュー（MQ）＝送信側がメッセージをキューへ投入し、受信側が自分の都合の良いタイミングで取り出して処理する非同期連携の基盤。送信側と受信側の処理速度差を吸収でき、受信側が一時的に停止していてもメッセージはキューに残り後で処理できるため、疎結合な連携に向く。
- ESB（エンタープライズサービスバス）＝複数システム間のメッセージ仲介・プロトコル変換・データ変換・ルーティングを一元的に担う基盤。異種システム間の統合を単純化できるが、ビジネスロジックをESB側に集約しすぎると、ESBが単一障害点や変更のボトルネックになりやすい（＝「スマートな配管、ダムなエンドポイント」ではなく配管自体が肥大化する落とし穴）。
- API Gateway＝クライアントからのリクエストを受け付け、認証・レート制限・ルーティングなど横断的関心事（クロスカッティングコンサーン）を一元処理してから各マイクロサービスへ振り分ける入口。個々のサービスが認証やレート制限を重複実装せずに済む利点がある一方、API Gateway自体が単一障害点や性能のボトルネックになり得るため冗長化が前提となる。
2.5.2非同期連携の注意点：順序・重複・結果整合性
- メッセージの順序保証＝分散環境では複数の送信元・複数のキュー分割（パーティション）を使うと、送信した順序どおりに受信側へ届くとは限らない。順序が業務上重要な場合（例：口座への入金と出金の順序）は、同一キー（口座ID等）のメッセージを同一パーティションへ固定する等の設計が必要になる。
- 重複配信（At-least-once配信）＝多くのメッセージング基盤は「少なくとも1回は届ける」ことを保証するために、ネットワーク再送等で同じメッセージが複数回届く可能性を許容する。このため受信側の処理は、同じメッセージを複数回処理しても結果が変わらない冪等性（べきとうせい）を持たせる設計が必須になる（例：処理済みメッセージIDを記録し二重処理を防ぐ）。
- 結果整合性＝非同期連携では、あるサービスでの更新が別サービスに反映されるまでに時間差が生じる。「更新直後は一時的にデータが食い違う可能性がある」ことを前提に、利用者への見せ方（処理中表示等）や補償処理を設計する必要があり、常に即座の一貫性を要求する業務（例：残高が瞬時に一致しないと致命的な決済）には非同期連携がそもそも不向きな場合もある。
「MQ＝送受信の速度差吸収・疎結合」「ESB＝異種統合を一元化するが肥大化するとSPOFになる」「API Gateway＝横断的関心事を一元処理する入口」「非同期連携は順序保証・重複配信・結果整合性への対処が必須」が最頻出です。「非同期にすれば必ず信頼性が上がる」という単純化に注意しましょう。
あるシステムアーキテクトが、注文サービスから在庫サービス・決済サービス・配送サービスへ連携する処理を、これまでの同期API呼び出しから非同期メッセージングへ切り替える設計を検討しています。現行の同期方式では、配送サービスの応答が遅延すると注文サービスもその分だけ待たされ、配送サービス側で障害が起きると注文確定処理そのものが失敗するカスケード障害が過去に発生していました。そこでアーキテクトは、注文確定イベントをメッセージキューへ発行し、在庫・決済・配送の各サービスがそれぞれ自分の都合の良いタイミングでイベントを受け取って処理するイベント駆動アーキテクチャへ移行します。これにより、配送サービスが一時的に停止していても、注文確定イベントはキューに残り、配送サービスが復旧した時点で処理を再開できるため、カスケード障害のリスクは大幅に下がります。しかし、この移行に伴い新たな注意点が生じます。まず、同じ注文確定イベントがネットワーク再送等の理由で決済サービスに2回届いてしまうと、決済処理が二重に実行され二重課金という重大な事故につながるリスクがあるため、決済サービス側は受信したイベントIDを記録し、既に処理済みのIDであれば処理をスキップする冪等性を持った実装に変更する必要があります。次に、同一注文について「注文確定」イベントと、それを取り消す「注文キャンセル」イベントが極めて短い間隔で発行された場合、メッセージ基盤の構成によっては後発のキャンセルイベントが先に届いてしまう順序の入れ替わりが起こり得るため、同一注文IDのイベントは同一パーティションに固定して送信順を保証する設計が必要です。さらに、注文確定から配送手配の反映までに数秒〜数十秒の遅延が生じ得るため、利用者向けの注文状況画面では「配送手配中」といった中間状態を明示し、即座に配送完了と誤解させない表示設計も合わせて行いました。このように、非同期メッセージングへの移行はカスケード障害の抑制という利点と引き換えに、冪等性・順序保証・結果整合性の見せ方という3つの設計課題を新たに引き受けることになります。
| 基盤 | 主な役割 | 主なリスク |
|---|---|---|
| MQ（メッセージキュー） | 送受信の速度差吸収・非同期の疎結合連携 | 順序入替・重複配信への対処が必要 |
| ESB | 異種システム間の仲介・変換・ルーティング | 肥大化でSPOF・変更ボトルネック化 |
| API Gateway | 認証・レート制限等の横断的関心事を一元処理 | 冗長化しないと単一障害点・性能ボトルネック |
ひっかけ： 「非同期メッセージングにすれば信頼性が自動的に上がる」は誤りです——カスケード障害の抑制という利点は得られますが、代わりにメッセージの重複配信・順序入れ替わり・結果整合性という新たな設計課題を引き受ける必要があります。特に冪等性を考慮せずに非同期化すると、重複配信によって決済の二重実行のような重大事故を招きます。また「ESBに業務ロジックを集約するほど統合が楽になる」も誤り＝ESBへの過度な集約はESB自体を単一障害点・変更のボトルネックにするリスクがあります。
2.5.3この節のまとめ
- MQは送受信の速度差吸収、ESBは異種統合の一元化（肥大化に注意）、API Gatewayは横断的関心事の一元処理
- 非同期連携ではメッセージの順序入れ替わり・重複配信・結果整合性への対処が必須
- 重複配信に備え受信側処理を冪等にし、順序が重要な場合は同一キーを同一パーティションへ固定する
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. 注文サービスから配送サービスへの同期API呼び出しで、配送サービスの障害時に注文確定処理そのものが失敗するカスケード障害が過去に発生した。この問題への最も妥当な設計対応はどれか。
Q2. 注文確定イベントを非同期メッセージングへ移行したところ、ネットワーク再送により同じイベントが決済サービスに2回届く可能性があることが分かった。この状況への最も妥当な設計対応はどれか。
Q3. 複数システムを統合するプロジェクトで、プロトコル変換・データ変換に加えて業務ロジックの大部分をESB側に実装する設計が提案された。この設計への最も適切な指摘はどれか。