要点: Capacity、顧客Experience、Business Outcome当たりCostが揃って動くScaleが健全です。
課題
平均CPUはPeak Concurrencyを隠し、Autoscalingは遅れ、Cloud Billは顧客Outcomeに結びつきません。過剰ProvisionまたはReliabilityを損なう削減になります。
単純な対策だけでは不十分な理由
平均値ではCapacityを決めるPeakが消えます。Traffic Shape、Concurrency、Failure Domain喪失を含めます。
安いComponentがRetryやChurnを増やすことがあり、Unit CostをReliabilityと評価します。
処理フロー
Journey・Peak→Load Test
Safe Capacity→Runtime
Budget・Autoscaling→Unit Economics
Outcome Cost
アーキテクチャ上の判断
Safe Capacity定義
SLO境界前のOperating PointとFailure Headroomを選びます。
Baseline・Burst分離
安定Demandを効率Capacityへ、Campaignと障害用Elastic余力を残します。
Shared Cost配賦
Tenant・Workload TagとSamplingでCost Driverを可視化します。
さらに深く考える
Performance TestはRelease Evidence
代表Payload、Cache State、Tenant Mixを試験します。
FinOpsにEngineering Context
共通Unit MetricでCode、Storage、Commitment、Product Limitを判断します。
実装手順
- Business Event、Peak、Tenant分布からDemandをModel化します。
- 実Dependency LimitでInstance安全Throughputを測ります。
- 成功OrderやActive Tenant当たりCostをSLOと監視します。
技術例: Release Capacity Gate
safeRps = loadTest.maxRpsWhere(p99 < sloP99 and errors < sloError)
minimumReplicas = ceil(peakRps / safeRps * 1.3)
assert capacityDuringZoneLoss >= peakRps
assert costPerSuccessfulJourney <= budgetHeadroomはForecast Error、Scaling Delay、Failure Scenario、Saturation Costから決めます。
想定すべき障害パターン
- CampaignでRequest Mixが変わります。
- ScaleがDB Connectionを枯渇させます。
- Cost Cutが冗長性を失わせます。
監視すべきシグナル
| シグナル | 確認する理由 |
|---|---|
| 成功Journey当たりCost | Spendを顧客Valueへ接続します。 |
| Concurrency・Safe Capacity | CPU 100%前にSaturationを示します。 |
| Waste・Retry・Idle率 | 削減CostとHeadroomを分離します。 |
設計の検証方法
- 一Failure DomainなしでPeak TrafficをReplayします。
- Cold Cache・Slow Dependencyを試験します。
- Tenant配賦CostとInvoiceを比較します。
安全なRollout計画
高Cost Journey一つと月次Unit Metricから始めます。反復可能Test、Deploy Gate、Autoscalingの順で導入し、安定Evidence後に購入Commitmentを変更します。
本番前チェックリスト
- Scaling SignalはSaturationより先行しWarm-upを含みます。
- BaselineとBurstを実TrafficからSizingします。
- 最適化をError BudgetとLatencyで確認します。
まとめ
Cost効率は後付けDiscountでなく明示的Capacity Engineeringの結果です。