Section 3 問題集: サイトリライアビリティエンジニアリング（SRE）プラクティスの適用
試験出題比率: 約 18% 試験ガイド対応: Professional Cloud DevOps Engineer 試験ガイド最新版 収録問題数: 20 問
学習方針
このセクションは PCDE 試験の中核である「SRE プラクティスの適用」を扱います。 SLI / SLO / SLA / Error Budget の数値計算、Multi-burn-rate アラート、サービスライフサイクル管理、容量計画（Quotas / Reservations / Dynamic Workload Scheduler）、各種オートスケール（MIG / Cloud Run / GKE HPA・VPA・CA）、インシデント緩和の優先順位（drain → redirect → capacity → rollback）の判断を、本番試験と同じシナリオ形式で訓練します。
学習の進め方
- まず通しで解く — 制限時間 30 分 / 20 問（1 問 90 秒）
- 採点して弱点把握 — 末尾の「正答率早見表」に記入
- 間違えた問題は学習資料
../02_学習資料/03_SREプラクティス/に戻る - 2 週間後に再挑戦 — 同じ問題で 90% 以上を目指す
正答率の目安
| 正答率 | 評価 | 次のアクション |
|---|---|---|
| 90% 以上 | 合格圏 | Section 4 / 5 に進む |
| 80-89% | 合格ライン | 間違えた領域だけ復習 |
| 70-79% | 要復習 | 02_応用.md を再読 |
| 70% 未満 | 基礎不足 | 01_基礎.md から学び直す |
難易度配分
- ★（基礎）: 3 問
- ★★（応用）: 12 問
- ★★★（発展）: 5 問
出題範囲対応表
| 試験ガイド項目 | 該当問題 |
|---|---|
| 3.1 変化・速度・信頼性のバランス（SLI/SLO/SLA、Error Budget、Cloud Service Mesh、Opportunity cost of nines） | 問題 1, 2, 3, 4, 5, 6, 7, 8, 9 |
| 3.2 サービスライフサイクル（planning/deployment/maintenance/retirement、quotas/limits/reservations、DWS、autoscaling MIG/Cloud Run/GKE） | 問題 10, 11, 12, 13, 14, 15, 16 |
| 3.3 インシデント影響の緩和（drain/redirect、容量追加、rollback） | 問題 17, 18, 19, 20 |
問題
問題 1 （難易度: ★）
シナリオ: Cymbal Bank の決済 API チームは、SLI / SLO / SLA を初めて整理しています。マーケティングは「99.9% を顧客契約に書く」、開発リーダーは「内部の判断基準として 99.95% を持ちたい」、SRE は「実測は過去 28 日 99.97% だった」と発言しています。
質問: SLI / SLO / SLA の数値関係として、適切に整列している組み合わせはどれですか。
選択肢:
- A. SLI 99.9% < SLO 99.95% < SLA 99.97%
- B. SLA 99.9% < SLO 99.95% < SLI 99.97%
- C. SLI 99.97% < SLO 99.95% < SLA 99.9%
- D. SLA 99.97% < SLO 99.95% < SLI 99.9%
解答と解説
正解: B
解説:
- B が正解: SLI（実測）が最も高く、SLO（内部目標）は SLI 実績にバッファを持たせて低めに、SLA（顧客契約）はさらに下に置くのが SRE Book の原則。実測 99.97% > 内部目標 99.95% > 契約 99.9% の順。
- A: 「SLI < SLA」になっている時点で誤り。実測が契約を下回ると返金事案。
- C: 順序が逆。
- D: SLA が最も厳しい数値になっており、契約と内部目標の関係が逆転している。
試験のひっかけポイント: 「SLI < SLO < SLA」に "見える" が、実際の 数値の大小は逆。SLA はあくまで顧客に約束する最低保証で、SLO はその上にバッファを置く。実測（SLI）は SLO を上回るように運用する。
関連リソース:
問題 2 （難易度: ★★）
シナリオ: あなたの API は SLO 99.9%（30 日 rolling）で運用されています。今月の 15 日時点で累計ダウンタイムは 22 分でした。
質問: 残りのエラーバジェットは何分ですか。また、残期間（15 日間）で同じ消費ペースを続けた場合、月末時点で SLO は達成できますか。
選択肢:
- A. 残予算 21.2 分。同じペースなら月末で予算超過し、SLO 違反
- B. 残予算 43.2 分。同じペースなら月末でちょうど SLO 達成
- C. 残予算 21.2 分。同じペースなら月末で予算内に収まり、SLO 達成
- D. 残予算 10 分。同じペースなら月末で大幅に予算超過
解答と解説
正解: A
解説:
- 月の総時間 = 30 × 24 × 60 = 43,200 分
- Error Budget = 0.1% × 43,200 = 43.2 分/月
- 15 日時点で 22 分消費 → 残予算 = 43.2 − 22 = 21.2 分
- 半月で 22 分使ったペース → 月末で 44 分消費見込み → 43.2 分を 0.8 分超過 → SLO 違反
- A が正解。
- B: 43.2 分は月初時点の予算であり、すでに 22 分消費している以上残予算ではない。
- C: 月末で 44 分消費見込みなのに「予算内」は計算誤り。
- D: 残予算 10 分は誤り。
試験のひっかけポイント: 「30 日 × 24 時間 × 60 分 = 43,200 分」を即答できること。99.9% SLO の月次予算 = 43.2 分は丸暗記。残予算と消費ペースから「月末予測」まで計算するのが頻出。
関連リソース:
問題 3 （難易度: ★★）
シナリオ: あなたは医療事業者向け SaaS の SRE です。経営層から「24/7 で動く決済 API は SLO 99.99% にしたい」「社内向け管理コンソールも揃えて 99.99% にしたい」と提案されました。社内向け管理コンソールは IT 担当者が月数時間しか使いません。
質問: 信頼性の機会費用（Opportunity cost of nines）を踏まえた、最も適切な提案はどれですか。
選択肢:
- A. 両方を 99.99% に揃え、運用を統一すべき
- B. 決済 API は 99.99%、管理コンソールは 99.9% で十分。Nine が 1 桁上がるとコストが約 10 倍になる
- C. 両方を 99.999% にしてユーザー満足度を最大化する
- D. 決済 API を 99.9%、管理コンソールを 99.99% にして社内利便性を上げる
解答と解説
正解: B
解説:
- B が正解: Nine が 1 桁上がるたびにコスト・複雑性は約 10 倍。99.99%（月 4.32 分許容）はマルチリージョン・ホットスタンバイ・厳しい変更管理が必要。社内向けで月数時間しか使わないシステムには 過剰投資。SRE Book は「ユーザーが気づかない高信頼性は無駄」と明言。
- A: 統一は楽だが、用途に合わない過剰投資となる。
- C: 99.999%（月 25.9 秒）は通常のクラウドアーキでは現実的に達成困難。
- D: 影響度の高い決済 API を低く設定するのは本末転倒。
試験のひっかけポイント: 「SLO は高ければ高いほど良い」は誤り。ユーザー要件 × ビジネス影響 × コスト の三者で決定。Nine の追加コストと機会費用（メンテナンス窓・変更速度の犠牲）を理解しているかが問われる。
関連リソース:
問題 4 （難易度: ★★）
シナリオ: 新しいリコメンデーション API の SLI を設計しています。チームから以下の候補が出ました。
- Pod の平均 CPU 使用率
- クラスタの Node 数
- HTTP 5xx エラー率
- p99 レスポンスタイム
質問: SRE Workbook の SLI 選定原則（ユーザーに影響する指標を選ぶ）に最も合致する SLI の組み合わせはどれですか。
選択肢:
- A. 1 と 2（リソース観点が重要）
- B. 1 と 4（リソースとレイテンシ）
- C. 3 と 4（エラー率とレイテンシ）
- D. 2 と 3（ノード数とエラー率）
解答と解説
正解: C
解説:
- C が正解: SLI は ユーザーが直接気にする指標 を選ぶ原則。HTTP 5xx 率（成功/失敗）と p99 レイテンシは、ユーザー体験を直接反映する。
- CPU 使用率や Node 数は 内部リソース指標 であり、ユーザー体験を直接表さない。CPU が 90% でもユーザーが問題なく応答を受けていれば SLO は満たしている。
- A, B, D: いずれもユーザー体験を直接表さない指標が含まれている。
試験のひっかけポイント: SRE Workbook Chapter 2 の SLI 選定 4 原則：(1) ユーザーが気にすることを測る、(2) 集計可能、(3) シンプル、(4) 構造化。「CPU 使用率を SLI にする」「ノード数を SLI にする」は典型的な間違い。
関連リソース:
問題 5 （難易度: ★★）
シナリオ: あなたは BigQuery を使った日次バッチ処理パイプラインの SLI を定義する必要があります。1 日 1 回起動するジョブで、「実行が 60 分以内に完了したか」を信頼性の基準にしたいと考えています。
質問: このバッチ処理に最も適した SLI 計算方式はどれですか。
選択肢:
- A. Request-based SLI（Good Events / Total Events）。リクエスト粒度で計測
- B. Window-based SLI（Good Windows / Total Windows）。1 日のウィンドウ単位で計測
- C. Burn rate ベースの SLI。各ジョブを bursty event として扱う
- D. Latency-based SLI のヒストグラム。p99 を取って評価
解答と解説
正解: B
解説:
- B が正解: バッチ・定期実行ジョブ・データパイプラインには Window-based SLI（"Good" な時間ウィンドウ数 / 全ウィンドウ数）が定石。例: 「1 日のウィンドウで 60 分以内に完了したか」を Good/Bad で判定し、過去 30 日のうち何日が Good かを SLI とする。
- A: Request-based は HTTP API などリクエスト/レスポンス系に適する。1 日 1 回のジョブには粒度が合わない。
- C: Burn rate はアラート判定指標であり、SLI そのものではない。
- D: 1 日 1 回のジョブで p99 を取っても意味がない。
試験のひっかけポイント: 「API → Request-based」「バッチ・定期処理 → Window-based」「ストリーム処理の鮮度 → Window-based（freshness）」の使い分けが頻出。SRE Workbook の SLI タイプを把握しておく。
関連リソース:
問題 6 （難易度: ★★★）
シナリオ: SLO 99.9%（30 日 rolling）の API があります。Cloud Monitoring で Multi-window multi-burn-rate アラートを設定したい。SRE Workbook の推奨に従って「Fast burn（クリティカル：Budget の 2% を 1 時間で消費するペース）」を設定する場合、Burn rate と long window / short window の組み合わせはどれですか。
質問: 推奨される Fast burn アラートの設定値はどれですか。
選択肢:
- A. Burn rate 1x、long window 30 日、short window 1 日
- B. Burn rate 6x、long window 6 時間、short window 30 分
- C. Burn rate 14.4x、long window 1 時間、short window 5 分
- D. Burn rate 60x、long window 24 時間、short window 1 時間
解答と解説
正解: C
解説:
- C が正解: SRE Workbook Chapter 5「Alerting on SLOs」の推奨は Fast burn = 14.4x / long 1h / short 5m。1 時間で予算の 2% を消費するペース（14.4 × 1h × 0.1% ≈ 2% × 43.2 分）に相当。long window で長期傾向、short window で誤検知防止の AND 条件。
- B: これは Medium burn（6x / 6h / 30m、Budget の 5% を 6h で消費）の設定。
- A: これは Slow burn（1x / 3 日 / 6h、Budget の 10% を 3 日で消費）に近い設定。
- D: 60x ではアラートが遅すぎる（既に深刻な障害）。Fast burn の基準ではない。
試験のひっかけポイント: Multi-burn-rate の 3 段階を暗記：Fast 14.4x / 1h / 5m、Medium 6x / 6h / 30m、Slow 1x / 3d / 6h。long window と short window を AND で組み合わせることで「短期スパイクで誤検知」と「長期で見落とし」を両立して防げる。
関連リソース:
問題 7 （難易度: ★★）
シナリオ: SLO 99.9% の API を運用中、過去 5 分間で 10,000 リクエスト中 600 件が 5xx でした。
質問: この期間の Burn rate はいくつですか。また、Fast burn alert（threshold 14.4x）は発火しますか。
選択肢:
- A. Burn rate 0.6x。発火しない
- B. Burn rate 6x。発火しない
- C. Burn rate 60x。発火する
- D. Burn rate 600x。発火する
解答と解説
正解: C
解説:
- エラー率 = 600 / 10,000 = 6%
- Error Budget = 1 − SLO = 1 − 0.999 = 0.1%
- Burn rate = エラー率 / (1 − SLO) = 6% / 0.1% = 60x
- 60x > 14.4x なので Fast burn alert は 発火する
- C が正解。
- A, B, D: 計算誤り。
試験のひっかけポイント: Burn rate の式 = エラー率 / (1 − SLO) を即答できること。「Burn rate 1x = SLO 期間（30 日）でちょうど予算を使い切る速度」「Burn rate 60x = 約 12 時間で予算枯渇」の感覚を持つこと。
関連リソース:
問題 8 （難易度: ★★）
シナリオ: あなたは SLO 99.9% のサービスを運用しており、Error Budget Policy をチームで合意しています。月の 10 日目で予算の 95% を消費してしまいました。次のスプリントでは「目玉となる新機能のリリース」を計画していました。
質問: Error Budget Policy に従った最も適切な判断はどれですか。
選択肢:
- A. 残予算が少なくても新機能リリースは計画通り実施し、問題があれば即時 rollback する
- B. 新機能リリースを凍結し、信頼性向上タスク（Postmortem アクション、エラー削減）に集中する
- C. SLO を 99.5% に下方修正し、予算を増やしてリリースを継続する
- D. 影響範囲が小さい部分だけリリースし、それ以外は通常運用を続ける
解答と解説
正解: B
解説:
- B が正解: Error Budget Policy の典型ステップ関数：予算枯渇（または僅少）時は 新機能リリース凍結、信頼性タスクに 100% 集中 が定石。Policy は事前合意であり、感情論を排除して客観的に判断する。
- A: Policy 違反。問題が出たら戻すのではなく、予算枯渇時点でリリースは止める。
- C: SLO の下方修正は議論なしに行うべきでない。四半期レビューで実績とユーザーニーズを評価して決める。
- D: Policy の「全面停止」を骨抜きにする運用。試験的にも誤り。
試験のひっかけポイント: Error Budget Policy は「Budget 残量に応じて段階的にリリース基準を厳格化」が原則。枯渇時は新機能凍結 → 信頼性投資 → Postmortem アクション優先。「Policy 違反」は組織の信頼を損なう。
関連リソース:
問題 9 （難易度: ★★★）
シナリオ: あなたは GKE 上で 30 以上のマイクロサービスを運用しており、それぞれの SLO を独立して設定したい。アプリ側のコードに計測ロジックを埋め込まずに、すべてのサービス間通信のリクエスト数・成功率・レイテンシを収集して Cloud Monitoring の SLO として可視化したい。
質問: 最小の改修で要件を満たすベストな組み合わせはどれですか。
選択肢:
- A. 各サービスに OpenTelemetry SDK を組み込み、メトリクスを Cloud Monitoring に送信する
- B. Cloud Service Mesh（旧 Anthos Service Mesh）を導入し、Envoy サイドカーが自動収集する
istio_requests_totalをベースに Service Monitoring で SLO を定義する - C. Cloud Trace を有効化し、トレースから SLO を抽出する
- D. Cloud Logging に全リクエストログを出力し、Log-based metrics で SLO を作る
解答と解説
正解: B
解説:
- B が正解: Cloud Service Mesh は Envoy サイドカープロキシが アプリ無改修で全リクエストをインターセプト し、
istio_requests_total、istio_request_duration_millisecondsなどのメトリクスを自動収集。Cloud Monitoring の Service Monitoring と統合済みで、マイクロサービスごとに SLO 定義・Burn rate alert 自動生成が可能。 - A: OpenTelemetry SDK の組み込みは アプリ改修が必要。「最小改修」の要件を満たさない。
- C: Cloud Trace はレイテンシ分布の可視化に強いが、SLO 計測のベースには不向き。サンプリングで誤差が出る。
- D: Log-based metrics は可能だが、全リクエストのログ出力はコスト・性能面で高負荷。Service Mesh の方が定石。
試験のひっかけポイント: 「マイクロサービスごとに SLO 定義」「アプリ未改修」というキーワードが出たら Cloud Service Mesh + istio_requests_total が定石解。Cloud Service Mesh は旧 Anthos Service Mesh の現行名称。
関連リソース:
問題 10 （難易度: ★）
シナリオ: あなたのチームは新サービスをローンチします。サービスライフサイクル管理を SRE 原則に従って整理したい。
質問: サービスライフサイクルの 4 フェーズの順序として正しいのはどれですか。
選択肢:
- A. Deployment → Planning → Maintenance → Retirement
- B. Planning → Deployment → Maintenance → Retirement
- C. Planning → Maintenance → Deployment → Retirement
- D. Deployment → Maintenance → Planning → Retirement
解答と解説
正解: B
解説:
- B が正解: SRE のサービスライフサイクルは Planning（計画）→ Deployment（展開）→ Maintenance（保守運用）→ Retirement（廃止） の 4 フェーズ。各フェーズで SLI/SLO 定義、容量計画、Toil 削減、廃止告知などの責務が定められている。
- A, C, D: 順序が誤り。Planning が必ず最初。
試験のひっかけポイント: Retirement（廃止）フェーズでは 顧客への EOL 事前告知（通常 6 ヶ月以上）、移行支援、データ移行、規制対応の削除証明 が必要。「最初にすべきこと → 顧客告知と移行支援」が頻出。
関連リソース:
問題 11 （難易度: ★★）
シナリオ: あなたは ML 研究チームの SRE です。研究者から「来月 1 か月、A3 (H100 GPU 8 基) インスタンス 16 台を 連続 14 日間 確実に確保したい。事前学習が止まると数百万円の損失」と要求されました。オンデマンドではゾーン在庫不足が頻発しています。
質問: 最も適切なリソース確保手段はどれですか。
選択肢:
- A. Spot VM を 16 台確保し、再起動スクリプトでチェックポイントから再開
- B. Dynamic Workload Scheduler（DWS）の Calendar mode で開始日と 14 日間を指定して予約
- C. Cluster Autoscaler の max を引き上げてオンデマンドで起動
- D. Any reservation を作成して全リージョンから自動消費
解答と解説
正解: B
解説:
- B が正解: Dynamic Workload Scheduler の Calendar mode は 開始日時を指定して GPU/TPU を長期確保（7 / 14 / 30 / 90 日） する仕組み。LLM 事前学習や大規模研究プロジェクト向けの定石。
- A: Spot VM は 中断あり。連続 14 日間の保証なし、研究で止まると数百万円損失するなら不適。
- C: オンデマンドはゾーン在庫依存で「確実に確保」は不可能。
- D: Any reservation は VM 確保には使えるが、GPU 在庫の柔軟な確保には DWS が最適。Calendar 指定もできない。
試験のひっかけポイント:
- DWS Flex-start mode: 開始時刻は柔軟、最大 7 日間、ファインチューニング向け
- DWS Calendar mode: 開始日時指定、最大 90 日、大規模事前学習向け
- 「GPU/TPU 確実確保」「長期予約」のキーワードが出たら DWS。
関連リソース:
問題 12 （難易度: ★★）
シナリオ:
ブラックフライデーで Compute Engine の N2 vCPU 使用量が通常の 10 倍に増加する見込み。リージョン asia-northeast1 での確実な容量確保と最適なコストを両立させたい。
質問: 最も適切なリソース確保戦略はどれですか。
選択肢:
- A. 通常通りオンデマンドで起動し、足りなければ手動追加する
- B. ピーク前に Specific reservation を作成して容量を事前確保し、1 年 CUD と組み合わせて割引も得る
- C. Spot VM のみで構成し、最大 91% 割引を享受する
- D. Cloud Run のオートスケールに切り替え、Compute Engine を廃止する
解答と解説
正解: B
解説:
- B が正解: Reservations は特定ゾーン・マシンタイプの容量を事前確保し、起動時の「キャパシティ不足」エラーを防ぐ。Specific reservation は特定 VM だけが消費するため競合せず確実。CUD（Committed Use Discount、1 年 25-37%、3 年 52-70%） と組み合わせて割引も得られる。
- A: ゾーン在庫不足のリスクがあり「確実」を満たさない。
- C: Spot VM は中断あり。ブラックフライデーの決済処理など中断不可ワークロードには不適。
- D: アーキテクチャ変更は短期間では非現実的。
試験のひっかけポイント:
- Quotas: プロジェクト上限（rate / allocation）
- Limits: サービスのハード上限（増やせない）
- Reservations: 容量事前確保（CUD と組合せ可能）
- DWS: GPU/TPU 専用の柔軟予約 キーワード「ピーク時の確実な容量」→ Reservations。「コスト最適」→ CUD 併用。
関連リソース:
問題 13 （難易度: ★★）
シナリオ: Cloud Run でホストしている画像処理 API があります。レスポンスを返した後にバックグラウンドで画像のサムネイル生成・Cloud Storage 保存・通知送信を非同期に行いたい。現在のところ、レスポンス後の処理が途中で停止してしまう問題が発生しています。
質問: 最も適切な Cloud Run の設定変更はどれですか。
選択肢:
- A. CPU always allocated（CPU 常時割り当て）に切り替える
- B. concurrency を 1 に下げ、1 リクエスト 1 インスタンスにする
- C. min-instances を 10 に増やして cold start を回避する
- D. max-instances を引き上げてスケールアウトを許可する
解答と解説
正解: A
解説:
- A が正解: Cloud Run のデフォルトは CPU はリクエスト処理中のみ割り当て。レスポンス返却後はバックグラウンド処理が止まる。CPU always allocated に設定すると、リクエスト処理外でも CPU が割り当てられ、バックグラウンド処理を完遂できる。WebSocket / gRPC ストリーミングでも必須。
- B: concurrency 1 にしても CPU 割り当てモードは変わらず、バックグラウンド処理は止まる。
- C: cold start とは無関係の問題。
- D: スケールアウト数の話ではない。
試験のひっかけポイント: Cloud Run のデフォルトは「リクエスト処理中のみ CPU 割り当て」で、レスポンス後のバックグラウンド処理は CPU always allocated が必要（コストは上がる）。WebSocket / gRPC ストリーミングも同様。
関連リソース:
../02_学習資料/03_SREプラクティス/01_基礎.md§13,02_応用.md§11
問題 14 （難易度: ★★★）
シナリオ:
GKE 上の recommendation-service で、HPA と VPA を同時に使ってリソース最適化したいと考えています。チームメンバーが「HPA で CPU 使用率 70% をターゲットに、VPA で CPU リクエストを Auto モードで自動調整しよう」と提案しています。
質問: この設計の問題点と推奨される修正はどれですか。
選択肢:
- A. 問題なし。HPA と VPA は完全に独立動作する
- B. HPA と VPA が 同じ CPU メトリクス で動くと衝突するため、HPA は カスタムメトリクス（RPS や queue length 等）、VPA は メモリのみ Auto にする
- C. HPA を使わず VPA だけで Pod の CPU/メモリを調整する
- D. Cluster Autoscaler を停止して固定ノード数で運用する
解答と解説
正解: B
解説:
- B が正解: 公式に HPA と VPA を同じメトリクス（CPU/メモリ）で同時利用するのは非推奨。HPA が Pod を増やそうとし、VPA が Pod の CPU リクエストを増やそうとして衝突する。推奨は HPA はカスタムメトリクス（RPS、queue length、リクエスト数）、VPA はメモリのみ Auto モード という分担。
- A: 衝突するため誤り。
- C: HPA の役割（負荷増時のスケールアウト）が失われる。
- D: Cluster Autoscaler を止めるとノード追加ができなくなり、本質的な解決にならない。
試験のひっかけポイント: GKE オートスケーラ 3 種：
- HPA: Pod 数（水平）
- VPA: Pod の CPU/Memory リクエスト（垂直）
- Cluster Autoscaler: Node 数
HPA + VPA を同じメトリクスで併用 = NG。「HPA はカスタムメトリクス、VPA はメモリ」の分担が定石。
関連リソース:
../02_学習資料/03_SREプラクティス/01_基礎.md§14,02_応用.md§12
問題 15 （難易度: ★★）
シナリオ: MIG で動かしている Web アプリで、毎日 12:00-13:00 のランチタイムに負荷が常時の 3 倍になる予測可能なパターンがあります。CPU ベースのオートスケールでは反応が遅く、ピーク開始時に SLO 違反が出ます。
質問: 最も適切なオートスケール戦略はどれですか。
選択肢:
- A. Cool-down period を 10 秒に短縮し、CPU 使用率の閾値を 50% に下げる
- B. Schedule-based autoscaling で 11:50-13:10 の間 min-replicas を引き上げる、または Predictive Autoscaling を有効化する
- C. max-replicas を常に最大値に張り付かせて余剰確保する
- D. MIG を廃止し、Cloud Run に切り替える
解答と解説
正解: B
解説:
- B が正解: 予測可能な負荷パターンには Schedule-based autoscaling（cron 的に min を引き上げ）または Predictive Autoscaling（過去 7 日のパターンから自動予測して事前スケール）が定石。ピーク開始前にウォームアップしておけば SLO 違反を防げる。
- A: Cool-down を縮めすぎるとフラッピング（スケール上下の振動）を招く。
- C: 余剰確保はコスト的に非効率。Reservations を活用する方が良い。
- D: アーキテクチャ変更は本質的な解決でない上、コストや要件次第。
試験のひっかけポイント:
- CPU / LB utilization: リアクティブ（既に負荷上がってから反応）
- Schedule-based: 予測可能なパターン
- Predictive Autoscaling: 過去パターンから自動予測（起動時間が長いアプリ向け）
- Custom metric: キュー長、RPS など特殊メトリクス
「予測可能な負荷」「起動に時間がかかる」→ Predictive または Schedule-based。
関連リソース:
../02_学習資料/03_SREプラクティス/01_基礎.md§12,02_応用.md§10
問題 16 （難易度: ★★）
シナリオ: Cloud Run でホストしている REST API があります。p99 レイテンシを下げるため、cold start を最小化したい。リクエストは I/O バウンド中心で 1 リクエストあたり 50ms 程度です。
質問: cold start と効率の両方を最適化するための設定として最も適切なのはどれですか。
選択肢:
- A. min-instances=0、concurrency=1、CPU always allocated
- B. min-instances=1 以上、concurrency=80（デフォルト）程度を維持、Startup CPU Boost を有効化
- C. min-instances=0、concurrency=1000、CPU always allocated
- D. min-instances=10、concurrency=1、max-instances=10
解答と解説
正解: B
解説:
- B が正解: min-instances ≥ 1 で常時 1 インスタンスを温存して cold start を回避。Startup CPU Boost（gen2）で起動時に CPU を増強。I/O バウンドで軽い処理なら concurrency 80（デフォルト） が効率的（1 インスタンスで複数同時処理）。
- A: min-instances=0 では cold start が発生。concurrency=1 は CPU バウンド向け、I/O バウンドには非効率。
- C: concurrency=1000 は極端に高すぎ、1 インスタンスが過負荷になりレイテンシ悪化。
- D: concurrency=1 + max=10 はインスタンス数上限が低く、わずかな負荷でスループット不足。
試験のひっかけポイント:
- concurrency 低（1〜10）: CPU バウンド、AI 推論、画像処理
- concurrency 高（80〜1000）: I/O バウンド、REST API、軽い処理
- min-instances ≥ 1: cold start 削減（常時課金あり）
- Startup CPU Boost: 起動時のみ CPU 強化（gen2 のみ）
関連リソース:
問題 17 （難易度: ★★）
シナリオ: 本番環境で 5 分前にデプロイした新版 v42 のリリース後、Cloud Monitoring が Fast burn alert を発火させました。Burn rate は 60x で増加中。SRE オンコール担当のあなたが対応します。
質問: SRE の原則「Mitigate first, fix later」に従った最も適切な最初のアクションはどれですか。
選択肢:
- A. ログを精査して根本原因を特定し、修正パッチを当てる
- B. 直前リリース v42 を v41 にロールバック（Cloud Deploy rollback /
kubectl rollout undo/ Cloud Run revision traffic 100%）して影響を即時緩和する - C. SLO の目標値を下方修正して Burn rate を抑える
- D. Postmortem テンプレートを開いて Five Whys を埋め始める
解答と解説
正解: B
解説:
- B が正解: SRE の鉄則は Mitigate first, fix later。新規デプロイ直後の障害は まず止血（ロールバック） が最優先。原因究明・修正は復旧後に行う。Cloud Deploy / Cloud Run / GKE それぞれにロールバック手段がある。
- A: 原因究明を先にすると影響時間が長引く。Burn rate が高い状況では SLO 違反が拡大する。
- C: SLO を下方修正して数字を誤魔化すのは SRE の精神に反する。
- D: Postmortem は復旧後に書く。緊急対応中ではない。
試験のひっかけポイント: インシデント緩和の優先順位：
- Mitigate（緩和）: Feature flag OFF → Rollback → Drain → Capacity 追加
- Recover（復旧確認）: SLO 回復確認
- Communicate（連絡）: Status Page、社内通知
- Postmortem: 復旧 24 時間以内に作成、Blameless、Five Whys
関連リソース:
../02_学習資料/03_SREプラクティス/01_基礎.md§15, §16
問題 18 （難易度: ★★★）
シナリオ: 新機能「AI コメント要約」を Feature flag で 5% のユーザーに段階的にロールアウト中、当該機能由来のエラーが急増しています。Feature flag システム（Firebase Remote Config）と CI/CD パイプラインがあります。コードのロールバックも可能ですが、他の新機能も同時にリリースされており、それらは正常に動作しています。
質問: 最も影響を早く止める手段はどれですか。
選択肢:
- A. CI/CD パイプラインで前のリリースに rollback する（5〜15 分かかる）
- B. Feature flag を OFF にする（秒単位）。コードはそのままで対象機能だけ無効化
- C. 該当機能の Pod をすべて削除する
- D. SLO を下方修正してアラートを止める
解答と解説
正解: B
解説:
- B が正解: Feature flag による即時無効化は 秒単位 で影響を止められる。コードは触らないため他の正常な新機能はそのまま動く。Firebase Remote Config / LaunchDarkly / Split などのツールで実現。
- A: パイプライン経由のロールバックは 5〜15 分かかる上、正常な他機能まで前バージョンに巻き戻ってしまう。
- C: Pod 削除は対症療法的で、再作成すれば同じ問題が再発する。
- D: SLO 下方修正は障害隠蔽に過ぎず、ユーザー影響は続く。
試験のひっかけポイント: 「最も早く影響を止める」→ Feature flag OFF（秒単位）。Rollback（5〜15 分）より早い。Feature flag は コードを触らず特定機能だけ無効化 できるのが強み。Cloud Deploy rollback / kubectl rollout undo / Cloud Run revision はパイプライン経由で時間がかかる。
関連リソース:
問題 19 （難易度: ★★）
シナリオ: Global External HTTP(S) Load Balancer の背後にある MIG（asia-northeast1）で深刻なバグが発覚し、当該 MIG を本番から切り離す必要があります。既存ユーザーのセッションが進行中（HTTP keep-alive、長時間レスポンス）です。
質問: ユーザー影響を最小化しつつ MIG を安全に切り離すための正しい手順はどれですか。
選択肢:
- A. すぐに MIG を削除する。LB は自動で他バックエンドにルーティングする
- B. バックエンドサービスで該当 MIG の capacity-scaler を 0 に設定して新規トラフィックを止め、connection draining timeout（最大 3600 秒）の完了を待ってから MIG を切り離す
- C. VPC ファイアウォールで該当 MIG への通信をブロックする
- D. Cloud Armor で IP 拒否ルールを追加する
解答と解説
正解: B
解説:
B が正解: GLB のバックエンド削除手順の定石：
capacity-scaler=0に設定 → 新規トラフィック停止- Connection draining timeout（0〜3600 秒）で既存接続の完了を待つ
- バックエンドから MIG を削除
これにより進行中のセッションは正常完了し、新規はゼロ。
A: 即削除はユーザーセッションを強制切断し、エラーを返してしまう。
C: ファイアウォールブロックは既存接続も切断する（drain でない）。
D: Cloud Armor は外部 IP 単位のアクセス制御で、バックエンド drain には使えない。
試験のひっかけポイント: Drain（ドレイン） の本質：新規トラフィックを止め、既存接続は完了させる。
- GLB: connection draining timeout（最大 3600 秒）
- GKE Pod:
kubectl drain（PDB を尊重） - MIG: capacity-scaler 0 → drain → remove
「ユーザー影響を最小化」「進行中セッション」というキーワードが drain のヒント。
関連リソース:
../02_学習資料/03_SREプラクティス/01_基礎.md§15,02_応用.md§13
問題 20 （難易度: ★★★）
シナリオ: あなたは複数リージョンの GKE クラスタ（asia-northeast1、us-central1、europe-west1）で稼働する Web サービスを運用しています。asia-northeast1 のゾーン a, b で深刻な GCP 障害が発生し、当該リージョンのサービスが応答しません。日本ユーザーのトラフィックを即座に他リージョンへ切り替えたい。
質問: 最も早く確実にリージョンフェイルオーバーを実現できる構成はどれですか。
選択肢:
- A. Cloud DNS の weighted routing で asia-northeast1 の weight を 0 に変更し、TTL 切れを待つ
- B. Multi-cluster Ingress（MCI） を使った Anycast Global LB 構成で、Config Cluster から asia-northeast1 のバックエンドを除外する（自動 health-check フェイルオーバーも働く）
- C. 各リージョンのクラスタを手動で操作して、asia-northeast1 のサービスを停止する
- D. ファイアウォールで asia-northeast1 の通信を全部ブロックする
解答と解説
正解: B
解説:
- B が正解: Multi-cluster Ingress（MCI） は複数 GKE クラスタを 1 つの Anycast Global LB で公開する仕組み。Config Cluster で
MultiClusterIngressリソースを管理し、リージョン障害時は LB の health check が自動でフェイルオーバー する。マニュアル操作不要、TTL 待ちもない。 - A: Cloud DNS weighted routing も有効だが、TTL 切れ待ち（クライアントキャッシュ）があり即時性に劣る。短い TTL を設定していてもブラウザキャッシュなどでばらつきが出る。
- C: 手動操作はミスのリスクが高く、即時性も悪い。
- D: 通信ブロックは復旧後の再開も含めて運用負荷が高い。
試験のひっかけポイント: リージョン障害対応の選択肢：
- Multi-cluster Ingress: GKE 複数クラスタを Anycast LB で公開、health check 自動フェイルオーバー
- Cloud DNS weighted / failover: シンプルだが TTL 依存
- Global External LB（GLB）: バックエンドサービス内の health check で自動切替
**「即時」「自動」「グローバル」**のキーワードなら Multi-cluster Ingress または GLB（health check 自動）。Cloud DNS は TTL の制約があるので即時性が劣る。
関連リソース:
../02_学習資料/03_SREプラクティス/02_応用.md§13, §16 ケース 4
正答率早見表
| 問題 | 範囲 | 難易度 | あなたの解答 | 正誤 |
|---|---|---|---|---|
| 1 | 3.1 SLI/SLO/SLA | ★ | ||
| 2 | 3.1 Error Budget 計算 | ★★ | ||
| 3 | 3.1 Opportunity cost of nines | ★★ | ||
| 4 | 3.1 SLI 選定原則 | ★★ | ||
| 5 | 3.1 Request/Window-based SLI | ★★ | ||
| 6 | 3.1 Multi-burn-rate alert | ★★★ | ||
| 7 | 3.1 Burn rate 計算 | ★★ | ||
| 8 | 3.1 Error Budget Policy | ★★ | ||
| 9 | 3.1 Cloud Service Mesh SLO | ★★★ | ||
| 10 | 3.2 サービスライフサイクル | ★ | ||
| 11 | 3.2 Dynamic Workload Scheduler | ★★ | ||
| 12 | 3.2 Reservations / CUD | ★★ | ||
| 13 | 3.2 Cloud Run CPU 割当 | ★★ | ||
| 14 | 3.2 GKE HPA + VPA 衝突 | ★★★ | ||
| 15 | 3.2 MIG Schedule/Predictive | ★★ | ||
| 16 | 3.2 Cloud Run concurrency | ★★ | ||
| 17 | 3.3 Mitigate first | ★★ | ||
| 18 | 3.3 Feature flag 即時無効化 | ★★★ | ||
| 19 | 3.3 GLB connection draining | ★★ | ||
| 20 | 3.3 Multi-cluster Ingress | ★★★ |
合計: ___ / 20 問 正答率: ___ %
弱点別の復習ガイド
3.1 SLI/SLO/SLA・Error Budget・Cloud Service Mesh で間違えた場合
- 復習資料:
../02_学習資料/03_SREプラクティス/01_基礎.md§2〜§10、02_応用.md§1〜§6 - 重点項目:
- SLI / SLO / SLA の数値関係（実測 > 内部目標 > 顧客契約）
- ダウンタイム表（99% / 99.9% / 99.99% / 99.999%）の丸暗記
- Error Budget = 1 − SLO、月 43,200 分から逆算する計算
- Burn rate = エラー率 / (1 − SLO)
- Multi-window multi-burn-rate（Fast 14.4x/1h/5m、Medium 6x/6h/30m、Slow 1x/3d/6h）
- Error Budget Policy のステップ関数（残量に応じた行動規範）
- Cloud Service Mesh +
istio_requests_totalでアプリ無改修 SLO - Opportunity cost of nines（Nine 1 桁追加でコスト 10x）
3.2 サービスライフサイクル・容量計画・オートスケールで間違えた場合
- 復習資料:
../02_学習資料/03_SREプラクティス/01_基礎.md§11〜§14、02_応用.md§7〜§12 - 重点項目:
- サービスライフサイクル: Planning → Deployment → Maintenance → Retirement
- Quotas（プロジェクト上限）/ Limits（ハード上限）/ Reservations（容量予約）/ DWS（GPU/TPU）の使い分け
- DWS Flex-start mode（最大 7 日、ファインチューニング）vs Calendar mode（最大 90 日、大規模事前学習）
- MIG の 4 種のオートスケーリングポリシー（CPU / LB / Custom / Schedule）と Predictive Autoscaling
- Cloud Run の concurrency / min-instances / CPU always allocated の判断軸
- GKE HPA + VPA 同時利用の注意（同じメトリクスで衝突する）
- Cluster Autoscaler / Node Auto-Provisioning / Pod Disruption Budget / Pause Pod パターン
3.3 インシデント緩和で間違えた場合
- 復習資料:
../02_学習資料/03_SREプラクティス/01_基礎.md§15, §16、02_応用.md§13〜§16 - 重点項目:
- Mitigate first, fix later の鉄則
- 緩和の優先順位: drain → redirect → capacity → rollback
- 「最も早い影響停止」→ Feature flag OFF（秒単位）> rollback（5〜15 分）
- GLB の安全なバックエンド削除: capacity-scaler 0 → connection draining → remove
- リージョンフェイルオーバー: Multi-cluster Ingress（自動）/ Cloud DNS weighted・failover（TTL 依存）
- Cloud Deploy rollback /
kubectl rollout undo/ Cloud Run revision traffic 切替の各手段 - Incident Command System（IC / Comms / Ops / Planning）の役割分担
次のステップ
- Section 4 問題集へ進む（次セクション: 可観測性とトラブルシュート）
- 学習資料に戻る:
../02_学習資料/03_SREプラクティス/ - 要点暗記カードで仕上げ:
../02_学習資料/03_SREプラクティス/03_要点と暗記.md