LinuCレベル4 システムアーキテクト システムアーキテクチャ 問16
システムアーキテクチャ／アーキテクチャの設計原則と主要パターンECサイトの注文サービスは、注文確定メール生成にユーザーの住所・氏名が必要である。ユーザーサービスへの同期呼び出しを避け、ユーザーサービスの障害が注文処理に波及しないようにしたい。設計として最も適切なものはどれか。
当サイトのオリジナル問題（LinuCレベル4 システムアーキテクトの出題範囲「システムアーキテクチャ」に対応。実際の試験問題ではありません）
- A注文サービスがユーザーサービスのDBに直接接続し、注文処理のトランザクション内で必要なプロフィールを読み取る
- Bユーザーサービスが発行するプロフィール更新イベントを購読し、注文サービスが自前のデータストアにコピーを保持して参照する
- C注文サービスがユーザーサービスのAPIを同期呼び出しし、常に最新プロフィールをキャッシュなしで取得して使う
- D注文サービスとユーザーサービスを同一プロセスにまとめ、プロセス内の関数呼び出しでプロフィールを参照する
正解：B
解説
マイクロサービス間でデータを共有する方法として、相手サービスのDBへの直接アクセスやAPIの同期呼び出しは、カプセル化を破壊したり可用性の依存関係を作ったりします。イベント駆動の非同期レプリケーションパターンでは、注文サービスがユーザーサービスのプロフィール更新イベントを購読して自前のデータストアに保持します。これによりユーザーサービスが停止しても注文サービスは独立して動作できます。結果整合性は生じますが、住所・氏名のような変化が少ないデータには多くの場合許容できます。
選択肢ごとの解説
- A誤り。ユーザーサービスのDBに直接アクセスすると、サービス間のデータ所有権とカプセル化が損なわれます。DB構造の変更がすべての利用側サービスに影響し、独立したデプロイが困難になります。
- B正しい。ユーザーサービスが変更イベントを発行し、注文サービスがそれを購読して非同期レプリカを保持するパターンです。同期依存がなくなり、ユーザーサービスの停止が注文処理に波及しません。
- C誤り。同期呼び出しを続けるとユーザーサービスの遅延や障害が注文サービスに直接波及します。ユーザーサービス停止時に注文処理も停止するという可用性の結合が残ります。
- D誤り。サービスをモノリスに統合すると、個別のデプロイやスケーリングができなくなりマイクロサービスの利点が失われます。可用性の隔離もできません。