LinuCレベル4 システムアーキテクト システムアーキテクチャ 問4
システムアーキテクチャ／アーキテクチャの設計原則と主要パターンECサイトの注文サービスが「注文確定」イベントを出すたびに、出荷・ポイント付与・売上分析の3サービスがそれぞれ全件を処理する必要がある。今後も購読するサービスが増える見込みだが、注文サービス側の改修は避けたい。連携方式として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「システムアーキテクチャ」に対応。実際の試験問題ではありません）
- A1つのメッセージキューに3サービスのワーカーを接続し、到着したメッセージを空いているワーカーが順に取り出す
- Bブローカーのトピックへイベントを発行し、各サービスが個別の購読を持って同じイベントをそれぞれ受け取る
- C注文サービスが3サービスのAPIを同期的に順に呼び出し、全サービスの応答を待ってから注文を確定する
- D注文サービスがイベントを出荷サービスに送り、出荷サービスが処理後にポイント、分析の順に転送する
正解：B
解説
Pub/Subパターンでは、発行者はブローカーのトピックへメッセージを送るだけで、購読者がそれぞれ同じメッセージの写しを受け取ります。発行者は購読者を知らなくてよいため、購読するサービスを後から追加しても発行側の改修が不要です。これに対し、1つのキューを複数のワーカーで取り合う構成（ポイントツーポイント）では、各メッセージは1つのワーカーにしか届かず、処理の負荷分散に向く方式になります。同じイベントを複数の独立した処理に配る要件ならPub/Subを選びます。
選択肢ごとの解説
- A誤り。1つのキューを複数のワーカーで取り合うと、各メッセージはどれか1つのサービスにしか届きません。同種の処理を分散させる用途なら適切な構成です。
- B正しい。トピックと購読を使うPub/Subなら全サービスが同じイベントを受け取れ、購読者の追加も発行側に影響しません。
- C誤り。同期呼び出しでは注文サービスが呼び出し先を知る必要があり、サービス追加のたびに改修が必要です。1つでも応答しないと注文確定まで止まります。
- D誤り。数珠つなぎに転送すると出荷サービスの障害や遅延が後続すべてに波及し、購読先の追加も出荷サービスの改修を伴います。