クイズの説明
月2「マイクロサービスへの移行を主導しよう」の全範囲から出題します。全10問、80%（8問）以上正解で合格です。
問題
Q1. 「分散モノリス」が発生する最も一般的な原因はどれですか？
- A) マイクロサービスの数が多すぎる
- B) 技術層（フロント/API/DB）で分割してしまい、ビジネスドメインの境界を無視した
- C) コンテナ技術を使用していない
- D) CIパイプラインが統合されていない
答えを見る
正解: B
分散モノリスは、マイクロサービスに分割したにもかかわらずサービス間の結合度が高い状態です。最も一般的な原因は、技術層で分割したことです。DDDのBounded Contextに基づくビジネスドメインの境界でサービスを分割しないと、モノリスの問題をそのまま分散環境に持ち込むことになります。
Q2. DDD における Aggregate の設計指針として正しいものはどれですか？
- A) 1つのAggregateに全てのエンティティを含める
- B) Aggregateは小さく保ち、他のAggregateへの参照はIDのみで行う
- C) Aggregate間でもDBトランザクションで整合性を保つ
- D) Aggregate RootはValue Objectとして実装する
答えを見る
正解: B
Aggregateはトランザクション整合性の最小単位であり、小さく保つことが重要です。他のAggregateへの参照はIDのみで行い、直接のオブジェクト参照を避けます。Aggregate間の整合性はイベントによる結果整合性で管理します。AggregateのRoot はEntityです。
Q3. Strangler Figパターンで最初に分離すべきサービスの選定基準の組み合わせとして最適なものはどれですか？
- A) コード行数が多い + テストが少ない
- B) 変更頻度が高い + 他モジュールへの依存が少ない
- C) 最も古いコード + 最も多くのバグ
- D) ユーザー数が多い + レスポンスが遅い
答えを見る
正解: B
最初に分離すべきは「変更頻度が高い（独立デプロイの効果大）」かつ「他モジュールへの依存が少ない（分離リスクが低い）」サービスです。この条件を満たすサービスから始めることで、早期に成果を示しながらリスクを最小化できます。
Q4. Kafkaで同一注文のイベント順序を保証するために最も重要な設定はどれですか？
- A) レプリカ数を3にする
- B) Partition Keyに注文IDを設定する
- C) Consumer Groupを1つにする
- D) メッセージにタイムスタンプを付与する
答えを見る
正解: B
KafkaはPartition内でのみメッセージ順序を保証します。注文IDをPartition Keyに設定することで、同一注文の全イベントが同じPartitionに格納され、順序が保証されます。レプリカ数は可用性、Consumer Groupは並列処理に関する設定です。
Q5. Outboxパターンにおいて、Debezium（CDC）ではなくPolling Publisherを選ぶべき場面はどれですか？
- A) リアルタイム性が重要な大規模システム
- B) インフラ構築コストを最小限にしたい小規模チーム
- C) イベント量が毎秒10万件を超えるシステム
- D) 複数のデータベース種類を統合する場合
答えを見る
正解: B
Polling Publisherはアプリケーション内で定期的にOutboxテーブルを読み取る方式で、Debezium等の追加インフラが不要です。小規模チームや初期フェーズではインフラの複雑さを抑えられます。ただし、ポーリング間隔分の遅延が発生するため、リアルタイム性が重要な大規模システムにはCDCが適しています。
Q6. Sagaパターンで決済処理を「ピボットトランザクション」として扱う理由はどれですか？
- A) 処理時間が最も長いから
- B) 外部APIへの課金は技術的にロールバックできず、返金は別トランザクションになるから
- C) 最初に実行されるトランザクションだから
- D) 全サービスが依存しているから
答えを見る
正解: B
外部決済API（Stripe等）への課金は、一度完了すると技術的にロールバックできません。返金は「新しい返金トランザクション」として処理されます。ピボットの前のステップはCompensatable（補償可能）、後のステップはRetriable（リトライで必ず成功）として設計します。
Q7. サービスメッシュにおけるサイドカープロキシの最大のトレードオフはどれですか？
- A) プログラミング言語が制限される
- B) 各Podにプロキシが追加されるためレイテンシとリソースオーバーヘッドが増加する
- C) アプリケーションコードの大幅な書き換えが必要
- D) オンプレミス環境では使用できない
答えを見る
正解: B
サイドカープロキシ（Envoy）は各Podに追加されるため、リクエストごとに1-3msのレイテンシ増加と、Pod数分のメモリ/CPUオーバーヘッドが発生します。サービス数が増えるほどコストが大きくなります。言語非依存で、コード変更は最小限です。
Q8. Consumer-Driven Contractsの最も重要な利点はどれですか？
- A) API仕様書を自動生成できる
- B) Provider の変更が既存 Consumer を壊さないことを自動テストで保証できる
- C) API のバージョニングが不要になる
- D) Consumer の数を制限できる
答えを見る
正解: B
Consumer-Driven Contractsでは、各Consumerが「自分が必要とするレスポンス」を契約として定義します。Providerは変更時にこの契約テストを実行することで、既存Consumerを壊さないことを自動的に検証できます。Pact等のツールで実現します。
Q9. Database per Serviceへの移行で「Schema分離」を最初のステップとする理由はどれですか？
- A) パフォーマンスが最も向上するから
- B) 同一DB内でスキーマを分けることでリスクを最小化しながら境界を明確にできるから
- C) マイグレーションツールが自動対応するから
- D) バックアップが簡単になるから
答えを見る
正解: B
Schema分離は同一データベースインスタンス内でスキーマ（名前空間）を分けるアプローチです。物理的なDB分離と異なり、既存のJOINやトランザクションが一時的に維持できるため、リスクが低く段階的に移行できます。Viewで互換性を維持しながら、API経由のアクセスに段階的に切り替えていきます。
Q10. マイクロサービスへの移行を「すべきでない」ケースとして最も当てはまるものはどれですか？
- A) チーム間のデプロイ待ちが頻発している
- B) 開発チームが5名以下の小規模スタートアップで、プロダクトマーケットフィットを探している段階
- C) 月間100万ユーザーを超え、機能別にスケーリングが必要
- D) 1つのモノリスに10チームが変更を加えている
答えを見る
正解: B
プロダクトマーケットフィット（PMF）を探している段階の小規模チームでは、ビジネスモデル自体が頻繁に変わる可能性が高く、サービス境界の設計が安定しません。マイクロサービスの運用コスト（分散システムの複雑さ、インフラ管理）は、この段階では足かせになります。まずモノリスで価値検証を行い、成長に伴い段階的に分離するのが賢明です。
結果
8問以上正解の場合
月2 合格です！ マイクロサービス移行の全体像を理解し、技術的な判断を下せるレベルに到達しました。
「素晴らしい。モノリス分析からサービス境界設計、イベント駆動、分散トランザクション、サービスメッシュまで — マイクロサービス移行をリードする力がついたな。次の月ではセキュリティの世界に踏み込む。組織全体の安全を守る方法を学ぼう」 — 佐藤CTO
7問以下の場合
もう少し復習しましょう。 間違えた問題の関連Stepを重点的に復習してください。
- Q1-Q3 → Step 1-2（モノリス分析、DDD、Strangler Fig）
- Q4-Q6 → Step 3-4（イベント駆動、Saga、分散トランザクション）
- Q7-Q8 → Step 5（サービスメッシュ、API契約）
- Q9-Q10 → Step 2（DB分離、移行判断）