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

Load Balancer 上一篇選完了，現在要把整張網路地圖攤開來畫。這一步的產出物只有一個：一張網路拓樸圖——region 在哪、zone 怎麼切、VPC 長什麼樣、一個 request 從 DNS 進來之後到底怎麼走到後面的 Pod。

PCA 很愛這種題。給你半張架構圖問你缺了什麼，或是丟一個場景要你描述怎麼畫。畫不出來，後面談可靠性、談安全，全都是空中樓閣。

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

---

拓樸圖不是裝飾，是你思路的證據

說一句可能有點刺耳的話：很多人畫的網路圖，只是把投影片上看過的方塊照抄一遍，連不起來。考官一眼就看得出來。

考官真正想知道的，不是你會不會背 VPC 的定義，而是你能不能把一個 request 從 DNS 查詢開始，一路講到資料回傳給用戶，中間每一跳經過誰、為什麼要經過它。你能講清楚這條路徑，這張圖就是活的；講不清楚，再漂亮的方塊都是死的。

我看過不少團隊在白板上畫架構，畫到一半就卡住——「欸這個流量到這裡之後是走內網還是繞出去？」答不上來。這不是粗心，是平常根本沒把整條路徑想通。考場上沒有白板可以慢慢卡，所以這條路徑你得先在腦子裡走過幾十遍，閉著眼睛都能描出來。

---

先把幾個最容易搞混的觀念釘死

GCP 的網路有幾個設定跟其他雲不一樣，第一次接觸很容易卡住。我把六個基本元件列出來，你可以當成畫圖時的檢查清單：

元件	範圍	功能
Region	全球數十個	地理區域（例如 asia-east1 彰化）
Zone	每 region 至少 3 個	區域內獨立故障域
VPC	全域（Global）	邏輯網路，跨 region
Subnet	區域（Regional）	VPC 內的 IP 段，綁在一個 region
Cloud DNS	全球	權威 DNS，支援 geo / latency routing
Cloud CDN	全球 edge	邊緣快取，綁在 Application LB

這張表裡藏著兩個最常被考、也最常被畫錯的點。

第一個：VPC 是 global 的。 同一個 VPC 可以橫跨所有 region 的 subnet。這跟 AWS 的習慣完全相反——AWS 一個 VPC 綁死在一個 region。從 AWS 跳過來的人最容易在這裡翻車，畫圖時下意識地一個 region 一個 VPC，然後 region 之間又拉一堆 Peering 連線，整張圖瞬間複雜兩倍。在 GCP，同一個 VPC 的不同 subnet 走 Google 自家骨幹就通了，不用 Peering。

第二個：subnet 是 regional 的，它會自動跨 zone。 一個 subnet 涵蓋該 region 內所有 zone。所以畫圖的時候，subnet 的框要包住整個 region，不能把它塞進某一個 zone 裡。這個錯後面還會再提一次，因為它真的太常見了。

剩下兩個比較不會錯，但別忘了畫：zone 要選 3 個以上做 HA，單 zone 的 SLA 遠低於多 zone；建 VPC 時有 Auto Mode（自動每個 region 幫你開 subnet）和 Custom Mode（手動規劃）兩種，production 一律用 Custom Mode——Auto Mode 開出來的 IP 段你管不動，遲早跟人家撞。

📝 考場提點

「VPC 是 global、subnet 是 regional」這組對照是 PCA 的高頻考點，幾乎每份 case study 都會繞到它。題目常見的陷阱是給你一個跨國場景，然後選項裡放一個「每個 region 各建一個 VPC 再用 VPC Peering 串起來」——看起來很合理，但在 GCP 屬於過度設計，正解通常是「一個 VPC 跨多 region subnet」。看到「跨 region 內部通訊」的字眼，先想 Google 骨幹，不要急著拉 Peering。

---

subnet 不是防火牆，這個誤會害死很多人

這點單獨拉出來講，因為它是新手最深的誤區之一：把 subnet 當成 security boundary。

很多人從傳統機房的思維帶過來，覺得「我把資料庫放進一個獨立 subnet，它就被隔離保護了」。錯。subnet 在 GCP 裡就只是一段 IP，它本身不擋任何流量。同一個 VPC 裡，預設情況下 subnet A 的機器可以直接打到 subnet B 的機器。

真正在做隔離的是 firewall rules 跟 service attachments。你想讓資料庫只接受後端來的連線，是靠 firewall rule 限定來源 tag 或來源網段，不是靠「它在不同的 subnet」。我看過團隊把敏感服務丟進獨立 subnet 就以為安全了，結果整個 VPC 內網是全通的——這種設計在資安稽核時會被狠狠記一筆。

subnet 的意義是 IP 規劃與 region 綁定，security 是另一條獨立的軸。考場上如果題目問「怎麼隔離 A 跟 B」，答 subnet 通常是錯的，答 firewall rules 才對。

---

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

真的動手畫的時候，不要從 VPC 開始畫框框。從用戶那一端開始，跟著流量一路往內走，每一跳問自己一個問題，圖自然就出來了：

1. 用戶從哪進來？ 第一個畫 Cloud DNS。這裡要決定路由策略——是 geo routing（按地理位置分流）還是 latency routing（按延遲分流）。打跨國市場的話這題很重要。
2. 流量第一站撞到誰？ Application LB，後面緊接 Cloud CDN 和 Cloud Armor。注意 Cloud DNS 和 CDN 都不在 VPC 裡，但它們是流量的最前線，圖上一定要畫出來。很多人畫拓樸只畫 VPC 內部，把這兩個漏掉，等於漏掉了整條路徑的開頭。
3. 流量要去哪個 region、哪個 zone？ 每個服務都標清楚它的 region / zone。這是這張圖的肉，標不清楚就只是裝飾。
4. 同 region 不同服務怎麼互相講話？ Internal LB？VPC Peering？還是 Private Service Connect？選哪個取決於對方是你自己的服務還是別人的託管服務。
5. 跨 region 要不要通？ 同一個 VPC 的不同 subnet 自動通，走 Google 骨幹；跨 VPC 才需要 Peering。

還有一個幾乎每次都被忘掉的問題，我特別拉出來提醒：資料庫怎麼對外、對內？ 答案是 Cloud SQL 走 Private Service Access，不要開 public IP。資料庫掛 public IP 是考場上的送分陷阱，也是真實世界裡資安團隊最怕看到的東西。

---

走一遍範例 — 登雲書店

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

第一層：DNS 與 edge

用戶 → Cloud DNS (shop.cloudon-books.com)
     → Global External Application LB (單一公網 IP)
     → Cloud CDN 邊緣節點（命中率 ~70%）
     → Cloud Armor（WAF + rate limit）

第二層：VPC 結構

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

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

第三層：Subnet 規劃（asia-east1）

Subnet 名稱	用途	CIDR
subnet-frontend	GKE nodes（前端 Pod）	10.0.0.0/20
subnet-backend	GKE nodes（後端 Pod）	10.0.16.0/20
subnet-db-psa	Private Service Access for Cloud SQL	10.0.32.0/24
subnet-mgmt	Bastion、維運工具	10.0.40.0/24

CIDR 規劃這件事，動手前一定要把整張 IP 地圖在紙上排一次。我看過太多案子一開始隨手切 /24，跑了一年要擴 GKE 才發現 Pod IP 不夠用，那時候改 range 等於整群重建，痛苦到不行。前端後端各給 /20 不是隨便給的，是預留了 Pod 數量成長的空間。

第四層：zone 分布

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

這裡有個取捨值得停下來看：GKE 跟 Cloud SQL 都做了跨 zone，但 Bigtable 故意只放單一 zone。為什麼？因為它不在關鍵交易路徑上，掛了不會讓客人下不了單，省成本比高可用更划算。架構不是每個元件都拉到最高規格，而是把錢花在會痛的地方——這種「哪裡該省、哪裡不能省」的判斷，正是 PCA 想看的東西。

第五層：流量路徑範例

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

這條路徑就是前面說的「把 request 從頭講到尾」。你能把這六行流暢地講出來，這張拓樸圖在你腦子裡就是活的。

PCA 還很愛追問一句：「如果 asia-east1 整個 region 掛掉怎麼辦？」完整答案留到第 12 步（DR）再展開，但這裡先記一個原則——拓樸圖上一定要看得出 DR region 的存在，還要標出 Cloud DNS 的 failover policy 設在哪。圖上看不到 failover 的觸發點，等於沒有 DR 計畫。

---

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

考前把這幾個檢查一遍，能避掉一堆低級失分。

subnet 畫成 zone 的子集合。 重複第三次，因為它最常見：subnet 是 regional 的，會自動跨 zone。畫圖時 subnet 的框應該包住整個 region，不要塞進單一 zone。看到別人的圖把 subnet 畫在 zone 裡面，基本上可以判斷他沒搞懂 GCP 的網路模型。

兩個 GKE cluster 共用同一段 secondary range。 Pod IP 跟 Service IP 是從 subnet 的 secondary range 切出來的。兩個 cluster 共用會直接 IP 衝突，建第二個的時候就報錯。一定要為每個 cluster 規劃獨立的 range——這也是前面講「IP 地圖先排好」的延伸，secondary range 比 primary range 更容易被忽略。

忘了幫 Cloud SQL 留 Private Service Access 的 peering range。 Cloud SQL 透過 Service Networking 配一段 /24 的 peering range。這段 range 不能跟既有 subnet 重疊，重疊的話建立時直接失敗。實務上這是新手第一次接 Cloud SQL Private IP 最常卡的地方，錯誤訊息還不太友善，所以規劃 IP 的時候就要把這段預留進去。

📝 考場提點

拓樸題的計分點往往不在「你畫得多漂亮」，而在「關鍵元素有沒有到齊」。畫圖前先在心裡跑一份 checklist：DNS 畫了嗎？CDN / Cloud Armor 畫了嗎？每個服務的 region 和 zone 標了嗎？資料庫是 Private 還是 public？DR region 看得到嗎？failover 點標了嗎？這幾項只要漏一項就是失分點。時間分配上，拓樸題不要鑽進 CIDR 的細節算到天荒地老——把骨架和關鍵元素先補齊拿到分，IP 細節有餘力再補。

---

延伸閱讀

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

---

系列導航

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

🎯 換你練習

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