Deep Dive: Compute

1コンピュート全体像 — IaaS / CaaS / PaaS / FaaS の階層

Google Cloud のコンピュートは 抽象化の度合い によって 4 階層に整理できます。 下層ほど OS や ネットワークまで自由に制御でき、上層ほど Google が運用を肩代わりします。 PCA 試験では「ステート保持」「コンテナ可否」「スケーリング特性」「運用負荷」の 4 軸で 正しく選定する判断力が問われます。

2コンピュート選定 完全フロー — 決定ツリー

PCA のケーススタディは、必ず「コンピュート選定」を内包します。 以下のフローを頭に焼き付けておくと、Q1 を 30 秒で正答候補に絞れます。

マシンファミリー選定（GCE 限定）

3Compute Engine 詳細 — マシンファミリーから Live Migration まで

"Compute Engine offers VM instances and bare metal instances with the KVM hypervisor. Compute Engine has a monthly uptime SLO of at least 99.9%." 公式↗

3.1 マシンファミリー全 5 系統

3.2 Custom Machine Type

N シリーズと E シリーズに限り、vCPU 数とメモリ量を自由に組み合わせできます。 「8 vCPU だけど 80 GB メモリほしい」といった非標準ニーズに対応。

3.3 ストレージオプション — Persistent Disk / Hyperdisk / Local SSD

3.4 Live Migration と メンテナンスポリシー

Compute Engine はホストメンテナンス時、VM を別ホストへ無停止移行（Live Migration）できます。 これにより、計画メンテナンスでアプリが止まらないのが GCE の差別化ポイントです。

4Spot VM 完全解剖 — 91% 割引の裏側と中断ライフサイクル

"Spot VMs are VMs that use the spot provisioning model... offer up to 91% discounts... Spot VMs are excluded from the Compute Engine SLA." 公式↗

4.1 Spot VM とは何か

Google が 余剰計算リソース を最大 91% 引きで提供する仕組み。 ただし、Google は いつでも任意のタイミングで中断（preempt）できます。 SLA 対象外で、Free Tier クレジットも適用されません。

4.2 中断ライフサイクル — 30 秒の猶予を逃すな

1. 中断通知: Metadata Server 上で scheduling/preempted=TRUE がセット。アプリは metadata polling で検知可能。
2. SIGTERM 送信: ACPI G2 Soft Off 経由で OS にシグナル。Linux なら systemd 終了プロセスが起動。
3. グレースフル猶予: 公式は「best effort and up to 30 seconds」。確約されないため、30 秒「以内」と考える。
4. SIGKILL: 強制停止。アプリは未完了処理をすべて失う。
5. 状態遷移: TERMINATION_ACTION 設定で STOP（再起動可）または DELETE。

4.3 Spot VM vs Preemptible VM

4.4 SIGTERM ハンドラー実装パターン

import signal, sys, time

def handle_sigterm(signum, frame):
    # 30 秒以内にすべて完結させる
    print("SIGTERM received. Flushing state...")
    flush_to_gcs()      # チェックポイント保存
    close_db()          # コネクション解放
    deregister_from_lb()# LB から登録解除
    sys.exit(0)

signal.signal(signal.SIGTERM, handle_sigterm)

# メイン処理
while True:
    do_work()
    time.sleep(1)

import requests, time

METADATA_URL = "http://metadata.google.internal/computeMetadata/v1/instance/preempted"
HEADERS = {"Metadata-Flavor": "Google"}

while True:
    r = requests.get(METADATA_URL, headers=HEADERS)
    if r.text.strip() == "TRUE":
        # 中断確定。シャットダウン処理
        graceful_shutdown()
        break
    time.sleep(5)

4.5 ベストプラクティス vs アンチパターン

5MIG オートスケーリング設計 — リージョナル・Stateful・シグナル選定

5.1 MIG とは — Zonal vs Regional

5.2 Autoscaler のシグナル種類

5.3 Stateful MIG — DB 等の State を保持

通常の MIG は「VM は使い捨て」前提ですが、Stateful MIG は インスタンス名、アタッチされた PD、メタデータを保持します。 これにより MIG の自動修復・更新で State を失わずに済みます。

5.4 ローリングアップデート — Surge / In-place

5.5 Auto-healing と Health Check

6Sole Tenant Nodes — 専有ハードウェアと BYOL

"Sole-tenant nodes are physical Compute Engine servers that are dedicated to hosting only your project's VMs." 公式↗

6.1 Sole Tenant Nodes が解決する 3 つの課題

6.2 コスト構造の特徴

6.3 Affinity Labels — VM のノード配置制御

Node Affinity: VM が特定のノード（または ノードグループ）に配置されるよう制御。 Node Anti-Affinity: 「Web1 と Web2 を必ず別ノードに置く」HA 配置。

# 1. ノードテンプレート作成
gcloud compute sole-tenancy node-templates create my-template \
  --node-type=n2-node-80-640 \
  --node-affinity-labels=workload=oracle

# 2. ノードグループ作成
gcloud compute sole-tenancy node-groups create my-group \
  --node-template=my-template \
  --target-size=2 \
  --zone=us-central1-a

# 3. ノードグループに VM 作成
gcloud compute instances create my-vm \
  --machine-type=n2-standard-8 \
  --node-group=my-group \
  --zone=us-central1-a

7Confidential Computing — 使用中のデータも暗号化

従来の暗号化は「保存時 (at rest)」と「転送中 (in transit)」のみカバー。 Confidential Computing は「使用中 (in use)」のメモリ内データもハードウェアレベルで暗号化します。

7.1 ハードウェア技術 — AMD SEV / SEV-SNP / Intel TDX

7.2 性能オーバーヘッド

7.3 ユースケース

• 規制業界: PCI DSS、HIPAA、GDPR でメモリ内データ保護を要求される場合
• マルチパーティ計算: 複数組織がデータを共有せずに共同分析（例: 銀行間 AML 分析）
• 機密 ML: 学習データとモデルを完全に保護
• Confidential GKE Nodes: K8s 全体を Confidential 上で運用

8GKE Autopilot vs Standard — 課金と制限の決定的な差

"Autopilot clusters enable and apply security best practices and settings by default... Privileged Pods require allowlists." 公式↗

8.1 課金モデルの違い

8.2 機能比較マトリクス

8.3 選定基準

9GKE 詳細設計 — Regional / リリースチャンネル / Workload Identity

9.1 Regional vs Zonal クラスタ

9.2 リリースチャンネル — どこを選ぶ？

9.3 Workload Identity — GKE 認証の事実上の必須

"Workload Identity Federation for GKE replaces the need to use Metadata concealment. The sensitive metadata protected by metadata concealment is also protected by Workload Identity Federation." 公式↗

1. Pod が KSA（Kubernetes Service Account）を使って GKE Metadata Server にトークンを要求
2. Metadata Server が K8s API Server に JWT を要求し取得
3. JWT を Security Token Service に渡し、Federated Token に交換
4. Federated Token で GCP API を呼び出し（IAM 権限はバインディング済み）

9.4 Cluster Autoscaler と Node Auto-Provisioning (NAP)

9.5 Cluster Upgrade 戦略 — Surge Upgrades

10GKE Enterprise (Anthos) — マルチクラスタ・マルチクラウド統制

GKE Enterprise（旧称 Anthos）は、GCP / オンプレ / AWS / Azure にまたがる K8s クラスタを一元管理するプラットフォーム。マルチクラウド時代の運用統制を実現します。

10.1 構成要素

10.2 各機能の役割

11Cloud Run vs Cloud Run functions — コンテナ or 関数

"Cloud Run is a fully managed application platform... A service can rapidly scale out to one thousand instances." 公式↗

11.1 Cloud Run の 3 種類のリソース

11.2 Cloud Run の仕様

11.3 Cloud Run functions（旧 Cloud Functions）

11.4 Direct VPC Egress — VPC Connector 不要

12Cloud Run コールドスタート対策 — SLA を守る設計

"Cloud Run minimizes cold starts... requests will be queued for up to 10 seconds or 3.5x the estimated cold start time, whichever is higher." 公式↗

12.1 コールドスタートが発生する条件

1. スケールゼロから初回リクエスト: 最も典型的。コンテナのプル + 起動 + アプリ初期化。
2. 急激なトラフィック増: 既存インスタンスで捌けないとき、新規インスタンス起動。
3. リビジョン更新後: 新リビジョンの最初のリクエスト。
4. 15 分のアイドルタイムアウト後: アイドルで削除されたインスタンスが再起動。

12.2 コールドスタート対策 4 種

12.3 コンテナのライフサイクル

12.4 SLA 厳守要件の設計パターン

13App Engine — Standard vs Flexible とレガシー位置づけ

"We recommend new Google Cloud users use Cloud Run as the preferred alternative over App Engine." 公式↗

13.1 Standard vs Flexible 比較

13.2 新規プロジェクトでの判断

14VMware Engine (GCVE) — リフトアンドシフトの最終手段

"Google Cloud VMware Engine is a fully managed service that lets you run the VMware platform in Google Cloud." 公式↗

14.1 GCVE が解決する問題

• VMware 資産の即時移行: vSphere / vSAN / NSX をそのまま GCP 上で稼働
• 運用継続性: 既存の vCenter / Tools / プロセスをそのまま利用
• 段階的モダナイズ: 移行後にコンテナ化等を段階的に実施
• DR / DC 廃止: オンプレ DC 撤退、DR サイトを GCP に集約

14.2 アーキテクチャ

14.3 ハイブリッド戦略

14.4 注意点とコスト

15試験頻出パターン — ケーススタディ別の推奨構成

15.1 「コスト最小化」と書かれたら？

1. Spot VM が使えるか？（中断耐性ある？）
2. Cloud Run min instances = 0 が使えるか？（スケールゼロ可？）
3. E2 マシン + CUD（1年 / 3年） の組合せ
4. 不要時間帯は Schedule ベースで停止

15.2 「運用工数最小化」と書かれたら？

1. サーバーレス優先: Cloud Run / Cloud Run functions
2. K8s が必要なら GKE Autopilot（Standard ではない）
3. VM が必要なら MIG + Auto-healing

15.3 「SLA 99.99% / 高可用性」と書かれたら？

1. Regional MIG または Regional GKE
2. Cloud Run は min instances ≥ 1 + 複数リージョン
3. Spot VM は 使わない（SLA 対象外）
4. VMware Engine は 6 ノード以上

16アンチパターンと注意点 — よくある設計ミス

17コンピュート選定マトリクス — 包括早見表

17.1 ワークロード別の推奨

18クォータと制限の一覧 — 数値早見表

18.1 Compute Engine

18.2 Spot VM

18.3 MIG

18.4 GKE

18.5 Cloud Run

18.6 App Engine

18.7 VMware Engine

次のステップ