クイズの説明
Step 2で学んだ内容の理解度をチェックします。
- 全8問
- 合格ライン: 80%（7問正解）
- 不合格の場合は復習してから再挑戦してください
問題
Q1. Cache-Aside パターンの動作として正しいものはどれですか？
- A) データ書き込み時にキャッシュとDBを同時に更新する
- B) キャッシュミス時にアプリケーションがDBから取得してキャッシュに保存する
- C) キャッシュに先に書き込み、非同期でDBに反映する
- D) DBが自動的にキャッシュを管理する
答えを見る
正解: B
Cache-Aside（Lazy Loading）パターンでは、アプリケーションがキャッシュを直接管理します。読み取り時にキャッシュを確認し、ミスの場合はDBから取得してキャッシュに保存します。
- A はWrite-Through
- C はWrite-Behind
- D は該当するパターンなし
Q2. Write-Behind パターンの最大のリスクは何ですか？
- A) 読み取りが遅い
- B) 実装が簡単すぎる
- C) キャッシュとDBの間でデータ損失が発生する可能性がある
- D) メモリを大量に消費する
答えを見る
正解: C
Write-Behindはキャッシュに先に書き込み、DBへの反映は非同期で行います。キャッシュサーバーが障害で停止した場合、まだDBに反映されていないデータが失われるリスクがあります。
Q3. 多層キャッシュで最もユーザーに近い（最速の）層はどれですか？
- A) データベースキャッシュ
- B) CDNキャッシュ
- C) ブラウザキャッシュ
- D) アプリケーションキャッシュ（Redis）
答えを見る
正解: C
ブラウザキャッシュはユーザーのデバイス上にデータを保存するため、ネットワークリクエストが一切発生しません。レイテンシは実質0msです。
層の順序: ブラウザ → CDN → アプリケーション → データベース
Q4. Cache-Control: public, max-age=31536000, immutable が適切なリソースはどれですか？
- A) ユーザーのプロフィールページ
- B) ハッシュ付きファイル名の静的アセット（例: style.abc123.css）
- C) リアルタイム在庫情報のAPIレスポンス
- D) ログイン後のダッシュボード
答えを見る
正解: B
public, max-age=31536000, immutable は1年間の長期キャッシュを意味します。ファイル名にハッシュが含まれている静的アセットは、内容が変わればファイル名も変わるため、安全に長期キャッシュできます。
ユーザー固有のデータやリアルタイムデータには不適切です。
Q5. Thundering Herd の原因として正しいものはどれですか？
- A) キャッシュのTTLが短すぎること
- B) キャッシュの期限が切れた瞬間に大量のリクエストが同時にDBに問い合わせること
- C) CDNのエッジサーバーが多すぎること
- D) ブラウザのキャッシュ容量が不足すること
答えを見る
正解: B
Thundering Herdは、人気のあるキャッシュエントリのTTLが切れた瞬間に、同時に大量のリクエストがキャッシュミスとなり、バックエンドのDBに殺到する現象です。対策として、ロック、Singleflight、確率的早期更新、事前ウォームアップがあります。
Q6. Stale-While-Revalidate パターンの動作として正しいものはどれですか？
- A) 常に最新のデータのみを返す
- B) 期限切れデータを返しつつ、バックグラウンドで最新データを取得する
- C) 期限切れデータは即座に削除する
- D) 複数のキャッシュノードを同期的に更新する
答えを見る
正解: B
Stale-While-Revalidateは、キャッシュの期限が切れた後も一定期間（stale期間）は古いデータを返し、その裏で非同期に最新データを取得・更新するパターンです。ユーザーは待たされることなく、次回以降のアクセスで最新データが提供されます。
Q7. キャッシュ無効化で「DB更新後にキャッシュを削除」すべき理由はどれですか？
- A) キャッシュの削除が高速だから
- B) DBの更新が失敗しても問題ないから
- C) キャッシュを先に削除すると、DB更新前に別リクエストが古いデータを再キャッシュする可能性があるから
- D) DBの更新後でないとキャッシュキーが分からないから
答えを見る
正解: C
キャッシュを先に削除すると、DB更新が完了するまでの間に別のリクエストがDBから古いデータを読み取り、再びキャッシュに保存してしまう可能性があります（レースコンディション）。DB更新後にキャッシュを削除することで、このリスクを軽減できます。
Q8. ホットキー問題の対策として最も適切なものはどれですか？
- A) ホットキーのTTLを0にする
- B) ホットキーをキャッシュしない
- C) ホットキーを複数のレプリカに分散し、ランダムに読み取る
- D) ホットキーのデータを圧縮する
答えを見る
正解: C
ホットキー問題は、特定のキーにアクセスが集中してキャッシュサーバーの1ノードに負荷が偏ることが原因です。キーを複数のレプリカに複製し、読み取り時にランダムにレプリカを選択することで負荷を分散できます。
結果
7問以上正解の場合
合格です。おめでとうございます。
Step 2「キャッシュ設計の極意」を完了しました。 次は Step 3「負荷テストとベンチマーク」に進みましょう。
6問以下の場合
もう少し復習しましょう。
| 問題 | 復習セクション |
|---|---|
| Q1, Q2 | step2_1 キャッシュの基本戦略 |
| Q3, Q4 | step2_2 多層キャッシュアーキテクチャ |
| Q6, Q7 | step2_3 キャッシュの無効化 |
| Q5, Q8 | step2_4 分散キャッシュの課題 |
推定所要時間: 30分