Cloud Load Balancing (負載平衡)

簡介

Google Cloud Load Balancing (GCLB) 是一個完全分散式的軟體定義代管服務，部署於 Google 全球邊緣網路據點 (PoPs)。和傳統硬體式 LB 不同，GCLB 沒有設備要佈建、可自動擴展至每秒一百萬次查詢且不需事先暖機，並對全域產品提供單一全球任播 (Anycast) IPv4 或 IPv6 位址。PCNE 考生必須熟悉 2022 年的命名更新：舊名「HTTP(S) Load Balancer」現稱為 Application Load Balancer、「TCP/SSL Proxy」改稱 Proxy Network Load Balancer、舊名「Network LB」則是 Passthrough Network Load Balancer，考試會同時出現新舊名稱。本篇章節走過所有 LB 系列、後端類型 (Instance Group、Zonal NEG、Internet NEG、Hybrid NEG、Serverless NEG、Private Service Connect NEG)、通訊協定 (HTTP/1.1、HTTP/2、HTTP/3+QUIC、gRPC、TCP、UDP、ESP)，以及進階流量功能 — URL map、weighted backend services、session affinity、後端 mTLS、流量鏡射 — 這些約佔 PCNE 情境題的 20%。

全域 vs 區域 Application Load Balancer

Global External Application Load Balancer

Global External Application Load Balancer (Premium Tier) 使用 Google 全域網路與任播 IP。東京和法蘭克福的用戶都連同一個 34.x.x.x，但會在最近的 PoP 被接住，由 GFE (Google Front End) 終止 TLS，再透過 Google 骨幹送到最近的健康後端。它支援跨區域 failover、Cloud CDN 整合、Cloud Armor、Identity-Aware Proxy、Serverless NEG。Classic 變體 (--load-balancing-scheme=EXTERNAL) 用傳統 targetHttpsProxies；新版 (--load-balancing-scheme=EXTERNAL_MANAGED) 改用 Envoy proxy，解鎖進階路由 (header-based、weighted、fault injection)。

Regional External Application Load Balancer

Regional External Application Load Balancer 採用 Envoy，完全位於單一 region 內，是資料主權要求 (例如 europe-west4 下的歐盟資料法規) 不可離區時的正確選擇。它不能用 Cloud CDN、不能用全域任播 IP，預設使用 Standard Tier 網路，成本較低因為出口流量留在 region 內。

跨區域 Internal Application Load Balancer

2023 年 GA 的 Cross-region Internal Application Load Balancer 可跨多個 region，但 VIP 維持私有 (RFC1918)。它是現代化的解法，適用於 us-central1 與 europe-west1 之間需要單一內部任播 IP 的 active-active 內部微服務架構。

Network Load Balancer：直通 vs 代理

Passthrough Network Load Balancer (外部 / 內部)

Passthrough Network Load Balancer 用 Maglev 一致雜湊把封包直接送到後端 VM，不改寫 source/destination IP。後端會看到原始 client IP (不需要 X-Forwarded-For)。它是區域型，支援 TCP、UDP、ESP、GRE、ICMP，是 GCLB 中唯一支援非 TCP/UDP 通訊協定的選項。適合遊戲伺服器、SIP、IPsec gateway，或任何需要保留 source IP 的情境。健康檢查由 compute.googleapis.com 從 35.191.0.0/16 與 130.211.0.0/22 發出。

Proxy Network Load Balancer (外部 / 內部)

Proxy Network Load Balancer 在 Envoy/GFE 代理處終止 TCP，再對後端開新連線。支援 SSL offload (前身為 SSL Proxy LB)、透過 PROXY protocol v1/v2 保留 client IP、全球任播 (僅 External 變體)。適合需要 TLS 終止的非 HTTP TCP 服務，例如 TLS 後的自製 MQTT broker。

直通 vs 代理決策法則

需要保留 client IP、非 TCP 協定、極低延遲 (沒有 proxy 一跳)、或 UDP，選直通。需要 TLS offload、全球任播、或 session 感知功能，選代理。

內部 vs 外部負載平衡

外部 (External) 負載平衡器

外部 LB 對外公開可路由的公有 IP，整合 Cloud Armor、Cloud CDN、Identity-Aware Proxy。Premium Tier 走 Google 骨幹送流量；Standard Tier 從 region 邊緣走公網。

內部 (Internal) 負載平衡器

內部 LB (Internal Application LB、Internal Proxy Network LB、Internal Passthrough Network LB) 對外提供 VPC 內的 RFC1918 IP。可由同 VPC 的 VM、peered VPC (透過 --purpose=PRIVATE_SERVICE_CONNECT 或 peering 加 import/export)、Cloud VPN 客戶端、以及 Cloud Interconnect 連結的地端網路存取。內部 LB 不對外、無 Cloud Armor 邊緣整合，但新版 EXTERNAL_MANAGED 在 backend service 層支援安全政策。

Proxy-only subnet 需求

任何 Envoy-based 的區域型 LB (Regional External App LB、Regional Internal App LB、Regional Proxy Network LB) 都需要 --purpose=REGIONAL_MANAGED_PROXY 且 --role=ACTIVE 的 proxy-only subnet，大小至少 /26 (64 個位址)。漏掉這個 subnet 是建立時最常見的錯誤。

Backend Service、MIG 與加權流量分流

Backend service balancing mode

Backend service 用 balancing mode 分配負載：UTILIZATION (目標 CPU 0.0-1.0)、RATE (目標每實例或每端點的 RPS)、CONNECTION (目標並行連線數，TCP/SSL Proxy 與 Passthrough 使用)。每個 backend 都有 maxUtilization、maxRate 或 maxConnections 上限，再加上一個 0.0-1.0 的 capacityScaler 用於優雅排空流量。

Weighted backend services 做流量分流

新的 EXTERNAL_MANAGED Envoy data plane 支援在 URL map 的 routeAction.weightedBackendServices 中設定 weighted backend services。可以把 90% 流量送到 backend-v1、10% 送到 backend-v2 做 canary release，不需改 DNS。權重是 0-1000 的整數，路由內加總須為非零。

健康檢查 (Health Checks)

健康檢查是獨立資源，從 35.191.0.0/16 與 130.211.0.0/22 (傳統) 或新版代管 LB 的 Envoy data plane 發出探測。設定 --check-interval、--timeout、--healthy-threshold、--unhealthy-threshold。VPC-native GKE pod 請用 BackendConfig 自訂健康檢查路徑。

URL Map 與 Path Matcher

Host rule 與 path matcher

URL map 是 Layer-7 路由表，內含 host rule (比對 Host: header) 指向 path matcher；每個 path matcher 又有 path rule 和一個可選的預設服務。Path 比對支援 prefix (/api/*)、完全比對，以及 regex (僅 Envoy data plane)。例如：shop.example.com → path matcher shop-paths → /checkout/* 對應 checkout-service，預設對應 frontend-service。

進階路由動作

EXTERNAL_MANAGED 方案中，route rule 暴露 routeAction，可設定：

• urlRewrite — 轉送前改寫 host 或 path。
• corsPolicy — 伺服器端 CORS 處理。
• faultInjectionPolicy — 以指定百分比注入延遲或 HTTP abort (5xx)。
• retryPolicy — 自動重試 5xx、gateway-error、connect-failure。
• requestMirrorPolicy — 將流量複本送到 shadow backend (見流量鏡射章節)。
• timeout — 路由層的 timeout override (預設 backend service timeout 為 30 秒)。

Header-based 路由

Match rule 支援 headerMatches (exact、prefix、suffix、regex、range) 與 queryParameterMatches，可以用 X-Beta-User 做 A/B 測試或用 cookie 做 canary。

Session Affinity

Affinity 類型

Session affinity 把同一個 client 的請求送到同一個 backend instance。可用類型依 LB 而異：

• NONE — 純 round robin (預設)。
• CLIENT_IP — client IP 雜湊；所有 LB (含 Passthrough) 都支援。
• CLIENT_IP_PORT_PROTO — 五元組雜湊 (僅 Passthrough)。
• GENERATED_COOKIE — LB 自動產生 GCLB cookie (僅 Application LB)。
• HEADER_FIELD — 指定 HTTP header 的雜湊 (僅 Envoy data plane)。
• HTTP_COOKIE — 自訂 cookie 名稱與 TTL (僅 Envoy data plane)。

Affinity 與 balancing mode 的互動

當 backend 超過 maxRate/maxUtilization 上限，GCLB 會主動破壞 affinity 以避免過載。若希望盡量保持 affinity，降低 balancing 目標值，或用 consistentHash.minimumRingSize 鎖住 client。

Hybrid NEG 連接地端與多雲

什麼是 Hybrid NEG

Hybrid Connectivity Network Endpoint Group (--network-endpoint-type=NON_GCP_PRIVATE_IP_PORT) 讓 Google Cloud LB 指向位於地端、AWS、Azure 或另一個 Google Cloud 專案的後端，透過 Cloud VPN、Cloud Interconnect 或 Cross-Cloud Interconnect 連通。每個端點是遠端目標的 IP:port 組合。

使用情境

• 遷移：在雲端遷移期間，用全球任播 IP 包住地端資料中心。
• 多雲 failover：主要後端在 Google Cloud，failover hybrid NEG 指向 AWS ALB。
• 法規遵循：工作負載留在地端，但透過 Google 邊緣享受 DDoS 防護。

限制

Hybrid NEG 必須使用 Premium Tier 網路，可由 Global/Regional External Application LB、Internal Application LB、Proxy Network LB 系列支援，但不支援 Passthrough Network LB。Hybrid NEG 端點的健康檢查必須走 proxy-only subnet 的 egress 路徑。

Serverless NEG：Cloud Run、App Engine、Cloud Functions

Serverless NEG 結構

Serverless NEG (--network-endpoint-type=SERVERLESS) 是一種沒有端點的 NEG，由 LB 代理到 serverless 服務。設定時加上 --cloud-run-service、--cloud-run-tag、--app-engine-service、--app-engine-version 或 --cloud-function。它讓 serverless 服務也能用 Cloud Armor、Cloud CDN、Managed SSL 自訂網域和 IAP。

URL map 分流

單一 URL map 可以把 /api/* 送到 Cloud Run NEG、/legacy/* 送到 App Engine NEG、/static/* 送到 Cloud Storage backend bucket — 讓你在單一任播 IP 之後逐步換平台。

限制

Serverless NEG 僅支援 External Application LB (Global classic、Global EXTERNAL_MANAGED、Regional)，不支援 Passthrough Network LB 與 Internal Application LB (內部 App LB 要連 Cloud Run 必須改用 PSC NEG)。

Private Service Connect Endpoint 作為後端

PSC NEG 類型

兩種 PSC NEG 最常考：

• --network-endpoint-type=PRIVATE_SERVICE_CONNECT 搭配 --psc-target-service — 透過 PSC endpoint 指向已發布的服務，用於消費合作夥伴 SaaS 或另一個 VPC 的服務。
• --network-endpoint-type=GCE_VM_IP_PORTMAP — 生產者端用以暴露服務。

透過 PSC 消費 Google API

Internal Application LB 或 Internal Proxy NLB 可以掛上指向 Google 代管 API (例如 vertexai-googleapis-com) 的 PSC NEG，讓地端用戶端透過 Interconnect 連到該 API，不必走公網。

為什麼 PSC NEG 重要

PSC NEG 解決「peering 不可遞移」的痛點：hub VPC 可以把下游服務 VPC 暴露給地端用戶，而不需要打平 IP 空間。再搭配跨區域 Internal Application LB，就能蓋出一個私有的全球 API gateway。

HTTP/2、HTTP/3 / QUIC 與 gRPC

後端 HTTP/2

把 backend service 設 --protocol=HTTP2 (或明文 --protocol=H2C)，LB 對後端就會多工串流。gRPC 必要 (因為 gRPC 只跑在 HTTP/2)。對任何重視延遲的後端也建議啟用，避免 head-of-line blocking。

邊緣 HTTP/3 與 QUIC

在 target HTTPS proxy 設 --quic-override=ENABLE 啟用 HTTP/3。LB 會回應 alt-svc: h3=":443"，支援的瀏覽器 (Chrome、Edge、Firefox、Safari 16+) 會切換到 UDP/443 的 QUIC。QUIC 把交握降到 1-RTT 或 0-RTT，在行動網路丟封包時恢復更快。後端通訊協定不變，仍是 HTTPS/HTTP2 — QUIC 只在邊緣。

gRPC 路由

當 LB scheme 為 INTERNAL_SELF_MANAGED (Traffic Director) 或 EXTERNAL_MANAGED 時，URL map 支援 gRPC 風格的 serviceName 與 methodName 比對。簡單部署可以把 gRPC 當 HTTP/2，照 :path 路由就好。

後端 mTLS 與後端認證 TLS

Client 對 LB 的 mTLS

Global External Application LB 可掛上 ServerTLSPolicy 與 ClientTLSPolicy (Certificate Manager + Network Security API) 在邊緣啟用 mTLS。Client 必須提供由 trust config 簽發的憑證；LB 會將驗證過的憑證鏈透過 X-Client-Cert-* header 帶到後端。

後端認證 TLS

把 backend service 設 --protocol=HTTPS 並繫結 BackendAuthenticationConfig，要求 LB 用 Certificate Manager 的 trust config 驗證後端憑證。這是達成真正端對端 TLS 的唯一方法 — LB 不只信任後端，還會主動驗證。

使用情境

受監管工作負載 (PCI-DSS、HIPAA) 的端對端加密、每一跳都要互相驗證的 zero-trust 微服務、以及取代舊有自簽憑證 workaround 的傳統後端。

流量鏡射 (Traffic Mirroring / Shadow Traffic)

鏡射運作機制

routeAction.requestMirrorPolicy.backendService 會把請求複製一份送到 shadow backend service，原請求繼續送往主要 backend。Shadow 的回應會被丟棄，client 只收到主要 backend 的回應。可在 EXTERNAL_MANAGED Application LB 使用。

為什麼要鏡射

用真實生產流量驗證 v2 部署、不影響使用者的容量測試、安全檢視 (把複本送到 IDS backend)。

注意事項

鏡射流量會計入 backend service 配額。Body 會整份複製，留意成本與隱私 — 送到非生產環境前請先剔除 PII。

白話文解釋（Plain English Explanation）

機場航廈與全球任播 IP

把 Global External Application Load Balancer 想像成「全球機場聯合報到櫃台」。旅客（流量）不管從台北、東京還是倫敦，都打同一支電話（任播 IP）。最近的機場（PoP）接到電話後，自動把旅客分配到當地的登機門（最近的 region 後端）。Regional Application LB 則像是只服務單一機場的櫃台，再厲害也離不開那個城市。

收銀員直送 vs 服務員代送

Passthrough Network Load Balancer 像便利商店的「直送收銀員」：客人把錢和商品直接遞給店員（VM），店員看到的是客人的真實長相（原始 client IP）。Proxy Network Load Balancer 像高級餐廳的「服務員」：客人付的錢經過服務員的手再交給內場（後端只看到 LB 的 IP），但是服務員可以幫你包裝、加註、收消費稅（TLS 終止、PROXY protocol、全球任播）。

大樓的訪客識別系統

後端 mTLS 像高安全性辦公大樓的雙向識別：大門警衛要看你的證件（client 出示憑證給 LB），同時你也要看警衛的證件（LB 出示憑證給 client）；進了大樓之後，每一層樓的房門又要再刷一次卡（LB 出示憑證給後端，後端也驗證 LB）。流量鏡射就像在大樓的監視螢幕上，把所有訪客的動作同步播放到隔壁的演練室，讓新進警衛（v2 後端）練習應對真實流量，又不會干擾正式辦公。

Cloud Armor 與 Identity-Aware Proxy 整合

LB 上的 Cloud Armor

Cloud Armor 將 securityPolicy 掛到 backend service 提供邊緣 WAF、OWASP Top 10 規則、地理封鎖、用 --action=rate-based-ban 做 rate limit、以及 bot 管理。Adaptive Protection 會自動偵測 L7 DDoS pattern 並建議新增規則。Edge policy (另一種 --type=CLOUD_ARMOR_EDGE) 位置更靠近 client、在 backend 選擇之前執行 — 適合用於 IP 白名單與 cookie 過濾。

Identity-Aware Proxy

backend service 加 --iap-enabled 後，每個請求都要透過 Google Identity、OIDC 或外部身分驗證。IAP 會簽 JWT header (X-Goog-IAP-JWT-Assertion) 給後端驗證。IAP 支援於 Global External Application LB、Regional External Application LB 與 Internal Application LB。IAP + Cloud Armor + signed URL 是內部管理介面 zero-trust 的官方建議組合。

Service Extensions

Service Extensions (callouts) 讓你把自訂 gRPC 服務插進請求路徑做 header 改寫、自訂認證、或路由判斷。它跑在 Envoy 上，透過 EXTENSION_CHAIN 與 EXT_PROC 資源設定，可用於 EXTERNAL_MANAGED Application LB 與 Internal Application LB。當 URL map 不夠用、又不想自架 ingress 時，這是程式驅動路由的解。

端對端 gcloud 實作

預留全球任播 IP

執行 gcloud compute addresses create web-ip --ip-version=IPV4 --global 預留靜態任播 IPv4。雙協定堆疊就再跑一次 --ip-version=IPV6。位址掛在 forwarding rule 上不收費，閒置超過一小時開始收 idle fee。

建立 backend service 並掛 NEG

gcloud compute backend-services create web-bes --global --load-balancing-scheme=EXTERNAL_MANAGED --protocol=HTTPS --port-name=https --health-checks=https-hc --enable-cdn。再用 gcloud compute backend-services add-backend web-bes --global --network-endpoint-group=run-neg --network-endpoint-group-region=us-central1 掛上 Cloud Run Serverless NEG，地端 failover 用 hybrid NEG 再做一次。

建立加權路由的 URL map

寫一份 YAML URL map，defaultRouteAction.weightedBackendServices 包含 web-bes-v1 權重 900、web-bes-v2 權重 100，再用 gcloud compute url-maps import web-map --source=web-map.yaml --global 匯入。綁上 target HTTPS proxy 與 managed SSL 憑證，最後建立 forwarding rule，加 --load-balancing-scheme=EXTERNAL_MANAGED --ports=443 --address=web-ip。

Tier 在建立時就決定

Network Service Tier 在每個 forwarding rule 透過 --network-tier=PREMIUM 或 STANDARD 設定。Premium 提供全球任播與 Google 骨幹路由；Standard 限定單一 region 且走公網。同一 LB 內不可混用 tier — tier 套用於同 scheme 的所有 forwarding rule。

Logging、Monitoring 與配額

Cloud Logging 欄位

在 backend service 加 --enable-logging --logging-sample-rate=1.0 啟用 LB log。每筆記錄包含 httpRequest、jsonPayload.statusDetails (例如 backend_timeout、failed_to_connect_to_backend、client_disconnected_before_any_response)、以及 jsonPayload.backendTargetProjectNumber。statusDetails 是任何 5xx 案件最強的除錯訊號，常見值請務必背熟。

Cloud Monitoring 指標

loadbalancing.googleapis.com 下的關鍵指標：https/request_count、https/backend_latencies、https/request_bytes_count。和 https/backend_request_count 對比可發現路由層丟封包 (LB 收到但沒轉出去)。對 QUIC 而言，https/frontend_tcp_rtt 換成 https/frontend_quic_rtt。

必背配額

每個專案的 forwarding rule 預設 75、URL map 預設 50、backend service 預設 75、managed SSL 憑證預設 100。用 gcloud compute project-info describe --project=PROJECT --format='value(quotas)' 與 Quotas 頁面申請提升。URL map 序列化後的硬上限是 256 KB。

考試提示與常見陷阱

決策樹捷徑

• HTTPS + 全球任播 + Cloud CDN → Global External Application LB。
• TCP/UDP + 保留 client IP → Passthrough Network LB (區域)。
• TCP + TLS offload + 全球任播 → External Proxy Network LB。
• HTTPS 內部微服務 → Internal Application LB (區域或跨區域)。
• Cloud Run + Cloud Armor → Global External App LB + Serverless NEG。
• 地端後端用全球 IP → Global External App LB + Hybrid NEG。

後端通訊協定不匹配

backend service 設 --protocol=HTTP2 但後端只講 HTTP/1.1 時，LB 會回 502。backend service protocol 必須對齊後端真正講的協定。

Standard 對 Premium Tier

Standard Tier 網路強制 region 內出口、停用全球任播。考題提到「global」幾乎都暗示 Premium Tier。

常見問題 (FAQs)

Q：什麼時候選 Internal Passthrough Network LB 而不是 Internal Application LB？ A：要做非 HTTP 通訊協定的負載平衡 (資料庫、自訂 TCP、UDP DNS、IPsec)，或必須保留原始 client IP 給後端做白名單時，選 Internal Passthrough。HTTP(S) 微服務想用 URL map 路由、header 流量分流、或 Cloud Trace 整合時，選 Internal Application LB。

Q：單一 forwarding rule 可以同時處理 IPv4 與 IPv6 嗎？ A：不行。要建兩個 forwarding rule (一個 IPv4、一個 IPv6) 都指向同一個 target proxy 與 URL map。Global External Application LB 採這種方式支援雙協定堆疊；預算上要備兩個靜態外部 IP。

Q：GCLB 如何處理 WebSocket 連線？ A：Application LB 在 HTTP/1.1 (Upgrade header) 與 HTTP/2 (Extended CONNECT) 上都支援 WebSocket。長連線會受 backend service timeoutSec (預設 30 秒 — 想要一小時級別請拉到 86400) 與 proxy 的 TCP keepalive 限制。

Q：EXTERNAL 與 EXTERNAL_MANAGED 兩個 load balancing scheme 差在哪？ A：EXTERNAL 是傳統的全域 GFE-based data plane；EXTERNAL_MANAGED 是新的 Envoy-based data plane，解鎖進階路由 (weighted backend services、fault injection、header rewrite、流量鏡射) 與跨區域 Internal Application LB 拓樸。除非有 classic 才支援的功能，新部署應預設 EXTERNAL_MANAGED。

Q：Cloud Armor 能用在 Internal Application LB 嗎？ A：可以，2023 年起 Cloud Armor 透過綁在 backend service (非 edge policy) 的安全政策支援 Internal Application LB。內部流量可用 WAF、rate limit、Adaptive Protection — 對 east-west zero-trust 執行很有用。

Q：Passthrough Network LB 支援 TLS 終止嗎？ A：不支援。Passthrough 把原始封包丟給 VM，所以 TLS 在 VM 本身終止。需要在 LB 層為非 HTTP 通訊協定做 TLS offload，請改用 External Proxy Network LB。

Q：要怎麼把舊的 classic Global External HTTP(S) LB 遷到新的 EXTERNAL_MANAGED scheme？ A：用 --load-balancing-scheme=EXTERNAL_MANAGED 建一個並行的新 LB，共用同樣的 backend service，先用加權 DNS 把部分流量導到新 IP，驗證後再切換。沒有原地升級的選項，因為底層的 proxy 是不同的引擎。