クイズの説明
L2 Month 6 の全範囲から出題される卒業クイズです。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は関連ステップを復習してから再挑戦してください
問題
Q1. リトルの法則「L = λ x W」で、同時接続数200、平均レイテンシ0.5秒の場合のスループットは？
- A) 100 RPS
- B) 200 RPS
- C) 400 RPS
- D) 1000 RPS
答えを見る
正解: C
リトルの法則: L = λ x W
- L（同時処理数）= 200
- W（平均レイテンシ）= 0.5秒
- λ（スループット）= L / W = 200 / 0.5 = 400 RPS
Q2. Cache-Aside、Write-Through、Write-Behind のうち、書き込みが最も高速なのはどれですか？
- A) Cache-Aside
- B) Write-Through
- C) Write-Behind
- D) 全て同じ速度
答えを見る
正解: C
Write-Behind（Write-Back）はキャッシュに先に書き込み、DBへの反映は非同期で行うため、書き込みが最も高速です。ただしキャッシュ障害時のデータ損失リスクがあります。
- Cache-Aside: 書き込みはDBのみ（標準速度）
- Write-Through: キャッシュとDBに同時書き込み（やや遅い）
- Write-Behind: キャッシュのみ書き込み、DB非同期（最速）
Q3. 以下のk6の設定で、テスト中のピーク時の仮想ユーザー数はいくつですか？
export const options = {
stages: [
{ duration: '2m', target: 50 },
{ duration: '5m', target: 50 },
{ duration: '2m', target: 200 },
{ duration: '5m', target: 200 },
{ duration: '2m', target: 0 },
],
};- A) 50
- B) 100
- C) 200
- D) 500
答えを見る
正解: C
stagesの設定では、3番目のステージで200VUまで増加し、4番目のステージで200VUを5分間維持します。したがって、ピーク時のVU数は200です。
Q4. データベースの書き込み負荷を分散するために必要な技術はどれですか？
- A) Read Replica
- B) シャーディング
- C) CDN
- D) コネクションプーリング
答えを見る
正解: B
Read Replicaは読み取りのみを分散し、書き込みは全てPrimaryに集中します。書き込み負荷を分散するにはシャーディングが必要です。データをシャードキーに基づいて複数のデータベースに分割し、それぞれのシャードが独立して書き込みを処理します。
Q5. Thundering Herd問題の対策として最も効果的な組み合わせはどれですか？
- A) TTLを長くする + エラーログを増やす
- B) Singleflight（ロック）+ 事前ウォームアップ + TTLジッター
- C) サーバーを増やす + DBを増やす
- D) CDNを導入する + 圧縮を有効にする
答えを見る
正解: B
Thundering Herd問題に対しては、以下の3つを組み合わせることが最も効果的です：
- Singleflight（ロック）: 同時リクエストを1つにまとめ、DB問い合わせを1回に制限
- 事前ウォームアップ: TTL切れ前にキャッシュを更新
- TTLジッター: 全キーが同時に期限切れにならないようランダムなオフセットを追加
Q6. Core Web VitalsのLCPが6秒の場合、最も効果的な改善策はどれですか？
- A) JavaScriptのminification
- B) Hero画像の最適化（WebP変換 + preload + 適切なサイズ）
- C) CSSアニメーションの削除
- D) フッターのHTML削除
答えを見る
正解: B
LCP（Largest Contentful Paint）は最大のコンテンツ要素の表示時間を測定します。LCPが6秒と非常に遅い場合、最大の要因はHero画像などの大きな画像です。WebPへの変換で25-35%サイズ削減、preloadで先読み、適切なサイズで不要な転送量を削減することで、LCPを劇的に改善できます。
Q7. 非同期処理で冪等性（Idempotency）が重要な理由はどれですか？
- A) メッセージの順序を保証するため
- B) 同じメッセージが複数回処理されても結果が変わらないようにするため
- C) メッセージの暗号化を行うため
- D) メッセージのサイズを小さくするため
答えを見る
正解: B
メッセージキューでは、ネットワーク障害、ワーカーのクラッシュ、リトライなどにより同じメッセージが複数回配信される可能性があります（At-Least-Once配信）。冪等性を確保することで、同じメッセージを何回処理しても結果が変わらず、データの整合性が保たれます。
Q8. パフォーマンスバジェットをCI/CDに組み込む目的として最も適切なものはどれですか？
- A) 開発速度を上げるため
- B) コードレビューを省略するため
- C) 機能追加によるパフォーマンス劣化を自動検知し、デプロイ前に防ぐため
- D) テストカバレッジを上げるため
答えを見る
正解: C
パフォーマンスバジェットをCI/CDに組み込むことで、新機能の追加やコード変更がパフォーマンスに与える影響を自動的にチェックできます。バジェットを超えた場合はデプロイをブロックし、パフォーマンスの劣化を本番環境に持ち込むことを防ぎます。
結果
7問以上正解の場合
合格です。おめでとうございます。
================================
L2 Month 6 修了証明書
パフォーマンスエンジニア
認定スキル:
- パフォーマンスエンジニアリング
- キャッシュ設計
- 負荷テスト（k6）
- スケーラビリティ設計
- フロントエンド最適化
修了日: ____年__月__日
================================あなたは「速さの限界を突破する」力を身につけました。
習得したスキル
| スキル | レベル |
|---|---|
| パフォーマンス分析 | レイテンシ/スループット分析、ボトルネック特定ができる |
| キャッシュ設計 | 多層キャッシュと分散キャッシュの設計ができる |
| 負荷テスト | k6でテストを設計・実施・分析できる |
| スケーラビリティ | 水平スケーリング前提のアーキテクチャ設計ができる |
| フロントエンド最適化 | Core Web Vitalsを改善できる |
6問以下の場合
もう少し復習が必要です。
| 問題 | 復習ステップ |
|---|---|
| Q1 | Step 1: レイテンシとスループット |
| Q2 | Step 2: キャッシュの基本戦略 |
| Q5 | Step 2: 分散キャッシュの課題 |
| Q3 | Step 3: k6による負荷テスト |
| Q4 | Step 4: データベーススケーリング |
| Q7 | Step 4: 非同期処理とキューイング |
| Q6 | Step 5: Core Web Vitals |
| Q8 | Step 1: パフォーマンスバジェット |
L2 Month 6 完了
お疲れさまでした。
学んだこと
| Step | テーマ | 主なスキル |
|---|---|---|
| Step 1 | パフォーマンスエンジニアリング入門 | レイテンシ、スループット、ボトルネック分析 |
| Step 2 | キャッシュ設計の極意 | Cache-Aside、多層キャッシュ、分散キャッシュ |
| Step 3 | 負荷テストとベンチマーク | k6、シナリオ設計、結果分析 |
| Step 4 | スケーラビリティの設計 | 水平スケーリング、ステートレス、非同期処理 |
| Step 5 | フロントエンドパフォーマンス | Core Web Vitals、バンドル最適化、CDN |
| Step 6 | 最終試験 | 総合演習 + 卒業クイズ |
次のミッション
L2 Month 7 では、さらに高度なシステム設計スキルに挑戦します。
速さの限界を突破したあなたは、次のステージへ進む準備ができています。
推定所要時間: 30分