服務定位

k6 是 Grafana Labs 旗下的 scriptable load testing 工具、2021 年被 Grafana 收購。產品線分兩層：k6 OSS（Go 寫的 engine + JS API 描述 scenario、CLI 為主、output 可丟 Prometheus / InfluxDB / JSON / CSV）跟 Grafana Cloud k6（前 k6 Cloud、SaaS 多 region runner + 結果保存 + 跟 Grafana Cloud dashboard / Loki / Tempo 同 plane）。底層 engine 是 Go、不是 JS — JS 只是 scenario 描述層、runtime 由 Go 跑、所以單機 VU 容量比 Python-based 工具高出一個量級。

跟 JMeter 比、k6 走 code-first + CI-friendly、JMeter 走 XML / GUI + plugin ecosystem；JMeter 在 protocol 廣度（JDBC / LDAP / JMS / FTP）跟非工程團隊操作勝出、k6 在版控、PR review、artifact pipeline 勝出。跟 Locust 比、k6 用 JS、Locust 用 Python；Locust 對 Python team 自然、但 Python GIL 讓單機 VU 容量受限、需多 worker、k6 單機可跑數千 VU。跟 Gatling 比、Gatling 走 JVM + Scala/Java/Kotlin DSL、適合 JVM-heavy 團隊；k6 的 threshold + Grafana ecosystem 整合在 release gate 場景更直接。

定位

k6 適合把壓測納入工程流程。當團隊已經能描述 traffic shape、endpoint mix、arrival rate、think time 與 stop condition，k6 可以把這些模型寫成腳本，讓每次 release、capacity review 或 peak-event readiness 都能重跑同一組驗證。

這個定位讓 k6 接到三個主章。它從 9.2 Workload Modeling 接收流量模型，從 9.4 Saturation Discovery 接收 ramp-up 與 knee point 判讀，從 9.10 Production-Side 驗證 接收 canary、dark launch 或 production-like load test 的安全邊界。

適用場景

API 壓測是 k6 最穩定的入口。Checkout、login、search、order query、payment callback mock 與 internal API 都可以用 scenario 表達，並用 threshold 把 latency、error rate 與 throughput 轉成 pass / fail 訊號。

CI performance gate 是 k6 的常見價值。團隊可以在 merge、nightly、pre-release 或 game day 前跑固定 baseline，觀察 p95 / p99、error rate、throughput 與 regression trend，再把結果交給 6.13 Performance Regression Gate。

Peak readiness rehearsal 適合用 k6 表達階段式負載。活動前可以用 ramping arrival rate 模擬 T-90、T-30、T-7、T-1 與 T-0 的負載階段，並把結果回寫到 9.11 高峰事件準備。

最短判讀路徑

判斷 k6 deployment 是否健康、最少看四件事：

• Scenario design：用 executor: ramping-arrival-rate 而非 constant-vus、把 RPS / arrival rate 設成 first-class、VU 由 engine 自動算；scenario 描述跟 9.2 Workload Modeling 的 endpoint mix、think time、cohort 對得起來
• Threshold gate：thresholds 區塊明確寫 p95 / p99 / error rate / throughput、CI fail 條件清楚、不靠人眼看 summary 判斷 pass / fail
• Output 進 observability stack：--out experimental-prometheus-rw 把 metric remote-write 到 Prometheus、Grafana dashboard 接 k6 同 datasource、結果跟 target service 的 saturation metric 在同一張圖上看
• k6 Cloud vs CLI 邊界：本地 CLI 跑 baseline + CI、Grafana Cloud k6 跑跨 region / 大規模 / 結果 retention；不要把 CI gate 放 Cloud（成本 + 時間不對）、也不要本地單機硬跑 100k VU（runner 自身瓶頸假象）

四件事任一缺失、就是 scenario 已經寫得不完整、threshold gate 失效、或 runner 觀測缺失。

選型判準

腳本化價值來自可重跑。一次性的壓測只能回答當天配置能撐多少；可版本化 scenario 可以回答 release 後容量曲線有沒有漂移，並讓退化調查回到同一份 workload model。

CI 友善價值來自交接成本低。壓測結果要能轉成 artifact、threshold、trend 與 gate decision，才會從「工程師手動跑工具」變成 release 流程的一部分。

API 導向價值來自後端路徑明確。k6 很適合 checkout API、search API、internal API 與 webhook receiver；如果主要問題是完整 browser UX、第三方真實支付或多裝置同步，文章要把資料準備、side effect 與環境隔離另外寫清楚。

跟其他工具的取捨

k6 和 JMeter 的主要差異是工作方式。k6 偏程式化腳本、CLI、CI artifact 與工程流程；JMeter 偏 GUI、protocol plugin、既有企業測試流程與非工程團隊協作。

k6 和 Gatling 的主要差異是生態與語言。k6 使用 JavaScript-style 腳本，Gatling 偏 JVM / Scala / Java / Kotlin 生態；團隊語言能力與既有 pipeline 會影響維護成本。

k6 和 Locust 的主要差異是團隊技能與模型表達。Locust 使用 Python，對 Python 團隊與 custom user behavior 很自然；k6 的 threshold、CLI 與雲端 / Grafana 生態讓 release gate 整合更直接。

k6 和 Vegeta 的主要差異是場景複雜度。Vegeta 適合簡單 HTTP load、CLI workflow 與快速 saturation 探測；k6 適合較完整的 multi-step scenario、threshold 與長期 baseline。

核心取捨表

選 k6 的核心訴求：API-first scenario + CI gate + Grafana / Prometheus ecosystem 已用、且團隊接受 JS DSL。Protocol 廣度需求大、走 JMeter；Python team、走 Locust；JVM-heavy、走 Gatling。

進階主題

k6 Browser：基於 Chromium + Playwright API、跑在 k6 同 scenario 內、可混 protocol-level 跟 browser-level load（前段 API call、後段真實 browser flow）。意義是「pure API load 跟 real user UX 在同一份 scenario」、不用維護兩套工具。但 browser VU 比 protocol VU 重幾十倍、runner cost 要重新算。

xk6 extensions：用 Go 寫 k6 extension、補 protocol（Kafka / Redis / SQL / AMQP）或 output（custom backend）。xk6 build 生出客製 binary、organization 可維護自家 extension。意義是 k6 不只跑 HTTP — Kafka producer load / Redis hot-key probe 都能用同一個 scenario harness。

Grafana Cloud k6（前 k6 Cloud）：SaaS 跑 multi-region runner、結果保存、跟 Grafana Cloud dashboard / Loki / Tempo / Prometheus 同 plane。適合 跨 region 真實延遲驗證、大規模 distributed run、結果 retention + team share。跟 Grafana Cloud 已用的團隊 ecosystem 一致；只用 OSS 的團隊走 k6 Operator on k8s。

Distributed execution：自管 distributed 走 k6 Operator on Kubernetes、scenario 拆 instance、結果 aggregate 到 output。意義是不需要 k6 Cloud 也能跑跨機器 load、但 runner pool 自管成本 + 結果 aggregation 自己處理。

Output integration：--out experimental-prometheus-rw 直接 remote-write 到 Prometheus、Grafana dashboard 一張圖看 k6 client metric + target service saturation；--out cloud 上 Grafana Cloud k6；--out json=... 落地檔案給 CI artifact；--out influxdb 接 InfluxDB（legacy）。Loki 用來接 k6 console log、Tempo 用來接 k6 trace（若 scenario 帶 W3C trace context）。

排錯與失敗快速判讀

• VU 跑不上去 / runner CPU 滿：scenario 寫了重 JS 邏輯（big JSON parse、複雜 regex、crypto）— 把 setup-once 邏輯搬 setup()、不要每 VU iteration 重算
• Resource throttling 假象：runner 機器 CPU / network bandwidth / file descriptor 自身瓶頸、target service 還沒到 saturation — 換大機 / 多 runner / 看 runner 自身 saturation metric 排除
• Threshold 設過嚴 / CI 一直 red：threshold 抄 production SLO 不留 budget — staging tenant 跑 5-10 次抓 baseline distribution、threshold 設 baseline + buffer、不是 SLO 直接搬
• p95 看起來好但 user 抱怨慢：scenario endpoint mix 跟 production traffic shape 不符 — 補 production endpoint distribution、按 weight 配 scenario、跟 9.2 Workload Modeling 對齊
• Script logic 太重 / VU iteration 不穩：在 scenario 內做 token refresh / large payload 處理、iteration 時間漂移 — 用 executor: ramping-arrival-rate 鎖 RPS 而非 VU count、iteration 時間漂移由 engine 吸收
• 結果無法回放 / 找不到 baseline：output 沒落 artifact、Grafana dashboard 沒存 time range — 每次 run 強制 --out json + tag scenario version + push 到 evidence package

操作成本

k6 的主要成本是 workload model 維護。腳本本身容易寫，真正的成本在 production endpoint mix、資料分布、tenant / region / user cohort、think time 與 peak shape 的持續校正。

Runner 成本會隨負載規模上升。單機 runner 適合小型 API baseline；跨 region、數十萬 RPS 或長時間 soak test 需要分散式 runner、網路成本、目標服務隔離與觀測儲存。

測試資料治理是高風險成本。Checkout、payment、order、email、notification 與 webhook 路徑都可能產生 side effect，因此 scenario 要明確定義 test tenant、idempotency key、mock boundary、cleanup 與 stop condition。

Evidence Package

k6 結果應回寫到 evidence package。最小欄位包括 scenario version、target environment、time range、VUs / arrival rate、threshold、p95 / p99、error rate、throughput、target service saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓 release gate 能判斷。k6 的 threshold pass 只是其中一個訊號；gate 還要看 target service 的 CPU、connection、DB latency、cache hit rate、queue lag 與 cloud cost。

案例回寫

k6 目前在 09 案例庫中主要作為工具類承接點，案例主角仍是負載形狀與驗證節奏。它可回寫到 9.C15 Tixcraft 售票壓測 的 pre-event load test 判讀、9.C1 Prime Day readiness 的 staged validation、9.C28 FanDuel 雙峰 workload 的多模型壓測需求、9.C2 GR8 Tech FIFA World Cup readiness 的 54000 TPS @ 25ms p95 驗證、以及 9.C7 Lyft 8x peak 跨 100+ 微服務的獨立 threshold 設計。

這些案例提供的是負載形狀與工程節奏。k6 頁引用案例時，要把 case 轉成 workload model、ramp-up、threshold、runner 規模與 stop condition，並讓工具回到可替換的承載選項 — 例如 GR8 Tech 25ms p95 是 threshold pass / fail 的硬目標、Lyft 的「8x 是特定服務、不是全部 8x」要拆成 per-service scenario。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.4 Saturation Discovery
• 跨模組：6.13 Performance Regression Gate
• 官方：Grafana k6 documentation

壓測理論的角色是讓「加機器能不能解決」這個問題從直覺變成可推導。沒有理論基礎時、容量決策容易陷入「跑壓測 → 看數字 → 加機器」的盲試循環；有理論之後、可以從「現在的延遲 / 吞吐 / 並發量」反推「瓶頸在哪個資源、加什麼有效」。

本章是 9.2-9.12 的共同基礎。後續章節的 workload modeling、saturation discovery、capacity planning、SLO 都會回引本章的數學工具。讀者可以把這章當作「容量規劃的最小詞彙表」、其他章節是這些詞彙的應用情境。

本章不深入推導公式、聚焦在 工程意義。讀完之後讀者能回答：為什麼系統在 80% utilization 就該擴、為什麼加機器會邊際效益遞減、為什麼 sub-ms 延遲需求會反推架構選擇。

Little’s Law：穩態系統的最小數學工具

Little’s Law 用一條等式 L = λW 把三個變數綁在一起：L 是系統內平均並發數、λ 是請求到達率、W 是請求平均逗留時間。這個關係在 穩態（流量已穩定、不在 warmup 階段）必然成立、不需要假設特定分布或服務模式。

工程上最有價值的用法是「反推」。給定預期 RPS λ = 1000 跟 SLO latency 上限 W = 200ms、能算出系統最大穩態並發 L = 1000 × 0.2 = 200。這個 200 直接對應「connection pool size」「thread pool size」「async worker count」這類容量參數 — 訂得比 200 小、系統撐不住預期流量；訂得比 200 大太多、資源浪費。

反向也成立。當 connection pool 卡死在某個 size L、latency budget W 已訂、能算出可支撐的 RPS。這個算法在 capacity planning 階段比 ramp-up 壓測更快、可以先用 Little’s Law 篩掉明顯撐不住的配置、再用壓測驗證剩下的候選。

對應案例：Coinbase sub-ms 把 W 訂在 sub-millisecond、所有架構選擇都從這個 W 反推；Tubi ML p99 < 10ms 從 W 反推 feature lookup 必須 cache hit 路徑、不能回到持久 store。

詳見 Little’s Law 卡片。

Queueing Theory：為什麼 80% 利用率就是 knee

排隊論（M/M/c 模型）解釋了一個常見直覺：「系統在 50% utilization 看似還很閒、80% 就該擴、90% 已經太晚」。這個直覺不是經驗法則、是 數學必然。

M/M/c 系統的平均 queue length 跟 utilization 之間是非線性關係。當 utilization 從 50% 漲到 70%、queue length 約增加 2-3 倍；從 70% 漲到 90%、queue length 增加 10 倍以上。latency 跟 queue length 成正比（Little’s Law 又出現）、所以 latency 也呈現同樣的指數成長。

工程意義：健康系統運轉在 50-70% utilization、超過 80% 就接近 knee、超過 90% 進入不可預測區。「為什麼明明還沒滿就 saturate」的答案就在這條曲線。autoscaler 的 target metric 通常訂在 60-70%、是 queueing theory 推導出的安全邊界、不是工程師憑感覺。

多 server 模型（M/M/c）比單 server（M/M/1）有顯著容量優勢：c 個 server 的有效容量遠超 1 個 server 容量 × c。這也解釋了為什麼水平擴容（多開幾個 instance）通常比垂直擴容（單機加 CPU）划算 — 不只是規模、是 queue 行為的本質差異。

對應案例：GR8 Tech 25ms p95 把 p95 維持在 25ms 同時撐 54K TPS、靠的是 永遠不讓系統進入 knee、AI 預測讓擴容窗口縮短到 reaction time 內。

Universal Scalability Law：擴容會邊際失效

USL（Neil Gunther 提出）的公式 throughput(N) = N / (1 + α(N-1) + βN(N-1)) 解釋了「為什麼加機器到某個點之後 throughput 反而下降」。兩個常數 α 跟 β 描述系統的擴展限制：

• α 是必須序列化的部分（Amdahl’s Law 的對應）。distributed lock、coordinator、單一 leader DB 都是 α 來源。α 越大、線性擴容越早 plateau。
• β 是節點間互相通訊的成本（crosstalk）。cache invalidation broadcast、consensus quorum、cross-region replication 都是 β。β 比 α 更危險、會讓 throughput 在 N 大到某點後 反向下降。

工程上 α 比較好處理 — 把序列化部分拆細、用 partition 切分、用 sharded coordinator。β 比較難 — 通訊本質就需要協調、降低 β 通常要重新設計分散式協議（例如 Spanner 用 TrueTime 把跨節點交易的協調成本降低）。

對應案例：Spanner 線性擴展到 10 億 req/sec — TrueTime API 讓跨地區交易的 β 降到可接受、達成傳統 OLTP 做不到的線性；Coinbase RAFT consensus — RAFT 的 quorum 通訊讓 β 不可降、所以 選擇不橫向擴、改用 z1d + Cluster Placement Group 榨單機。

詳見 USL 卡片。

Saturation Curve：linear → knee → cliff

實際系統的 latency vs throughput 曲線分三段。第一段是 linear region — utilization 低、latency 平穩、加流量幾乎不影響 latency。第二段是 knee — utilization 接近 80%、latency 開始指數成長、再加流量會明顯變慢。第三段是 cliff — 系統進入不穩定區、latency 不可預測、可能 timeout、可能 cascade failure。

容量規劃的關鍵概念是 knee point = 設計容量上限。健康系統運轉在 knee 以下 50-70%、留出 headroom 應付 burst 跟 forecast 誤差。沒有量過 knee 的系統等於「不知道距離崩潰多遠」 — 平日看起來穩、實際隨時可能因為一個小 spike 進入 cliff。

不同 system 的 knee 位置差異很大。stateless service 通常 knee 在 80% CPU；DB 因為 lock contention、knee 可能在 60% utilization；broker / queue 因為 disk I/O bottleneck、knee 可能在 50%。容量規劃時不能一概而論、必須個別量測。

每次重大改動後必須 re-test knee。新增功能、改 ORM、升級 library、調 GC tuning、改 cache 策略 — 任何一個都可能讓 knee 往不好的方向移。

對應案例：Tixcraft DynamoDB IOPS 20 → 135K — partition 設計均勻時 saturation point 可以推到極遠（6750x 擴展）；Amazon Ads 9000 萬 RPS — 線性擴展靠 partition key 均勻、不靠 vendor 神話。

詳見 Saturation Point 卡片。

反推：從業務 KPI 到系統參數

理論工具的真正價值在「反推」 — 不是先設計系統再量測 saturate 多少、是 先訂業務目標再反推系統參數。這層思維把容量規劃從 reactive（撐到撐不住才擴）變成 proactive（按業務需求預先配置）。

反推流程通常從 latency budget 開始（詳見 9.12 SLO 與 Performance Budget）：

1. 從 user-perceived end-to-end latency（例如 p99 500ms）開始
2. 拆到每個 stage（網路、CDN、application、cache、DB、第三方）的 latency 配額
3. 配額決定每個 stage 的設計選擇 — DB 配 50ms → 不能跨 region、application 配 100ms → 不能多層 microservice hop
4. 配額 + 預期 RPS → Little’s Law 算每個 stage 的並發
5. 並發 → 每個 stage 的容量需求 → 實例數 / connection pool size / cache size

反推失敗的常見徵兆：算出來的某個 stage 容量超過 vendor 提供的上限（例如「需要 50 萬 DynamoDB RCU」可能超過單一 table partition 上限）、或某個 stage latency 配額過短（例如 cross-AZ 網路至少 1-2ms、配 0.5ms 不可能達成）。這時要回頭調整 SLO 或重新設計架構。

詳見 Latency Budget 卡片。

案例對照

下一步路由

• 下游：9.2 Workload Modeling（把模型量化成 production traffic）
• 下游：9.4 Saturation Discovery（實測 knee point）
• 跨章節：9.12 SLO 與 Performance Budget（latency budget 拆解）

既建知識卡片

• Little’s Law
• Universal Scalability Law
• Saturation Point
• Latency Budget
• Tail Latency

觀察

2025 年 Prime Day 期間 AWS 主要服務的峰值數字（引自 AWS News Blog）：

基礎設施層面：AWS Graviton 處理器承擔超過 40% 的 EC2 compute、部署超過 87,000 顆 Inferentia / Trainium AI 晶片、AWS Outposts 對機器人下達 5.24 億條指令（年增 160%）。

判讀

Prime Day 是「可預期極端峰值」的標竿。它的容量問題不是「會不會撐住」、而是「準備到什麼程度才划算」。對應主章問題節點：

1. Capacity Planning（9.6）：年度活動的容量計算可以用歷史 baseline × 預期成長 × headroom 三項相乘、但 Prime Day 規模下、每一項的不確定性放大都會變成數百萬美金成本差異。Amazon 公開的年增率（API Gateway +30%、CloudFront +43%、ECS on Fargate +77%）顯示連 Amazon 自己每年的成長預測都不能直線外推。
2. Performance Observability（9.8）：DynamoDB 「1.51 億 RPS、毫秒級回應」這種敘述同時包含吞吐與延遲、是 production-grade 容量地圖的最小單位。只說吞吐不說延伸分布、容量資訊不完整。
3. Improvement Loop（9.9）：FIS 混沌實驗 8 倍於 2024 顯示 Amazon 把「在 Prime Day 之前主動製造失敗」當成必修課、不是事後檢討。這層投資跟容量規劃同等重要。

策略

這個案例可以抽出三個跨平台可重用的工程做法。

1. 把可預期峰值寫進服務級 SLO：Prime Day 在 SQS / Lambda / DynamoDB / Aurora 都建立了內部 SLO baseline、平日跑在 baseline 之下、峰值是擴張到「設計容量」而不是「實驗容量」。這跟 9.12 SLO 與 Performance Budget 直接對齊。
2. pre-scaling + scheduled capacity：CloudFront 43%、API Gateway 30% 的年增率都是 提前算進 容量計畫、不是當天 reactive 擴容。對應 EC2 Auto Scaling 的 predictive / scheduled scaling 模式。
3. 事前主動製造失敗、不靠當天 reactive：FIS 8x 成長代表「在 Prime Day 之前 6800 次 chaos test」、把驗證成本前置到容量規劃階段。這條跟 06.4 Chaos Testing 形成閉環 — 06 講失敗模式驗證、09 講容量地圖、兩者在 Prime Day 級別的事件上必須一起做。

跨平台等效：GCP 的 Compute Engine MIG + Predictive Autoscaler、Azure 的 VM Scale Sets + Predictive Autoscale、Kubernetes 生態的 KEDA + Karpenter 都可以實作同樣的 pre-scaling 策略。差異是 vendor 整合度、不是工程概念。

下一步路由

• 想規劃年度活動容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備
• 想設計可預期峰值的 SLO → 9.12 SLO 與 Performance Budget + 06.6 SLO 與 Error Budget 政策
• 想做事前混沌驗證 → 06.4 Chaos Testing + 06.22 Steady State Definition
• 對照不同形狀的峰值 → 9.C2 GR8 Tech（事件型不可預期峰值）/ 9.C3 Coinbase（無峰值低延遲）

引用源

• AWS services scale to new heights for Prime Day 2025: key metrics and milestones
• Conquering Peak Retail Events with AWS
• Predictive scaling for Amazon EC2 Auto Scaling

服務定位

JMeter 是 Apache Software Foundation 的 OSS load testing tool、Java 寫、用 XML 描述 thread group / sampler / listener 組成的 test plan（.jmx 檔）、支援 GUI 與 CLI（non-GUI / headless）雙模式。它是業界最老牌、protocol 覆蓋最廣的壓測工具 — sampler 直接覆蓋 HTTP、JDBC、JMS、SOAP、FTP、SMTP、IMAP、TCP、JUnit、OS process 等。

跟 k6 比、JMeter 走 GUI-driven + protocol 廣、k6 走 code-first（JavaScript）+ HTTP 為主；JMeter 適合 QA 團隊維護、k6 適合 dev / SRE 寫進 CI。跟 Locust 比、JMeter 用 XML + plugin、Locust 用純 Python class、custom client 彈性 Locust 強但 protocol 內建支援 JMeter 廣。跟 Gatling 比、JMeter 偏 GUI / 多 protocol、Gatling 偏 JVM DSL（Scala / Java / Kotlin）+ async runtime、單機 throughput Gatling 較高但 protocol 廣度與既有資產承接 JMeter 勝。

關鍵張力：GUI / protocol 廣度 ↔ 單機 throughput / CI 友善度 是選 JMeter 的根本取捨。GUI 適合 QA 團隊與跨角色協作、.jmx 又有 plugin 生態與十多年累積；代價是 XML diff 難 review、GUI listener 吃記憶體、CI 整合相比 k6 / Gatling 多一層 packaging。

JMeter 適合測試資產已經存在的組織。當團隊有大量 .jmx 測試計畫、QA 團隊用 GUI 維護 scenario、或壓測需要跨 HTTP、JDBC、JMS 與其他 plugin protocol，JMeter 的價值在於承接組織流程，而不只是產生 HTTP 負載。這個定位讓 JMeter 接到 9.3 壓測工具選型 與 9.10 Production-Side 驗證。它能支援 production-like test 的多系統 dependency，但 evidence package 要補上測試計畫版本、plugin 版本、runner 配置與結果保存方式。

適用場景

多 protocol 壓測是 JMeter 的主要入口。企業服務常同時需要測 HTTP API、JDBC query、JMS queue、FTP 或 mail flow，JMeter 的 sampler 與 plugin 生態能讓同一份測試計畫覆蓋多種 dependency。

GUI 協作適合非純工程團隊。QA、測試中心或受監管環境常需要可視化測試設計、審核與交接，JMeter 的 GUI 能降低跨角色溝通成本。

Legacy 測試資產適合保留 JMeter。既有 .jmx 檔案、listener、plugin 與報表流程如果已經運作多年，重寫到 k6、Gatling 或 Locust 的機會成本要用維護收益抵銷。

最短判讀路徑

判斷 JMeter deployment 是否健康、最少看四件事：

• Thread group 設計：thread count / ramp-up / loop count / duration 是否反映真實流量模型、有沒有用 Stepping Thread Group（plugin）或 Concurrency Thread Group 控制 arrival rate、不是把 thread 當「user」直接綁
• Listener 配置：GUI listener（View Results Tree / Aggregate Report / Graph）只在 design / debug 階段開、正式跑必須改 Simple Data Writer 輸出 JTL、結果分析交給離線 HTML report 或外部 Grafana
• Distributed mode 設定：單機 thread 上限約 3000-5000（受 JVM heap 與 thread context switch 限制）、超過要走 master + slave（remote engine）；slave 機器 plugin / JMeter version / JVM 參數要跟 master 一致、否則結果不可信
• GUI vs CLI 模式區分：GUI 是 design / debug only、production load 一律走 jmeter -n -t plan.jmx -l result.jtl；GUI 跑大規模測試會把 listener 拉爆記憶體、結果反而失真

四件事任一缺、就是 9.3 壓測工具選型 邊界的待補項目。

選型判準

多 protocol 價值來自 dependency coverage。當 workload model 包含 database、queue、file transfer 或 legacy endpoint，JMeter 可以把不同 dependency 的壓力放在同一個測試計畫中觀察。

GUI 協作價值來自跨角色可見性。這個優點會帶來版本控制成本，因為 XML diff 不容易 review；團隊要補上 naming、folder structure、parameterization 與 review checklist。

跟其他工具的取捨

JMeter 和 k6 的主要差異是 workflow。JMeter 偏 GUI、plugin 與既有企業流程；k6 偏 code-first、CLI、threshold 與 CI artifact。

JMeter 和 Gatling 的主要差異是 scenario 表達。JMeter 用 test plan、thread group、sampler 與 listener 組裝；Gatling 用 JVM DSL 描述 simulation，較適合工程團隊維護複雜 flow。

JMeter 和 Locust 的主要差異是自訂能力。JMeter 依賴 plugin 與 sampler，Locust 可以直接用 Python library 實作 custom client；如果 protocol 特別特殊，Python 團隊可能更適合 Locust。

JMeter 和 Vegeta 的主要差異是複雜度。Vegeta 適合快速 HTTP saturation probe；JMeter 適合多步驟、多 dependency 與可交接測試計畫。

操作成本

JMeter 的主要成本是測試計畫治理。.jmx 檔案可以累積大量 listener、debug sampler、hard-coded variable 與過期 assertion，長期不整理會讓壓測結果失去可追溯性。

Runner 成本來自 JVM 與 listener。GUI listener 適合開發階段觀察，不適合大規模壓測；正式測試要使用 non-GUI mode，把結果輸出成 JTL、HTML report 或外部 metrics。

Plugin 成本來自版本漂移。不同 runner、不同工程師機器或 CI image 的 plugin 版本如果不一致，同一份測試計畫可能產生不同結果，因此要把 plugin 清單、JMeter 版本與 container image 固定下來。

Evidence Package

JMeter 結果應回寫到 evidence package。最小欄位包括 test plan version、JMeter version、plugin list、runner topology、thread group 設定、ramp-up、duration、p95 / p99、error rate、throughput、target saturation metric 與 known gap。

Evidence package 的核心用途是讓結果可審查。JMeter 測試計畫常由多人維護，gate decision 要能追到哪一版 .jmx、哪一組 runner、哪一批測試資料與哪一個目標環境。

進階主題

JMeter Plugins 生態：jmeter-plugins.org 社群維護的 plugin 集合補齊原版 JMeter 的不足 — Custom Thread Groups（Stepping / Ultimate / Concurrency / Arrivals）讓 thread schedule 反映真實 arrival rate、PerfMon 抓 remote server CPU / memory、Throughput Shaping Timer 直接以 RPS 為目標而非 thread count、Dummy Sampler 拿來 mock dependency。Plugin Manager 統一安裝、CI image 要把 plugin 清單固定（PluginsManagerCMD.sh install <plugins>）避免漂移。

BlazeMeter Cloud / Distributed execution：自建 distributed mode（master + slave 跨多 VM）成本高 — slave 機器要同 JMeter 版本、同 plugin、同 JVM 參數、RMI port 開通、結果回傳網路足夠。BlazeMeter（Perforce / 前 CA）是 JMeter SaaS、直接吃 .jmx 跑 cloud-scale 壓測、附 geo-distributed runner、適合短期 spike 測試不想自建 distributed cluster 的團隊。trade-off 是 vendor lock-in 跟 per-test 計費 — 長期高頻測試自建較划算。

Distributed mode 細節：master 機器發 control plane（thread group 配置、test plan 分發）、slave 跑 thread 並回傳 sample 結果。瓶頸常出在 master 收結果（RMI / 自訂 protocol），不是 slave 跑不動 — 大規模測試應該關掉 GUI listener、用 Backend Listener 把 metric 即時推到外部時序資料庫、master 只收彙整指標而非每個 sample。同步要點：所有 slave 用同一份 .jmx 與 test data CSV，CSV 不能依賴 master local path。

Backend Listener + Grafana 整合：JMeter 原生 Backend Listener 支援 InfluxDB / Graphite / Elasticsearch、把 active thread / response time / hit / error 即時推出去、Grafana 配 official JMeter dashboard 即時看 throughput / latency curve。這個組合取代 GUI listener、是 distributed mode 的標準觀測方式 — listener overhead 從 master 移到外部時序系統、master 不再被 GUI 拉爆。配合 4 observability 的時序資料庫已有時、JMeter metric 進同一個 Grafana、跟 application 端的 latency / error 並列、加速 6.13 Performance Regression Gate 的對照判讀。

排錯與失敗快速判讀

• GUI 模式吃記憶體爆 / OOM：GUI listener（View Results Tree / Graph）會把所有 sample 留在 heap、跑大規模就 OutOfMemoryError — 設計階段才開 GUI、正式跑切 jmeter -n non-GUI、listener 用 Simple Data Writer 寫 JTL 而非 in-memory aggregate
• Listener 拖累 throughput / 結果失真：太多 listener 同時開、每個 sample 都被多個 listener 處理、JMeter 自身成為瓶頸 — 正式測試只留 Simple Data Writer + Backend Listener、結果分析離線跑 jmeter -g result.jtl -o report/ 產 HTML
• Thread group 計算錯 / 真實流量對不上：把 thread 當「user」直接設、忽略 think time + ramp-up、結果壓出來的是 thread 全速跑而非業務流量 — 改用 Concurrency Thread Group 或 Throughput Shaping Timer 直接以 RPS 為目標、配 Constant Timer 模擬 think time
• Distributed mode 結果跟單機對不上：slave 機器 plugin / JMeter version / JVM heap 不一致、或 CSV 路徑只存在 master — 把 slave 環境 container 化（同 Docker image）、CSV 隨 .jmx 一起分發、--remote-start 統一啟動
• .jmx XML diff 不可 review / merge conflict 多：多人同時改測試計畫、GUI 改完 XML 結構大變 — 拆 fragment（Test Fragment + Module Controller）、scenario 分檔、parameterization 走外部 CSV / properties、PR review 看截圖 + 跑結果而非 raw XML diff
• Plugin 版本漂移 / CI 結果不可重現：dev 機器 plugin 跟 CI image 不同版 — 固定 plugin manifest、CI image 用 PluginsManagerCMD.sh install-for-jmx plan.jmx 從 plan 自動安裝、版本鎖到 image tag
• HTTPS / TLS 連線數爆炸：JMeter 預設每 thread 一個 TLS handshake、large thread count 把 server TLS 拖垮、結果反而測到 TLS 不是 app — 開 HTTP Cache Manager 跟 KeepAlive、必要時調 httpclient4.idletimeout

案例回寫

JMeter 在 09 案例庫中適合作為 enterprise load test 承接點。它可回寫到 9.C15 Tixcraft 售票壓測 的 pre-event validation、9.C17 BookMyShow ticketing 的售票流量模型、9.C1 Prime Day readiness 的 staged validation、9.C13 Hotstar IPL 1860 萬同時觀看 的全球直播 pre-event rehearsal、以及 9.C14 Standard Chartered 跨 7 個受監管市場的 Aurora 4000 TPS 容量驗證。

這些案例提供的是複雜業務流程與活動前驗證節奏。JMeter 頁引用案例時，要把 case 轉成 thread group、ramp-up、data set、dependency sampler 與 result artifact，並讓負載數字回到業務流程判讀 — 例如 Hotstar 的「集中地理區 CDN 壓力」要在 JMeter 用 per-region thread group 模擬、不是把全球流量塞進單一 runner。

下一步路由

• 上游：9.3 壓測工具選型
• 上游：9.10 Production-Side 驗證
• 平行：k6、Gatling、Locust
• 跨模組：6.13 Performance Regression Gate
• 官方：Apache JMeter documentation

Workload modeling 的角色是讓壓測結果有意義。如果壓測模型跟 production traffic shape 不一致、壓測通過不代表 production 撐得住。這一層的工作不是「製造大量請求」、而是「製造跟 production 一樣形狀的請求」。

跟 9.1 壓測理論 的關係：9.1 提供推導工具、9.2 把工具的輸入（流量參數）量化。沒有 workload model、Little’s Law 的 λ 跟 W 都是猜。

本章的核心問題：production traffic 不是「N RPS」這麼簡單。它有時間分布、地理分布、操作分布、cohort 分布、burst pattern。每個維度都會影響系統行為。一個只測「總 RPS」的壓測通過了、production 還是可能因為某個 cohort 集中或某個 burst pattern 出事。

Traffic shape 的五個維度

Production traffic shape 至少要量五個維度才算 model 完整。

平均吞吐 vs 峰值：peak/avg ratio 是工程意義最大的單一指標。1.5x 的 peak/avg 代表流量相對平緩、容量規劃可以接近 average peak；3-5x 的 peak/avg 代表 bursty 流量、必須按 peak 規劃、平日大幅 over-provision。對應案例：ASOS Black Friday 24h 1.67 億 / 峰值 3500 RPS 峰均比約 1.81x 屬於相對溫和；Tixcraft 5 分鐘賣完 是另一極端。

時間分布：日內（早晚通勤）、週內（週末活躍）、月內（月初發薪）、季內（節慶）、年內（活動）。不同尺度的週期都要記錄、用於 forecast 跟 pre-scaling 決策。

用戶分布：geographic（哪個 region 多）、device（mobile vs desktop）、tier（free / paid / VIP）。同樣 RPS、不同分布可能造成完全不同系統行為 — VIP 用戶可能跑更複雜 query、mobile 用戶可能更多 retry、跨 region 用戶可能更多 cross-zone latency。

操作分布：read vs write 比、不同 endpoint 的 mix。一個系統 90% read 跟 50% read 的容量設計完全不同 — read-heavy 可以 cache、write-heavy 必須關注 storage IOPS。

Cohort 與 burst pattern：同一秒的請求不一定均勻 — bursty arrival 比 Poisson arrival 對系統更殘酷。突發 burst 來源：promo 推播、KOL 推廣、新片發布、新聞事件。

對應案例：GR8 Tech 賽事高潮 burst — 賽事「進球瞬間」 burst 比平均流量高 10-50 倍；Disney+ 新片發布 — 同片瞬間集中、cohort 高度集中。

從 production log 抽 workload model

實務上 workload model 不能憑空寫、要從 production data 抽。流程通常分四步：

第一步：data 蒐集。從 access log、APM trace、metric 系統取得 production traffic 樣本。要 sampling（不是全量）、避免影響 production；要包含 至少一個完整 weekly cycle（含週末、含峰谷）；要按 endpoint / per-tenant 分組。

第二步：分組統計。對每組（per endpoint、per tier、per region）計算 percentile（p50 / p95 / p99）、arrival pattern（Poisson、bursty、scheduled）、payload size 分布。輸出是「workload profile」 — 比單一數字更接近 reality。

第三步：序列重播。複製一段 production traffic 的時間序列、保留 inter-arrival timing（不只是 RPS 平均、是 每秒幾個）。這層讓 burst 在壓測重現、不只是「平均壓力均勻分布」。

第四步：脫敏處理。PII（user_id、phone、address）必須匿名化或替換 — 否則壓測環境變成 PII 洩漏點。常見做法：hash + salt + 確保結果 cardinality 跟 production 一致。

production log 通常缺寫入 payload（log 只記 metadata、不記 request body）、要從 application metric 或 schema sample 補。schema sample 用「distinct value 抽樣」、不是「random」 — 確保壓測涵蓋常見 value pattern。

Synthetic load vs production replay

兩種主要壓測方式各有取捨。

Synthetic load：手寫腳本、明確控制每個請求的 shape。優點是好複現、可以針對特定情境設計（例如「測登入失敗 retry」）；缺點是容易脫離 production reality、寫腳本的人會無意識套用自己的偏見。

Production traffic replay：用 GoReplay、Istio mirror、AWS VPC Traffic Mirroring 等工具把 production traffic 複製到測試環境。優點是 最貼近真實、自動帶上 burst 跟 cohort；缺點是消耗 production 下游資源（要算進容量規劃）、PII / 合規處理複雜、replay 環境的下游 mock 不容易做。

混合模式：常態壓測用 synthetic（cheap、可控）、release candidate 驗證用 production replay（真實）、debug 特定 incident 用 特定時段 的 replay。三種工具在不同階段用、不是二選一。

對應案例：FanDuel 雙峰需要兩個 workload model 並行 — 直播 model（CDN heavy、長 session）跟投注 model（低延遲、burst at goal）必須分開壓測、不能合成一個。

詳見 Workload Model 卡片 跟 Shadow Traffic 卡片。

模型驗證：怎麼知道模型像 production

寫了 workload model 之後、怎麼驗證它真的「像 production」？方法是 跑壓測 同時 對比 production metrics。

驗證指標包含：throughput pattern（總 RPS、各 endpoint mix）、latency 分布（p50 / p95 / p99 對比）、resource utilization（CPU / memory / network 行為）、error rate 與 retry pattern。

兩個可能的偏差結果：

• 模型撐不住但 production 撐得住 → 模型太苛刻、可能高估了流量或操作複雜度。usually fine、調整模型參數即可。
• 模型撐得住但 production 撐不住 → 模型不足、漏了某個維度。dangerous、需要回到 data 蒐集階段找漏掉的 pattern。

對應案例：Zoom 30x COVID surge — 之前的 workload model 完全不能用、必須 reset baseline 重新從 post-COVID 流量抽 model；Tixcraft 10K t2.micro 壓測 — 用實際售票場景重播驗證、不是 synthetic 數字。

模型維護：定期 review

Workload model 不是一次抽完就永久有效。業務變化會讓模型過時、過時的模型導出的容量規劃會失準。

需要 re-抽 model 的訊號：

• 新功能上線改變 user journey（例如新增 video upload、user 行為變寫多）
• 新市場進入改變 cohort 分布（例如進入印度市場、mobile share 大幅增加）
• 行銷活動改變 burst pattern（例如新增 push notification、burst 集中度上升）
• 用戶習慣轉變（例如 work-from-home 讓週末跟平日流量比變化）

維護節奏建議每季 review 一次、重大產品改動立即 re-抽。每次 re-抽要 跟前一版對比、量化變化幅度、決定哪些容量計畫要重新評估。

案例對照

下一步路由

• 上游：9.1 壓測理論
• 下游：9.3 壓測工具選型（用什麼工具實作 model）
• 下游：9.4 Saturation Discovery（用 model 跑 ramp-up）
• 跨模組：04 可觀測性模組（production log 來源）

既建知識卡片

• Workload Model
• Shadow Traffic
• Growth Curve
• Peak Forecast

觀察

GR8 Tech 從本地基礎設施遷移到 AWS、重建為微服務架構後的關鍵數字（引自 GR8 Tech case study）：

服務組合：Amazon EKS（Kubernetes 容器編排、跨雲端與本地）、Amazon EC2（compute）、Amazon S3 與 Amazon EBS（儲存）、AWS Auto Scaling 結合 GR8 Tech 自家 AI 預測模型、AWS Infrastructure Event Management（重大賽事支援）。

擴展範圍：「Scaled to 15 markets using AWS」。事件覆蓋：2022 FIFA World Cup 期間零停機。

判讀

GR8 Tech 的工程做法揭露三個事件型峰值的判讀重點。

1. 不可預期 ≠ 不可預測：賽事「何時開打」是已知的（schedule 提前公告）、「賽事內何時爆量」是未知的（進球、加時、最後一分鐘）。AI 預測模型不是預測「會不會有峰值」、而是預測「峰值在 60 秒內可能多大」、把擴容窗口縮短到反應時間之內。對應 9.11 高峰事件準備 跟 9.6 容量規劃模型 的「預測時間尺度」軸。
2. 延遲是業務指標、不是技術指標：「2-3 秒額外延遲」直接造成「投注失敗、客戶流失」。25ms p95 是收入 KPI 而不是 SLO 漂亮數字。對應 9.8 效能可觀測性 把 latency 翻成業務 metric 的責任。
3. 微服務 + 容器編排是擴容粒度的前置：遷移前的單體系統「擴容」只能複製整套系統、成本曲線陡峭。EKS 拆解後可以針對熱點服務（投注引擎、結算引擎）獨立擴容、跟 9.5 瓶頸定位流程 的逐層定位直接對齊。

需要警惕的判讀盲點：54000 TPS @ 25ms 是 公開的成功數字、不是「永遠都這樣」的承諾。AI 預測模型必然有預測誤差、AWS Infrastructure Event Management 也是事件型服務、不是平台預設。這類案例適合作為「目標可達性」的存在證明、不適合直接套用為自家服務的容量假設。

策略

可重用的工程做法：

1. 把賽事 schedule 灌進 capacity forecast：在事件已知的條件下、預先把 baseline 拉高、避免 AI 模型在零起跑時擴容。對應 EC2 Auto Scaling 的 scheduled scaling + predictive scaling 雙模。
2. AI 模型輸入要包含領域訊號：通用 ML autoscaler 用 CPU / latency 預測、領域 autoscaler 還會用 賽事重要性、投注量歷史曲線、下注玩家集中度 等業務訊號。這層讓擴容時機從反應式變成預測式。
3. 熱點服務獨立擴容、不是整體擴容：投注引擎跟結算引擎的峰值時間不一致（投注集中在賽前 + 比賽中、結算集中在賽後）、單獨擴容比整體擴容省 25%+ 成本。
4. AWS Infrastructure Event Management 等廠商支援服務：在年度重大事件可以申請（World Cup、Olympic、Black Friday 等）、提供 pre-scaling 與專屬監控通道。這在 GCP / Azure 也有對等服務（GCP Customer Care Premium、Azure Event Management Support）。

跨平台等效：GCP GKE + Vertical Pod Autoscaler + 自家 ML 預測、Azure AKS + KEDA + Azure ML 預測、自建 Kubernetes + Karpenter + Prometheus 推導模型都可以實作同樣的「預測 + 擴容」模式。

下一步路由

• 想做事件型峰值的容量預測 → 9.11 高峰事件準備 + 9.6 容量規劃模型
• 想用 AI / ML 做預測式擴容 → 9.9 Performance Improvement Loop + 9.8 效能可觀測性
• 想拆解微服務以便獨立擴容 → 9.5 瓶頸定位流程 + 9.7 成本邊界與 efficiency
• 對照不同形狀的峰值 → 9.C1 AWS Prime Day（可預期極端峰值）/ 9.C3 Coinbase（無峰值低延遲）

引用源

• GR8 Tech Achieves High Performance and Scalability with Data Center Migration to AWS
• Predictive scaling for Amazon EC2 Auto Scaling
• Scheduled scaling for Amazon EC2 Auto Scaling

服務定位

Gatling 是 Scala-origin / 現以 Java DSL 為主流 的 load testing 工具、跑在 JVM、async / non-blocking engine（基於 Akka / Netty）讓單一 injector node 就能驅動高 RPS。它跟 k6 / JMeter / Locust 的核心差異在 語言生態 + engine efficiency + scenario 表達力、壓出負載的能力都具備：

• vs k6 — k6 走 Go runtime + JavaScript scripting、CLI / Grafana 生態友善；Gatling 走 JVM + Java/Scala/Kotlin DSL、適合既有 JVM 工具鏈與強型別 review
• vs JMeter — JMeter 走 GUI / XML test plan、適合非工程角色協作；Gatling 走 code-first、適合 PR / build pipeline / refactor 工作流
• vs Locust — Locust 走 Python coroutine、scripting 自由度高；Gatling 走 DSL + injection profile、scenario 結構化程度更高
• engine efficiency — async / non-blocking model 讓 Gatling 在單機可推到數萬 RPS、JMeter thread-per-user 在同等資源下 throughput 較低

產品線分兩層：Gatling OSS（開源 simulation runner + HTML report）與 Gatling Enterprise（前身 FrontLine、加上 distributed injector、cluster orchestration、live monitoring、long-term result storage、role-based access）。OSS 適合單機 baseline / CI smoke、Enterprise 適合 cross-region distributed / 大型活動前壓測 / 結果長期治理。

最短判讀路徑

判斷 Gatling 在壓測流程裡是否健康、最少看四件事：

• Scala DSL vs Java DSL 版本：Gatling 3.7+（2022）正式加 Java DSL、2024 後新專案多走 Java DSL；舊 Scala simulation 仍可跑、但團隊要決定 維持 Scala 還是漸進改寫 Java、避免雙語言治理
• Injection profile 設計：simulation 是否明確區分 open model（rampUsersPerSec / constantUsersPerSec、模擬真實 arrival）vs closed model（atOnceUsers / rampUsers、模擬 fixed user pool），對應 9.2 Workload Modeling 的 traffic shape
• Assertion gate：simulation 是否有 assertions { global.responseTime.percentile3.lt(500) } 這類 hard gate、CI 跑完直接 fail build；沒 assertion 的 simulation 只是壓測、不是 release gate
• Enterprise vs OSS 邊界：是否清楚知道哪些能力只 Enterprise 有（distributed injector / multi-region / long-term result storage / live dashboard）、避免用 OSS 拼湊 Enterprise 級需求

定位

Gatling 適合 code-first 且 JVM 能力強的團隊。當 workload model 需要多步驟 flow、資料 feeder、條件分支、session state 與明確 injection profile，Gatling 能用 simulation 把這些行為寫成工程 artifact。

這個定位讓 Gatling 接到 9.2 Workload Modeling 與 9.4 Saturation Discovery。它的價值在於把 traffic shape 寫進 injection profile，讓 ramp-up、constant users、stress peak 與 soak test 都能被版本化。

適用場景

JVM 團隊適合用 Gatling 承接壓測。Java、Scala 或 Kotlin 團隊能把 simulation 當成一般程式碼 review，並用既有 build、dependency、CI 與 artifact 流程維護。

複雜 scenario 適合用 Gatling 表達。登入、搜尋、加入購物車、checkout、payment mock、order query 這類 multi-step flow 可以用 session 與 feeder 管理資料。

高品質 report 適合 release review。Gatling 的 report 能幫 reviewer 看到 response time distribution、request group、error 與 injection profile，適合在 release gate 中保留可讀證據。

選型判準

JVM DSL 價值來自可維護性。壓測 scenario 如果需要被長期 review、重構、抽 helper 或接 build pipeline，Gatling 的 code-first workflow 會比 GUI test plan 更適合工程團隊。

Injection profile 價值來自負載形狀精準。團隊可以把 steady load、spike、ramp、open model 與 closed model 放到 simulation 中，讓 9.4 Saturation Discovery 的 knee point 判讀更可重現。

跟其他工具的取捨

Gatling 和 k6 的主要差異是語言與生態。Gatling 適合 JVM 團隊與強型別 simulation；k6 適合 JavaScript-style scripting、CLI workflow 與 Grafana 生態。

Gatling 和 JMeter 的主要差異是維護模式。Gatling 偏 code review、build pipeline 與 simulation abstraction；JMeter 偏 GUI、plugin 與跨角色測試資產。

Gatling 和 Locust 的主要差異是自訂語言。Locust 適合 Python 團隊與任意 Python client；Gatling 適合 JVM 團隊與 report / injection profile 的結構化壓測。

Gatling 和 Vegeta 的主要差異是 scenario 深度。Vegeta 適合快速 HTTP pressure test；Gatling 適合需要 session、feeder、assertion 與多 request group 的長期測試。

操作成本

Gatling 的主要成本是 JVM 團隊能力。非 JVM 團隊要承擔語言、build tool、dependency 與 simulation pattern 的學習成本；這個成本只有在 scenario 複雜度夠高時才划算。

測試資料成本來自 feeder 與 session。多步驟 flow 需要 account、cart、order、token、region 與 tenant 資料，資料過期或分布偏差會讓壓測結果失真。

Enterprise / distributed 成本要提前評估。單機 Gatling 適合中小型 baseline；跨 region、大型活動前驗證或長時間 soak test 需要 runner topology、結果集中與雲端成本治理。

Evidence Package

Gatling 結果應回寫到 evidence package。最小欄位包括 simulation version、injection profile、feeder source、target environment、assertion、response time distribution、error rate、throughput、target service saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓 simulation 可回放。Reviewer 要能從 report 回到 injection profile、scenario code、feeder 與目標環境，才有辦法判斷一次壓測是容量訊號還是測試設計偏差。

核心取捨表

選 Gatling 的核心訴求：JVM 團隊 + 複雜 scenario（session / feeder / 多 group）+ 高 RPS 單機效率 + HTML report 作為 release gate 證據。Java DSL 在 2024 後降低了 Scala 學習門檻、讓 Java/Kotlin 後端團隊不必再為了壓測導入 Scala。

進階主題

Gatling Enterprise（前 FrontLine）：商業版加 distributed injector cluster（跨 region / 跨 cloud 推大型負載）、live monitoring dashboard（real-time RPS / response time 趨勢、不用等 simulation 結束看 HTML）、long-term result storage（cross-run comparison、retention policy）、role-based access（QA / dev / SRE 不同權限）。對只跑單機 baseline 的團隊 OSS 已夠；要跑黑五 / 春晚級活動前壓測或多 region 同時施壓、需要 Enterprise 或自建 distributed topology。

Java DSL 取代 Scala 成主流（2022-2024）：Gatling 3.7（2022）正式釋出 Java DSL、3.9+ 文件 Java / Kotlin / Scala 三語並列、2024 後新教學多以 Java 為主。對 Java 後端團隊降低 onboarding 成本、但要注意 Gatling 2.x → 3.x 的 Scala syntax 不向後相容（scenario builder、http config、feed 用法都改寫）— 舊 simulation 升級時等於改寫一遍。

Distributed execution（OSS）：OSS 沒有內建 cluster orchestration、要靠 multiple injector + result aggregation：每台 injector 跑同一份 simulation（按 user count 切割）、結束後把 simulation.log 蒐集到一處用 gatling.sh 重跑 report stage。常見補位是用 Kubernetes Job + 共享 PVC、或直接走 Gatling Enterprise。

HTML report 與 release gate：simulation 跑完自動產 HTML report、含 response time percentile distribution（mean / p50 / p95 / p99 / max）、per-request-group breakdown、active users over time、error log。release gate 的標準做法是：CI job 跑 simulation → assertion gate fail 直接 break build → HTML report 存成 build artifact 供 reviewer 翻查、配合 Evidence Package 治理。

CI integration 模式：Jenkins / GitLab CI / GitHub Actions 都靠 mvn gatling:test / gradle gatlingRun / sbt gatling:test 入口、CI 設定 baseline simulation（每 PR 跑、catch regression）+ release simulation（release branch / nightly 跑、長時間 soak）。staging environment 跑壓測時要隔離噪音來源（其他 QA 流量 / cron job）、否則 RPS 數字會被污染。

排錯與失敗快速判讀

• Scala learning curve 拖累進度：團隊沒人會 Scala、被 implicit / case class / pattern match 卡住 — 改用 Java DSL（3.7+）或 Kotlin DSL、保留 Gatling 表達力但去除 Scala 學習成本
• Gatling 2.x → 3.x 升級 simulation 全紅：bootstrap import path / scenario builder API / feed 語法都變了 — 走 新專案直接 3.x、舊專案維持 2.x 雙軌、或安排專門 sprint 改寫、避免邊跑邊踩雷
• JVM heap OOM / GC pause 拖慢 RPS：高 RPS 下 default heap 不夠、Young Gen GC 頻繁 — 調 -Xmx4G -Xms4G、用 G1GC / ZGC、監控 injector 的 GC log 跟 CPU、不是只看 target service
• Injection profile 設計錯導致誤判 saturation：用 atOnceUsers(1000) 壓 closed model 但實際 traffic 是 open arrival、結果 knee point 找錯 — 看 production traffic shape、open model 用 constantUsersPerSec / rampUsersPerSec、closed model 才用 atOnceUsers
• Single injector node 撞 client-side bottleneck：injector CPU / network / file descriptor / source port 用滿、看起來 target saturate 其實是 injector saturate — 監控 injector resource、scale out 成 distributed 或走 Enterprise
• Feeder data 過期 / 分布偏差：用同一份 users.csv 反覆壓、cache hit rate 失真、production 看不到的 cache miss 路徑沒被測 — feeder 走 random / shuffle、定期 regenerate、覆蓋 long-tail key
• HTML report 看起來綠但 production 出事：assertion gate 只設 average response time、p99 / error rate 沒設、release 後尖峰時段才爆 — assertion 要明確設 p95 / p99 + error rate threshold、不只看 mean

案例回寫

Gatling 適合回寫多步驟與多負載模型案例。它可接 9.C28 FanDuel 雙峰 workload 的直播與投注雙模型、9.C16 SeatGeek waiting room 的 token / admission flow、9.C17 BookMyShow ticketing 的售票流程壓力、9.C4 DraftKings Aurora 金融帳本 的「比賽期讀爆量 + payout 時寫爆量」雙峰錯位，以及 9.C2 GR8 Tech 的「投注 / 結算 / 賠率更新」三類請求 group 的 injection profile。

這些案例的重點是 scenario 與 injection profile。Gatling 頁引用案例時，要把業務流程拆成 request group、session state、feeder、assertion 與 stop condition — 例如 DraftKings 雙峰錯位要寫成兩個 scenario 平行注入、各自有獨立 assertion budget。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.4 Saturation Discovery
• 平行：k6、JMeter、Locust
• 官方：Gatling documentation

壓測工具選型的核心不是「哪個工具最強」、是「哪個工具最貼合本團隊的 workload model 表達能力跟 CI 整合需求」。沒有絕對最好的工具、只有最匹配當前場景的工具。

跟 9.2 Workload Modeling 的關係：9.2 定義 workload 長什麼樣、9.3 找能複製這個樣子的工具。工具選對、壓測結果可信；工具選錯、壓測結果誤導。

本章不是工具教學、是 選型維度 + 主流工具的 適用情境。讀者讀完後能回答「我現在這個 workload 該用哪個工具」、而不是「哪個工具最快」。

六個選型維度

選工具時要按六個維度評估、不能只看「能不能跑 HTTP GET」。

腳本表達能力：能不能寫複雜 user journey（登入 → 瀏覽 → 加購物車 → 結帳）、不只是單一 HTTP request。複雜系統的壓測通常是 user journey 級別、單一 endpoint 壓測只能找絕對極限、找不到 cross-endpoint contention。

協議支援：HTTP / WebSocket / gRPC / TCP / 自家二進位協議。WebSocket 跟 gRPC 是現代後端常見、傳統工具（JMeter、wrk）可能要 plugin 補。

規模能力：單機可以發多少 RPS、能不能分散式擴容。本機 wrk 可發 10K-50K RPS；分散式 Locust 可發 1M+ RPS。決定因素：CPU 效率、async I/O 模型、是否單機 bound。

CI 整合：能不能在 PR 上跑 lightweight perf check、結果能不能機器可讀（JSON / Prometheus exposition）、能不能跟 baseline diff。沒有 CI 整合的工具只能做「事件型壓測」、無法做 continuous perf governance。

結果分析：原生 dashboard（k6 Cloud、Gatling Enterprise）/ Prometheus + Grafana 整合 / 純文字輸出。要看結果分發、團隊成員能不能輕鬆查詢歷史。

學習曲線：腳本語言（JavaScript / Scala / Python / Go）、團隊熟悉度。工具好但團隊不會用、會變成 1-2 個工程師的孤島技能、流失時整套廢掉。

主流開源工具對照

k6 是過去 5 年崛起的綜合首選。JavaScript 腳本（前端工程師也能寫）、原生 dashboard、Prometheus exposition、CI 友善。Grafana 收購後生態加速。缺點：複雜 stateful 場景（DB connection pool 共享）需要繞 workaround。

JMeter 是企業常見的 incumbent。協議支援廣（含 LDAP、JDBC、JMS）、有 GUI 編輯器。缺點：腳本是 XML、版本控制困難；GUI 主要用來生成腳本、實際跑壓測還是要 headless。已經在用的團隊建議繼續、新團隊不必特意選它。

Gatling 高 throughput 純 async、性能優秀、報表精美。缺點：Scala / Kotlin DSL 學習曲線陡、新版本（11+）改了 DSL 不向後相容。

Locust 是 Python 生態的選擇、特別適合複雜業務邏輯（用 Python 寫 user journey 自然）。分散式部署原生支援。缺點：Python 單線程 throughput 受限、要靠分散式擴容。

Vegeta 跟 wrk 是「quick check」工具、用於單一 endpoint 的極限測試。不適合複雜場景、適合 saturation discovery 第一輪「找這個服務的天花板」。

Production traffic replay 工具

當需要複製 真實 production traffic 的壓測場景時、需要另一類工具。

GoReplay 是最常用的開源 traffic replay 工具。在 production server 上 tcpdump-based 捕獲 HTTP traffic、可以 store 到 file 或 stream 到 staging 環境。優點：開源、無 vendor lock-in；缺點：HTTP only、加密流量要拿到 key 才能用。

Service mesh shadow（Istio / Linkerd mirror）：mesh 層 mirror traffic 到 staging service。優點：mesh 已部署的話 zero infra cost、加密 traffic 也能 mirror。缺點：需要 service mesh 已落地。

AWS VPC Traffic Mirroring：底層網路層 mirror、application 完全無感。優點：最低 invasion；缺點：AWS only、加密 traffic 要另外處理。

Diffy（Twitter / X 開源、已 deprecated 但概念仍有效）：dual-write 同時打到舊 / 新版本、比對結果。適合驗證「新版本是否邏輯正確」、不是純壓測。

對應案例：Tixcraft 10K t2.micro 壓測 — 用分散式 EC2 跑 synthetic load 模擬 100K 同時搶票；SeatGeek Virtual Waiting Room — token 配發邏輯通常用 dual-write 驗證新舊版本一致。

雲端 managed 壓測服務

當不想養 load test infrastructure、想 ad-hoc 跑大規模壓測時、用 managed service。

AWS Distributed Load Testing：CloudFormation 起 Fargate cluster 跑 JMeter 或 Taurus、報表寫到 S3。優點：一鍵部署、Fargate 計費；缺點：JMeter-based、不是現代 k6 風格。

Grafana k6 Cloud：託管 k6、跨地理 distributed 壓測（從多個 region 同時發流量）。優點：地理分散原生、跟 Grafana 整合無縫；缺點：vendor cost。

Azure Load Testing：Azure 原生、整合 Application Insights。優點：Azure 用戶無縫；缺點：相對較新、生態還在補。

GCP 沒有 first-party managed load testing：要靠 Marketplace 方案或自管 Locust on GKE。

工具選型決策樹

落地時的快速決策：

• 想快速驗證單一 API 極限 → wrk / Vegeta
• 想寫複雜 user journey + CI 整合 + JavaScript 團隊 → k6（新項目首選）
• 企業已有 JMeter 流程、不想換 → JMeter（接受 XML / GUI 複雜度）
• 大規模分散式 + Python 生態 → Locust
• 報表給管理層看、Scala 團隊 → Gatling
• 想複製真實 production traffic → GoReplay 或 service mesh shadow
• 想 ad-hoc 雲端大規模壓測 → 對應雲商的 managed load test

常見反模式

• 只測單一 API、不測 user journey：找不到 cross-endpoint contention、找不到 session state 累積
• 壓測機跟被測機在同一網段：網路延遲被低估、p99 比 production 樂觀
• 壓測時 throttle 自己的工具：結果不是被測系統的極限、是工具自己的極限
• 結果報表只看平均：tail latency 看不到、p99 退化被掩蓋
• 壓測環境跟 production hardware 不一致：CPU 型號、network、disk IOPS 差很大、結果不可外推
• 沒驗證 model：跑了壓測但沒對比 production metrics、不知道 model 是否貼近 reality

案例對照

下一步路由

• 上游：9.2 Workload Modeling
• 下游：9.4 Saturation Discovery（用工具找 knee）
• 下游：9.9 Improvement Loop（CI 整合）
• 跨模組：06.1 CI Pipeline（壓測在 CI 的位置）

既建知識卡片

• Load Test
• Workload Model
• Shadow Traffic
• Saturation Point

觀察

Coinbase 在 2023-05 推出國際交易所、上線後關鍵數字（引自 Coinbase Case Study）：

服務組合：

• Amazon EC2 z1d 實例：高頻 CPU + NVMe 本地儲存、針對單執行緒效能最佳化
• EC2 Cluster Placement Groups：強制把節點集中到單一機架附近、最小化 node-to-node 網路延遲
• Amazon Aurora：高速 transaction lookup 的關聯式資料庫
• 「Built from the ground up, using Cloud Native principles」（沒有複用既有交易所程式碼）
• 內部使用 RAFT consensus 維持交易順序

判讀

這個案例最值得讀的地方、是它「沒有做」的事比「做了」的事更有教學價值。

1. 沒有用 Auto Scaling：交易撮合引擎用 RAFT consensus 維持嚴格順序、節點數量是 consensus 一部分、不能臨時增加。容量規劃完全是 pre-provision、不是 reactive。對應 9.6 容量規劃模型 必須區分「可水平擴容服務」跟「不可水平擴容服務」、後者的容量公式只有 headroom × peak、沒有 elastic 補救。
2. 沒有用通用 EC2 實例：z1d 是 AWS 針對「高頻 CPU + NVMe」設計的特化實例、犧牲了通用性換取單核效能。這層選擇隱含一個容量規劃決策：單機效能上限 直接決定 系統理論吞吐上限、橫向擴容不能超過 RAFT 節點數限制、那麼縱向就必須榨乾。對應 9.5 瓶頸定位流程 必須先判斷瓶頸屬「可分散」還是「不可分散」。
3. 沒有用多區域分散：Cluster Placement Group 把節點壓到同一可用區內、犧牲了 region failover 速度、換取 node-to-node 網路延遲。這跟「高可用性」的常見直覺相反、是「延遲敏感型負載的容量設計優先於可靠性設計」的一個範例。
4. 延遲是設計輸入、不是設計結果：sub-millisecond 是先訂目標、再反推所有架構選擇的結果、壓測只是驗證手段。對應 9.1 壓測理論與系統行為 中 Little’s Law 的反向應用 — 給定延遲目標 + 吞吐目標、反推 concurrency 上限 + 每個 stage 的 latency budget。

需要警惕的判讀盲點：「sub-millisecond latency 達成」這類陳述通常指 p50 或 p90、不一定是 p99 或 p999。長尾延遲在 RAFT 系統下可能比平均高一個數量級（leader election、replication lag）。讀案例時要注意延遲分布 vs 平均值的差別。

策略

可重用的工程做法：

1. 延遲敏感型服務先做 latency budget 反推：給每個 stage（網路、CPU、磁碟、序列化、共識）一個 latency 配額、總和等於 SLO 上限。對應 9.12 SLO 與 Performance Budget。
2. 單機效能榨乾優先於橫向擴容：當 consensus / ordered processing 限制了水平擴容時、單機選型（CPU 頻率、NUMA locality、NVMe）變成主要槓桿。對應 9.4 Saturation Discovery 把 saturation 點推得越遠。
3. 拓樸感知的部署策略：Cluster Placement Group 是 AWS 名稱、概念是「網路拓樸感知的工作負載放置」。GCP 有 Compact Placement Policy、Azure 有 Proximity Placement Groups、自建 Kubernetes 有 Pod Topology Spread Constraints + Node Affinity。
4. 接受「不可彈性」是有意識決策、不是失敗：很多服務不該全部都自動擴容。設計時要區分「需要 elastic 的 stateless 邊緣」跟「必須 pre-provision 的有狀態核心」、容量規劃也要兩條腿。

跨平台等效：所有主流雲端都有對應的高頻 CPU 實例（GCP C2 / Azure HBv 系列）、placement policy 與本地 NVMe 儲存。自建環境可以用 SR-IOV + RDMA + NUMA pinning 達成更極致的版本。

下一步路由

• 想設計延遲敏感型服務的容量地圖 → 9.1 壓測理論與系統行為 + 9.6 容量規劃模型
• 想搞清楚哪些服務該水平擴容、哪些不該 → 9.5 瓶頸定位流程 + 9.4 Saturation Discovery
• 想做 latency budget 反推 → 9.12 SLO 與 Performance Budget + 04.16 SLI / SLO 訊號
• 對照不同形狀的負載 → 9.C1 AWS Prime Day（可預期極端峰值）/ 9.C2 GR8 Tech（事件型不可預期峰值）

引用源

• Coinbase Launches an Ultra-Low-Latency Cryptocurrency Exchange on AWS
• Coinbase Scales 50% Faster, Cuts Costs 62% with AWS
• Ultra-Low-Latency Crypto Exchange on AWS（video）

服務定位

Locust 適合把壓測寫成一般 Python 程式。當 workload model 需要呼叫 internal SDK、特殊 protocol、複雜資料準備、狀態機、隨機行為或自訂 client、Locust 可以直接使用 Python 生態來表達。底層架構是 master + worker 分散式 swarm、worker 之間用 Gevent green-thread（非 OS thread）模擬大量並發 user、master 負責 spawn rate、aggregation 跟 Web UI。

這個定位讓 Locust 接到 9.2 Workload Modeling 與 9.5 瓶頸定位流程。它能把特殊 client 與下游 dependency 放進同一個 user behavior、但也要求團隊處理 runner、資料與可重現性。

跟 k6（JS / Go runtime）比、Locust 用 Python 換到 自訂能力與生態相容、但代價是單 worker capacity 低、CPU bound 容易先打到自己。跟 JMeter（GUI / XML）比、Locust 偏 code-first 工程團隊、scenario 直接走 Git review、不靠 GUI plugin 拼裝。跟 Gatling（Scala DSL）比、Locust 換到 Python team 友善 + 既有 domain library 重用、但失去 JVM injection profile 的精細度與報表內建。

關鍵張力：Python 表達力 ↔ runner 效能上限。Python team 想 reuse domain library、staging fixture、API client 寫壓測腳本時 Locust 是首選；但要心裡有數 單 worker RPS 上限不高、超過幾千 RPS 就要靠 worker scale-out、不是調 Locust 本身。

適用場景

Python 團隊適合用 Locust 長期維護壓測。既有 domain library、API client、fixture、資料產生器與驗證 helper 都可以被壓測腳本重用。

自訂 protocol 適合用 Locust。HTTP 之外、如果服務需要 gRPC、WebSocket、binary protocol、message broker client 或自家 SDK、Locust 可以直接接 Python library。

Distributed load 適合用 Locust worker 擴展。當單機 Python runner 遇到 CPU 或 connection bottleneck、可以用 master / worker 拆開負載產生能力。

本章目標

讀完本頁、讀者能判斷：

1. Locust 在壓測 stack 中承擔哪一段（user behavior modeling / load generation / distributed swarm）、哪些要外接（Prometheus / Grafana 觀測 worker 自身、APM 看目標 saturation）
2. User class / task weight / on_start lifecycle 的 ownership 設計（誰寫 locustfile、誰 review、誰調 spawn rate）
3. Distributed master-worker 部署的容量規劃（單 worker user 上限、worker 數量計算、target RPS 對應 worker count）
4. 何時用 Locust、何時走 k6 / JMeter / Gatling 的取捨

最短判讀路徑

判斷 Locust 壓測是否健康、最少看四件事：

• User class 設計：每個 HttpUser / User subclass 是不是一個明確的 persona（mobile user / API client / admin user）、wait_time 是否反映真實使用者間隔（不是 0 拼最大 RPS、是 between(1, 5) 模擬 think time）、user state 是否在 instance 內封閉
• Task 比例：@task(weight) 數字是否對應 production traffic mix（80% read / 15% write / 5% admin、不是每個 endpoint 等比例）、weight 是否走版控 review
• on_start lifecycle：login / token fetch / session bootstrap 是否寫在 on_start（每個 user 一次）、不是寫在 @task 裡（每個 request 都重做）— 寫錯位置會讓 auth endpoint 變成主要 traffic
• Distributed master-worker：worker 數量是否夠（單 worker 跑幾千 user 後 CPU 會先打死、不是目標服務先死）、master 是否獨立機器（master 也跑 user 時 aggregation 跟 Web UI 會卡）、--expect-workers 是否設、worker sync drift 是否觀察

四件事任一缺失、就是壓測證據可信度的待補項目。

日常操作與決策形狀

locustfile 結構：locustfile.py 是 Python module、定義 User / HttpUser subclass、每個 user 有 wait_time、若干 @task(weight) method、on_start / on_stop lifecycle hook。執行用 locust -f locustfile.py --host=https://target 起 Web UI、或 locust --headless -u 1000 -r 100 -t 10m 在 CI 跑無 UI 模式。locustfile 應該走 Git review、不是 GUI 改完就跑。

Task weight / wait_time 設計：weight 是 相對權重、不是百分比 —@task(8) + @task(2) 等於 80% / 20%。wait_time = between(1, 5) 在每個 task 之間等 1-5 秒、模擬 think time；若要拚最大 RPS 用 constant(0)、但同時要意識到這就不是 user behavior 模型、是 throughput probe。

on_start vs @task 的邊界：on_start(self) 每個 user instance 啟動時跑一次、適合做 login、token fetch、cache warm、fixture lookup；@task 是 user 行為主迴圈、每次選一個 task 跑。把 login 寫在 @task 是常見錯誤、會讓 IdP 變成主壓力來源、不是目標 API。

Gevent-based concurrency：Locust 用 gevent 的 green-thread 模擬大量 concurrent user、不是 OS thread。意義是單 worker 可以跑幾千個 user、但 CPU bound 工作（JSON serialization、加密、本地計算）會 blocking 整個 worker 的 event loop。gevent.monkey.patch_all() 要在 import 第一行、否則 socket / time / ssl 不會被 patch、blocking call 會卡死 swarm。

Distributed master-worker：單機到極限時開 distributed — locust --master 起 master、locust --worker --master-host=master.example.com 起 worker。Master 負責 Web UI、spawn rate 控制、result aggregation、stat 收集；worker 負責跑 user。Master 不該跑 user（會跟 aggregation 搶 CPU、stat 失真）。worker 數量計算：先單 worker 拉到 CPU 80% 看能撐多少 user、目標 user 數除這個值 + 20% buffer。

Custom load shape：除了固定 -u 1000、Locust 支援 LoadTestShape subclass 寫 時間軸負載曲線 — spike test（瞬間 0 → 5000 user）、ramp test（線性爬升）、wave test（週期性高低交替）、step test（階梯式增加）。tick() method 每秒回傳 (user_count, spawn_rate)。用 custom shape 才能模擬 9.C16 SeatGeek waiting room 那種 ticket drop 瞬間衝擊。

Prometheus exporter / 觀測：Locust 內建 stat 只是 in-memory 的 p50 / p95 / p99 / RPS、結束就消失。長期觀測接 locust-prometheus-exporter（或 --csv result.csv 自己抓）、把 metric 推到 Prometheus + Grafana。worker 自身的 CPU / memory / network 一定要同時觀測、不然分不出是目標 saturation 還是 worker 已死。

Locust Cloud（managed SaaS）：2024 後 Locust 推官方 Locust Cloud、託管 master + worker + result storage、付費換 ops 成本。自管 master-worker 對 CI / staging 是合理的；production 等級的 scale test（10k+ concurrent user）跑一次要拉幾十台 worker、用 Cloud 省 infra ops 是合理 trade-off。

核心取捨表

選 Locust 的核心訴求：Python team + custom user behavior + 既有 domain library 重用、且能投入 worker scale-out 預算（單 worker capacity 低、要靠分散式補）+ scenario 走 Git review 不靠 GUI。標準 HTTP 高 RPS 單機壓測直接走 k6 更快、非工程角色協作壓測走 JMeter、JVM team 精細模擬走 Gatling。

進階主題

Distributed Locust 的 master-worker swarm：production scale test 通常需要 10-100 個 worker。實作要點：worker 之間 不要 共享 state、shared resource 由 master 統一發（用 zeromq message bus）；worker 加入 / 離開時 user 會 redistribute、避免 user index 當 unique key；worker 跨 region 跑時 latency 來自 worker → target 不只是 target 內部、要在 worker 本身的 region 對齊。

Custom load shape（spike / wave / step）：LoadTestShape.tick(self) return (user_count, spawn_rate) tuple 每秒被叫一次。Spike test：前 60 秒 0 user、第 61 秒瞬間衝 5000、模擬 9.C16 SeatGeek waiting room 的 admission storm。Wave test：sine wave 在 1000-3000 user 之間振盪、測 autoscaling 反應速度。Step test：每 5 分鐘加 1000 user、觀察哪一階開始降級。custom shape 是 Locust 比 k6 強的點之一。

跟 Prometheus exporter 整合：locust-prometheus-exporter 把 Locust stat 推到 Prometheus / Grafana、做長期 baseline、跨 test 比較、p99 退化偵測。實務上要在 dashboard 同時放 Locust 內部 stat + worker host metric + 目標服務 APM、三層 stack 起來才能判讀是 runner 還是目標 saturation。

Locust Cloud（managed SaaS）：2024+ 官方 SaaS、託管 master + worker + result + dashboard。trade-off：自管適合 CI / staging / 內網壓測（target 跑在內網時 Cloud 連不到）；Cloud 適合大規模一次性 scale test（拉 50 worker 跑 2 小時、跑完即停、不想自己 infra ops）。

操作成本

Locust 的主要成本是 runner overhead 與分散式治理。Python runner 的效能上限要用 worker scale-out 解決；壓測結論要同時檢查目標服務 saturation 與 worker 本身 CPU、connection、network 是否已成瓶頸。

腳本工程成本來自自由度。Python 可以很快寫出複雜行為、也容易把測試資料、randomness、side effect、sleep 與 exception handling 寫散；團隊要維持 scenario structure、fixture、logging 與 artifact 標準。

自訂 client 成本來自校正。使用 SDK 或 custom protocol client 時、要確認 client retry、timeout、connection pool 與 serialization 行為是否接近 production、避免 runner 模擬出不存在的壓力形狀。

排錯與失敗快速判讀

• Worker CPU 100% 但目標服務閒：Python runner 先死、不是 target saturation — 加 worker 數量、或檢查 task 裡有沒有 CPU bound 的本地計算（大 JSON parse、加密、本地 fixture 生成）擠掉 event loop
• Gevent monkey-patch gotcha：requests / psycopg2 / 自家 SDK 在第三方 library 內部 blocking call、整個 worker 卡住 — gevent.monkey.patch_all() 一定要寫在 import 第一行；無法 patch 的 C extension（如 native MySQL driver）改用 gevent-friendly client
• RPS 達不到目標 / 看起來像 target 慢：實際是 worker connection pool 耗盡、或 worker 本身網卡飽和 — 觀測 worker 本身的 TCP socket 數、netstat ESTABLISHED、network throughput；不要直接 blame target
• Distributed sync drift：worker 之間 user count 不平均、aggregation 顯示 RPS 抖動 — --expect-workers=N 確認 master 等所有 worker join 才開測；worker 跨 region 時 message bus latency 也會影響 sync
• on_start 在 @task 裡跑：壓測啟動瞬間打爆 auth endpoint、看到 IdP latency 飆高以為是 target — 把 login / token fetch 移到 on_start、每個 user 只做一次
• wait_time = 0 拼最大 RPS 結果結論奇怪：這已經不是 user behavior 是 throughput probe、p99 跟 production 對不上 — 改成 between(1, 5) 模擬 think time 或寫 custom shape
• Web UI 卡 / master CPU 100%：master 同時在跑 user + aggregation — locust --master 跟 worker 拆機器、master 不跑 user

何時改走其他服務

不在本頁內的主題

• locustfile 完整語法 reference、User 跟 HttpUser 的 attribute 細節
• Locust Cloud 計費跟 quota 細節（看官方 docs）
• gevent 跟 asyncio 的取捨（Locust 選了 gevent、不在本頁討論替代）
• 壓測證據怎麼歸檔（看 9.7 evidence package 通則）

Evidence Package

Locust 結果應回寫到 evidence package。最小欄位包括 locustfile version、user class、task weight、spawn rate、worker count、client library version、target environment、p95 / p99、error rate、throughput、target saturation metric、known gap 與 owner。

Evidence package 的核心用途是區分目標瓶頸與 runner 瓶頸。Locust 分散式測試要同時保存 worker 數量、worker 資源、spawn rate 與 client behavior、讓 reviewer 知道壓力是否真的打到目標服務。

案例回寫

Locust 適合回寫需要高度自訂 user behavior 的案例。它可接 9.C28 FanDuel 雙峰 workload 的投注行為模型、9.C16 SeatGeek waiting room 的 admission / token flow、9.C26 PayPay mobile payment messaging 的外部推送與下游 quota 模擬、9.C8 Niantic Pokémon GO 50x surge 的玩家移動 + 互動混合行為、以及 9.C18 Zoom COVID 30x surge 的會議建立 / 加入 / 離開行為混合。

這些案例的重點是 domain behavior。Locust 頁引用案例時、要把 case 轉成 user class、task weight、custom client、downstream mock 與 worker capacity、再把總 RPS 放回這些行為條件下判讀 — 例如 Pokémon GO 玩家行為跟一般 web user 完全不同（持續 GPS 上報 + 偶發互動）、不能直接用 HTTP RPS 衡量；SeatGeek waiting room 要寫 LoadTestShape 模擬 ticket drop 瞬間衝擊、不是穩態 RPS。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.3 壓測工具選型
• 上游：9.5 瓶頸定位流程
• 平行：k6、JMeter、Gatling、Vegeta
• 跨類：GoReplay（production traffic replay 替代 synthetic load）
• 跨模組：4 Observability（worker 自身 + 目標 APM 雙觀測）
• 官方：Locust documentation

Saturation discovery 的責任是把「系統能撐多少」這個問題變成可量化答案。沒有 saturation 量測時、容量規劃只能猜；有 saturation 量測之後、能說「在當前配置下、p99 < 100ms 的條件下、能撐 X RPS、headroom Y%」。

跟 9.1 壓測理論 的關係：9.1 預測 saturation curve 的形狀（linear → knee → cliff）、9.4 用實測找出 本服務 的曲線具體位置。理論告訴我們 knee 存在、實測告訴我們它在哪裡。

本章不深入工具操作（9.3 處理工具）、聚焦在 方法論 — 怎麼設計 ramp-up、怎麼判斷 knee、怎麼把結果文件化讓後續決策可用。

Saturation 的精確定義

容量規劃裡 saturation 不是「系統當機」、是「系統 進入 latency 指數成長區」。這個區分很重要 — 系統 看起來 還在跑、其實已經不可預測。

技術上 saturation 對應 queueing theory 的 knee point：utilization 超過某個臨界（M/M/c 通常 70-80%）、平均 queue length 從線性轉成指數成長。latency 是 queue length 的線性函數、所以也跟著指數成長。

實務上把 saturation 分三段：

• linear region（utilization < 50%）：latency 平穩、加流量幾乎不影響
• knee region（utilization 50-80%）：latency 開始上升、但還可接受
• cliff region（utilization > 80%）：latency 不可預測、可能 timeout / cascade failure

健康系統運轉在 linear 後半段或 knee 前段（utilization 50-70%）、留出 headroom 應付 burst。autoscaler 的 target metric 通常訂在 60-70%、是這條曲線推導出的安全位置。

Ramp-up 測試方法

要找出 saturation 點、必須跑 ramp-up 測試 — 不能固定一個壓力值。

單點壓測的問題：跑「2000 RPS 連續 10 分鐘」、看 latency 100ms、結論「能撐 2000 RPS」 — 但不知道 1500 跟 2500 RPS 是什麼樣。可能 1500 也是 100ms（離 knee 還很遠）、可能 2500 直接崩（已經在 cliff）。

Ramp-up 流程：從基線開始、按倍數加壓（1x / 2x / 4x / 8x …）。每個壓力 level 維持 5-10 分鐘、觀察 latency / throughput / resource utilization 的穩態（不是 transient）。紀錄每個 level 的 percentile 分布。

Knee 出現的訊號：

• throughput 從線性成長轉成 sub-linear（加壓但 throughput 不再等比成長）
• latency p50 還算穩、但 p99 / p999 開始飆
• resource saturation queue 開始堆積（不只 utilization 上升）
• error rate 仍接近 0（cliff 才會 error 飆）

Cliff 出現的訊號：throughput 開始下降（加壓反而越來越慢）、latency p99 變成 timeout、error rate 飆升、retry storm 出現。

對應案例：Tixcraft 用 10K t2.micro 壓測 找 DynamoDB 從 20 IOPS 到 135K 的擴展曲線、知道 knee 在哪。

Resource saturation 的六個維度

每次 ramp-up 都要同時觀察六個維度的 resource saturation、找出哪個 先 saturate。

CPU：utilization 100% 不一定 等於 saturation。要看 load average 跟 run queue。utilization 80% 但 run queue 不斷增長 → 已 saturate；utilization 100% 但 run queue 空 → 還能撐（單純 CPU bound）。

Memory：not OOM 即可？不夠。GC pause（Java、Go）、swap（Linux）、cache eviction 都是隱性 saturation。記憶體不直接 OOM 但 GC 飆 → 已影響 tail latency。

Disk I/O：要看三個維度：throughput（MB/s）、IOPS（operations/sec）、queue depth。雲端 SSD 通常先 IOPS bound、不是 throughput；本機 NVMe 可能先 throughput bound。

Network：bandwidth（Gbps）、packets per second、connection count。雲端 instance 通常有 PPS limit、超過會 silent drop、不是顯式錯誤。

Connection pool：DB / cache / external API 的連線數。這是 最常見的隱性 bottleneck。pool size 訂 100、實際在用 95 → utilization 看似還好、其實已經 saturate（剩下的 request 在等 connection）。

External API quota：第三方 rate limit（Stripe、Twilio、Slack API）。這個維度的 saturation 看不到 本系統 的訊號、要看 對方 API 的 429 error rate。

對應案例：Lemino RDB connection limit — connection 是 RDB 的 saturation 點、CPU 跟 RAM 都還沒到。

詳見 USE Method 卡片。

Hot partition 的隱性 saturation

對分散式 KV / OLTP（DynamoDB、Cosmos DB、Bigtable、Cassandra）、saturation 還有另一個維度：hot partition。

名義容量 = 每 partition 上限 × partition 數量。partition key 分布不均 → 名義容量達不到。整體 utilization 看起來 20% → 系統還能撐？不一定。最熱 partition 已經 100%、其他 partition 0%、整體平均才 20%、但加流量會打在最熱 partition、立即 throttle。

識別 hot partition 的訊號：

• throughput 上不去、但 average resource utilization 低
• 某些 key 的 request latency 飆、其他 key 正常
• DynamoDB throttling event 出現（即使 capacity 還沒滿）

處理方法：

• composite key（event_id + user_id_hash）
• write sharding（event_id + random_suffix）
• time-bucket（event_id + minute）
• 用 cache 吸收 hot key（DAX、ElastiCache）

對應案例：Amazon Ads 9000 萬 RPS — partition 設計均勻時可以撐 sustained 高吞吐；Tixcraft 售票 — 同一場演唱會（event_id）天然容易 hot、必須用 composite key 分散。

Long-tail latency 的 saturation

p50 / p95 / p99 / p999 在 saturate 時表現可能完全不同。

p50（中位數）對 GC pause、retry storm、tail latency 不敏感 — 大部分 request 沒事、p50 看不到。 p99（百分之 1）對 connection contention 開始敏感、能早期看到 saturation。 p999（千分之 1）對 GC stop-the-world、leader election、retry storm 敏感、是長尾的最強訊號。

純看 average / p50 會誤判 saturation 還沒到。SLO 通常訂 p99（讓 99% 用戶體驗良好）、internal critical 系統可訂 p99.9（5 個 9 的可用性對應 5 個 9 的 latency 期待）。

對應案例：Tubi p99 < 10ms — ML 系統的 user-perceived latency 是 最後完成的 inference、p50 快沒用；Coinbase sub-ms — RAFT 系統的 p999 通常比 p99 高一個量級。

詳見 Tail Latency 卡片。

Saturation 文件化：容量地圖

Saturation discovery 跑完之後、產出 容量地圖 — 不是一個數字、是一張表。

容量地圖至少要回答：

• 在 X 配置下（instance count、type、network）
• SLO 條件 Y 下（p99 < N ms、error rate < M%）
• 能撐 Z RPS（含分解到不同 endpoint）
• knee 在哪（什麼條件下進入 cliff）
• 第一個 saturate 的 resource 是什麼

紀錄 測試時間 跟 軟硬體版本：硬體 / 軟體版本變動後、saturation 點可能位移、舊地圖不能套用。

加入 release gate：每次重大改動後 re-test、確認 knee 沒往不好的方向移。這層自動化跟 9.9 Improvement Loop 對接。

案例對照

下一步路由

• 上游：9.1 壓測理論 / 9.3 壓測工具選型
• 下游：9.5 瓶頸定位流程（找到 knee 之後、定位是哪個 resource）
• 下游：9.6 容量規劃模型（用 knee 算 headroom）
• 跨模組：04 可觀測性模組（量測訊號）

既建知識卡片

• Saturation Point
• USE Method
• Tail Latency
• Hot Partition

觀察

DraftKings 帳本系統的關鍵數字（引自 DraftKings case study）：

服務組合：Amazon Aurora MySQL-Compatible、Aurora Replicas（讀寫分流）、Aurora I/O-Optimized（2023-05 推出）、Aurora Database Cloning（測試環境）、跨三個 AZ 儲存複製。

關鍵負載形狀：「write workloads spike up significantly around payout events, but opening the app during the game also activates a lot of balance queries」— 比賽進行時是讀爆量、payout event 時是寫爆量、雙峰錯位。

判讀

DraftKings 的工程選擇揭露三個 OLTP 容量設計重點。

1. 200 個獨立資料庫 = sharding 預先做好：按業務切 200 個 cluster、用巨型 cluster 撐全部在這個規模行不通。對應 9.5 瓶頸定位流程 把「單機極限」改成「shard 極限」、每個 shard 的容量規劃變成獨立問題。
2. Replication lag 30 秒 → 10-30 ms：這個改善不只是「快」、而是讓 read-after-write 變得可預測。Aurora 的 storage layer 多 AZ 複製是這個 lag 改善的主因。對應 01 資料庫模組 的 replication lag 影響 transaction boundary 設計。
3. Super Bowl +50% 「no sweat」：這句話的工程意義是 提前做好容量規劃、不是「Aurora 神奇」。寫 workload 預期可能 + 50%、整個 system headroom 預留至少 50%、加上 read replica 動態加減、才能讓 50% 增幅變成「不流汗」。對應 9.6 容量規劃模型 的 headroom budget 與 event-driven scheduled scaling。

需要警惕：100 萬 ops / 分鐘 = ~17K ops / 秒、跨 200 個 databases 平均下來每個 DB 約 80 ops / 秒。這不是「單一 DB 撐 100 萬 ops」、而是「200 shard 加總 100 萬」。讀案例時要看「峰值是分散到多少 shard」、不只看總數。

策略

可重用的工程做法：

1. 按業務切 OLTP cluster、不要一個 DB 撐全部：DraftKings 200 個 databases 顯示「業務切片」是 OLTP 擴容的前置。對應 01 資料庫模組 的 schema design 與 partition 決策。
2. 讀寫分流是 OLTP 容量規劃的基線：6ms 寫 vs <1ms 讀的差距、加上 read replica、是 OLTP 擴容最基本的兩個槓桿。
3. 事件型峰值預測寫進 baseline：Super Bowl 是已知事件、+50% 是歷史經驗、所以可以提前 pre-scale。事件未知（突發新聞、KOL 推廣）的情況才需要 AI 預測（對照 9.C2 GR8 Tech）。

跨平台等效：GCP Cloud SQL + read replica / Spanner、Azure Database for PostgreSQL + read replica、自建 PostgreSQL + Patroni + pgbouncer 都可以實作對等架構。Aurora 的差異是 storage layer 對 replica 的 lag 改善。

下一步路由

• 想規劃 OLTP 高峰容量 → 9.6 容量規劃模型 + 9.11 高峰事件準備 + 01 資料庫模組
• 想搞清楚事件型 vs 突發型峰值 → 9.C2 GR8 Tech 對照
• 想做 read replica 容量設計 → 01.6 高併發資料存取 + 9.5 瓶頸定位流程
• 想理解 replication lag 對 transaction boundary 的影響 → 01.5 transaction boundary
• 想理解 6 寫 / 4 讀 quorum 跟 200 cluster fleet 治理 → Aurora 儲存層架構
• 想規劃 read replica scaling 與 reader endpoint 路由 → Aurora read replica scaling

引用源

• DraftKings Scales Its Financial Ledger with Amazon Aurora
• Aurora I/O-Optimized announcement

服務定位

Vegeta 是 Go 寫的 HTTP load testing CLI，核心模型是 constant rate attack：指定「每秒 N 個 request」就持續打 N rps、不會因 server 變慢就降速，跟「fire-and-wait」型工具（hey / wrk 預設 closed-loop）行為差異很大。constant rate 是 open-loop 模型 — 模擬真實流量「不會因服務慢而減少」的行為、所以 saturation 點才會明確浮現。

Vegeta 是 Unix philosophy CLI：targets 從 stdin 讀（可以 pipe 進複雜 generator）、binary report 從 stdout 出（可以 pipe 進 vegeta report / vegeta plot / vegeta encode）。這個設計讓 Vegeta 容易跟 shell pipeline / CI script 接合、但同時也決定它不適合表達多步驟 session。

跟 k6 比、Vegeta 走 CLI-first + open-loop constant rate、k6 走 JS scenario + threshold + CI artifact。Vegeta 適合「我要對這個 URL 打 200 rps 60 秒」的一次性壓測、k6 適合「我有 3 種 user journey、各占 40/30/30%、跑 ramp-up profile」的可維護 scenario。跟 hey 比、Vegeta 的 constant rate 是真的 open-loop、hey 的 -q 是 per-worker rate（worker 變慢整體就降速）— 探測 saturation 時 Vegeta 比較誠實。跟 wrk / wrk2 比、Vegeta 沒有 LuaJIT 那麼極致的單機壓測效能、但 binary report + vegeta plot + targets pipe 對日常工程師工作流更友善。

本章目標

讀完本頁、讀者能判斷：

1. 何時用 Vegeta、何時走 k6 / hey / wrk / Gatling / Locust 的取捨
2. constant rate attack 的設計意涵（open-loop vs closed-loop、為什麼這對 saturation discovery 重要）
3. target file / rate / duration / report 四件套的 baseline workflow 跟 evidence package 對應
4. 排錯時的常見陷阱：runner 端 TCP socket exhaust、open file limit、constant rate 跟 target server 限速 disconnect

定位

Vegeta 適合快速回答「這個 endpoint 在某個 rate 下表現如何」。當團隊需要先找出大概 knee point、驗證一個修補是否降低 latency、或在 CI 裡跑小型 performance smoke test，Vegeta 的 CLI workflow 很直接。

這個定位讓 Vegeta 接到 9.4 Saturation Discovery 與 9.5 瓶頸定位流程。它提供的是快速壓力探針，後續若要表達複雜 workload model，通常要轉向 k6、Gatling、Locust 或 JMeter。

最短判讀路徑

判斷一次 Vegeta 壓測是否有效、最少看四件事：

• Target 描述完整性：targets file 是否包含 method / URL / headers / body、是否反映真實 request shape（含 auth header、content-type、representative payload size），缺一就會讓壓測結果偏離正式環境
• Rate model 設計：選的是 constant rate（-rate=200/s）還是 ramp（用多段 attack pipe），constant rate 適合 saturation probe、ramp-up 要 wrap script 自己 stage、Vegeta 沒有原生 ramp profile
• Report 解讀：vegeta report 給 mean / p50 / p95 / p99 / max latency + success rate + throughput，重點看 p99 跟 max 的距離 與 requested rate vs actual throughput 是否 disconnect — disconnect 表示 server / runner 端有人在限速
• Duration vs warm-up：短 duration（< 30s）容易吃到 JIT / cache / connection pool warm-up 噪音，baseline 壓測 duration 至少 60s、且第一段 result 要 discard，否則 p99 會被前 5s 拉高

適用場景

單 endpoint saturation probe 是 Vegeta 的主要入口。工程師可以對 login、search、read API、feature flag endpoint 或 internal health-like endpoint 施加固定 rate，觀察 p95 / p99 與 error rate 何時開始上升。

Regression smoke test 適合用 Vegeta。CI 或 pre-release 可以用短時間固定 rate 測試，確認 hot path 沒有明顯退化，再把更完整的 scenario 交給 k6、Gatling 或 Locust。

Incident 後修補驗證適合用 Vegeta。當事故根因是某個 endpoint 的 query、cache miss、lock contention 或 timeout，修補後可以用相同 request set 重跑，快速比較 latency distribution。

選型判準

CLI 簡潔價值來自低摩擦。當問題還在定位階段，工程師可以很快產生可重跑 command 與 target file，先取得 baseline，再決定是否需要完整壓測平台。

固定 rate 價值來自可比較。用相同 request set、rate、duration 與 target environment 重跑，可以讓修補前後的 latency distribution 有清楚對照。

跟其他工具的取捨

Vegeta 和 k6 的主要差異是 scenario 深度。Vegeta 適合固定 rate HTTP probe；k6 適合多步驟 scenario、threshold、CI artifact 與 browser-style flow。

Vegeta 和 JMeter 的主要差異是工具重量。Vegeta 適合快速 CLI；JMeter 適合 GUI、多 protocol、plugin 與企業測試資產。

Vegeta 和 Gatling 的主要差異是長期維護模式。Vegeta 用 command / target file 保持簡單；Gatling 用 simulation 維護複雜 flow 與 injection profile。

Vegeta 和 Locust 的主要差異是自訂能力。Locust 適合 Python user behavior 與 custom client；Vegeta 適合 HTTP endpoint 的直接壓力測量。

操作成本

Vegeta 的主要成本是 workload coverage 有限。它能快速測 endpoint，但多步驟 session、資料依賴、payment mock、queue side effect 與 realistic user journey 需要額外工具或腳本補上。

Artifact 成本來自命令可追溯性。每次測試要保存 rate、duration、targets、headers、body、環境、版本與結果檔；否則快速 probe 很容易變成不可比較的一次性觀察。

Runner 成本通常較低，但仍要檢查本機瓶頸。高 rate 測試時，產生負載的機器也可能先被 CPU、network、file descriptor 或 connection limit 卡住。

Evidence Package

Vegeta 結果應回寫到 evidence package。最小欄位包括 command、target file hash、rate、duration、workers、target environment、p95 / p99、max latency、error rate、throughput、target saturation metric、known gap 與 owner。

Evidence package 的核心用途是讓快速測試可以比較。Vegeta 的結果通常很短，反而更需要保存 command 與 target set，讓下一次修補驗證能跑同一組條件。

核心取捨表

選 Vegeta 的核心訴求：工程師本機 / CI smoke / 修補驗證 / saturation probe 都要快速可重跑、且結果要可以保存比較；不需要完整 scenario 模型也不需要 GUI 報表。若團隊需要完整 user journey、threshold / SLO gate、長期 trend dashboard，直接走 k6 或 Gatling。

進階主題

Reporting 多輸出 format：vegeta report 預設 text summary、加 -type=hist[0,10ms,50ms,100ms,500ms] 給 latency bucket histogram、-type=json 給機器可讀 result、vegeta plot 出 HTML latency chart、vegeta encode -to=csv 轉成可進 spreadsheet / dashboard 的 CSV。binary result 檔可重複 decode 成不同 format，不用重跑壓測。修補驗證的標準作法是保留 results.bin、之後可隨時 re-render report。

Pipe attack workflow：Vegeta 的 stdin/stdout 都是 stream — 可以用 shell pipe 串接 jq 動態產 targets（jq -r '.urls[] | "GET " + .'）、用 vegeta attack | tee results.bin | vegeta report 同時寫檔跟即時看 summary、用 cat results-old.bin results-new.bin | vegeta report 比較兩次結果。這個設計讓 Vegeta 跟 incident drill / chaos test script 容易接合 — 修補 deploy 完跑一次 attack、result 直接 commit 進 git 當 evidence。

CI integration pattern：CI 裡 Vegeta 沒有 k6 那種內建 threshold，要自寫 gate — vegeta report -type=json results.bin | jq '.latencies.p99' 出 p99、bash 比較 budget、超標 exit 非零。把 targets.txt + attack.sh + expected-budget.json commit 進 repo、CI artifact 上傳 results.bin + plot.html，下次 regression 時可以 diff。

排錯與失敗快速判讀

• Requested rate 跟 actual throughput disconnect（要 200rps 實際只跑 80rps）：runner 端先飽和、不是 server 飽和 — 看 vegeta attack stderr 是否報 socket: too many open files、檢查 ulimit -n（生產壓測 runner 至少設 65535）；或 server 端有限速 / rate limit / connection cap 把 request reject 在 TCP 層、Vegeta 看不到完整 response 就被卡
• TCP socket exhaust（runner 端）：constant rate 模型下、若 server 回應慢、connection 會堆積、TIME_WAIT socket 爆 ephemeral port range — 用 -keepalive=true（預設）並調 net.ipv4.tcp_tw_reuse=1、或加 -connections=N 限制 connection pool 上限避免無限堆 socket
• p99 / max latency 異常高、但 server-side metrics 看不到：runner 端 GC pause / CPU steal / network jitter 把 latency 量測污染 — 把 runner 移到跟 target 同 placement group / same AZ、確認 runner CPU 沒被其他 process 搶、duration 拉長到 5min 讓 outlier 變稀釋
• Success rate 100% 但 server 已經爆：targets 沒帶 auth header / 打到 LB 而非 backend、所有 request 在前面就 200 / cache hit、server 根本沒收到壓力 — 檢查 target server access log 的 request count 跟 Vegeta requested rate 是否對得上
• 短時間壓測結果不穩定（同 command 跑兩次差很多）：duration 太短（< 30s）、warm-up 噪音占比太高 — 至少 60s、第一段 5-10s discard、若 endpoint 有 lazy initialization（cache / connection pool / JIT compile）先跑一段 warm-up attack 再正式量

案例回寫

Vegeta 適合回寫單 endpoint hot path 與修補驗證案例。它可接 9.C3 Coinbase ultra-low latency 的 sub-millisecond latency distribution 判讀、9.C25 Tubi feature store 的 p99 < 10ms lookup 驗證、9.C29 Lemino connection limit 的 RDB bottleneck 探測、9.C6 Tinder ElastiCache 的次毫秒 cache lookup 驗證，以及 9.C5 Amazon Ads DynamoDB 的 hot partition 探測。

這些案例的重點是快速定位與比較。Vegeta 頁引用案例時，要把 case 轉成 endpoint、rate、duration、latency budget、target saturation metric 與 runner limit — 例如 Coinbase 的 sub-ms 目標要求 Vegeta runner 必須跟 target 同 placement group、否則 runner 自身的網路 jitter 會吃掉觀測精度。

下一步路由

• 上游：9.4 Saturation Discovery
• 上游：9.5 瓶頸定位流程
• 平行：k6、Gatling、Locust
• 跨模組：6.13 Performance Regression Gate
• 官方：Vegeta documentation

瓶頸定位的責任是回答「為什麼擴 app 沒用」這類問題。當 9.4 Saturation Discovery 找到 knee point 之後、下一步是知道 哪個 resource 先 saturate。沒有定位、容量規劃只能 全部翻倍；有定位、可以 精準加在瓶頸層。

跟其他章節的關係：跟 9.4 是姊妹章（9.4 找出 knee、9.5 定位 knee 的成因）、跟 9.8 效能可觀測性 互補（9.8 訊號治理、9.5 用訊號做定位）。

本章不深入工具操作、聚焦在 方法論 — 怎麼按層次定位、怎麼避免常見誤判、怎麼區分可分散 vs 不可分散瓶頸。

USE method：resource-oriented 觀察

Brendan Gregg 的 USE method 提供逐層定位的最小框架：對每個資源、量三個維度。

Utilization：資源使用率 0-100%。CPU 70%、memory 60%、disk 40% 這類數字。 Saturation：資源排隊量（queue depth）。CPU run queue length、memory swap rate、disk I/O wait queue、connection pool wait count。 Errors：資源層錯誤。CPU page fault、memory OOM、disk I/O error、network packet drop、connection refused。

對每個資源（CPU / RAM / disk / network / DB connection / cache connection / file descriptor）逐一檢查。第一個出現 saturation 上升的資源是 bottleneck、不是 utilization 最高的那個。

USE 跟 RED method（rate / errors / duration）互補：USE 看「哪個資源頂不住」、RED 看「哪個 endpoint 表現變差」。容量規劃通常先用 USE 找瓶頸、再用 RED 看影響面。

詳見 USE Method 卡片。

逐層定位流程

從 application 層往下查、按依賴鏈逐層檢查。多數 bottleneck 在 application 跟 DB 兩層、但不能跳過其他層 — 偶爾真的在意外位置。

1. 應用層（application）：

• thread / coroutine pool 使用率：是否已飽和
• event loop lag（Node.js、async runtime）：> 50ms 是警訊
• GC pause 頻率與時長：影響 p99 / p999
• request queue（accept queue、application internal queue）

2. DB 層：

• connection pool 使用率（最常見隱性 bottleneck）
• slow query frequency
• replication lag
• lock contention（row lock、table lock）
• transaction queue depth

定位到 DB 層瓶頸時、優先檢查 1.13 應用層查詢反模式 清單 — 多數 DB 層瓶頸的根因是「應用程式發給 DB 的 query 寫法」、不是 DB 規格不夠。N+1 query 放大 connection 占用、long-running transaction 放大 lock contention、缺索引讓 slow query frequency 升高、SELECT * 放大 transaction queue。這層判讀走完、再考慮 DB 規格升級或加 replica。

3. Cache 層：

• hit rate（突然下降是訊號）
• eviction rate
• connection 飽和（cache pool 也會耗盡）
• memory utilization

4. Broker / queue 層：

• consumer lag（最重要的單一指標）
• queue depth
• dead-letter rate
• broker connection count

5. 外部 API / 第三方 quota：

• rate limit 觸發頻率
• retry storm（自家 retry 把對方 quota 打爆）
• circuit breaker trip
• timeout rate

6. 網路層：

• bandwidth utilization
• packets per second（PPS limit）
• socket count（file descriptor limit）
• 跨 region / 跨 AZ latency

7. DNS / load balancer：

• DNS resolution latency
• LB connection establishment time
• TLS handshake duration
• backend health check failure

對應案例：Lemino RDB connection limit 是隱性 bottleneck、CPU / RAM 都還行；Tixcraft 付款層獨立 — 把高頻搶票流量跟低頻付款流量分離、避免一層拖累另一層。

Profile 工具鏈

USE 找出哪一層 saturate 之後、profile 工具找出 該層的哪段 code 拖累。

Continuous profiling：Datadog Continuous Profiler、Pyroscope（開源 + Grafana 整合）、Parca（CNCF）、GCP Cloud Profiler、Azure Application Insights Profiler、AWS CodeGuru Profiler。production 持續取樣 CPU / heap / lock、overhead 通常 < 1%。

Distributed tracing：OpenTelemetry、Jaeger、Tempo、AWS X-Ray、GCP Cloud Trace、Azure Application Insights。記錄 request 在每個 service / 每個 stage 花了多少時間、找跨服務的 latency 累積。

Flame graph：profile 結果視覺化的標準。從寬度可以看到「哪段 code 佔 CPU 最多」。學會看 flame graph 是 SRE 的基本功。

Profile diff：壓測 baseline 跟 release candidate 比 stack 差異。看 相對變化 而非絕對值。詳見 Profile Diff 卡片。

對應案例：Netflix Aurora storage / compute 分離 — DB 統一後 application profile 變單純、退化來源更容易識別。

詳見 Continuous Profiling 卡片。

跨層依賴鏈

瓶頸不一定在 本服務、可能在 下游服務。這層判斷常被忽略。

第三方 API quota 是常見隱性瓶頸。Twilio SMS、Stripe API、Slack webhook、Sendgrid email、Google Maps API 都有 rate limit。自家服務看起來健康、實際是 對方 throttle、自家 retry 再讓對方更慢。

跨 region / 跨 zone 網路延遲 是累積的。一個 user request 經過 5 個 service、每個 service 跨 AZ 一次、累積 10-20ms cross-AZ latency。看起來每個 service 都很快、但 end-to-end 慢。

Downstream cache 也是依賴。app 看起來健康、但其實是 cache 在擋；cache 突然 cold start（restart、eviction storm）、application 直接被打爆。

對應案例：PayPay 行動支付 — DynamoDB 寫入可以撐 3K msg/sec、但 APNs / FCM 一天的 quota 有限、推送下游才是瓶頸。

可分散 vs 不可分散瓶頸

定位完瓶頸後、要判斷它 可不可以橫向擴。這個判斷決定能不能用「加機器」解決。

可分散瓶頸：

• stateless app server → 加機器有用
• partitioned KV / OLTP（partition key 均勻時）→ 加 partition 有用
• read replica（read-heavy workload）→ 加 replica 有用
• worker pool → 加 worker 有用

不可分散瓶頸：

• consensus DB（RAFT / Paxos）→ 加節點不一定快（quorum overhead）
• single leader DB（master 寫）→ 必須垂直擴
• 中央 coordinator → 必須拆解或垂直擴
• 共享 cache（hot key）→ 必須改 partition key 或加 local cache

判斷不可分散的關鍵是「協調成本」。一個操作必須 跟所有 / 多數節點協調 才能完成、就不可水平擴。

對應案例：Coinbase RAFT consensus — consensus 不可水平擴、所以 選擇不擴、改用單機極致；Spanner TrueTime — TrueTime 把協調成本 amortize 到 hardware（GPS + 原子鐘）、讓 OLTP 可水平擴。

常見定位陷阱

看單一指標就下結論：CPU 100% 不一定是 bottleneck（可能 saturation queue 空）；CPU 50% 不一定健康（可能 saturation queue 已滿）。always 看 USE 三個維度。

平均看 OK、p99 看不出來：average latency 50ms 看起來健康、p99 500ms 已經出事。用 percentile、不用 average。

Observer effect：profile / tracing 本身有 overhead、量測會輕微影響系統。critical path 上的 instrumentation 要 sampled 不要 100%。

跨 release 比較 baseline 沒對齊：上週的 baseline 對應 v1.2、這週的 candidate 對應 v1.3、但 v1.2 跟 v1.3 之間還有 schema migration / hardware 變化、baseline 已經漂移。重新建 baseline 再 diff。

案例對照

下一步路由

• 上游：9.4 Saturation Discovery
• 下游：9.6 容量規劃模型（針對 bottleneck 規劃）
• 下游：9.9 Improvement Loop（用 profile diff 改進）
• 下游：1.13 應用層查詢反模式與 Query 預算（DB 層 bottleneck 多半在 query 寫法）
• 跨模組：04 可觀測性模組 / 05 部署平台模組

既建知識卡片

• USE Method
• RED Method
• Continuous Profiling
• Profile Diff
• Universal Scalability Law

觀察

Amazon Ads 在 DynamoDB 的關鍵數字（引自 DynamoDB customers）：

讀寫比約 18:1。這個比例反映「曝光發生 1 次、後續查詢可能發生 18 次」的廣告計費邏輯。

判讀

這個案例最重要的不是「DynamoDB 能撐多少」、而是「為什麼可以這樣設計」。

1. 單表分散到上千個 partition：DynamoDB 把每個 table 拆成多個 partition、每個 partition 內部還可以再分散。9000 萬 reads / 秒 是上千個 partition 加總的結果、單一節點達不到這個量級。對應 9.5 瓶頸定位流程 的 sharding 邊界、跟 01 資料庫模組 的 partition 設計。
2. partition key 選擇直接決定容量上限：DynamoDB 的容量是「每 partition 上限 × partition 數量」。partition key 不均勻會出現 hot partition、實際容量遠低於名義容量。對應 9.4 Saturation Discovery 的 saturation 不一定是整體 saturation、而是 最熱的 partition saturation。
3. 99.999% availability ≈ 5 分鐘 / 年的容錯：廣告計費 1 分鐘斷線可能損失幾百萬美金廣告收入。這個 SLO 不是行銷數字、是真實的營收邊界。對應 04.16 SLI / SLO 訊號 與 9.12 SLO 與 Performance Budget。

需要警惕：「9000 萬 reads / 秒」這種敘述通常是 年度峰值的最高一秒、不是平均值。容量規劃要區分「最大瞬時」、「99 百分位平均」、「常態流量」三個不同口徑。

策略

可重用的工程做法：

1. partition key 設計是 KV 容量的第一決策：均勻分散、避免 hot partition、必要時加 random suffix 強制分散。對應 01 資料庫模組 的 schema design 章節。
2. read-heavy 跟 write-heavy 比例變化是容量警訊：當業務邏輯改變（例如新增即時報表）、讀寫比可能跳一個量級、原本的容量規劃會失效。對應 9.8 效能可觀測性 持續監控比例變化。
3. on-demand vs provisioned 是成本 vs 反應速度的取捨：on-demand 自動擴容但成本高、provisioned 便宜但需要預測。Amazon Ads 這種 sustained workload 通常用 provisioned + auto scaling、不用 on-demand。對應 9.7 成本邊界與 efficiency。

跨平台等效：GCP Cloud Bigtable + 良好 row key 設計、Azure Cosmos DB partition key 設計都是對等概念。差異是 DynamoDB 的 partition 透明度（你看不到 partition 數量）vs Bigtable 的明確 tablet 模型。

下一步路由

• 想規劃 KV 高吞吐架構 → 9.5 瓶頸定位流程 + 01 資料庫模組
• 想避免 hot partition → 01.6 高併發資料存取 + 9.4 Saturation Discovery
• 想對照其他 KV 案例 → 9.C11 Minecraft Earth Cosmos DB（Azure 全球分散）
• 想深入 DynamoDB hot partition 反模式 → DynamoDB partition key 反模式
• 想拆 access pattern 對應的 single-table design → DynamoDB single-table design
• 想評估 on-demand vs provisioned 切換時機 → DynamoDB on-demand vs provisioned

引用源

• Amazon DynamoDB Customers
• Handle traffic spikes with Amazon DynamoDB provisioned capacity
• Demystifying Amazon DynamoDB on-demand capacity mode

容量規劃的責任是把「未來 N 個月可能多大」翻成「現在該訂多少 capacity」。這層工作不純靠歷史外推、要結合業務 forecast、事件型成長、頂部風險 buffer。

跟 9.4 Saturation Discovery 的關係：9.4 提供「當前配置能撐多少」、9.6 用這個數字加上 forecast 推「該規劃多少」。沒有 9.4 的 baseline、9.6 只是猜；沒有 9.6 的 forecast、9.4 的 baseline 只是 snapshot。

跟 9.13 擴展軸 的關係：9.13 先決定「沿哪條軸擴」（垂直 / 水平 / Y 軸拆服務 / Z 軸 partition），9.6 才能算出「該擴多少」。同樣是「處理 10 倍流量」、選垂直擴展要算單機規格上限、選水平擴展要算協調成本跟連線池放大、選 Y 軸拆服務要算跨服務 latency budget — 三條軸的容量公式參數完全不同。沒先做 9.13、9.6 的數字會落到錯誤的擴展軸上。

本章是「規劃決策」的章節、不是執行手冊。讀完後讀者能回答：peak 怎麼預測、headroom 訂多少、autoscaler 怎麼配、不可水平擴的服務怎麼處理。

容量公式三項

容量規劃的核心公式可以濃縮成三項相乘：容量 = 預期峰值 × (1 + headroom) / 可擴容速度。每一項都需要獨立分析：

預期峰值（peak forecast）：歷史 baseline × 預期成長 × 事件因子。三項中最影響整體準度。詳見 Peak Forecast 卡片。

Headroom budget：通常 30-50%、為了應付異常 burst + AZ 故障 + forecast 誤差。不同工作負載 headroom 不同。詳見 Headroom Budget 卡片。

可擴容速度（reactive vs predictive）：autoscaler 反應時間 vs 流量上升速度。如果流量上升比 autoscaler 快、必須 提前 pre-scale、不能等 reactive 反應。

這個公式的另一個寫法是「容量 = peak × 安全係數」、安全係數 = (1 + headroom) / 可擴容速度。預測準 + 擴容快 → 安全係數小、容量緊湊；預測差 + 擴容慢 → 安全係數大、成本高。

Peak forecast 方法

Forecast 方法分三層、按業務型態選用。

歷史線性外推：拿過去 N 個月的趨勢、按斜率外推到下 N 個月。適合 sustained growth（B2B SaaS 月增 X%）；不適合 event peak（年度活動）跟 surge（產品爆紅）。

季節性分解（STL：Seasonal-Trend decomposition using Loess）：把長期趨勢、週期成分、殘差分開預測。適合電商（雙 11 / Black Friday）、串流（IPL / Super Bowl）、零售（聖誕節）。需要 至少兩個完整 cycle 的歷史資料。

業務 ML 模型：結合 marketing pipeline（廣告投入）、新用戶獲取（acquisition rate）、留存率、產品變化等多 feature。最精準但成本高、需要 ML team。

最常見錯誤是「拿去年同期 × (1 + 預期成長 %)」：忽略產品改動 + 行銷投入變化 + 外部事件。Prime Day 2025 vs 2024 不只是 +30% — 是 AI shopping assistant 上線、是 ad spend 變化、是新國家上線。

對應案例：Prime Day 年增率 +30% ~ +77% — 連 Amazon 自家每年成長都不能線性外推；Disney+ 新片發布 — 事件型 forecast、按過去新片 metric 預估。

Forecast 必須有 誤差範圍、不能單一數字。給上下界（最壞 / 預期 / 最好）、容量規劃才能用 worst-case 訂 baseline。

Headroom budget 設計

Headroom 不是 over-provisioning 浪費、是容量規劃的安全邊界。常見比例 30-50%、按 saturation 行為跟工作負載敏感度調整。

為什麼是 30-50% 而不是 10%：

• forecast 誤差：預測準度通常 ±20-30%
• burst pattern：瞬間 spike 超過 average peak、需要短時間吸收
• AZ / region failover：一個 AZ 掛、剩下兩個要承擔全部（多 33% 容量）
• 系統老化 / drift：軟硬體升級後 saturation 點可能位移

不同工作負載不同 headroom：

• stateless service：30%（autoscaler 反應快、headroom 可以薄）
• DB：50%（不易擴容、要備援足夠空間）
• broker / queue：60%（consumer 落後恢復時要瞬間吃下積壓）
• consensus DB：80%+（完全不能 reactive 擴）

headroom 太低 → 出事：peak 期間進 cliff、用戶體驗變差。 headroom 太高 → 浪費錢：平日成本拉高、CFO 質疑。

對應案例：GR8 Tech AI 預測 — 預測準了可以降 headroom 比例；預測不準必須拉高 headroom 補回安全邊界。

Growth curve 形狀分類

不同 growth curve 形狀對應不同 forecast 方法跟 review 節奏。

Linear growth：用戶月增 X%。B2B SaaS 最常見。forecast 線性外推、每季 review、headroom 可以薄（成長可預測）。

Step growth：每次行銷 / 活動跳一階、之間 plateau。需要 event tier 規劃、每個事件單獨 forecast、headroom 跟 event 強度連動。

Exponential growth：早期初創、病毒擴散。forecast 容易低估、傳統線性外推會大幅低估；headroom 必須拉到 100%+、不能省。

S-curve growth：成熟產品、會 saturate。Forecast 初期像 exponential、中期 plateau、晚期 mature。需要識別 inflection point、過了就調 forecast 方法。

Cyclical：電商季節性。每年 Black Friday / Cyber Monday / Christmas / Chinese New Year 都重複、forecast 用 STL 季節性分解。

對應案例：Zoom 30x COVID — step growth、外部衝擊讓 baseline 永久上移；Pokemon GO 50x surge — exponential（早期）+ 之後 S-curve；ASOS Black Friday — cyclical。

詳見 Growth Curve 卡片。

Autoscaling sizing

訂好 capacity 之後、要設計 autoscaler 把這個容量 動態使用。

min / max / target metric 三個參數：

• min 太低 → cold start 風險（流量上來時還在 boot）
• min 太高 → 平日浪費
• max 太低 → 限流（peak 時 autoscaler 不能再擴）
• max 太高 → 月底炸帳單（autoscaler 不受控、過 peak 不會主動降）
• target 太高 → autoscale 啟動太晚、進 knee 才反應
• target 太低 → autoscale 太敏感、頻繁 scale up / down 浪費

Predictive vs reactive：

• predictive scaling：根據歷史 pattern 或 ML 模型提前擴
• reactive scaling：根據當下指標擴
• 兩者組合最穩：predictive 處理已知 pattern、reactive 處理 unexpected burst

Scheduled vs metric-based：

• scheduled scaling：時段觸發（年度活動、daily peak）
• metric-based：根據 utilization / queue depth 觸發
• 三層組合（scheduled + predictive + reactive）最穩

不同層的 autoscaler 各自設計：

• EC2 Auto Scaling Group：infrastructure 層
• Kubernetes HPA / VPA：pod 層
• Karpenter：node 層
• DynamoDB auto-scaling：DB capacity 層
• CloudFront：CDN 層

對應案例：Tixcraft 30 分鐘擴 130 倍 — 6 台 → 800 台靠 ASG + AMI prebuild + ELB warmup；Prime Day predictive — pre-scaling 30-77% 年增率提前算進容量。

不可水平擴容服務的容量規劃

部分服務不能用「加機器」解決容量問題。這類服務的容量規劃有獨立邏輯。

典型不可水平擴：

• consensus DB（RAFT / Paxos）：節點數量是 consensus 一部分、不能臨時增減
• single leader DB（PostgreSQL primary、MySQL master）：寫只有一個 leader
• 中央 coordinator：必須拆解才可擴

容量公式變成：單機極限 × headroom、沒有 elastic 救援。 設計重點：

• 預先 provision 到能撐 peak、不依賴 reactive 擴
• 垂直擴容（更大 instance）為主、不是橫向
• 留更高 headroom（80%+）、出事沒有第二招

對應案例：Coinbase pre-provision — RAFT 限制下完全 pre-provision、不 autoscale；Spanner 節點即容量單位 — 雖然全球可擴、但每個 region 內節點數要預先規劃。

跨地理 / 跨 region 容量規劃

跨 region 服務不能用 全球總量 平攤、每個 region 獨立規劃。

為什麼不能聚合：

• 用戶在哪、流量就在哪、不會自動 spread
• 跨 region 切流量有延遲（DNS TTL、用戶習慣）、不能即時 rebalance
• 資料駐留合規可能強制各 region 獨立

規劃方法：

• 每個 region 抽各自的 workload model
• 各自跑 saturation discovery
• 各自訂 headroom（區域峰值 + 區域 AZ failover）
• 跨 region failover plan：哪個 region 掛了、流量去哪、目標 region 要留多少 headroom 接

對應案例：Standard Chartered 7 個受監管市場 — 跨市場獨立容量規劃；Genesys 15 region — 15 主 region + 5 衛星 region 各自規劃；Mercado Libre 18 國 — 每國獨立 cycle。

案例對照

下一步路由

• 上游：9.2 Workload Modeling / 9.4 Saturation Discovery
• 上游：9.13 擴展軸與 Stateless 前提（先選軸再算數量、不可水平擴容服務的判讀基底）
• 下游：9.7 成本邊界與 efficiency（容量翻成成本）
• 下游：9.11 高峰事件準備
• 跨模組：05 部署平台模組 autoscaler 實作

既建知識卡片

• Peak Forecast
• Headroom Budget
• Growth Curve
• Predictive Scaling
• Scheduled Scaling

觀察

Tinder 在 ElastiCache for Valkey 的關鍵數字（引自 ElastiCache customers）：

ElastiCache for Redis 7.1 在 r7g.4xlarge 上可達單節點 100 萬 RPS、單 cluster 5 億 RPS（引自 AWS Database Blog）。

判讀

Tinder 案例值得讀的是「快取在 long-running 服務的角色變化」。

1. 快取不是 DB 的補救、是主要服務面：配對引擎每次互動讀 cache 不讀 DB、cache miss 是 邊緣案例。對應 02 快取模組 的 cache-as-source-of-truth 與 02.4 cache copy freshness boundary 設計。
2. 次毫秒延遲是業務 KPI、不只是技術指標：手指滑動之後 250ms 內必須給結果、否則「卡頓」。中間整個 chain（網路、cache、序列化）的 latency budget 必須緊。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。
3. 長期 sustained growth 的容量曲線是成本曲線：47M MAU 沒有明顯峰谷、容量規劃變成「每月線性擴容 X%」的長期決策、不是峰值規劃。對應 9.7 成本邊界與 efficiency 的長期成本工程。

需要警惕：Tinder 的「configurable matching」業務邏輯複雜、快取資料的 schema 變化頻繁。一個 schema 變更可能讓既有 cache 全部 invalid、引發 cache stampede。對應 02.6 cache migration stampede rollback。

策略

可重用的工程做法：

1. cache layer 容量規劃跟 DB 容量規劃要分開：cache 容量受 working set size 影響、DB 容量受 total dataset 影響、兩者擴容邏輯不一樣。對應 02 快取模組 的 cache sizing。
2. cache 命中率變化是業務變化的訊號：突然命中率掉、可能是新功能影響 access pattern、不一定是 cache 容量問題。對應 9.8 效能可觀測性 的訊號治理。
3. Valkey vs Redis OSS vs MemoryDB 是不同 trade-off：Valkey（社群分支、AWS 主推）、Redis OSS（受授權變化影響）、MemoryDB（持久化）三者選擇影響長期 vendor lock-in。

跨平台等效：GCP Memorystore for Redis / Valkey、Azure Cache for Redis、自建 Redis Cluster + Sentinel 都可以實作對等架構。差異是 vendor 的 patch cadence 與容量擴張流程。

下一步路由

• 想設計 cache layer 容量 → 02 快取模組 + 9.5 瓶頸定位流程
• 想做 latency budget 反推 → 9.12 SLO 與 Performance Budget + 9.1 壓測理論與系統行為
• 想理解 cache stampede 風險 → 02.6 cache migration stampede rollback
• 對照其他 cache 案例 → 9.C5 Amazon Ads DynamoDB（KV 高吞吐）

引用源

• Amazon ElastiCache Customers
• Achieve over 500 million requests per second per cluster with ElastiCache for Redis 7.1
• Optimize Redis Client Performance for ElastiCache and MemoryDB

成本工程的責任是讓容量決策有經濟邊界。沒有成本意識時、容量規劃會「保險起見全部擴」、最終帳單炸裂；有成本意識之後、能 在每一個容量決策點 把「多保險」跟「多省錢」一起評估。

跟 9.6 容量規劃模型 的關係：9.6 算「該訂多少容量」、9.7 算「這樣訂值不值得」。兩者必須一起做、不能先決定容量再算成本。

本章從 cost per request 這個 unit economics 開始、推到 cost curve、TCO、降級成本、人力成本工程化、FinOps 整合。讀完後讀者能回答「容量設計的成本邊界在哪、什麼時候該降級而非擴容」。

Cost per request 模型

雲端帳單從月度視角看是黑箱、從 cost per request 視角看可拆解。

基本公式：月帳單總額 / 月總 RPS = cost per request。但這只是平均、不同 endpoint 成本差很大。 分 stage 拆解：app compute + DB read + DB write + cache + network egress + 第三方 API。每個 stage 自己有 unit cost。 分 endpoint 拆解：登入請求可能 $0.0001、結帳請求可能 $0.001（10x 差距）。原因：結帳走更多 stage、可能跨 region、可能呼叫第三方支付。

對齊業務 metric：

• cost per active user：總成本 / MAU
• cost per transaction：總成本 / 完成的訂單數
• cost per ML inference：總成本 / inference 次數

業務 metric 級別的 cost 才能跟收入對比、才能算 unit economics。

對應案例：Zomato 50% 成本下降 — 算出每筆計費事件的 cost per request 後、發現 TiDB over-provision 拖累、遷移 DynamoDB 後減半；Netflix Aurora 28% 成本降 — DB consolidation 把多套 DB 的 cost 統一到 Aurora、Aurora 自己的 cost per request 更便宜。

詳見 Cost Per Request 卡片。

Cost curve 形狀

不同 pricing 模式的 cost curve 形狀不同、組合起來才能最佳化。

On-demand（pay-per-use）：流量上升、成本同步上升。線性 cost curve。優點：彈性、不用承諾；缺點：單位成本最貴。 Reserved instances（RI）/ Savings Plans：承諾 1-3 年用量、單位成本降 30-60%。階梯 cost curve。優點：便宜；缺點：承諾期內如果用量低、浪費。 Spot instances：用 cloud 閒置 capacity、單位成本降 70-90%。可被中斷。優點：最便宜；缺點：可能突然被收回。

最佳組合通常是「Reserved baseline + On-demand spike + Spot batch」：

• Reserved 覆蓋 baseline 容量（永遠用得到）
• On-demand 處理 peak 跟 unpredicted burst
• Spot 跑 batch 工作（不在 critical path、可被中斷）

對應案例：Riot Games 年省 1000 萬 — 從自管 Mesos 遷到 EKS、降的不只是 instance cost、是 cluster 管理人力 + ops 簡化；Capcom 30% 成本下降 — DynamoDB + EKS 取代自管、釋放 DBA 人力。

Over-provisioning vs under-provisioning 取捨

容量決策的核心經濟學問題：訂多大容量才是最划算？

Over-provisioning 成本：每月多付 $X 雲端費。這個數字直接看帳單。 Under-provisioning 成本：sigma 機率 × downtime × revenue per minute。這個數字更難算 — 需要 historical incident rate + downtime impact analysis。

兩個成本平衡點 = 經濟最佳 headroom。但實務上 under-provisioning 成本不容易量化、保守做法是把 sigma 機率拉高（用 worst-case 估）、headroom 訂寬一點。

Critical workload（金融、醫療、付款）：under-provisioning 成本極高（合約違約 + 客戶流失 + 法規）、寧可 over-provisioning 30-50%。 Non-critical workload（內部工具、分析、batch）：under-provisioning 成本低、可以更貼近 minimum capacity。

對應案例：Zomato TiDB 必須 over-provision — 為了應付 spike、TiDB 必須長期 over-provision；DynamoDB on-demand 不必、pay-per-use 自然處理。

降級的成本邊界

「降級 vs 擴容」是常見容量決策、但常被當成「技術問題」而非「成本問題」。

降級不是免費：

• 流失轉換：UI 顯示「系統忙碌」、用戶可能放棄
• 客訴成本：客服處理客訴的 OpEx
• 品牌損失：社群媒體負面評論、口碑下降
• 合約違約：B2B 客戶可能基於 SLA 求償

算「降級 vs 擴容」哪個成本低：

• 擴容成本：peak 時段多付的 cloud 費用
• 降級成本：上述四項合計
• 哪邊低就選哪邊

降級觸發條件通常按負載門檻 / 成本門檻 / SLA 觸發：

• 負載門檻：utilization > 85% → 啟動降級
• 成本門檻：本月雲端費已超預算 X% → 啟動降級
• SLA 觸發：error budget 快用完 → 啟動降級保 SLA

對應案例：Pokemon GO 50x surge — surge 期間無法等比擴容、必須降級保住核心遊戲機制、犧牲附加功能。

人力成本工程化

雲端帳單是顯性成本、但 人力成本 是常被忽略的隱性容量成本。

自建 vs managed 的人力成本對比：

• 自建 Kafka / PostgreSQL / Redis：需要 DBA / SRE 持續維護 + 升級 + 故障處理
• Managed 服務（MSK、Aurora、ElastiCache）：vendor 負責 patch、backup、failover
• 差距通常 3-10 倍 人力成本

DBA / SRE / network engineer 都是隱性容量成本：

• 一個資深 DBA 在美國年薪 $200K+、台灣 NTD 200-400 萬
• 工程師時間是有上限的、自管系統佔的時間就是 無法投入產品開發 的機會成本

「90% 工程工時下降」是管理 ROI 的關鍵：重點是把工程資源從 維持 轉移到 建構、不是拿來吹噓技術。這條自建 vs managed 的人力成本對比、是 0.22 能力級買 vs 建 裡「計費隨規模成長、自建 TCO 出現交叉點」那條 tripwire 的算法側 — 選型方向在 0.22 判、成本量化在這裡做。

對應案例：Spotify Kafka → Pub/Sub — 不是因為 Pub/Sub 便宜、是因為 Spotify 規模下自管 Kafka 的人力成本不划算；Lemino 90% 工程工時降 — managed 路線讓電信商級新串流服務只用 5-10 個工程師 launch；Capcom DBA 釋放 — 把 DBA 時間從 patching 轉到遊戲品質。

FinOps 跟容量規劃的整合

FinOps 是 財務跟工程的協作框架、把成本決策從事後對帳變成事前規劃。

Showback / chargeback：把雲端成本攤到團隊 / 服務 / feature。每個團隊看得到自己的成本、自然開始 optimize。chargeback（實際扣預算）比 showback（純展示）更有效但組織複雜度高。

每月 cost review 變成容量 review 的一部分：

• 對比預算 vs 實際
• 找出 top 5 cost driver
• 對比上月趨勢、看是否有 anomaly
• 跟 capacity team 一起討論 right-sizing

Spot diversification：spot 中斷風險可以靠 多 instance type 跟多 AZ 分散。例如：spot pool 同時包含 m5.large + m5a.large + m5n.large、各 AZ 都有、單一 type pool 撤回時其他 type 還在。

Right-sizing：定期 review instance type 是否最適。常見浪費：訂太大 instance（CPU / RAM 用 30%）、過時 instance generation（用 c5 沒升到 c7）、reserved 過剩。

反模式

容量成本的常見錯誤模式：

Autoscaling max 設無限大：流量爆衝時 autoscaler 跟著爆衝、月底帳單炸裂。max 必須訂、是 financial circuit breaker。

全部用 on-demand、沒談 reserved / savings plan：cloud spending > $10K/月 已經值得跟雲商 talk discount、savings plan 通常 30-60% off。

沒成本 monitoring、直到帳單來才知道：要建 daily cost dashboard、anomaly 即時 alert、不要等月帳單。

降級用人工觸發、出事時來不及：降級邏輯要 自動化、按 metric 觸發、不是 oncall 工程師看到 dashboard 才下指令。

忘了人力成本：算 build vs buy 只算 cloud 費、忘了 SRE / DBA 時間、結果發現「省的 cloud 費 < 多花的人力」。

案例對照

下一步路由

• 上游：9.6 容量規劃模型
• 下游：9.8 效能可觀測性（cost attribution）
• 跨模組：04.14 cost attribution

既建知識卡片

• Cost Per Request
• Headroom Budget

觀察

Lyft 在 AWS 的關鍵數字（引自 Lyft case study）：

服務組合：Amazon DynamoDB（搭乘追蹤、GPS 座標）、Amazon Redshift（客戶洞察）、Amazon Kinesis（即時事件串流）、AWS Auto Scaling、Amazon EC2 Container Registry。

判讀

Lyft 的工程做法揭露三個微服務容量治理重點。

1. 微服務不是「全部 8x」、是「特定服務 8x」：8x 是 某些核心服務 在週末爆量時刻的擴容比、不是 100 個服務全部 8x。對應 9.5 瓶頸定位流程 必須先做「哪個服務是熱點」的層次定位。
2. 微服務粒度 = 擴容粒度：把 ride matching、payment、driver tracking、notification 切成獨立服務、每個服務的 autoscaling policy 可以獨立設計。對應 03 訊息佇列模組 跟 05 部署平台模組 的服務邊界。
3. GPS 座標寫入 DynamoDB 是高頻 sustained workload：每個 driver 每秒寫 1-2 次位置、200+ 城市 × 每個城市數萬司機 = 巨量持續寫入、跟峰值無關。對應 9.C5 Amazon Ads 的 KV 高吞吐設計同類。

需要警惕：「8x 峰值」是 峰值倍數、不是 尖峰持續時間。週末晚間的尖峰可能持續 3-4 小時、機場特殊事件可能持續 30 分鐘、演唱會結束可能只有 10 分鐘瞬間。容量策略要按持續時間區分。

策略

可重用的工程做法：

1. 微服務粒度切到「同性質擴容單位」：同步 vs async、stateful vs stateless、CPU-bound vs I/O-bound 不該混在同一服務、否則擴容邏輯互相衝突。對應 05 部署平台模組 的 service decomposition。
2. 預測式 + 反應式擴容混用：可預測（早晚通勤）用 scheduled scaling、不可預測（演唱會散場）用 reactive autoscaling、兩者組合。
3. GPS 類持續寫入適合 KV / time-series store：不適合放 OLTP DB、會佔用 transaction 資源。對應 01 資料庫模組 的 storage choice。

跨平台等效：GCP GKE + HPA / VPA / Karpenter、Azure AKS + KEDA、自建 Kubernetes + Cluster Autoscaler 都可以實作對等架構。

下一步路由

• 想做微服務容量治理 → 05 部署平台模組 + 9.6 容量規劃模型
• 想規劃事件型峰值 → 9.11 高峰事件準備 + 9.C2 GR8 Tech
• 想設計高頻 sustained workload → 01 資料庫模組 + 9.C5 Amazon Ads

引用源

• Lyft Case Study
• DynamoDB Customers

效能可觀測性的責任是讓容量決策有訊號基礎。沒有適當訊號時、就算有壓測結果跟容量計畫、也看不到「現在實際距離 saturation 多遠」、無法做即時調整。

跟 9.4 Saturation Discovery 的關係：9.4 找到 saturation 點、9.8 定義持續監控這個點的訊號跟 dashboard。跟 04 可觀測性模組 是 sibling — 04 處理通用觀測、9.8 處理 容量規劃用 的觀測。

本章不重複 04 的訊號治理基礎、聚焦在 容量 / 效能 / 成本三條觀測線怎麼整合。讀完後讀者能設計一個「容量 dashboard」、回答「現在距離 saturation 還有多遠、什麼時候該擴」。

USE method 在 production 持續監控

USE method 不只是壓測時用、production 也要持續監控。

對每個資源（CPU / RAM / disk / network / DB connection / cache pool / file descriptor）量三個維度：

• Utilization（使用率 0-100%）：直觀但會誤判
• Saturation（queue depth）：早期警訊
• Errors（資源層錯誤）：已經出事的訊號

為什麼不能只看 utilization：

• CPU 100% 但 run queue 空 → 還能撐（單純 CPU bound）
• CPU 80% 但 run queue 不斷增長 → 已 saturate（saturation 比 utilization 領先）

Saturation metric 是 capacity warning 的最早訊號：

• queue depth（每個 queue / pool）
• connection pool 使用率（最常見隱性 bottleneck）
• thread pool / coroutine count
• event loop lag（Node.js、async runtime）
• GC pause time / frequency
• cache hit rate / eviction rate
• replication lag

Dashboard 設計：每個關鍵資源獨立 panel、同時顯示 utilization 跟 saturation。alert 在 saturation 起飛 時觸發、不是 utilization 滿。

對應案例：Lemino connection limit — connection saturation 是 RDB 的真正 bottleneck、不是 CPU；Zomato latency 降 90% — 從 TiDB 換到 DynamoDB、saturation 行為完全不同、observability 也要跟著改。

RED method：請求層的容量訊號

RED method 跟 USE 互補、從請求層看容量。

• Rate：requests per second（每個 service / endpoint）
• Errors：error rate
• Duration：latency distribution（histogram、不是單一 percentile）

Duration 比 Errors 早：duration p99 飆通常先於 error rate 上升、是 saturation 的早期警訊。

每個 endpoint 都要有 RED：不能只看全站 average、要分 endpoint。登入 endpoint 跟結帳 endpoint 的 saturation 行為不同、混在一起看不到 issue。

Histogram 是必須、不是 nice-to-have：

• 只記 p99 → 看不到 p999、看不到 distribution shape
• 記 histogram → 可以隨時算任何 percentile、可以做 long-tail 分析
• Prometheus histogram、OpenMetrics histogram 是現代標準

對應案例：GR8 Tech 25ms p95 — p95 是業務 KPI、不是技術指標、每個 endpoint 都有獨立 SLO。

p50 / p95 / p99 / p999 的取捨

不同 percentile 反映不同問題、選錯 percentile 會錯失 issue。

• p50（中位數）：整體狀況、感覺正常的指標、對長尾不敏感
• p95：日常 user-perceived experience、大多數用戶感受到的延遲
• p99：minority but critical 用戶體驗、SLO 常訂在這
• p999：極端長尾、受 GC pause / leader election / retry storm 影響、internal critical 系統訂在這

業務 SLO 通常訂 p99：「99% 用戶 request < 500ms」是常見承諾、合約 SLA 也通常基於 p99。 Internal critical 系統訂 p99.9：金融交易、即時配對、客服 SaaS（5 個 9 可用性對應 5 個 9 latency 期待）。

紀錄分布、不只紀錄 percentile：

• gauge p99 → 看不到 distribution shape、看不到 multimodal 分布
• histogram → 可以重新計算任何 percentile、可以對比 distribution、可以找 anomaly

對應案例：Tubi p99 < 10ms — ML inference 在 p99 才能控制用戶體驗、p50 沒意義；Coinbase sub-ms — 必須關注 p999、RAFT 系統長尾顯著。

詳見 Tail Latency 卡片。

Cost dashboard

成本訊號跟容量訊號要 並列顯示、不要分開看。

Per-service / per-endpoint cost attribution：

• 每個 service 自己的雲端成本
• 拆到每個 endpoint
• 跟 RPS / latency 並列、看「成本上升是因為流量還是低效」

Cost per request 的時序變化：

• 突然上升通常是 退化 訊號（新版本沒效率）
• 緩慢上升通常是 規模 訊號（用戶增加但 efficiency 沒變）

成本異常告警（vs 容量異常告警）：

• 容量告警：utilization > X% → 擴容
• 成本告警：cost spike > X% → review
• 兩者可能同時觸發（autoscaler 擴容也擴 cost）、要區分

跟業務 metric 對齊：cost per active user、cost per transaction、cost per ML inference。業務 metric 級別的 cost 才能 review unit economics。

對應案例：Lyft 100+ 微服務各自 cost — 微服務粒度的 cost attribution、找出哪個 service 過貴；對應 04.14 cost attribution。

Continuous profiling

Continuous profiling 是現代效能 observability 的關鍵環節 — production 持續取 profile（CPU / heap / lock）、隨時可以做 diff 跟 root cause。

工具生態：

• Datadog Continuous Profiler、Pyroscope（開源 + Grafana 整合）、Parca（CNCF）
• GCP Cloud Profiler、Azure Application Insights Profiler、AWS CodeGuru Profiler
• Overhead 通常 < 1% CPU、放心開在 production

跟 distributed tracing 整合：trace → span → profile。一個 slow request 點下去、能看到對應 span、再下去看 profile。

Profile diff 是 release gate 的核心訊號：每次 deploy 後自動對比 baseline、退化幅度過門檻 trigger alert。詳見 9.9 Improvement Loop 跟 Profile Diff 卡片。

對應案例：Netflix 多 DB 統一後 profile 變單純 — DB 統一 → application 層 profile 噪音降低 → 退化定位更快。

Cardinality cost governance

效能 observability 的成本經常爆炸、源頭通常是 high cardinality metric。

高 cardinality 來源：

• per-user metric（user_id label）
• per-request metric（request_id label）
• per-trace metric（trace_id label）

為什麼會爆：Prometheus 等 metric system 為每個 label 組合存獨立 time series、cardinality = 所有 label value 的笛卡爾積。100 萬 user × 100 endpoint × 10 region = 10 億 time series、儲存爆炸。

對策：

• high cardinality 資訊放 log / trace、不放 metric
• metric label 限制在 low-cardinality 維度（service、endpoint、region、status）
• 真的需要 high-cardinality 分析、用 sampled trace + log query

對應 04.10 cardinality cost governance、跟 Metric Cardinality 卡片。

訊號跟 SLO 對接

最後一層整合：每個 saturation metric 都要對應一個 SLO threshold、訊號驅動行動。

訊號 → 行動鏈：

• saturation metric 超 threshold → trigger alert
• alert 觸發 → trigger autoscaler / runbook / oncall
• 持續超 threshold → trigger error budget burn alert
• error budget 用完 → trigger release freeze

Alert 不要太敏感：

• false positive 浪費 oncall、長期會 alert fatigue（Alert Fatigue 卡片）
• 用 multi-window multi-burn-rate alert（Google SRE 推薦）
• 用 symptom-based alert（業務影響）而非 cause-based alert（單一資源）

跟 9.12 SLO 與 Performance Budget 直接對接。

案例對照

下一步路由

• 上游：9.4 Saturation Discovery / 9.5 瓶頸定位流程
• 下游：9.12 SLO 與 Performance Budget
• 跨模組：04 可觀測性模組（基礎訊號）

既建知識卡片

• USE Method
• RED Method
• Tail Latency
• Continuous Profiling
• Cost Per Request

觀察

Niantic Pokémon GO 在 GCP 上的關鍵敘述（引自 Bringing Pokémon GO to life on Google Cloud）：

關鍵敘述：「Niantic chose GKE for its ability to orchestrate container clusters at planetary-scale」「Google CRE seamlessly provisioned extra capacity on behalf of Niantic to stay ahead of their record-setting growth」。

判讀

這個案例最重要的判讀是「surge load 跟可預測峰值是不同問題」。

1. 50x surge 沒辦法事前規劃：任何合理的 capacity planning 都不會預留 50x headroom — 那會讓平日成本爆炸。surge 的工程做法不是「事前撐住」、是「事中快速補上」。對應 9.11 高峰事件準備 跟 08 事故處理模組 的事件管理。
2. CRE 不是技術、是 vendor 關係：Google Customer Reliability Engineering 是 GCP 提供給戰略客戶的 24/7 工程支援團隊。能即時為 Niantic 補容量靠的是 人 + 流程 + 工具 的組合、不是純技術。對應 00.6 操作控制服務選型 的廠商支援能力評估。
3. Kubernetes 是 surge 的前置條件：如果 Niantic 用 VM-based 架構、即使 CRE 想補容量也來不及 boot up。Container orchestrator 把 provisioning 時間從分鐘級降到秒級、才讓 surge 反應變得可能。對應 05 部署平台模組 的 platform 選型。

需要警惕：「Google CRE 即時補容量」這種敘述對中小客戶不適用。一般客戶在 surge 下能依賴的是 自己的 autoscaler、不是 vendor 工程師。設計 surge 對應策略時要假設「沒有 vendor 救援」。

策略

可重用的工程做法：

1. 接受 surge 不可避免、設計快速 onboard 流程：核心問題不是「會不會 surge」、是「surge 之後 24 小時內能不能撐住」。對應 9.11 高峰事件準備 跟 08.8 incident communication。
2. 降級機制作為 surge 救命稻草：當容量不足時、優先保住核心功能、暫時關閉非核心。對應 02.3 cache stampede 跟 01.6 high concurrency access 的降級設計。
3. 預先談好 vendor 緊急支援條款：戰略服務在簽約時就要談好 surge 期間的容量配額、限流豁免、CRE / TAM 支援、不要等出事才談。對應 00 服務選型模組 的 vendor relationship 設計。
4. container-first 是 surge 反應的前置：VM-based 架構在 surge 下擴容速度比 container 慢一個量級、會直接成為 bottleneck。

跨平台等效：AWS Enterprise Support + TAM、Azure Premier Support + CSAM 都有對等服務、但能即時動用工程師補容量的程度跟客戶等級綁定。

下一步路由

• 想對應 surge load → 9.11 高峰事件準備 + 08.6 incident severity trigger
• 想設計降級策略 → 01.6 high concurrency access + 02 快取模組
• 想評估 vendor 支援 → 00.6 operations control service selection
• 對照可預測峰值案例 → 9.C1 AWS Prime Day

引用源

• Bringing Pokémon GO to life on Google Cloud
• Google Customer Reliability Engineering

Improvement loop 的責任是把效能優化從「事件型 hotfix」變成「持續改進的工程流程」。沒有 loop 時、效能問題靠 oncall 觸發、改了又改、改完又退化；有 loop 之後、每次 release 都通過 perf gate、退化在發布前就攔住。

跟 06.13 perf regression gate 的關係：06.13 是 release gate 的一個環節、9.9 是這個 gate 背後的完整工程閉環。06.13 處理「進 gate 後怎麼判斷」、9.9 處理「進 gate 前怎麼產生比較資料」。

本章聚焦在 閉環設計 — 怎麼建 baseline、怎麼跑 re-test、怎麼用 profile diff、怎麼整合 CI。讀完後讀者能設計一個 perf improvement workflow、不是只有 ad-hoc 壓測。

Loop 五個階段

完整的 improvement loop 包含五個階段、缺一不可：

1. Baseline 建立：壓測 + profile 取得「當前正常」snapshot。 2. 變更 + re-test：每次 release candidate 跑壓測、跟 baseline diff。 3. Profile diff：用 flame graph diff 定位退化原因。 4. Fix：rollback 或修正 code path。 5. Update baseline：通過後更新 baseline、進下個 cycle。

少了 baseline → re-test 沒有比較對象、看絕對數字會錯判。 少了 profile diff → 退化定位靠猜、修錯方向。 少了 update baseline → 永遠跟 old baseline 比、退化累積看不出來。 少了 fix → 退化通過 gate、production 出事。

Baseline 設計

Baseline 不是「歷史最佳」、是「最低可接受效能」。

設計原則：

• 不只一個 baseline、按 workload model 訂多個（不同 endpoint、不同 user tier 各自 baseline）
• baseline 必須可重複：固定 seed、固定資料集、固定環境、固定壓測參數
• 定期 review：硬體 / 軟體升級會讓 baseline 該往好的方向走、不更新就是裝盲

儲存策略：

• baseline as artifact：存進 release artifact、隨 release 帶走
• baseline as code：用 Pulumi / Terraform / dedicated config 管理、可 version control
• baseline as service：dedicated service 管 baseline、提供 query API

Drift 監控：baseline 每月對比上月、看趨勢是否往好方向。drift 超門檻 → re-baseline 並 review 原因。

Profile diff

退化定位的關鍵工具是 profile diff — 對比兩次 profile 找 hottest 變化。

工具實作：

• Brendan Gregg 的 differential flame graph：開源、需要手動 generate
• Pyroscope diff：UI 直接對比兩個時間段
• Datadog Continuous Profiler diff：跟 deployment marker 整合
• Parca compare：CNCF 標準
• AWS CodeGuru Profiler：自動偵測 CPU / memory anti-pattern

正確使用方法：

• 在 相同負載 + 相同硬體 + 相同 sampling rate 下取兩次 profile
• 比較 相對變化、不是絕對 CPU%
• 看 wider stack（不只看 leaf function）找 systemic regression

Profile diff 結果通常需要工程師判讀：「多花 20% CPU 但 throughput 多 50%」可能是好變化、不能純自動化判斷退化是否可接受。

對應案例：Netflix Aurora 統一 — DB 層統一後 profile diff 噪音降低、退化來源更容易識別。

Regression gate 整合 CI

效能改進閉環必須整合到 CI、不能只在 release 前一次性跑。

Multi-tier 壓測策略：

• 每個 PR：跑 lightweight perf test（單 endpoint、5 分鐘）、合併前比 baseline
• 主分支 nightly：跑 medium perf test（多 endpoint、30 分鐘）
• Release candidate：跑 complete perf test（完整 workload model、數小時）

Gate 觸發條件：

• p99 退化 > X%（例如 10%）
• 吞吐降 > Y%（例如 5%）
• error rate 升 > Z%
• cost per request 升 > W%

Gate 通過 / 不通過的後果：

• 通過：自動 promote 到下個 stage（staging / canary / production）
• 不通過：block release、自動 notify owner、附 profile diff link

Gate 太敏感的反模式：

• 每天 false positive、最後沒人看（alert fatigue）
• false positive 來源：壓測環境噪音、baseline drift 未更新、業務變化
• 對策：multi-window detection（變化必須持續 N 個 sample）、配合 manual override（資深工程師判斷異常正常）

對應案例：06.13 perf regression gate 的實作建議。

Canary perf check

Canary perf check 是 release 階段的另一道 perf gate。跟 regression gate（pre-release）對應、是 production 階段的監控。

Canary 階段除了看 error rate、也看：

• latency p99 / p999（最先看到的 regression 訊號）
• throughput（是否處理變慢）
• resource utilization（CPU / RAM / connection 變化）
• cost per request（是否更貴）

Canary 流量 vs control 流量比較：

• 同樣流量同樣時段、不同版本的差才有意義
• 不能拿 canary 跟 historical baseline 比（外部變數太多）
• abort condition：canary p99 比 control 退化 > X%

漸進放大策略：1% → 5% → 25% → 50% → 100%、每階段觀察足夠時間（至少 15 分鐘看 long-tail）。

對應案例：Prime Day FIS 8x chaos — canary 模式跟 chaos test 並行、確保新版本在故障場景也撐得住。

Pre-release 改進迴圈頻率

不同層級的 review 在不同節奏：

• 每日 PR 級 perf check：lightweight、單 endpoint、5 分鐘
• 每週 release candidate 完整壓測：完整 workload model、數小時
• 每月 baseline review + drift 評估：對比歷史趨勢、決定是否 re-baseline
• 每季容量地圖 review：跟 9.6 容量規劃模型 連動

頻率不夠 → 退化累積看不到；頻率太高 → 工程資源吃緊。按團隊規模跟 release 節奏調整。

退化的常見來源

知道退化怎麼來、才能設計對應的 detection：

• 新功能引入 N+1 query：ORM lazy loading、loop 內 query。看 DB call count 變化
• ORM 沒下 index、cache miss 飆升：看 slow query 跟 cache hit rate
• 第三方 library upgrade 帶來 overhead：新版本可能多了 telemetry / validation。看 profile diff
• GC tuning 變動：JVM / Go GC config 調整造成 pause time 變化。看 p999
• container resource limit 變動：Kubernetes limit 改、限制更嚴造成 throttling。看 CPU throttling event

反模式

• 只在 release 前一次性壓測：退化已累積數月、找不出原因
• baseline 不更新：永遠跟舊版本比、低估目前狀態
• 改了又改、改完忘記更新 baseline：下次 release 又跟過時 baseline 比、迴圈失效
• 缺 profile diff、退化原因靠猜：修錯方向、退化還在
• gate 訊號跟業務無關：技術指標退化但業務 metric 沒事、被當 false positive

案例對照

下一步路由

• 上游：9.4 Saturation Discovery / 9.5 瓶頸定位
• 下游：9.10 Production-Side 驗證
• 跨模組：06.13 perf regression gate / 06.8 release gate

既建知識卡片

• Profile Diff
• Continuous Profiling
• Canary Perf Check

觀察

Spotify 在 Google Cloud 的遷移敘述（引自 Spotify’s journey to cloud）：

關鍵動機：「moving event delivery to a managed service」— 卸下 Kafka broker 的容量規劃與運維負擔。

判讀

Spotify 遷移揭露三個 broker 容量規劃的長期工程問題。

1. 自管 broker 的容量規劃是長期 tax：Kafka cluster 需要 partition planning、broker 數量、副本因子、disk capacity、network bandwidth、ZooKeeper / KRaft 治理 — 每個維度都要持續規劃、每次擴容都是工程專案。對應 03 訊息佇列模組 的 broker basics 與 9.7 成本邊界與 efficiency 的人力成本評估。
2. managed service 的容量是 trade-off、不是免費午餐：Pub/Sub 自動 scaling、但 vendor lock-in、cost-per-message 累積、message ordering / latency 特性跟 Kafka 不同。遷移本身要驗證 業務語意 跟 Pub/Sub 兼容。對應 03.4 broker basics。
3. 遷移本身是容量規劃題目：把 7500 萬用戶的事件交付從 A 平台搬到 B 平台、不能停機、不能丟 message。這個遷移過程本身就是高併發容量工程。對應 01.3 schema migration rollout evidence 的同類流程。

需要警惕：Spotify 這個決定不是「Kafka 不好」、是「Spotify 規模下、自管 Kafka 的工程投入不划算」。對中小團隊、自管 Kafka 可能是更便宜的選項。讀案例時要看 規模門檻 跟 團隊能力。

策略

可重用的工程做法：

1. broker 自管 vs managed 是長期 TCO 評估：算「平日運維 + 容量擴容 + 故障處理 + 升級遷移」的人力成本、不只算「broker 雲端費用」。對應 9.7 成本邊界與 efficiency。
2. 遷移分階段：dual write → shadow → cutover：先寫兩邊、驗證一致性、再切流量。對應 01.3 schema migration rollout evidence 的同類流程。
3. 業務語意對映是遷移關鍵：Kafka 的 partition / offset / consumer group 在 Pub/Sub 對映成不同概念（subscription / ordering key / message attribute）、不是 1:1。

跨平台等效：AWS SNS / SQS / Kinesis、Amazon MSK（managed Kafka）、Azure Service Bus / Event Hubs / Event Grid 都是對等候選。差異是 message ordering 保證、delivery guarantee、cost model。

下一步路由

• 想評估 broker 自管 vs managed → 03 訊息佇列模組 + 9.7 成本邊界與 efficiency
• 想做大規模 message 系統遷移 → 01.3 schema migration rollout evidence 的對等流程
• 想理解 broker 容量規劃 → 03.4 broker basics
• 對照其他事件型負載 → 9.C5 Amazon Ads

引用源

• Spotify’s journey to cloud: why Spotify migrated its event delivery system from Kafka to Google Cloud Pub/Sub
• Spotify chooses Google Cloud Platform
• Spotify’s experiments with stream processing on Google Cloud Dataflow

本模組跟 模組六：可靠性驗證流程 是 sibling 工程紀律。06 看「失敗模式如何被驗證」，走 SLO、Error Budget、Failure Mode、Chaos Hypothesis 的詞彙；09 看「正常負載如何被量化與規劃」，走 Workload、Saturation、Capacity、Cost、Throughput、Latency 的詞彙。兩個模組共用案例庫但讀法不同：06 從案例讀「失敗模式驗證」、09 從案例讀「容量量化實踐」。

教材定位

效能工程的角色是把「我不知道目前配置能撐多少」這個常見焦慮，變成可量測、可重播、可改進的工程流程。

多數後端服務不會每天遇到高併發，真正的工程問題是平常運作時的容量地圖。平常運作正常時，目前的配置距離 saturation 還有多遠；當意外流量出現時，現有配置能撐到 autoscaling 介入嗎；要加機器時，怎麼算出該加多少、加在哪一層；加了機器之後，怎麼確認瓶頸真的被移除了。

這四個問題不需要假設高併發場景，而是要求系統在任何配置下都能回答「現在的容量地圖長什麼樣」。沒有這張地圖，加機器是猜測、不加機器是賭運氣、改架構是恐慌。

教材邊界

問題節點

問題節點先描述「不知道答案會發生什麼」，再描述「怎麼建立答案」。讀者能先理解這個問題為什麼重要，再看到怎麼處理。

這張表的責任是路由。當讀者卡住時，先問三個問題：是模型還是訊號的問題、是量測還是規劃的問題、是技術瓶頸還是成本邊界的問題。這三個問題會把讀者導向不同主章。

跟既有模組的分工

跟 06 的邊界要特別清楚。06.2 load-testing、6.9 capacity-cost、6.13 perf regression gate 留下「在驗證流程中的角色」入口；09 負責「壓測理論、模型、工具、瓶頸定位、容量規劃、成本邊界」的深化。當讀者問「load test 在 release gate 的判讀條件」屬 06；問「load test 的 workload model 怎麼設計、工具怎麼選、瓶頸怎麼定位」屬 09。

從章節到實作的 chain

各章節交付三樣：問題節點、判讀訊號、控制面 link。判讀完成後沿兩條 chain 進入 implementation。

1. Mechanism chain：點問題節點表的 [control-name] link 進 knowledge-cards，那層展開機制、邊界、context-dependence。例：[saturation point] 的 knowledge-card 是該 control 的 mechanism SSoT。
2. Delivery chain：章節「交接路由」欄位指向下游模組，包括可觀測性（saturation metric / cost dashboard）、部署平台（autoscaling policy / HPA sizing）、可靠性（perf regression gate / SLO budget）與事故處理（capacity incident playbook）。

兩條 chain 走完，控制面交付完整。Implementation 強度取決於兩條 chain 的完成度，章節閱讀本身完成 routing 階段。

主章規劃

14 個主章已完成首輪正文。後續工作是補 vendors/ 工具入口、提升案例回寫密度，並校正各章與 06 reliability 的分工。

主章撰寫順序：9.1 → 9.2 → 9.4 → 9.5 → 9.6 → 9.3 → 9.8 → 9.9 → 9.7 → 9.10 → 9.11 → 9.12。理論與模型先行，工具落地放在 saturation 與 bottleneck 概念成熟之後，最後處理成本與 production 驗證的進階主題。

案例庫規劃

案例庫主軸採「AWS Customer Success Stories」公開案例。這層案例提供具體流量、實例、延遲、成本數字，比一般 engineering blog 更接近實戰判讀。完整索引、讀法與規劃中案例見 9.C 案例正文。

已發佈案例

三篇對應三種負載形狀，讀完可以開始把自己的服務歸類，再回到對應主章規劃容量地圖。

規劃中案例（補不同視角與規模）

Engineering Blog 補充候選

當 AWS 案例缺乏某些工程紀律的深度（例如 chaos hypothesis、cell-based architecture 細節），補引 engineering blog 作為交叉驗證。候選來源：Shopify BFCM、Netflix Tech Blog、Amazon Builders’ Library、Google SRE Book、LinkedIn Engineering、Stripe Engineering、Cloudflare Blog、Discord Engineering、Uber Engineering、Pinterest Engineering 等。這層不另開資料夾，補在主章「案例對照」段。

跨語言適配評估

效能工程使用方式會受語言的並發模型、runtime overhead、profiler 工具鏈與 client library 成熟度影響。

1. 同步 thread-based runtime（Java、C#、傳統 Python / Ruby）：connection pool 是首要瓶頸、blocking I/O 會把 thread 鎖住、壓測時要量 thread saturation 跟 pool exhaustion。
2. async / event-loop runtime（Node.js、Python asyncio、Tokio）：要量 event loop lag、避免 CPU-bound work 阻塞 loop、backpressure 失控時 throughput 跟 latency 會同時崩。
3. Goroutine 或 lightweight task runtime（Go、Erlang）：goroutine 廉價但下游連線、檔案 handle、broker channel 仍是昂貴資源、要量「廉價並發 → 昂貴資源」的轉換點。
4. JIT 語言（JVM、.NET）：warmup 期 latency 高、壓測要區分 cold 與 warm 階段、profile diff 要排除 GC noise。
5. AOT 語言（Go、Rust、C++）：cold start 較快、但 GC（Go）或 allocator 行為仍影響長時間 latency。
6. 動態語言（Python、Ruby、PHP）：interpreter overhead 是基線、要先排除 framework 預設配置的隱性成本（worker model、GIL、autoload）。

服務分類規範

每個討論具體壓測工具或容量服務的章節（k6、JMeter、Gatling、Locust、Vegeta、Grafana k6 Cloud、AWS Distributed Load Testing、Datadog Synthetics、Akamas），都必須包含「成本權衡與機會成本」段落，至少回答：

1. 這個工具降低哪一種風險（容量未知、缺少持續驗證、缺少瓶頸定位）。
2. 工具本身的維運成本：runner、artifact、結果儲存、CI 整合成本。
3. 在大規模壓測下會增加哪些雲端成本（流量費、跨區、目標服務的容量壓力）。
4. 團隊需要承擔哪些前置成本：workload model 設計、結果判讀、baseline 維護。
5. 若選擇更簡單方案（人工 ad-hoc 壓測），會承擔哪些風險。
6. 什麼條件出現時，原本的工具選擇應該被重新評估。

Vendor 清單

實作工具見 vendors — 已建立 k6 / JMeter / Gatling / Locust / Vegeta 五個壓測工具頁、GoReplay / Service Mesh Mirroring / AWS VPC Traffic Mirroring 三個 production traffic replay 頁，Datadog Continuous Profiler / Pyroscope / Parca 三個 continuous profiling 頁，以及 Akamas / Vantage / CloudHealth / AWS Cost Explorer 四個 capacity / cost analysis 頁。跟 06 vendors 的差異：06 收錄壓測工具是為了「驗證流程的工具鏈」、09 收錄是為了「效能工程的工具鏈」、選型角度不同。

Deep article（工具自身的配置、故障、容量）跟 migration playbook（跨工具遷移流程）的撰寫進度見 vendors/ 的「內容覆蓋進度」段。

09 模組專屬知識卡片

09 模組已建立 22 張效能工程與容量規劃專屬卡片、覆蓋理論基礎、量測方法、規劃決策、production 驗證與 SLO 治理四個面向。

理論基礎（5 張）：

• Little’s Law — 並發、到達率、逗留時間的數學關係
• Universal Scalability Law — 擴容到某點後 throughput 反向下降的數學模型
• Saturation Point — linear / knee / cliff 三段曲線的臨界點
• USE Method — 資源層 Utilization / Saturation / Errors
• RED Method — 請求層 Rate / Errors / Duration

Workload 與容量規劃（8 張）：

• Workload Model — production traffic shape 量化模型
• Tail Latency — p99 / p999 長尾為何比平均更能反映 saturation
• Hot Partition — 分散式 KV 的隱性 saturation
• Peak Forecast — 預期峰值的預測方法
• Headroom Budget — 容量規劃的安全餘量
• Growth Curve — 五種典型成長形狀
• Predictive Scaling — 預測式擴容
• Scheduled Scaling — 已知時間表預先擴容

Production 驗證（5 張）：

• Shadow Traffic — production traffic 複製驗證
• Dark Launch — UI 入口暫不開放的發布模式
• Canary Perf Check — canary 階段的 latency 退化檢查
• Profile Diff — 兩次 profile 對比找退化原因
• Continuous Profiling — production 持續低 overhead profile

成本與 SLO（4 張）：

• Cost Per Request — 雲端成本 unit economics
• Performance Budget — 跟 error budget 並列的效能退化額度
• Latency Budget — end-to-end latency 拆到每 stage 配額
• SLO Baseline Drift — SLO 需要重新校準的現象

既有可引用卡片

從其他模組沿用的卡片：

• Load Test
• Throughput
• Consumer Capacity
• Connection Pool
• Backpressure
• Load Shedding
• Rate Limit
• Cold Start
• Thundering Herd
• Bulkhead
• SLI / SLO
• Error Budget
• Metric Cardinality
• Game Day
• Blast Radius
• Autoscaling

模組方法

問題驅動方法的核心是讓案例退到證據角色，讓知識網以「容量量化問題」為主體。

1. 先定義效能或容量問題的責任邊界。
2. 再定義判讀訊號（saturation curve、cost curve、percentile distribution）與門檻條件。
3. 接著定義交接路由與前置控制面。
4. 最後在問題觸發時引用對應服務案例。

規劃方向

本模組的核心是把模組架構為「容量量化問題 + 服務級實踐案例」兩層結構。

1. 問題節點先行：9.1-9.12 主章已建立理論、模型、工具、saturation、瓶頸、容量、成本、可觀測性、改進閉環、production 驗證、高峰準備與 SLO 對接的基礎。
2. 服務級案例庫：以公開效能與容量實踐（Shopify BFCM / Netflix scale / Amazon cost / Google performance budget / LinkedIn capacity planning）作 cases，每個服務累積容量規劃脈絡。
3. 跟 06 共用案例但不同讀法：服務 case 同一批、但 06 讀「失敗模式驗證」、09 讀「容量量化實踐」、避免重複案例蒐集成本。

不經實作即可推進的理由：效能工程的價值在「容量地圖建立與成本邊界判讀」，這層跟具體框架解耦，performance engineering 公開素材成熟，符合先建概念層的條件。

Tripwire

• 寫到第 6 章發現持續繞回 06 已有章節 → 軸線過於相似、合併回 06 或重切。
• 案例庫跟 06 cases/ 重疊度 > 70% → 改共用 06 案例、不另起一份。
• 工具章節寫起來像 vendor 比較表、缺判讀邏輯 → 改寫成「workload model → 工具選型」的決策章節。
• 9.6 capacity planning 跟 9.7 cost engineering 變成兩篇都在講同一個 trade-off → 合併。
• 9.10 production validation 跟 06.20 experiment safety boundary 內容開始重疊 → 明確分工：9.10 走「正常負載驗證」、6.20 走「故障注入安全邊界」。
• 寫 T1 服務第 3 個時、若 case 之間無共通分類軸 → 改用單服務獨立檔，不開資料夾。

模組完成狀態

模組主章與案例庫已完成首輪正文，vendors/ 已建立壓測工具、production traffic replay 與 continuous profiling 第一批工具頁。後續工作排序：先補 capacity / cost analysis 工具頁，再提高 9.7-9.12 對案例的回寫密度，最後整理跟 06 reliability 共用案例的分工。

文件版本：v0.1.0 最後更新：2026-05-12 系列狀態：主章首輪完成，進入工具入口與案例回寫補強

本文是 Prometheus 的 vendor deep article，深化 overview「Cardinality 管理」跟「Memory pressure」段。初次接觸 Prometheus 的讀者建議先讀 Prometheus 服務頁。

定位

Prometheus 的容量模型跟傳統資料庫不同 — 它的容量邊界主要受 active series 數量（cardinality）跟 retention 期決定，而非資料筆數或 disk size。理解 Prometheus 的資源消耗模型，才能判斷什麼時候單機夠用、什麼時候需要 remote write 卸載或遷移到 Mimir / Thanos。

資源消耗模型

Memory：由 active series 決定

Prometheus 把近期的 time series 保存在記憶體（head block）。每個 active series 大約消耗 3-4 KB 記憶體（含 index、chunks、postings；Prometheus TSDB 的業界經驗值，實際依 label 長度與 chunk encoding 而定）。

這是 head block 的記憶體，不含 query execution 跟 WAL replay 的暫時開銷。Heavy PromQL query（大範圍 aggregation、多 series join）會額外消耗數 GB 的暫時記憶體。

判讀指標：prometheus_tsdb_head_series 代表當前 active series 數量，process_resident_memory_bytes 代表實際記憶體使用。兩者的比值偏離預期時（例如 50 萬 series 但記憶體用了 10 GB），可能是 query 記憶體壓力或 WAL corruption。

Disk：由 retention 期與 ingestion rate 決定

Prometheus 的 disk 消耗 = ingestion rate × retention 期 × 壓縮後每 sample 大小（約 1-2 bytes，Gorilla 壓縮算法下的業界經驗值）。

Disk I/O 的瓶頸通常在 compaction — Prometheus 定期把 head block 壓縮成 persistent block。Compaction 期間的 disk write 跟 CPU 使用會短暫上升。SSD 環境下 compaction 通常不是問題；HDD 環境下可能造成 scrape timeout。

CPU：由 scrape 數量與 query 負載決定

Scrape 本身的 CPU 消耗不高（HTTP GET + parse），但 scrape 數量 × scrape 間隔決定了基本的 CPU 基線。1000 個 target × 15 秒間隔 = 每秒 ~67 次 scrape，單核可以處理。

Query 是 CPU 的主要消耗者。Recording rule evaluation、alert rule evaluation、dashboard panel 查詢各自佔 CPU。Recording rule 數量增長到數百條時，evaluation 的 CPU 消耗可能成為瓶頸。

判讀指標：prometheus_rule_evaluation_duration_seconds 的 p99 超過 evaluation interval 時，rule 跑不完、alert 會延遲。

Cardinality 失控的判讀

Cardinality 是 Prometheus 最常見的容量問題。一個意外的高 cardinality label（user_id、request_id、完整 URL）可以在分鐘內把 series 數從 10 萬推到 100 萬、消耗數 GB 記憶體。

判讀訊號

• prometheus_tsdb_head_series 持續成長、斜率陡峭
• prometheus_tsdb_head_active_appenders 成長（新 series 的寫入速率）
• Prometheus 的 memory 持續上升、最終 OOM kill
• Query 延遲增加（更多 series 要掃描）
• Compaction 時間變長

定位方式

1# 找出哪個 metric name 的 series 最多
2topk(10, count by (__name__)({__name__=~".+"}))
3
4# 找出哪個 job（scrape target）的 series 最多
5topk(10, count by (job)({__name__=~".+"}))
6
7# 找出某個 metric 的哪個 label 組合在爆
8count by (method, status) (http_requests_total)

修復方向

• Label 白名單：在 scrape config 或 relabeling rule 中 drop 高 cardinality label
• Metric relabeling：metric_relabel_configs 在 scrape 後、寫入前移除特定 label
• Recording rule 替代：把高 cardinality metric 聚合成低 cardinality 的 recording rule，下游只讀 recording rule
• 移到 traces：user_id / request_id 這類維度放在 trace 的 span attribute 而非 metric label

常見故障模式

OOM Kill

觸發條件：active series 超過記憶體容量、或 heavy query 消耗大量暫時記憶體。

表現：Prometheus process 被 kernel OOM killer 終止。重啟後 WAL replay 可能需要分鐘到十分鐘（取決於 WAL 大小），期間 scrape 跟 query 都不可用。

預防：設定 memory limit alert（process_resident_memory_bytes / machine memory > 70%）、tracking cardinality growth slope、query timeout 限制。

Scrape timeout 連鎖

觸發條件：target 的 metrics endpoint 回應慢（> scrape_timeout）、或 target 數量超過 Prometheus 的並行 scrape 能力。

表現：up metric 為 0、scrape_duration_seconds 升高、dashboard 出現資料斷層（missing data points）。大量 target 同時 timeout 時，Prometheus 的 scrape goroutine pool 被佔滿，影響其他健康 target 的 scrape。

修復：調整 scrape_timeout（預設 10s，太短會造成 false timeout）、把慢 target 移到獨立的 scrape pool、或把 metrics endpoint 的回應最佳化（減少 expose 的 metric 數量）。

WAL corruption

觸發條件：Prometheus process 非正常終止（OOM kill、機器斷電）時，WAL 可能損壞。

表現：重啟後 WAL replay 失敗、Prometheus 無法啟動。Error log 顯示 WAL corrupted 或 invalid segment。

修復：刪除損壞的 WAL segment（丟失對應時間段的資料），重啟 Prometheus。嚴重時刪除整個 data 目錄重新開始（丟失所有歷史資料）。WAL 的持久性保證不如資料庫 — Prometheus 設計上允許短暫資料丟失，長期儲存靠 remote write 到 Mimir / Thanos。

Recording rule evaluation lag

觸發條件：recording rule 數量多且表達式複雜、evaluation 時間超過 evaluation interval。

表現：prometheus_rule_group_last_duration_seconds 超過 prometheus_rule_group_interval_seconds。Dashboard 讀 recording rule 的 panel 看到的資料落後當前時間。Alert rule 也在同一個 evaluation pipeline 裡，evaluation lag 會讓 alert 延遲觸發。

修復：把重的 recording rule 拆到獨立的 rule group（各自 evaluation interval）、最佳化 PromQL expression（減少 aggregation 層數、縮小 time range）、或把 recording rule 卸載到 Mimir（ruler component 獨立擴展）。

何時該從單機 Prometheus 遷出

遷出的第一步通常是加 remote write — Prometheus 繼續本地 scrape 跟短期查詢，長期資料寫到遠端。這是最低風險的演進路徑，不需要改 scrape config 或 PromQL。

下一步路由

• Prometheus 服務頁：overview 跟日常操作
• 4.7 cardinality：cardinality 治理的完整策略
• 4.2 metrics basics：recording rule 跟 rollup 的查詢面設計
• Grafana Stack：Mimir 作為 Prometheus 的長期儲存後端
• 4.23 觀測查詢設計：recording rule 在查詢設計中的定位

KV / Document DB 的容量規劃跟傳統 OLTP 完全不同。OLTP 容量靠「instance type 升級 + read replica」、KV 靠「partition 切分 + capacity unit 配置」。兩者瓶頸不同、可擴範圍不同、設計取捨也不同。

本章針對 DynamoDB、Azure Cosmos DB、Google Cloud Bigtable、MongoDB Atlas 等主流 KV / Document DB、整理容量規劃的共通方法論。讀完後讀者能回答：partition key 怎麼設計才不會 hot partition、on-demand vs provisioned 怎麼選、什麼時候從 single-region 升到 multi-region。

跟 1.1 高併發資料存取 的關係：1.1 處理 OLTP 高併發、本章處理 KV 高併發。兩者讀者群有重疊但解法不同。

跟 9.4 Saturation Discovery 跟 9.6 容量規劃模型 的關係：本章從 DB 視角 看容量、9.4 / 9.6 從 workload 視角 看容量、兩者互補。

KV / Document DB 的容量模型

KV 容量模型可以簡化成一條公式：總容量 = partition 數量 × 每 partition 上限。

vendor 不同、細節不同，但都遵循這個邏輯。

HTTP API DB vs connection-based DB 的本質差異

KV DB 在 surge 場景比 OLTP 有結構性優勢的主因、不只是 partition 設計、是 連線模型 的本質差異。

Connection-based DB（PostgreSQL、MySQL、MongoDB、Cassandra）：

• 用戶端跟 DB 維持 TCP connection、connection 有 state（authenticated session）
• 每個 connection 在 DB server 端佔記憶體 + 一個 process/thread
• connection 上限通常 1K-5K
• application 想開更多 connection、DB 直接拒絕

HTTP API DB（DynamoDB、Cosmos DB、Bigtable、Firestore）：

• 用戶端每次 request 開新 HTTP connection（或用 keep-alive 池）
• DB 端沒有「per-user connection state」、是 stateless API server
• 沒有 connection 上限概念、能力上限是 每 partition 的 RU / RCU
• application 加多少 instance 都不影響 DB

對應 9.C29 Lemino — NTT DOCOMO 串流服務選 DynamoDB 而非 RDB 的關鍵原因是 RDB 的 connection limit 在 surge 場景變成 bottleneck、HTTP API 模型沒這個問題。

判讀含義：選 KV DB 不只是「擴容容易」、是 連線模型 適合無 state HTTP 服務的天然契合。微服務數量增加時、HTTP API DB 不需要每次都 review connection pool 設定。但若 application 仍以 SQL transaction 為主流程設計、改 KV 需要 改 application 架構、不是換 driver 而已。

Amazon DynamoDB：

• 容量單位是 RCU（Read Capacity Unit）跟 WCU（Write Capacity Unit）
• 1 RCU = 1 strongly consistent read of 4KB / sec、2 eventually consistent reads
• 1 WCU = 1 write of 1KB / sec
• 每個 partition 上限：3000 RCU / 1000 WCU、底層 partition 數量透明

Azure Cosmos DB：

• 容量單位是 RU（Request Unit）— 把 read / write / query 統一抽象
• 1 RU = strongly consistent read of 1KB document
• 寫成本約 5x read、複雜 query 可達數百 RU
• 每個 logical partition 上限：10,000 RU/s

Google Cloud Bigtable：

• 容量單位是 node（SSD / HDD）
• 每個 node 約 10,000 reads/sec、10,000 writes/sec（依 row size）
• partition 透明、靠 tablet 自動分裂

MongoDB Atlas：

• 容量單位是 cluster tier（M10、M30、M60 等）+ shard
• 每個 shard 是獨立 mongod replica set、容量按 instance type 跟 storage
• 主動 sharding 設計、跟 DynamoDB 透明 partition 不同

共通點：容量上限不是「單一 number」、是「partition / shard 數量 × 每 partition 上限」。要擴容、要嘛加 partition、要嘛升級 partition、不能像 OLTP 一樣換更大 instance。

Partition key 設計：容量的命脈

partition key 設計不均勻、實際容量遠低於名義。這是 KV DB 最常見的 production issue。

Hot partition 的成因：

• 名義容量 = partition 數量 × 每 partition 上限
• 實際容量 = 最熱 partition 上限（如果分布不均）
• 100K RPS 名義能撐、若 80% 流量集中在 1 個 partition、實際 只能撐 3K RPS（DynamoDB partition 上限）

識別 hot partition 的訊號：

• throughput 上不去、但 average resource utilization 低
• 某些 key 的 request latency 飆、其他 key 正常
• DynamoDB throttling event 出現（即使 capacity 還沒滿）
• Cosmos DB 顯示「per-partition RU consumption skew」

設計策略：

1. 天然均勻 partition key：user_id、order_id、device_id 等天然分布廣的 ID。最簡單、最常用。
2. Composite partition key：把容易集中的維度（event_id）跟均勻的維度（user_id_hash）組合。例如 event_id#user_id_hash_mod_100、強制把同一 event 的流量分散到 100 個 sub-partition。
3. Write sharding：在 partition key 後加 random suffix。event_id#0 ~ event_id#9 讓同一個 event 變成 10 個 partition。讀的時候要 scatter-gather 從 10 個 partition 讀回來。
4. Time-bucket：對時序資料、加 minute / hour bucket。metric#2026-05-13-T12、每個時段一個 partition。

對應案例：

• 9.C5 Amazon Ads — 9000 萬 reads/sec 靠 partition 設計均勻、不是純擴 capacity
• 9.C15 Tixcraft — 售票 event_id 天然容易 hot、必須用 composite key 或 write sharding 分散
• 9.C11 Minecraft Earth — Cosmos DB synthetic partition key 強制分散

詳見 Hot Partition 卡片。

彈性來自 partition key 均勻分布

KV DB 的吞吐彈性等於 partition key 均勻分布的結果。partition key 均勻時、總容量 ≈ partition 數量 × 單 partition 上限；partition key 不均時、實際容量 = 最熱 partition 上限（DynamoDB 每 partition 3000 RCU / 1000 WCU）、跟 partition 總數無關。

對應 9.C15 Tixcraft — 售票 IOPS 從 20 衝到 135K 的 6,750 倍彈性、前提是 partition key 把流量分散到大量 partition（合理做法是 composite key event_id + user_id_hash 或 write sharding event_id + random_suffix）。若用裸 event_id 當 partition key、同一場演唱會所有訂單擠進同一個 partition、實際 IOPS 上限被鎖在 1000 WCU、跟 partition 總數無關。

判讀重點：讀「Amazon Ads 9000 萬 reads/sec」、「DynamoDB 1.51 億 RPS」這類數字、要追問「partition 設計是什麼」、再判斷自己的服務能否複製。換 DynamoDB 是必要前提、partition key 設計是充分前提；只換 DB 而沒解決 partition key、會出「換了 DB 但 hot partition 依舊」的事故。

Capacity mode：on-demand vs provisioned

DynamoDB / Cosmos DB 都提供兩種容量模式、各有適用場景。

On-demand（pay-per-use）：

• 不需事前配置 RCU / WCU / RU
• 自動 scale up / down、處理突發流量
• 單位成本高（約 7x provisioned）
• 適合：流量不可預測、burst 頻繁、開發 / 測試環境

Provisioned（預配置）：

• 預先訂購 RCU / WCU / RU
• 超過配額會 throttle（除非開 auto-scaling）
• 單位成本低
• 適合：流量可預測、sustained workload、生產環境

選型決策：

對應案例：

• 9.C20 Zomato — TiDB 必須長期 over-provision、換 DynamoDB on-demand 後 pay-per-use、50% 成本下降
• 9.C26 PayPay — sustained 3 億 msg/day 適合 provisioned + auto-scaling
• 9.C5 Amazon Ads — 9000 萬 RPS sustained workload 必然 provisioned + careful tuning

詳見 9.7 成本邊界與 efficiency 的成本曲線分析。

計費粒度 vs 工程顆粒

KV / Document DB 的計費單位（DynamoDB 的 RCU/WCU、Cosmos DB 的 RU、Spanner 的 processing unit）決定容量規劃可以從多小開始。計費粒度太大、中小規模負載付過多錢；計費粒度太小、大規模負載要管理很多細項。

對應 9.C10 Spanner — Spanner 早期最小單位是 100 processing units（pu）≈ 1 node、對中小負載門檻過高。後來推出 100 pu 起跳的 granular sizing、讓容量規劃可以從小開始、降低 onboarding 門檻。

選型含義：

• 新服務 / 中小規模：選計費粒度小的選項（Cosmos DB serverless、Spanner granular sizing、DynamoDB on-demand）、避免一開始就為了「未來會用到」過配。中小規模付過配成本、實際就是替「不確定的未來」付保險費、保險費過高代表選錯產品。
• 穩定大規模：計費粒度可大（DynamoDB provisioned with reserved capacity、Spanner full-node provisioning）、單價較低。Reserved capacity 通常綁 1-3 年合約、要看業務 未來 12-24 月需求是否穩定、若業務量可能下降或遷移、Reserved 反成沉沒成本；若業務量穩定上升、Reserved 是合理 hedging。
• POC / 測試：選 on-demand 或 serverless、付實際用量、別為了未實際 production 的 workload 付 reserved 成本。

判讀重點：計費粒度同時是 vendor 商業策略 跟 工程顆粒、選 vendor 時要看 min sizing 跟 增量 granularity、不只看 max throughput。

業務邏輯變化 → 讀寫比跳量級

讀寫比變化是容量規劃的早期警訊、但常被忽略。原始容量規劃通常基於某個讀寫比（例如 1:1 或 5:1）、業務邏輯改變可能讓比例跳一個量級、原容量規劃失效。

對應 9.C5 Amazon Ads — 廣告事件量測讀寫比 18:1（曝光發生 1 次、後續查詢 18 次）。如果業務新增即時報表功能、讀次數從 18 跳到 50、容量規劃要重做、不是「再加一點 capacity」。

常見業務變化導致讀寫比跳量級：

• 新增即時 dashboard：每筆資料被查詢頻率從 1 次跳到 N 次
• 新增推薦演算法：每用戶 read profile 從每次登入 1 次變成每次推薦 1 次（× 推薦頻率）
• 新增 audit / compliance 查詢：每筆敏感資料額外被查 5-10 次
• 新增 cache：讀次數從 100 降到 5（cache hit rate 95%）— 跟其他變化方向相反、是 capacity 該縮容 的訊號、若沒同步 review 反而會繼續按舊容量付錢
• 新增 anti-fraud 檢測：每寫入觸發 N 次 read 驗證

判讀重點：容量規劃 review cadence 不只看流量、要 review 讀寫比 是否漂移。比例跳量級是設計需要重做的訊號、不是單純 capacity 增加（或減少）的訊號。

一致性模型：strong vs eventual vs session

KV / Document DB 通常提供多個 consistency level、不同 level 對應不同延遲跟可用性。

DynamoDB：

• Eventually consistent reads（預設、便宜）：1 sec 內收斂、cost = 0.5 RCU
• Strongly consistent reads：跨 AZ quorum、cost = 1 RCU、不可跨 region
• 沒有中間 level

Cosmos DB（最豐富）：

• Strong：linearizable、跨 region quorum、最高 latency
• Bounded staleness：訂上限（時間 / 版本差異）
• Session：同一 session 內強一致（最常用）
• Consistent prefix：保證寫入順序、不保證收斂時間
• Eventual：最便宜、最終一致

Bigtable：

• Single-region：strongly consistent
• Replicated：eventually consistent

選 consistency level 的工程後果：

• Strong consistency → 跨 region 延遲（quorum round-trip）
• Eventual → 用戶可能看到舊資料、需要 application 容忍
• Session → 大多數網路服務的 sweet spot（用戶看自己寫的東西要立即、別人寫的可以稍晚）

對應案例：

• 9.C10 Spanner — external consistency（線性化）跨地區、付出 quorum 延遲代價
• 9.C30 Microsoft 365 Cosmos DB — 分析平台用 weakest consistency 換最大 throughput

詳見 1.3 Transaction Boundary 的一致性取捨。

Multi-model 取捨

部分 KV / Document DB 支援多個 model interface、同一服務跑不同抽象。

Cosmos DB（最廣 multi-model）：

• SQL API（document）
• MongoDB API（document、wire-protocol compatible）
• Cassandra API（wide-column）
• Gremlin（graph）
• Table（key-value）

DynamoDB（KV + document）：

• 原生 KV、但 attribute 可以是 nested map / list（document-like）
• 沒有 SQL interface（PartiQL 是 query language、不是 model）

Bigtable（wide-column）：

• 沒有 multi-model、純 wide-column
• 替代方案：用 Spanner + Bigtable 組合

Multi-model 的優缺：

• 優勢：同一團隊不必管多個 vendor、ops 簡化
• 優勢：不同 use case 用同一 datastore、減少 data sync
• 限制：vendor lock-in 加深、難換
• 限制：每個 API 都不是 最好 的（compromise）— MongoDB API 跟 native MongoDB 有 behavior 差異

選型建議：

• 已用 single model → 不必為 multi-model 而換
• 多種 use case 同時上 → 評估 Cosmos DB（特別是 MongoDB workload + 新需求）
• 純 KV 高吞吐 → DynamoDB / Bigtable 比 Cosmos DB 通常便宜

對應案例：

• 9.C30 Microsoft 365 — MongoDB → Cosmos DB MongoDB API、應用層幾乎不改、底層改用 Cosmos 分散式架構
• 9.C11 Minecraft Earth — 用 SQL API、不需要 MongoDB compat

KV DB 作為寫入緩衝的特殊用法

本節展開 KV 在 flash-sale 架構 的特殊角色、屬於資料層責任、但跟 9.11 高峰事件準備 跟 03 訊息佇列模組 互補（後者主寫 broker / queue 設計、本節聚焦把 KV 當 buffer 的取捨）。

9.C15 Tixcraft 揭露一個非傳統用法：DynamoDB 不當 OLTP、當 durable queue。

模式：前端把訂單塞進 DynamoDB（高吞吐、partition 均勻）、後端 legacy server 按自己能承受的速度從 DynamoDB 消費。

為什麼用 DynamoDB 而非 SQS / Kafka：

• DynamoDB Stream 提供 change data capture、後端可以 stream 消費
• 寫入後立即可查（OLTP-like）、不是純 fire-and-forget
• partition 設計讓單一事件可以分散到多個 partition
• 同樣 vendor、不必另起一個 broker 服務

適用場景：

• 突發流量遠超後端處理能力
• 後端是 legacy、不容易擴
• 需要寫入後立即可查（用戶看「我下單成功了」）

不適用場景：

• 純 fire-and-forget（用 SQS 更便宜）
• 高吞吐 stream processing（用 Kafka 更專業）
• 順序性嚴格要求（DynamoDB Streams 只在 partition 內保證順序）

詳見 9.C15 Tixcraft 案例 的詳細分析。

連線管理：跟 OLTP 完全不同

KV / Document DB 通常是 HTTP / gRPC 介面、不是 connection pool。這是跟 OLTP 完全不同的設計、影響應用層架構。

OLTP（PostgreSQL / MySQL）：

• 每個 application instance 維護 connection pool（10-100 connections）
• connection 是有狀態的（transaction、session variable）
• pool size × instance 數量 ≤ DB 上限（PostgreSQL 預設 100、PgBouncer 可破百）
• 9.C29 Lemino 案例 揭露 RDB connection 是隱性 bottleneck

KV（DynamoDB / Cosmos DB）：

• 純 HTTP / gRPC、無 stateful connection
• 每個 request 獨立、不必預先 establish connection
• 沒有 connection limit 概念
• 應用層擴容不會打爆 DB connection

這個差異是 KV DB 在 surge 場景 比 OLTP 有優勢的主因 — KV 不會 connection saturate。

隱性限流 vs 明確限流

flash-sale 或極端負載場景的限流可能分散在多層元件、不是單一「rate limiter」。同一架構可能同時包含 隱性 限流（用 DB / LB 上限自然攔截）跟 明確 限流（用排隊系統精確控速）。

對應 9.C15 Tixcraft — 售票架構圖上看不到明確「rate limiter」元件、但限流發生在多層：

• DynamoDB 寫入排隊：DynamoDB 把訂單塞進 queue、傳統 server 按自己能力消費 — DynamoDB throughput 就是隱性限流
• ELB max connection：load balancer 上限自動拒絕超量請求
• Application 層 connection pool：超過 pool size 的 request 排隊或被拒
• 付款層獨立：搶票流量塞爆時、付款不受影響、低頻路徑「自然限流」

對比 9.C16 SeatGeek Virtual Waiting Room 的 明確限流：用 Counters table 精確控發 token 速率、用戶看得到排隊位置。

選擇取捨：

失敗模式延伸：隱性限流的失敗特徵是「provisioned capacity / connection pool 飽和、用戶看到 5xx / timeout、沒人收到排隊位置」— 監控訊號是 DynamoDB throttling event 或 ELB queue length 飆。明確限流的失敗特徵是「排隊系統本身的 DB / counter 飽和、token 發不出來、所有用戶包含 VIP 都被擋」— 監控訊號是 token issuance success rate 掉。兩種失敗對應不同 runbook、混在同一 alert dashboard 會誤判。

適合業務延伸：隱性限流適合「流量瞬間到頂、業務願意接受用戶看不見排隊」的場景（演唱會搶票、Black Friday 開賣瞬間、限量商品）— 業務優先收住流量、用戶體驗可以事後解釋。明確限流適合「流量持續高、用戶等待時間長、需要顯示進度減少跳離」的場景（IPO 開盤、長期熱門商品上架、跨小時的搶購事件）— 用戶能看到「我還有 30 分鐘」會繼續等。

判讀重點：選哪種限流取決於業務願意接受什麼用戶體驗、不是工程偏好。隱性限流用透明度換流量吸收能力、明確限流用流量吸收能力換體驗可見度。兩者並存、沒有「best practice」。

案例對照

9.C16 SeatGeek 把 DynamoDB 當 排隊調度系統、不只當 queue buffer：用 Counters table 控發 token 的速率、Queue table 紀錄序號、Connection table 串 WebSocket。這個架構跟 9.C15 Tixcraft 的「全部塞進 DynamoDB 隱性緩衝」是兩種對立取捨 — Tixcraft 用透明度換流量吸收能力、SeatGeek 用流量吸收能力換體驗可見度。判讀重點：KV DB 不只能當 OLTP 替代品、4 張表組合就能變成業務級調度引擎、選表前要先確定業務需要哪一面。

下一步路由

• 上游：0.2 State Storage Selection — KV vs OLTP vs SearchIndex 選型
• 平行：1.1 高併發資料存取（OLTP 版本）/ 1.3 Transaction Boundary
• 下游：1.11 全球分散式 OLTP、1.12 大規模 DB 遷移實戰（含「預設 DB 治理 pattern」— KV 在大規模平台的選型治理）
• 跨模組：9.4 Saturation Discovery（hot partition 量測）、9.6 容量規劃模型、9.7 成本邊界
• DynamoDB 深入：partition key 反模式、on-demand vs provisioned 切換、single-table design、GSI / LSI 設計
• Cosmos DB 深入：partition key 設計、RU 成本模型、一致性層次工程
• MongoDB 深入：shard key 選型、schema design pattern、connection 管理與 cache 層

既建知識卡片

• Hot Partition
• Saturation Point
• Connection Pool
• Tail Latency

Production-side 驗證的責任是回答「staging 過了 production 一定過嗎」。多數 staging 環境的硬體 / 流量 / 資料 / 第三方依賴都跟 production 不一樣、staging 通過不代表 production 安全。本章處理「在 production 安全驗證新配置」的工程做法。

跟 06.20 experiment safety boundary 的關係：06.20 走「故障注入」的安全邊界（chaos）、9.10 走「正常負載」的 production 驗證（perf）。兩者方法論類似、目標完全不同。chaos test 是「主動破壞看會不會出事」、production perf validation 是「真實流量看新版本能不能跑」。

本章四個工具（shadow traffic、dark launch、canary、production-like load test）按 blast radius 從小到大排列、每個適合不同驗證場景。

Shadow traffic

Shadow traffic 是 blast radius 最小的工具：複製 production traffic 到新版本、但 不把結果返回用戶。

運作機制：

• 用戶看到的還是舊版本回應、體驗不變
• 新版本只是「並行跑、看會不會崩」
• 新版本的結果可以跟舊版本對比、找出邏輯差異
• 對下游的寫入要 特別處理：要麼寫入 sandbox、要麼 dry-run（純驗證 query plan、不真寫）

工具實作：

• GoReplay：tcpdump-based 開源、適合 HTTP
• Service mesh shadow（Istio、Linkerd mirror）：mesh 層 mirror、零 application invasion
• AWS VPC Traffic Mirroring：底層網路層、加密 traffic 要另處理
• Diffy（已 deprecated 但概念有效）：dual-write 對比結果

適合場景：架構大改、想驗證 是否能撐 production traffic 但不能影響用戶。例如「DB 從 PostgreSQL 換 Aurora、想看新 DB 在真實 query pattern 下穩不穩」。

注意事項：

• shadow traffic 也消耗 production 下游資源（DB read、API call）— 必須算進容量
• 加密 / PII 資料需要處理
• shadow 通常跑 1-7 天看 long-tail、不是 30 分鐘就下結論

對應案例：Tixcraft 10K t2.micro 壓測 — pre-event 壓測但走 staging；real shadow 則是 production-traffic-driven 而非合成。

Dark launch

Dark launch 介於 shadow 跟 canary 之間：程式碼上線、走 production traffic、但 UI 入口暫不開放。

跟 shadow 的差別：

• Shadow：traffic 複製、新版本 不寫入真實狀態
• Dark launch：真實寫入 production、但用戶看不到 UI

運作機制：

• 後端 code 部署到 production
• 用 feature flag 控制 UI 暴露
• 從內部 API、cron job、employee-only access 觸發新功能
• 真正寫入 production DB / cache / queue
• 用戶看不到 UI 入口、無感

Exit criteria：

• 跑足夠時間（通常 1-2 週）
• 內部使用沒有 critical issue
• metric 在預期範圍

適合場景：新功能後端風險高、想 production-validate 再開放給用戶。 不適合：純 UI 改動（沒有後端風險、直接 canary）。

對應案例：SeatGeek Virtual Waiting Room 從第三方換到自建、必然有 dark launch 階段驗證 token 配發機制、再正式 cutover。

Canary

Canary 是 production-side 驗證最常用工具：小比例流量導到新版本、跟舊版本對比。

運作機制：

• 小比例（1% / 5% / 10%）流量導到新版本
• 大部分流量（99% / 95% / 90%）走舊版本
• 比較 perf / error / business metric
• 通過 → 漸進放大；不通過 → 自動 rollback

漸進放大策略：1% → 5% → 25% → 50% → 100%、每階段觀察足夠時間（至少 15 分鐘看 long-tail）。

自動 rollback 條件：

• error rate canary 比 control 高 X%（例如 50%）
• p99 latency canary 比 control 退化 X%（例如 10%）
• business metric（conversion rate）canary 比 control 低 X%

Canary perf check 跟一般 canary 的差異：

• 一般 canary：看 error rate 為主
• Canary perf check：看 latency / throughput / cost、退化通常早於 error rate

比較的對象是 control（同時跑的舊版本）、不是 baseline：同樣流量同樣時段才能對比、不能拿 canary 跟昨天 baseline 比（外部變數太多）。

對應案例：Prime Day pre-event 驗證 / FanDuel canary across 20 州 — 按 region 漸進放大、控制 blast radius。

Production-like load test

當需要驗證 peak 場景 但 production 平日流量達不到時、在 production 跑額外的 synthetic load。

為什麼要在 production 跑：

• staging 環境的硬體 / 網路 / 第三方依賴跟 production 不同
• staging 沒有 production 級資料量、cache hit pattern 不一樣
• 只有 production 才能驗證真實 peak

風險高、必須有安全邊界：

• blast radius 限制（用 dedicated test endpoint、限制影響範圍）
• abort condition（什麼訊號觸發停止）
• rollback path（rollback 流程跟時間）
• 通訊（相關 oncall 通知、避免誤判 incident）

通常用在：

• Pre-event 壓測（Black Friday、Super Bowl、IPL 決賽 前一週）
• 重大架構變更後驗證
• 容量規劃 review（每年 / 每季）

跟 06.20 experiment safety boundary 同等嚴格的安全要求：production 壓測本質是 controlled experiment、必須有 game day-level 的計畫跟人員。

對應案例：Prime Day FIS 8x chaos — 把 chaos test 跟 load test 結合、production-like 驗證；Tixcraft 10K t2.micro 壓測 — pre-event 大規模壓測模擬實際售票場景。

A/B test 與 perf 對齊

Product A/B test（測試新功能對 conversion 的影響）同時也是 perf A/B test。

為什麼要對齊：

• 新 feature 可能帶來 perf 退化（多 query、多 component、額外 logic）
• 純看 conversion lift 會誤判：「conversion 上升、所以 OK」可能掩蓋「但 p99 上升 30%」
• A/B 同時看 conversion 跟 perf 兩個 metric

Guardrails：

• 業務 metric 改善 + perf 退化 → 工程判斷是否值得（trade-off review）
• 業務 metric 沒改善 + perf 退化 → 直接 reject
• 業務 metric 改善 + perf 改善 → 直接 ship
• 業務 metric 退化 → 不論 perf 怎樣、reject

對應 06.20 experiment safety boundary 的 experiment guardrails。

Pre-event readiness check（game day）

大事件前跑「全系統 production-like 壓測」、是 production-side 驗證的整合演練。

跟 9.11 高峰事件準備 直接對接 — game day 是 readiness 流程的一個 stage。

Shopify game day、Stripe game day 是業界範本（06 cases 有完整案例）。

安全邊界設計

任何 production-side 驗證都要有清楚的安全邊界、不能臨機應變。

Blast radius：

• 影響哪些用戶（X% 流量、特定 cohort、特定 region）
• 影響哪些 service（受 perf 影響的下游）
• 影響哪些 metric（哪些 business metric 可能變化）

Abort condition：

• 什麼訊號觸發停止（error rate > X%、latency > Y ms、特定 alert 觸發）
• 由誰觸發（自動 vs oncall 手動）
• 觸發後多久內必須完成 abort（< 60 秒）

Rollback path：

• rollback 流程是什麼（feature flag、deployment rollback、traffic shift）
• rollback 需要多久（target < 5 分鐘）
• rollback 是否需要 data 處理（已寫入的資料怎麼處理）

通訊：

• 啟動驗證前 notify 哪些 channel
• 期間 oncall 待命
• 結束後 retro

反模式

• Canary 比例太大（50% 起跳）：出事影響大、blast radius 失控
• 沒 control group：不知道 baseline、看絕對數字會誤判
• Canary 跑太短時間（< 15 分鐘）：看不到 long-tail、看不到 user pattern shift
• 沒 abort condition：人工監控失誤就出事、不可預測
• shadow traffic 寫入真實狀態：可能造成 double charge、duplicate notification
• production load test 沒 notify 相關團隊：被當成 incident、誤觸 escalation

案例對照

下一步路由

• 上游：9.9 Improvement Loop
• 下游：9.11 高峰事件準備
• 跨模組：06.20 experiment safety boundary / 06.4 chaos testing

既建知識卡片

• Shadow Traffic
• Dark Launch
• Canary Perf Check

觀察

Spanner 公開數字（引自 Spanner overview / Spanner performance docs）：

代表性客戶：Google 內部所有支付、廣告計費、Play 商店、Search 索引；公開客戶包括 Blockchain.com、Niantic（部分服務）、Sharechat、ZEE5、Wayfair。

關鍵設計：TrueTime API（GPS + 原子鐘）讓跨地區交易能維持 external consistency、不是 eventual。

判讀

Spanner 案例最值得讀的不是「能撐多大」、是「為什麼要這樣設計才能撐」。

1. 線性擴展是 OLTP 的最高設計目標：「2 nodes → 45K reads/sec、4 nodes → 90K reads/sec」這個 linear scaling 在傳統 OLTP（PostgreSQL、MySQL）做不到 — 因為 跨節點交易 需要 coordinator、coordinator 是 bottleneck。Spanner 用 Paxos + TrueTime 把 coordinator 變成「拓樸感知的多 leader」、才達成線性。對應 01.5 transaction boundary 的設計取捨。
2. 強一致 vs 全球部署不是必須二選：CAP 定理常被解讀為「全球部署只能 eventual consistency」、Spanner 顯示「投入專屬硬體（GPS、原子鐘）+ 演算法（TrueTime）可以同時拿到 strong consistency + global distribution」。但這套硬體投資對其他 vendor 不容易複製。對應 01 資料庫模組 的全球 OLTP 選項。
3. 計費粒度 = 容量規劃顆粒：Spanner 早期最小單位是 100 processing units（pu）≈ 1 node、太大讓中小負載難以用。後來推出 100 pu 起跳的 granular sizing、讓容量規劃可以從小開始。對應 9.7 成本邊界與 efficiency 的容量單位選擇。

需要警惕：「10 億 req/sec」是 Google 內部的某個峰值瞬間、是 Spanner 服務 全部使用者加總、不是單一 instance 數字。讀案例時要區分「全球聚合峰值」跟「單一客戶能拿到的最大配額」。

策略

可重用的工程做法：

1. 跨地區一致性需求要在設計初期決定：如果業務必需 strong consistency（金融、ticketing）、選 Spanner 等對等服務；如果 eventual 可接受（社群、推薦）、選 Cassandra / DynamoDB Global Tables 等更便宜的選項。對應 00 服務選型模組 的全球一致性需求識別。
2. 節點數即容量單位、預先規劃 sizing：Spanner 容量 = 節點數 × 單節點 QPS。每年 capacity review 主要在調節點數、不在調 schema。對應 9.6 容量規劃模型。
3. 跨地區 latency 是強一致的代價：external consistency 必須等多區 quorum、跨洲交易延遲可達 100-200ms。延遲敏感型業務不能用跨地區 strong consistency。對應 9.12 SLO 與 Performance Budget 的 latency budget 反推。

跨平台等效：AWS Aurora DSQL（2024 推出、跨地區 strong consistency）、CockroachDB（自管）、TiDB（自管或 cloud）都是對等候選。差異是 TrueTime / 同等同步機制的成熟度。

下一步路由

• 想評估全球一致性需求 → 00 服務選型模組 + 01.5 transaction boundary
• 想規劃 OLTP 容量 → 9.6 容量規劃模型 + 01 資料庫模組
• 想對照其他 OLTP 案例 → 9.C4 DraftKings Aurora
• 想看不需要強一致的全球 KV → 9.C11 Minecraft Earth Cosmos DB
• 想理解 TrueTime ε 與外部一致性實作 → Spanner TrueTime API 深入
• 想對照 Spanner / Aurora DSQL / CockroachDB 不同一致性層 → Spanner 一致性模型對照

引用源

• Spanner: Always-on, virtually unlimited scale database
• Spanner Performance overview
• Using Cloud Spanner to handle high throughput writes
• Get more out of Spanner with granular instance sizing
• Amazon Aurora DSQL for global-scale financial transactions

高峰事件準備的責任是把「事件臨頭才動手」變成「事前數週流程化準備」。沒有 readiness 流程時、年度活動靠 oncall 撐、出事率高；有流程之後、活動成「routine event」、工程資源穩定釋放。

本章 是 9.10 Production-Side 驗證 跟 9.6 容量規劃模型 在「事件型場景」的應用組合、不重新建立方法論。要看具體方法回到那兩章、本章聚焦在 流程整合。

讀完後讀者能設計一個 T-90 → T-0 的事件準備時程、回答「Black Friday 該怎麼準備、Super Bowl 該怎麼準備、新片發布該怎麼準備」。

事件分類：五種負載形狀

不同事件對應不同準備強度、第一步要分類。

可預期極端峰值：年度活動、預售、賽事決賽。提前數月已知時間、業務影響大。例：Prime Day、Black Friday、Super Bowl、IPL 決賽。 事件型不可預期峰值：賽事高潮、突發新聞、KOL 推廣。時間或大小不完全可預測。例：賽事進球瞬間、KOL 帶貨、突發新聞引發的流量。 Flash-sale 瞬間爆量：售票開賣、報名活動、限量搶購。t=0 瞬間爆量、5-30 分鐘結束。例：演唱會售票、限量商品搶購、報名截止前最後一小時。 產品爆紅 surge：新 app 紅、病毒擴散。完全不可預期、流量會隨熱度消退。例：Pokemon GO、ChatGPT 爆紅初期、TikTok challenge。 結構性 surge：COVID 類外部衝擊、永久 baseline 上移。不會回到舊水準。例：COVID 期間遠距工作工具、烏俄戰爭期間能源類 app。

對應案例：9.C1 / 9.C13 / 9.C21 / 9.C27 / 9.C29（predictable）/ 9.C2 / 9.C4 / 9.C7 / 9.C28（event）/ 9.C15 / 9.C16 / 9.C17（flash-sale）/ 9.C8 / 9.C18（surge）。

T-90 → T-0 準備時程

可預期極端峰值的完整準備時程：

T-90 天：流量 forecast + 容量計畫敲定。確認預期峰值倍數、確認 headroom 比例、確認跨 region / AZ 分布。產出 容量計畫文件。

T-30 天：基礎設施 quota 申請。雲端 instance limit、connection pool、API rate limit、DynamoDB throughput、Lambda concurrency 都要 提前申請、不能事件當天才發現 quota 不夠。AWS Infrastructure Event Management（IEM）等服務在這階段啟動。

T-14 天：第一輪 production-like 壓測。驗證容量計畫是否真的能撐預期峰值、找出第一輪 bottleneck。

T-7 天：完整 game day 演練。注入故障場景（DB failure、AZ outage、第三方 quota 耗盡）、驗證降級、failover、rollback 流程。修正最後問題、更新 runbook。

T-2 天：pre-scaling 開始。CDN cache pre-warm、Lambda provisioned concurrency 啟動、autoscaler scheduled 開始、DB capacity 預先 scale up。避免事件當天還在 boot。

T-0 day：watch room 待命、runbook 開機可執行。所有相關 oncall 跨團隊聯合 channel、dashboard 集中、escalation path 清楚。

T+7 天：retro。對比預測 vs 實際、紀錄 incident 跟 near-miss、列下個事件要改的事。寫進 06 cases 或本模組 cases。

Pre-scaling 策略

T-2 階段的 pre-scaling 是「不依賴 autoscaler 反應」的容量保險。

Pre-scaling 涵蓋層次：

• ELB warm-up：請 AWS 預先 warm up ELB，避免流量上來時 ELB 自身需要時間擴容
• Lambda provisioned concurrency：預先 boot 一定數量 instance、避免 cold start
• DynamoDB / Cosmos DB capacity：scheduled 提前 scale up
• EC2 ASG：min instances 提前拉高
• CDN cache pre-warm：重要 URL 提前 invalidate / pre-populate
• DB connection pool：應用層提前 warm up connection
• Cache warmup：把 hot key 提前 populate 進 cache

Pre-warm window 通常 30 分鐘到 2 小時、取決於：

• Instance boot time（VM-based 慢、container 快）
• Cache warmup 時間（cold cache 命中率低、要時間 populate）
• Connection pool 預熱（DB connection establish 有 latency）

CDN Pre-warm 操作細節

CDN pre-warm 在 T-2 階段是 high-impact 操作、但跟其他 pre-scaling 的特性不同。具體做法：

• 找出活動會大量被讀取的 URL 清單：商品頁、活動 landing page、新 release 內容
• 在每個 CDN edge POP 觸發 cache populate：可以用 vendor warmup API（Cloudflare Argo、Fastly Image Optimizer pre-fetch、Akamai NetStorage push），或從多個 region 發 synthetic request 強制 edge 拉取
• 驗證 hit ratio 已升高：用 vendor dashboard 觀察 cache_status=HIT 比例、確認 pre-warm 生效
• 預估 origin 流量曲線：pre-warm 完成後、活動開始時 edge miss 流量應該大幅降低、origin 容量規劃可以對應放鬆

跟其他 pre-scaling 不同的是 CDN pre-warm 沒有「容量上限」這個概念 — edge cache 是被動填的、warm 完就是 warm、不像 EC2 / Lambda 那樣需要 reserve 容量。風險不在「填不夠」、在「填錯」（key 不對、TTL 設錯讓 pre-warm 立刻過期）。詳見 5.9 邊緣分發 的 purge 與 cacheable 判讀。

事件結束後也要 scheduled scale down：autoscaler 通常 scale up 快、scale down 慢、長期 over-provision 浪費錢。

對應案例：Tixcraft 30 分鐘擴 130 倍 — pre-scaling + Auto Scaling Group + AMI prebuild + ELB warmup 組合；Prime Day pre-scaling — predictive scaling + scheduled scaling 兩種組合。

詳見 Predictive Scaling 卡片 跟 Scheduled Scaling 卡片。

Watch room 設計

T-0 當天的指揮中心、跨團隊聯合 channel。

人員配置：

• 跨團隊聯合 channel：app / infra / network / SRE / business / customer support
• 24/7 輪班（國際事件可能跨 24 小時）
• 明確 incident commander（08.7 incident command roles）

Dashboard 集中：

• 流量 dashboard：總 RPS、按 region 拆分、按 endpoint 拆分
• 延遲 dashboard：p50 / p95 / p99 即時、按 service 拆分
• 錯誤 dashboard：error rate、按 endpoint、按 status code
• 成本 dashboard：當前 hourly cost、預估全天 cost
• 業務 dashboard：訂單數、轉換率、收入

Runbook 隨手可用：常見問題 → 對應動作的明確指引。不要事件當下還在 wiki 找資料。

Escalation path：什麼狀況找誰、多久升級。寫成決策樹、不要靠人記。對應 08.7 incident command roles。

對應 Game Day 卡片。

Vendor 緊急支援

戰略事件可以申請 vendor 工程師待命、是「人力 backup」。

AWS Infrastructure Event Management（IEM）：年度重大事件可以申請、提供 pre-scaling 與專屬監控通道。 GCP Customer Reliability Engineering（CRE）：戰略客戶的 24/7 工程支援、能即時為客戶補容量。 Azure Premier Support + CSAM：對等服務。

注意：這類服務通常綁定 enterprise 等級合約、不是所有客戶都能用。設計事件準備時要假設「沒有 vendor 救援」、vendor 是 bonus 而非 primary plan。

對應案例：GR8 Tech World Cup IEM — AWS Infrastructure Event Management 在 2022 FIFA World Cup 期間支援；Pokemon GO CRE — GCP CRE 即時補容量、撐過 50x surge。

Game day 演練

T-7 階段的核心活動、把 readiness 從計畫變實戰。

演練場景：

• 模擬「事件當天 worst case」
• 注入故障：DB primary failure、AZ outage、第三方 quota 達標、network partition
• 演練降級：哪些功能關閉、用戶看到什麼
• 演練 failover：流量切到備援
• 演練 rollback：發現新版本問題、能不能快速回退

Game day 學習目標：

• runbook 不夠詳細 → 補
• 訊號不夠 → 加 metric / alert
• 人員不夠 → 排班補
• 工具不夠 → 工程補

對應 06 cases Shopify game day — Shopify game day 是業界範本、值得直接參考。

Event tier 分級

不同事件規模對應不同準備強度、不能一律照 T-90 流程跑。

Regular event（每週 promo、small feature launch）：

• scheduled scaling 即可
• 無 dedicated watch room
• 對應 06.8 release gate 的常規 release

Major event（季度行銷、新功能發布）：

• pre-scaling + watch room
• 簡化版 T-14 → T-0 流程
• 跨 team coordination

Critical event（年度大促、Super Bowl、IPL）：

• 完整 T-90 流程
• vendor IEM + game day
• 24/7 watch room
• C-level visibility

對應案例：FanDuel regular game → playoff → Super Bowl 三 tier — NFL 賽季 baseline → playoffs 升 2-3x → championship 升 4-5x → Super Bowl 升 5-10x、每 tier 對應不同準備強度。

事後 retro

T+7 retro 是讓 readiness 持續改進的關鍵。

Retro 必答的問題：

• 流量 forecast 跟實際差多少？（forecast 改進方向）
• 容量 utilization 峰值多少？（headroom 是否合適）
• 有沒有 incident 跟 near-miss？（runbook 更新方向）
• 下個事件要改的事是什麼？

Retro 產出：

• forecast 改進建議（給 9.6）
• 新 runbook 或 runbook 更新
• 新 monitoring / alert
• 新工程任務（補容量、補工具）

對應 08.13 post-incident review — retro 不只用在 incident、event readiness 也需要。

案例對照

下一步路由

• 上游：9.6 容量規劃模型 / 9.10 Production-Side 驗證
• 上游：9.13 擴展軸（pre-scaling 前要分辨可不可水平擴展）
• 跨模組：5.9 邊緣分發與靜態資源（CDN pre-warm / origin protection 是 T-2 核心）
• 跨模組：06.20 experiment safety boundary / 08 事故處理模組

既建知識卡片

• Predictive Scaling
• Scheduled Scaling
• Game Day
• Peak Forecast
• Headroom Budget

觀察

Minecraft Earth 在 Azure Cosmos DB 的關鍵敘述（引自 Minecraft Earth and Azure Cosmos DB）：

Cosmos DB 平台特性（引自 Cosmos DB technical overview）：

• 配置擴容延遲：99 百分位 5 秒內生效
• 多 model 支援：SQL API、MongoDB API、Cassandra API、Gremlin、Table
• partition 動態分裂：透明
• 5 個 well-defined consistency levels（strong / bounded staleness / session / consistent prefix / eventual）

判讀

Cosmos DB 設計揭露三個全球 KV / document DB 的容量設計重點。

1. 一致性是 spectrum、不是 binary：Cosmos DB 提供 5 個層級、每個延遲與吞吐特性不同。AR 遊戲的玩家位置不需要 strong consistency（位置稍微 stale 沒問題）、但庫存交易需要 strong。同一 application 內不同操作選不同 consistency、是進階的容量設計策略。對應 01.5 transaction boundary 的一致性取捨。
2. Request Unit (RU) 是抽象容量單位：1 RU = 1 KB document 的 strong read 成本、寫成本約 5 RU、複雜 query 可達數百 RU。容量規劃變成「估每個操作多少 RU × 操作頻率」、跟「估 CPU / IOPS」是不同的思維。對應 9.6 容量規劃模型 的容量單位設計。
3. turnkey global distribution = 容量單位的全球複製：開啟跨地區後、容量在每個地區都 mirror 一份、成本乘以地區數。對中等規模團隊、turnkey 省下大量 ops、但要算「全球複製的成本是否值得業務需求」。對應 9.7 成本邊界與 efficiency。

需要警惕：「100 萬 RU/s 通過測試」是 壓測通過、不是 生產持續跑。實際營運要看 partition key 設計是否均勻、是否有 hot partition、跨地區複製延遲是否符合業務需求。

策略

可重用的工程做法：

1. 一致性需求分流到不同 collection / table：同一 application 不同操作有不同一致性需求、用不同 collection 配不同 consistency level、不要一刀切。
2. partition key 設計影響容量上限：跟 DynamoDB 一樣、hot partition 會讓名義容量達不到。Cosmos DB 的特殊性是「synthetic partition key」可以混合多個 field 強制分散。對應 9.4 Saturation Discovery 的 hot partition 識別。
3. RU-based pricing 鼓勵 query 最佳化：每個 expensive query 都吃 RU、優化 query 直接降成本。對應 9.9 Performance Improvement Loop 的持續改進迴圈。

跨平台等效：AWS DynamoDB Global Tables（global KV）、GCP Spanner（global SQL with strong consistency）、ScyllaDB Cloud（自管 Cassandra）都是對等候選。差異是 multi-model 廣度（Cosmos 最廣）vs 一致性深度（Spanner 最強）。

下一步路由

• 想設計全球分散 KV → 01 資料庫模組 + 9.6 容量規劃模型
• 想對照強一致全球 OLTP → 9.C10 Spanner
• 想對照單區 KV 高吞吐 → 9.C5 Amazon Ads DynamoDB
• 想理解 consistency level 的取捨 → 01.5 transaction boundary
• 想理解 Cosmos DB 五層一致性的工程選擇 → Cosmos DB 一致性層次工程
• 想做全球 multi-region write 衝突收斂 → Cosmos DB 多 region write 衝突
• 想拆 partition key 設計與全球分散搭配 → Cosmos DB partition key 設計

引用源

• Minecraft Earth and Azure Cosmos DB part 2: Delivering turnkey geographic distribution
• A technical overview of Azure Cosmos DB
• Azure Cosmos DB: Pushing the frontier of globally distributed databases

SLO 與 performance budget 的責任是讓容量決策有「可衡量的目標 + 可審查的代價」。沒有 SLO 時、容量規劃容易變「越大越好」、沒邊界；有 SLO + budget 之後、所有決策都能回答「是否在 budget 內」、「超出 budget 該怎麼辦」。

跟 06.6 SLO 與 Error Budget 的關係：06.6 處理「可靠性 SLO」（用 error budget 凍結 release）、9.12 處理「效能 SLO」（用 performance budget 約束容量）。兩者用同一套方法論、目標不同。讀者可以把本章當作 06.6 的 效能對應 章節。

本章覆蓋 SLI/SLO/SLA 分層、latency budget 分解、performance budget vs error budget、SLO 等級的成本含義、多 SLO 對齊、SLO drift 維護。讀完後讀者能設計一套完整的 SLO + budget 系統、把容量決策跟 SLO 對接。

SLI / SLO / SLA 三層分清

三個名詞常被混用、實際是三個不同層的概念。

SLI（Service Level Indicator）：客觀量測值。p99 latency、availability、throughput、error rate 都是 SLI。 SLO（Service Level Objective）：團隊內部目標。「99.95% 用戶請求 < 500ms」這類具體承諾。 SLA（Service Level Agreement）：對外合約承諾。達不到要退款、違約金、信用補償。

SLO 比 SLA 嚴 — 給內部 buffer。SLA 訂 99.9%、SLO 訂 99.95% — 萬一 SLO 沒達到、SLA 還沒違約、有反應時間。

容量規劃針對 SLO、不是 SLA：SLA 是「最低不能跌破」、SLO 才是「日常目標」。用 SLA 做容量規劃會經常 violate SLA、給用戶 / 客戶不好體驗。

詳見 SLI / SLO 卡片。

Latency budget 分解

Latency budget 是把 SLO 翻成可分解工程目標的關鍵工具。

從 end-to-end latency 開始：

• 用戶感受到的 latency：DNS resolution + TLS handshake + CDN + load balancer + application + cache + DB + serialization + network back
• SLO 訂在 user-perceived：例如「p99 end-to-end < 500ms」

拆到每個 stage 的 budget：

• DNS：5ms（assume cached）
• TLS handshake：50ms（first request）
• CDN：20ms
• Load balancer：5ms
• Application：100ms
• Cache lookup：5ms（hit）/ 100ms（miss）
• DB query：30ms
• Serialization：10ms
• Network return：15ms
• 總和：240ms（cache hit）/ 335ms（miss）

每個 stage 的 budget 必須 跟 SLO 對齊：

• 每個 stage 加總 = SLO 上限
• 任何 stage 超 budget → 該 stage 必須改善（不是其他 stage 來補）
• 每個 stage 必須有 current measurement — 不能訂了沒量

Cross-region call 自帶不可壓縮 latency：

• 同 AZ：< 1ms
• 跨 AZ：1-2ms
• 跨 region 同 continent：20-30ms
• 跨 continent：100-200ms
• SLO 訂 50ms 但服務要跨 region 設計 → 不可能達成

任何新增 stage 都會吃 budget：middleware、sidecar、interceptor、API gateway 都會增加 latency。設計時要明確認知這層代價。

對應案例：Coinbase sub-ms — sub-millisecond 反推所有架構選擇（Cluster Placement Group 壓網路、z1d 壓 CPU、RAFT 壓共識）；Tubi p99 < 10ms — ML inference 多 stage 各自分配 budget。

Performance budget

Performance budget 跟 error budget 是 姊妹概念 — 用同一套方法論處理可靠性 vs 效能。

Error budget（06.6）：

• 每月有允許的 unavailability 額度
• 例如 SLO 99.95% → error budget = 0.05% × 30 days = 21.6 分鐘 / 月
• 額度用完 → freeze new release、focus on reliability

Performance budget（本章）：

• 每月有允許的 latency 退化額度
• 例如「p99 允許比 baseline 高 10ms 連續 X 分鐘」、用 burn rate alert
• 額度用完 → freeze new feature release、focus on perf

兩個 budget 並列、不衝突：

• 一個燒一個健康 → 部分 freeze（freeze 對應的那條）
• 兩個都健康 → 全速 release
• 兩個都燒 → 全面 freeze、deep review

Burn rate alert 比 threshold alert 好：

• threshold：p99 > 500ms 就 alert → false positive 多
• burn rate：過去 1 小時 budget burn rate > 14.4x 就 alert（Google SRE 推薦）→ 對應「再這樣下去 budget 5 分鐘內燒光」

對應案例：Coinbase 延遲就是收入 — 沒 performance budget 等於沒 release control；FanDuel 多 SLO — 直播 vs 投注不同 budget。

SLO 等級的成本含義

不同 SLO 等級對應不同容量成本、選 SLO 就是選成本。

每多一個 9、容量成本指數成長：

• 99 → 99.9：成本 +30-50%
• 99.9 → 99.99：成本 +50-100%
• 99.99 → 99.999：成本 +200-500%

選 SLO 不是 marketing 決策、是工程經濟決策：選太高、燒錢；選太低、用戶不滿。要算 每個 9 對應的業務價值、是否值得對應的容量投資。

對應案例：Amazon Ads 99.999% — 廣告計費 1 分鐘斷線損失幾百萬美金、5 個 9 是真實營收邊界；Genesys 99.999% — B2B 客服 SaaS、客戶停線 = 客戶失去用戶信任、5 個 9 是合約義務。

多 SLO 對齊

同一系統不同工作負載可以有不同 SLO、按業務重要性分級。

設計原則：

• 按「業務重要性 × 用戶感知」分級
• 同一個 endpoint 不同情境可能有不同 SLO（例如登入 vs 結帳）
• 多 SLO 必須有 優先順序、衝突時知道犧牲哪個

範例：

衝突處理：當 capacity 不夠時、優先保 結帳 而非 推薦、即使技術上推薦比較好擴容。

對應案例：FanDuel 直播秒級 SLO vs 投注毫秒級 SLO、同一個 user 同一場 NFL Super Bowl、兩個服務必須分開部署、各自 SLO。

SLO 演進：baseline drift

SLO 不是訂了就不動 — 業務變化要重新校準。

SLO drift 來源：

• Structural surge：COVID 類外部衝擊讓 baseline 永久上移
• Product change：新 feature 改變用戶 journey
• Architectural improvement：DB 換型、cache 加強、CDN 擴點
• User behavior：mobile share 上升、跨 region 比例變化

Drift 不是 anomaly、是 新常態。

Review 節奏：

• 每季 review SLO：拉過去 90 天 SLI 分布、看是否需要調整
• 重大產品改動立即 review
• Drift 確認後要更新：alert threshold、autoscaler trigger、performance budget 額度、容量規劃 baseline

對應案例：Zoom 30x COVID — 30 倍成長後 baseline 永久上移、SLO threshold 跟著重新校準、不能套用 COVID 前的標準。

SLO 跟容量規劃對接

回到本章開頭的論點 — SLO 是容量決策的目標。

容量公式：能撐多少 RPS @ SLO 條件。 規劃時用「SLO-constrained capacity」、不是「max capacity」：

• max capacity：絕對極限、進 cliff
• SLO-constrained capacity：知道在 SLO 條件下能撐多少
• 兩者差 30-50%（headroom）

9.4 saturation 找 knee 是技術指標、9.6 容量規劃用 SLO-constrained knee：

• saturation 在 utilization 80% 時開始
• 但 SLO 可能要求 utilization 60% 以下
• 容量規劃用 60% 而非 80%

跟 9.7 成本工程 對接：

• 每多一個 9 多花多少錢
• 業務需要這個 9 嗎
• 不需要的話降 SLO 省成本

SLO 跟 performance budget 一起用

最後的整合 — error budget + performance budget 一起治理 release 節奏。

Error budget 控制 變更節奏：

• error budget 健康 → release 可以快
• error budget 燒光 → freeze release

Performance budget 控制 容量決策：

• performance budget 健康 → 新 feature 可以引入 perf cost
• performance budget 燒光 → freeze new feature

兩個 budget 並列：

• 都健康 → 全速 release + 新 feature
• error 健康 + perf 燒 → release 但只接 perf-neutral 變更
• error 燒 + perf 健康 → 暫停 release、修可靠性
• 都燒 → 全面 freeze、deep review

對應 06.6 SLO 跟 06.8 release gate。

案例對照

下一步路由

• 上游：9.1 壓測理論（latency budget 反推）
• 上游：9.4 Saturation Discovery（SLO-constrained capacity）
• 跨模組：06.6 SLO 與 Error Budget 政策（可靠性 SLO）
• 跨模組：04.16 SLI / SLO 訊號（量測層）

既建知識卡片

• SLI / SLO
• Latency Budget
• Performance Budget
• SLO Baseline Drift
• Error Budget

觀察

Riot Games 遷移到 EKS 的關鍵數字（引自 Riot Games case study）：

服務組合：Amazon EKS（主要）、AWS Local Zones（低延遲就近部署）、AWS Outposts（on-prem edge）、Karpenter（node lifecycle）、Terraform（IaC）。

關鍵架構決策：從 multi-tenant cluster 模型改成 single-tenant per game — 每個遊戲一個獨立 cluster、避免跨遊戲互相影響。

判讀

Riot Games 案例揭露三個多 cluster K8s 容量治理重點。

1. Cluster 隔離是容量規劃的單位：246 個 cluster 看似很多、但 每個 cluster 是獨立容量單位、不互相影響。一個遊戲的擴容不會吃掉另一個遊戲的容量。對應 05 部署平台模組 的 multi-tenant vs single-tenant 取捨。
2. 延遲門檻反推 region 部署：35ms 是競技遊戲（VALORANT、League）的可接受上限、超過會「卡」。從這個門檻反推：玩家所在 region 不能跨洲、需要區域 cluster。對應 9.12 SLO 與 Performance Budget 的 latency budget。Local Zones / Outposts 是這個門檻的工程回應。
3. Karpenter + Terraform = cluster 容量自動化：246 個 cluster 手動管理會崩。Karpenter（node 動態 lifecycle）+ Terraform（IaC）讓 cluster 級操作可重複、可審查。對應 9.9 Performance Improvement Loop 的自動化迴圈。

需要警惕：「年省 1000 萬」是 vs 自管 Mesos、不是 vs 沒上雲。EKS 仍有 vendor cost、只是比自管便宜。讀案例時要看 baseline 是什麼。另外、單一 cluster 的容量上限（pod 數、node 數）仍是工程現實、超過時要做 cluster sharding（這正是 Riot 走 246 個 cluster 的部分原因）。

策略

可重用的工程做法：

1. single-tenant cluster per workload：每個高敏感度工作負載（每個遊戲、每個關鍵服務）一個獨立 cluster、避免 noisy neighbor。對應 05 部署平台模組。
2. 延遲門檻反推 region 部署數量：先訂 latency budget、再算 玩家分布 × region cluster 數量。region 增加會線性增加 ops 成本、要在 latency 跟 cost 之間找平衡。對應 9.7 成本邊界與 efficiency。
3. cluster 級 IaC + 自動化是 multi-cluster 治理前置：Terraform / Pulumi / Crossplane + Karpenter / Cluster Autoscaler 是基本工具。

跨平台等效：GCP GKE Fleet management（multi-cluster）、Azure Fleet Manager、自建 Cluster API + ArgoCD 都可以做 multi-cluster 治理。差異是 vendor 整合度跟政策。

下一步路由

• 想設計 multi-cluster K8s → 05 部署平台模組 + 9.6 容量規劃模型
• 想做延遲門檻反推部署 → 9.12 SLO 與 Performance Budget + 9.C3 Coinbase
• 想對照微服務 vs multi-cluster → 9.C7 Lyft

引用源

• Riot Games Cuts $10M Annual Infrastructure Costs by Migrating to Amazon EKS
• Riot Games on Using AWS to Improve Gaming

觀察

Hotstar IPL 直播的關鍵數字（引自 Hotstar global record）：

AWS Media Services 在大型事件的歷史記錄：Olympics、Super Bowl、IPL Cricket（引自 AWS large-scale streaming events）。

判讀

Hotstar 案例揭露三個全球直播容量重點。

1. 集中地理區 = CDN 壓力集中：Prime Day 的流量分散全球、單一地區 CDN 不會 saturate；IPL 主要觀眾在印度、所有印度 PoP 同一時間 saturate。CDN 容量規劃必須按地區獨立做、不能用「全球總容量」當保證。對應 04 可觀測性模組 的 cardinality 與地區訊號治理、跟 9.6 容量規劃模型 的「地理分片容量」。
2. 直播跟 VoD 是不同容量問題：VoD 觀眾分散時間、CDN 可預先 cache；直播觀眾集中時間、每一個 manifest / segment 都是 live 拉取、cache hit 反而是危險（拉到舊的 segment）。對應 02 快取模組 的 cache freshness boundary、跟 03 訊息佇列 的 fan-out 設計。
3. 多 bitrate 動態切換 = 真實容量是 bitrate 加權：1860 萬觀眾不是都看 1080p — 印度行動網路下大多看 720p 或 480p、bitrate 加權後的 total bandwidth 可能比想像低。對應 9.2 Workload Modeling 的真實 workload shape。

需要警惕：「1860 萬同時觀看」是 峰值瞬間、不是全程平均。決賽 4 小時、觀眾數呈鐘形曲線、峰值維持時間可能只有 10-30 分鐘（比賽關鍵時刻）。容量規劃要看峰值持續時間、不只看峰值高度。

策略

可重用的工程做法：

1. CDN 容量規劃按地理區分割：不要假設「全球 CDN 總量」夠用、要按主要觀眾分布的地區做容量保證。對應 9.6 容量規劃模型。
2. 直播必須 pre-scaling、不能依賴 reactive：直播開始之後 CDN reactive 擴容已經太晚、觀眾體驗已壞。事件型 scheduled scaling + over-provisioning 是必須。對應 9.11 高峰事件準備。
3. multi-bitrate / ABR streaming 是容量緩衝：當網路擁塞、player 自動降 bitrate、總頻寬壓力下降。這層降級是隱性容量緩衝、要在壓測時驗證。對應 9.4 Saturation Discovery 的 saturation 行為。

跨平台等效：GCP CDN + Media CDN、Azure Front Door + Media Services、Akamai / Cloudflare / Fastly 等 multi-CDN 都是對等候選。差異是 PoP 地理分布跟 manifest 處理能力。

下一步路由

• 想規劃全球直播 → 9.11 高峰事件準備 + 9.6 容量規劃模型
• 想做 CDN 容量設計 → 05 部署平台模組 + 04 可觀測性模組
• 想理解 cache freshness 在直播的影響 → 02.4 cache copy freshness boundary
• 對照其他可預期峰值 → 9.C1 AWS Prime Day（分散全球的峰值）

引用源

• In the news: Hotstar sets new global record for live viewership
• Large scale streaming events on AWS
• Direct to Consumer & Streaming on AWS

觀察

Standard Chartered 在 Aurora 的關鍵敘述（引自 AWS search results 與相關 case study）：

服務組合：Amazon Aurora（PostgreSQL 或 MySQL 相容）、加密 at rest / in transit、多 AZ 部署、跨地區複製（受監管市場各自獨立）。

判讀

受監管銀行案例揭露三個合規驅動容量規劃的重點。

1. 資料駐留限制 = 容量規劃的單位是「per 市場」：7 個受監管市場代表 7 個獨立 cluster（資料不能跨境）、容量規劃變成「7 個獨立規劃 × 各自合規門檻」。對應 00 服務選型模組 的合規要求識別、跟 9.6 容量規劃模型 的地理分片。
2. 「韌性 + 性能」並列、不是 trade-off：傳統工程文化常把可靠性跟性能視為對立、銀行業務要求兩者同時達標。Aurora 的多 AZ storage + replica 同時提供性能（讀分流）跟韌性（故障切換）、達成 韌性即性能 的目標。對應 06.18 reliability metrics governance 的可靠性指標。
3. 遷移本身的合規驗證 = 容量規劃延伸：受監管系統遷移不只是技術測試、還要過合規審查（中央銀行 / 金融監管機關）、每個市場各自審。這個審查 lead time（數月）必須算進遷移時程。對應 01.4 database migration playbook 的合規驅動 migration。

需要警惕：「10x throughput」是 vs 舊系統、不是 vs 競爭對手。受監管銀行的舊系統通常是 1990s-2000s 的 mainframe 或自建 OLTP、性能本來就低。讀案例時要對標的是「自家改善幅度」、不是「絕對性能」。

策略

可重用的工程做法：

1. 資料駐留是容量規劃的硬限制、不是優化選項：受監管市場必須各自獨立 cluster、不能用「全球單一 cluster」優化。對應 00.4 traffic data scale 的合規限制。
2. 多 AZ + 跨地區複製是合規基線、不是優化：銀行業務 RPO / RTO 通常由監管要求（不能丟資料、必須 X 小時內恢復）、不是業務 SLA 選項。對應 06.7 DR rollback rehearsal。
3. 遷移時程要算合規 lead time：每個受監管市場的審查可能 3-12 個月、合計遷移時程是「市場數 × 平均審查月份」、不是「技術遷移月份」。對應 01.4 database migration playbook。

跨平台等效：Azure SQL Hyperscale + Azure regions、GCP Cloud SQL / Spanner + regional configurations、各家雲端的受監管雲端方案（AWS GovCloud、Azure Government、GCP Assured Workloads）都是對等候選。差異是各家對特定監管框架（PCI-DSS、ISO27001、各國金融法規）的認證覆蓋。

下一步路由

• 想規劃受監管產業 OLTP → 00 服務選型模組 + 01 資料庫模組
• 想做合規驅動的容量規劃 → 00.4 traffic data scale + 9.6 容量規劃模型
• 想理解韌性跟性能的同步達成 → 06.18 reliability metrics governance
• 對照其他金融交易案例 → 9.C4 DraftKings Aurora / 9.C3 Coinbase
• 想拆解跨 AZ failover RTO 量級與合規 anti-recommendation → Aurora 跨 AZ failover RTO
• 想評估全球資料常駐與多 region 部署 → Aurora global database 多 region
• 想對照 distributed SQL（CockroachDB / Aurora DSQL / Spanner）的合規場景 → Aurora DSQL / Spanner / CockroachDB 決策樹

引用源

• Amazon Aurora Customer Stories
• Amazon Aurora for Core Banking Systems
• Amazon Aurora DSQL for global-scale financial transactions

觀察

拓元 Tixcraft 在 AWS 的關鍵數字（引自 tixCraft Case Study 與 AWS re:Invent 2015 簡報）：

服務組合（依用戶提供的架構圖）：

• 入口：Amazon Route 53（DNS）+ CloudFront + S3（靜態資源 static.tixcraft.com）
• UI 層：Elastic Load Balancing → EC2 跨 3 個 Availability Zone（Tixcraft UI）
• API 層：ELB → EC2 跨 3 個 AZ（API）+ ElastiCache 加速 session
• 資料層：DynamoDB 作為主要寫入目標（接 UI 寫入跟 API 寫入）
• 付款層：獨立的 EC2 Payment、連到 traditional server（合作金流、跑於企業 data center）
• 同步層：S3 Sync + EC2 Bridge 跟 corporate data center 的 backend 雙向同步

判讀

拓元案例最值得讀的、是它揭露三個 flash-sale 工程設計的非直覺事實。

1. DynamoDB 作為寫入緩衝、不是 OLTP：搶票時的「訂單」先丟進 DynamoDB、傳統 server 用自己能承受的速度消費、即時生效在此架構下不是目標。架構上 DynamoDB 扮演 durable queue 的角色、不是傳統 OLTP DB。這層解耦讓「前端可以擴 130 倍、後端不用同步擴」、避免後端被前端拖垮。對應 03 訊息佇列模組 的 outbox / async delivery 概念、跟 01 資料庫模組 的 transaction boundary 分離。
2. DynamoDB IOPS 從 20 衝到 135,000 = partition 設計能撐：這個 6,750 倍的彈性不是 DynamoDB 魔法、是 partition key 設計均勻 的結果。partition key 不均、IOPS 上限是「最熱 partition 上限」、不是「總和」。對應 9.C5 Amazon Ads 的同一判讀重點、跟 9.4 Saturation Discovery 的 hot partition 識別。
3. 30 分鐘擴 130 倍 = 雲原生架構的存在證明：6 台 → 800 台不是手動操作、是 Auto Scaling Group + AMI prebuild + load balancer warmup 的組合。傳統 IDC 做不到。這層彈性是「30 秒內」flash-sale 的前置條件。對應 05 部署平台模組 的 autoscaling 與 9.6 容量規劃模型。

需要警惕的判讀盲點：

• 「限流到底怎麼做」這個工程社群關心的問題、架構圖上看不到明確元件。可能是「DynamoDB 寫入排隊 = 隱性限流」、也可能是 ELB / WAF / 應用層限流。沒有公開資訊不要過度推測。
• 2015 年的數字、用的還是 t2.micro 跟舊版 DynamoDB throughput model。現在等效實作可能會用 DynamoDB on-demand、AWS WAF、CloudFront WAF rules、或 SeatGeek-style Virtual Waiting Room（見 9.C16）。
• 「30,000 張 / 3 分鐘」是 票房成績、不是 系統極限。系統能撐遠不止這個量、只是票本身賣完了。

策略

可重用的工程做法：

1. flash-sale 的核心架構模式：寫入緩衝 + 慢速消費：前端把訂單塞進可彈性擴容的儲存（DynamoDB / Redis Stream / Kafka）、後端按自己能力消費。這個模式讓「短時間吸收洪峰」跟「實際處理」解耦。對應 03 訊息佇列模組 與 01 資料庫模組。
2. partition key 設計是 flash-sale 的命脈：搶票場景天然容易 hot partition（同一場演唱會 = 同一 event_id）、必須用 composite key（event_id + user_id_hash）或 write sharding（event_id + random_suffix）分散。對應 9.C5 Amazon Ads。
3. flash-sale 必須事先 ELB / Auto Scaling 預熱：開賣前 30-60 分鐘 pre-warm ELB、預先啟動最低額度的 EC2、避免 t=0 時冷啟動。對應 AWS 官方 Flash Sale 工程指引。
4. 付款層獨立、不被搶票流量影響：拓元把 Payment EC2 拉出來、直連傳統金流 server。讓「選位 + 下單」的高頻流量不會塞爆「付款」的低頻流量。對應 9.5 瓶頸定位流程 的關鍵路徑切分。
5. 限流（rate limiting）通常是隱性的、不一定看得到 component：DynamoDB 寫入排隊本身就是隱性限流；也可以加 WAF rate-based rule、ELB request throttling、或前置 Virtual Waiting Room 做明確限流（見 9.C16）。

跨平台等效：GCP Cloud Spanner / Bigtable + Cloud Pub/Sub 作 buffer + GKE autoscaling；Azure Cosmos DB + Service Bus + AKS；自建 PostgreSQL + Kafka + Kubernetes 都可以實作對等架構。差異是 vendor 整合度跟擴容速度。

下一步路由

• 想設計 flash-sale 緩衝架構 → 03 訊息佇列模組 + 01 資料庫模組 + 9.6 容量規劃模型
• 想做 partition key 設計 → 9.C5 Amazon Ads + 01.6 高併發資料存取
• 想做明確限流 / 排隊機制 → 9.C16 SeatGeek Virtual Waiting Room
• 想預熱 ELB / Auto Scaling → 05 部署平台模組 + 9.11 高峰事件準備
• 對照其他售票市場 → 9.C17 BookMyShow（印度市場、年售 2 億張）
• 想理解 flash-sale 場景的 partition key 反模式 → DynamoDB partition key 反模式
• 想評估 on-demand vs provisioned 在 flash-sale 的搭配 → DynamoDB on-demand vs provisioned

引用源

• tixCraft Case Study (AWS)
• tixCraft on AWS re:Invent 2015 Recap (SlideShare)
• tixCraft: Handling Millions of Ticketing Requests with AWS (YouTube)
• Top considerations for Flash sale events (AWS Cloud Operations Blog)
• Handle traffic spikes with Amazon DynamoDB provisioned capacity

觀察

SeatGeek Virtual Waiting Room 架構（引自 AWS Architecture Blog）：

業務動機：取代「第三方 waiting room 服務」、原因是缺乏客製化（VIP 規則、優先級）跟 metrics 可見度。

關鍵機制：

1. Token = 庫存單位：access token 總數 = 可售票數量。沒拿到 token 的用戶被導到 waiting room 頁面、看到排隊位置與預估等待時間。
2. FIFO 或 priority queue：可以按進入順序、也可以對 VIP 客戶優先發 token。
3. Token 失效機制：用戶完成購票 / 主動退出時、token 釋放回 pool、給下一位等候用戶。

判讀

SeatGeek 案例揭露三個明確限流設計重點。

1. 隱性緩衝 vs 明確排隊是兩種架構取捨：Tixcraft 模式「全部塞進 DynamoDB」、用戶以為下單成功、實際處理排隊。SeatGeek 模式「明確告訴你排隊位置」、用戶看得到等待時間。前者犧牲透明度換流量吸收、後者犧牲流量吸收換體驗。對應 9.10 Production-Side 驗證 的用戶體驗 vs 系統行為取捨。
2. WebSocket connection 是 stateful 容量單位：100 萬個 active waiting room 用戶 = 100 萬個 WebSocket connection、每個 connection 都吃記憶體跟 file descriptor。Lambda 沒辦法保持 WebSocket、需要 API Gateway WebSocket API 或 AppSync 配合。對應 05 部署平台模組 的 stateful service 容量規劃。
3. 限流粒度 = 業務粒度：「每分鐘發 N 個 token」這個參數直接決定「每分鐘成交 N 張票」。N 太小、賣不完；N 太大、後端撐不住。N 不是技術參數、是業務 × 後端容量的協商結果。對應 9.6 容量規劃模型 把容量規劃跟業務 KPI 對接。

需要警惕的判讀盲點：

• AWS Architecture Blog 沒提具體流量數字（concurrent users、queue depth、throughput）。讀者無法直接套用到自家容量規劃、必須自己壓測。
• DynamoDB 4 張表的設計 看似簡單、實際上每張表的 partition key / sort key 設計都要仔細想。複製這個架構不等於拿到 SeatGeek 的吞吐能力。
• 「token expiration」機制如果設計不好（例如用戶關閉瀏覽器、token 沒回收）、會導致「排隊很長但實際空著」、影響轉換率。

策略

可重用的工程做法：

1. 明確 vs 隱性限流的選擇：高價值門票（演唱會、限量周邊）適合明確排隊（用戶願意等）；高頻低價值商品（FCFS 折扣）適合隱性緩衝（讓用戶快速完成）。
2. Virtual Waiting Room 是 stateful service、要規劃連線容量：不是 stateless Lambda 一招到底、需要 WebSocket gateway + DynamoDB state store。對應 05 部署平台模組 的混合架構。
3. token 過期策略要寫進設計初稿：用戶離開、付款超時、瀏覽器當掉 — 三種狀況的 token 回收邏輯都不一樣、要明確設計。
4. 可觀測性是「自建 waiting room」勝過「第三方」的關鍵：SeatGeek 換掉第三方就是要 metrics 可見、知道每分鐘 token issue rate、queue depth distribution、token expiration rate、conversion funnel。對應 04 可觀測性模組。

跨平台等效：GCP Cloud Functions + Firestore + Pub/Sub；Azure Functions + Cosmos DB + SignalR；自建 Redis（INCR / TTL）+ WebSocket gateway（Soketi / Socket.IO + Redis adapter）都可以實作對等架構。AWS 還推出官方 Virtual Waiting Room on AWS Solutions、是 SeatGeek 模式的可重用版本。

下一步路由

• 想設計明確排隊限流 → 05 部署平台模組 + 9.11 高峰事件準備
• 對照隱性緩衝模式 → 9.C15 Tixcraft
• 想做 conversion funnel 可觀測性 → 04 可觀測性模組 + 04.16 SLI / SLO 訊號
• 想了解 stateful service 容量規劃 → 05 部署平台模組 + 9.5 瓶頸定位流程

引用源

• Build a Virtual Waiting Room with Amazon DynamoDB and AWS Lambda at SeatGeek
• Virtual Waiting Room on AWS (Solutions)
• How to manage peak traffic on AWS using Queue-it’s virtual waiting room

觀察

BookMyShow 在 AWS 的關鍵敘述（引自 BookMyShow AWS Migration Blog）：

資料架構：

• Data Lake：Amazon S3 統一儲存
• Ingestion：Kafka consumers、AWS Glue ETL、AWS IoT Core（MQTT）
• Processing：Amazon EMR（streaming permanent cluster + batch transient cluster）
• Data Warehouse：Amazon Redshift + materialized views
• Analytics：Amazon Athena（ad-hoc）+ Amazon QuickSight（dashboard）
• ML：Amazon SageMaker（內容熱度、活動熱度、搜尋趨勢模型）
• Orchestration：Amazon MWAA + AWS Step Functions

關鍵業務支撐：「sudden spikes with new movies or events launched」靠 serverless（S3、Glue、Athena、Step Functions、Lambda）自動擴容、無需人工介入。

判讀

BookMyShow 案例揭露三個規模化 ticketing 平台的長期工程重點。

1. 單一搶票 → 常態多事件 = 架構從「為峰值設計」變「為流量分佈設計」：每天上百場電影 + 數十場演唱會 + 各種活動同時開票、每場都是 mini flash-sale。容量問題不再是「為一場演唱會準備」、而是「為每天上百個峰值同時準備」。對應 9.2 Workload Modeling 從單一 workload 變成 workload portfolio。
2. 資料層比交易層更難擴：8 TB → 80 TB 過程中、舊 analytics 系統用 15 年才走到極限。交易層擴容靠 stateless EC2 + auto-scaling 相對容易、資料層 schema migration、ETL 重寫、報表回對都是長 lead time 工作。對應 01 資料庫模組 的 schema migration 與 04 可觀測性模組 的 cost attribution。
3. 跨國市場 = 多重合規約束：印度、新加坡、印尼、中東各自有資料駐留 / 加密 / 報稅規則。S3 + EMR + Redshift 的「資料分區」不只是性能議題、也是合規議題。對應 9.C14 Standard Chartered 的合規容量規劃。

需要警惕的判讀盲點：

• 「年售 2 億張」是 年度總和、不是 峰值。實際單秒峰值（板球比賽決賽開票、寶萊塢新片首映）案例本身沒揭露。
• 案例聚焦在 資料分析層 的遷移、不是 交易層 的 flash-sale 設計。讀者若想學「單場 flash-sale 怎麼撐」、應該回 9.C15 Tixcraft 或 9.C16 SeatGeek。
• 「80% 成本下降」是 vs 15 年舊系統、不是 vs 競爭對手。舊系統的儲存效率、運維成本本來就低、改善幅度部分來自「現代化紅利」、不只是 AWS 服務本身。

策略

可重用的工程做法：

1. 大規模 ticketing 平台要分「交易層」跟「資料層」兩條容量規劃：交易層為單一 event flash-sale 設計（9.C15 / 9.C16 模式）；資料層為「上千場活動的長期分析」設計（BookMyShow 模式）。兩者用不同服務、不同 SLO。
2. 跨國平台先解決資料駐留、再規劃跨國 analytics：印度資料不能搬到新加坡分析、合規必須各國資料本地處理、再彙整 metadata。對應 9.C14 Standard Chartered。
3. serverless data stack 是 ticketing 平台的長期方向：S3 + Glue + Athena + Step Functions 的成本曲線比 EMR cluster 平穩、沒事件時近乎 0、有事件時自動擴。對應 9.7 成本邊界與 efficiency。
4. 遷移時程 4 個月 = 計畫密度極高：15 年資產 4 個月遷完不是常態、需要先把 資料模型 canonical 化、再 batch 平行遷。對應 01.4 database migration playbook 的 schema 對映先行。

跨平台等效：GCP BigQuery + Dataflow + Cloud Storage + Pub/Sub 是對等 stack；Azure Synapse + Data Lake + Event Hubs；自建 Delta Lake + Spark + Kafka 都可以實作對等架構。差異是 vendor 整合度跟 serverless 透明度。

下一步路由

• 想規劃多事件 ticketing 平台 → 9.2 Workload Modeling + 01 資料庫模組
• 想看單一 flash-sale 設計 → 9.C15 Tixcraft + 9.C16 SeatGeek
• 想做跨國合規容量規劃 → 9.C14 Standard Chartered + 00 服務選型模組
• 想做大規模 migration → 01.4 database migration playbook + 9.C9 Spotify migration

引用源

• How BookMyShow saved 80% in costs by migrating to an AWS modern data architecture
• AWS Modern Data Architecture

觀察

Zoom 在 2020 年 COVID 期間的關鍵敘述（引自 DynamoDB Customers）：

關鍵敘述：「On the backend, they were able to manage this surge with Amazon DynamoDB for Zoom Meetings.」

判讀

Zoom surge 揭露三個 SaaS 突發成長的工程重點。

1. SaaS surge 是結構性、不是暫時性：Pokemon GO 上線爆紅後流量會隨熱度消退、Zoom COVID 成長是「永久 baseline 上移」。容量規劃不能假設「過幾個月會回來」、必須假設「3 億 DAU 是新常態」。對應 9.6 容量規劃模型 的長期 baseline 重新校準。
2. DynamoDB 「無限擴容」對 SaaS 元資料層特別適用：Zoom 會議 metadata（room ID、participant list、permission state）是典型 KV 工作負載、partition key（meeting_id）天然均勻、不會 hot partition。對應 9.C5 Amazon Ads 同樣的 partition 均勻優勢。
3. 媒體串流不在 DynamoDB：Zoom 的影音流量是 P2P + edge servers、不經 DynamoDB。DynamoDB 只承擔「control plane」、不承擔「data plane」。這個分離是擴 30 倍的前提 — 控制面跟資料面解耦、控制面用 managed 服務、資料面用專屬基礎設施。對應 9.5 瓶頸定位流程 的關鍵路徑切分。

需要警惕：「nearly infinitely」是行銷敘述、不是工程承諾。實務上 Zoom 在 COVID 初期確實遇到 outage 與性能問題、後續才穩定。讀案例時要看 最終狀態 跟 過程中的 incident。

策略

可重用的工程做法：

1. 控制面跟資料面分離：高頻 metadata 操作放 managed KV（DynamoDB / Cosmos DB / Firestore）、大資料量串流放專屬基礎設施（CDN / WebRTC / 自管 servers）。對應 05 部署平台模組 與 9.5 瓶頸定位流程。
2. surge 後重新校準 SLO baseline：30x 成長之後、SLO 的「正常範圍」要更新、否則 monitoring 會誤報。對應 9.12 SLO 與 Performance Budget 的 SLO 演進。
3. 長期 surge 觸發架構重新評估：DynamoDB 是「擴大量」的好選擇、但成本也跟著放大。當 baseline 從 1000 萬永久升到 3 億、原本的 on-demand 模式可能變得貴、要考慮 provisioned + auto-scaling 組合。對應 9.7 成本邊界與 efficiency。

跨平台等效：Google Meet 也用 Spanner / Firestore、Microsoft Teams 用 Cosmos DB — 三家視訊會議都靠 managed KV 撐 metadata、是同一個架構模式的不同 vendor 實作。

下一步路由

• 對照 product surge → 9.C8 Pokemon GO
• 想理解 control plane vs data plane → 9.5 瓶頸定位流程 + 05 部署平台模組
• 想規劃 surge 後的 SLO → 9.12 SLO 與 Performance Budget + 04.16 SLI / SLO 訊號
• 想評估 surge 下的 on-demand vs provisioned 切換 → DynamoDB on-demand vs provisioned
• 想避免 surge 觸發 hot partition → DynamoDB partition key 反模式

引用源

• Amazon DynamoDB Customers
• Zoom Video Communications on AWS

觀察

Capcom 在 AWS 的關鍵敘述（引自 Capcom Case Study 與 DynamoDB Customers）：

關鍵敘述：「Capcom uses Amazon DynamoDB to meet this demand with single-digit millisecond response times」。

判讀

Capcom 案例揭露三個遊戲後端 KV 的工程重點。

1. 遊戲後端 KV = 跨遊戲共用基礎設施：Resident Evil / Street Fighter / Monster Hunter 是不同類型遊戲（單機+多人 / 對戰 / 合作打怪）、卻共用 同一套後端 KV。這個共用降低了單一遊戲的維運成本、也讓新遊戲上線時不用重做基礎設施。對應 05 部署平台模組 的 multi-tenant platform。
2. single-digit ms response time = 玩家體感「即時」的底線：戰鬥動作、技能釋放、玩家對戰都要次秒級反應、超過 10ms 就「卡」。這個延遲門檻反推 Capcom 必須用 sub-region cache（ElastiCache / 本地 game server）+ DynamoDB DAX、不能單靠 DynamoDB。對應 9.C3 Coinbase 的延遲反推。
3. 「工程資源從 DB 運維轉到遊戲品質」是 managed 服務的真實價值：Capcom 不是 IT 公司、是遊戲公司。把 DBA 時間從「Postgres patching、replication 設定、backup 排程」釋放到「遊戲機制設計、玩家行為分析」、才是 30% 成本下降的本質。對應 9.7 成本邊界與 efficiency 的人力成本工程化。

需要警惕：「billions of requests」沒指明時間單位（每秒、每天、每月）。讀案例時要找具體單位、不要直接套用到自家。

策略

可重用的工程做法：

1. 遊戲後端 KV 用 DynamoDB / Cosmos DB / Bigtable：partition key 用 player_id 天然均勻、不會 hot partition。對應 01 資料庫模組 的 schema 設計。
2. EKS 跑 game server、不直接連 DynamoDB：game server 處理遊戲邏輯（戰鬥、配對、防作弊）、DynamoDB 處理持久狀態。中間用 DAX 或 ElastiCache 減少 DynamoDB 呼叫。對應 9.5 瓶頸定位流程。
3. 多 IP / 多遊戲共用平台是降本核心：每個新遊戲不重做基礎設施、共用同一套 DynamoDB + EKS。跟 9.C12 Riot Games 的「single-tenant per game」對照 — 不同 IP 公司有不同取捨。

跨平台等效：GCP Bigtable + GKE + Memorystore、Azure Cosmos DB + AKS + Cache for Redis 都可實作對等架構。

下一步路由

• 對照其他遊戲後端 → 9.C12 Riot Games EKS（cluster 隔離 vs 共用）
• 想設計遊戲 KV → 01 資料庫模組 + 9.C5 Amazon Ads
• 想理解 sub-ms latency 反推 → 9.C3 Coinbase + 9.12 SLO 與 Performance Budget
• 想規劃遊戲 KV access pattern 與 single-table design → DynamoDB single-table design
• 想評估遊戲流量的 on-demand vs provisioned → DynamoDB on-demand vs provisioned

引用源

• CAPCOM Case Study
• Amazon DynamoDB Customers
• Powering Gaming Applications with Amazon DynamoDB

定位

Akamas 適合已經有可量測 workload 與成本壓力的服務。當團隊能說清楚 request rate、latency SLO、error budget、CPU / memory headroom、replica policy 與雲端費用目標，Akamas 可以把這些條件轉成 optimization objective，找出更好的配置組合。

這個定位讓 Akamas 接到三個主章。它從 9.6 容量規劃模型 接收 headroom 與 growth curve，從 9.7 成本邊界與 efficiency 接收 cost per request 與 cost curve，從 9.9 Performance Improvement Loop 接收 test、profile、fix、re-test 的閉環。

服務定位

Akamas 的核心定位是 AI-driven autonomous optimization、不是 monitoring、不是 cost reporting、也不是手動 rightsizing 工具。它用 ML 在 parameter space 中找出可同時降 cost 並達到 SLO 的配置組合、目標是把 效能調校 從 expert-driven 手工活、轉成可重跑的工程實驗。

跟 Vantage / CloudHealth 這類 FinOps cost tool 的差異是 動作面。FinOps tool 看到 cost 已經發生、把帳單拆 tag、推薦保留方案；Akamas 看 workload 在 SLO 邊界下能不能跑得更便宜、輸出的是 configuration change、不是 invoice 切片。

跟 Datadog APM / Prometheus 這類 observability stack 的差異是 決策面。APM 告訴你 哪裡慢、哪個 endpoint p99 飆；Akamas 接 APM / metrics 訊號當輸入、輸出 該怎麼改 JVM heap、HPA target、connection pool 的 recommendation。Observability 是 看、Akamas 是 動。

跟手動 tuning（SRE 拍腦袋、grid search、A/B configuration test）的差異是 參數空間規模。Manual tuning 在 3-5 個參數還可控；JVM + container limit + HPA + DB pool + node packing 同時轉動時、組合爆炸、ML-driven search 才能在合理 budget 內收斂。

最短判讀路徑

判斷 Akamas optimization study 是否健康、最少看四件事：

• Agent / collector 部署完整度：哪些 target（JVM / container / K8s / DB）裝了 Akamas agent 或接到 metrics source、metrics window 是否涵蓋 representative peak、是否漏 tail latency 與 GC pause
• Target system 邊界定義：optimization 是針對單一 service / 一組 microservice / 整個 K8s cluster、tunable parameter list 是否經 service owner 審核、不在 list 內的參數是否會被間接影響
• Optimization goal 對得上 business outcome：goal 是「降 cost 30%」還是「同 SLO 下 cost minimize」、是否同時聲明 latency / error budget / throughput 的下界、避免 ML 為達 cost target 把 latency 推到邊緣
• Safety bound 緊 / 鬆的取捨：bound 太緊收斂不到方案、bound 太鬆 production validation 會出事、是否有 staging tenant 跑完再 promote、autopilot 範圍是否限定 non-critical workload

四項任一缺、就是 9.9 Performance Improvement Loop 邊界的待補項目、不是 Akamas 設定問題。

適用場景

Kubernetes rightsizing 是 Akamas 的主要入口。多服務平台常見問題是 requests / limits、HPA target、replica floor、node pool 與 runtime 參數互相牽動；Akamas 的價值是把這些參數放進同一個優化空間，而非逐項手動調整。

Runtime 與 database tuning 適合需要穩定 SLO 的服務。JVM heap、Go runtime、PostgreSQL、MongoDB、Elasticsearch 或 Spark workload 會同時受配置、資料形狀與流量尖峰影響；optimization tool 可以用可重跑實驗保留調校證據。

FinOps 與 SRE 協作適合用 Akamas 建立共同語言。FinOps 關心浪費與預算，SRE 關心 latency、error rate 與可靠性；Akamas 類工具把節省幅度、性能風險與回退條件放在同一份 recommendation 裡，降低跨團隊溝通成本。

選型判準

優化目標價值來自約束透明。成本降低只有在 latency、availability 與 error budget 邊界內才成立，因此 Akamas 頁面要先問目標函數與 guardrail，再談節省幅度。

參數空間價值來自跨層調校。單看 CPU request 可能會誤判，因為 GC、DB connection、thread pool、replica policy 與 node packing 會一起改變 cost per request。

執行模式價值來自可控自動化。Human-in-the-loop 適合早期導入，pipeline mode 適合 release gate，autopilot 適合 guardrail、rollback 與 owner model 已成熟的環境。

跟其他工具的取捨

Akamas 和 Vantage 的主要差異是控制面。Vantage 偏 cost visibility、allocation、forecast 與報表；Akamas 偏把效能約束放進 configuration optimization，適合需要直接調整 capacity 與 runtime 參數的場景。

Akamas 和 CloudHealth 的主要差異是操作層級。CloudHealth 偏 enterprise FinOps governance、policy、showback / chargeback 與多雲管理；Akamas 偏 service-level optimization 與工程調校閉環。

Akamas 和 AWS Cost Explorer 的主要差異是範圍與自動化。Cost Explorer 是 AWS-native 成本分析入口；Akamas 可以把成本訊號跟 workload、SLO 與配置實驗接起來，適合需要跨層優化的服務。

操作成本

Akamas 的主要成本是 optimization model 建立。團隊要定義目標、約束、可調參數、測試窗口、流量代表性與成功門檻，並讓 service owner 審核每個 recommendation 的業務風險。

導入成本會隨自動化程度上升。早期可以用 approval workflow 接 recommendation；進入 pipeline 或 autopilot 後，要補 change window、deploy marker、rollback、SLO guardrail、audit log 與 incident handoff。

資料品質會直接影響結果可信度。Metric 延遲、缺少 tail latency、成本 tag 錯誤、workload window 偏差或測試環境差異，都會讓 recommendation 的 confidence 下降。

Evidence Package

Akamas 結果應回寫到 optimization evidence package。最小欄位包括 optimization goal、constraint、tunable parameters、workload window、baseline cost、baseline performance、recommended configuration、expected saving、risk note、validation result 與 owner。

Evidence package 的核心用途是讓成本調校可以被審查。Akamas recommendation 要能回答「節省來自哪個配置變更、哪個 SLO 保護這次變更、哪個訊號觸發回退」。

核心取捨表

選 Akamas 的核心訴求是 參數空間大 + workload 可重跑 + cost 壓力夠高、值得投入 optimization study setup 成本。小規模 / 參數少 / SLO 不明、直接走 manual tuning 更快；只想看帳單拆解、走 FinOps tool；只想知道哪裡慢、走 APM。

進階主題

Optimization study 的三要素：goal（目標函數、常見 minimize cost subject to p99 latency < X, error rate < Y）、parameter list（哪些 knob 可動、各自合法區間）、safety bound（哪些 metric 不能越界、越界即 reject candidate）。study setup 是 Akamas 最重的人力投入、value 來自 把隱性調校 know-how 寫成可重跑配置、不是 ML 本身。

Live experiment vs offline study：offline study 用 staging 環境跑代表性 workload、安全但與 production 流量結構有偏差；live experiment 在 production 上小範圍試 candidate（例如 single canary pod）、訊號真實但需要嚴格 safety bound 與 rollback。多數團隊先 offline 找候選 region、再 live 收斂 — 不要一開始就 production autopilot。

跟 K8s VPA / HPA 互補不互斥：HPA 處理 replica 數量、VPA 處理 單 pod request / limit、Akamas 處理 參數組合 + 跨層協同（含 JVM heap、HPA target、replica floor、node pool selection）。三者並用時要明確分工 — Akamas 不該跟 VPA 同時調 request，否則彼此推翻；常見作法是 Akamas 設 baseline configuration、VPA / HPA 在 baseline 上做即時微調。

跟 observability stack integration：Akamas 接 Datadog / Prometheus / New Relic / Dynatrace 取 metrics、接 Kubernetes API 取 workload state、接 cloud billing API 取 cost。integration 品質直接決定 recommendation 信度 — metric 缺 tail latency 或 cost tag 不準、ML 會找到 看起來省、實際出事 的配置。對應 9.4 Performance Observability 的訊號治理。

安全邊界 — 不該全 autopilot production：critical workload（payment / auth / DB primary）即使 SLO bound 寫清楚也不該 autopilot、recommendation 要走 human approval + change window；non-critical workload（batch job / dev cluster / internal tool）autopilot 可接受。ML black-box 是 production safety 的本質風險、不是設定問題。

ML 黑箱可解釋性：Akamas recommendation 給出 why this configuration 的 sensitivity analysis（哪個參數影響最大、哪個參數對 cost / latency 是 trade-off curve），但根因解釋仍弱於人類性能工程師的 mental model。Production 採用前、service owner 要能用自己的 domain knowledge 對 recommendation 做 sanity check、不是純靠 ML score 拍板。

排錯與失敗快速判讀

• Optimization goal 對不上 business outcome：goal 寫「降 cost 30%」但沒寫 latency / error budget 下界 — ML 把 cost 壓到 SLO 邊緣、production 上線就 incident、回頭補 safety bound + business KPI alignment
• Safety bound 太鬆 / 太緊：太鬆 candidate 過 staging 但 production validation 出事、太緊 study 跑不出有意義方案 — bound 應綁 production-observed p99 / error rate baseline + 20% 緩衝、不是拍數字
• ML black-box 沒辦法解釋：service owner 看不懂為何 recommendation 改某個 obscure JVM flag — 跑 sensitivity analysis、不接受 無 domain rationale 的 recommendation、視為 candidate 而非 final
• 參數空間 leak 到 list 外：Akamas 改 JVM heap 但間接讓 GC 行為變、撞到沒納入的 thread pool — 補 cross-parameter dependency 到 list、或縮小 study scope
• Workload window 不代表 production：staging 跑 50% 流量、ML 找到的方案在 100% peak hour 出事 — workload sample 必須涵蓋 representative peak、不是平均值
• Autopilot 推到 critical service：non-critical workload 試出甜頭、團隊把 autopilot 推到 payment service、incident 後 rollback 困難 — autopilot 範圍要寫進政策、critical service 永遠 human approval
• Recommendation 跟 VPA 互推：Akamas 設 request = X、VPA 立刻調回 Y、循環 — Akamas baseline 跟 VPA scope 要分層、不要在同一個 dimension 兩個 controller 同時動

案例回寫

Akamas 目前在 09 案例庫中適合作為 9.7 成本邊界與 efficiency 的工具承接點。它可回寫到 9.C20 Zomato TiDB → DynamoDB 遷移 的成本下降 50% 取捨、9.C12 Riot Games 246 EKS cluster 的年省 1000 萬美金的 Kubernetes capacity 調校、9.C19 Capcom 遊戲後端 的營運成本下降 30%、以及 9.C2 GR8 Tech 體育博彩 的需求降低時成本下降 25% 彈性曲線。

這些案例的重點是優化條件。Akamas 頁引用案例時，應把「某公司節省成本」轉成 workload window、SLO constraint、調整參數、驗證方式與回退條件 — 例如 Zomato 的 4x throughput / 90% latency 改善是同時優化目標、不是只看成本欄位。

下一步路由

• 上游：9.6 容量規劃模型
• 上游：9.7 成本邊界與 efficiency
• 上游：9.9 Performance Improvement Loop
• 平行：Vantage
• 官方：Akamas documentation

定位

GoReplay 適合在 synthetic workload 可信度偏低時使用。當 9.2 Workload Modeling 很難準確描述使用者路徑、payload 分布或 endpoint mix，GoReplay 可以從 production traffic 擷取真實樣本，再用 rate limit、filter、rewrite 與 output target 控制重播範圍。

這個定位讓 GoReplay 接到 9.10 Production-Side 驗證 的 shadow traffic。它的價值在於保留 production 請求形狀；它的風險在於 PII、credential、side effect、下游容量與 capture host overhead 都要被治理。

跟 k6 / JMeter 的 synthetic load 設計 mindset 完全不同。Scripted load 假設 測試者能描述使用者行為 — 寫 script、設 rate、跑 scenario；GoReplay 假設 production 才是 source of truth — endpoint mix、header 分布、payload size、burst pattern 都從真實 traffic 抽樣、不靠人為建模。對 long-tail 行為（少見 endpoint、巨大 payload、特殊 header 組合）這個差異決定了 capacity 規劃的真實度。

最短判讀路徑

判斷 GoReplay deployment 是否健康、最少看四件事：

• Capture mode：用 raw (libpcap-based)、pcap-file（離線 replay 已存檔的 pcap）、file（GoReplay 原生 gor format）哪一種？raw 對 production host 有 CPU / network overhead、pcap-file 適合事後 replay、file 適合 long-running capture buffer
• Replay target：打到 staging full-stack、shadow service、還是 isolated sandbox？POST / PUT / DELETE 是否導到 dry-run path 或 idempotent mock？webhook / payment / notification 是否被攔截？
• Rate adjustment：用原始 production rate replay，還是 2x / 10x / 0.1x？capacity 規劃通常需要 speed up 來測未來流量、debug 通常需要 slow down 跟單一請求追查
• Middleware filter：PII / token / cookie / credential redaction 在哪一段做（capture 前、capture 後、replay 前）？是否走 GoReplay middleware binary（stdin / stdout pipeline）統一處理

適用場景

架構遷移驗證適合 GoReplay。DB、cache、search、API gateway 或 framework 重寫時，可以把真實 HTTP traffic replay 到新路徑，觀察 latency、error、resource saturation 與 response diff。

Long-tail workload 校正適合 GoReplay。Synthetic scenario 通常覆蓋主路徑，GoReplay 可以揭露少見 endpoint、特殊 header、巨大 payload、冷門 tenant 與尖峰 cohort。

事故後修補驗證適合 GoReplay。若事故由特定請求形狀觸發，capture sample 可以在修補環境重播，確認 latency、error 或 resource usage 是否回到可接受範圍。

選型判準

真實 traffic 價值來自分布保真。它能捕捉 synthetic script 容易漏掉的 query parameter、header、payload size 與 endpoint mix，但 capture sample 也會帶入 production 資料治理責任。

Filter / rewrite 價值來自安全邊界。Replay 前要改寫 target、移除 credential、遮罩 PII、限制 rate，並把寫入類請求導到 sandbox 或 dry-run path。

跟其他方式的取捨

GoReplay 和 k6 / Gatling / Locust 的主要差異是流量來源。GoReplay 取 production sample，保真度高；scripted load test 取人工模型，可控性高。

GoReplay 和 service mesh mirroring 的主要差異是部署位置。GoReplay 在 host / network capture 層工作，適合沒有 mesh 的服務；service mesh mirroring 在 sidecar / proxy 層工作，適合已經落地 mesh 的平台。

GoReplay 和 AWS VPC Traffic Mirroring 的主要差異是應用語意。GoReplay 對 HTTP replay 更直接；VPC Traffic Mirroring 在網路層複製封包，侵入性低但應用層 rewrite、遮罩與 replay 控制需要額外處理。

核心取捨表

選 GoReplay 的核心訴求：HTTP 應用層 replay + production shape 保真 + 沒落地 mesh；若已用 mesh、優先看 mesh 內建 mirroring；若要跨 protocol（gRPC / 自家 binary）GoReplay 開源版受限、需考慮 Pro 版或 mesh 方案。

操作成本

GoReplay 的主要成本是資料安全。Production request 可能包含 token、cookie、PII、payment payload、internal IDs 與 tenant 資料，capture、保存、重播與刪除都要有明確 owner。

Replay 成本來自下游副作用。POST、PUT、DELETE、webhook、email、payment、notification 與 queue publish 都要導到 sandbox、mock 或 idempotent dry-run，避免 replay 造成重複交易或通知。

Capture 成本來自主機資源。高流量服務上的 capture agent 會消耗 CPU、network 與 disk，正式啟用前要先量測 overhead，並設定 sampling、rate limit 與 stop condition。

Evidence Package

GoReplay 結果應回寫到 evidence package。最小欄位包括 capture source、capture time range、filter / rewrite rule、sample size、replay rate、target environment、data masking status、p95 / p99、error rate、resource saturation、known gap 與 owner。

Evidence package 的核心用途是讓 replay 結論可審查。Reviewer 要能知道樣本來自哪段 production、經過哪些 filter、打到哪個 target，以及哪些 side effect 被 mock 或隔離。

進階主題

Capture to file（pcap-like artifact）：用 --output-file 把 capture 寫成 GoReplay 原生 gor file（或讀 pcap）、之後用 --input-file 重複 replay。這個模式讓 capture window 跟 replay run 解耦 — capture 一次，可在不同 staging branch / 不同 rate / 不同 target 重播多次。對 regression 驗證跟「事故當時的 traffic shape」回放特別關鍵、但 file artifact 也成為 PII 儲存物、retention 跟存取控制要跟 production log 同級。

Replay with rate adjustment（10x speed）：--input-file-replay-speed 10（gor format）或加 --input-file-loop 反覆播放。10x speed 對 capacity headroom 驗證直接有用 — 用真實 traffic shape 模擬「未來流量翻 10 倍」、避開 scripted scenario 自帶的人為偏差。反向用法 0.1x 跟 isolated request replay 適合排錯特定 endpoint 的 long-tail latency。注意 10x 會把下游 DB / cache / external API 同樣放大，sandbox target 容量要先評估。

Middleware filter（PII redaction）：GoReplay middleware 是獨立 binary、用 stdin / stdout 跟 GoReplay process 串接、可寫任何語言。典型責任：JSON body 解析、Authorization / Cookie / Set-Cookie header strip、Email / phone / card number regex 遮罩、cross-request session ID rewriting（讓 staging 不撞 production session）。middleware 邏輯本身需要 code review、寫進版控、staging 測過再放到 production capture host。

Pro version（GoReplay Pro - binary protocols）：開源版聚焦 HTTP/1.x；GoReplay Pro 支援 binary protocol（自家 protocol、protobuf-over-TCP、部分 gRPC pattern）跟 enterprise 維護 SLA。判斷點：若服務是純 HTTP REST 開源版夠用、若有 gRPC 或自家 binary 且不在 mesh 內、要評估 Pro 或改走 service mesh mirroring。

排錯與失敗快速判讀

• Capture loss / sample 不完整：libpcap 在高流量下會 drop packet、gor stat 的 capture stats 顯示 drop > 1% 就不可信 — 加 capture host CPU、改用 PF_RING / AF_PACKET、或縮 capture filter 範圍（只 capture target port + sampling）
• TCP reassembly 失敗 / replay 結果亂碼：跨 packet 的 HTTP body 沒被正確組裝、常見於 MTU / TCP segment offload 設定異常 — 確認 capture interface 沒開 TSO / GRO、或用 application-level capture（HEC-style sidecar）取代 packet capture
• PII / secret 漏 redact 進 staging：middleware 規則沒覆蓋新加的 header / 新的 body schema — 建立 redaction allowlist（只放行已知 schema）而非 denylist、每次 schema 變更同步更新 middleware、staging 入口加 secret scanner 做 last-mile 攔截
• Replay 觸發下游真實副作用：POST / PUT 沒導 sandbox、webhook 真的打出去、payment 真的扣款 — replay target 預設 deny all write、白名單放行特定 idempotent endpoint、其餘走 mock 或 dry-run flag
• Replay rate 拖垮 capture host：同機 capture + replay、CPU / NIC 互相搶 — capture host 只負責 sniff + write to file、replay 機器獨立、用 gor file 解耦
• 長時間 capture 寫爆 disk：未設 rotation 或 size limit — --output-file 加 size / time rotation、定期 archive 到 S3 + 過期刪除
• Staging 容量比 production 小、放大流量打爆：10x replay 沒先估下游 — capacity 規劃前先用 1x 暖機、觀察下游 saturation、再 ramp 到目標倍率

案例回寫

GoReplay 適合回寫 migration 與 production validation 案例。它可接 9.C15 Tixcraft 售票壓測 的 production-shaped load、9.C16 SeatGeek waiting room 的 cutover 前 replay、9.C23 Netflix Aurora consolidation 這類資料庫整併前的 query pattern 驗證、9.C20 Zomato TiDB → DynamoDB 跨 DB 遷移的請求 pattern 重播，以及 9.C30 Microsoft 365 MongoDB → Cosmos DB 的全球分析平台遷移 query 驗證。

這些案例的重點是 production request shape。GoReplay 頁引用案例時，要把 case 轉成 capture window、filter、rewrite、target isolation、rate limit 與 diff / saturation metric — 例如 Zomato 遷 DB 時、replay 必須先 mask PII + 改寫 SQL 方言、不能直接把 TiDB query 打進 DynamoDB SDK。

Capacity 規劃用 real workload model 是這些案例的共通對照啟示。Tixcraft 的售票 spike、SeatGeek 的 waiting room cutover、Netflix 的 Aurora 整併、Microsoft 365 的全球 query 分布 — 共通點是 scripted scenario 無法事先列舉所有 endpoint 跟 payload 組合。GoReplay 的回應是把「使用者行為建模」這個工作丟回給 production traffic 本身、規劃者只負責決定 capture window、replay rate 跟 target boundary，不再試圖窮舉 scenario。這個 mindset 才是 GoReplay 跟 k6 / JMeter 在 capacity 規劃流程中的真正分工點。

下一步路由

• 上游：9.2 Workload Modeling
• 上游：9.10 Production-Side 驗證
• 平行：Service Mesh Mirroring
• 平行：AWS VPC Traffic Mirroring
• 知識卡：Shadow Traffic
• 官方：GoReplay documentation

觀察

Zomato 帳單系統遷移的關鍵數字（引自 AWS Database Blog）：

關鍵動機：TiDB 必須為「突發流量峰值」提前 over-provision、付出常態成本；DynamoDB on-demand 模式「pay only for what we use」、避免 over-provisioning。

判讀

Zomato 遷移揭露三個 DB 選型決策的判讀重點。

1. NewSQL vs NoSQL 的取捨不只是 schema：TiDB 提供 SQL 介面跟 ACID、DynamoDB 提供 KV 介面跟最終一致性。Zomato 選 DynamoDB 是判斷「帳單事件本身可以接受 eventually consistent」、用一致性換性能跟成本。對應 01.5 transaction boundary 的一致性取捨。
2. TiDB 必須 over-provision 是分散式 SQL 的常態：分散式 SQL 為了支援跨節點交易、必須有預留容量、否則峰值會出現 leader election storm 或 follower lag。這跟 9.C10 Spanner 的「節點數即容量」是同類取捨、Spanner 也必須預先 scale 節點。
3. 2K → 8K RPM 是 4 倍、但延遲降 90% 才是真關鍵：吞吐改善可能來自架構優化、延遲改善才是 DB 本質差。從 baseline → 10% 通常代表少了 1-2 個 hop（例如 cross-region replication、coordinator round-trip）。對應 9.1 壓測理論與系統行為 的 Little’s Law。

需要警惕：

• 「成本降 50%」是 當下流量下的對照。如果未來流量繼續成長、DynamoDB 的 cost-per-request 成長率比 TiDB 自管 cluster 高 — 達到某規模後 TiDB 反而更便宜。讀遷移案例要看「在當下流量下划算」、不等於「永遠划算」。
• 「90% 延遲降」可能只是 p50、p99 / p999 改善幅度通常較小。

策略

可重用的工程做法：

1. DB 遷移前先確認業務一致性需求：能接受 eventually consistent 的工作負載適合 KV / NoSQL；必須 strong consistency 的工作負載必須 SQL / NewSQL。對應 01.5 transaction boundary。
2. 遷移評估要看「總成本曲線」、不是「當下 snapshot」：算未來 12-24 個月在預期流量下的成本對照、不是只算現在。對應 9.7 成本邊界與 efficiency。
3. 遷移過程要 dual-write + shadow read 驗證：避免新舊系統行為不一致導致業務問題。對應 01.3 schema migration rollout evidence。
4. on-demand vs provisioned 的選擇與業務流量形狀對應：突發流量適合 on-demand、可預測流量適合 provisioned。對應 9.C15 Tixcraft 的 on-demand 應用。

跨平台等效：MongoDB Atlas → DynamoDB、Cassandra → DynamoDB、PostgreSQL → Aurora、CockroachDB → Spanner 都是常見遷移路徑。每條路徑的取捨類似。

下一步路由

• 想做 DB 遷移評估 → 01 資料庫模組 + 01.4 database migration playbook
• 想理解一致性取捨 → 01.5 transaction boundary + 9.C10 Spanner
• 想做總成本評估 → 9.7 成本邊界與 efficiency
• 對照其他 DB 遷移 → 9.C9 Spotify Kafka→Pub/Sub
• 想拆 access pattern 對應的 DynamoDB schema → DynamoDB single-table design + DynamoDB partition key 反模式
• 想評估搬遷後的 capacity mode → DynamoDB on-demand vs provisioned

引用源

• Unlocking performance, scalability, and cost-efficiency of Zomato’s Billing Platform by switching from TiDB to DynamoDB
• How Zomato Boosted Performance 25% and Cut Compute Cost 30% Migrating Trino and Druid Workloads to AWS Graviton

跟 GoReplay 比、Service Mesh Mirroring 在 proxy / sidecar 層、是 K8s mesh-native 的 L7 HTTP request mirror、不需要 application 或 host 端 capture binary；GoReplay 在 application host 層、適合無 mesh 的環境或要 capture artifact 離線 replay。跟 AWS VPC Traffic Mirroring 比、Service Mesh Mirroring 在 L7（HTTP route / header / subset 可控）、VPC Traffic Mirroring 在 L3-L4 packet 層、見度更底層但缺 application 語意。三者組合常見於 K8s + 多 cloud 混合環境。

最短判讀路徑

判斷 Service Mesh Mirroring 部署是否健康、最少看四件事：

• Mesh implementation 對齊：用哪套 mesh（Istio / Linkerd / Envoy gateway / Consul Connect）、control plane 版本、sidecar injection coverage、跨 namespace policy 邊界是否清楚
• VirtualService mirror config：mirror destination 是否限制在同 namespace / 同 cluster、mirror_percent 是否從 1% 漸進、route / header filter 是否排除 write-heavy 或 PII path
• Target service capacity：shadow target deployment 是否有獨立 HPA、跟 primary 同 node pool 還是隔離、DB / cache / external API 是否導 mock 或 sandbox、不會 share connection pool 造成 primary 飽和
• Response handling：mirrored response 是 fire-and-forget（Istio 預設）還是有 logging、shadow 端是否能辨識 mirrored request（X-Envoy-Internal / custom header）、side effect（payment / notification / webhook）是否走 dry-run

四件事任一缺失、就是 9.10 Production-Side 驗證 shadow traffic 治理的待補項目。

定位

Service mesh mirroring 適合平台已經有 proxy control plane 的團隊。當 service-to-service traffic 都經過 sidecar 或 gateway，mirror policy 可以把部分 production request 複製到新版本，不需要在 application code 中加 capture / replay 邏輯。

這個定位讓 service mesh mirroring 接到 9.10 Production-Side 驗證 的 shadow traffic 與 canary perf check。它比 host capture 更貼近 service routing，但也依賴 mesh 的觀測、policy、資源隔離與治理能力。

適用場景

新版本 shadow validation 適合 service mesh mirroring。平台可以把 1%、5% 或特定 route 的流量 mirror 到 shadow deployment，觀察新版本 CPU、memory、latency、DB read 與 error。

Service-to-service migration 適合 service mesh mirroring。當下游服務準備換 runtime、framework、DB client 或 cache client，mirror 可以讓新路徑吃到 production upstream pattern。

多 region / 多 version 對照適合 service mesh mirroring。Mesh policy 能按 namespace、host、route、header 或 subset 控制 mirror target，讓平台在小 blast radius 下收集 production-shaped evidence。

選型判準

Proxy 層控制價值來自一致性。當所有 service 都走 mesh，mirror policy 可以用同一套控制面管理，避免每個 application 自行實作 replay。

Mesh observability 價值來自對照能力。Shadow service 的 latency、error、resource saturation 與 dependency call 可以直接跟 primary path 對比，但 dashboard 要清楚標記 mirrored traffic，避免混入正式 SLO。

跟其他方式的取捨

Service mesh mirroring 和 GoReplay 的主要差異是控制面。Service mesh mirroring 依賴既有 proxy / mesh，適合服務間流量；GoReplay 適合 HTTP capture artifact、離線 replay 與沒有 mesh 的環境。

Service mesh mirroring 和 AWS VPC Traffic Mirroring 的主要差異是語意層級。Mesh 在 L7 routing 層，能按 route、host、header 與 subset 控制；VPC mirroring 在網路層，能見度更底層但應用語意控制較少。

Service mesh mirroring 和 canary 的主要差異是使用者影響。Mirrored request 的回應不回給使用者，適合 capacity / correctness observation；canary 會讓真實使用者走新版本，適合最終放量。

操作成本

Service mesh mirroring 的主要成本是下游容量。Shadow traffic 雖然不回應使用者，但仍會消耗 shadow service、DB、cache、third-party mock、queue 與 observability pipeline 的資源。

Policy 成本來自控制面治理。Mirror rule、route、subset、namespace、owner 與 rollout window 都要可審查；錯誤的 mirror policy 可能把過大比例流量導到未準備好的 target。

Side effect 成本來自 application 行為。Shadow service 要能辨識 mirrored request，並把 write、external API call、notification、payment 與 queue publish 導到 sandbox、mock 或 dry-run。

Evidence Package

Service mesh mirroring 結果應回寫到 evidence package。最小欄位包括 mesh policy version、source service、route、mirror ratio、target subset、time range、shadow target resource、data / side effect isolation、p95 / p99、error rate、dependency saturation、known gap 與 owner。

Evidence package 的核心用途是讓 mirror 實驗可關閉。Reviewer 要能看到 mirror policy 何時啟動、何時停止、覆蓋哪些 route、消耗哪些下游資源，以及 shadow target 是否接近 production。

進階主題

Istio VirtualService mirror / mirror_percent：Istio 用 VirtualService 的 mirror 欄位指定 shadow destination、mirrorPercentage（v1.7+；舊版 mirror_percent）控制比例。production 操作慣例是從 1% 起步、每 30-60min 觀察 shadow target latency / error / saturation 再放大、達到 100% 後維持一週收 evidence 才 promote。route-level config 比 mesh-wide policy 安全、blast radius 限定在指定 host / path。

Linkerd traffic split：Linkerd 用 SMI TrafficSplit CRD 或 native HTTPRoute 分流、走 active-active shadow 模式而非 fire-and-forget。Linkerd mirror 預設較輕量、proxy overhead 比 Istio 低、適合資源敏感的 K8s cluster；但 L7 policy 表達力不如 Istio EnvoyFilter。

Envoy MirrorPolicy：直接寫 Envoy config（不透過 Istio control plane）時、route.RouteAction.request_mirror_policies 是底層 primitive。多 cluster 邊緣 gateway（Contour / Emissary-Ingress / Gloo）都是這層的 abstraction、適合不想引入 full Istio 但要 mirror 能力的場景。

跟 Argo Rollouts canary 整合 — shadow deployment：Argo Rollouts 的 analysis step 可以接 mesh mirror — shadow stage 先用 mirror 收 evidence、canary stage 才放真實流量。對應 9.10 Production-Side 驗證 的「shadow 先於 canary」原則、避免把使用者當小白鼠。

跟 Datadog APM trace correlation：mirrored request 應該有獨立的 trace tag（env:shadow 或 traffic.mirror:true）、讓 Datadog APM / observability stack 能 filter 出 shadow path 的 p95 / error rate、不混入 primary SLO dashboard。trace propagation header 要保留、否則 distributed trace 斷在 mesh 邊界。

排錯與失敗快速判讀

• Mirror target capacity 不足 / shadow service OOM：shadow deployment 沒獨立 HPA、跟 primary 共用 node pool — 拆 node pool、shadow 設獨立 resource request、mirror_percent 從 1% 起步
• Mirrored response 漏處理（fire-and-forget 副作用）：Istio 預設丟棄 mirrored response、shadow 端的 error 沒被 collect — shadow service 自己 emit metric / log、不依賴 mirror response、加 X-Shadow-Request header 讓 shadow 端可辨識並走 dry-run 路徑
• PII / sensitive data 進 staging：mirrored request 帶真實 user token / payment info 打到 staging — header / body filter 走 EnvoyFilter 做 PII redaction、或在 mesh 邊界跑 data masking proxy 再 mirror
• Side effect 真的發生（payment double charge / notification 真寄）：shadow service 沒辨識 mirrored request 就走正式邏輯 — 強制 shadow 端用 sandbox credential、external API client 走 mock / dry-run mode、write 改 read-only replica
• Mesh control plane 飽和 / mirror policy drift：mirror rule 散落各 namespace 沒 owner、policy version 不一致 — 走 GitOps（Argo CD / Flux）+ policy as code、定期 audit kubectl get virtualservice -A
• Cross-cluster mirror blast radius 失控：mirror destination 指向其他 cluster 導致跨 cluster 流量爆增 — mirror destination 限 same-cluster、跨 cluster 要走獨立的 gateway 並設 quota
• Shadow trace 混進 SLO dashboard：APM 沒分 primary / shadow tag、p95 看起來變差但其實是 shadow 拖累 — trace tag env:shadow 強制、observability dashboard filter

何時改走其他服務

不在本頁內的主題

• Istio / Linkerd / Envoy 完整 install / 升級 / control plane HA 細節
• Service mesh 安全模型（mTLS / SPIFFE / authorization policy）— 屬 7 security 邊界
• Mesh-level retry / timeout / circuit breaker 等 resilience pattern
• Multi-cluster mesh federation（Istio multi-primary、Linkerd multicluster）

案例回寫

Service mesh mirroring 適合回寫平台遷移與新版本 shadow validation 案例。它可接 Miro managed EKS migration、Tradeshift self-managed K8s to EKS、9.C28 FanDuel 雙峰 workload 的逐步驗證需求、9.C12 Riot Games 246 EKS cluster 的 single-tenant per game 跨 cluster 流量 shadow，以及 9.C7 Lyft 100+ 微服務 跨服務的 mirror 範圍治理。

這些案例的重點是 routing policy 與 blast radius。Service mesh mirroring 頁引用案例時，要把 case 轉成 route、mirror ratio、target subset、dependency isolation 與 abort condition — 例如 Riot Games 的 single-tenant 模式下、mirror policy 必須限制在 同遊戲 cluster 內、不能跨 game 否則 blast radius 失控。

下一步路由

• 上游：9.10 Production-Side 驗證
• 上游：5.6 Traffic, Config and Control Plane Boundary
• 平行：GoReplay
• 平行：AWS VPC Traffic Mirroring
• 知識卡：Shadow Traffic

它適合多 account、多 provider、Kubernetes 與 shared infrastructure 成本需要分攤到 service、team、namespace、label 或 resource 的組織。

服務定位

Vantage 的差異在 使用者體驗與切入角度、指標本身跟同類工具相近。CloudHealth / Apptio 是傳統 enterprise FinOps platform、面向 procurement、CFO、FinOps governance team；Vantage 把入口換成工程團隊 — 報表能直接 share URL、UI 接近 observability dashboard、connector 走 self-service onboarding 而非 SOW + professional service。

跟 CloudHealth 比、Vantage 淺但快上手、適合 100 - 1000 人工程組織自助 FinOps；CloudHealth 走 enterprise governance、policy engine、approval workflow 更深、適合 5000+ 員工跨 BU 治理。跟 Apptio Cloudability 比、定位類似 CloudHealth、但 Apptio 把成本接到 TBM（Technology Business Management）frame、適合需要把 IT 成本對到 business service / product P&L 的組織。跟 AWS Cost Explorer 比、Cost Explorer 是 AWS-only 入口、免費但只有 AWS、跨 provider / Kubernetes / SaaS spend 看不到；Vantage 把 AWS + GCP + Azure + Snowflake + Databricks + Datadog + Fastly 等串成單一視圖。

關鍵張力：modern SaaS 速度 ↔ enterprise governance 深度 是 Vantage 的核心定位 trade-off。要 procurement-grade workflow、approval chain、custom data warehouse export 走 CloudHealth / Apptio；要工程 owner 直接打開 dashboard 看 cost trend、5 分鐘加新 connector 走 Vantage。

定位

Vantage 適合把 cost attribution 帶進容量規劃流程。當團隊已經能用 workload model 描述流量，下一步要知道每個 workload、namespace、database、cache、region 與 account 對成本曲線的影響，Vantage 可以把雲端費用整理成可查詢、可分組、可預測的報表。

這個定位讓 Vantage 接到三個主章。它從 9.7 成本邊界與 efficiency 接收 cost per request 與 over-provision waste，從 9.8 效能可觀測性 接收 dashboard 與 ownership 訊號，從 04 可觀測性成本歸因 接收 tag、label 與 attribution vocabulary。

適用場景

Showback 與 chargeback 是 Vantage 的主要入口。當平台成本散在 shared Kubernetes cluster、managed database、network egress、storage 與 support plan 裡，Cost Reports 可以把費用依 team、service、environment 或 business unit 切開，讓討論從總帳單轉成 owner action。

Kubernetes 成本分析適合用 Vantage 補足平台可見性。Namespace、label、service、pod、CPU、RAM、storage 與 GPU 維度能讓團隊看到 idle cost、resource efficiency 與 rightsizing recommendation，特別適合多租戶平台。

Forecast 與 anomaly review 適合日常成本治理。每月 forecast、cost trend、unexpected spike 與 budget drift 可以接到 engineering review，讓容量調整、release、marketing event 與成本變化在同一個時間軸上被討論。

選型判準

Cost allocation 價值來自 owner 明確。總帳單只能告訴組織花了多少錢；service-level report 才能讓工程團隊知道哪個 workload、region、database 或 network path 改變了成本。

Kubernetes 成本價值來自 shared cluster 拆分。多租戶平台常把多個服務塞進同一組 node pool；Vantage 類工具把 pod lifecycle 與底層基礎設施成本接起來，讓 namespace 或 label 變成成本討論單位。

Forecast 價值來自提前介入。成本 review 如果只看月底結果，容量浪費和異常用量已經發生；forecast 和 anomaly 讓團隊在月中就能調整 resource request、replica、reserved capacity 或 release plan。

最短判讀路徑

判斷 Vantage deployment 是否健康、最少看四件事：

• Multi-cloud connector coverage：AWS / GCP / Azure / Snowflake / Datadog / Fastly 等 connector 是否都接上 — 缺一個就有成本盲區、缺了 Snowflake 反而比缺了 AWS 痛（query cost 沒人看）
• Cost Report 設計：是否依 service / team / environment / business unit 切出可 share 的 saved report、URL 是否進 wiki / Slack canonical 位置、誰每週看
• Anomaly Detection 設定：threshold 跟 baseline 是否 tune 過、false positive rate、anomaly 出現後是否有 owner 接、不是只進 email spam
• Report sharing 機制：cost report 是否走 read-only URL share 給工程 owner、不是把每個工程師都拉進 Vantage account；team 是否有 cost retrospective 節奏

四件事任一缺失、就是 9.7 成本邊界與 efficiency 邊界的待補項目。

跟其他工具的取捨

Vantage 和 Akamas 的主要差異是決策深度。Vantage 讓團隊看清成本、分攤責任與找出浪費；Akamas 更進一步把 workload constraint 與 configuration tuning 接成 optimization loop。

Vantage 和 CloudHealth 的主要差異是組織重心。Vantage 偏工程團隊可直接使用的 cost reports、Kubernetes 成本與 resource-level 分析；CloudHealth 偏 enterprise FinOps governance、policy 與大組織流程。

Vantage 和 AWS Cost Explorer 的主要差異是範圍。AWS Cost Explorer 是 AWS-native 入口；Vantage 適合跨 provider、Kubernetes 與多 workspace 的成本視圖。

核心取捨表

選 Vantage 的核心訴求：工程團隊自助 FinOps + 跨雲跨 SaaS 一張視圖 + UI / 報表 share 走 modern observability 體驗、且不需要 enterprise approval workflow / TBM business mapping。需要重 governance 走 CloudHealth、需要 IT-to-business cost mapping 走 Apptio、純 AWS 預算敏感先用 Cost Explorer。

進階主題

Cost Report builder：Vantage 的核心 primitive、走 filter + group by + time range 的 declarative model — 例如 provider:aws AND service:ec2 AND tag:team=payments group by region。Saved report 變團隊 canonical view、URL 可貼 wiki / Slack；scheduled report 走 email / Slack notification。實務上 每個 service owner 都該有一張 saved report、不是 FinOps team 中央集中看。

Anomaly Detection：依 cost trend 統計 baseline、超過 threshold 觸發 anomaly。痛點是 false positive：deploy 新 service、月底 invoice timing、provider 計費延遲都會觸發。Tune 方向是 排除 known event（new connector 接入後 7 天 grace period）+ 調 sensitivity per service（payment 可容忍 5% drift、ML training cluster 容忍 50%）。對應 9.7 成本邊界與 efficiency 的 anomaly governance frame。

Resource ROI / efficiency metric：Vantage 把 cost 跟 utilization metric 對齊、算 cost per unit（cost / request、cost / GB stored、cost / GPU-hour）。意義是把 cost report 從 absolute spend 升級到 efficiency frontier、能識別 overprovision 跟 underutilization。需要 metric source 接上（Datadog / Prometheus / CloudWatch）、純帳單 data 算不出 ROI。

Datadog / Slack integration：cost anomaly + scheduled report 推到 Slack channel、跟 incident channel 共用；Datadog 接成 metric source 後可在 Datadog dashboard 看 cost trend 跟 latency / error rate side-by-side、適合做 cost-aware SLO review。

Vantage Network（vendor benchmark）：匿名化彙整 Vantage 客戶的 unit cost benchmark（每 GB S3 storage、每 RDS instance hour、每 Snowflake credit）、讓客戶看自己跟同產業比是貴是便宜。價值在 negotiation leverage — 跟 AWS / Snowflake 談 EDP / 多年合約時、benchmark 是議價素材。注意是匿名 aggregate、不是 vendor 個別揭露。

排錯與失敗快速判讀

• Multi-cloud tag drift：AWS 用 team、GCP 用 Team、Azure 用 Team-Name、Vantage report group by 後出現大量 untagged — 在 Vantage Virtual Tag（rule-based tag normalization）統一 mapping、或源頭走 tag policy enforcement（AWS Organizations tag policy、GCP organization policy）
• Anomaly false positive 過多 / SOC-like alert fatigue：threshold 設太緊、month-end billing delay 沒排除 — 拉大 baseline window、加 grace period for new resource、per-service tune sensitivity
• Cost spike root cause 不明：總帳單漲了但 group by service / region / tag 都看不出來 — 切到 Resource Report（最細粒度、看 instance / volume / snapshot 個別 cost）找 outlier、或開 Vantage Cost Diffs（兩個 time window 對比 delta breakdown）
• Kubernetes cost agent 資料缺：agent 沒裝 / cluster role 權限不足 / metric server 沒啟用、namespace breakdown 全空 — 走 Vantage Kubernetes onboarding checklist 補 agent + RBAC + metric server、確認資料 24hr 內出現
• Connector 接上但資料沒進來：跨 account assume role 失敗、CUR（Cost and Usage Report）export 沒開、Snowflake account usage 權限缺 — 在 Vantage connector page 看 sync status 跟 error log、不是盲猜
• Report share URL 被外人猜到：read-only URL 預設 unauthenticated、share 給 contractor 後沒 revoke — 改用 Authentication-required share 或定期 rotate URL、敏感成本數字（payment processor cost / customer-specific dedicated infra）走 internal-only
• Forecast 不準 / 跟實際差太多：base period 太短 / 有 one-off event（migration backfill、disaster recovery test）、forecast model 抓不到 seasonality — 拉長 base period、標記 one-off event 排除、或改走 manual override forecast 給特定 service

操作成本

Vantage 的主要成本是 cost taxonomy 維護。Tag、label、account、workspace、cluster、namespace 與 service owner 要有穩定規則，Cost Reports 才能被工程團隊信任。

Kubernetes agent 導入需要平台協作。Cluster 權限、資料上傳、node / pod mapping、provider cost delay 與 double counting 防護，都需要平台團隊與 FinOps 團隊一起定義。

Remediation 成本在報表之後才開始。找到 idle cost、overprovisioned workload 或 unexpected egress 只是第一步，後續要有 ticket、owner、驗證、rollback 與 saving confirmation。

Evidence Package

Vantage 結果應回寫到 cost attribution evidence package。最小欄位包括 report name、filter、grouping、time range、provider、owner dimension、baseline cost、forecast、anomaly、efficiency metric、action item 與 owner。

Evidence package 的核心用途是把成本問題交給正確 owner。Vantage report 要能回答「誰的 workload 產生成本、成本從何時開始改變、哪個維度最能解釋變化」。

案例回寫

Vantage 目前適合作為 9.7 成本邊界與 efficiency 與 04 cost attribution 的工具承接點。它可回寫到 9.C12 Riot Games 246 EKS cluster 的多 cluster 成本歸屬與年省 1000 萬美金驗證、9.C23 Netflix Aurora consolidation 的 28% 成本下降跨 DB 整併、9.C17 BookMyShow modern data architecture 的儲存 90% / 分析 80% 成本下降，以及 9.C20 Zomato 的 on-demand cost model 50% 降幅。

這些案例的重點是成本歸屬。Vantage 頁引用案例時，要把 report filter、owner dimension、成本變化、action item 與驗證結果寫清楚 — 例如 Netflix 的 28% 下降需要拆到 DB tier、replication topology 與 read replica 比例，避免停在帳單 dashboard 截圖。

Vantage 的客戶輪廓偏 modern startup 與 mid-market — 工程組織 100-1000 人、cloud-native first、沒有獨立 FinOps team、由 platform / SRE 兼任成本治理。這類組織的痛點是 誰看 cost report、誰調 anomaly、誰負責 saving validation 的工程節奏沒建立、governance policy 本身反而不缺。引用 Riot Games / Netflix / BookMyShow / Zomato 案例時、重點是把這些 enterprise-scale 的 attribution 機制轉譯成 mid-market 可執行的 weekly review 節奏、而非照搬全部 governance overhead。

下一步路由

• 上游：9.7 成本邊界與 efficiency
• 上游：9.8 效能可觀測性
• 跨模組：04 可觀測性成本歸因
• 平行：CloudHealth、AWS Cost Explorer
• 官方：Vantage Cost Reports

觀察

ASOS 在 Azure 的關鍵數字（引自 ASOS Microsoft Customer Story）：

關鍵業務驅動：「ASOS chose Azure Cosmos DB because of its global distribution and ability to handle heavy seasonal bursts like Black Friday」。

判讀

ASOS 案例揭露三個全球零售 KV 容量規劃重點。

1. Black Friday 24h 1.67 億 = 平均 1,930 req/sec、峰值 3,500 req/sec：峰值 / 平均 = 1.81 倍。這個比例顯示 Black Friday 「持續高峰」、不是「瞬間爆量」 — 24 小時內流量曲線相對平緩、跟 9.C15 Tixcraft 的「5 分鐘賣完」是完全不同形狀。對應 9.2 Workload Modeling 的負載形狀識別。
2. 48ms 平均響應 = 全球分散下 Cosmos DB 的代表性數字：英國時尚電商、客戶遍及全球、Cosmos DB 在每個地區複製、讀取在最近 region 完成。這個 48ms 包含網路、DB、應用層 — DB 本身可能只佔 5-10ms、其他是網路與應用層。對應 9.12 SLO 與 Performance Budget 的 latency budget 分解。
3. 85K SKU + 每週新增 5K = 高更新頻率 catalog：商品資料不只是讀、還有頻繁更新（價格、庫存、推薦排序）。這層 write throughput 對 Cosmos DB partition key 設計（通常用 category_id 或 brand_id）至關重要。對應 9.4 Saturation Discovery 的 hot partition 識別。

需要警惕：這是 2016 年的數字、過去 10 年 ASOS 應該成長很多。但 1.67 億 req/24h 跟 33 orders/sec 對許多新興電商仍是天花板級數字、可作為「中大型零售」對標。

策略

可重用的工程做法：

1. Black Friday 類「持續高峰」適合 provisioned + scheduled scaling：跟 flash-sale 的「on-demand 吃彈性」不同、Black Friday 整天高、用 provisioned 比較划算。對應 9.11 高峰事件準備 的可預期峰值準備。
2. 全球零售用 Cosmos DB / DynamoDB Global Tables：客戶在哪、讀取就在哪、避免跨洲 latency。對應 9.C10 Spanner 的全球分散取捨。
3. 微服務 + Cosmos DB 是電商現代化典型路徑：從單體 → 微服務、從關聯式 DB → multi-model NoSQL、是 2016 後零售業常見遷移。對應 01 資料庫模組 與 05 部署平台模組。

跨平台等效：AWS DynamoDB Global Tables + Lambda、GCP Firestore + Cloud Run 都可以實作對等架構。差異是 Cosmos DB 的 multi-model（同一服務支援 SQL、Mongo、Cassandra、Gremlin、Table API）、AWS 對應有 DynamoDB（KV/Document）+ Neptune（Graph）+ Keyspaces（Cassandra）等多個服務。

下一步路由

• 對照其他可預期峰值 → 9.C1 AWS Prime Day / 9.C13 Hotstar IPL
• 對照 flash-sale-spike → 9.C15 Tixcraft
• 想對照其他 Cosmos DB 使用 → 9.C11 Minecraft Earth
• 想規劃全球電商 → 01 資料庫模組 + 9.6 容量規劃模型
• 想拆 Black Friday 容量背後的 RU 成本與 sizing → Cosmos DB RU 成本模型與 sizing
• 想做電商 partition key 設計 → Cosmos DB partition key 設計

引用源

• ASOS – Online retailer uses cloud database to deliver world-class shopping experiences
• Azure Cosmos DB

定位

AWS VPC Traffic Mirroring 適合需要網路層能見度的 AWS workload。當 application code、service mesh 或 host capture 都不適合改動時，VPC 層 mirror 可以從 ENI 複製封包到 analysis appliance、IDS、packet capture 或自管處理服務。

這個定位讓 AWS VPC Traffic Mirroring 接到 9.10 Production-Side 驗證 的 shadow traffic 前置觀測。它偏封包觀察與樣本收集，若要做應用層 replay、filter、rewrite 或 side effect 隔離，通常還需要 GoReplay、proxy、custom processor 或測試環境配合。

跟 GoReplay 比、VPC Traffic Mirroring 走 無侵入 L3 packet copy、GoReplay 走 application-level HTTP capture / rewrite；跟 Service Mesh Mirroring 比、VPC Mirror 在 ENI 層、Mesh Mirror 在 K8s pod 層；跟 AWS Network Firewall 比、Firewall 是 inline 阻擋、Mirror 是 side-channel 觀察、兩者目的不同但 packet path 相近。

最短判讀路徑

判斷 VPC Traffic Mirroring deployment 是否健康、最少看四件事：

• Source ENI selection：哪些 ENI 被 mirror（per-instance / per-subnet / 用 tag 自動選）、是否覆蓋瓶頸路徑上的關鍵節點（ALB target / NAT Gateway / RDS proxy / cross-AZ ENI）、漏掉哪個 ENI 就是 evidence 盲區
• Filter rule 收斂：mirror filter 用 protocol / port / CIDR / direction 限定、避免「全 ENI 全 traffic」這種失控設定；filter 太寬會把 cross-AZ cost + target 處理量直接炸上去
• Target NLB capacity：mirror target 是 ENI 或 NLB、target capacity（NLB flow / bandwidth）跟 source 流量比例要對得起來、target overload 會 drop 封包讓 evidence 失真
• Sampling rate / packet length truncation：高流量服務不必 1:1 mirror、要設 packet_length 截斷（只取 header）跟 mirror session ratio；忘設 sampling 等於整條 production 流量複製兩份、AWS bill 月底會出事

四件事任一缺失、就是 9.10 Production-Side 驗證 邊界的待補項目。

適用場景

網路層瓶頸定位適合 VPC Traffic Mirroring。當 latency、packet loss、TLS handshake、connection reset、NAT、load balancer 或 cross-AZ traffic 是疑點時，封包 mirror 能提供 application metrics 看不到的證據。

低侵入 traffic sampling 適合 VPC Traffic Mirroring。團隊可以在不改 application code 的情況下收集 production flow，作為 workload model、security analysis 或 replay pipeline 的輸入。

受管 AWS 網路環境適合 VPC Traffic Mirroring。當服務主要跑在 EC2 / ENI 可 mirror 的環境中，VPC 原生能力可以讓網路團隊用既有安全與觀測流程管理。

選型判準

網路層鏡像價值來自低侵入。團隊可以在不調整 application 或 service mesh 的情況下取得 flow evidence，但也要承擔 L7 語意不足的限制。

安全分析價值來自封包細節。對容量工程而言，封包證據能幫忙確認 connection、TLS、NAT、load balancer 與跨區流量成本；對資安而言，則能支援 IDS 與 forensic workflow。

跟其他方式的取捨

AWS VPC Traffic Mirroring 和 GoReplay 的主要差異是層級。VPC mirroring 在 L3 / L4 觀察封包；GoReplay 更接近 HTTP application replay，對 request rewrite 與 target control 更直接。

AWS VPC Traffic Mirroring 和 service mesh mirroring 的主要差異是控制範圍。VPC mirroring 由網路層控制，適合低侵入封包觀察；service mesh mirroring 由 L7 route policy 控制，適合服務版本與 route 對照。

AWS VPC Traffic Mirroring 和 synthetic load test 的主要差異是用途。VPC mirroring 提供 production traffic evidence；synthetic load test 提供可控壓力。兩者常搭配：先用 mirror 校正 workload model，再用 k6 / Gatling / Locust 產生可控負載。

操作成本

AWS VPC Traffic Mirroring 的主要成本是資料治理。Mirror target 可能收到 payload、token、cookie、internal identifiers 與敏感資料，因此保存、查詢、保留期限、存取權與刪除責任要先定義。

網路成本來自複製 traffic。Mirror session 會增加網路流量與 target processing 成本，高流量服務要先估算 mirror ratio、filter、target capacity 與跨 AZ 費用。

加密成本來自 L7 可讀性。TLS traffic 在網路層 mirror 後通常仍是加密封包；若需要 application payload，要搭配解密點、proxy、key 管理或 application-level capture。

Evidence Package

AWS VPC Traffic Mirroring 結果應回寫到 evidence package。最小欄位包括 mirror source ENI、filter rule、mirror target、session number、time range、sampling / truncation、target capacity、payload handling、packet metrics、known gap 與 owner。

Evidence package 的核心用途是把網路層觀察接回效能判斷。Reviewer 要能知道 mirror 覆蓋哪些 ENI、哪些封包被 filter、target 是否有 capacity，以及封包證據如何對應到 application latency 或 saturation。

進階主題

Filter rule 設計：mirror filter 支援 source CIDR / dest CIDR / protocol / port range / direction（ingress / egress）、rule number 決定 evaluation 順序。production 慣例是 最小覆蓋原則 — 先用 port 443 + dest CIDR = ALB target group 限定到關鍵 path、再依需要擴張。filter 寫太寬會把 control-plane heartbeat、health check、internal RPC 全部 mirror 進來、target 處理量瞬間爆掉。

跟 IDS / packet analyzer 整合：mirror target 接 ENI 後常見的下游堆疊是 Zeek（前 Bro、生成 connection log / protocol log）、Suricata（rule-based IDS / IPS 偵測）、Wireshark / tshark（離線封包分析）。實務上 mirror → NLB → 自管 EC2 跑 Zeek 產 JSON log → 進 Datadog / Splunk 做 correlation。容量工程關心 connection reset 跟 retransmit、資安關心 protocol anomaly、共用同一份 mirror feed。

Replay 到 staging cluster：mirror feed 不能直接 replay（沒有 stateful 重組），但可以接 packet replayer（tcpreplay / GoReplay packet mode）把樣本送到 staging。要注意 side effect 隔離 — staging 的 DB / external API 不應該真的執行寫入、否則 mirror 變成 production fanout。

Traffic analysis platform 整合：mirror 取得的 packet evidence 通常進 Datadog Network Performance Monitoring 做 NPM dashboard、或進 Splunk Stream app 做 SIEM correlation。整合的關鍵是 時間軸對齊 — packet timestamp、application log、metrics 三者要同步、否則 root cause 拼不回去。

排錯與失敗快速判讀

• Target NLB capacity 不夠 / drop packet：mirror traffic 量超過 NLB flow limit、packet 被 silently drop — 拆 mirror session 到多個 target、開 NLB flow log 看 drop reason、必要時改用 Gateway Load Balancer
• Filter rule 太寬導致流量爆：「mirror 所有 traffic」設定上線後 target ENI 跟 cross-AZ bandwidth 雙重炸 — 立刻關掉 session、改用 dest CIDR / port 收斂、加 packet_length 截斷只取 header
• Cross-AZ mirror cost 暴增：source ENI 跟 target 在不同 AZ、每個封包複製都收 cross-AZ traffic 費 — target NLB 部署到每個 AZ、用 AZ-affinity routing、或把 mirror target 限定在 source 同 AZ
• TLS payload 看不到：mirror 拿到加密封包、L7 內容無法分析 — 把解密點移到 ALB / NLB-TLS termination、或在 application 層加 capture（不再用 VPC mirror）
• Mirror session 漏掉新 instance：autoscaling 起新 instance 沒自動加入 mirror — 用 mirror target by tag、Terraform / CloudFormation 把 mirror session 寫進 ASC launch template
• Packet timestamp 不對齊 application log：mirror packet 時間是 source ENI capture 時間、不是 application processing 時間、做 latency 分析會偏差 — 用 packet 5-tuple + request ID 對齊 application log、不要直接相減 timestamp

案例回寫

AWS VPC Traffic Mirroring 適合回寫網路與平台層效能案例。它可接 9.C34 GCP 130K node GKE cluster 的大規模網路觀測需求（雖在 GCP、但網路證據的層次拆解可類比）、9.C22 Wayfair GCP burst capacity 的跨雲容量觀測、9.C1 Prime Day readiness 的 pre-event network evidence、9.C12 Riot Games 246 EKS cluster 跨 cluster 的網路流量觀測、以及 9.C24 Genesys DynamoDB 15-region 的 99.999% 可用性下封包層 evidence 補強。

這些案例的重點是網路層 evidence。VPC Traffic Mirroring 頁引用案例時，要把 case 轉成 mirror source、filter、target capacity、packet metric、cross-AZ cost 與 L7 correlation — 例如 Riot Games 35ms 延遲門檻下、cross-AZ traffic mirror 本身會增加成本、必須先用 filter 收斂到關鍵 ENI。

下一步路由

• 上游：9.10 Production-Side 驗證
• 上游：9.5 瓶頸定位流程
• 平行：GoReplay
• 平行：Service Mesh Mirroring
• 知識卡：Shadow Traffic
• 官方：AWS VPC Traffic Mirroring documentation

服務定位

CloudHealth 跟 AWS Cost Explorer / Azure Cost Management 那種單雲原生工具的差異在 跨雲一致 schema + enterprise FinOps operating model、單雲帳單細節反而是原生工具更深。Cost Explorer 在 AWS-only 場景的 granularity 更深、但跨 Azure / GCP 帳單對齊、成本中心 chargeback、policy 治理就需要 CloudHealth 這類 multi-cloud platform。

跟 Vantage 比、CloudHealth 走 enterprise governance-first、Vantage 走 engineering-friendly dashboard-first。Vantage 對小到中型 cloud-native 團隊更快上手、但 chargeback 流程、policy violation queue、approval workflow 都不是它的主場。跟 Apptio Cloudability（IBM 收購）比、兩者定位最接近、都吃 large enterprise FinOps 市場；CloudHealth 的差異是 VMware / Broadcom ecosystem 整合（vCenter / Tanzu / on-prem hybrid），Cloudability 強在 TBM（Technology Business Management）財務分攤模型成熟度。

關鍵張力：Broadcom 收購後的 product roadmap 不確定性 ↔ enterprise FinOps ecosystem 深度。Broadcom 對 VMware portfolio 的價格調整、partner 縮編、support tier 變動 2024-2025 持續發生；客戶要評估 退場成本（chargeback rule + tag taxonomy 量大）vs 短期 license 漲幅、不是只看當下功能。

定位

CloudHealth 適合 enterprise FinOps 與 cloud governance。當組織需要跨 AWS、Azure、Google Cloud、Kubernetes、shared services 與成本中心建立 showback、chargeback、policy 與 optimization workflow，CloudHealth 類平台可以提供集中式成本管理與治理視角。

這個定位讓 CloudHealth 接到三個主章。它從 9.7 成本邊界與 efficiency 接收 cost curve 與 over-provision waste，從 9.8 效能可觀測性 接收成本 dashboard 需求，從 04 可觀測性成本歸因 接收 owner、tag 與 attribution 規則。

適用場景

多雲成本治理是 CloudHealth 的主要入口。大型企業常有不同 cloud provider、不同採購合約、不同 account 結構與不同團隊成熟度；CloudHealth 可以把成本、資產、policy 與權限治理收斂到 FinOps 工作流程。

Showback / chargeback 適合用 CloudHealth 建立財務語言。成本中心、部門、產品線、環境與專案需要穩定分攤規則，才能讓工程決策接到預算管理、採購承諾與年度規劃。

Optimization workflow 適合用 CloudHealth 管理組織節奏。Rightsizing、reserved capacity、idle resource、tag compliance 與 policy violation 都需要 owner、例外、核准、驗證與追蹤，enterprise 平台的價值在於流程一致。

選型判準

組織治理價值來自一致流程。單一工程團隊可以靠雲端原生工具追成本；大型組織需要 policy、role、approval、exception 與 audit trail 才能讓成本治理長期運作。

成本分攤價值來自可對帳。Showback / chargeback 要能讓財務、平台與服務 owner 對同一筆費用得到相同解釋，shared platform cost、discount、support fee 與 commitment benefit 都要有分攤規則。

最佳化流程價值來自閉環管理。Rightsizing recommendation 只有在 owner 接手、服務驗證、變更落地與 saving confirmation 完成後，才會變成實際成本改善。

最短判讀路徑

判斷 CloudHealth deployment 是否健康、最少看四件事：

• Multi-cloud connector 完整性：AWS（CUR / billing role）、Azure（EA / MCA billing role）、GCP（BigQuery billing export）、Kubernetes（kube-state-metrics + Prometheus）連接器是否都接通、是否有 daily ingestion lag、是否漏 account / subscription
• FinOps team workflow 落地：policy queue、recommendation queue、approval flow 是否有實際 owner（不只是 dashboard 看一看）、weekly / monthly FinOps cadence 是否進到工程 sprint 跟財務 close cycle
• Chargeback 規則可對帳：business unit / cost center / application / environment 的分攤公式是否文件化、shared service（platform team / CI runner / observability stack）的 split rule 是否被各 BU 接受、月底財務 close 對得起來
• Reserved Instance / Savings Plan 管理：commitment coverage（已 commit 比例）、utilization（已用比例）、expiration alert、跨 account 的 commitment sharing 是否有 owner 主動經營、不是買完就放著

四件事任一缺失、就是 9.7 成本邊界與 efficiency 邊界的待補項目。

核心取捨表

選 CloudHealth 的核心訴求：enterprise scale + 多雲 + 已有 VMware / Broadcom ecosystem、且能投入 FinOps team 維護 chargeback rule、policy queue、commitment management lifecycle。中小型 cloud-native 走 Vantage 更快；AWS-only 直接用 Cost Explorer + Cost Anomaly Detection；重財務 TBM 整合走 Apptio Cloudability。

跟其他工具的取捨

CloudHealth 和 Vantage 的主要差異是治理深度。Vantage 偏工程友善報表與 Kubernetes cost visibility；CloudHealth 偏 enterprise FinOps operating model、policy 與大組織分攤流程。

CloudHealth 和 Akamas 的主要差異是最佳化方式。CloudHealth 偏成本治理與推薦流程；Akamas 偏把 SLO 約束與 configuration tuning 放進 optimization engine。

CloudHealth 和 AWS Cost Explorer 的主要差異是多雲與流程。Cost Explorer 適合 AWS-native 成本分析；CloudHealth 適合跨 provider、跨成本中心與跨團隊治理。

操作成本

CloudHealth 的主要成本是組織模型維護。Business unit、cost center、application、environment、owner、account 與 tag policy 需要持續治理，平台才能提供穩定報表。

流程成本會高於單純報表工具。Recommendation 需要進入 approval、exception、change management、validation 與 financial close process；這些流程讓工具適合大型組織，也要求更高維運紀律。

資料品質成本會集中在標籤與 shared cost。未標記資源、跨團隊 shared service、commitment benefit 分攤與 marketplace charge 都會影響成本歸屬信任度。

進階主題

Reserved Instance 與 Savings Plan management：CloudHealth 把 commitment 視為 portfolio、不是單筆採購。Coverage（已 commit 比例）、utilization（已用比例）、break-even（攤平時間）三個指標要持續追、跟業務 roadmap 對齊；新服務上線前先 model 預期用量、commit 太多反而 lock-in 浪費、太少又付 on-demand 溢價。跨 account / linked account 的 commitment sharing 要明確 owner、不然 platform team 買的 RI 被 product team 吃掉、財務分攤回不去。

Chargeback / showback 流程：showback 是 讓 BU 看到自己花多少、chargeback 是 讓 BU 帳本上真的扣這筆。chargeback 需要財務簽核、需要每月 close cycle、需要 dispute 機制；CloudHealth 的 chargeback rule 改動要走 approval、不能 admin 自己改完就上線、會直接影響 BU 月結。

Multi-cloud asset inventory：CloudHealth 不只是帳單工具、也作 asset inventory — EC2 / RDS / VM / GKE node / Azure SQL 等資源的 owner、tag、environment、policy state 在同一視角。這個能力是 enterprise CMDB integration 的入口、也能反向支援 7 security posture 的 untagged / unauthorized resource 偵測。

跟 Datadog / SIEM integration：CloudHealth 的 cost data 可以 export 到 Datadog 作 SRE cost-aware alert（service 突然花費暴衝 → 通常是 retry storm / runaway job），也可送 SIEM 作 untagged resource / cross-account spend anomaly 偵測。整合的價值不是把 CloudHealth 當另一個 observability tool、而是讓 cost signal 進到工程值班的視野。

Broadcom 收購後 product roadmap 變動風險：2023 Broadcom 完成 VMware 收購後、CloudHealth 經歷 license model 調整、partner program 變動、support tier 重整。對既有大客戶來說 license 漲幅、SLA 條款、roadmap 透明度都進入再評估期；新客戶選型時 退場成本評估 要先做、不能假設 platform 五年不變。Broadcom 對 enterprise 客戶仍會維持產品線、但中小客戶可能感受到 support 縮減。

排錯與失敗快速判讀

• Multi-cloud tag 不一致：AWS 用 Environment=prod、Azure 用 env=production、GCP 用 env-tier=prod — CloudHealth 報表看起來三套不同 — 統一 tag taxonomy（cost center / application / environment / owner）寫進 cloud governance policy、用 cloud-native enforcement（AWS Tag Policy / Azure Policy / GCP Org Policy）擋未標記資源
• Chargeback 對不上帳：BU 看到的金額 ≠ 財務 close 的金額 — shared service split rule 沒被簽核、commitment benefit attribution 跑掉、marketplace charge 沒分攤 — 走 monthly close reconciliation、把 rule 鎖定後才開 dispute window
• Reserved Instance 浪費：commit 買了沒用滿（utilization < 80%）— 跨 account share 沒開、或業務 roadmap 改了沒同步 commitment team — 開 cross-account RI sharing、commitment review 進 monthly FinOps cadence
• 新雲帳號接不進來：connector 一直 ingestion failure — IAM role / EA permission / BigQuery export 沒設好、或 organization 結構改了 CloudHealth 沒同步 — 走 onboarding checklist、新 account 自動化納管
• Recommendation 一直沒人 action：rightsizing queue 累積幾百筆沒處理 — 沒有 owner、或 recommendation 沒對應到實際 service team — 用 tag 反查 owner、把 recommendation 進 sprint backlog 而非 FinOps 自己追
• Broadcom 收購後 support / price 變動：renewal 漲幅突然 30-50%、support tier 被降級 — 早一年開始評估替代方案（Vantage / Apptio / 雲原生組合）、把 chargeback rule 跟 tag taxonomy 抽象到不綁 vendor 的格式

Evidence Package

CloudHealth 結果應回寫到 FinOps governance evidence package。最小欄位包括 business unit、cost center、application、provider、account、policy、recommendation、expected saving、approval state、implementation state、verified saving 與 exception。

Evidence package 的核心用途是支援治理審查。CloudHealth report 要能回答「這筆成本屬於誰、哪條 policy 觸發、誰核准例外、變更是否真的帶來 savings」。

案例回寫

CloudHealth 目前適合作為 enterprise FinOps 與多雲治理案例的工具承接點。它可回寫到 9.C14 Standard Chartered 的 7 個受監管市場跨地區治理與成本中心分攤需求、9.C33 Maersk + Bosch on Azure AKS 的傳統產業多 BU 治理一致性、9.C22 Wayfair hybrid burst 的 on-prem + GCP 雙來源帳單合併、以及 9.C35 Snap multi-cloud 的 GCP + AWS 跨雲成本對照。

這些案例的重點是組織能力。CloudHealth 頁引用案例時，要把案例拆成 governance model、owner taxonomy、policy action、engineering validation 與 financial reporting — 例如 Standard Chartered 的 7 市場分割要回到 per-market policy + 合規 tag、不是單一全球 report、而非停在雲端帳單下降。

下一步路由

• 上游：9.7 成本邊界與 efficiency
• 上游：9.8 效能可觀測性
• 跨模組：04 可觀測性成本歸因
• 平行：Vantage
• 官方：Broadcom CloudHealth announcement