Section 5 問題集: Optimizing performance and cost

試験出題比率: 約 12% 試験ガイド対応: 2024-2025 改訂版（Spot VM / Flexible CUD / Recommender / Cloud Profiler / Carbon Footprint 反映） 収録問題数: 15 問

学習方針

このセクションは PCDE 試験における 「観測 → 推奨 → 最適化 → 運用」のループ を扱います。 APM（Cloud Trace / Profiler / Monitoring）の使い分け、Active Assist の 5 カテゴリ、Spot/CUD/SUD/Network Tier の選定、GKE/Cloud Run/Compute Engine の最適化、観測可能性のコスト管理を 数値・公式仕様レベル で押さえてください。

学習の進め方

まず通しで解く — 制限時間 25 分 / 15 問（1 問 100 秒）
採点して弱点把握 — 末尾の「正答率早見表」に記入
間違えた問題は学習資料 ../02_学習資料/05_パフォーマンスとコスト/ に戻る
数値（CUD %、Spot %、SUD %）は別途暗記カード化 — 03_要点と暗記.md の「主要数値の暗記」を反復

正答率の目安

正答率	評価	次のアクション
90% 以上	合格圏	模擬試験に進む
80-89%	合格ライン	間違えた小項目だけ復習
70-79%	要復習	`02_応用.md` を再読
70% 未満	基礎不足	`01_基礎.md` から学び直す

難易度配分

★（基礎）: 2 問
★★（応用）: 9 問
★★★（発展）: 4 問

出題範囲対応表

試験ガイド項目	テーマ	該当問題
5.1 Cloud Profiler / Trace / APM	パフォーマンス情報収集	問題 1, 2, 3
5.1 Active Assist / Recommender / Insights	推奨エンジン活用	問題 4, 5
5.2 観測可能性コスト最適化	Logging / Monitoring / Trace コスト	問題 6, 7
5.2 Spot VM	バッチ / Stateless 最適化	問題 8
5.2 CUD / SUD / Network Tier	インフラコスト計画	問題 9, 10, 11
5.2 GKE / Cloud Run / Compute Engine	ワークロード別最適化	問題 12, 13, 14
5.2 BigQuery Billing Export / Budget / Carbon	FinOps 運用	問題 15

問題

問題 1 （難易度: ★★）

シナリオ: ゲーム配信スタートアップ ArenaCast は Go 製のマッチメイキングサービスを GKE で運用しています。SRE から「p95 レイテンシが 250ms から 800ms に悪化したが、CPU 使用率は 30% のまま変化していない」と報告がありました。Cloud Monitoring で確認しても CPU・メモリは正常、Cloud Trace では「アプリ内部の処理時間」が伸びていることだけ判明しました。コード行レベルでボトルネックを特定したいです。

質問: Cloud Profiler で最初に確認すべきプロファイル種別はどれですか。

選択肢:

A. CPU time プロファイル
B. Heap プロファイル
C. Wall-clock time プロファイル
D. Thread / Goroutine プロファイル

解答と解説

正解: C

解説:

C が正解: Wall-clock time は I/O 待ち・ロック待ち・外部 API 待ちを含む 経過時間 を測るため、「CPU は低いがレイテンシが長い」症状の第一選択。DB 呼び出しや外部 HTTP 待ち、sync.Mutex の待機などが見える。Go は Wall-clock を goroutine プロファイル経由で完全サポート。
A: CPU プロファイルは CPU 消費時間を見る。本シナリオでは CPU 使用率が低いため、関数別に分けても本質的に薄い。
B: Heap はメモリ割当のスナップショット。OOM やメモリ膨張のときに使う。今回は CPU/メモリが正常なため不適。
D: Goroutine 数のリーク調査用。レイテンシ悪化の直接原因特定には Wall-clock を優先する。

試験のひっかけポイント: 「レイテンシ長い + CPU 低い」= Wall-clock、「CPU 高い」= CPU、「メモリ膨張」= Heap のマッピングを即答できること。Contention（ロック待ち）も同症状で出るが、Go では Wall-clock に統合されるケースが多い。

関連リソース:

問題 2 （難易度: ★★）

シナリオ: データ分析プラットフォーム DataSphere は Python 製の ETL ワーカー を Cloud Run で運用しています。直近 1 週間で「コンテナがランダムに OOMKilled される」事象が頻発し、メモリ使用量が単調増加していることが Cloud Monitoring の container/memory/used で確認されました。原因の関数・呼び出し元を Cloud Profiler で特定したいです。

質問: Cloud Profiler を使った場合、最も適切なアプローチはどれですか。

選択肢:

A. Heap プロファイルを 1 時間後と 6 時間後で取得し、差分で増加箇所を特定する
B. Heap allocation プロファイルでアロケーション元の関数を特定する
C. Wall-clock プロファイルで GC pause を特定する
D. Cloud Profiler の Python は Heap / Heap allocation プロファイルを提供していないため、tracemalloc 等の言語標準ツールや Monitoring + heap dump で代替する

解答と解説

正解: D

解説:

D が正解: Cloud Profiler の Python は CPU と Wall-clock のみ対応 で、Heap・Heap allocation は提供されません。メモリリーク調査には tracemalloc、memray、objgraph などの Python 標準/サードパーティを使うのが現実解。Monitoring でメモリ増加トレンドを把握しつつ、コンテナ内で heap dump を取得して分析します。
A: Heap プロファイルが取れる言語（Go / Java / Node.js）であれば有効ですが、Python では取得不可。
B: Heap allocation は Go のみ（Java も不可）。Python では取得不可。
C: Wall-clock は I/O 待ちの確認に使うのが本来の用途。GC pause 調査には Heap allocation（Go）や JVM 専用ツール（Java）が必要。

試験のひっかけポイント:

Python = CPU / Wall のみ（Heap 系プロファイル不可）
Java = Heap allocation は不可（Heap は可）
Node.js = Wall-clock は不可
「Python アプリのメモリリーク調査に Cloud Profiler の Heap を使う」という選択肢は誤りの典型。

関連リソース:

問題 3 （難易度: ★★★）

シナリオ: EC サイト RetailFlux はマイクロサービスを 12 個運用しています。あるユーザートランザクション（カート → 決済）の p99 レイテンシが 4 秒を超えるようになり、顧客 CS に苦情が入っています。複数サービスを横断する 1 リクエストの内訳を可視化し、「どのサービスのどの DB クエリが遅いか」を特定し、さらに該当関数のソースコード行レベルで CPU 消費を確認したいです。

質問: 最も効率的な GCP サービス組み合わせはどれですか。

選択肢:

A. Cloud Monitoring の Dashboard で各サービスの p99 を並べる
B. Cloud Trace で遅延 Span を持つトレースを特定し、相互リンクされた Cloud Profiler で該当時刻のプロファイルを参照、加えて Cloud Logging のトレースリンク付きログでエラー文脈を確認
C. Cloud Logging で全サービスのログを severity >= ERROR で抽出し相関分析
D. Network Intelligence Center の Performance Dashboard でパケットロスを確認

解答と解説

正解: B

解説:

B が正解: APM の 3 サービス（Trace / Profiler / Logging）は trace_id / span_id で相互リンク されており、Cloud Trace の遅い Span から該当時刻の Profiler プロファイル、対応するログへワンクリックで横断できます。これが GCP の APM 統合の最大の強みで、「どのサービスが遅い → コード行で何が遅い → ログで何が起きたか」を一気通貫で追えます。
A: 各サービスの p99 並列表示はボトルネック「位置」の特定には弱い。Trace の Span 単位の方が早い。
C: ログ抽出は事後分析寄りで、遅延の構造分解には不向き。
D: Performance Dashboard は GCP 内ネットワーク / インターネット側のレイテンシ・パケットロス計測。アプリ内処理時間には触れない。

試験のひっかけポイント: 「分散トレース + プロファイル + ログの 三位一体」が GCP APM の核。試験では「Trace のみ」「Profiler のみ」のような単独答えは要件を満たさないケースが多い。request_id 串刺し可能であることを覚える。

関連リソース:

問題 4 （難易度: ★）

シナリオ: グローバル SaaS の InsightCorp は Org 配下に 300 プロジェクトを持ちます。FinOps チームは「全プロジェクト横断で、節約見込み額が大きい順にコスト最適化推奨を確認し、毎週 Slack に Top 10 を投稿したい」という運用要件を持っています。手動で各プロジェクトの Console を巡回するのは非現実的です。

質問: 最も適切な実装アプローチはどれですか。

選択肢:

A. 各プロジェクトの請求書を BigQuery にエクスポートし、SQL で推奨を再計算する
B. Recommender API の BigQuery Export を有効化し、SQL で COST カテゴリ・節約額順に集計、Cloud Scheduler + Cloud Functions + Pub/Sub で Slack に通知する
C. Cloud Asset Inventory で全リソースをスキャンし、CPU < 5% の VM を抽出する
D. Cloud Billing Budget アラートで通知する

解答と解説

正解: B

解説:

B が正解: Recommender API の BigQuery Export を有効化すると、全プロジェクト・全カテゴリの推奨が recommendations_v1 テーブルに集約され、primary_impact.cost_projection.cost.units（節約は負の値）で順位付け可能。Cloud Scheduler（cron）→ Cloud Functions → Pub/Sub → Slack が Google 公式パターン。Recommendation Hub を Org スコープで開くと UI でも横断確認できる。
A: 請求書から推奨を再計算するのは Recommender の存在意義を無視している。
C: 手動条件でのスキャンは Recommender が既に提供する分析を再発明することになる。
D: Budget アラートは予算超過通知であり、推奨配信ではない。

試験のひっかけポイント:

Recommender は API / BigQuery Export / Recommendation Hub の 3 経路でアクセス可能
「組織横断 + 自動化」が条件のときは BigQuery Export + Pub/Sub パターン
「Console で全プロジェクト集約表示」だけなら Recommendation Hub も正解になりうる

関連リソース:

../02_学習資料/05_パフォーマンスとコスト/01_基礎.md §3.2, §3.3
../02_学習資料/05_パフォーマンスとコスト/02_応用.md §2.1, §2.5

問題 5 （難易度: ★★）

シナリオ: セキュリティ監査で「サービスアカウントに過剰な IAM 権限が付与されている」と指摘を受け、Cymbal Bank はラテラルムーブメント（権限を踏み台にした横断的攻撃）リスクの可視化と是正を求められました。「何が事実か（現状）」と「何をすべきか（処方箋）」を分けて報告する必要があります。

質問: Active Assist の機能の使い分けとして最も適切なものはどれですか。

選択肢:

A. Recommender API のみで「Idle VM の削除」を提案する
B. Insights API で Lateral movement insight（事実）を取得し、Recommender API の IAM role rightsizing（処方箋）を組み合わせる
C. Cloud Security Command Center の脆弱性スキャンで CVE を抽出する
D. VPC Service Controls のログを Pub/Sub で受信する

解答と解説

正解: B

解説:

B が正解: Active Assist は Insights（事実）と Recommendations（処方箋）の二段構成。Lateral movement insight は SA 間の過剰権限による横断的攻撃可能性を 検出（事実）、IAM Recommender（Policy Recommender）が 過剰権限を実使用ベースで削減提案（処方箋） します。Insight が「血液検査の結果」、Recommendation が「処方箋」の関係。
A: Idle VM Recommender は Cost カテゴリで、本シナリオの Security 要件とずれている。
C: SCC の脆弱性スキャンは CVE 検出であり、IAM 過剰権限の最適化ではない。
D: VPC SC は境界制御で IAM 権限の最適化機能ではない。

試験のひっかけポイント:

Recommender 5 カテゴリ（Cost / Security / Performance / Manageability / Reliability）の即答
Insights と Recommendations の 役割分担：Insights = 診断、Recommendations = 処方箋
Lateral movement insight、Firewall insight、Policy insight、Reliability insight の 4 大 Insight

関連リソース:

問題 6 （難易度: ★★）

シナリオ: EC プラットフォーム ShopWave の月次請求書を確認したところ、Cloud Logging Ingestion 課金が先月の 3 倍（USD 18,000） に増えていました。原因を調査すると、GKE クラスタの Liveness/Readiness Probe（User-Agent: kube-probe/1.27） のヘルスチェックログが大量に取り込まれていることが判明。本番運用上、これらのログを残す必要はありません。ingestion 課金を直接削減 したいです。

質問: 最も効果が大きい対策はどれですか。

選択肢:

A. Logging Sink を別プロジェクトの BigQuery に追加で作成する
B. Log Router で Exclusion filter を _Default シンクに設定し、httpRequest.userAgent="kube-probe/1.27" のログを取り込み前に除外する
C. Logging Bucket の Retention を 30 日から 7 日に短縮する
D. Cloud Logging API のクォータを引き下げる

解答と解説

正解: B

解説:

B が正解: Exclusion filter は Log Router で取り込みそのものを止めるため、Ingestion 課金を直接削減できる唯一の手段。_Default シンクに対し httpRequest.userAgent="kube-probe/1.27" のような条件で除外するのが定石。GCP の観測可能性コスト削減で 最強の手法。
A: Sink を追加するのは「別の場所に出力を増やす」だけで Ingestion は減らない。逆に保管課金が増える可能性がある。
C: Retention 短縮は Storage（保管）課金には効くが、Ingestion（取り込み）課金には効かない。本シナリオは Ingestion が増えているので不適。
D: クォータを下げると正常なログまでドロップしアラート漏れが起きる。コスト最適化の正攻法ではない。

試験のひっかけポイント:

Ingestion ≠ Storage：取り込み課金は Exclusion でしか減らせない
Sink を追加 = 重複出力で Storage 課金が増える可能性
Cloud Logging 無料枠は 50 GiB/月、デフォルト Retention は 30 日

関連リソース:

問題 7 （難易度: ★★★）

シナリオ: B2C アプリ MetricLab の SRE が「Cloud Monitoring のカスタムメトリクス課金が 3 か月で 4 倍 に膨れている」と報告しました。調査の結果、最近追加したアプリ内メトリクスのラベルに user_id と session_id を含めており、月間アクティブユーザー 500 万人 × セッション 1,200 万件分の 時系列が爆発的に増加していました。長期的に再発防止したいです。

質問: 最も適切な対策の組み合わせはどれですか。2 つ選びなさい。

選択肢:

A. user_id / session_id などの高基数ラベルを廃止し、代わりにユーザーセグメント等の低基数属性に置き換える
B. Monitoring の使用済みカスタムメトリクスを棚卸しし、参照されていないメトリクスを削除する
C. Cloud Monitoring 全体を無効化し、Prometheus を自前運用に切り替える
D. Cloud Logging Sink で Monitoring メトリクスを BigQuery にエクスポートする
E. ラベルの値を Cloud KMS で暗号化する

解答と解説

正解: A, B

解説:

A が正解: 高基数（high cardinality）ラベルを入れると 時系列数 = ラベル値の組合せ数 が爆発し、課金もクエリ時間も急増します。user_id の代わりに user_tier、session_id の代わりに session_type のような 低基数の集約軸 に置き換えるのが正攻法。設計レベルでのアンチパターン回避が再発防止の本質。
B が正解: 使われていないカスタムメトリクスを定期的に棚卸し削除することで、不要な時系列を削減できる。FinOps の観測可能性 KPI（Logging cost / total cost: 5-10% 目安）に直結。
C: Managed Service for Prometheus に移行しても、ラベル設計が悪ければ同じ問題が再発。根本解決ではない。
D: Sink でエクスポートしても元の時系列課金は変わらず、むしろストレージコスト増。
E: 暗号化はカーディナリティ削減に無関係。

試験のひっかけポイント:

カーディナリティ問題の典型例：user_id、request_id、session_id、trace_id、timestamp をラベルにする
Distribution メトリクス（ヒストグラム集約済み）はカウンタより効率的
ログベースメトリクスもカーディナリティ問題が起きうる

関連リソース:

問題 8 （難易度: ★★）

シナリオ: 研究機関 GenomeLab はゲノム解析バッチを 連続 36 時間 動かす必要があります。コスト圧縮のため Preemptible VM の利用を検討しましたが、24 時間で強制終了 する制約があり、現状の Preemptible では完走できません。中断が発生してもチェックポイントから再開できる実装は完了しています。

質問: 最も適切な選択肢はどれですか。

選択肢:

A. Preemptible VM を 24 時間ごとに自動再起動するスクリプトを書く
B. Spot VM を使う。Spot は最大稼働時間の上限が撤廃されており、preempt されない限り 36 時間以上連続稼働可能。割引率も最大 91% OFF と Preemptible 同等以上
C. CUD 3 年で N2 を予約購入する
D. オンデマンド VM で 36 時間稼働させる

解答と解説

正解: B

解説:

B が正解: Spot VM は旧 Preemptible の後継 で、最大の違いは 24 時間制限が撤廃されたこと。割引率は 最大 60-91% OFF、中断通知は 30 秒前、SLA はなし。チェックポイント実装済みであれば、長時間バッチに最適。
A: 自動再起動スクリプトは状態管理・冪等性で複雑化し、本質解決ではない。Spot に移行するのが Google 推奨。
C: CUD は長期コミット（1y/3y）で過剰、36 時間の単発バッチには不向き。
D: オンデマンドはコスト圧縮要件と矛盾。Spot で 60-91% 削減が可能。

試験のひっかけポイント:

Spot = 24h 上限なし、Preemptible = 24h 上限あり（旧仕様、非推奨）
中断通知は 30 秒前（ACPI G2 → SIGTERM）
terminationGracePeriodSeconds は 25 秒以下 が推奨（30 秒猶予に収まるよう）
「24 時間連続バッチを安く」= Spot VM

関連リソース:

問題 9 （難易度: ★★★）

シナリオ: SaaS 企業 SteadySync は本番ワークロードを 東京リージョン (asia-northeast1) の N2 ファミリーで 3 年継続 することが確定しています。月間 Compute コストは USD 50,000、VM タイプ・リージョンを変える予定は当面ありません。FinOps チームは「最大の割引率」を実現したいと考えています。

質問: 最もコスト削減効果が高い選択肢はどれですか。

選択肢:

A. Flexible CUD（Spend-based）を 3 年で購入する
B. Resource-based CUD を N2 / asia-northeast1 で 3 年購入する
C. Resource-based CUD を 1 年購入し、毎年更新する
D. SUD のみで運用する（事前購入なし）

解答と解説

正解: B

解説:

B が正解: Resource-based CUD 3 年は Compute Engine で 最大 ~57-66% OFF（マシン族による）と、CUD ファミリーで最高の割引率。マシン族・リージョンが固定で長期確定している本シナリオに最適。
A: Flexible CUD（Spend-based）3 年は ~46% OFF。マシン族・リージョン横断適用が利点ですが、割引率は Resource-based より低い。固定が確定しているなら Resource-based が有利。
C: Resource-based CUD 1 年は ~37% OFF。3 年契約より低割引で更新運用コストもかかる。
D: SUD は自動適用で最大 30%（N1 系）と魅力的ですが、CUD と組み合わせる方が合計割引が大きい（適用順は Spot → SUD → CUD）。SUD のみは機会損失。

試験のひっかけポイント:

Resource-based CUD 1y: ~37% / 3y: ~57-66%
Flexible CUD 1y: 28% / 3y: 46%
SUD 最大 30%（N1 系）、自動適用
Spot 最大 91% OFF
「マシン族・リージョン固定 + 長期」= Resource-based CUD 3y
「マシン族・サービス横断で変動」= Flexible CUD

関連リソース:

問題 10 （難易度: ★★）

シナリオ: データ分析企業 ChartMint は GKE Autopilot、Cloud Run、Cloud Functions、Compute Engine の N2 / E2 / C2 を組み合わせた多様なワークロードを運用しています。月間 Compute 系合計支出は USD 30,000 で、今後 1 年は安定見込みですが、サービス比率やマシン族の構成は四半期ごとに変動 する可能性があります。

質問: 最も適切な購買戦略はどれですか。

選択肢:

A. すべてのワークロードを N2 に統一して Resource-based CUD 1 年を購入する
B. Flexible CUD（Spend-based）1 年を購入し、Compute Engine / GKE / Cloud Run / Cloud Functions の Compute 部分に横断適用する
C. CUD は購入せず、SUD と Spot だけで運用する
D. 各サービスで個別に Resource-based CUD を購入する

解答と解説

正解: B

解説:

B が正解: Flexible CUD（Spend-based CUD） は「毎月一定額の Compute 系利用」を Commit し、Compute Engine / GKE / Cloud Run / Cloud Functions の Compute 課金部分に横断適用できます。マシン族やサービス比率が変動する組織に最適。1 年: 28%、3 年: 46% OFF。
A: ワークロードの強制統一は最適化を阻害（メモリ最適化が必要なものまで N2 にすると逆効果）。
C: 安定使用分を CUD でカバーしないのは機会損失。SUD（最大 30%）より Flexible CUD 1y（28%）は同等以上で確実。
D: マシン族・サービスが変動するため、Resource-based の固定購入は使い切れず無駄が出る。

試験のひっかけポイント:

Flexible CUD は Spend-based とも呼ばれる
Resource-based CUD は 特定マシン族 + 特定リージョン にロックされる
「GKE Autopilot や Cloud Run を含む横断利用」が出題されたら Flexible CUD
CUD は 価格割引のみ、容量保証は Reservation が必要

関連リソース:

問題 11 （難易度: ★★）

シナリオ: 動画配信プラットフォーム StreamArc は 欧州・北米・アジアのエンドユーザーに低レイテンシでコンテンツを配信 する必要があります。同時に、社内バッチで GCS から自社オンプレへ毎晩 50TB の大量データ転送 をしており、こちらは品質より料金を最優先したいです。

質問: 最も適切な Network Tier の組み合わせはどれですか。

選択肢:

A. 両方 Premium Tier に統一
B. 両方 Standard Tier に統一
C. 動画配信は Premium Tier（Google グローバルバックボーン + グローバル LB）、バッチデータ転送は Standard Tier（公衆インターネット経由で料金が 25-50% 安い）に分ける
D. 動画配信を Standard、バッチを Premium に設定

解答と解説

正解: C

解説:

C が正解: Premium Tier は Google のグローバルバックボーンを通り、低レイテンシ・99.99% SLA・グローバル LB 対応で動画配信に必須。Standard Tier は公衆インターネット経由で料金が Premium の 25-50% 程度、リージョナル LB のみで機能制約はあるが、品質要件のないバッチデータ転送には最適。ワークロード特性に応じて使い分けるのが正解。
A: 全部 Premium はコスト最適化を放棄。
B: 全部 Standard だと動画配信のレイテンシ・SLA・グローバル LB が満たせない。
D: 逆。レイテンシ重視を Standard にするのは要件と矛盾。

試験のひっかけポイント:

Premium = Google バックボーン / グローバル LB / 99.99% SLA / 高コスト
Standard = 公衆インターネット / リージョナル LB のみ / SLA なし / 25-50% 安
「グローバル LB が使えるのは Premium のみ」「同一リージョン内は Tier 関係なし（内部トラフィック）」
動画配信・ゲーミング・グローバル SaaS = Premium 必須
バッチ転送・リージョナル限定サービス = Standard で OK

関連リソース:

問題 12 （難易度: ★★）

シナリオ: ヘルスケア SaaS の MedSync は GKE Standard クラスタを運用しています。ワークロードの大半は ステートレスな Web API（HPA で 5-50 Pod スケール） ですが、現状は オンデマンドノードプール 1 種 のみで、ピーク時に余剰ノードが残りコストが嵩んでいます。SLA はそこまで厳しくなく、Pod は複数 replica で常時稼働させる前提です。

質問: 最もコスト削減効果が高い構成変更はどれですか。

選択肢:

A. Cluster Autoscaler を無効化し、ノード数を手動最適化する
B. Spot node pool を作成し、taint + toleration / nodeSelector でステートレス Pod を Spot に配置、PodDisruptionBudget と preStop hook（grace period < 30 秒）でグレースフルシャットダウン対応する
C. GKE Autopilot に移行する（既存ワークロードをそのまま）
D. Workload に GPU を割り当てる

解答と解説

正解: B

解説:

B が正解: ステートレス + 複数 replica + SLA 緩めの条件は Spot node pool に最適。手順は (1) --spot フラグで Spot node pool 作成、(2) cloud.google.com/gke-spot=true:NoSchedule の taint、(3) Pod 側に matching toleration + nodeSelector、(4) terminationGracePeriodSeconds < 30 と preStop hook で drain、(5) PodDisruptionBudget で同時退避数制御。最大 91% OFF のノード費削減が見込める。
A: Cluster Autoscaler 無効化は逆効果。需要に応じた縮退が止まり、無駄が増える。
C: Autopilot 移行は Pod 単位課金で運用負担は減るが、ノード単位の Spot 活用ができず本ケースでは Standard + Spot より割高になる可能性が高い。
D: GPU 追加はコストを増やすだけで、本シナリオに無関係。

試験のひっかけポイント:

Spot node pool は taint で誤配置を防ぐのが基本
PDB は voluntary disruption（rolling update など）には効くが、Spot preemption には完全には効かない（Google ドキュメントの注記頻出）
terminationGracePeriodSeconds は 30 秒の Spot 猶予内に収める（25 秒以下が安全）
ステートフル・即時フェイルオーバー要求 = Spot 不向き

関連リソース:

../02_学習資料/05_パフォーマンスとコスト/01_基礎.md §6, §10.1
../02_学習資料/05_パフォーマンスとコスト/02_応用.md §4.1〜§4.4, §7.1

問題 13 （難易度: ★★★）

シナリオ: EC スタートアップ QuickCart は Cloud Run で Web API を運用しています。要件は (1) コールドスタートを 200ms 以下に抑えたい、(2) 待機中もメトリクス送信などの バックグラウンド処理を継続したい、(3) リクエスト処理は I/O 待ち中心 で 1 インスタンスあたり多重処理可能、(4) コストは可能な限り抑えたい。

質問: 最も適切な Cloud Run 設定の組み合わせはどれですか。3 つ選びなさい。

選択肢:

A. min instances = 1 以上に設定してコールドスタートを回避する
B. CPU is always allocated を有効にし、待機中もバックグラウンド処理を継続できるようにする（CPU 単価が約 25% 安いメリットあり）
C. concurrency を 80-1000 の高めに設定し、I/O 待ち中の同時処理数を増やして必要インスタンス数を削減する
D. concurrency = 1 に設定して 1 リクエスト 1 インスタンスで実行
E. CPU boost を無効化する
F. min instances = 0 に設定する

解答と解説

正解: A, B, C

解説:

A が正解: min instances = 1 以上で待機インスタンスを常時保持し、コールドスタートを回避。要件 (1) を満たす。
B が正解: CPU is always allocated モードは待機中も CPU が割り当てられ、バックグラウンド処理（メトリクス送信、非同期 publish 等）を継続できる。さらに Request based（デフォルト）より CPU 単価が約 25% 安いため、min instances を立てる用途では実質的にコスト削減になる。要件 (2)(4) を満たす。
C が正解: I/O バウンドな処理は concurrency を高く（80-1000） することで 1 インスタンスで多重処理し、必要インスタンス数を削減できる。要件 (3)(4) を満たす。
D: concurrency=1 は CPU バウンド処理向け。I/O 待ち中も 1 リクエスト独占でインスタンス数が膨張、コスト最大化となる。
E: CPU boost は 起動時のみ CPU を増強しコールドスタートを短縮する機能。無効化はコールドスタート対策と逆行。
F: min instances = 0 はコールドスタートが発生する設定で要件 (1) と矛盾。

試験のひっかけポイント:

CPU is always allocated と CPU is only allocated during request の課金モデルの違い
CPU バウンド = concurrency 低 / I/O バウンド = concurrency 高
CPU boost は 起動時のみ で常時は効かない
min instances の待機分も課金される（always allocated の方が単価安）

関連リソース:

問題 14 （難易度: ★★）

シナリオ: レガシー基幹システムを Compute Engine に移行した EnterpriseCo は、運用開始 60 日後に Recommender から「多数の VM で CPU 使用率が平均 8%、推奨マシンタイプは現状より小さい」という指摘を受けました。さらに標準マシンタイプ（n2-standard-4: 4 vCPU / 16 GB）では vCPU は余るが、メモリは半分しか使っていません。CFO から「コストを 30% 削減せよ」と指示が来ました。

質問: 最も効果的な改善策の組み合わせはどれですか。2 つ選びなさい。

選択肢:

A. VM rightsizing Recommender（過去 8 日間の使用率分析）に基づき、提案されたマシンタイプに変更する
B. Custom Machine Type で --custom-cpu=2 --custom-memory=4GB のように vCPU・メモリ比率を実使用に合わせる
C. Sole-tenant nodes に変更する
D. すべての VM を Spot VM に変更する
E. PD タイプを PD Extreme にアップグレードする

解答と解説

正解: A, B

解説:

A が正解: VM rightsizing Recommender は 過去 8 日間の CPU・メモリ使用率 を分析し、適正なマシンタイプを推奨します。本シナリオは典型的な過剰割当てで、Recommender 適用で 20-50% のコスト削減が見込めます。
B が正解: Custom Machine Type は標準マシンタイプの vCPU:メモリ比率に縛られず、1 単位で指定可能。本シナリオのように「vCPU 余り、メモリ半分使用」のケースで 5-30% のコスト削減につながる。
C: Sole-tenant nodes は 物理ホスト占有でライセンス要件（BYOL）向け。共有テナント（標準）より高コストで、本シナリオでは逆効果。
D: 基幹システムは状態を持つことが多くフェイルオーバー設計も難しいため、Spot に一律変更はリスク大。バッチ・ステートレス限定。
E: PD Extreme は超高 IOPS 用途。コスト削減と逆行。

試験のひっかけポイント:

VM rightsizing Recommender は過去 8 日間分析 が暗記必須
Custom Machine Type は標準（n2-standard-4 等）と 規定マシンタイプ より柔軟
Sole-tenant は BYOL 等の特殊要件専用、コスト削減ではない
基幹システムを「全部 Spot」は試験での罠選択肢の典型

関連リソース:

../02_学習資料/05_パフォーマンスとコスト/01_基礎.md §3.1, §10.3
../02_学習資料/05_パフォーマンスとコスト/02_応用.md §5.1, §7.3

問題 15 （難易度: ★★★）

シナリオ: グローバル金融 PrimeOps は 5 部門 × 200 プロジェクトの GCP を運用しています。CFO 要件は (1) 部門別・サービス別のコストを毎日可視化、(2) 月予算 USD 500,000 の 50% / 80% / 100% / 120% でアラート通知、(3) GKE クラスタについては Namespace 別の課金集計、(4) CO2 排出量も BigQuery で分析、(5) アラートは Pub/Sub 経由で社内 Slack 通知ワークフローと連携。

質問: 要件を満たすために必要な機能の組み合わせとして 適切なもの 4 つ を選びなさい。

選択肢:

A. Cloud Billing の BigQuery Export（Standard / Resource / Pricing）を有効化し、Looker Studio で部門別ダッシュボードを構築
B. Cloud Billing Budgets を Pub/Sub 通知付きで作成し、--threshold-rule=percent=0.5/0.8/1.0/1.2 の 4 段階で設定
C. GKE Cost Allocation を有効化し、Billing Export 経由で goog-k8s-cluster-namespace ラベルから Namespace 別集計
D. Carbon Footprint の BigQuery Export を有効化し、リージョン別 CO2 排出量を分析
E. Budget アラートを設定すれば自動でプロジェクト課金が停止される
F. Cloud Logging Sink で BigQuery にコストを送る

解答と解説

正解: A, B, C, D

解説:

A が正解: Cloud Billing の BigQuery Export には Standard / Resource-level / Pricing の 3 種類があり、組み合わせれば部門別・サービス別・リソース別の集計が SQL で可能。Looker Studio で可視化が定石。
B が正解: Cloud Billing Budgets は --threshold-rule=percent=... を複数指定でき、50/80/100/120% の段階通知が可能。Pub/Sub 連携で Slack/Jira/Cloud Functions に流せる。
C が正解: GKE Cost Allocation をクラスタで有効化すると Billing Export のラベルに goog-k8s-cluster-name / goog-k8s-cluster-namespace が付き、Namespace 別の課金を SQL で集計可能。
D が正解: Carbon Footprint はプロジェクト・サービス・リージョン別の CO2 排出量を可視化する無料ツールで、BigQuery Export 可能。低炭素リージョン（europe-west1、us-west1、asia-northeast1 等）の選定に活用。
E: Budget アラートは通知のみで、自動停止は行いません。停止には Cloud Function + Billing API（billing.projectBillingInfo.update で billingEnabled=false）の自前実装が必要で、本番では危険なため慎重運用。試験の典型ひっかけ。
F: Cloud Logging Sink はログを送るための仕組みで、Billing データの送信経路ではない。Billing は専用の Billing Export が正規。

試験のひっかけポイント:

Budget アラート = 通知のみ、停止は別途実装（重要）
BigQuery Export には Standard / Resource-level / Pricing の 3 種類
GKE Cost Allocation 有効化で Namespace 別集計のラベルが Billing に伝播
Carbon Footprint は 無料 + BigQuery Export 対応
ShowBack（可視化）と ChargeBack（実請求）の使い分けも頻出

関連リソース:

../02_学習資料/05_パフォーマンスとコスト/01_基礎.md §4, §11
../02_学習資料/05_パフォーマンスとコスト/02_応用.md §6.5, §8.1〜§8.4

正答率早見表

学習者用チェックリスト。回答後に記入し、弱点把握に使ってください。

問題	難易度	試験ガイド項目	テーマ	正誤
1	★★	5.1	Profiler Wall-clock の使い分け	☐
2	★★	5.1	Profiler 言語サポート（Python の制限）	☐
3	★★★	5.1	Trace × Profiler × Logging 統合	☐
4	★	5.1	Recommender API + BigQuery Export 自動化	☐
5	★★	5.1	Insights vs Recommendations / 5 カテゴリ	☐
6	★★	5.2	Logging Exclusion filter	☐
7	★★★	5.2	高基数ラベルとカスタムメトリクス棚卸し	☐
8	★★	5.2	Spot VM（24h 制限なし、91% OFF）	☐
9	★★★	5.2	Resource-based CUD 3y（最大割引）	☐
10	★★	5.2	Flexible CUD（横断適用）	☐
11	★★	5.2	Network Tier Premium / Standard 使い分け	☐
12	★★	5.2	GKE Spot node pool + PDB + preStop	☐
13	★★★	5.2	Cloud Run（min instances / CPU always / concurrency）	☐
14	★★	5.2	Compute Engine Rightsizing + Custom MT	☐
15	★★★	5.2	Billing Export / Budget / GKE Cost Allocation / Carbon	☐

目標スコア

合格圏: 14/15 (93%) 以上
合格ライン: 12/15 (80%) 以上
要復習: 10/15 (67%) 未満

弱点別の復習リンク

弱点領域	該当問題	復習先
Cloud Profiler の使い分けと言語サポート	1, 2	`01_基礎.md` §2.2, `02_応用.md` §1.1〜§1.3
Trace / Profiler / Monitoring の統合	3	`01_基礎.md` §2.4, `02_応用.md` §1.4
Recommender / Insights / 5 カテゴリ	4, 5	`01_基礎.md` §3, `02_応用.md` §2
観測可能性コスト（Logging / Monitoring）	6, 7	`01_基礎.md` §5, `02_応用.md` §3
Spot VM	8, 12	`01_基礎.md` §6, `02_応用.md` §4
CUD / SUD / Network Tier	9, 10, 11	`01_基礎.md` §7〜§9, `02_応用.md` §6
GKE 最適化	12	`01_基礎.md` §10.1, `02_応用.md` §7.1
Cloud Run 最適化	13	`01_基礎.md` §10.2, `02_応用.md` §7.2
Compute Engine 最適化	14	`01_基礎.md` §10.3, `02_応用.md` §7.3
BigQuery Billing Export / Budget / Carbon	15	`01_基礎.md` §4, §11, `02_応用.md` §8

次のステップ

全 5 セクションを通しで確認できる 模擬試験 に挑戦：../04_模擬試験/模擬試験1.md
試験直前の最終確認は 要点と暗記：../02_学習資料/05_パフォーマンスとコスト/03_要点と暗記.md

試験対策のコツ: Section 5 は出題比率 ~12% と低めですが、数値（CUD %、Spot %、SUD %、Cloud Run 設定値）の正確さ と 「症状 → どのプロファイル」「コスト課題 → どの推奨カテゴリ」のマッピング が問われます。特に「Python の Heap プロファイル不可」「Exclusion filter が ingestion 削減で最強」「Spot VM の 24h 制限撤廃」「Budget は通知のみ、停止は別実装」の 4 大ひっかけは即答できるようにしてください。