效能優化的架構思維
效能優化不是「寫完再調」的事後補救，而是架構設計的核心考量。身為架構師，你的首要任務是找到瓶頸在哪，而不是憑直覺亂調參數。
系統效能瓶頸通常落在四個維度：
| 瓶頸維度 | 常見徵兆 | 診斷工具 |
|---|---|---|
| 運算（Compute） | CPU 使用率持續 > 80%、請求延遲上升 | Cloud Monitoring、Cloud Profiler |
| 網路（Network） | 高延遲、跨區域傳輸費用異常 | Network Intelligence Center、VPC Flow Logs |
| 儲存（Storage） | IOPS 飽和、磁碟佇列深度過高 | Persistent Disk 監控指標 |
| 資料庫（Database） | 慢查詢、連線池耗盡、鎖爭用 | Cloud SQL Insights、BigQuery INFORMATION_SCHEMA |
Amdahl’s Law 的啟示：如果一個系統有 90% 的時間花在資料庫查詢上，即使你把其餘 10% 的運算速度提升 10 倍，整體效能也只改善約 10%。永遠先量測、再優化，把力氣花在佔比最大的瓶頸上。
💡 考試小提示：PCA 題目常問「如何改善系統延遲」——正確答案通常是先分析瓶頸（Cloud Profiler、Cloud Trace），而非直接加機器。
Cloud CDN
Cloud CDN 利用 Google 遍布全球超過 100 個快取節點快取靜態和動態內容，大幅降低使用者端延遲。它與 Cloud Load Balancing 深度整合，只需勾選一個選項即可啟用。
快取模式（Cache Modes）
| 模式 | 行為 | 適用場景 |
|---|---|---|
| CACHE_ALL_STATIC | 自動快取圖片、CSS、JS 等靜態資源（即使 origin 沒設 Cache-Control header） | 大部分網站，快速上手 |
| USE_ORIGIN_HEADERS | 完全依據 origin 回應的 Cache-Control header 決定快取策略 | 需要精細控制快取行為的應用 |
| FORCE_CACHE_ALL | 快取所有回應（包含動態內容） | API 回應變化頻率低的場景，需謹慎使用 |
關鍵設計要點
- Cache Keys — 預設包含 URI 和 Host，可自訂排除或包含 query string、header、cookie，減少不必要的 cache miss
- Cache Invalidation — 支援路徑模式（如
/images/*）批次清除，但不可濫用——CDN 設計應以 TTL 為主，invalidation 為例外 - Signed URLs / Signed Cookies — 保護付費內容或敏感資源，設定到期時間，防止未授權存取
💡 考試小提示：題目描述「全球使用者存取靜態資源延遲高」，答案指向 Cloud CDN + Global HTTP(S) Load Balancer。如果需要保護內容，加上 Signed URLs。
Memorystore
Memorystore 是 GCP 的全代管記憶體資料存放服務，提供毫秒以下（sub-millisecond）延遲的資料存取，是效能優化的殺手級武器。
Redis vs Memcached
| 面向 | Memorystore for Redis | Memorystore for Memcached |
|---|---|---|
| 資料結構 | 豐富（String、Hash、List、Set、Sorted Set、Stream） | 簡單 key-value |
| 持久化 | 支援 RDB/AOF 快照 | 不支援（純快取） |
| 高可用 | 自動故障轉移（HA 模式） | 需自行處理節點故障 |
| 叢集模式 | Redis Cluster（水平擴展至 TB 級） | 原生支援多節點分散 |
| 適用場景 | Session 快取、排行榜、速率限制、Pub/Sub | 大規模簡單快取（HTML Fragment、DB 查詢結果） |
架構設計考量
- Redis Cluster — 當單節點記憶體不足時，透過分片（sharding）水平擴展。支援線上擴縮容，不中斷服務
- 容量規劃 — 記憶體使用建議不超過 80%，預留空間給 fragmentation 和 replication buffer
- HA 設定 — 生產環境必選 HA 模式，自動 failover 時間通常在數秒內完成
💡 考試小提示：「需要毫秒以下快取且支援複雜資料結構」選 Redis；「只需要簡單的分散式快取，追求最大吞吐量」選 Memcached。
非同步處理模式
非同步架構是可擴展性的基石——將耗時操作從請求路徑中解耦，讓前端快速回應，背景處理繁重工作。
Pub/Sub：事件驅動的訊息中介
Pub/Sub 是 GCP 的全代管訊息佇列服務，支援全球規模的事件串流：
| 特性 | 說明 |
|---|---|
| 交付保證 | At-least-once（標準），Exactly-once（啟用 exactly-once delivery） |
| Push vs Pull | Push：Pub/Sub 主動呼叫 HTTP endpoint；Pull：訂閱者主動拉取訊息 |
| Dead-letter Topic | 多次處理失敗的訊息自動轉移至死信主題，避免阻塞佇列 |
| Ordering Keys | 確保相同 key 的訊息按順序交付（如同一用戶的事件） |
| 訊息保留 | 最長 31 天，支援 seek 功能回溯重新處理 |
Push vs Pull 選擇：Push 適合 Cloud Run / Cloud Run functions 等 serverless 架構（自動觸發）；Pull 適合需要控制處理速率的長時間運行工作負載。
Cloud Tasks：任務佇列
Cloud Tasks 與 Pub/Sub 的核心差異在於——它是任務導向而非事件導向：
- 速率限制（Rate Limiting） — 精確控制每秒派送多少任務給目標服務，保護下游不被流量壓垮
- 排程延遲（Scheduled Delay） — 指定任務在未來某個時間點執行
- 重試設定 — 自訂重試次數、退避策略（exponential backoff）
- 去重（Deduplication） — 透過 task ID 防止重複任務
Cloud Scheduler：排程即服務
Cloud Scheduler 是全代管的 cron 服務，支援三種目標：
- HTTP — 呼叫任意 HTTP endpoint（Cloud Run、Cloud Run functions、外部 API）
- Pub/Sub — 發送訊息至 Pub/Sub topic
- App Engine — 直接觸發 App Engine handler
典型用途：定期報表產出、排程資料同步、定時清理過期資源。
💡 考試小提示：「解耦微服務之間的通訊」用 Pub/Sub；「需要精確控制任務派送速率」用 Cloud Tasks；「需要定時觸發工作」用 Cloud Scheduler。
可擴展性設計模式
水平擴展 vs 垂直擴展
| 策略 | 做法 | 優勢 | 限制 |
|---|---|---|---|
| 垂直擴展（Scale Up） | 升級單一機器的 CPU / 記憶體 | 簡單、無需改程式碼 | 有硬體上限，單點故障風險 |
| 水平擴展（Scale Out） | 增加更多相同規格的機器 | 理論上無上限，容錯性高 | 需要無狀態設計（Stateless） |
關鍵設計原則
- Stateless Design — 應用狀態外部化（存到 Memorystore、Cloud SQL 或 Firestore），每個實例可獨立處理任何請求
- Sharding（分片） — 將資料按 key 分散到多個節點，Spanner 和 Bigtable 原生支援自動分片
- Partitioning（分區） — BigQuery 按日期或整數範圍分區，查詢時只掃描必要的分區，大幅降低成本和延遲
- Event-driven Architecture — 用事件（Pub/Sub、Eventarc）取代直接 API 呼叫，實現鬆耦合
- CQRS（Command Query Responsibility Segregation） — 讀寫分離，寫入走主庫（Cloud SQL Primary），讀取走 Read Replica 或快取層（Memorystore），各自獨立擴展
Gemini Cloud Assist：AI 驅動的效能優化
Gemini Cloud Assist（v6.1 新增考試範圍）是 Google Cloud Console 內建的 AI 助手，為效能調校帶來全新的工作模式：
- 效能建議 — 分析 Cloud Monitoring 指標，主動推薦資源 right-sizing（如「這個 VM 的 CPU 使用率長期低於 20%，建議降級至 e2-medium」）
- 故障排除協助 — 用自然語言描述問題（如「為什麼我的 Cloud SQL 延遲突然飆高？」），Gemini 會分析相關日誌和指標給出診斷建議
- 架構最佳化 — 根據工作負載模式建議快取策略、負載平衡設定、自動擴縮參數
💡 考試小提示：Gemini Cloud Assist 是 PCA v6.1 新增範圍。題目提到「AI 輔助維運」或「智慧化效能建議」，記得這個選項。
資料庫效能優化
查詢與連線優化
- Query Optimization — 使用 Cloud SQL Insights 識別慢查詢，建立適當索引，避免 full table scan
- Connection Pooling — 透過 Cloud SQL Auth Proxy 管理連線，搭配應用層連線池（如 HikariCP、pgBouncer），避免連線數爆炸
- Read Replicas — Cloud SQL 和 AlloyDB 支援跨區域 Read Replica，將讀取流量分散，主庫專注寫入
快取策略與大數據效能
- Cache-Aside Pattern — 應用先查 Memorystore，miss 時查資料庫並回填快取，適合讀多寫少的工作負載
- Write-Through Pattern — 寫入時同時更新資料庫和快取，確保快取一致性，適合對資料新鮮度要求高的場景
- BigQuery Slot Reservations — 為關鍵工作負載預留運算 slot，避免隨需（on-demand）模式下與其他查詢爭搶資源，確保穩定的查詢效能
實戰情境
情境一：電商限時搶購的流量突增
背景：Cymbal Shops 每月舉辦限時搶購活動，流量在活動開始的前 30 秒內從平時的 500 RPS 飆升至 50,000 RPS，過去三次活動都導致系統崩潰。
架構決策：
- 前端靜態資源 — 透過 Cloud CDN（CACHE_ALL_STATIC 模式）快取商品圖片和頁面框架，80% 的請求不到達 origin
- 應用層 — Cloud Run 搭配 minimum instances = 50 預熱，避免冷啟動延遲；設計為完全 Stateless，session 存放在 Memorystore
- 搶購佇列 — 使用者點擊「立即搶購」後，請求寫入 Cloud Tasks（啟用去重防止重複提交），設定速率限制保護庫存資料庫
- 庫存快取 — Memorystore for Redis 的 DECR 原子操作進行即時庫存扣減，Redis 庫存歸零後直接回傳「已售罄」，不再查詢資料庫
- 結果通知 — 訂單處理結果透過 Pub/Sub 推送至通知服務，非同步發送確認信
情境二：即時遊戲排行榜
背景：一款手機遊戲有 200 萬日活躍玩家，需要全球即時排行榜，排名更新延遲不能超過 500ms。
架構決策：
- 排行榜儲存 — 使用 Memorystore for Redis Cluster 的 Sorted Set 資料結構，ZADD 更新分數、ZREVRANGE 取得排名，單次操作 < 1ms
- 資料持久化 — Redis 分數變更透過 Pub/Sub 非同步寫入 Cloud Spanner 作為永久記錄（每分鐘批次寫入，非逐筆）
- 全球存取 — 每個區域部署獨立 Redis Cluster，透過 Cloud Scheduler 每 30 秒觸發跨區域排名同步任務
- 防作弊 — 分數更新先經驗證服務檢查合理性，異常分數寫入 Dead-letter Topic 供人工審查
- CQRS 應用 — 寫入路徑（分數更新）和讀取路徑（排行榜查詢）完全分離，各自獨立擴展
重點整理
- 先量測、再優化 — 用 Cloud Profiler 和 Cloud Trace 找出真正的瓶頸，Amdahl’s Law 告訴你把力氣花在佔比最大的地方
- Cloud CDN 搭配 Global Load Balancer 大幅降低靜態資源延遲，Signed URLs 保護付費內容
- Memorystore 提供微秒級快取——Redis 適合複雜資料結構和 HA 需求，Memcached 適合大規模簡單快取
- 非同步解耦三劍客：Pub/Sub（事件驅動）、Cloud Tasks（速率控制）、Cloud Scheduler（定時觸發）
- 可擴展性核心：Stateless 設計、水平擴展、CQRS 讀寫分離、Event-driven Architecture
- Gemini Cloud Assist（v6.1 新增）提供 AI 驅動的效能建議和故障排除
- 資料庫效能：連線池、Read Replica、Cache-Aside Pattern、BigQuery Slot Reservations
下一步
在下一課中，我們將探討部署管理與 API 策略，掌握 Apigee API 管理平台、Cloud Deploy 部署策略與 Gemini Cloud Assist 智慧維運。