Google PCNE: 負載平衡、Cloud CDN 與全球流量管理 — 學習指南

By Laurynas Brazys · 23 August 2026 · #google #PCNE #certification #exam-prep #study-guide

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

總覽

本節說明 Google Cloud Load Balancing、Cloud CDN 與全球流量管理如何協同運作，以提供具備彈性、高效能且安全的服務。內容涵蓋負載平衡器系列與選擇、代理與直通行為的比較、後端與路由元件、故障轉移與容量管理、Cloud CDN 快取與來源保護、anycast 與跨區域設計、DNS 導向與健康狀態檢查、可觀測性，以及建構穩健全球進入點的設計模式。

負載平衡器系列、選擇與資料平面行為

Google Cloud 提供外部和內部負載平衡器，各自具備不同的範圍、協定與資料平面特性。選擇合適的負載平衡器，能使其符合協定需求、地理位置及營運控制的要求。

• 外部代理 L7 (全球型)：External Application Load Balancer，適用於 HTTP(S) 與 gRPC。它會終止 TLS、強制執行 L7 政策、支援 URL 映射、Cloud CDN、Cloud Armor、請求/回應功能，以及 anycast IPv4/IPv6。最適合需要進階路由、安全性和快取功能的網際網路導向 Web API/網站。

• 外部代理 L4.5：External TCP Proxy Load Balancer (全球型) 與 External UDP Proxy Load Balancer (區域型) 會終止用戶端連線，並將流量代理至後端。當您需要全球 VIP 和 L4 功能 (例如 TLS 政策、透過標頭保留 TCP 的用戶端 IP)，但不需要 L7 路由時，可使用此類負載平衡器。

• 外部直通 L3/L4 (區域型)：External Network Load Balancer 會轉送封包而不終止連線。延遲最低且最簡單；支援 TCP/UDP/ESP/ICMP。適用於直接遷移 (lift-and-shift)、異質後端，或無法容忍代理終止的協定。傳統的 NLB 使用目標池 (target pools)；較新的區域型直通 NLB 則使用後端服務 (backend services)。

• 內部代理 (區域型)：Internal HTTP(S) Load Balancer (L7) 與 Internal TCP Proxy Load Balancer (L4.5) 在 VPC 內部終止連線並進行代理，適用於微服務的南北向流量與服務對服務 (service-to-service) 的使用情境。支援主機/路徑路由 (HTTP)、透過應用程式對用戶端進行 mTLS，以及個別服務的安全政策。

• 內部直通 (區域型)：Internal TCP/UDP Load Balancer 透過私有 RFC1918 位址將連線分發至後端，會保留用戶端 IP 並使用 MAGLEV 雜湊演算法。非常適合需要可用區感知 (zone-aware) 分發與低額外負擔的東西向服務 (例如資料庫、自訂協定)。

層級與連線終止的權衡：

• 代理 L7/4.5 提供進階路由、TLS 卸載、可觀測性、Cloud Armor/CDN 及跨區域故障轉移，但代價是會增加額外的躍點 (hop) 以及可能發生標頭/NAT 變更。它適合用於公有進入點和服務網格 (service mesh)。
• 直通 L3/L4 能端對端地保留用戶端 IP 並將延遲降到最低，但不具備 L7 功能，且可觀測性的掛鉤 (hook) 較少。其工作階段行為是基於雜湊；健康狀態檢查也較為簡單。

範圍與 IP 系列：

• 全球 anycast VIP 可用於 External Application LB 和 External TCP Proxy LB，提供可從任何地方連線的單一 IPv4/IPv6 位址。區域型 LB 則使用區域型 unicast VIP。若要為公有服務啟用 IPv6，可以透過為外部全球負載平衡器設定 IPv6 位址來達成。

選擇標準重點：

• 需要主機/路徑路由、重新導向、Cloud CDN、Cloud Armor 或 gRPC：選擇 External Application LB。
• 需要全球 TCP 但不需要 L7 功能：選擇 External TCP Proxy LB。
• 不適用於代理的協定 (例如某些舊版 UDP/TFTP)：選擇外部或內部直通型負載平衡器。
• 需要具備 HTTP 路由功能的私有服務對服務通訊：選擇 Internal HTTP(S) LB。
• 希望將 VPC 內部流量的成本/躍點數降到最低：選擇內部直通型負載平衡器。

後端服務、路由物件、健康狀態與流量黏性

核心資料平面物件：

• Backend services：定義後端 (instance groups、zonal NEG、hybrid NEG、serverless NEG)、健康狀態檢查、平衡模式、容量、工作階段親和性 (session affinity)、逾時和容錯移轉政策。Proxy LB 和較新的 passthrough LB 都需要此設定。
• Target pools：用於傳統外部 NLB 的舊版結構。適用於簡單的 TCP/UDP 分散和 lift-and-shift 期間的異質 VM。
• Named ports：執行個體群組上的鍵，將邏輯名稱 (例如 http) 對應到連接埠號碼，由後端服務和 URL map 參照。確保群組成員之間的一致性。

健康狀態檢查與容錯移轉：

• 類型：HTTP(S)、HTTP/2、gRPC、TCP、SSL。選擇能驗證實際服務就緒情況的檢查，而不僅是作業系統的可連線性。
• 範圍：健康狀態檢查是區域性的；每個後端都應有範圍設定在其服務區域的健康狀態檢查。
• 容錯移轉政策：Backend service 可以指定主要和容錯移轉後端。當主要後端不健康或容量不足時 (如果已啟用 failover-on-capacity 且達到閾值)，流量會進行容錯移轉。考慮使用 draining 和容量預留來避免「驚群效應」(thundering herd)。

URL map 與路由：

• URL map 附加到外部或內部 HTTP(S) LB，並定義主機規則和路徑匹配器。
• Default service：用於處理不符合任何規則的請求的全捕獲 (catch-all) 後端；如果未設定，則會回傳 404。
• 重新導向與重寫：使用 URL map 的動作來執行 HTTPS 重新導向、標準主機重新導向或在路由前進行路徑重寫。

範例：具有 HTTPS 重新導向和預設後端的最小 URL map

• 為 example.com 建立一個主機規則，將 HTTP 重新導向到 HTTPS，將 /static 路由到一個啟用 CDN 的後端值區，並預設路由到一個區域性後端服務。

工作階段親和性與連線排空 (draining)：

• 親和性選項取決於 LB 類型。常見選項：
  • None：最適合無狀態應用；可最大化負載分佈。
  • Client IP：在 L4/L7 上根據來源 IP 保持黏性；當多個協定 (例如 HTTP 和 TFTP) 必須共同黏性到同一個後端時使用。
  • Generated cookie (僅限 L7)：LB 設定一個 cookie 以將連線持續導向到某個後端；對於經過 NAT 的用戶端，其分佈效果比 client-IP 更好。
• 權衡取捨：親和性可能導致熱點 (hotspotting) 並使自動擴展複雜化。盡可能優先選擇無狀態架構。
• Connection draining：在縮減 (scale-in) 或移除後端時，LB 會遵循 draining 逾時設定，讓現有連線能優雅地關閉。請將 drain time 調整為您預期最長的請求時間，以防止連線重設。

容量與自動擴展：

• 平衡模式：基於使用率 (例如 CPU)、RPS 或連線數。每個後端會宣告其容量；當達到飽和時，LB 會分流或進行容錯移轉。
• Autoscaling：受控執行個體群組根據信號 (CPU、自訂指標) 進行擴展。擴展延遲 (Scale-out lag) 可能在 LB 容量耗盡時導致 503 錯誤；對於日夜流量模式，可透過設定最小副本數或使用預測性自動擴展來進行預熱。
• 容錯移轉與溢流：啟用 failover-on-capacity 並設定適當的閾值，可以實現平滑的跨區域流量溢流。

後端的安全性：

• 使用針對執行個體標籤或服務帳戶的防火牆規則來限制後端存取。僅允許來自 Google 負載平衡器和健康狀態檢查來源範圍的流量，以及在內部用戶端需要直接存取時，您核准的用戶端範圍。

範例：限制用戶端和健康狀態檢查只能存取帶有後端標籤的群組

• 用 application 標籤標記執行個體。
• 建立一個傳入允許規則，允許來自您的用戶端 CIDR 和 Google 健康狀態檢查範圍的 tcp:80 流量，並以 application 標籤為目標。
• 建議採用預設拒絕 (deny-by-default) 策略，以便在日誌中呈現被丟棄的流量。

Cloud CDN、快取政策與來源保護

Cloud CDN 與外部 Application Load Balancer 整合，在邊緣 POP 快取回應，藉此降低延遲並減輕來源伺服器的容量負擔。

快取模式與 TTL：

• 使用來源標頭 (Use origin headers)：遵循您來源伺服器的 Cache-Control 和 Expires 標頭。為求正確性，此為建議選項。
• 強制快取 (Force cache)：使用設定的預設 TTL 快取所有回應，可選擇性地覆寫或忽略靜態內容的來源標頭。請謹慎使用，以避免快取到動態資料。
• 略過快取 (Bypass cache)：適用於絕不可快取路徑。

快取金鑰：

• 金鑰欄位包含通訊協定、主機、路徑、查詢參數、標頭和 Cookie。可根據需求設定查詢字串政策 (全部包含、包含選定項目或忽略)、選擇性地包含標頭和 Cookie，以及裝置區隔。
• 保持金鑰最小化以最大化命中率；僅根據會改變內容呈現的欄位進行變化。

已簽署的要求：

• 已簽署的網址 (Signed URLs)：附加帶有到期時間和路徑範圍的 HMAC 或 RSA 簽章，以授予對特定資源的限時存取權限。適用於將 CDN 作為加速器並進行個別物件授權的場景。
• 已簽署的 Cookie (Signed cookies)：使用 Cookie 授權一組路徑；適用於整個網站的門禁內容 (gated content)。
• 輪替金鑰並強制執行短效期，以降低重放攻擊的風險。

壓縮與正確性：

• 即使請求中包含 Via 標頭，來源伺服器也必須進行壓縮。如果 CDN 提供未壓縮的物件，而來源伺服器「支援壓縮」，請確認來源伺服器已設定為在存在 Via 標頭時進行壓縮。

來源伺服器安全性：

• 從邊緣代理伺服器到來源伺服器應使用 HTTPS，並搭配現代化的 TLS 政策。
• 限制來源伺服器的可達性：後端防火牆規則應只允許來自 Google 負載平衡器、健康檢查來源範圍以及已知私有生產者的流量。後端執行個體不應接受任意的公開傳入流量。
• 搭配 Cloud Armor 以進行 L7 DDoS/WAF、速率限制和威脅偵測。對新規則使用預覽模式，以減少誤判。
• 當您必須在 TTL 到期前清除內容時，請使用快取失效 API 來刻意使內容失效。對於動態內容，建議使用較短的 TTL 並搭配重新驗證 (ETag/If-None-Match)。

故障模式與權衡取捨：

• 過於寬鬆的快取金鑰會浪費快取空間並降低命中率；過於狹窄的金鑰則有提供錯誤版本的風險。
• 強制快取動態資料可能導致個人化內容外洩。
• 已簽署的網址/Cookie 在邊緣提供存取保護，但仍必須透過網路政策拒絕直接存取來源伺服器的行為。

全球流量管理、DNS 導向、可觀測性與彈性進入點

Anycast 前門與跨區域容錯移轉：

• External Application LB 和 external TCP Proxy LB 使用全球 anycast VIP，將用戶端吸引到最近的 Google 邊緣。流量接著會被代理到最健康且最近、尚有容量的後端。設定多個後端區域，並搭配一致的健康狀態檢查與容量設定，以實現無縫的容錯移轉與溢流。
• 在次要區域預先佈建容量，以避免冷啟動懲罰；將自動擴展器的最小/最大值與 LB 的容量閾值進行協調。

區域性內部流量管理：

• Internal HTTP(S) LB 和 internal passthrough LB 是區域性的；設計時應考慮區域內的多可用區多樣性，並在需要時，使用具備 Private Service Connect 的獨立 LB 或服務感知客戶端來選擇區域性端點，以實現多區域部署。
• 將相互通訊的服務放置在同一個區域和 VPC 中，以保持東西向的低延遲。使用 RFC1918 位址搭配單一 VPC 或對等的 VPC，以達到最低成本與操作簡易性。

Cloud DNS 路由政策與健康狀態檢查：

• 政策：加權循環 (Weighted round robin，用於流量分割)、地理位置 (geolocation，將使用者傳送到最近的區域性 VIP) 與容錯移轉 (failover，主要/備用)。結合多種政策以滿足業務規則。
• 健康狀態檢查：將 DNS 健康狀態檢查 (HTTP/HTTPS/TCP) 附加到用於導向的 A/AAAA 記錄上，以便將不健康的端點撤下。需考慮解析器快取 (TTL) 會延遲反應時間；在被導向的記錄上保持較低的 TTL，以提高容錯移轉的反應速度，但代價是會增加 DNS 查詢次數。
• 流量導向：使用加權政策來分階段遷移或在區域之間轉移負載。除非使用分割域 DNS (split-horizon DNS)，否則應避免從網際網路導向至私有位址。

可觀測性與診斷：

• 負載平衡器日誌記錄：為所有 LB 啟用日誌記錄。HTTP(S) 日誌包含請求方法/URI、延遲、快取命中/未命中、後端服務、URL 映射規則、TLS 詳細資訊與回應碼。TCP/UDP 日誌提供連線元資料與健康探測狀態。
• 指標：監控後端健康狀態、使用率、RPS、連線數、延遲、快取命中率、4xx/5xx 錯誤率與容量飽和度。針對突然變化與持續超過閾值的情況發出警報。
• 常見的 HTTP(S) 錯誤模式：
  • 404：沒有匹配的 URL 映射；請確認主機/路徑規則與預設服務。
  • 301/302：刻意的重新導向；請檢查是否有重新導向迴圈。
  • 502：後端連線或協定不匹配 (例如 HTTP/1.1 vs gRPC)；請檢查健康狀態與後端協定設定。
  • 503：沒有健康的後端或後端沒有容量；請檢查健康狀態檢查、配額與自動擴展器行為。
• 請求追蹤：使用 X-Forwarded-For、X-Forwarded-Proto，以及由您的應用程式傳播的追蹤 ID。使用請求 ID 將 LB 日誌與後端日誌相互關聯。
• 防火牆洞察：在允許和拒絕規則上啟用 VPC 防火牆日誌記錄。若要明確記錄被捨棄的封包，請新增一條啟用日誌記錄的低優先權全部拒絕規則。

彈性的全球進入點設計：

• 在一個 external Application LB 上使用單一全球 anycast VIP，並將其前端指向多個區域性後端。將無伺服器/VM/容器後端放置在至少兩個區域。啟用跨區域容錯移轉與溢流，設定保守的健康狀態檢查，並為您的工作負載調整耗盡 (draining) 與逾時設定。
• 使用 Cloud Armor 和配額限制政策來保護進入點。使用 Cloud CDN 提供靜態和可快取的動態內容，以在邊緣吸收流量突波。
• 在全球 LB 上公開雙協定堆疊 IPv4/IPv6，以服務所有網路。對於嚴格的用戶端存取，請套用具有精確來源範圍和執行個體標籤或服務帳戶的後端防火牆規則。

範例：限制用戶端與健康狀態檢查範圍至具備標籤的後端之防火牆規則

• 為執行個體加上 application 標籤。
• 建立一條傳入允許規則，允許來自 source-ranges=203.0.113.0/24,198.51.100.0/24 和 Google 健康狀態檢查範圍的 tcp:443 流量，並以 application 為目標。
• 確保存在一條啟用日誌記錄的較低優先權全部拒絕規則，以捕捉非預期的來源。

實務問題情境

Acme Retail 推出一個全球電子商務平台，需要在 us-east1 和 europe-west1 之間實現低延遲、強大的安全性與透明的容錯移轉，同時高效率地提供靜態媒體。只有公司辦公室與合作夥伴 CDN 的預備網路才能存取私人的管理介面。

1. 前門與後端

• 建立一個 external Application Load Balancer，具備雙協定堆疊 anycast VIP，並為公開的商店主機名稱設定 TLS 憑證。
• 定義兩個後端服務，各自指向位於 us-east1 和 europe-west1 的區域性託管執行個體群組 (MIG)。啟用健康狀態檢查 (HTTPS)，並將平衡模式設為使用率 (utilization)，容量閾值為 80%。理由：Anycast 加上多區域後端可確保使用者連線到最近的邊緣，並在某個區域不健康或飽和時無縫地進行容錯移轉。

2. URL 映射、路由與重新導向

• 設定一個 URL 映射，包含公開商店和私人管理員主機名稱的主機規則。將 /static 路由到一個已啟用 Cloud CDN 的後端值區；將 /api 和 / 路由到 VM 後端。新增一個 HTTP-to-HTTPS 的重新導向。理由：主機/路徑路由將靜態與動態流量分開，並強制執行安全存取。

3. Cloud CDN 政策

• 對於 /static 的後端值區，將快取模式設定為使用來源標頭 (use origin headers)，並定義一個忽略非功能性查詢參數且僅包含 Accept-Encoding 標頭的快取金鑰。為常見的 404 錯誤啟用負向快取 (negative caching)，並設定較短的 TTL。理由：尊重內容的語意，最大化命中率，並避免快取到不正確的變體。

4. 工作階段親和性與耗盡

• 為公開商店設定產生 cookie 的親和性 (generated-cookie affinity)，靜態資產則不設定；將連線耗盡 (connection draining) 時間設為 60 秒。理由：Cookie 能保持購物車工作階段的穩定，同時允許廣泛的分散；耗盡則可在縮減規模或容錯移轉期間防止使用者看到錯誤。

5. 跨區域容錯移轉與自動擴展

• 啟用容量容錯移轉 (failover-on-capacity)，溢流閾值為 90%，以將超額流量轉移到另一個區域。設定 MIG 自動擴展，每個區域的最小副本數為 4，並讓 CPU 目標與 LB 的使用率目標相符。理由：避免容量懸崖，並協調 LB 與自動擴展器的決策，以實現平滑的擴展。

6. 管理介面限制

• 為私人管理員主機名稱建立一個 internal HTTP(S) Load Balancer，使其只能在 VPC 內部存取。發布分割域 Cloud DNS (split-horizon Cloud DNS)，讓內部用戶端解析到 ILB 的 VIP，而外部用戶端則收到 NXDOMAIN。理由：在不暴露公開端點的情況下，保持管理流量的私密性與可控性。

7. 後端防火牆與來源安全性

• 為管理和網站後端加上 application 標籤，並新增一條允許規則，允許來自公司與預備環境 CIDR 以及 Google 負載平衡器和健康狀態檢查來源範圍的 tcp:443 流量；在較低優先權處新增一條啟用日誌記錄的全部拒絕規則。理由：確保只有預期的用戶端和 Google 基礎設施可以連線到後端，並提供捨棄流量的可見性。

8. Cloud Armor

• 套用一個安全政策，包含託管 WAF 規則，並對 /api 的突發流量設定一個預覽模式的速率限制。理由：L7 保護和分階段實施可在調整期間降低風險。

9. Cloud DNS 導向與健康狀態檢查

• 為公開商店主機名稱發布指向 ALB anycast VIP 的 A 和 AAAA 記錄。為了進行藍/綠金絲雀部署，在指定的金絲雀主機名稱上建立一個加權政策，將 5% 的流量分割到僅限 europe-west1 的 ALB，95% 則導向全球部署。附加 HTTPS 健康狀態檢查，以便在金絲雀部署不健康時將其撤下，並將 TTL 設為 20 秒。理由：基於 DNS 的金絲雀部署能實現漸進式曝光，並具備健康感知移除與快速收斂的能力。

10. 可觀測性

• 啟用 LB 和 CDN 日誌；將其匯出至 BigQuery 進行分析。針對 5xx 錯誤率、後端容量、健康狀態檢查失敗和 CDN 命中率設定警報。使用 URL 映射測試和請求日誌來診斷路由錯誤；檢查 502/503 錯誤的突增，以判斷後端是否飽和或協定不匹配。理由：主動監控和快速診斷可最小化 MTTR (平均修復時間) 並維護使用者體驗。

← 混合式連線、Cloud Router 與 BGP · 所有領域 · Cloud DNS、服務探索與混合式名稱解析 →

練習這些題目 → · 在 ExamRoll.io 上限時練習 →

瀏覽 Google →