打造不當機的系統：GCP 高可用架構設計實戰

「系統當機」是每個工程師的惡夢。一次意外停機，可能造成數百萬營收損失、用戶信任崩盤，甚至上新聞頭條。在雲端時代，高可用性（High Availability）不再是大型企業的專利，而是每個架構師都得會的基本功。

這篇從自動擴縮容的 MIG 開始，講到負載平衡器選型、CDN/Armor，最後把多區域容錯架構整個搭起來。看完你會知道每個元件解決什麼問題、考試會怎麼考。

開始之前，假設你已經會開 VM、也知道 region（區域）和 zone（可用區）的差別——這篇會一直用到這兩個概念。

---

一、高可用架構的核心概念

什麼是高可用性？

高可用性（High Availability, HA） 是指系統在長時間內持續正常運作的能力，通常用 SLA（Service Level Agreement）來衡量：

SLA 等級	年停機時間	月停機時間	適用場景
99%	3.65 天	7.2 小時	內部工具
99.9%	8.76 小時	43.2 分鐘	一般 Web 應用
99.95%	4.38 小時	21.6 分鐘	電商平台
99.99%	52.56 分鐘	4.32 分鐘	金融服務
99.999%	5.26 分鐘	25.9 秒	關鍵基礎設施

實現高可用的三大支柱：

1. 冗餘（Redundancy）：消除單點故障，任何元件故障都有備援
2. 自動化（Automation）：自動偵測故障、自動擴容、自動恢復
3. 監控（Monitoring）：即時掌握系統狀態，提前發現問題

GCP 高可用架構的關鍵服務

服務	角色	核心功能
Managed Instance Group	自動管理虛擬機群組	Autoscaling、Autohealing、滾動更新
Load Balancer	流量分配	健康檢查、跨區域負載平衡
Cloud CDN	內容加速	邊緣快取、降低延遲
Cloud Armor	安全防護	DDoS 防護、WAF 規則
Regional Persistent Disk	資料冗餘	跨可用區同步複製

接下來就一個一個來看這些服務實際怎麼用。

---

二、Managed Instance Group：自動擴縮容的核心

什麼是 Managed Instance Group (MIG)？

MIG 是 GCP 幫你自動管理一組虛擬機的服務。你定好規則，它就會自動建立、刪除、修復虛擬機，確保應用程式隨時都有足夠的資源扛流量。

MIG 的核心優勢

1. Autoscaling（自動擴縮容）

   • 流量增加時自動新增 VM
   • 流量降低時自動刪除 VM
   • 節省成本，避免過度配置

2. Autohealing（自動修復）

   • 偵測到故障 VM 自動刪除並重建
   • 無需人工介入

3. Rolling Updates（滾動更新）

   • 逐步更新應用程式版本
   • 避免全部實例同時停機

4. Regional MIG

   • 跨多個可用區部署
   • 某區故障時其他區繼續服務

Autoscaling 三種模式怎麼選

1. Reactive Autoscaling（反應式） - 最常用

根據即時指標（CPU、記憶體、請求數）動態調整實例數量：

# 範例配置
autoscaling:
  minReplicas: 2
  maxReplicas: 10
  cpuUtilization:
    targetUtilizationPercent: 70
  coolDownPeriod: 60s

運作邏輯：

• 當 CPU 使用率超過 70%，新增實例
• 當 CPU 使用率低於 70%，移除實例
• 冷卻期 60 秒，避免頻繁擴縮

2. Predictive Autoscaling（預測式）

用歷史資料預測接下來的負載，提前把機器開好：

autoscaling:
  minReplicas: 2
  maxReplicas: 20
  coolDownPeriod: 300s
  cpuUtilization:
    targetUtilizationPercent: 70
    predictiveMethod: OPTIMIZE_AVAILABILITY # 啟用預測式擴縮

對應的 gcloud 指令：

gcloud compute instance-groups managed set-autoscaling MIG_NAME \
  --cpu-utilization-predictive-method optimize-availability \
  --target-cpu-utilization 0.7 \
  --max-num-replicas 20 \
  --cool-down-period 300

適用場景：

• 電商網站的促銷活動（例如：雙 11、Black Friday）
• 新聞網站的流量高峰（例如：重大事件發生時）
• 金融交易系統的開盤時段

優點：流量還沒進來，機器就已經備好了，不用等冷啟動。

Predictive Autoscaling 透過機器學習分析歷史 CPU 使用率的每日／每週週期，在預期負載到達前、依你設定的「應用初始化期（application initialization period）」提前把機器開好——初始化期設 5 分鐘，它就提前 5 分鐘擴容，讓 VM 有時間完成開機與暖機，等流量真的進來時已經 ready。它沒有 cron 排程（cron 排程屬於下方第 3 項的 Scheduled Autoscaling）。此功能自 2021 年起即為 GA。

3. Scheduled Autoscaling（排程式）

針對可預測的流量模式設定固定排程：

autoscaling:
  scalingSchedules:
    - name: 'business-hours'
      minRequiredReplicas: 5
      schedule: '0 9-18 * * 1-5'
    - name: 'off-hours'
      minRequiredReplicas: 1
      schedule: '0 19-8 * * *'

適用場景：

• 辦公時間才有流量的內部系統
• 僅白天營業的線上客服系統

健康檢查（Health Check）配置

Health Check 是 MIG 判斷實例是否正常的依據：

healthCheck:
  type: HTTP
  port: 80
  requestPath: /health
  checkIntervalSec: 10
  timeoutSec: 5
  unhealthyThreshold: 2
  healthyThreshold: 1

參數說明：

• checkIntervalSec: 10：每 10 秒檢查一次
• timeoutSec: 5：5 秒內無回應視為失敗
• unhealthyThreshold: 2：連續失敗 2 次，標記為不健康
• healthyThreshold: 1：成功 1 次，恢復健康狀態

Health Check 類型選擇

類型	協定	適合場景
HTTP	HTTP GET	Web 應用（最常見）
HTTPS	HTTPS GET	需要 TLS 的應用
TCP	TCP 連線	資料庫、非 HTTP 服務
SSL	SSL 握手	TLS proxy 服務
gRPC	gRPC 健康協定	微服務（gRPC 應用）

# 建立 HTTP Health Check
gcloud compute health-checks create http web-hc \
  --port=80 --request-path=/health \
  --check-interval=10 --timeout=5 \
  --unhealthy-threshold=3 --healthy-threshold=1

# 建立 TCP Health Check（適合資料庫 proxy）
gcloud compute health-checks create tcp db-hc \
  --port=5432 --check-interval=30 --timeout=10

Autohealing 行為

當 Health Check 把實例標成 unhealthy，MIG 的 Autohealing 就會自動接手：

實例 unhealthy → MIG 刪除該實例 → MIG 建立新實例（用 Instance Template）
                                   → 等待 initialDelaySec → 開始 Health Check

這裡的 initialDelaySec（初始延遲）是新實例建好之後、MIG 暫時不對它做健康檢查的緩衝時間——讓應用有時間完成開機、載入設定、連上資料庫，避免「都還沒啟動完就被判定失敗」。

# 設定 Autohealing（含初始延遲）
gcloud compute instance-groups managed set-autohealing my-mig \
  --health-check=web-hc \
  --initial-delay=300  # 新實例啟動後等 5 分鐘才開始檢查

📝 考場提點

ACE 很愛考一道「新實例不斷被刪了又建、永遠起不來」的故障題，答案幾乎都是 initial-delay 設得比應用啟動時間還短。情境通常是：應用要 3 分鐘才起得來，但 initial-delay 只設 30 秒，於是 MIG 在它還在開機時就判定 unhealthy、刪掉重建，陷入無限迴圈。看到題目描述「實例反覆重建」「一直進不了 serving 狀態」，先想 initial-delay。

第二個高頻陷阱：LB 的 Health Check 和 Autohealing 的 Health Check 要分開兩套。LB 健康檢查要快（門檻低、間隔短），偵測到問題馬上把流量導開；Autohealing 要慢、要謹慎（門檻高、initial-delay 給足），免得一次暫時性抖動就把好端端的實例砍掉重建。共用一套，往往兩邊都顧不好。

最佳實踐：

1. /health endpoint 應該檢查關鍵依賴（資料庫、快取、外部 API）
2. initial-delay 要大於應用最慢啟動時間
3. unhealthy-threshold 至少設 3，避免暫時性故障誤判

---

三、負載平衡器選型

GCP Load Balancer 類型選擇

GCP 有兩大類負載平衡器。選錯類型後面很難救，所以先搞清楚這兩大類差在哪。

Application Load Balancer (Layer 7 - HTTP/HTTPS)

適合需要內容路由的 Web 應用，例如依路徑或 Header 分流：

類型	範圍	IP 地址	適用場景
Global External ALB	全球	Anycast IP	全球使用者訪問的 SaaS 服務
Regional External ALB	區域	區域 IP	僅服務特定區域的應用
Internal ALB	VPC 內部	私有 IP	微服務間的內部通訊

表裡的 Anycast IP 是 Global ALB 的招牌：全世界只給你一個 IP，但這個 IP 同時掛在 Google 各地的邊緣節點上，使用者連過來會自動被導到離他最近的入口——不用你自己搞 DNS 分流，一個 IP 就服務全球。

ALB 是 L7（第七層）的負載平衡器，看得懂 HTTP，所以能依路徑分流（/api/* 走 API、/images/* 走圖片）或依 Header（例如 User-Agent）把請求送到不同後端，也能在 LB 這層直接做 SSL/TLS 終止——憑證放在 LB 解密，後端只收明文 HTTP，省下每台機器各自處理加解密的負擔。它還支援 WebSocket，並能一路接上 Cloud CDN 和 Cloud Armor。

Network Load Balancer (Layer 4 - TCP/UDP)

適合追求高性能、或是跑非 HTTP 協議的應用：

Proxy 模式：

• 作為反向代理處理 TCP 流量
• 支援 SSL 代理
• 隱藏後端 IP 地址

Passthrough 模式：

• 保留客戶端來源 IP
• 支援 UDP、ESP（IPsec VPN 加密封包用的協定）、ICMP（ping 用的協定）等非 TCP 流量
• 無代理開銷，性能更高

適用場景：

• 遊戲伺服器（需要 UDP）
• VoIP 服務
• 自定義 TCP 協議的應用

如何選擇 Load Balancer？

開始
  ↓
需要處理 HTTP/HTTPS 流量？
  ├─ 是 → 需要全球訪問？
  │        ├─ 是 → Global External Application LB
  │        └─ 否 → Regional External Application LB
  │
  └─ 否 → 需要保留來源 IP？
           ├─ 是 → Passthrough Network LB
           └─ 否 → Proxy Network LB

📝 考場提點

Load Balancer 選型是 ACE 和 PCA 的高頻題，題目幾乎都用「關鍵字」暗示答案，記住這幾組對照就能秒選：

• 看到「URL 路徑路由」「依 Header 分流」「SSL 終止」「接 CDN／WAF」→ 要 L7，選 Application LB。
• 看到「要保留 client source IP（後端要拿到使用者真實 IP）」「UDP／遊戲伺服器」→ 選 Passthrough Network LB（它不做 proxy，來源 IP 原封不動）。
• 看到「全球單一 IP」「Anycast」「全世界使用者就近進入」→ 選 Global External ALB。
• 看到「Cloud Run 要跨 region 容錯」→ 答案是 Global External ALB + Serverless NEG，而不是靠 Cloud Run 自己（Cloud Run 是區域型服務，自己不跨 region，這點下面第五節會再講一次）。

實戰範例：配置 Global Application Load Balancer

假設你有一個電商網站，使用者分布在亞洲、歐洲、美洲：

# 1. 建立 Health Check
gcloud compute health-checks create http web-health-check \
    --port=80 \
    --request-path=/health \
    --check-interval=10s \
    --timeout=5s \
    --unhealthy-threshold=2

# 2. 建立 Backend Service
gcloud compute backend-services create web-backend-service \
    --protocol=HTTP \
    --health-checks=web-health-check \
    --global

# 3. 將 MIG 加入 Backend Service
gcloud compute backend-services add-backend web-backend-service \
    --instance-group=web-mig-asia \
    --instance-group-zone=asia-east1-a \
    --balancing-mode=UTILIZATION \
    --max-utilization=0.8 \
    --global

gcloud compute backend-services add-backend web-backend-service \
    --instance-group=web-mig-europe \
    --instance-group-zone=europe-west1-b \
    --balancing-mode=UTILIZATION \
    --max-utilization=0.8 \
    --global

# 4. 建立 URL Map
gcloud compute url-maps create web-url-map \
    --default-service=web-backend-service

# 5. 建立 HTTP(S) Proxy
gcloud compute target-https-proxies create web-https-proxy \
    --url-map=web-url-map \
    --ssl-certificates=my-ssl-cert

# 6. 建立 Forwarding Rule（全球 IP）
gcloud compute forwarding-rules create web-forwarding-rule \
    --global \
    --target-https-proxy=web-https-proxy \
    --ports=443

運作流程：

1. 使用者訪問 https://yourdomain.com
2. Global Load Balancer 將請求路由到最近的健康後端
3. 若亞洲區域的 MIG 故障，自動轉向歐洲或美洲
4. Health Check 持續監控，自動移除故障實例

---

四、Cloud CDN + Cloud Armor：全球加速與安全防護

Cloud CDN：就近取用、壓低延遲

什麼是 CDN？

內容傳遞網路（Content Delivery Network） 把靜態資源快取到全球各地的邊緣節點，使用者就近從最近的節點拿內容，延遲明顯降低。

啟用 Cloud CDN

在 Backend Service 開 CDN 很簡單：

gcloud compute backend-services update web-backend-service \
    --enable-cdn \
    --cache-mode=CACHE_ALL_STATIC \
    --default-ttl=3600 \
    --max-ttl=86400 \
    --global

快取策略：

模式	說明	適用場景
CACHE_ALL_STATIC	快取所有靜態內容	靜態網站、圖片、CSS/JS
USE_ORIGIN_HEADERS	依據 Cache-Control header	動態內容混合的網站
FORCE_CACHE_ALL	強制快取所有內容	公開 API 資料

TTL（Time to Live）：

• default-ttl=3600：預設快取 1 小時
• max-ttl=86400：最長快取 24 小時

效能提升實例

假設你的網站主機在 us-central1：

使用者位置	無 CDN 延遲	啟用 CDN 延遲	改善幅度
台灣	180ms	20ms	89% ↓
歐洲	150ms	25ms	83% ↓
巴西	220ms	30ms	86% ↓

以上是示意數字，幫你建立「就近取用差多少」的直覺，實際延遲依來源位置、節點分布和內容大小而定，不要當成官方 benchmark。

🆕 2025-2026 Cloud CDN 重要更新

根據 Cloud CDN Release Notes，2025-2026 年推出的新功能：

1. Cache Tags（快取標籤）

• 用途：為快取內容加上標籤，實現精細化的快取失效控制
• 優勢：可以批次清除特定標籤的快取，而不需清除整個快取
• 適用場景：電商網站商品更新、新聞網站內容發布

範例：

# 設定快取標籤
Cache-Control: public, max-age=3600
Cache-Tag: product-123, category-electronics

# 清除特定標籤的快取
gcloud compute url-maps invalidate-cdn-cache web-url-map \
    --tags=product-123

2. Private Origin Authentication（私有來源驗證）

• 用途：確保只有 Cloud CDN 可以存取源伺服器，防止直接繞過 CDN 訪問
• 安全性提升：源伺服器可設為私有 IP，僅接受來自 Cloud CDN 的請求
• 防止攻擊：避免攻擊者直接攻擊源伺服器

配置方式：

# 使用 Cloud CDN 簽署的請求
gcloud compute backend-services update web-backend-service \
    --enable-cdn \
    --signed-url-cache-max-age=3600

---

Cloud Armor：抵禦 DDoS 與 Web 攻擊

2025-2026 最新功能

根據 Cloud Armor Release Notes，2025-2026 年重要更新包括：

1. Hierarchical Security Policies（階層式安全政策）

   • 在組織層級定義基礎安全規則
   • 專案層級繼承並擴展規則
   • 集中管理，降低維護成本

2. Network Threat Intelligence (NTI)

   • 自動整合威脅情報資料庫
   • 封鎖已知惡意 IP 和殭屍網路
   • ⚠️ 需訂閱 Cloud Armor Enterprise 方案：威脅情報 feeds（evaluateThreatIntelligence()）與 named IP address lists 屬 Enterprise 功能，Standard 方案無法使用

3. 🆕 Edge Security Policies（邊緣安全政策）

   • 在 Google 邊緣節點層級執行安全規則
   • 更早攔截攻擊：惡意流量在到達後端之前就被封鎖
   • 降低成本：減少後端伺服器處理惡意請求的負擔
   • 適用場景：全球分散式應用、大規模 DDoS 防護

4. 🆕 Service Extensions with Plugins

   • 支援自定義外掛程式擴展 Cloud Armor 功能
   • 整合第三方安全解決方案（如 Palo Alto、Check Point）
   • 建立客製化的流量處理邏輯
   • 適用場景：需要特殊安全邏輯的企業應用

建立 Cloud Armor 安全政策

# 1. 建立安全政策
gcloud compute security-policies create web-security-policy \
    --description="Protect web application"

# 2. 封鎖特定國家（例如：封鎖來自 CN 的流量）
gcloud compute security-policies rules create 1000 \
    --security-policy=web-security-policy \
    --expression="origin.region_code == 'CN'" \
    --action=deny-403

# 3. 啟用 OWASP Top 10 防護
gcloud compute security-policies rules create 2000 \
    --security-policy=web-security-policy \
    --expression="evaluatePreconfiguredExpr('xss-stable')" \
    --action=deny-403

gcloud compute security-policies rules create 2001 \
    --security-policy=web-security-policy \
    --expression="evaluatePreconfiguredExpr('sqli-stable')" \
    --action=deny-403

# 4. 速率限制（防止暴力破解）
gcloud compute security-policies rules create 3000 \
    --security-policy=web-security-policy \
    --expression="request.path.matches('/login')" \
    --action=rate-based-ban \
    --rate-limit-threshold-count=10 \
    --rate-limit-threshold-interval-sec=60 \
    --ban-duration-sec=600

# 5. 附加到 Backend Service
gcloud compute backend-services update web-backend-service \
    --security-policy=web-security-policy \
    --global

Adaptive Protection（自適應防護）

開啟後，Cloud Armor 會自己分析流量模式，揪出異常的 L7 DDoS 攻擊：

gcloud compute security-policies update web-security-policy \
    --enable-layer7-ddos-defense

運作方式：

1. 建立流量基線（正常流量模式）
2. 偵測偏離基線的異常流量
3. 自動生成建議的 WAF 規則
4. 管理員確認後一鍵套用

Cloud CDN + Cloud Armor 整合

當安全政策附加到啟用 CDN 的 Backend Service：

• 快取命中：直接從邊緣節點回傳，不經過安全檢查
• 快取未命中：請求到達源伺服器前，先經過 Cloud Armor 檢查
• 動態內容：每次請求都會檢查

最佳實踐：

• 將靜態資源（CSS/JS/圖片）設定為可快取，減少源伺服器負擔
• 動態 API 請求務必通過 Cloud Armor 檢查
• 定期檢視 Cloud Armor 日誌，調整安全規則

---

五、多區域容錯：把雞蛋放到不同籃子

為什麼需要多區域部署？

單區域風險：

• ❌ 整個資料中心電力設施故障（例如：2022 年 Google us-central1／Council Bluffs 資料中心電力設施爆炸起火事故）
• ❌ 光纖被挖斷（網路中斷）
• ❌ 天災（地震、颱風、洪水）

多區域優勢：

• ✅ 某區域完全失效，其他區域繼續服務
• ✅ 降低全球使用者延遲（就近存取）
• ✅ 符合資料主權法規（例如：GDPR 要求歐盟資料存放在歐盟）

Regional MIG vs Multi-Regional 部署

Regional MIG（跨可用區）

將實例分散在同一區域的多個可用區：

gcloud compute instance-groups managed create web-mig \
    --base-instance-name=web-instance \
    --template=web-instance-template \
    --size=3 \
    --region=asia-east1 \
    --target-distribution-shape=EVEN

特性：

• 實例均勻分布在 asia-east1-a、asia-east1-b、asia-east1-c
• 某個可用區故障，其他可用區繼續服務
• 資料傳輸成本低（同區域內免費或低成本）

Multi-Regional 部署（跨區域）

在多個區域各建立 MIG，搭配 Global Load Balancer：

# 亞洲區域
gcloud compute instance-groups managed create web-mig-asia \
    --region=asia-east1 \
    --template=web-instance-template \
    --size=3

# 歐洲區域
gcloud compute instance-groups managed create web-mig-europe \
    --region=europe-west1 \
    --template=web-instance-template \
    --size=3

# 美洲區域
gcloud compute instance-groups managed create web-mig-us \
    --region=us-central1 \
    --template=web-instance-template \
    --size=3

流量分配策略：

• UTILIZATION 模式：優先將流量送到使用率低的後端
• RATE 模式：根據每秒請求數平衡
• 地理位置優先：使用者自動路由到最近的區域

資料庫的多區域高可用設計

Cloud SQL 跨區域複製

# 主實例（亞洲）
gcloud sql instances create primary-db \
    --database-version=POSTGRES_14 \
    --tier=db-n1-standard-4 \
    --region=asia-east1 \
    --availability-type=REGIONAL

# 建立唯讀副本（歐洲）
gcloud sql instances create read-replica-eu \
    --master-instance-name=primary-db \
    --region=europe-west1 \
    --tier=db-n1-standard-2

# 建立唯讀副本（美洲）
gcloud sql instances create read-replica-us \
    --master-instance-name=primary-db \
    --region=us-central1 \
    --tier=db-n1-standard-2

架構說明：

• 寫入：所有寫入操作都發送到 asia-east1 的主實例
• 讀取：應用程式從最近的副本讀取，降低延遲
• 災難恢復：若主實例故障，手動將副本提升為主實例

Cloud Spanner 全球分散式資料庫

適合那種非要強一致性不可的關鍵任務應用：

gcloud spanner instances create global-db \
    --config=nam-eur-asia1 \
    --description="Global multi-region database" \
    --nodes=3

gcloud spanner databases create app-db \
    --instance=global-db

特性：

• ✅ 自動跨區域複製（北美-歐洲-亞洲）
• ✅ 強一致性（任何區域讀取都是最新資料）
• ✅ 自動故障轉移
• ❌ 成本較高（適合金融、電商等高價值應用）

多區域配置裡會看到一個叫 Witness（見證者） 的角色：它只存投票用的中繼資料、不存完整資料，故障轉移要選新主寫入區時靠它湊出多數票決，確保整個系統不會因為某區掛掉就無法決策。你不用自己管它，知道「多數決靠 Witness 撐住」這個概念即可。

Cloud Run Multi-Region 架構 ⭐ 2026 新功能

根據 Google Cloud Next 2026 發表，Cloud Run 推出 Service Health 功能：

N+1 Zonal Redundancy

預設在「單一區域內」跨多個可用區（zone）提供足夠的故障轉移容量，某個可用區故障時自動將流量轉移到同區域的其他可用區。

重要：N+1 Zonal Redundancy 只保護「區域內的可用區（zone）故障」。Cloud Run 是區域型服務，本身不會自動跨「區域（region）」轉移流量。若要做到區域層級的容錯，必須將服務部署到多個區域，並在前方搭配 Global External Application Load Balancer + Serverless NEG（如本節稍後的範例所示）。

這裡的 Serverless NEG（Serverless Network Endpoint Group，無伺服器網路端點群組） 是負載平衡器用來「指到一個 Serverless 服務」的接頭——因為 Cloud Run／App Engine 這類服務沒有固定的 VM 或 IP 可以掛進後端，GCP 就用 Serverless NEG 把「某 region 的某個 Cloud Run 服務」包成一個 LB 認得的後端目標。每個 region 各包一個，全部掛到同一個 Global ALB，LB 就能在區域間導流與容錯。

配置範例

# cloud-run-service.yaml
apiVersion: serving.knative.dev/v1
kind: Service
metadata:
  name: web-app
spec:
  template:
    metadata:
      annotations:
        autoscaling.knative.dev/minScale: '1'
    spec:
      containers:
        - image: asia-east1-docker.pkg.dev/my-project/my-repo/web-app:latest
          ports:
            - containerPort: 8080
          livenessProbe:
            httpGet:
              path: /healthz
            initialDelaySeconds: 10
            periodSeconds: 10
          readinessProbe:
            httpGet:
              path: /ready
            initialDelaySeconds: 5
            periodSeconds: 5

運作方式：

1. 配置 Readiness Probe 和 Minimum Instances = 1
2. Cloud Run 持續監控區域內每個可用區的服務狀態
3. 偵測到某可用區服務故障時，自動在同區域內把流量轉移到健康的可用區（N+1 Zonal Redundancy）
4. 故障可用區恢復後，流量自動回流

跨「區域（region）」的故障轉移並非 Cloud Run 內建行為——必須部署到多個區域，並由前方的 Global External Application Load Balancer 搭配 Serverless NEG 負責偵測各區域健康狀態並導流（見下方範例）。

部署到多區域：

# 部署到亞洲
gcloud run deploy web-app \
    --image=asia-east1-docker.pkg.dev/my-project/my-repo/web-app:latest \
    --region=asia-east1 \
    --platform=managed \
    --min-instances=1

# 部署到歐洲
gcloud run deploy web-app \
    --image=asia-east1-docker.pkg.dev/my-project/my-repo/web-app:latest \
    --region=europe-west1 \
    --platform=managed \
    --min-instances=1

# 部署到美洲
gcloud run deploy web-app \
    --image=asia-east1-docker.pkg.dev/my-project/my-repo/web-app:latest \
    --region=us-central1 \
    --platform=managed \
    --min-instances=1

# 建立 Global Load Balancer 整合 Cloud Run
gcloud compute backend-services create web-backend \
    --global \
    --load-balancing-scheme=EXTERNAL_MANAGED

gcloud compute backend-services add-backend web-backend \
    --global \
    --network-endpoint-group=web-app-asia-neg \
    --network-endpoint-group-region=asia-east1

gcloud compute backend-services add-backend web-backend \
    --global \
    --network-endpoint-group=web-app-europe-neg \
    --network-endpoint-group-region=europe-west1

---

六、其他網路服務：完善高可用架構

Cloud DNS：地理路由與故障轉移

Cloud DNS 的 routing policy 有好幾種，這裡先看 GEO（地理路由）——它依使用者所在地理位置，把同一個域名解析到不同的 IP（亞洲使用者解到亞洲 IP、歐洲使用者解到歐洲 IP），目的是「就近導流、降低延遲」：

# 建立健康檢查
gcloud compute health-checks create https dns-health-check \
    --port=443 \
    --request-path=/health

# 建立 DNS 政策（依地理位置解析到不同 IP）
gcloud dns managed-zones create ha-zone \
    --dns-name=yourdomain.com \
    --description="HA DNS zone"

gcloud dns record-sets create www.yourdomain.com \
    --zone=ha-zone \
    --type=A \
    --ttl=60 \
    --routing-policy-type=GEO \
    --routing-policy-data="asia-east1=1.2.3.4;europe-west1=5.6.7.8"

要特別分清楚：GEO 是「就近路由」，不等於「故障轉移」。GEO 本身不會因為某個 IP 掛了就自動切走——真正的 DNS failover 要用 --routing-policy-type=FAILOVER（設 primary／backup target），或把上面的 GEO policy 綁定健康檢查（enable health checking），讓 Cloud DNS 偵測到後端不健康時才把流量導到備援。如果你只設 GEO 卻期待它自動避開故障節點，考試和正式環境都會踩雷。

Cloud NAT：高可用的網際網路存取

讓私有 VM 安全地訪問網際網路，無需公開 IP：

gcloud compute routers create nat-router \
    --network=my-vpc \
    --region=asia-east1

gcloud compute routers nats create my-nat \
    --router=nat-router \
    --region=asia-east1 \
    --auto-allocate-nat-external-ips \
    --nat-all-subnet-ip-ranges

高可用特性：

• 自動配置 NAT IP 地址
• 若某個 NAT gateway 故障，自動轉移到其他 gateway
• 無單點故障

---

七、完整架構範例與成本估算

典型的三層式高可用架構

                       Internet
                          ↓
              [Global Load Balancer]
              (Cloud CDN + Cloud Armor)
                          ↓
        ┌─────────────────┼─────────────────┐
        ↓                 ↓                 ↓
   [MIG Asia]        [MIG Europe]      [MIG US]
   2-10 instances    2-10 instances    2-10 instances
   asia-east1        europe-west1      us-central1
        ↓                 ↓                 ↓
   [Regional PD]     [Regional PD]     [Regional PD]
        └─────────────────┼─────────────────┘
                          ↓
                  [Cloud Spanner]
                 (Multi-Region DB)

成本估算（月費用，2026 年價格）

假設場景：

• 流量：1TB/月
• 平均實例數：3 個區域 x 5 個實例 = 15 個 n1-standard-2

項目	數量	單價	月費用
Compute Engine (n1-standard-2)	15 台	$69.35/台	$1,040.25
Regional Persistent Disk	15 x 100GB	$0.04/GB	$60
Global Load Balancer	1	$18 + $0.008/GB	$26
Cloud CDN	1TB 快取輸出	$0.04/GB	$40
Cloud Armor	100 條規則	$5/策略 + $1/規則	$105
Cloud Spanner (nam-eur-asia1 多區域)	3 nodes	$6,570/node	$19,710
Cloud NAT	3 個 gateway	$0.045/hour	$97.2
總計			$21,078.45

成本提醒：多區域 Cloud Spanner（nam-eur-asia1）是這個架構中最大的成本來源。多區域節點約 $9.00/node/hour（≈ $6,570/node/月），遠高於單一區域節點的約 $0.90/node/hour。若不需要跨洲強一致性，改用單一區域 Spanner（3 nodes ≈ $1,971/月）可大幅降低費用。

成本優化建議：

1. 使用 Committed Use Discounts

   • 承諾使用 1 年：節省 37%
   • 承諾使用 3 年：節省 55%

2. 使用 Preemptible / Spot VM

   • 適合非關鍵的批次處理工作
   • 成本約為隨需（on-demand）的 20–40%（折扣 60–91%，價格會隨供需浮動）

3. 調整 Autoscaling 參數

   • 設定合理的 minReplicas 和 maxReplicas
   • 避免過度配置

4. 善用 Cloud CDN

   • 減少源伺服器流量，降低運算成本

---

總結

到這裡，GCP 高可用架構的幾塊拼圖你大致都摸過一輪了。往下扛流量靠 MIG（自動擴縮、自動修復、滾動更新），前面用 Load Balancer 分流並決定走 L7 還是 L4，再疊上 Cloud CDN 加速、Cloud Armor 擋攻擊；要做到單區域掛掉還活著，就把服務鋪到多個 region，搭配 Regional MIG、跨區複製或 Cloud Spanner。最後那張三層式架構圖和成本表，是把這些元件擺在一起時長什麼樣、要花多少錢。

考試最常考的就三點，記熟比什麼都實在：MIG autohealing 的 initial-delay 陷阱（設太短會反覆刪建實例）、Load Balancer 選型決策樹（看關鍵字選 L7／L4、Global／Regional、Passthrough），還有 Cloud Run 不跨 region（要跨 region 容錯得靠 Global ALB + Serverless NEG）。

下一步行動

1. 動手實作

   • 建立你的第一個 MIG + Load Balancer
   • 啟用 Cloud CDN 並測試效能提升
   • 配置 Cloud Armor 安全政策

2. 深入學習

   • GCP High Availability 官方文檔
   • Qwiklabs：Architecting with GCP

3. 考取認證

   • Professional Cloud Architect 認證會深入考核高可用架構設計

延伸閱讀

• 上一篇：ACE-201 GCP 資料儲存策略
• 下一篇：ACE-203 無伺服器時代：App Engine、Cloud Run 與 GKE 選型策略

相關主題推薦：

• GCP-104：GCP 網路基礎：VPC、防火牆與安全連線完全指南
• ACE-205：企業級資安防護：GCP 安全架構與合規指南