要点: 健全な成長には、顧客体験、処理能力、成果一件当たりの費用を同時に見る必要があります。
この記事の用語: 処理能力：安全に処理できる能力。予備能力：障害や予測誤差に備える余力。成果単位コスト：成果一件当たりの費用。
現場の課題
平均CPUはピークを隠し、オートスケールはキューが増えた後に反応します。クラウド請求の総額だけでは、価値を生む費用と無駄を区別できません。
単純な対策だけでは不十分な理由
クラウド費用は成功リクエストや完了業務フローなどの成果単位へ結び付けます。処理能力計画はピーク、スケールの遅れ、一つのZoneの障害、必要な予備能力を含めます。
処理フロー
需要 モデル
業務フロー・ピーク→負荷テスト
安全な処理能力→Runtime
Budget・オートスケール→Unit Economics
Outcome コスト
業務フロー・ピーク→負荷テスト
安全な処理能力→Runtime
Budget・オートスケール→Unit Economics
Outcome コスト
アーキテクチャ上の判断
安全な処理能力定義
SLO境界前のOperating Pointと失敗 予備能力を選びます。
Baseline・Burst分離
安定需要を効率処理能力へ、キャンペーンと障害用Elastic余力を残します。
Shared コスト配賦
テナント・Workload TagとSamplingでコスト Driverを可視化します。
さらに深く考える
Performance テストはリリース 検証結果
代表Payload、キャッシュ State、テナント Mixを試験します。
FinOpsにEngineering コンテキスト
共通Unit メトリクスでコード、Storage、長期契約、Product 上限を判断します。
実装手順
- 業務イベント、ピーク係数、テナント規模の分布から需要を見積もります。
- 実際の依存サービス上限を含む負荷テストで、プロセス一つ当たりの安全能力を測ります。
- 成功業務フロー、利用中テナント、処理データ量など成果単位のコストをSLOと一緒に追跡します。
コード例: リリース 処理能力 ゲート
safeRps = loadTest.maxRpsWhere(p99 < sloP99 and errors < sloError)
minimumReplicas = ceil(peakRps / safeRps * 1.3)
assert capacityDuringZoneLoss >= peakRps
assert costPerSuccessfulJourney <= budget予備能力はForecast エラー、スケールの遅れ、失敗 Scenario、Saturation コストから決めます。
想定しておく障害
- キャンペーンでリクエスト Mixが変わります。
- スケールがDB 接続を枯渇させます。
- コスト Cutが冗長性を失わせます。
監視すべきこと
| 指標 | 何が分かるか |
|---|---|
| 成功業務フロー当たりコスト | Spendを顧客Valueへ接続します。 |
| 同時実行数・安全な処理能力 | CPU 100%前にSaturationを示します。 |
| Waste・再試行・Idle率 | 削減コストと予備能力を分離します。 |
設計の検証方法
- 一障害領域なしでピーク トラフィックを再実行します。
- Cold キャッシュ・Slow 依存サービスを試験します。
- テナント配賦コストとInvoiceを比較します。
本番導入の進め方
高コストな業務フロー一つから成果単位コストを測ります。繰り返せる負荷テストで安全な処理能力を決め、デプロイ判定とオートスケールへ反映した後に長期長期契約を変更します。
本番前チェックリスト
- Scaling SignalはSaturationより先行しWarm-upを含みます。
- BaselineとBurstを実トラフィックからSizingします。
- 最適化をエラーバジェットと遅延で確認します。
まとめ
コスト効率のよいSaaSは、測定済み処理能力と成果単位のコストから生まれます。