📚 GCP PCA 学習: 2026-05-02

セクション: 2.3 コンピュートシステムの設定 前回からの繋がり: ストレージの設計が終わり、いよいよワークロードを動かすコンピュート基盤の選択・構成へ。アーキテクチャの「心臓」であり、ビジネス要件（SLA・スケール）とコスト（リージョン・台数・ライフサイクル）のトレードオフが最も鋭くなる。

① 一言サマリー

コンピュートシステムとは、「どのマシンを、どこで、どのくらい持つか」を定める意思決定。GCP には Compute Engine（IaaS・既存資産↔）・GKE（K8s・複雑アプリ）・Cloud Run（サーバーレス・不確実）の 3 つの主流があり、PCA 試験では「要件に対する最小限度の複雑性」で選ぶことが正解軸。

② たとえ話

駅前のタクシー営業所として考えると：

Compute Engine：タクシー会社が車を何台か持って、運転手も自分で雇う。毎日の維持費（電気・保険）はかかるが、完全に自由にカスタマイズできる。既存の大型トラック（Windows ライセンス）を持っているなら、そのまま持ち込める（Rehost）。
GKE：複数の小型配送業者（複数のマイクロサービス）が共同で駅前に停留所を持つ。各業者は自分の配送ボックスの中身だけに専念し、「停留所の運営」（K8s マスター）はプロに任せる。複雑な調整（オートスケーリング・ローリングアップデート）が自動化される。
Cloud Run：Uber のようにスマホで呼び出す。トラフィック来たら勝手に車が湧いて出て、来なくなったら消えてなくなる（冷起動秒単位）。「乗客さえいれば営業」という波状需要に最適。

この 3 つは「管理負荷↔自由度」のトレードオフを視覚化したもの。

③ 図解

graph LR
    Req[「要件」
スケール・トラフィック波状・複雑度]

    subgraph Uncertain["不確実性が高い
トラフィック波状・定期バッチ"]
        CloudRun["☁️ Cloud Run
完全サーバーレス
コールドスタート: 100ms
スケール: 0→MAX 秒単位"]
    end

    subgraph Medium["不確実性・複雑度・中程度
マイクロサービス・複数言語"]
        GKE["🐳 GKE
K8s オートスケーリング
スケール: 1-1000pod 秒単位
複雑な調整が自動化"]
    end

    subgraph Certain["確実性が高い
ベースロード・24/7 運用"]
        CE["💻 Compute Engine
VM 数固定
スケール: MIG で台数制御
完全カスタマイズ可"]
    end

    Req --> Uncertain
    Req --> Medium
    Req --> Certain

    style CloudRun fill:#e1f5ff
    style GKE fill:#f3e5f5
    style CE fill:#fff3e0

④ 仕組みの深掘り

Compute Engine（IaaS）

何か：仮想マシン（VM）そのもの。OS・メモリ・CPU・ディスクを自分で選び、中身は自由。

料金体系： - オンデマンド：秒単位課金。1 秒から加算（最小 1 分）。月 730 時間（24h × 30.4 日）稼働で /month の計算。 - Committed Discount（1年/3年）：25～70% オフ。「最低限このリソースは使う」という約束で割引。PCA 試験では「スパイク時のオンデマンド + ベースロード用 Committed」が正解パターン。 - プリエンプティブル VM：「Google が必要になったら、いつでも停止して良い」という約束で 70% オフ。ただし保証時間 24 時間。バッチ処理・開発環境向け。 - Spot VM：プリエンプティブルの後継（2023 GA）。保証時間なし、更に安い（80% オフ近い）。

ライフサイクル：

PROVISIONING（リソース割当中）
→ RUNNING（実行中、課金開始）
→ STOPPING（停止中）
→ TERMINATED（停止・オンデマンド課金停止）
→ DELETED（永遠に削除）

停止状態でもディスク代は請求される（重要）。

自動スケーリング（Managed Instance Group = MIG）： - Stateless MIG：Web サーバー・ロードバランサー配下。CPU 閾値（デフォルト 60%）で自動増減。Cooldown = 300秒（スケール後に次の判定まで待つ）。 - Stateful MIG：VM ごとに「ディスク名」「タグ」を記憶。削除時に「これは重要な VM」として保護。ステートフルなワークロード向け（例：database replica）。

最新 GA（2026-05 現在）： - Autoscaling events の監視（Preview）：MIG の各スケーリング決定を詳細に可視化。「なぜこの時点で +3 VM 増やされたのか」が明確化される。PCA 試験では「トレンド分析」の題材になり始めている。

Google Kubernetes Engine（GKE）

何か：マネージド Kubernetes。Pod（アプリコンテナ）を「数」で宣言すると、Node（VM グループ）が自動的に増減し、Pod を適切に配置。

構成パターン： 1. GKE Standard（手動管理）： - Node Pool を自分で定義（マシンタイプ・個数）。 - MIG を使用して Pod に応じた Node スケーリング。 - Network Policy・RBAC を細かく設定できる（自由度高い）。 - 運用負荷：中程度。

GKE Autopilot（完全マネージド）：
Node の管理を丸投げ。「このクラスタで Pod を実行したい」とだけ言う。
Pod の CPU・メモリ単位で課金（VM 単位ではない）。
Network Policy・Pod security policy が Google により自動実装。
運用負荷：低い。PCA 試験ではコスト・管理簡素化の観点から「Autopilot が勝ち」。

スケーリング階層： - Horizontal Pod Autoscaler（HPA）：Pod レプリカ数を CPU メトリクスで増減（秒単位）。 - Vertical Pod Autoscaler（VPA）：各 Pod の CPU・メモリ要求値を自動最適化。 - Cluster Autoscaler：Node（VM）を増減（数分単位）。

最新 GA（2026-05 現在）： - GKE Gateway が Cloud CDN をサポート：GKE Ingress の前に CDN キャッシュを置いて、オリジン負荷を削減。「大規模メディア配信」がより容易に。

Cloud Run

何か：コンテナを「リクエストに応じて自動起動」し、「リクエスト終了で自動停止」するサーバーレス。VM は不要。

起動モデル： - Cold Start：新規リクエスト → コンテナイメージ取得 → コンテナ起動 → ハンドル。約 100ms（Google Cloud の最速）。 - Warm Start：既存コンテナ再利用。数 ms。 - Min Instances（オプション）：待機状態で常に起動しておく Pod 数。例：Min=1 だと常に 1 つは待機（コスト増だが Cold Start 回避）。

課金体系： - リクエスト数（100万リクエスト/月まで無料） - 実行時間（CPU・メモリ） - 実行中だけ課金。待機中は 0 円。これが Cloud Run の最大の利点。

制約： - リクエスト/レスポンスで完結（長時間バックグラウンドジョブは不可）。 - ステートレス（セッション情報をメモリに保つと、次リクエスト時に消える）。

Cloud Functions

何か：Cloud Run より軽量な関数単位のサーバーレス。「1 つの関数」を実行するだけ。

違い： - Cloud Run：コンテナ（OS レベルの制御）。 - Cloud Functions：関数（言語ランタイムレベル）。 - 起動速度：Cloud Functions の方が早い（20-50ms）。 - 複雑度：Cloud Functions は言語固定（Node/Python/Go/Java）。

PCA 試験での扱い： - Cloud Functions は「選択肢の消去法」で出現。「1 つの API エンドポイント」「Pub/Sub トリガー」などの単純な要件なら Functions。複雑なら Run。

⑤ 他サービスとの使い分け

軸	Compute Engine	GKE	Cloud Run	Cloud Functions
最小管理負荷	❌（VM OS 管理）	⚠️（Node 管理）	✅（完全マネージド）	✅（最小）
コスト（ベースロード）	✅（Committed）	⚠️（Node 課金）	❌（常時は高い）	N/A
コスト（スパイク）	❌（フルスケール）	⚠️（Pod + Node）	✅（リクエスト単位）	✅（実行単位）
複雑度対応	⚠️（手書き）	✅（オーケストレーション）	❌（単一コンテナ）	❌（単一関数）
起動速度	分単位（OS起動）	秒単位（Pod）	100ms（Cold Start）	20-50ms
ステート保持	✅（可能）	✅（Persistent Volume）	❌（推奨しない）	❌（不可）
スケール波状への対応	❌（ベースロード固定）	⚠️（秒単位）	✅（秒単位・完全）	✅（完全）
既存資産対応	✅（5R Rehost）	⚠️（コンテナ化必要）	❌（要再構築）	❌（要再構築）

判定フローチャート（PCA 試験の決定木）

graph TD
    A["要件分析: スケール・複雑度・既存資産"]

    B["既存 VM/ライセンス
必須?"]
    B -->|Yes| CE["✅ Compute Engine
Rehost パス"]
    B -->|No| C["複雑な
マイクロサービス?"]

    C -->|Yes| D["複数チーム・
長期運用?"]
    D -->|Yes| GKEStd["✅ GKE Standard
RBAC・NPol 細かく"]
    D -->|No| GKEAuto["✅ GKE Autopilot
運用楽・コスト透明"]

    C -->|No| E["トラフィック
波状?"]
    E -->|Yes| F["リクエスト/応答
型?"]
    F -->|Yes| Run["✅ Cloud Run
秒スケーリング・冷起動OK"]
    F -->|No| Pub["✅ Pub/Sub
+ Cloud Tasks
+ Compute Engine"]

    E -->|No| CE2["✅ Compute Engine
or GKE Standard"]

    style CE fill:#c8e6c9
    style GKEStd fill:#bbdefb
    style GKEAuto fill:#bbdefb
    style Run fill:#ffe0b2
    style Pub fill:#f8bbd0
    style CE2 fill:#c8e6c9

⑥ 実務への応用

シーン 1：Web スタートアップ（トラフィック波状・ユーザー数未確定）

初期フェーズ: Cloud Run + Cloud SQL（最小コスト）
↓ ユーザー 10k→100k に成長
↓ キャッシュ・複雑なロジック必要
→ GKE Autopilot + Cloud Memorystore（Redis）
  理由：Cloud Run では複数言語・複雑な API gateway が必要になり、
       結果的に「GKE の小規模クラスタ」より高コスト化する。

シーン 2：大規模 SaaS の本番環境

構成：GKE Standard クラスタ × 3 リージョン（東京・大阪・シンガポール）
  - Node Pool: 低予定/高予定 2 つ（Committed Discount 最適化）
  - HPA: CPU 70% で Pod 増減
  - Cluster Autoscaler: Node 80% で VM 追加
  - Cloud CDN + GKE Gateway（最新 GA）で全リージョン統一キャッシュ

コスト削減：
  - Committed Discount 適用: ベース層を月 30万円削減
  - Spot Node 20%: バースト時 Node を低コスト実行
  - 結果：月 150万円→ 90万円（40% 削減）

シーン 3：レガシーオンプレミス統合

要件：Windows SQL Server（ライセンス持込）+ Java ERP を AWS から GCP へ
→ Compute Engine × 2（WinRM, SQL Server）
→ GKE（Java ERP をコンテナ化）
→ ハイブリッド接続：Dedicated Interconnect（AWS Interconnect 接続）

理由：
  - Rehost（既存 VM をそのまま移行）で移行期間短縮・学習コスト削減
  - Java ERP は Kubernetes 化で運用を標準化
  - Interconnect で SQL Server セッション同期（低遅延）

シーン 4：バッチ処理・定期ジョブ

10GB CSV 日次変換（毎日 2:00 AM に 1 時間実行）
→ Cloud Functions（Pub/Sub トリガー） + 一時 Compute Engine（Spot）
  理由：
  - Cloud Run は「リクエスト型」なので定期実行に向かない
  - Spot VM で 80% コスト削減（1 時間だけ起動なので十分）
  - 失敗時は Cloud Tasks で 5 分後リトライ

⑦ よくある誤解・落とし穴

誤解 1：「GKE なら何でもできて最強では？」

❌ 常識的な開発チームには不要な複雑性

Kubernetes を学ぶコスト：3-6 ヶ月
運用負荷：Pod ログ・マニフェスト・RBAC・Network Policy
PCA 試験の採点軸は「必要最小限度」。「複雑性」は減点対象。

✅ GKE が活躍するのは： - マイクロサービス 10+個（Pod 100+個） - マルチリージョン・複数チーム - ローリングアップデート・カナリア・Blue-Green 同時進行

「開発チーム 5 人の Web サービス」なら Cloud Run + Cloud SQL が正解。

誤解 2：「Compute Engine は古い・IaaS は使うな」

❌ これは大嘘。Compute Engine は「最良の選択」になり得る

✅ Compute Engine が正解： - Windows / SQL Server / Oracle（ライセンス持込） - 既存 VM → Rehost（移行期間短縮） - ベースロード + Committed Discount（最安） - 複雑なカスタムネットワーク（ダイレクト接続・BGP）

PCA 試験では「何となく最新（Kubernetes・サーバーレス）を選ぶ」が不正解パターン。

誤解 3：「Cloud Run はコールドスタート 100ms だから無視できる」

❌ ユーザー体験は「全体の応答時間」で決まる

コールドスタート: 100ms
+ API ハンドリング: 200ms
+ DB クエリ: 300ms
+ 外部 API（決済）: 800ms（最も遅い）
─────────────────────
合計: 1400ms（1.4秒）

この場合、Cold Start の 100ms はノイズ。
それより「決済 API の呼び出し最適化」が効果大（ハイレベル）

誤解 4：「Committed Discount は 1 年が最適」

❌ GCP 料金は常に更新される。長期拘束は危険

✅ PCA 試験での判断軸： - ベースロード・確実性高い → Committed（1 年か 3 年） - スパイク・不確実 → オンデマンド or Spot - 「ハイブリッド」：Committed（60%）+ オンデマンド（30%）+ Spot（10%）

誤解 5：「Cloud SQL は 1 インスタンス、シンプル」

❌ HA・読み取り複製・バックアップで複雑性が急増

Single 構成: $300/月（ダウンタイムリスク高い）
HA 構成: $600/月（自動フェイルオーバー・同期レプリケーション）
読み取り複製 +3: +$900/月（分析用途・負荷分散）
─────────────────────
合計: $1500/月（5倍に膨張）

要件：「ローカル開発用」「分析の急増」ごとに再評価

⑧ 理解度チェック

以下 3 つのシナリオで、どのコンピュートを選びますか？理由も答えてください。

Q1：スマートロック SaaS（IoT スタートアップ）

要件：
- トラフィック：9AM-6PM は 10,000 req/s、夜間 100 req/s
- 構成：API Gateway + Auth Service + Device Handler
- チーム：エンジニア 3 人
- 既存資産：なし

あなたの答え： - 選択肢：(A) Compute Engine (B) GKE Autopilot (C) Cloud Run (D) Cloud Functions - 理由：

答え（クリック）

**正解：(C) Cloud Run** **理由**： 1. **スケール波状**が最大の特徴。9AM に 10,000 req/s、夜間 100 req/s は 100 倍差。 2. **Compute Engine**：Min 台数をどう決めるか？9AM 用に 50 台確保 → 夜間遊ぶ（コスト無駄）。 3. **GKE Autopilot**：Pod で秒単位スケーリング可能だが「運用負荷（マニフェスト・RBAC）」が過剰。チーム 3 人には重い。 4. **Cloud Run**：リクエスト単位で自動スケーリング。夜間は冷起動 100ms だが「ユーザーが少ないから許容」。コスト：数千円/月で最小。 **ハイレベル加点**：Cloud Run の前に Cloud CDN を置いて「静的 API レスポンス」をキャッシュ（オリジン負荷 80% 削減）。

Q2：銀行間決済システム（ミッションクリティカル）

要件：
- トラフィック：安定 1,000 tx/s、ピーク 2,000 tx/s
- 構成：複数言語（Java・Go・Python）、DB Spanner（複数リージョン）
- チーム：DevOps 5 人・インフラ 3 人
- SLA：99.99%（年間 52 分のダウン許容）
- 既存資産：なし

あなたの答え： - 選択肢：(A) Compute Engine (B) GKE Standard (C) GKE Autopilot (D) Cloud Run - 理由：

答え（クリック）

**正解：(B) GKE Standard** **理由**： 1. **複数言語**：Kubernetes ならマニフェスト 1 つで「Java Pod・Go Pod・Python Pod」を統一管理。Compute Engine なら言語ごとに VM グループを作る（複雑）。 2. **99.99% SLA**：複数リージョン × 複数 Node が必要。GKE の Cluster Autoscaler + Pod Disruption Budget で「計画メンテナンス中も自動再配置」（ダウンなし）。 3. **チーム規模**：DevOps 5 人がいるので「RBAC・Network Policy・Pod Security Policy」の細かい設定が可能。Autopilot では制御不足。 4. **Committed Discount**：ベース 1,000 tx/s は固定なので、Node Pool に Committed を適用（月 20%削減）。 **デプロイ戦略**：Cloud Deploy + GKE にて Blue-Green デプロイ（無停止更新）。

Q3：医療データ分析プラットフォーム（HIPAA 対応）

要件：
- ワークロード：毎日 AM 2:00 に 500GB のデータを処理（3 時間）
  → Apache Spark で分析
  → 結果を BigQuery に投入
- 構成：既存オンプレ Hadoop を置き換え
- チーム：データサイエンス 10 人（インフラ知識なし）
- セキュリティ：VPC Service Controls で「流出禁止」

あなたの答え： - 選択肢：(A) Compute Engine (B) GKE Standard (C) Dataproc (D) Cloud Run - 理由：

答え（クリック）

**正解：(C) Dataproc（Compute Engine/GKE の上位選択肢）** **理由**： 1. **Apache Spark**：フルマネージド Dataproc クラスタ（Hadoop・Spark・Hive）を使う。Compute Engine で自分でセットアップ → 迷路。 2. **定期実行**：Dataproc は Cloud Composer（Airflow）で定期実行・リトライ・アラートが統合。 3. **自動スケーリング**：処理完了後にクラスタを「自動削除」（1 時間で消える）。Compute Engine なら手動削除→コスト無駄。 4. **VPC Service Controls**：Dataproc + BigQuery が VPC Service Controls に対応。Data Scientist は「VPC の外」から安全に使用。 **見た目の「コンピュート」選択肢の落とし穴**： - Compute Engine：「自由」だが、Hadoop・Spark ブートストラップの 1000 行スクリプト化。 - GKE：Spark on K8s（スケーリング複雑）+ 運用負荷。 - **Dataproc**：「Hadoop と Spark」に特化した正解。試験では「見たことない」ハイレベル知識。

⑨ 深掘り補足（実務・最新 GA）

Spot VM の実践的リスク管理

⚠️ Spot VM は「いつ停止するか不明」が本質。安さと reliability のトレードオフ。

# GKE クラスタで Spot Node を 20% 混入する例
# デプロイ時：Pod Disruption Budget で「Spot 削除時の影響最小化」

apiVersion: policy/v1
kind: PodDisruptionBudget
metadata:
  name: my-api
spec:
  minAvailable: 1  # 常に 1 Pod は alive
  selector:
    matchLabels:
      app: my-api
---
# Spot Node はトレーニング・低優先度バックエンド向け
# 本体 Pod は Regular Node に置く（Affinity）

コスト効果： - Regular Node 80%: $10,000/月 - Spot Node 20%: $2,000/月 - 合計: $12,000/月（Spot なし $15,000 の 80%）

MIG の Autoscaling Events 監視（新 GA）

最新リリース（2026-05）で Compute Engine の autoscaling 決定を詳細ログ化。

# コマンド例
gcloud compute instance-groups managed describe my-mig \
  --region us-central1 \
  --format="value(autoscaledGroupUrl)" | xargs -I {} \
  gcloud monitoring time-series list \
    --filter="resource.labels.autoscaler_id={}"

# ダッシュボード：各スケーリング決定（時刻・判定値・変化数）を可視化
# PCA 試験では「キャパシティプランニング」に活用する問題が増加傾向

実務への応用： - 「この時間帯になぜ +5 VM?」→ トラフィックパターン分析 → 予測スケーリング導入 - 「Cooldown 300s は短すぎて振動している」→ 900s に変更 → コスト安定化

GKE Gateway + Cloud CDN（新 GA）

従来：Ingress → 直接オリジンサーバー

新：Ingress → GKE Gateway → Cloud CDN → オリジンサーバー

apiVersion: networking.gke.io/v1
kind: Gateway
metadata:
  name: my-gateway
spec:
  addresses:
  - type: NamedAddress
    value: my-static-ip
---
apiVersion: compute.cnrm.cloud.google.com/v1beta1
kind: ComputeBackendService
metadata:
  name: my-backend
spec:
  enableCDN: true  # Cloud CDN 有効化
  cdnPolicy:
    cacheMode: "CACHE_ALL_STATIC"  # 静的コンテンツ全キャッシュ
    clientTtl: 3600
    defaultTtl: 3600
    maxTtl: 86400

効果： - オリジン負荷 50-70% 削減（CDN キャッシュヒット率 80%+） - 全リージョンの CDN ノードから配信（遅延 100ms → 50ms） - コスト増は「CDN 出力」のみ（$0.085/GB）。削減効果がはるかに大。

Cloud Run の Min Instances vs オンデマンド

シナリオ：API が夜間も監視・アラートで呼び出される（1-2 req/分）

オプション A：Min Instances = 0（完全オンデマンド）
  夜間トラフィック: 2 req/分 × 60分 × 24h = 2,880 req/月
  コスト: 2,880 req × $0.0000002 = $0.0006/月
  + Cold Start 毎回: 100ms × 2,880 = 5 時間の遅延（累積）

オプション B：Min Instances = 1（常に待機）
  月額: 1 インスタンス × 730時間 × $0.00002/時間 = $1.46/月
  Cold Start なし：遅延 100ms 削減

判定：$1.46/月 で遅延排除 → **Min Instances = 1 推奨**
（スタートアップの「無料枠」内で吸収可能な額）

まとめ：PCA 試験の「正解軸」

コンピュートシステムの選択は「ビジネス要件 → 非機能要件 → 最小複雑性」
で導出されるべき。

❌ 不正解パターン
  「Kubernetes は最新だから」→ 複雑性増で減点
  「Cloud Run はサーバーレスだから最強」→ ステートフル要件で失格
  「Compute Engine は古い」→ Rehost・既存資産活用を無視

✅ 正解パターン
  スケール不確実 → Cloud Run
  複数言語・複雑 → GKE
  ベースロード・既存資産 → Compute Engine
  定期バッチ → Dataproc or Cloud Run + Cloud Tasks
  実務コスト最小化 → ハイブリッド構成（Committed + オンデマンド + Spot）

次回: 2.4 セキュリティと IAM の設定

📚 GCP PCA 学習: 2026-05-02

① 一言サマリー

② たとえ話

③ 図解

④ 仕組みの深掘り

Compute Engine（IaaS）

Google Kubernetes Engine（GKE）

Cloud Run

Cloud Functions

⑤ 他サービスとの使い分け

判定フローチャート（PCA 試験の決定木）

⑥ 実務への応用

シーン 1：Web スタートアップ（トラフィック波状・ユーザー数未確定）

シーン 2：大規模 SaaS の本番環境

シーン 3：レガシー オンプレミス統合

シーン 4：バッチ処理・定期ジョブ

⑦ よくある誤解・落とし穴

誤解 1：「GKE なら何でもできて最強では？」

誤解 2：「Compute Engine は古い・IaaS は使うな」

誤解 3：「Cloud Run はコールドスタート 100ms だから無視できる」

誤解 4：「Committed Discount は 1 年が最適」

誤解 5：「Cloud SQL は 1 インスタンス、シンプル」

⑧ 理解度チェック

Q1：スマートロック SaaS（IoT スタートアップ）

Q2：銀行間決済システム（ミッションクリティカル）

Q3：医療データ分析プラットフォーム（HIPAA 対応）

⑨ 深掘り補足（実務・最新 GA）

Spot VM の実践的リスク管理

MIG の Autoscaling Events 監視（新 GA）

GKE Gateway + Cloud CDN（新 GA）

Cloud Run の Min Instances vs オンデマンド

まとめ：PCA 試験の「正解軸」

シーン 3：レガシーオンプレミス統合