LinuCレベル4 システムアーキテクト システムアーキテクチャ 問13
システムアーキテクチャ／柔軟性を高めるアーキテクチャパターン注文サービスが発行する注文イベントを、配送・請求の2つのサービスが処理している。新たに需要予測サービスを追加するにあたり、過去7日分の注文イベントを最初から読み直して学習させたい。また、障害で止まったサービスは、再開後に自分が止まった位置から処理を続けたい。既存のサービスの処理には影響させない。イベントの受け渡し方式として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「システムアーキテクチャ」に対応。実際の試験問題ではありません）
- A1つの作業キューにイベントを入れ、各サービスのワーカーが取り出して処理し、処理済みのメッセージはキューから削除する
- B注文サービスがイベントの発生時に各サービスのAPIを同期的に呼び出し、新しいサービスも呼び出し先の一覧に加える
- C購読中のサービスへその場で配信して配信後は保持しないPub/Subのトピックに発行し、需要予測サービスも購読に加える
- Dイベントを保持期間付きのストリームに順に追記し、各サービスが自分の読み取り位置を記録しながら独立に読み進める
正解：D
解説
ストリーム（ログ型のメッセージング）は、イベントを順序付きで一定期間保持し、読み手ごとに読み取り位置を管理させる方式です。読み手は互いに独立しているため、新しいサービスを追加しても既存のサービスの処理に影響せず、保持期間内であれば過去のイベントを先頭から読み直せます。障害で止まった読み手も、記録しておいた位置から処理を再開できます。作業キューは取り出したメッセージを消費して消すため、複数サービスへの配信や過去分の再処理には向きません。
選択肢ごとの解説
- A誤り。作業キューは1件のメッセージを1つのワーカーが処理する負荷分散向けの方式で、取り出したメッセージは削除されます。サービスごとに全件を受け取ることも、過去分を読み直すこともできません。
- B誤り。同期呼び出しでは呼び出した時点のイベントしか渡せず、過去7日分を読み直す要件を満たせません。呼び出し先が増えるほど注文サービス側の応答時間と改修も増えます。
- C誤り。保持しないPub/Subでは、購読を始める前に発行されたイベントは受け取れません。複数のサービスへ同じイベントを配る要件には合いますが、過去分の再処理には使えません。
- D正しい。ストリームはイベントを保持期間の間残すため、新しいサービスは先頭から読み直せます。読み取り位置を各サービスが管理するので、停止後もその位置から再開でき、他のサービスにも影響しません。