クイズの説明
Step 3「イベント駆動で疎結合を実現する」で学んだ内容の理解度を確認します。全8問、80%（7問）以上正解で合格です。
問題
Q1. イベント駆動アーキテクチャにおけるメッセージングパターンで「Pub/Sub」の特徴はどれですか？
- A) 1つのメッセージは1つのConsumerのみが処理する
- B) 1つのメッセージを複数のSubscriberが受信できる
- C) メッセージは先入先出で必ず順序通りに処理される
- D) 送信者が受信者のアドレスを直接指定する
答えを見る
正解: B
Pub/Sub（Publish/Subscribe）パターンでは、Publisherがトピックにメッセージを発行し、そのトピックを購読している複数のSubscriberが同じメッセージを受信できます。Point-to-Point（キュー）パターンでは1つのConsumerのみが処理します。KafkaのConsumer Groupを使うと、同一グループ内ではPoint-to-Point、グループ間ではPub/Subとして動作します。
Q2. Apache KafkaのPartitionの主な目的はどれですか？
- A) データの暗号化
- B) メッセージの並列処理とスループット向上
- C) メッセージの圧縮
- D) Consumer認証
答えを見る
正解: B
Partitionはトピックを複数の並列処理単位に分割します。各Partitionは独立してConsumerに割り当てられるため、Partition数を増やすことでスループットが向上します。同一Partition内ではメッセージの順序が保証されますが、Partition間では保証されません。注文IDなどをPartition Keyにすることで、同一注文のイベントを同一Partitionに集約できます。
Q3. CloudEvents仕様の「type」フィールドの用途として正しいものはどれですか？
- A) イベントのシリアライゼーション形式を指定する
- B) イベントの種別を示し、Consumerのルーティングに使用する
- C) イベントの優先度を指定する
- D) イベントの有効期限を指定する
答えを見る
正解: B
CloudEventsのtypeフィールドはイベントの種別（例: order.confirmed）を示します。Consumerはこのフィールドでイベントをフィルタリング・ルーティングし、適切なハンドラに振り分けます。シリアライゼーション形式はdatacontenttypeで指定します。
Q4. スキーマのFORWARD互換性が意味するものはどれですか？
- A) 新しいConsumerが古いProducerのデータを読める
- B) 古いConsumerが新しいProducerのデータを読める
- C) 新旧のConsumer/Producerが双方向に互換性がある
- D) スキーマの変更が一切できない
答えを見る
正解: B
FORWARD互換性は「古いConsumerが新しいProducerのデータを読める」ことを保証します。フィールドの追加は許可されますが、既存フィールドの削除や型変更は禁止です。これにより、Producerを先にデプロイし、Consumerを後からアップデートできます。
Q5. Choreography SagaよりOrchestration Sagaが適している場面はどれですか？
- A) 2つのサービスだけで完結する単純なフロー
- B) 5つ以上のサービスが関わる複雑なビジネスフロー
- C) サービス間の依存を完全に排除したい場合
- D) イベントブローカーを使わないシステム
答えを見る
正解: B
Orchestration Sagaは5つ以上のサービスが関わる複雑なフローに適しています。中央のオーケストレーターがフロー全体を制御するため、可視性が高く、デバッグやモニタリングが容易です。Choreographyはサービス数が増えるとイベントの連鎖が追跡困難になり、「分散スパゲッティ」に陥るリスクがあります。
Q6. 補償トランザクション（Compensating Transaction）の原則として正しいものはどれですか？
- A) 元のトランザクションを技術的にロールバックする
- B) ビジネスレベルで逆の操作を実行し、整合性を回復する
- C) データベースのWALを使って自動ロールバックする
- D) 失敗したトランザクションを無限にリトライする
答えを見る
正解: B
補償トランザクションは技術的なロールバックではなく、ビジネスレベルで逆の操作を行います。例えば、決済の補償は「ロールバック」ではなく「返金」という新しいトランザクションです。在庫の補償は「引当解除」です。各補償は冪等に設計し、補償自体が失敗した場合のアラートとマニュアル対応フローも必要です。
Q7. イベントの冪等性を確保する最も効果的な方法はどれですか？
- A) メッセージにTTLを設定する
- B) イベントIDを記録し、処理済みのイベントをスキップする
- C) Consumerの処理速度を遅くする
- D) 全てのイベントをバッチ処理する
答えを見る
正解: B
冪等性の確保にはイベントIDの重複チェックが最も効果的です。処理済みイベントIDをDBに記録し、同じIDのイベントが再度到着した場合はスキップします。これにより、ネットワーク障害やConsumerの再起動による重複処理を防止できます。Inbox パターンとして知られるこのアプローチは、exactly-once セマンティクスを実現する基盤です。
Q8. Sagaにおけるピボットトランザクションの説明として正しいものはどれですか？
- A) 最初に実行されるトランザクション
- B) 補償不可能なトランザクションで、成功すればSagaは必ず完了に向かう
- C) 最も処理時間が長いトランザクション
- D) 全てのサービスに影響するトランザクション
答えを見る
正解: B
ピボットトランザクションは「補償不可能なトランザクション」です。例えば外部決済APIへの課金は、一度完了すると技術的にロールバックできません（返金は別トランザクション）。ピボットトランザクションが成功すれば、残りのステップは「リトライ可能」なステップのみとなり、Sagaは必ず完了に向かいます。設計上、ピボットトランザクションはできるだけ後ろに配置します。
結果
7問以上正解の場合
合格です。 イベント駆動アーキテクチャの基礎を理解しています。
「イベント駆動の設計ができたな。次は分散トランザクションをさらに深く掘り下げよう」 — 佐藤CTO
6問以下の場合
もう少し復習しましょう。
- Q1-Q2を間違えた場合 → Step 3-1「メッセージングパターン」を復習
- Q3-Q4を間違えた場合 → Step 3-3「イベントスキーマ設計」を復習
- Q5-Q8を間違えた場合 → Step 3-4「Sagaパターン」を復習