GCP 負載平衡器怎麼選？從流量入口到 CDN 與 Armor

先問流量是什麼

同一個網站跑在好幾台 VM，或同時部署在不同區域，使用者不能自己挑一台健康的後端。負載平衡器就是那個固定入口：接住請求，再依協定、路由規則與後端狀態決定往哪裡送。

選型時，我會先問三件事：流量是 HTTP(S) 還是其他協定？入口要對網際網路開放，還是只給 VPC 內的服務使用？後端需要跨區域，還是必須留在特定區域？先回答這些，比從一長串產品名稱裡猜答案容易。

表格超出欄寬時，可左右捲動；鍵盤可聚焦表格後用左右方向鍵查看。

選好協定後，還要分 external／internal 與 global／regional。例如「內部 HTTP 微服務」不是直接選任意 ALB，而是選內部 ALB，再看後端只在一個區域，還是需要跨區域。Google 的 負載平衡器選型文件有完整產品矩陣；建立資源前，最好用它確認所選模式支不支援你的後端與功能。

舊教材可能把 ALB 寫成 HTTP(S) Load Balancer，把 Proxy NLB 寫成 TCP／SSL Proxy Load Balancer。看到舊名稱，先辨認它處理的是 HTTP 還是 TCP，以及是否代理連線，不必把每個名字當成新產品背一次。

以前常聽到「Passthrough NLB 一定是區域級」。這句現在不能照背：Google 已提供 global external passthrough NLB，截至本文更新時仍是 Preview；regional external 與 internal passthrough NLB 也都存在。若要正式採用全域模式，先確認 Preview 條款與功能限制。詳見產品總表。

ALB 的請求到底走哪裡

假設 example.com 的首頁跑在 VM，/api/* 則交給 Cloud Run。全域外部 ALB 可以給兩者同一個公開入口，使用 URL map 把請求分到不同的 backend service。

flowchart LR
  USER["使用者"] --> FR["Forwarding rule<br/>公開 IP 與連接埠"]
  FR --> PROXY["Target HTTPS proxy<br/>處理 TLS"]
  PROXY --> MAP["URL map<br/>依網域與路徑選後端"]
  MAP -->|"/api/*"| API["Backend service<br/>Serverless NEG → Cloud Run"]
  MAP -->|"其他路徑"| WEB["Backend service<br/>MIG → VM"]
  HC["Health check"] -. "檢查 VM 後端" .-> WEB

這串元件各管一件事：forwarding rule 定義入口 IP 和連接埠；target HTTPS proxy 處理用戶端的 TLS；URL map 依 Host、路徑等規則挑 backend service；backend service 再連到實際後端。要建立一個新的 ALB，通常也得從後端與路由往入口組，因為外層資源要引用已存在的內層資源。

URL map 可以把 example.com/api/* 送到 API 後端，把 /static/* 送到靜態資源後端，其餘交給預設後端。這比把三套服務各開一個公開 IP 好管理。不過規則並非只有一種寫法：簡單場景用 host／path 規則即可，進階的 header matching、流量分配則要看所選 ALB 模式的支援範圍。實作時可參考 URL map 文件與對應模式的設定指南，別把其他模式的範例指令直接混用。

全域或區域，不只是在選 IP

全域外部 ALB 使用 Anycast IP，客戶端通常會連到附近的 Google Front End（GFE）。但「先到附近的 GFE」不等於「一定送到最近的後端區域」：接下來仍要看 URL map、後端種類、健康狀態與容量設定。官方請求分配說明把這兩段分得很清楚。

若你需要在指定區域終止 TLS、後端也必須留在該區域，應評估區域外部 ALB。這有助於設計區域內的請求路徑，但法律或資料落地要求仍要逐項確認，不能只靠「regional」這個名稱保證整個系統合規。全域 ALB 可以接跨區域後端；真正要抵抗區域故障，還得把應用和資料層都部署並測試好，而不是只換一個全域入口。

後端選 VM、NEG，還是 Cloud Run？

如果網站跑在 VM，常見做法是把 Managed Instance Group（MIG）接到 backend service。MIG 管 VM 的擴縮、修復與更新；ALB 管入口和流量分配。兩者的健康檢查用途相關，但不是同一個開關：用來判斷負載平衡後端是否能收流量的健康檢查，與 MIG 自動修復設定，應分別檢查。

NEG（Network Endpoint Group）讓後端不必只是一整組 VM。Zonal NEG 可以指到 IP:Port 端點；serverless NEG 則能把 ALB 接到 Cloud Run 等無伺服器服務。Cloud Run 要跟其他後端共用 ALB 入口，或需要 ALB 的路由與防護功能時，這種接法很實用。

有兩個地方特別容易設錯：

• Serverless NEG 的 backend service 不能設定 health check，也不能把 serverless NEG 和其他 NEG 類型混在同一個 backend service。若首頁用 MIG、API 用 Cloud Run，應分成兩個 backend service，再由 URL map 選擇。
• Serverless NEG 能接哪些服務，會隨 ALB 的全域、區域、內部模式而異。設計前先核對支援矩陣與限制，不要只看「支援 Cloud Run」四個字。

VM 後端如果一直顯示不健康，除了檢查 /health 是否真的回應，也要查防火牆有沒有放行健康檢查來源、連接埠是否一致。探測來源與規則依負載平衡模式不同，請按健康檢查文件設定，不要把一張舊截圖的來源範圍套到所有情境。

TLS、CDN 與 Armor 放在哪一層

HTTPS 入口需要憑證，並由 target HTTPS proxy 使用。Google 管理的憑證可省掉自行續期的工作；若有多個網域、萬用字元憑證或憑證對應需求，可評估 Certificate Manager。憑證是否已簽發、DNS 是否指向入口 IP、憑證對應是否生效，都要在切換正式流量前確認。詳情見 Certificate Manager 與負載平衡器整合指南。

Cloud CDN 是快取，不是另一種負載平衡器。它能搭配全域外部 ALB（以及 classic 模式），但不能直接套在區域或內部 ALB。比較適合先拿不含使用者資料的圖片、CSS、JS 試：看回應的快取標頭、命中率和失效流程，再擴大範圍。Cloud CDN 文件也列出支援的入口與後端種類。

CACHE_ALL_STATIC、USE_ORIGIN_HEADERS、FORCE_CACHE_ALL 是常見快取模式。最後一種會覆蓋 origin 原本的 private 或 no-store 意圖；若把個人頁面或依登入身分變動的回應快取成共用內容，後果比「頁面沒更新」嚴重得多。除非已核對每種回應的快取鍵與資料性質，別為了提高命中率就開它。可參考快取行為說明。

Cloud Armor 則負責流量防護與安全規則。以常見的 backend security policy 為例，政策是附加在 backend service，不是直接附加在 forwarding rule。規則依優先序評估，數字小的先處理；你可以用 IP、地區、預先設定的 WAF 規則或速率限制處理不同風險。先用預覽／記錄觀察誤擋，再逐步啟用拒絕規則，通常比一口氣上線整套規則穩妥。Cloud Armor 也不只支援 ALB，實際可用政策類型與負載平衡器組合請查安全政策總覽。

一句話分工：ALB 決定請求去哪裡；CDN 回答能否直接從快取取出內容；Armor 決定請求能否通過政策。 三者各有設定與限制，不是把開關全打開就自動得到高可用或安全。

如果不是 HTTP，就別硬套 ALB

像遊戲伺服器或 VPN 需要 UDP，或後端必須直接看到封包的來源 IP，就該看 passthrough NLB。它不代理連線，後端 VM 收到的封包保留來源與目的資訊；回應也由後端直接送回客戶端。代價是 TLS 等連線處理要由後端負責，不能期待 URL map 幫你按 /api/* 分流。

純 TCP 服務若可以由入口終止連線，則可比較 proxy NLB。它建立到後端的新連線，後端看到的連線來源不會像 passthrough 一樣保留原始用戶端 IP。要選哪個，先看協定與來源 IP 需求，再確認需要的 external／internal、global／regional 模式是否提供對應功能；別用「NLB 都是區域級」或「TCP 一定選 proxy」這種口訣代替設計。

上線前，沿著請求走一次

以「全球使用者連到網站，API 在 Cloud Run，靜態資源要快取」為例，我會這樣檢查：公開入口是否需要全域外部 ALB；HTTPS 憑證和 DNS 是否已就緒；URL map 是否把 /api/* 與靜態路徑送到各自的 backend service；Cloud Run 是否透過 serverless NEG 接入；CDN 是否只快取能公開共用的內容；Armor 政策是否綁在正確的 backend service。最後再實測一個正常請求、一個預期被擋的請求，以及後端故障時的行為。

如果題目改成「後端必須讀到原始來源 IP 的 UDP 封包」，前面那套 ALB/CDN 路徑就不適用，應回到 passthrough NLB 的支援模式重新設計。選型不是記住最多產品名，而是知道哪個需求會讓前一個選擇失效。

下一課 GCP-110：VPC 進階網路設計 會接著看 Shared VPC、VPC Peering、Cloud NAT 與 Private Google Access。