Google PCA: 運算、應用程式平台與工作負載架構 — 學習指南

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

屬於 Google Professional Cloud Architect — 學習指南. 使用經過驗證的解答練習： Google 考試中心, 或參加限時模擬考試： ExamRoll.io.

總覽

此領域涵蓋如何在 Google Cloud 上選擇與設計運算平台、如何封裝與部署應用程式，以及如何營運工作負載以達到可靠性、效能、安全性與成本效益。其範圍橫跨虛擬機器、Kubernetes、無伺服器執行環境、負載平衡、部署策略、有狀態與特殊運算，以及在滿足不斷變化的需求的同時，減少技術債的現代化模式。

Compute Engine 與以 VM 為基礎的架構

Compute Engine 提供對作業系統、網路與機器規格的精細控制。根據工作負載的特性選擇機器系列：

E2：成本最佳化的一般用途；適合開發/測試、具備突發流量的應用程式。
N2/N2D：為多數生產環境工作負載提供平衡的價格/效能；N2D 使用具備強大記憶體頻寬的 AMD CPU。
C2/C2D/C3：運算最佳化，適用於受 CPU 限制的任務 (例如，高 QPS 的 API、批次運算)。
M3：記憶體最佳化，適用於大型記憶體內資料集 (快取、記憶體內分析)。
A3：GPU 最佳化 (NVIDIA)，適用於訓練/推論；也可將 GPU 掛載至其他系列。
Confidential VMs (在支援的 CPU 上) 以最少的程式碼變更來加密使用中的資料。

Managed instance groups (MIGs) 帶來彈性與韌性：

使用 Instance Templates 進行不可變的設定，並透過 MIGs 跨可用區進行水平擴展。
自動擴展政策：CPU、負載平衡器使用率、Cloud Monitoring 指標，或透過自訂指標監控佇列深度。設定最小/最大副本數與冷卻時間，以避免在突發負載下發生資源抖動 (thrash)。
滾動式更新與金絲雀部署可降低風險；對於有狀態或冷啟動負擔較重的服務，請將 surge (突增) 與 unavailable (不可用) 的設定保持保守。

負載平衡與健康狀態檢查：

Global external HTTP(S) load balancer 會終止 TLS、支援 URL 映射，是 Web API 的標準前端；internal HTTP(S) LB 則用於東西向流量。
健康狀態檢查必須能觸及後端。一個常見的失敗原因是探測被阻擋，導致執行個體不斷重啟並造成流量遺失。使用 VPC 防火牆規則與目標標籤，允許健康狀態檢查的來源範圍存取後端通訊埠。

允許 HTTP 健康狀態檢查存取 MIG 的範例：

gcloud compute firewall-rules create allow-lb-health-checks –network=my-net –direction=INGRESS –action=ALLOW –rules=tcp:80 –source-ranges=35.191.0.0/16,130.211.0.0/22 –target-tags=web-backend

VM 生命週期考量：

使用啟動指令碼或映像檔中繼資料來進行啟動程序；將執行階段的設定儲存在 Secret Manager 中，而非寫死在映像檔裡。
對於 preemptible/Spot VM，新增一個 shutdown-script，以便在收到終止通知時將工作處理完畢 (drain)。
透過預先製作好的映像檔與滾動式替換來進行修補，以避免設定偏移。
Persistent disk 的大小調整是線上操作：增加磁碟大小，然後擴展檔案系統 (例如，在 ext4 上使用 resize2fs)，只需極短的停機時間。

PD 大小調整範例：

gcloud compute disks resize my-disk –size=500GB –zone=us-central1-a
sudo resize2fs /dev/sdb

安全的身分識別與可觀測性：

將最小權限的服務帳戶附加到執行個體上；不要嵌入靜態憑證。
安裝 Ops Agent 以使用 Cloud Logging 與 Cloud Monitoring。使用 Cloud Trace 與 Cloud Profiler 來減少長尾延遲與熱點。
將稽核與指標資料匯出至 BigQuery 或 Cloud Storage 以進行長期保留與分析。

批次與特殊運算：

使用 Cloud Batch 或搭配 preemptible VM 的 MIGs 來執行容錯的批次處理以降低成本；並實作檢查點 (checkpointing)。
在需要 ML 加速的地方掛載 GPUs/TPUs。使用專用節點池或 sole-tenant nodes 來滿足合規性/隔離性的要求。
Confidential VMs 保護記憶體中敏感的資料；需評估其額外開銷與需求的權衡。

狀態考量：

保持應用程式執行個體為無狀態；將 session 外部化至共享儲存區 (例如 Memorystore、Cloud SQL)，以避免在擴展時發生使用者可見的異常情況。
對於綁定在 VM 上的狀態，使用 regional persistent disks 或複製的資料庫；並測試故障轉移路徑。

Kubernetes 與容器平台 (GKE)

GKE 提供一個受託管的控制平面，並搭配具備彈性的工作節點池：

區域叢集會將控制平面與節點複製到多個可用區以實現高可用性；可用區叢集則將資源集中，以降低成本並應對延遲敏感的應用。
使用多個節點池來區隔工作負載 (例如：通用型、GPU、高記憶體、Spot)。應用污點 (taints)/容忍 (tolerations) 和親和性 (affinity)/反親和性 (anti-affinity) 來控制 Pod 的放置位置，並減少吵雜鄰居效應。
自動擴展層級：叢集自動擴展器會新增/移除節點；Horizontal Pod Autoscaler (HPA) 根據 CPU/自訂指標來擴展副本數量；Vertical Pod Autoscaler (VPA) 則負責調整請求的大小。結合 HPA 與叢集自動擴展器以獲得彈性。

工作負載排程與服務：

適當調整 CPU/記憶體的請求 (requests)/限制 (limits)，以最小化驅逐風險並最大化裝箱效率。
在升級期間使用 PodDisruptionBudgets 來維持可用性。
Service 類型：ClusterIP (叢集內部)、NodePort/LoadBalancer (南北向流量)，以及用於 HTTP(S) 路由並搭配全域 LB 的 Ingress。對於金絲雀部署，可透過獨立的 Services/Ingress 後端或服務網格來引導流量。

升級與韌性：

使用激增升級 (surge upgrades) 和 maxUnavailable 來控制變動；將關鍵工作負載固定到多個可用區和節點池。
為業務關鍵時期設定維護期間/排除時段。
在進行大規模推出前，先使用預先生產環境和金絲雀節點池進行驗證。

映像檔與安全性：

將容器映像檔儲存在 Artifact Registry 中；啟用漏洞掃描，並設定二進位授權 (binary authorization) 或證明 (attestations) 以確保來源可靠性。
使用 Workload Identity 將 GSA 映射到 KSA，以實現對 Google API 的無憑證、最小權限存取。
透過 CSI 驅動程式從 Secret Manager 提取執行階段組態；除非使用 CMEK 加密且 RBAC 權限控管嚴格，否則應避免使用 Kubernetes Secrets 儲存高度敏感的值。

推出與回滾：

建議採用 Deployment 滾動更新，並搭配小步推進和健康探測；對於低容錯的系統，可使用藍綠部署，即在單一 Service 後方部署兩個 Deployments，再切換標籤/選擇器。
務必定義就緒探測 (readiness) 和存活探測 (liveness)；設定不當的探測會在推出期間導致連鎖重啟或流量黑洞。

無伺服器與事件驅動平台

Google Cloud 的無伺服器平台將基礎架構抽象化，同時在規模、安全性與成本方面提供強大的控制能力：

Cloud Run：容器原生，由 HTTP 請求或 Eventarc 觸發。可擴展至零；可設定的並行處理；依修訂版本進行流量分割，以實現金絲雀部署和回滾。設定最小執行個體數以減少延遲敏感端點的冷啟動時間。透過 Serverless VPC Access 與 VPC 整合，以實現私有輸出流量。
App Engine：特定框架的 PaaS。標準環境 (Standard) 提供快速擴展能力，並可依語言設定每個請求的並行處理限制；彈性環境 (Flexible) 在 VM 上執行容器，提供更多控制權。避免使用執行個體本地的會話狀態；應將其外部化至共享儲存，以防止在高負載下出現過時或重複的使用者體驗。
Cloud Functions：用於事件驅動邏輯的函式層級粒度。使用 Pub/Sub、Cloud Storage 或 Eventarc 觸發器來執行輕量級的微型操作；保持函式冪等且無狀態。對於沒有現成程式碼的批次/串流混合管線，Dataflow 提供具備自動擴展能力的統一處理方案。

平台選擇的權衡取捨：

維運控制權：Compute Engine > GKE > Cloud Run/App Engine > Cloud Functions。
可攜性：容器型 (GKE/Cloud Run/App Engine Flex) > VM 映像檔 > 函式與 App Engine 標準環境。
延遲：對於低長尾延遲需求，可選用設定了最小執行個體的 Cloud Run 或 GKE；避免讓互動式工作負載遇到冷啟動。
擴展速度：Cloud Functions/Run 擴展最快；其次是 GKE HPA 加上叢集自動擴展器；MIGs 則需要預熱和健康檢查。
成本：無伺服器採按用量計費，適合流量有尖峰或穩定狀態流量低的應用；GKE/VMs 搭配承諾使用折扣，適合穩定、高吞吐量的服務；可搶佔/Spot 則適合批次處理。

身分識別與組態設定：

每個服務都應使用具備最小權限的專用服務帳戶。對於 Cloud Run 和 Cloud Functions，應明確設定其執行階段服務帳戶。
將密鑰儲存在 Secret Manager 中，並透過 IAM 綁定存取權限；可透過環境變數或磁碟區掛載的方式注入。

架構模式、交付與維運

服務拆解與邊界：

單體式 (Monolith)：最簡單的部署與交易處理方式，但限制了獨立擴展與爆炸半徑 (blast-radius) 的控制；可能會隱藏呼叫鏈深處的效能問題。
模組化單體 (Modular monolith)：內部模組清晰，共享同一個處理程序；是個良好的過渡步驟——在沒有分散式系統的負擔下強制執行介面。
微服務 (Microservices)：可獨立部署與擴展；但引入了網路延遲、分散式交易與一致性的挑戰。需定義清楚的限界上下文 (bounded contexts) 與資料所有權；避免共享資料庫以防耦合。

現代化模式：

絞殺榕模式 (Strangler-fig)：逐步將部分流量路由到新元件，並逐漸淘汰舊的端點。
直接遷移 (Lift and shift)：先透過容器化或虛擬機遷移來穩定系統，然後再進行重構。
防腐層/外觀模式 (Anti-corruption layer/facade)：在建構新服務的同時，隔離舊有的合約 (contract)。
優先處理高變動、高摩擦的領域，以最大化商業價值並降低風險。

交付與推出：

具備自動化測試和分階段環境的 CI/CD 可減少回滾。加入金絲雀分析、錯誤預算和漸進式交付。
藍綠部署 (Blue-green) 以雙倍容量為代價，最小化停機時間並簡化回滾。
流量分割 (Traffic splitting)：Cloud Run/App Engine 支援跨修訂版本/版本的百分比路由；在嚴格的 SLO 錯誤預算下，用真實流量進行測試。

負載平衡與健康狀態：

對 HTTP 使用全域 L7，對非 HTTP 協定使用 TCP 代理；對私有服務使用內部負載平衡器。僅在必要時設定工作階段綁定 (session affinity)，並將會話狀態外部化。
健康檢查應反映應用程式的可用性（例如，依賴項的健康狀態）；一個簡單的 200 OK 回應若隱藏了資料儲存庫的故障，可能導致錯誤的流量導向。

可觀測性與治理：

埋設追蹤 (trace) 以分析跨服務的端到端延遲；啟用請求 ID (request ID) 的日誌記錄，以關聯日誌與追蹤。
將日誌/指標/稽核軌跡匯出到 BigQuery 或 Cloud Storage 以滿足保留和稽核需求；透過視圖 (view) 和 IAM 保護存取權限。
對於 VM 日誌，安裝 Ops Agent；定義保留政策和匯出槽 (sink) 以控制成本和合規性。

安全軟體供應鏈：

使用具備掃描功能的 Artifact Registry；保持映像檔最小化。優化 Dockerfile：優先使用 slim 基礎映像檔，先安裝依賴項，然後再複製原始碼以利用建置快取。

網路與分段：

透過 VPC 防火牆標籤和規則強制執行分層存取，僅允許預期的流量（例如，web → API → DB）。拒絕 web → DB 的直接存取。

容量、效能與特殊運算

為變動需求設計：

GCE：根據前導指標（例如佇列長度）自動擴展 MIGs，以避免 CPU 飽和；加入請求速率限制與背壓機制來保護下游服務。
GKE：結合基於每秒請求數或自訂指標的 HPA 與叢集自動擴展器；預留少量緩衝區以避免擴展延遲。
Serverless：調整並行處理數量與最小執行個體數，以在成本與延遲之間取得平衡；使用區域性部署以降低使用者端的延遲。

彈性與測試：

執行綜合負載測試以驗證自動擴展與 SLOs；納入混沌測試（例如，隨機終止執行個體/pod），確保系統在故障與升級期間仍能維持可用性。
設定 PodDisruptionBudgets 與優雅終止的掛鉤，以在 pod/VM 關閉前將連線排空。

效能與儲存選擇：

高吞吐量、低延遲的時間序列與點擊流資料擷取非常適合使用 Bigtable；設計寬資料列與時間分桶的鍵值以避免熱點。
對於希望營運變動最小的 Spark/Hadoop，可使用 Dataproc；透過自動擴展來適當調整叢集規模。
對於沒有現成程式碼，且需結合每小時批次處理與串流處理的場景，可使用 Dataflow，並透過自動擴展與視窗化來統一管線。

資料移動與連線能力：

對於持續性、高頻寬的私有複製（例如，數 TB 的資料庫），可考慮使用 Dedicated Interconnect；使用 VLAN attachments 與 Cloud Router 進行動態路由。對於臨時性或較低吞吐量的需求，Cloud VPN 已足夠。

有狀態的工作負載：

在 GKE 上，使用 StatefulSets 搭配永久性磁碟區（使用 regional PDs 實現 HA）以及有序且穩定的身份識別；若需 NFS 語意，可考慮使用 Filestore。
盡可能使用託管式資料庫（Cloud SQL, AlloyDB, Spanner）以確保耐用性與擴展性；規劃讀取複本與故障轉移。

安全性與合規性：

考慮使用 Confidential VMs 來保護使用中的資料，其效能開銷有限；根據工作負載的需求進行評估。
在金鑰必須由客戶控制的情況下，使用 CMEK；強制執行每個環境的隔離，並為開發/測試/生產環境使用獨立的專案。

成本控制：

對於穩定狀態的運算，使用承諾使用與持續使用折扣；對於容錯的批次處理，使用 preemptible/Spot 執行個體；在 serverless 上，自動擴展至零。
根據 Monitoring 的建議來適當調整資源規模；移除閒置的服務，並設定基於日誌的指標配額，以避免意外的成本。

延遲問題的疑難排解：

使用 Cloud Trace 來找出造成最大延遲的微服務；優化該服務的程式碼路徑、快取或資料庫索引。透過 A/B 金絲雀部署來驗證改善成效。

實際問題情境

FerroLine Logistics 計劃將一個處理貨物追蹤與客戶通知的 J2EE 單體應用進行現代化改造。該工作負載在區域結單期間會出現突發流量，必須達到 99.9% 的可用性目標，且團隊希望在引入事件驅動功能的同時，能有高可攜性並將營運負擔降至最低。

穩定並觀察現有系統

理由：在進行變更前，先建立行為與錯誤的基準線，以降低回滾風險。在現有 VM 上部署 Ops Agent 以使用 Cloud Logging 和 Monitoring，並在高延遲的請求路徑中埋入分散式追蹤。將日誌與指標匯出至 BigQuery，以進行歷史分析與 SLO 報告。

選擇分階段的落地環境與平台組合

理由：在控制權與開發速度之間取得平衡。將單體應用以容器形式遷移，批次處理元件使用 Cloud Run jobs，無狀態的 HTTP API 使用 Cloud Run services，並為對延遲敏感的端點設定最小執行個體數。初期將有狀態的 Oracle DB 保留在 Compute Engine 上，並由一個 regional internal HTTP(S) LB 作為內部 API 的前端，未來再規劃遷移至 AlloyDB。

將會話與組態狀態外部化

理由：避免執行個體本地的會話問題，並實現安全的自動擴展。將密鑰儲存在 Secret Manager 中，並為每個服務使用獨立的服務帳戶以實現最小權限存取。將會話狀態移至 Memorystore，共享檔案移至 Cloud Storage。這可以防止使用者在尖峰負載下看到過時的資料。

建立身份識別與註冊中心控管機制

理由：強制執行最小權限與來源追溯。將映像檔儲存在已啟用弱點掃描的 Artifact Registry 中。為每個 Cloud Run service 與 GKE 工作負載（用於後續分解的元件）指派一個唯一的執行階段服務帳戶，並僅授予必要的角色（例如，Pub/Sub Publisher）。

實作具備安全推出策略的 CI/CD

理由：減少非預期的回滾。建立一個執行單元/整合測試並部署到預備環境的管線。使用 Cloud Run 的流量分割功能，將 5-10% 的流量以金絲雀方式導向新版本，並實現快速回滾。對於基於 VM 的資料庫變更，使用藍綠部署的 schema 遷移模式，以解耦應用程式與資料庫的部署。

優先分解高變動性的領域

理由：以較低風險實現漸進式價值。應用絞殺者模式：將通知發送功能切割出來，成為一個部署在 GKE 上的微服務，以利用 HPA 處理流量高峰，並使用 Pub/Sub 進行解耦。在介面穩定之前，將剩餘的單體應用作為一個模組化的單體應用保留在 Cloud Run 上。

設計自動擴展與負載卸除

理由：處理突發流量而不會引發連鎖故障。設定每個端點的 Cloud Run 並行處理數量與最小執行個體數；在 global HTTP(S) LB 上設定 Cloud Armor 速率限制，以防禦未經身份驗證的流量激增。對於 GKE 服務，啟用基於自訂指標（每秒請求數）的 HPA，並透過叢集自動擴展器預留一個小的節點緩衝區。

準備有狀態服務與資料路徑

理由：確保耐用性與效能。對於 GKE 的通知重試機制，使用一個以客戶區域和時間分桶為鍵值的 Bigtable 資料表，以高寫入速率儲存暫時的傳送狀態。在過渡期間，為了與地端 ERP 建立私有且一致的連線，使用 Dedicated Interconnect 搭配 Cloud Router。

執行彈性與效能測試

理由：在完全切換前驗證 SLOs。執行綜合性、隨機化的使用者流程，以觸發各層的自動擴展。透過終止隨機的 Cloud Run 執行個體（讓控制平面重新建立）與驅逐 GKE pod 來注入混沌，以驗證 PodDisruptionBudgets 與 readiness gates。使用 Trace 找出造成長尾延遲的最大因素並進行修復。