ストーリー
高橋アーキテクトがクイズを用意してくれた。
クイズの説明
Step 4 で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. 分散トレーシングにおけるSpanの説明として最も適切なものはどれですか？
- A) サービス全体のヘルスチェック結果
- B) Trace内の1つの処理区間を表す単位
- C) メトリクスの1つの計測値
- D) ログの1つのエントリ
解答と解説
正解: B
Spanは分散トレーシングにおける基本単位で、Trace内の1つの処理区間を表します。各SpanはoperationName、startTime、duration、attributesなどの情報を持ち、親子関係でトレースツリーを構成します。
Q2. Context Propagationの目的として正しいものはどれですか？
- A) サービス間でデータベース接続を共有する
- B) TraceIDやSpanIDをサービス間の呼び出しで伝搬する
- C) ログファイルを各サービスで同期する
- D) メトリクスをリアルタイムで共有する
解答と解説
正解: B
Context PropagationはTraceIDやSpanIDをHTTPヘッダー（W3C Trace Context: traceparentヘッダー）等を通じてサービス間で伝搬する仕組みです。これにより、複数サービスを横断する1つのリクエストのトレースを、同じTraceIDで紐づけることができます。
Q3. Tail-basedサンプリングの最大の利点はどれですか？
- A) 実装が最も簡単である
- B) メモリ使用量が最も少ない
- C) エラーや遅延リクエストを確実に記録できる
- D) サンプリング率が最も高い
解答と解説
正解: C
Tail-basedサンプリングはリクエストの処理完了後にサンプリング判定を行うため、エラーが発生したトレースや遅延が大きいトレースを確実に記録できます。確率的サンプリングではこれらの重要なトレースを見逃す可能性がありますが、Tail-basedでは結果に基づいて判定できます。
Q4. トレースのウォーターフォールビューで、同種のDBクエリが20回繰り返されている場合、最も疑うべき問題はどれですか？
- A) データベースの容量不足
- B) N+1問題
- C) コネクションプールの枯渇
- D) インデックスの欠如
解答と解説
正解: B
同種のDBクエリが繰り返し実行されている場合、N+1問題を疑うべきです。ループ内で個別にクエリを発行する代わりに、JOINやIN句を使ったバッチ取得に変更することで、クエリ数を大幅に削減できます。
Q5. Jaegerのアーキテクチャにおいて、トレースデータを保存する役割を持つコンポーネントはどれですか？
- A) Agent
- B) Collector
- C) Storage（Elasticsearch/Cassandra）
- D) Query
解答と解説
正解: C
Jaegerのアーキテクチャでは、Agentがアプリからトレースを受信し、CollectorがAgentからデータを収集・処理し、StorageバックエンドEl（Elasticsearch、Cassandra等）に保存します。Queryはストレージからデータを取得してUIに表示する役割です。
Q6. サービスマップから検出すべき「単一障害点（Single Point of Failure）」の例として最も適切なものはどれですか？
- A) 3つのサービスが同じデータベースを使用している
- B) 全サービスのリクエストが通過する認証サービスにレプリカがない
- C) 通知サービスのレスポンスタイムが長い
- D) ログの保持期間が短い
解答と解説
正解: B
全サービスのリクエストが通過する認証サービスにレプリカ（冗長構成）がない場合、認証サービスがダウンするとシステム全体が停止します。これが「単一障害点」の典型例です。対策として、レプリカの追加、キャッシュの導入、認証トークンのローカル検証などがあります。
Q7. W3C Trace Contextの標準ヘッダー名はどれですか？
- A) X-Trace-ID
- B) X-Request-ID
- C) traceparent
- D) X-B3-TraceId
解答と解説
正解: C
W3C Trace Contextの標準では、traceparentヘッダーを使用してトレースコンテキストを伝搬します。形式は{version}-{traceId}-{parentSpanId}-{flags}です。X-B3-TraceIdはZipkinの旧形式（B3形式）のヘッダーです。
Q8. パフォーマンスボトルネックの対策として、非同期化（メッセージキューイング）が適切なケースはどれですか？
- A) ユーザー認証の処理
- B) 注文作成後のメール通知送信
- C) 決済処理のバリデーション
- D) 在庫数の確認
解答と解説
正解: B
メール通知は注文作成のレスポンスに含める必要がなく、多少の遅延が許容されるため、非同期化の良い候補です。メッセージキューに投入して、バックグラウンドで処理することで、注文APIのレスポンスタイムを短縮できます。認証、決済バリデーション、在庫確認はレスポンスに結果が必要なため、同期処理が適切です。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 4「分散トレーシング」を完了しました。 次は Step 5「信頼性設計とSRE」に進みましょう。
6問以下の場合
もう少し復習しましょう。
間違えた問題の内容を、該当するセクションで復習してください：
| 問題 | 復習セクション |
|---|---|
| Q1 | step4_1 分散トレーシングの基本 |
| Q2 | step4_1 分散トレーシングの基本 |
| Q3 | step4_1 分散トレーシングの基本 |
| Q4 | step4_4 パフォーマンスボトルネックの特定 |
| Q5 | step4_2 Jaeger/Zipkinの活用 |
| Q6 | step4_3 サービス依存関係の可視化 |
| Q7 | step4_1 分散トレーシングの基本 |
| Q8 | step4_4 パフォーマンスボトルネックの特定 |
Step 4 完了
お疲れさまでした。
学んだこと
- Trace、Span、Context Propagationの基本概念
- Jaeger/Zipkinによるトレースの可視化と分析
- サービスマップによる依存関係の可視化とリスク分析
- トレースを使ったパフォーマンスボトルネックの特定と対策
次のステップ
Step 5: 信頼性設計とSRE（4時間）
3本柱を学んだ今、次はそれらを活用して「信頼性」を設計する方法を学びます。
推定所要時間: 30分