GCP 運算服務總覽
GCP 提供五大運算服務，從完全自管的虛擬機到全託管的無伺服器平台，涵蓋了不同程度的控制力與抽象層級。作為架構師，你的核心任務是根據業務需求、團隊能力和成本限制，為每個工作負載選擇最適合的運算平台。
| 服務 | 類型 | 抽象層級 | 適用情境 |
|---|---|---|---|
| Compute Engine | IaaS | VM | 需要完整 OS 控制、自訂核心與驅動程式 |
| GKE | CaaS | 容器叢集 | 微服務架構、需要編排多容器工作負載 |
| Cloud Run | Serverless 容器 | 容器 | 無狀態 HTTP 服務或任務，免管叢集 |
| Cloud Run functions | FaaS | 函式 | 事件驅動的輕量邏輯 |
| VMware Engine | VMware-as-a-Service | VM（VMware） | 既有 VMware 工作負載原生搬遷 |
Compute Engine 深入分析
Compute Engine 是 GCP 的基礎運算服務，提供最大的彈性與控制權。架構師需要熟悉機器系列的選型邏輯：
機器系列與選型
| 系列 | 定位 | 典型場景 | 代表機型 |
|---|---|---|---|
| E2 / N2 / N4 | 一般用途（General-purpose） | Web 伺服器、中型資料庫、開發環境 | e2-standard-4、n4-standard-8 |
| C2 / C3 / C3D / C4 | 運算最佳化（Compute-optimized） | 批次處理、遊戲伺服器、科學模擬、HPC | c3-standard-22、c4-standard-48 |
| M2 / M3 / X4 | 記憶體最佳化（Memory-optimized） | SAP HANA、大型 In-memory 資料庫 | m3-megamem-128、x4-megamem-960 |
| A2 / A3 / G2 | 加速器最佳化（Accelerator-optimized） | AI/ML 訓練與推論、GPU 渲染 | a3-highgpu-8g（H100）、g2-standard-4（L4） |
| H3 | HPC 最佳化（HPC-optimized） | 高效能運算、分子動力學、天氣模擬 | h3-standard-88 |
進階配置選項
- 自訂機器類型（Custom Machine Types） — 當標準機型的 CPU/記憶體比不符需求時，可自訂配置，避免過度佈建
- Spot VM — 較搶佔式 VM 更成熟的低成本選項，最高節省 91%，適合容錯性高的批次工作負載
- Sole-tenant Nodes — 獨佔實體伺服器，滿足授權合規（如 per-core licensing）或安全隔離需求
- AI Hypercomputer — Google 最新的 AI 基礎架構，整合 TPU v5p 與 A3 GPU 機器，針對大規模 AI/ML 訓練最佳化
💡 考試小提示：看到題目提及「既有 Windows Server 授權」或「per-core licensing」，優先想到 Sole-tenant Nodes；看到「容錯」「批次」「可中斷」，優先想到 Spot VM。
GKE（Google Kubernetes Engine）
GKE 是 GCP 的託管 Kubernetes 服務，當你的應用需要容器編排、微服務治理或跨環境一致的部署模型時，GKE 是首選。
Autopilot vs Standard 模式
| 面向 | Autopilot | Standard |
|---|---|---|
| 節點管理 | Google 全託管 | 自行管理節點池 |
| 計費單位 | 按 Pod 資源請求 | 按節點 VM |
| 安全強化 | 預設啟用（如 Workload Identity） | 需自行設定 |
| 適合團隊 | 專注於應用的開發團隊 | 需要精細控制的平台團隊 |
| GPU / TPU | 支援（透過 nodeSelector） | 完全支援 |
關鍵架構決策
- Workload Identity — 將 Kubernetes Service Account 對應到 GCP IAM Service Account，取代在 Pod 中掛載金鑰的不安全做法
- 叢集網路 — VPC-native 叢集（使用 Alias IP）是建議預設，支援 Pod 層級的防火牆規則和 Private Google Access
- 多叢集策略 — 使用 Multi-cluster Ingress 或 Fleet 管理跨區域叢集，實現全球高可用
💡 考試小提示：當題目強調「可攜性（portability）」或「避免供應商鎖定」，GKE 通常是正確答案，因為 Kubernetes 是開放標準。
Cloud Run
Cloud Run 是 v6.1 考試指南中最受重視的無伺服器平台，取代了過去 App Engine 的核心地位。它讓你直接部署容器映像，無需管理伺服器或叢集。
核心特性
- 自動擴縮至零 — 無流量時不計費，有請求時自動擴展至數千個實例
- 並行處理模型（Concurrency） — 單一實例可同時處理多個請求（預設 80），不同於傳統 FaaS 的一對一模型
- 最小實例數（Min Instances） — 設定最小實例避免冷啟動，適合延遲敏感的服務
- Cloud Run Jobs — 執行批次任務或定時排程，不需要接收 HTTP 請求
適用場景
- 無狀態 REST API 與 Web 應用
- 容器化的微服務
- 事件驅動的資料處理管道（搭配 Eventarc）
- 批次處理與 ETL 任務（Cloud Run Jobs）
Cloud Run functions
Cloud Run functions（原 Cloud Functions）已全面升級為第二代（2nd gen），底層運行在 Cloud Run 基礎架構上。這代表它繼承了 Cloud Run 的所有優勢——更長的執行時間（最高 60 分鐘）、更大的實例規格和並行處理能力。
何時選 Functions vs Cloud Run？
| 面向 | Cloud Run functions | Cloud Run |
|---|---|---|
| 部署單位 | 單一函式（原始碼） | 容器映像 |
| 開發體驗 | 最簡單，只需寫函式 | 需要 Dockerfile 或 Buildpacks |
| 事件觸發 | 原生支援 Eventarc 事件 | 需額外設定 Eventarc |
| 適合 | 膠水邏輯、Webhook、輕量事件處理 | 完整的應用服務、複雜依賴 |
💡 考試小提示：v6.1 考試中提到「事件驅動」或「自動回應 Cloud Storage 上傳」，優先考慮 Cloud Run functions；但如果是「容器化的微服務」或「需要自訂 runtime」，則選 Cloud Run。
VMware Engine
Google Cloud VMware Engine 讓企業將既有 VMware 工作負載原生搬遷到 GCP，無需重構應用或變更操作工具。它提供完整的 VMware 堆疊——vSphere、vCenter、NSX-T 和 vSAN——運行在 Google 的專用硬體上。
適用情境
- 大量既有 VMware VM 需要快速上雲，但無法立即重構
- 災難復原（DR）站點——將地端 VMware 環境複製到 GCP 作為備援
- 資料中心退役（Data center exit）——合約到期後直接搬遷至雲端
💡 考試小提示：題目中出現「既有 VMware 環境」「不想重構」「lift-and-shift」等關鍵字，VMware Engine 是最佳答案。
架構選型決策框架
面對選型題目時，依序回答以下問題即可快速收斂答案：
| 決策點 | 選擇路徑 |
|---|---|
| 既有 VMware 工作負載需要原生搬遷？ | → VMware Engine |
| 需要完整 OS 存取、自訂核心或特殊硬體？ | → Compute Engine |
| 應用已容器化且需要複雜編排（多容器、服務網格）？ | → GKE |
| 無狀態容器服務，希望免管基礎設施？ | → Cloud Run |
| 輕量事件驅動邏輯，只需寫一個函式？ | → Cloud Run functions |
進一步考量維度：
- 有狀態 vs 無狀態 — 有狀態工作負載偏向 Compute Engine 或 GKE（StatefulSet）；無狀態偏向 Cloud Run
- 長時間運行 vs 事件驅動 — 長時間運行的守護程序適合 Compute Engine 或 GKE；短暫事件處理適合 Cloud Run functions
- 成本模式 — 以秒計費（Cloud Run）vs 持續運行計費（Compute Engine）vs 按 Pod 計費（GKE Autopilot）
實戰情境
情境一：傳統企業遷移
需求： 一家金融機構有 200 台地端 VMware VM，需要在 6 個月內完成上雲，且不能中斷現有營運。
建議方案： 第一階段使用 VMware Engine 進行 lift-and-shift，確保業務連續性；第二階段逐步將適合的工作負載現代化至 Cloud Run 或 GKE，實現長期成本優化。
情境二：微服務電商平台
需求： 新創電商需要快速迭代，團隊熟悉容器但不想管理 Kubernetes 叢集。
建議方案： 核心 API 服務部署在 Cloud Run（自動擴縮、按用量計費），訂單事件處理用 Cloud Run functions 串接 Pub/Sub，商品圖片 AI 標籤使用 Cloud Run Jobs 批次處理。
情境三：AI/ML 訓練平台
需求： 資料科學團隊需要大規模 GPU 運算進行模型訓練，同時有推論服務需要低延遲回應。
建議方案： 訓練工作負載使用 Compute Engine（A3 GPU 機器 + Spot VM 降低成本）或 GKE 搭配 GPU 節點池進行分散式訓練；推論服務部署到 Cloud Run（GPU 支援已上線），利用自動擴縮應對流量波動。
重點整理
- GCP 五大運算服務各有定位：Compute Engine（IaaS）→ GKE（CaaS）→ Cloud Run（Serverless 容器）→ Cloud Run functions（FaaS）→ VMware Engine（VMware-aaS）
- Cloud Run 是 v6.1 的重點無伺服器平台，取代了過去 App Engine 的考試比重
- Cloud Run functions 2nd gen 底層運行於 Cloud Run，兩者界線日益模糊
- 選型決策應從業務需求出發：先確認是否有特殊限制（VMware、OS 控制），再根據抽象層級偏好收斂
- VMware Engine 是 v6.1 新增的明確考試範圍，遇到 lift-and-shift VMware 題型必選
- AI/ML 工作負載注意 Accelerator-optimized 機器系列和 AI Hypercomputer
下一步
在下一課中，我們將探討 GCP 的儲存與資料庫服務選型，學習如何根據資料特性、存取模式和一致性需求，選擇 Cloud Storage、Cloud SQL、Cloud Spanner、Firestore 或 BigQuery。