PCA 雲端架構師之旅 10 — 網路拓樸

上一篇選了負載平衡器，現在要把它放回整張網路圖裡。Region 和 Zone 在哪、VPC 與 Subnet 怎麼分、請求從 DNS 進來後如何抵達後端，都要能沿著線走一遍。

一張有用的拓樸圖，應該讓讀圖的人能指出流量入口、網路邊界與故障範圍。如果線畫得通，後面才方便討論可靠性和安全控制。

這是 13 步驟 PCA 雲端架構師之旅 的第十站。

拓樸圖要能回答「流量怎麼走」

網路圖如果只畫出服務名稱，卻說不清楚流量怎麼走，就很難拿它來檢查設計。

試著從 DNS 查詢開始，沿著一次 request 走到資料回傳給使用者：每一跳經過哪個元件？為什麼要經過它？如果圖上回答不了這些問題，就還有路徑沒想清楚。

例如畫到前端呼叫後端時，停下來確認它走內部位址、負載平衡器，還是公開入口。平時先把路徑走過一遍，考試遇到拓樸題也比較容易看出多繞或漏接的一段。

畫圖前，先釐清網路範圍

Google Cloud 的 VPC、subnet 與運算資源分屬不同範圍。先把六個常用元件放在同一張表裡，畫圖時比較不會把它們畫錯層：

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

畫圖時，最容易搞混的是 VPC 與 subnet 的範圍。

VPC 是全域資源，可以包含不同 region 的 subnet；subnet 本身則屬於單一 region，可供該 region 內不同 zone 的資源使用。畫圖時把 subnet 放在 region 層級，不必為了跨區域就先畫兩個 VPC 和 Peering。

同一個 VPC 讓路由可達，不代表每條連線都獲准通行；防火牆規則和服務本身的存取設定仍要另外標出。

若題目要求跨 zone 高可用，才需要把工作負載分布到多個 zone，並檢查服務本身的 HA 設定。建 VPC 時則可選 Auto Mode（自動建立各 region 的 subnet）或 Custom Mode（自行規劃）；正式環境若有 IP 配置、跨網路連線或未來擴充需求，Custom Mode 通常比較好控制。

subnet 不是防火牆

把資料庫放進獨立 subnet，有助於規劃位址，但不會單憑這個動作完成存取隔離。

例如前端和資料庫分別在兩個 subnet，不能因此就說「前端一定連不到資料庫」。同一 VPC 內的 subnet 有路由，能不能通行還要看防火牆與服務設定；也別把 default VPC 的預設規則，當成自訂 VPC 一定有的設定。

如果資料庫只接受後端連線，就在圖上標出允許的來源與連線方式。subnet 負責位址範圍，不會替你寫好存取規則。（參考：VPC 防火牆規則）

畫圖的順序：跟著流量走一遍

畫拓樸時，可以從使用者發出請求的地方開始，沿著實際流量一路往內追。下面用登雲書店的網站入口示範：

1. 用戶從哪進來？ 這個案例有公開網域，先畫出 DNS 名稱如何解析到入口。若用 Cloud DNS 分流，再確認要用地理位置、權重或故障切換政策；它沒有一個通用的「按延遲選最快區域」開關。
2. 公開入口接到哪裡？ 畫出 Application LB，再標註是否使用 Cloud CDN 與 Cloud Armor。它們不是每個網站都必備，也不是依序串接的三台機器。
3. 後端在哪個 region、哪個 zone？ 把服務的部署範圍標清楚，才能看出單一 zone 故障時是否還有後端可接手。
4. 服務之間怎麼連線？ 依後端所在網路與存取方式，比較內部 LB、Private Service Connect 或其他私有連線方式；不是每兩個服務都要建 Peering。
5. 跨 region 需要什麼？ 同一 VPC 的區域 subnet 有路由，但是否允許流量還要看 firewall rules。跨 VPC 時則需另規劃連線與路由。

還要確認應用怎麼連到資料庫。這個案例選擇私有連線，讓資料庫不必提供公開入口；若架構使用其他連線方式，也要清楚說明網路範圍、身分驗證與存取限制。

sequenceDiagram
  participant U as User
  participant D as Cloud DNS
  participant E as Global LB／CDN／Armor
  participant F as Frontend Pod
  participant I as Internal LB
  participant B as Backend Pod
  participant S as Cloud SQL Private IP
  U->>D: 查詢網域
  D-->>U: 回 Anycast IP
  U->>E: HTTPS request
  alt CDN hit
    E-->>U: Edge 回應
  else CDN miss
    E->>F: 路由到健康 region／zone
    F->>I: 內部 API 呼叫
    I->>B: 選健康 backend
    B->>S: Private Service Access 查詢
    S-->>B: 資料
    B-->>U: 沿原路回應
  end

走一遍範例 — 登雲書店

照前面那套順序，把登雲書店的網路拓樸從外到內畫出來。後面幾步都會回來引用這張圖，先讀熟。

第一層：DNS 與 edge

用戶查詢 Cloud DNS (shop.cloudon-books.com)
     → Global External Application LB (單一公網 IP)
     → 視設定由 Cloud CDN 快取回應或轉送後端
       Cloud Armor 在入口套用 WAF 與 rate limiting 規則

第二層：VPC 結構

• VPC：cloudon-vpc（custom mode，global）
• 主 region：asia-east1（彰化）
• DR region：asia-northeast1（東京）

一個 VPC、兩個 region，這就是前面講的「VPC global」在實務上長的樣子。不用為了東京 DR 另開一個 VPC。

第三層：位址規劃（asia-east1）

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

規劃 CIDR 時，先估算 VM、GKE Pod 和 Service 未來可能用到的位址。這裡替前後端節點各留 /20，Pod 還需要 secondary range；Service 位址是否使用自訂範圍，要依 GKE 版本與設定確認。表中的 PSA allocated range 也不是 subnet；/24 僅是最小值，這個例子若要跨區或擴充 Cloud SQL，仍得重新估算。若一開始只按目前數量切得太小，後續擴容會比較麻煩。

第四層：zone 分布

• GKE regional cluster 橫跨 asia-east1-a、asia-east1-b、asia-east1-c
• Cloud SQL HA 啟用，自動選兩個 zone（primary + standby）
• Bigtable 單叢集放 asia-east1-b（節省成本，非關鍵路徑）

這個案例假設 Bigtable 只承接非關鍵資料查詢，所以暫時使用單一叢集；GKE 與 Cloud SQL 則要支撐交易流程，優先配置跨 zone 高可用。如果 Bigtable 也進了交易路徑，就得重新評估單叢集的故障風險。可用性要跟業務影響一起看，不必每個元件都套同一個規格。

第五層：流量路徑範例

用戶查詢 shop.cloudon-books.com
 → Cloud DNS 回 Global LB 的 Anycast IP
 → 由 LB 的 Cloud CDN 快取回應，或回源到 GKE frontend Pod
 → Pod 呼叫 Internal LB (backend service)
 → backend Pod 透過 Private Service Access 查 Cloud SQL
 → 結果回傳

把這段路徑跟拓樸圖對照一遍：哪些連線走公開入口，哪些留在內部網路；Cloud CDN 命中時，請求也不會繼續送到 GKE。

如果題目要求 region 故障後仍能服務，拓樸圖就要畫出備援區域，以及流量什麼時候、如何切過去。只有第二個 region 的方塊，卻沒有健康檢查與切換條件，還不能算完整的 DR 設計。

幾個畫圖時最常翻車的地方

圖畫完後，再檢查幾個容易漏掉的細節。

把 subnet 畫在單一 zone 裡。 Subnet 是 regional 資源，範圍涵蓋該 region 的 zone；畫圖時應把它放在 region 層級。

沒算好 GKE 的 Pod 與 Service IP 範圍。 兩個 cluster 在同一 subnet 下，特定設定允許共用 secondary range，並非一共用就會衝突；但共用的 Pod 範圍可能被其中一個 cluster 用掉大半，讓另一個無法擴容。也要分清 Pod 和 Service 使用的範圍及各自限制，先估容量再配置。（參考：GKE VPC-native cluster 的 IP 範圍）

忘了預留 Cloud SQL Private Service Access 的位址。 若使用 Private Service Access，需先配置不與既有範圍重疊的 allocated range。/24 是最小配置，不代表跨區或未來新增服務時一定夠；要依實例位置與預期擴展量預留空間。（參考：Cloud SQL 私有 IP 的位址規劃）

收尾時，把自己當成第一次看圖的人，沿每條箭頭問：「誰要連誰？靠什麼連？這個 region 或 zone 壞了會怎樣？」只畫方案實際用到的 DNS、CDN 或 Cloud Armor；少一個不一定是漏畫，多一個也不會讓架構比較完整。

延伸閱讀

• VPC 網路總覽
• Region 與 Zone 說明
• Private Service Access
• Cloud DNS 路由政策

系列導航

• 系列首頁：PCA 雲端架構師之旅
• 上一篇：PCA 雲端架構師之旅 09 — 網路與 Load Balancing
• 下一篇：PCA 雲端架構師之旅 11 — 可靠性與擴展性

🎯 換你練習

理論讀完，換自己來。到 架構師設計工作坊 · 步驟 10 填入你的 case study，邊寫邊內化。