CCU Capacity Planning（壓測數據推算法）¶
概念概覽
推算公式（可重現框架）¶
核心知識¶
推算公式（可重現框架）¶
# Step 1: Pod 數量
Pod 數 = 目標 CCU / 單 Pod CCU 上限
= 100,000 / 200 = 500 Pod
# Step 2: DB 連線需求
DB 連線數 = Pod 數 × 每 Pod 連線池大小
= 500 × ~83 = 41,472（含 HPA buffer）
# Step 3: IO 需求（線性推算）
目標 WAL = 單 Pod 實測 WAL × Pod 數
≈ 4.26–6.01 MB/s × 500 ≈ 2,130–3,005 MB/s
壓測必量指標清單¶
- DB 連線數（active vs idle 分開量測）
- WAL 寫入速率 + Checkpoint 頻率
- Valkey cache hit rate（影響 RDS write TPS 估算）
- Pod CPU/Memory 實際使用率（驗證 Pod 規格假設）
不確定性處理¶
- Valkey cache hit rate 未知：hit rate 越高 RDS 壓力越小，hit rate 偏低則寫入 TPS 成為新瓶頸
- 建議：從 loadtest 或線上 Valkey metrics 取得實測數據後，再精確估算 RDS write TPS
經驗教訓¶
-
容量規劃必須從真實壓測數據出發，不能只用理論公式估算
-
連線池引入後需要單獨壓測 Pooler 的延遲影響，Pooler 本身可能成為新瓶頸
-
Valkey cache hit rate 是影響 RDS 實際負載的關鍵未知數，容量規劃前應先取得此數據
常見陷阱¶
-
線性推算假設負載均勻分布，實際 peak 流量可能有突發倍數，需加入安全係數
-
只壓測到 P3 規模就線性推算到 P5，中間可能出現非線性瓶頸（如鎖競爭）
最佳實踐¶
-
壓測時盡量測到目標 CCU 的 20–30%，再線性推算，誤差較小
-
容量規劃應同時識別所有並行瓶頸，不要解決一個就停止分析
-
建立瓶頸清單：連線數、IO throughput、CPU、Cache hit rate，逐一量化
相關概念¶
- Architecture Audit Methodology
- Aurora IO Pricing
- Aurora RDS Proxy
- EKS Node Group Migration Runbook
- PostgreSQL Checkpoint IO Storm
- RDS PostgreSQL Connection Pool (Transaction Mode)
- Redis Sorted-Set TTL GC Capacity Bomb
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- PostgreSQL Write Capacity Planning — 共享：
capacity-planning/ 獨特：1m-ccu,database
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-25 | 135234ac-cc13-4bd9-92f0-c123f2169ae2 | 建立從單 Pod 壓測數據出發，系統推算 100k CCU 所需 Pod 數、DB 連線數、IO 需求的可重現方法論 |