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

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

這篇我們來談 GCP 的高可用架構，從自動擴縮容的 Managed Instance Group、負載平衡器選型、全球內容加速，一路到多區域容錯設計，一步步把一個「不會掛掉」的系統搭起來。

你將學到：

✅ 如何使用 Managed Instance Group 實現自動擴縮容
✅ 選擇正確的 Load Balancer 類型並配置健康檢查
✅ 整合 Cloud CDN 與 Cloud Armor 提升速度與安全性
✅ 設計多區域容錯架構避免單點故障
✅ 完整的高可用架構範例與成本估算

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

什麼是高可用性？

高可用性（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 秒	關鍵基礎設施

實現高可用的三大支柱：

冗餘（Redundancy）：消除單點故障，任何元件故障都有備援
自動化（Automation）：自動偵測故障、自動擴容、自動恢復
監控（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 的核心優勢

Autoscaling（自動擴縮容）
- 流量增加時自動新增 VM
- 流量降低時自動刪除 VM
- 節省成本，避免過度配置
Autohealing（自動修復）
- 偵測到故障 VM 自動刪除並重建
- 無需人工介入
Rolling Updates（滾動更新）
- 逐步更新應用程式版本
- 避免全部實例同時停機
Regional MIG
- 跨多個可用區部署
- 某區故障時其他區繼續服務

Autoscaling 三種模式 (2026 最新)

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 使用率的每日／每週週期，在預期負載到達前約 5 分鐘提前擴容；它沒有 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

# 設定 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）。

最佳實踐：

/health endpoint 應該檢查關鍵依賴（資料庫、快取、外部 API）
initial-delay 要大於應用最慢啟動時間
unhealthy-threshold 至少設 3，避免暫時性故障誤判
Load Balancer 和 Autohealing 應使用不同的 Health Check（LB 要快速反應，Autohealing 要謹慎）

三、負載平衡器：流量分配的藝術

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	微服務間的內部通訊

核心功能：

✅ URL 路徑路由：/api/* → API 伺服器，/images/* → 圖片伺服器
✅ Header-based 路由：根據 User-Agent 分配到不同後端
✅ SSL/TLS 終止：在 Load Balancer 解密，後端伺服器減輕負擔
✅ WebSocket 支援
✅ 整合 Cloud CDN 和 Cloud Armor

Network Load Balancer (Layer 4 - TCP/UDP)

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

Proxy 模式：

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

Passthrough 模式：

保留客戶端來源 IP
支援 UDP、ESP、ICMP 等協議
無代理開銷，性能更高

適用場景：

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

如何選擇 Load Balancer？

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

實戰範例：配置 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

運作流程：

使用者訪問 https://yourdomain.com
Global Load Balancer 將請求路由到最近的健康後端
若亞洲區域的 MIG 故障，自動轉向歐洲或美洲
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% ↓

🆕 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 年重要更新包括：

Hierarchical Security Policies（階層式安全政策）
- 在組織層級定義基礎安全規則
- 專案層級繼承並擴展規則
- 集中管理，降低維護成本
Network Threat Intelligence (NTI)
- 自動整合威脅情報資料庫
- 封鎖已知惡意 IP 和殭屍網路
- ⚠️ 需訂閱 Cloud Armor Enterprise 方案：威脅情報 feeds（evaluateThreatIntelligence()）與 named IP address lists 屬 Enterprise 功能，Standard 方案無法使用
🆕 Edge Security Policies（邊緣安全政策）
- 在 Google 邊緣節點層級執行安全規則
- 更早攔截攻擊：惡意流量在到達後端之前就被封鎖
- 降低成本：減少後端伺服器處理惡意請求的負擔
- 適用場景：全球分散式應用、大規模 DDoS 防護
🆕 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

運作方式：

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

Cloud CDN + Cloud Armor 整合

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

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

最佳實踐：

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

五、多區域容錯設計：災難恢復的終極方案

為什麼需要多區域部署？

單區域風險：

❌ 整個資料中心斷電（例如：2021 年 Google us-central1 大規模斷電）
❌ 光纖被挖斷（網路中斷）
❌ 天災（地震、颱風、洪水）

多區域優勢：

✅ 某區域完全失效，其他區域繼續服務
✅ 降低全球使用者延遲（就近存取）
✅ 符合資料主權法規（例如：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

特性：

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

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（如本節稍後的範例所示）。

配置範例

# 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

運作方式：

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

跨「區域（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：高可用的域名解析

自動故障轉移：

# 建立健康檢查
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"

地理路由：使用者自動解析到最近的 IP 地址。

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 台	$48.55/台	$728.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
總計			$20,766.45

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

成本優化建議：

使用 Committed Use Discounts
- 承諾使用 1 年：節省 37%
- 承諾使用 3 年：節省 55%
使用 Preemptible VM
- 適合非關鍵的批次處理工作
- 成本僅為一般 VM 的 20%
調整 Autoscaling 參數
- 設定合理的 minReplicas 和 maxReplicas
- 避免過度配置
善用 Cloud CDN
- 減少源伺服器流量，降低運算成本

總結

到這裡，GCP 高可用架構的幾個核心技術你大致都摸過一輪了：

✅ Managed Instance Group：自動擴縮容、自動修復、滾動更新 ✅ Load Balancer 選型：根據需求選擇 Application LB 或 Network LB ✅ Cloud CDN + Cloud Armor：全球加速 + DDoS/WAF 防護 ✅ 多區域容錯：Regional MIG、Multi-Regional 部署、Cloud Spanner ✅ 完整架構範例：三層式架構 + 成本估算

下一步行動

動手實作
- 建立你的第一個 MIG + Load Balancer
- 啟用 Cloud CDN 並測試效能提升
- 配置 Cloud Armor 安全政策
深入學習
- GCP High Availability 官方文檔
- Qwiklabs：Architecting with GCP
考取認證
- Professional Cloud Architect 認證會深入考核高可用架構設計

延伸閱讀

相關主題推薦：

ACE 架構設計 — 2/5 完成查看系列全覽 →

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

什麼是高可用性？

GCP 高可用架構的關鍵服務

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

什麼是 Managed Instance Group (MIG)？

MIG 的核心優勢

Autoscaling 三種模式 (2026 最新)

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

2. Predictive Autoscaling（預測式）

3. Scheduled Autoscaling（排程式）

健康檢查（Health Check）配置

Health Check 類型選擇

Autohealing 行為

三、負載平衡器：流量分配的藝術

GCP Load Balancer 類型選擇

Application Load Balancer (Layer 7 - HTTP/HTTPS)

Network Load Balancer (Layer 4 - TCP/UDP)

如何選擇 Load Balancer？

實戰範例：配置 Global Application Load Balancer

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

Cloud CDN：讓全球使用者感受飛快體驗

什麼是 CDN？

啟用 Cloud CDN

效能提升實例

🆕 2025-2026 Cloud CDN 重要更新

Cloud Armor：抵禦 DDoS 與 Web 攻擊

2025-2026 最新功能

建立 Cloud Armor 安全政策

Adaptive Protection（自適應防護）

Cloud CDN + Cloud Armor 整合

五、多區域容錯設計：災難恢復的終極方案

為什麼需要多區域部署？

Regional MIG vs Multi-Regional 部署

Regional MIG（跨可用區）

Multi-Regional 部署（跨區域）

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

Cloud SQL 跨區域複製

Cloud Spanner 全球分散式資料庫

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

N+1 Zonal Redundancy

配置範例

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

Cloud DNS：高可用的域名解析

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

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

典型的三層式高可用架構

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

總結

下一步行動

延伸閱讀

相關文章

無伺服器時代：App Engine、Cloud Run 與 GKE 選型策略完全指南

GCP AI 與大數據：從 BigQuery 到生成式 AI 的完整工具鏈

相關學習資源

留言討論