PCDE 合格対策
SECTION 5

セクション 5：
パフォーマンス & コスト最適化

PCDE の締めくくり（出題比 ~12%）。Cloud Profiler / Cloud Trace / Cloud Monitoring を中心とした APM、Active Assist の Recommender 5 カテゴリ（Cost / Security / Performance / Manageability / Reliability）、そして FinOps（Inform / Optimize / Operate） サイクル、Spot VM / CUD / Flexible CUD / SUD、Network Tiers、GKE / Cloud Run / Compute Engine 各ワークロードの最適化、Carbon Footprint によるサステナビリティまで体系的に押さえる。

📊 出題 ~12% 💰 FinOps ⚡ APM 🌱 Sustainability 📘🔧🎯 全レベル対応
出題 ~12% 📘 基礎 🔧 応用 🎯 要点
🔑 TL;DR — このセクションの要約 APM は Cloud Trace（リクエスト旅路）+ Cloud Profiler（コード行）+ Cloud Monitoring（メトリクス）。Profiler は 5 種別（CPU/Heap/Heap allocation/Wall/Contention/Thread）、Python は CPU/Wall のみ（Heap 使えない）。Active Assist は Recommender + Insights で 5 カテゴリ（C・S・P・M・R）。FinOps は Inform → Optimize → Operate のサイクル、ShowBack / ChargeBack で文化定着。コスト最適化は Spot（最大 91% OFF、24h 制限なし、30 秒通知）→ SUD（自動最大 30%）→ CUD（Resource 3y で最大 66% / Flexible 3y で 46%） の組合せ。観測可能性コストは Exclusion filter が最強。GKE は HPA / VPA / CA / NAP / Autopilot / Spot、Cloud Run は min instances + CPU boost + concurrency 調整。Network Tier は グローバル LB なら Premium 必須、コスト最優先なら Standard。Carbon Footprint で CO2 を BQ にエクスポートし低炭素リージョンを選定。

🎯 学習目標

このセクションの達成度0 / 0










※ チェック状態はこのブラウザに保存されます。

5.1 APM と Active Assist

APM の 3 サービス

APM = アプリケーションのレイテンシ・スループット・リソース使用を継続的に観測し、ボトルネックを特定する仕組み。GCP では 3 つのサービスが APM の中核。

①

Cloud Trace

分散トレース。1 リクエストの旅路を Span で可視化。App Engine / Cloud Run / Functions は自動計装。月 250 万 span 無料。

②

Cloud Profiler

連続プロファイル。コード行レベルで CPU/Heap/Wall/Contention を可視化。常時無料・本番常時稼働 OK（オーバーヘッド < 1%）。

③

Cloud Monitoring

メトリクス、Dashboard、Alerting、Uptime、SLO。基本 GCP メトリクスは無料、カスタム / ログベースは数に応じて課金。

Cloud Profiler — 5 種別（+Threads）

Cloud Profiler 種別 × 症状マッチング CPU time 関数別 CPU 時間 → CPU 100% Heap 割当済みメモリ → メモリリーク調査 Heap allocation 割当発生箇所 → GC pause 長 Wall-clock time 経過時間（I/O 含む） → 遅延長 CPU 低 Contention ロック待ち → Mutex / スレッド競合 Threads / Goroutine スレッド数 → リーク疑い 言語サポート（試験頻出ひっかけ） Go : 全部対応 / Java : CPU + Heap + Wall + Contention（Heap alloc なし） Python : CPU / Wall のみ（Heap なし） / Node.js : CPU / Heap のみ

Cloud Profiler 言語サポート

プロファイル種別GoJavaPythonNode.js
CPU time✓✓✓✓
Heap✓✓✗✓
Heap allocation✓✗✗✗
Wall-clock time✓✓✓✗
Contention✓✓✗✗
Thread / Goroutine✓✓✗✗
⚠️ 試験頻出ひっかけ「Python アプリのメモリリーク調査に Cloud Profiler の Heap を使う」は 誤り。Python は CPU / Wall のみサポート。メモリは Monitoring + 別ツール（heap dump）で代替。

APM の典型運用シナリオ

1. ユーザーから「遅い」と報告 ↓ 2. Cloud Monitoring で SLI（p95 latency）を確認 → 確かに悪化 ↓ 3. Cloud Trace で遅延が大きい Span を特定 → DB 呼び出しが 800ms ↓ 4. Cloud Profiler の CPU プロファイルで該当関数を見る → ORM が N+1 クエリを発行していた ↓ 5. コード修正、リリース後に同じ流れで再計測

Active Assist と Recommender

Active Assist は Google Cloud の AI/ML ベース推奨エンジンファミリーの総称。Recommender（処方箋＝アクション提案）と Insights（診断＝現状の事実）の 2 系統。

区分RecommenderInsights
性質アクション提案（処方箋）現状の事実（診断）
例「この VM を e2-medium に」「この VM は CPU 5%」
適用具体的な API 操作群原因の説明

Recommender 5 カテゴリ（PCDE 最頻出）

Active Assist Cost 💰 VM rightsizing / Idle / CUD Security 🔒 IAM / Firewall / Lateral Performance ⚡ Rightsizing 大 / suggest Manageability 🛠 Unused project / Dep API Reliability 🛡 HA / SPOF 検出 / Cluster

覚え方: C・S・P・M・R（コスパ管理し信頼）

代表的な Cost Recommender

Recommender提案内容
VM rightsizing recommender過剰サイズの VM を縮小（過去 8 日間の使用率を分析）
Idle VM recommender停止していないが未使用の VM の削除
Idle persistent disk recommenderアタッチされていない PD の削除
Idle IP address recommender未使用の static external IP の解放
Idle Cloud SQL recommender接続のない Cloud SQL インスタンスの削除
Committed use discount recommenderCUD 購入推奨
GKE cost optimizationGKE workload の rightsizing

推奨のライフサイクル

ACTIVE ─ 未対応 ↓ claim CLAIMED ─ 対応中（作業者が宣言） ↓ apply SUCCEEDED ─ 適用成功 or FAILED ─ 適用失敗 or DISMISSED ─ 却下（採用しない判断）
💡 Recommendation HubCloud Console の 1 画面で全プロジェクト・全カテゴリの推奨をまとめて表示。Organization スコープでさらに横断集約可能。

🔧 Cloud Profiler 使い分け判断フロー

症状: アプリが遅い │ ├── CPU 使用率が高い？ │ YES → CPU プロファイル（どの関数が CPU を食っているか） │ NO → ↓ │ ├── メモリが膨張する / OOM？ │ YES → Heap プロファイル（現在のメモリ割当） │ + Heap allocation（割当発生源、GC 圧の原因） │ NO → ↓ │ ├── レイテンシは長いが CPU は低い？ │ YES → Wall-clock time（I/O 待ち、外部 API 待ち） │ + Contention（ロック待ち） │ NO → ↓ │ └── スレッド/ゴルーチン数が増え続ける？ YES → Thread / Goroutine プロファイル（リーク疑い）

🔧 メモリリーク特定の流れ（Go / Java）

  1. Monitoring で container/memory/used が単調増加していることを検知
  2. Cloud Profiler で Heap プロファイルを 1 時間後 / 6 時間後で比較
  3. 増えている割当先（呼び出し元関数）を特定
  4. Heap allocation プロファイル（Go / Java）でアロケーション元の関数を確認
  5. ソースコード修正 → デプロイ → 同じ手順で再検証

🔧 Recommender API の自動化アーキテクチャ

Recommender API gcloud / API Cloud Scheduler 日次 / 週次 Cloud Function / Cloud Run Job Pub/Sub → Slack/Jira 手動承認 + IaC 反映 BigQuery 蓄積 Looker Studio dashboard 「推奨を自動適用は危険、推奨を IaC 経由で人が承認」が DevOps のベストプラクティス

🔧 Recommender API（Python 擬似コード）

from google.cloud import recommender_v1 client = recommender_v1.RecommenderClient() parent = "projects/PROJECT_ID/locations/LOCATION/recommenders/google.compute.instance.MachineTypeRecommender" for rec in client.list_recommendations(parent=parent): if rec.state_info.state == State.ACTIVE: publisher.publish(topic, json.dumps({ "id": rec.name, "category": rec.primary_impact.category, "saving_usd": rec.primary_impact.cost_projection.cost.units, "description": rec.description, }).encode())

🔧 Recommender BigQuery Export 分析

-- 月 1000 USD 以上の節約見込みのある Cost 推奨を抽出 SELECT project_id, recommender_name, primary_impact.cost_projection.cost.units AS saving_usd, description FROM `PROJECT.recommender.recommendations_v1` WHERE primary_impact.category = 'COST' AND primary_impact.cost_projection.cost.units < -1000 -- 節約は負の値 AND DATE(last_refresh_time) = CURRENT_DATE() - 1 ORDER BY saving_usd ASC;

🔧 主要 Insights（事実の診断）

Insight内容
Lateral movement insightサービスアカウント間で過剰権限による横断的攻撃リスク
Firewall insight使用されていない / シャドウされている FW ルール
Policy insight過剰な IAM 権限の使用実績
Reliability insight高可用構成への改善案（SPOF 検出）

🔧 Idle resource 自動削除リスト

リソースRecommender
Idle VMIdleVmRecommender
Unattached PDIdlePdRecommender
Idle static external IPIdleAddressRecommender
Idle Cloud SQLIdleSqlInstanceRecommender
Idle GKE clusterIdleClusterRecommender

🎯 APM & Active Assist 即答

要件答え
本番常時動かせるプロファイラCloud Profiler
メモリリーク調査Cloud Profiler Heap profile（ただし Python は非対応）
Mutex 待ち（ロック競合）Contention profile
同期 IO 待ち含む経過時間Wall-clock profile
マイクロサービス間ボトルネックCloud Trace
アプリ例外の集約Error Reporting
Python のメモリリークProfiler Heap は不可、Monitoring + heap dump
Java の GC pause 解析Heap allocation プロファイル
Recommender 5 カテゴリC・S・P・M・R
大量未使用 PD の発見Idle PD Recommender
IAM 権限の過剰検出IAM Recommender / Lateral movement insight
推奨の自動化通知Recommender API → Pub/Sub → Slack/Jira
推奨を組織横断で集約Recommendation Hub + Recommender BQ Export

5.2 FinOps（観測可能性コスト / Spot / CUD / SUD / Network Tiers）

FinOps とは

FinOps = Finance + DevOps。クラウドコストを エンジニアリング・財務・ビジネス の 3 者が協働で管理する文化・プラクティス・運用モデル。

FinOps Inform / Optimize / Operate サイクル

📊 Inform 可視化・配賦 Billing Export → BQ Labels / Looker Studio ⚙️ Optimize 最適化 Recommender / Spot CUD / Rightsizing 🔁 Operate 運用・ガバナンス Budget Alert Quota / Org Policy 継続的サイクル Crawl → Walk → Run の成熟度で段階的に
フェーズやることGCP 機能
Inform可視化、配賦、ベンチマークBilling Export → BigQuery、Labels、Looker Studio
Optimize推奨適用、Rightsizing、CUD 購入Active Assist、Spot、CUD、Recommender
Operateアラート、ガバナンス、定期レビューBudget Alerts、Quotas、Organization Policy

FinOps 6 原則

  1. Teams need to collaborate（協働）
  2. Decisions are driven by business value of cloud（ビジネス価値駆動）
  3. Everyone takes ownership for their cloud usage（オーナーシップ）
  4. FinOps reports should be accessible and timely（迅速で透明な可視化）
  5. A centralized team drives FinOps（中央 FinOps チーム）
  6. Take advantage of the variable cost model of the cloud（変動コストを活用）

観測可能性コストの管理

「ログを全件保存、メトリクスを全件取り込み、トレースを 100% サンプリング」は無料ではない。観測可能性自体が課金される。

観測可能性コスト削減の優先順位

優先度手法効果
1Exclusion filter取り込み課金そのものを 0 にする（最強）
2Sampling確率的に間引く
3Retention 短縮古いログは BigQuery / GCS へ
4高基数ラベル抑制user_id 等を避ける
5不要 custom metric棚卸し削除
⚠️ Sink 追加は NG「Sink を追加すれば良い」は 誤り。Sink は別の場所に追加で出力するだけで ingestion 課金は減らない。Exclusion が正解（取り込み自体を止める）。

Spot VM

Spot VM = Google のスペアキャパシティを激安で借りる仕組み。旧 Preemptible VM の後継。

特性Spot VMPreemptible VM（旧）
最大割引率60-91% OFF約 80% OFF
最大稼働時間無期限24 時間上限
中断通知30 秒前 に ACPI G2 シグナル30 秒前
SLAなしなし

Spot VM ライフサイクル

Google が preempt 30 秒前 通知 ACPI G2 シグナル OS / コンテナへ SIGTERM 伝播 preStop hook 実行 graceful shutdown LB から外す / drain SIGKILL 30 秒後 推奨設定 terminationGracePeriodSeconds < 30 秒 / preStop hook / アプリ SIGTERM ハンドラ

Committed Use Discounts（CUD）の 2 種類

種類内容割引率の目安
Resource-based CUD特定リージョン・特定マシン族（N2、C2 等）の vCPU・RAM を Commit1y: ~37% / 3y: ~57-66%（Compute Engine）
Flexible CUD（Spend-based）毎月一定額の Compute 系利用を Commit。マシン族・リージョン・サービス横断1y: 28% / 3y: 46%

Sustained Use Discounts（SUD）

月の利用時間割引率（概算）
0-25%通常価格
25-50%~10% OFF
50-75%~20% OFF
75-100%最大 30% OFF（N1 系）
🔑 適用順Spot 価格 → SUD 適用 → CUD 適用 → 最終課金。CUD が先に適用され、残りの利用分に SUD が当たる（Spot は SUD 対象外）。

CUD / SUD / Spot の選定マトリクス

状況選ぶべき
同じ VM 族で長期安定Resource-based CUD（割引率が高い）
マシン族・サービス横断で変動Flexible CUD
短期検証、不確実性高いCUD なし（SUD / Spot で対応）
バッチ / CI/CD / MLSpot VM

Network Tiers

観点Premium TierStandard Tier
経路Google グローバルバックボーン公衆インターネット
性能低レイテンシ・高信頼性通常のインターネット品質
SLA99.99%なし（ベストエフォート）
料金高い安い（Premium の 25-50%）
グローバル LB利用可能不可（Regional LB のみ）

🔧 組合せ最適化のレイヤー

┌─────────────────────────────────────────┐ │ ベースライン使用量 → CUD（3y / 1y） │ ← 最も大きな節約 ├─────────────────────────────────────────┤ │ ベースライン超の安定使用 → CUD 追加 │ │ または SUD │ ├─────────────────────────────────────────┤ │ バースト / バッチ → Spot VM │ ├─────────────────────────────────────────┤ │ 繁忙期スポット → オンデマンド │ └─────────────────────────────────────────┘

🔧 Reservation と CUD の併用

構成容量保証割引
Reservation 単独✓なし
CUD 単独なし✓
Reservation + CUD✓✓（推奨パターン）

🔧 GKE Spot node pool 構成

gcloud container node-pools create spot-pool \ --cluster=my-cluster \ --spot \ --machine-type=e2-standard-4 \ --num-nodes=3 \ --node-labels=cloud.google.com/gke-spot=true \ --node-taints=cloud.google.com/gke-spot=true:NoSchedule
# Pod 側に matching の toleration / nodeSelector apiVersion: apps/v1 kind: Deployment spec: template: spec: tolerations: - key: cloud.google.com/gke-spot operator: Equal value: "true" effect: NoSchedule nodeSelector: cloud.google.com/gke-spot: "true"
⚠️ PDB の限界Spot は いつでも preempt される。PDB は通常の rolling update には効くが、Spot 中断には完全には効かない。preemption は voluntary でない disruption として扱われる。

🔧 Cloud Logging 最適化レシピ

# GKE のヘルスチェックログを完全に除外 resource.type="k8s_container" httpRequest.userAgent="kube-probe/1.27" # Cloud LB の 2xx だけを除外（4xx/5xx は残す） resource.type="http_load_balancer" httpRequest.status<400 # 10% だけ取り込む resource.type="cloud_run_revision" sample(insertId, 0.1)

🔧 GKE Cost Allocation + BigQuery Billing Export

Cluster の cost-allocation を有効化 ↓ Billing Export → BigQuery ↓ labels に kubernetes.io/namespace, workload.name 等が付与 ↓ SQL で namespace 別・workload 別の課金を集計 ↓ Looker Studio で各チーム/サービスのコストダッシュボード
-- Namespace 別の月次コスト SELECT labels.value AS namespace, SUM(cost) AS total_cost_usd, invoice.month FROM `billing_export.gcp_billing_export_v1_XXX`, UNNEST(labels) AS labels WHERE labels.key = 'goog-k8s-cluster-name' AND invoice.month = '202605' GROUP BY namespace, invoice.month ORDER BY total_cost_usd DESC;

🔧 ShowBack vs ChargeBack

概念内容効果
ShowBack各チームの利用コストを「可視化」する（請求はしない）意識向上、自発的最適化
ChargeBack各チームに「実際に請求」する（社内振替）強制力あり、財務的に厳格

🔧 Budget アラート設計

閾値アクション
50%情報通知（Slack）
80%チーム警告、レビュー会議
100%経営層エスカレーション
120%強制対策、サービス縮退検討
gcloud billing budgets create \ --billing-account=ACCOUNT_ID \ --display-name="prod-monthly" \ --budget-amount=10000 \ --threshold-rule=percent=0.5 \ --threshold-rule=percent=0.8 \ --threshold-rule=percent=1.0 \ --notifications-rule-pubsub-topic="projects/PROJECT/topics/budget-alerts"
⚠️ Budget は通知のみBudget アラートは 支出停止を行わない（通知のみ）。停止には Cloud Function + Billing API でプロジェクト課金を無効化 するスクリプトが必要。本番では危険なので慎重に。

🔧 FinOps KPI 設計

KPI目的
Cost per requestサービス効率の指標
CUD Coverage %コミット使用率（80% 以上を維持）
Idle resource ratio無駄の比率
Logging cost / total cost観測可能性比率（5-10% が目安）
Recommendation 適用率Active Assist の活用度合い

🎯 FinOps & 価格モデル 即答

要件答え
バッチを 24 時間連続 + 最安Spot VM（旧 Preemptible の 24h 制限なし）
3 年同じ VM 族確定Resource-based CUD 3y（最大割引）
マシン族・サービス横断で長期Flexible CUD
事前購入なしの自動割引SUD（最大 30%）
ログコスト急増を抑制Exclusion filter
長期ログ保存を安価にSink → BigQuery（or GCS）+ Logging retention 短縮
GKE Namespace 別コストGKE Cost Allocation + BigQuery Billing Export
動画配信を安くPremium 必要（Standard では LB 機能制限）
同一リージョン内バッチを安くStandard Network Tier
推奨を組織横断で集約Recommendation Hub（Org スコープ）
推奨を社内チケットに自動連携Recommender API → Pub/Sub → Slack/Jira

🎯 主要数値の暗記

項目数値
Spot 割引率最大 91%
Spot 中断通知30 秒前
Preemptible 最大稼働（旧）24 時間（Spot は撤廃）
CUD 1 年（Resource-based）~37%
CUD 3 年（Resource-based）~57-66%
Flexible CUD 1 年28%
Flexible CUD 3 年46%
SUD 最大（N1 系）30%
Cloud Logging 無料枠50 GiB/月
Cloud Trace 無料枠250 万 span/月
Rightsizing Recommender 分析期間過去 8 日
Profiler オーバーヘッド< 1% CPU

🛠 ワークロード別の最適化

GKE — Standard vs Autopilot

GKE モードStandardAutopilot
課金単位ノード（VM）単位Pod 単位（vCPU・メモリ・GiB）
ノード管理ユーザーGoogle
設定柔軟性高い制限あり（DaemonSet 等）
コスト最適化手動で頑張れる平均的・予測しやすい
推奨カスタム要件多い小〜中規模 / SRE 人手少ない

GKE — 主要最適化機能

機能役割
HPA（Horizontal Pod Autoscaler）Pod 数を CPU/メモリ/カスタムメトリクスで増減
VPA（Vertical Pod Autoscaler）Pod の requests/limits を自動推定・調整
Cluster Autoscaler (CA)ノード数を必要に応じて増減
Node Auto-Provisioning (NAP)適切なマシン族のノードプールを自動作成
Spot node pool60-91% OFF のノードプール（taint + toleration）
Autopilot modePod 単位課金、ノード管理は Google

GKE — Cluster Autoscaler Profile

balanced ─ 安定重視（デフォルト）、本番向け optimize-utilization ─ 積極縮小、コスト最優先（bin packing 重視）
⚠️ VPA と HPA の併用VPA と HPA を 同じ CPU メトリクス で併用は禁止。VPA の "Off" モードで推奨値だけ取得し HPA に渡すのが安全。

Cloud Run — 主要設定

設定影響
min instancesコールドスタート回避だが、待機中も課金
max instances暴走・コスト爆発の上限
concurrencyデフォルト 80。CPU バウンドは低く（1〜10）、I/O 待ちは高く（50〜1000）
CPU always allocated待機中も CPU 課金、単価約 25% 安い、min instances 使用時に推奨
CPU is only allocated during request（デフォルト）リクエスト処理中のみ課金
CPU boost起動時のみ CPU を増やしコールドスタート短縮

Cloud Run — コールドスタート対策

1. min instances = 1〜2 ← 待機分課金あり 2. CPU boost ← 起動加速 3. コンテナイメージ最小化 ← pull 高速化 4. 言語: Go / Rust / Java native ← 起動速い

Compute Engine — 主要テクニック

テクニック効果
Rightsizing（Recommender）適正サイズ化、20-50% 削減
Custom Machine TypevCPU / メモリを 1 単位指定、5-30% 削減
Spot / Preemptibleバッチ用に最大 91% OFF
CUD（Resource-based）1y 37% / 3y 66%
Idle 削除Recommender の Idle VM 推奨を自動適用
共有テナントライセンス要件がない限り Sole-tenant より共有が安い
Instance Scheduler開発 VM を平日 9-18 時のみ起動

Compute Engine — PD タイプ選定

タイプIOPS料金 / GB用途
PD Standard低最安バックアップ、低 IO
PD Balanced中中一般 Web アプリ（推奨デフォルト）
PD SSD高高DB、高 IO
PD Extreme超高最高専用 DB、Latency センシティブ
Hyperdisk柔軟サイズ別大規模・カスタム要件

Storage — Cloud Storage クラス

クラス最小保管期間用途
Standardなしアクセス頻度高い
Nearline30 日月 1 アクセス
Coldline90 日四半期アクセス
Archive365 日年 1 アクセス、長期保管

BigQuery — コスト最適化

手法効果
パーティション必要な日付範囲だけスキャン
クラスタリング特定列でソートして scan 削減
SELECT * 禁止スキャン量に直結
Materialized View再計算不要
BI Engineキャッシュ高速化
Capacity (Slot) Reservation大量クエリは on-demand より定額制が安い
Storage Long-term90 日変更なしの table 自動で 50% OFF

ワークロード別最適化の優先順位（実務）

1. 削除可能なリソース（Idle VM、unattached PD） ← まず無料化 2. Right-sizing ← 即効 3. Spot / Preemptible への切替（バッチ） ← 大幅 4. CUD 購入（安定使用分） ← 長期コミット 5. 観測可能性コスト削減 ← 見落としがち 6. Storage クラス調整 ← 低速移行 7. Network Tier 切替 ← 機能制約あり

🌱 Carbon Footprint と Sustainability

GCP は Carbon Footprint ツール（無料）を提供。プロジェクト・サービス・リージョン別の CO2 排出量 を可視化、BigQuery にエクスポートして分析可能。

排出スコープ内容
Scope 1Google データセンター自体の直接排出
Scope 2データセンターの電力（市場ベース、再エネ証書考慮）
Scope 3機器製造などの間接排出

リージョン選定時の 3 軸トレードオフ

Cost ─┐ ├── 最適バランス点 Performance ─┤ │ Sustainability ─┘ 例: - レイテンシ重視 + 低 CO2 → asia-northeast1（東京） - コスト重視 + 低 CO2 → us-west1（オレゴン） - 全部重視 → リージョン別比較して選定
💡 24/7 carbon-free energyGoogle は 2030 年までに全データセンターで 24/7 carbon-free energy を実現する目標を掲げている。低炭素リージョン候補: europe-west1（ベルギー）、us-west1（オレゴン）、asia-northeast1（東京）等。

🎯 要点と暗記 — 一問一答

Q1. Cloud Profiler で Python アプリのメモリリークを調査するベストな方法は？

A. Cloud Profiler では Python のメモリ系プロファイルは取得できない。Python は CPU と Wall のみサポート。Heap は Go / Java / Node.js のみ。Python では Monitoring + heap dump（外部ツール）で代替。

Q2. Spot VM の特性として正しいのは？

A. 旧 Preemptible より割引率は最大 91%（同等）、24h 制限がなくなった。中断通知は 30 秒前、SLA なし。

Q3. 同じ N2 タイプを 3 年間継続利用する。最も割引が大きいのは？

A. Resource-based CUD 3y（最大 66% OFF）。Flexible CUD は柔軟だが割引率は 46%。

Q4. Cloud Logging のコストが急増。最も効果が大きい対策は？

A. Log Router で Exclusion filter を設定し、不要ログの ingestion を止める。Sink は別場所への追加出力で ingestion 課金は減らない。Retention 短縮は次の手。

Q5. GKE で特定のチーム / Namespace のコストを把握したい

A. GKE Cost Allocation を有効化し、Billing Export を BigQuery に送る。labels に goog-k8s-cluster-name や namespace が付与され、SQL で集計可能。

Q6. Active Assist の Recommender 5 カテゴリを言える？

A. Cost / Security / Performance / Manageability / Reliability（C・S・P・M・R）。「コスパ管理し信頼」と覚える。

Q7. Recommender と Insights の違いは？

A. Recommender = アクション提案（処方箋）/ Insights = 現状の事実（診断）。Insight が原因、Recommendation が処方箋の関係。例: 「この VM を e2-medium に」（Recommendation）/ 「この VM は CPU 5%」（Insight）。

Q8. グローバル外部 HTTP(S) LB を使うために必須の Network Tier は？

A. Premium Tier。Standard では Regional LB のみ利用可能。動画・ゲーミング配信も Premium 推奨。同一リージョン内バッチで安くしたいなら Standard。

Q9. Cloud Run のコールドスタートを減らしつつコスト削減

A. min instances = 1〜2 + CPU boost + CPU only during request。CPU boost で起動加速、必要に応じて待機分課金あり。バックグラウンド処理が必要なら CPU always allocated（単価約 25% 安い）。

Q10. GKE で新マシン族（GPU 等）が必要な Pod が来たら自動でノードプール作成したい

A. Node Auto-Provisioning (NAP)。Cluster Autoscaler に加えて、新規ノードプールを Pod の要件に応じて自動作成。

Q11. FinOps の Inform / Optimize / Operate を簡潔に

A. Inform = 可視化（Billing Export / Labels / Looker） / Optimize = 最適化（Recommender / Spot / CUD / Rightsizing） / Operate = 運用（Budget / Quota / Org Policy）。Crawl → Walk → Run で段階的に成熟させる。

Q12. ShowBack と ChargeBack の違いは？

A. ShowBack = 見せるだけ（請求しない、意識向上）/ ChargeBack = 社内振替で実際に請求（財務的強制力）。文化段階に応じて選択。

Q13. Budget アラートを 100% 超えたら自動で支出を止められる？

A. 止められない。Budget アラートは通知のみ。停止は Cloud Function + Billing API で別途実装（プロジェクト課金を無効化）。本番では誤停止が危険なので慎重に。

Q14. Java アプリで GC pause が長い、どのプロファイルが有効？

A. Heap allocation プロファイル（割当発生箇所）。Java は Heap allocation 非対応のため Go のみだが、Java では Heap profile で割当多い場所を特定、または JFR/heap dump 併用。

Q15. Mutex 待ちで応答が遅い、どのプロファイル？

A. Contention profile。Go / Java で対応。スレッド競合・ロック競合を可視化。

Q16. レイテンシが長いが CPU は低い、IO 待ちが疑われる

A. Wall-clock time profile。経過時間（I/O 待ち含む）を計測。Go / Java / Python で対応。

Q17. VM rightsizing Recommender はどのくらいの期間を分析する？

A. 過去 8 日間の使用率を分析。CHANGE_MACHINE_TYPE で適切なマシンタイプへの縮小を提案。

Q18. CO2 排出量を可視化・分析する仕組みは？

A. Carbon Footprint（無料）。プロジェクト・サービス・リージョン別に Scope 1/2/3 で可視化、BigQuery にエクスポートして詳細分析。低炭素リージョン（europe-west1、us-west1、asia-northeast1 等）を優先選定。

Q19. Spot 価格と CUD と SUD の適用順序は？

A. Spot 価格 → SUD → CUD → 最終課金（CUD が先に適用され、残りに SUD）。Spot は SUD 対象外（既に激安）。CUD と SUD は併用可能。

Q20. 推奨を組織横断で集約 + 自動化するアーキテクチャは？

A. Recommender API → Cloud Scheduler → Cloud Function → Pub/Sub → Slack/Jira（通知）+ BigQuery（蓄積）→ Looker Studio。自動適用は危険、推奨を IaC 経由で人が承認するのがベストプラクティス。

💡 必殺フレーズ集（試験当日用）

状況即答
「本番で常時プロファイル」Cloud Profiler（オーバーヘッド < 1%）
「メモリリーク調査」Heap profile（Python 不可）
「Python のメモリ系」Profiler 不可、heap dump で代替
「Mutex 待ち」Contention profile
「IO 待ち含む経過時間」Wall-clock profile
「Goroutine リーク」Thread / Goroutine profile
「マイクロサービス間ボトルネック」Cloud Trace
「Recommender 5 カテゴリ」C・S・P・M・R
「Recommender vs Insights」処方箋 vs 診断
「Idle VM / PD / IP 発見」Idle Recommender
「IAM 過剰権限の検出」IAM Recommender / Lateral movement insight
「推奨を組織横断で集約」Recommendation Hub（Org スコープ）
「推奨を社内チケット化」Recommender API → Pub/Sub → Slack/Jira
「バッチ最安 + 24h 連続」Spot VM（24h 制限撤廃）
「3 年同じ VM 族で最大割引」Resource-based CUD 3y
「マシン族・サービス横断」Flexible CUD
「事前購入なしの自動割引」SUD（最大 30%）
「容量保証 + 割引」Reservation + CUD 併用
「ログコスト緊急削減」Exclusion filter
「Sink 追加で削減」NG（重複課金）
「長期ログ最安」BigQuery Sink + Retention 短縮、または GCS Archive
「GKE Namespace 別コスト」GKE Cost Allocation + BigQuery Billing Export
「グローバル LB / 世界中ユーザー」Premium Tier（必須）
「コスト最優先・リージョン内」Standard Tier
「Cloud Run コールドスタート対策」min instances 1+ + CPU boost
「Cloud Run でバックグラウンド処理」CPU always allocated
「Cloud Run の concurrency」CPU バウンドは低く、I/O 待ちは高く
「GKE Pod 課金、運用負荷低い」Autopilot
「GKE Node 数を増減」Cluster Autoscaler
「GKE Pod 数を増減」HPA
「GKE Pod sizing を自動」VPA
「新マシン族ノードを自動作成」Node Auto-Provisioning (NAP)
「GKE CA Profile - コスト最優先」optimize-utilization
「FinOps サイクル」Inform → Optimize → Operate
「ShowBack」見せるだけ・請求しない
「ChargeBack」社内振替で実際に請求
「Budget アラート 100%」通知のみ（停止は別実装）
「CO2 排出量可視化」Carbon Footprint（無料、BQ Export）
「低炭素リージョン」europe-west1 / us-west1 / asia-northeast1
「3 ヶ月に 1 回アクセス大量データ」Coldline
「Rightsizing 分析期間」過去 8 日
🔑 5 分で復習する箇条書きまとめ
  • APM 3 サービス: Cloud Trace + Cloud Profiler + Cloud Monitoring
  • Profiler 5 種別: CPU / Heap / Heap alloc / Wall / Contention / Threads（Python は CPU/Wall のみ）
  • Recommender 5 カテゴリ: C・S・P・M・R（コスパ管理し信頼）
  • Recommender vs Insights: 処方箋 vs 診断
  • FinOps サイクル: Inform → Optimize → Operate / 6 原則 / Crawl → Walk → Run
  • 観測可能性コスト: Exclusion > Sampling > Retention 短縮（Sink 追加 NG）
  • Spot VM: 最大 91% / 24h 制限なし / 30 秒前通知 / ACPI G2 → SIGTERM
  • CUD: Resource-based 3y で最大 66% / Flexible 3y で 46% / SUD は自動最大 30%
  • 適用順: Spot 価格 → SUD → CUD → 最終課金
  • Network Tier: グローバル LB なら Premium / コスト最優先 Standard（25-50% 安）
  • GKE: HPA / VPA / CA / NAP / Spot / Autopilot
  • GKE CA Profile: balanced（本番）/ optimize-utilization（コスト最優先）
  • Cloud Run: min instances / concurrency / CPU always allocated / CPU boost
  • Compute Engine: Rightsizing / Custom Machine Type / Spot / CUD / Idle 削除
  • Storage: Standard / Nearline / Coldline（90 日）/ Archive（365 日）
  • GKE Cost Allocation: Namespace 別コストを BigQuery で集計
  • Budget Alert: 通知のみ。50/80/100/120% の閾値設計、停止は別実装
  • Carbon Footprint: 無料、Scope 1/2/3、BigQuery Export、低炭素リージョン選定
← セクション 4：可観測性 🏁 ホームに戻る（全 5 セクション完走） 📝 問題演習を解く 📖 用語集