運算資源選擇與設計策略

運算光譜：從 IaaS 到 Serverless

選擇正確的運算服務是 Professional Cloud Architect 最頻繁的任務之一。Google Cloud 提供了一系列運算選項，每個選項在控制權、擴展性和運維開銷 (Operational Overhead) 之間取得了不同的平衡。

• 基礎設施即服務 (IaaS)： Compute Engine (VMs)。最大化控制權，最大化管理負擔。
• 容器即服務 (CaaS)： Google Kubernetes Engine (GKE)。平衡控制權與擴展性。
• Serverless 容器： Cloud Run。高度抽象，可自動縮減至零。
• 平台即服務 (PaaS)： App Engine。專為網頁和 API 工作負載設計的全代管平台。
• 函數即服務 (FaaS)： Cloud Functions。事件驅動，適用於小型程式碼片段。

對於 GCP PCA 考試，「最優」選擇通常是能最小化運維開銷 (SaaS/Serverless) 的選項，除非有特定的技術需求（如自定義內核、舊版 OS、專用硬體）迫使您選擇更底層的架構。

白話文解釋 運算選擇策略

選擇運算服務就像決定如何解決您的晚餐。

類比 1 — 大廚的私人廚房 (Compute Engine)

Compute Engine 就像是從頭開始建造自己的廚房。您買爐灶，選擇刀具，並負責清潔地板以及在烤箱壞掉時修理它。您擁有絕對的控制權（您可以烹飪任何菜餚），但您需要花費大量時間進行維護。如果您有一個非常特殊、罕見的食譜（舊有軟體）無法在其他任何地方運作，請使用它。

類比 2 — 百貨美食街 (GKE)

GKE 就像是在繁忙的美食街經營一個攤位。商場（Google）提供電力、水和座位區（控制平面）。您專注於您的特定菜單（容器）。如果排隊的人變長，您可以透過開設更多攤位來擴展。它強大且靈活，但您仍需管理您的員工和特定設備（節點池）。

類比 3 — 自動販賣機 (Cloud Run / Serverless)

Cloud Run 就像是一台高科技自動販賣機。您不在乎機器如何運作或誰來清潔。您只需將您的產品（容器映像檔）放入其中。如果一個人想要零食，它就提供一份。如果一千個人同時出現，機器會立即神奇地複製自己。如果沒人在那裡，它就不產生費用。對於大多數現代 App 來說，這是「最優」選擇，因為它需要零維護。

深度解析：Compute Engine (VMs)

何時選擇 Compute Engine：

• 舊有應用程式： 需要特定 OS 版本或內核的軟體。
• 自定義硬體： 需要特定的本地 SSD 或複雜的網路配置（如多個 NIC）。
• 單獨租用節點 (Sole-tenant Nodes)： 為了合規性或授權而進行的物理隔離。
• 裸機 (Bare Metal)： 適用於無法虛擬化的工作負載（如 Oracle）。

成本優化功能

• Spot VM： 為具備容錯能力的批次任務提供高達 91% 的折扣。
• 自定義機器類型： 建立具備確切 CPU 和 RAM 數量的 VM——不再浪費資源。
• 承諾使用折扣 (CUDs)： 適用於穩定、長期的工作負載。

深度解析：Google Kubernetes Engine (GKE)

GKE 是複雜、基於微服務架構的「最優」選擇。

• Standard vs. Autopilot：
  • Standard： 您管理節點池和擴展。
  • Autopilot： Google 管理節點、安全性和擴展。這是 2025/2026 年符合 WAF 規範的首選。
• 區域集群 (Regional Clusters)： 實現跨分區的高可用性。
• Workload Identity： 為 Pod 提供存取 GCP 服務的安全性方式。

深度解析：Cloud Run (Serverless 容器)

Cloud Run 已成為大多數架構師的「首選」運算服務。

• 開發人員效率： 「寫完程式碼，取得 URL」。
• 並行性 (Concurrency)： 單個容器執行個體可以同時處理多個請求。
• 事件驅動： 可透過 Eventarc 由 HTTP、Pub/Sub 或 Cloud Storage 事件觸發。

專用運算：GPU 與 TPU

適用於 AI/ML 和高性能運算 (HPC)。

• GPU (NVIDIA)： 用於圖形、影片和 ML 訓練的通用加速。可在 Compute Engine 和 GKE 上使用。
• TPU (Tensor Processing Units)： Google 客製化的 ASIC，專為大規模機器學習（TensorFlow, JAX, PyTorch）優化。對於海量 LLM 訓練，請使用這些設備。

GCE 機器類型家族 (E2, N2, C3, M3)

Compute Engine 提供針對不同成本/效能設定檔最佳化的多個機器家族。PCA 考試期望您能將工作負載模式對應到正確的家族，而不是凡事都用 n2-standard-4。

通用型家族

• E2（成本最佳化）： 共享核心至 32 vCPU，可在 Intel/AMD/Ampere 上透明執行。最適合低流量網頁伺服器、開發/測試環境、小型資料庫。比 N1 便宜最多 31%，但沒有承諾資源保證，也不支援 GPU。
• N2 / N2D： 在 Intel Cascade/Ice Lake (N2) 或 AMD EPYC Milan (N2D) 上提供平衡的價格/效能。生產環境網頁層、記憶體快取、中型資料庫的預設選擇。
• N4 (Titanium)： 最新通用型層級，基於 Google 自研的 Titanium offload 架構。每 vCPU 價格低於 N2，並具備 Dynamic Resource Management。

運算最佳化

• C3 / C3D： 第 4 代 Xeon (Sapphire Rapids) / 第 4 代 AMD EPYC Genoa。針對高效能網頁伺服器、遊戲伺服器、廣告投放、HPC 前端。可搭配 Titanium SSD 取得次毫秒級本地 NVMe。
• C2 / C2D： 較舊的運算最佳化系列；對於釘選特定 CPU 世代的授權軟體仍然有效。

記憶體最佳化

• M3 / M2 / M1： 最高 12 TB RAM。SAP HANA 認證部署、大型記憶體內分析、超過 624 GB 的 Redis cluster 之必要選擇。
• M3 採用 DDR5，是新部署的 SAP 認證預設選項。

加速器最佳化

• A3 / A2： NVIDIA H100 / A100 GPU，透過 NVLink 與 GPUDirect-TCPX 以高頻寬連接。用於 LLM 訓練與大規模推論。
• G2： NVIDIA L4，用於推論、影片轉碼、繪圖工作站。

Cloud Run vs Cloud Functions vs GKE：決策樹

這三個「現代化容器/程式碼」服務的重疊範圍足以讓考生混淆。請完全依照以下決策樹：

1. 工作單位是否為單一函數，由事件 (Pub/Sub 訊息、Cloud Storage 物件、Firestore 寫入、HTTPS 呼叫) 觸發，且不需自帶執行環境？

   • 是 → Cloud Functions (2nd gen)。注意 2nd-gen Functions 實際上建構於 Cloud Run + Eventarc 之上，所以邊界已被模糊化。
   • 否 → 繼續。

2. 是否需要 Kubernetes 特有功能 — service mesh (Anthos Service Mesh / Istio)、DaemonSet、附帶持久卷的 StatefulSet、複雜的網路策略、multi-cluster ingress，或客製化 CRD/Operator？

   • 是 → GKE Autopilot（代管節點）或 GKE Standard（當您需要控制節點映像檔、特定 GPU driver 或單獨租用節點配置時）。
   • 否 → 繼續。

3. 工作負載是否為容器化的 HTTP、gRPC 或 WebSocket 服務，可自動擴展（包含縮減至零），且 60 分鐘請求逾時可接受？

   • 是 → Cloud Run services。

4. 是否為有限、執行至完成的容器化任務（資料遷移、ML 批次推論、夜間 ETL、影片轉碼批次）？

   • 是 → Cloud Run jobs（見下節）或 Batch API。

取消 Cloud Run 資格的硬性限制

• 請求時間 > 60 分鐘 → 使用 GKE 或搭配 Managed Instance Group 的 Compute Engine。
• 超過閒置上限的長期持久連線（例如聊天 backplane） → GKE。
• 需要 hostNetwork、特權容器或客製化內核模組 → GKE Standard（Autopilot 會封鎖這些）。

Cloud Run Jobs vs Cloud Run Services

PCA 常見的混淆點是將「Cloud Run」僅視為 HTTP 服務。自 2023 起，Cloud Run jobs 已成為批次型容器的一等資源。

Cloud Run services

• 由 HTTP/gRPC 請求 或 Eventarc 觸發。
• 常駐 URL，依並行度由 0 → N 擴展。
• 依請求範圍計 CPU 費用（或可選 CPU always-allocated 處理背景工作）。

Cloud Run jobs

• 由 gcloud run jobs execute、Cloud Scheduler、Workflows 或 Eventarc 觸發。
• 不需要 HTTP 監聽器 — 容器執行至完成後退出。
• 支援任務平行度（單次執行最多 10,000 個 task，每個有自己的 CLOUD_RUN_TASK_INDEX）。
• 單一 task 最長 24 小時（services 為 60 分鐘）。

何時選 jobs 而非 services

Spot VM 搭配 Batch API 實現成本最佳化運算

將 Spot VM 與 Batch API 結合，是 GCP 上對「embarrassingly parallel」工作負載（渲染農場、Monte Carlo 模擬、基因組 pipeline）槓桿最高的成本模式之一。

Spot VM 機制

• 相對隨需 (on-demand) 折扣 60–91%。
• 無 24 小時限制（不同於舊版 Preemptible）。
• 回收前有 30 秒優雅關機訊號 (ACPI G2 Soft Off)。
• 無 SLA；請以 checkpoint 設計。

Batch API

Batch 是 GCP 代管的批次排程器（2023 GA）。它接收 JSON 任務規格，佈建 Compute Engine 或 GKE 支援的執行器（包含 Spot），執行您的容器或腳本，並在完成後拆解所有資源。

# job.yaml — 渲染農場 shard
taskGroups:
  - taskSpec:
      runnables:
        - container:
            imageUri: gcr.io/my-proj/renderer:v3
            commands: ["--frame", "${BATCH_TASK_INDEX}"]
      computeResource:
        cpuMilli: 4000
        memoryMib: 16384
    taskCount: 5000
    parallelism: 200
allocationPolicy:
  instances:
    - policy:
        machineType: c3-standard-4
        provisioningModel: SPOT

為何優於自製 MIG + Spot

• Batch 替您處理任務佇列、搶占時的重試、結果彙整。
• 原生整合 Cloud Logging 與 Cloud Storage 作為輸入/輸出。
• 可與 GPU Spot（例如便宜的 A100 80GB Spot 進行 ML 訓練）混搭，無需自寫排程器膠水程式。

Cloud Run Direct VPC Egress

2024/2025 一個常被測驗的新增功能。較舊的 Cloud Run 服務若需存取私有資源（透過私有 IP 連 Cloud SQL、Memorystore、經 Interconnect 連地端），必須繞行 Serverless VPC Access connector — 一個額外的代管元件，有自己的吞吐量上限與每小時費用。

Direct VPC egress 完全移除 connector：

• Cloud Run 直接將 ENI 注入您 VPC 的子網路。
• 更高吞吐量（每執行個體最高 1 Gbps，相較於 connector 約 200 Mbps）。
• 更低延遲 — 不再多一個 NAT hop。
• 子網路 IP 規劃很重要：每個執行個體佔用一個 IP，請依「最大並行 × 執行個體數」調整子網路大小。

仍需 connector 的情境

• 跨區域 egress 至 Direct VPC 尚未支援的區域。
• 在 Direct VPC for jobs 仍在分階段推出的區域使用 Cloud Run jobs — 啟用時請查驗矩陣。

架構意涵

對 PCA 考試而言，Cloud Run 服務連線私有 Cloud SQL 的「最優」模式現在是 Direct VPC egress + Private Service Connect，不是 connector。Connector 屬於「可行」方案，但會新增一個您不再需要的維運單元。

GPU vs TPU 選型：何時該選哪一個

除了基本的 GPU/TPU 區分外，考試會測驗以下細節：

選 GPU (A3 H100、A2 A100、G2 L4) 的時機

• 框架是 PyTorch 搭配客製 CUDA kernel，且尚未移植到 XLA。
• 模型是推論導向並有嚴格延遲 SLO（G2 上的 L4 是成本/效能甜蜜點）。
• 繪圖 + ML 混合工作負載（3D 渲染、影片 AI pipeline）。
• 需要 NVIDIA 專屬函式庫（TensorRT、Triton Inference Server、RAPIDS）。

選 TPU (v5e、v5p、Trillium/v6) 的時機

• 以 JAX、TensorFlow 或 PyTorch/XLA 訓練大型 transformer 模型。
• 需要 pod 級互連（TPU v5p pod 可達 8,960 顆晶片，ICI 頻寬 4.8 TB/s）。
• 持續性訓練計畫中，每 FLOP 成本至關重要。
• TPU v5e 專門鎖定 ~70B 參數以下 LLM 的成本效率推論。

混合方案：Vertex AI 代管訓練

若題目寫「最小化維運開銷同時訓練大型模型」，答案經常是 Vertex AI custom training jobs，它抽象化了 GPU 與 TPU 的供應 — 您只需挑選加速器類型。

GCP 上的機密運算 (Confidential Computing)

Confidential VM 透過硬體記憶體加密（AMD SEV / SEV-SNP、Intel TDX）加密使用中資料 (data in use)。這對受監管的工作負載（金融、醫療、國防承包商）很重要，因為威脅模型包含「具備 hypervisor 存取權的 Google 維運人員」。

服務範圍

• Confidential VM (Compute Engine)： N2D、C2D、C3D 採 AMD SEV；C3 採 Intel TDX。透過 --confidential-compute --maintenance-policy=TERMINATE 啟用。
• Confidential GKE Nodes： 整個節點池運行於 Confidential VM 之上；無須修改程式碼即可保護 Pod 記憶體。
• Confidential Space： 強化、可遠端驗證 (attested) 的 VM 環境，用於多方資料 clean room — 兩方匯集資料，雙方（與 Google）皆無法看到對方原始資料列；僅釋出經 attestation 的工作負載輸出。
• Confidential Cloud Run / Functions： 撰文時為 roadmap 項目；目前敏感的使用中運算應放在 Confidential GKE Nodes。

取捨

• 記憶體加密帶來約 2–6 % 的效能開銷。
• 停用 live migration — 主機維護時 VM 會重啟。
• 並非所有機器家族都支援（E2 不行，M3 目前也尚未支援 SEV-SNP）。

PCA 解題框架

若情境提到**「資料必須在記憶體中加密」、「防範雲端服務商內部威脅」或「跨組織多方運算」**，最優答案是 Confidential VM／Confidential GKE Nodes／Confidential Space，而不是只用 CMEK（屬於 data at rest）或 VPC-SC（屬於 API 邊界）。

單獨租用節點 (Sole-Tenant Nodes)：授權與合規

單獨租用節點是一個專供單一客戶專案使用的實體 Compute Engine 主機 — 沒有其他租戶共享硬體。

架構師選用的原因

• 自帶授權 (BYOL)： Oracle Database、Windows Server Datacenter、SQL Server Enterprise 等綁定實體 socket 的每核心授權。
• 合規： PCI、HIPAA BAA 邊緣情境要求超越標準共享租戶證明的可驗證實體隔離。
• 親和性控制： 透過節點親和性標籤 (compute.googleapis.com/node-name) 將特定 VM 配置到特定節點。
• 可預測效能： 記憶體頻寬與 cache 不會有 noisy-neighbor 變異。

設定模型

1. 保留節點範本（機器家族，例如 n2-node-80-640）。
2. 在某個區域 (zone) 建立節點群組，可選擇啟用自動擴展。
3. 以 --node-group=<group> 或親和性標籤啟動 VM。

成本現實

單獨租用的計價等於完整節點成本加上單獨租用溢價，與您塞入多少 VM 無關。此架構僅在以下情形划算：

• 授權節省超過溢價，或
• 合規強制要求，或
• 您將節點密集打包（高 VM-to-node 比）。

與裸機解決方案的差異

不要將單獨租用節點與 Bare Metal Solution (BMS) 混淆。BMS 是針對完全無法虛擬化的工作負載（通常是 Oracle RAC、相當於 Exadata 的設備）的獨立產品。單獨租用節點仍然執行於 GCE hypervisor — 只是不與其他人共享機器。

運算資源最優解 (Optimal) vs. 可行解 (Viable) 決策摘要

FAQ — 運算選擇策略

Q1. 為什麼選擇 GKE 而非 Cloud Run？

如果您需要複雜的網路功能（如服務網格）、專用硬體 (GPU)，或者您的工作負載包含超過 Cloud Run 時間限制的長時間運行程序，請選擇 GKE。

Q2. 搶占式 VM 與 Spot VM 有什麼區別？

Spot VM 是搶占式 VM 的繼任者。它們具有同樣的低價，但沒有 24 小時的時間限制，這意味著只要有剩餘容量，它們就可以一直運行。

Q3. 我可以在 Cloud Run 上執行 Windows 嗎？

不行。Cloud Run 是基於 Linux 的。對於 Windows 特定應用，您必須使用 Compute Engine 或 App Engine Flexible。

Q4. 什麼是「冷啟動 (Cold Start)」問題？

在 Serverless（Cloud Functions/Run）中，一段時間未活動後的首個請求可能會較慢，因為 GCP 必須啟動一個新的容器執行個體。您可以透過設置 最小執行個體 (Min Instances) 來緩解此問題。

Q5. 什麼時候應該使用 App Engine？

App Engine 對於您希望 Google 處理一切的「特定規格」網頁 App 非常出色。然而，由於 Cloud Run 在容器映像檔方面的靈活性，它在很大程度上已取代了 App Engine。

最終架構師提示

「代管優於手動」。在 PCA 考試中，如果代管服務 (Cloud Run, GKE Autopilot) 能完成工作，它幾乎總是優於 IaaS 解決方案 (Compute Engine) 的「最優」選擇。除非您有明確記錄的特定限制，否則不要輕易降低架構層級。