ストーリー
高橋アーキテクト が最後の試験を前に、あなたに語りかけました。
クイズ（8問）
合格ライン: 80%（8問中7問正解）
Q1. 以下のうち、マイクロサービスへの分割基準として最も適切なものはどれか？
- A: データベースのテーブル数に基づいて分割
- B: 技術レイヤー（プレゼンテーション、ビジネスロジック、データアクセス）で分割
- C: DDDの境界づけられたコンテキストとコンウェイの法則に基づいて分割
- D: コード行数が均等になるように分割
回答と解説
正解: C
マイクロサービスの分割はDDDの境界づけられたコンテキスト（ビジネスドメインの自然な境界）とコンウェイの法則（チーム構造との整合）に基づいて行うべきです。テーブルやレイヤーでの分割はアンチパターンであり、コード行数の均等化にはビジネス上の意味がありません。
Q2. 配車サービスで「ドライバーの位置情報取得」に最適な通信方式はどれか？
- A: メッセージキュー経由の非同期通信
- B: gRPCによる同期通信
- C: メール通知
- D: バッチ処理
回答と解説
正解: B
ドライバーの位置情報取得は、リアルタイムで即座に結果が必要な場面であるため、同期通信が適切です。gRPCはProtocol Buffersによる高速なバイナリ通信で、位置情報のような頻繁な呼び出しに向いています。非同期通信では遅延が発生し、リアルタイムの位置表示に適しません。
Q3. Kafkaのパーティションキーに「rideId」を指定する目的はどれか？
- A: メッセージのサイズを最適化するため
- B: 同じrideIdのイベントが同じパーティションに送られ、順序が保証されるため
- C: パーティション数を自動調整するため
- D: メッセージの暗号化のため
回答と解説
正解: B
Kafkaは同一パーティション内のメッセージ順序を保証します。rideIdをパーティションキーに指定すると、同じ配車の全イベント（requested, matched, started, completed）が必ず同じパーティションに送られるため、イベントの処理順序が保証されます。
Q4. 決済サービスで二重課金を防ぐために最も効果的な方法はどれか？
- A: リトライを無効にする
- B: 冪等キー（rideIdベース）を使った冪等な決済処理
- C: 決済処理を同期的に実行する
- D: 決済前に必ず残高を確認する
回答と解説
正解: B
冪等キー（例: ride-${rideId}-payment）を使って決済処理を冪等にすることで、同じリクエストが複数回届いても1回だけ決済が実行されます。リトライの無効化はメッセージロストのリスクがあり、同期実行や残高確認だけでは重複リクエストを防げません。
Q5. Sagaの補償トランザクションについて正しいものはどれか？
- A: 補償はデータベースのROLLBACKと同等の動作をする
- B: 補償は最初のステップから順に実行する
- C: 補償は完了済みステップを逆順に実行し、それ自体も冪等でなければならない
- D: 補償が失敗した場合はSaga全体を最初からやり直す
回答と解説
正解: C
補償トランザクションは完了済みステップを逆順に実行して、ビジネス的に打ち消す操作を行います。補償自体もネットワーク障害等でリトライされる可能性があるため、冪等性が必要です。DBのROLLBACKとは異なり履歴は残り、最初から再実行するのではなく失敗地点から逆順に補償します。
Q6. Outboxパターンで「同一トランザクション」内に書き込む理由はどれか？
- A: パフォーマンスを向上させるため
- B: ビジネスデータの保存とイベントの発行を原子的に行うため
- C: テーブル結合を最適化するため
- D: 外部キー制約を適用するため
回答と解説
正解: B
Outboxパターンでは、ビジネスデータ（例: 注文レコード）とイベントデータ（Outboxテーブル）を同一トランザクション内に書き込みます。これにより、「データは保存されたがイベントが発行されない」または「イベントは発行されたがデータが保存されない」という不整合を防ぎます。
Q7. CQRSのRead Modelに非正規化データを持つ最大の利点はどれか？
- A: ストレージ使用量が減る
- B: JOINなしで高速なクエリが可能になる
- C: データの整合性が強化される
- D: Write Modelの設計がシンプルになる
回答と解説
正解: B
Read Modelを非正規化することで、複数テーブルのJOINが不要になり、1回のクエリで必要な情報をすべて取得できます。これにより読み取りパフォーマンスが大幅に向上します。ストレージは増加しますが、読み取り性能の向上がそのコストを上回ります。
Q8. Chaos Engineeringで「Payment Serviceが5秒間応答しない」実験を行った。期待される正しいシステムの挙動はどれか？
- A: 全サービスが5秒間停止する
- B: 乗車完了は正常に表示され、決済はタイムアウト後に非同期でリトライされる
- C: 乗客に「システムエラー」が表示される
- D: ドライバーアプリがクラッシュする
回答と解説
正解: B
適切に設計された分散システムでは、Payment Serviceの遅延は決済処理にのみ影響し、他のサービスは正常に動作し続けます。乗車完了は正常に処理され、決済はタイムアウト後にサーキットブレーカーが作動し、メッセージキューを通じて非同期でリトライされます。これがSagaパターンとイベント駆動の耐障害性です。
結果判定
合格（7問以上正解）
おめでとうございます！ Month 5「分散の嵐を乗りこなそう」を修了しました。
あなたは以下のスキルを身につけました:
- マイクロサービスアーキテクチャの設計
- イベント駆動アーキテクチャの構築
- Sagaパターンによる分散トランザクション管理
- CQRSと結果整合性の設計
- Contract TestingとChaos Engineeringの計画
Month 6では、さらに高度なインフラストラクチャとクラウドアーキテクチャの世界に踏み込みます。
不合格（6問以下）
Step 4（Sagaパターン）とStep 5（CQRS）を中心に復習しましょう。特に以下のポイントを重点的に見直してください:
- 補償トランザクションの設計原則
- Outboxパターンの仕組み
- CQRSのRead/Write Model設計
- 結果整合性のUX対策
高橋アーキテクト の言葉:
「分散システムは難しい。でも、原則を理解して正しいパターンを適用すれば、複雑さを管理できる。大事なのは”銀の弾丸はない”ということ。常にトレードオフを意識して、最適な判断をしよう。君はもう、その力を持っている」
推定所要時間: 30分