モビリティスケールアップ：クラウド請求−30%、SLO同等。

トラフィックが追随せずにAWS請求が18か月で倍増：それは成長ではなく、現金で支払われるアーキテクチャ負債です。

コンテキスト

都市モビリティスケールアップ、180人、パリとモントリオールのハブ、400万アクティブユーザー。4年間本番稼働のマイクロサービスプラットフォーム、12エンジニアのプラットフォームチーム。CFOがテーブルを叩きました：年間クラウド請求は210万ドルを超え、同期間のトラフィック成長は22%。

問題

• トラフィック+22%に対して18か月でAWS支出2倍
• チーム別予算なし、FinOps未導入
• EKSノードの体系的オーバープロビジョニング（平均CPU 14%）
• MTTR 47分、ノイジーアラート、分散トレーシングなし
• エンジニアがサービスにコストを割り当てられない

アプローチ

GreenOps監査6週間、その後7か月の段階的修正。ビッグバンなし、リプラットフォーミングなし。測定から開始し、明白な脂肪を切り、再考すべきものを再考しました。

4つのワークストリーム

• 完全な可観測性：Prometheus、Grafana、Tempo、Kubecost経由の名前空間別コスト割り当て
• Cluster AutoscalerからKarpenterへのマイグレーション：タイトパッキング、spot first、積極的統合
• ベンチマーク後、ステートレスワークロードの60%でARM64 Graviton
• スマートスケジューリング：中断可能スポットで夜間バッチ、taints/tolerationsをリセット

スタック

• Go 1.22、EKS上のKubernetes 1.29
• Karpenter 0.34、Graviton2/3（c7g、m7g）
• Prometheus、Grafana、Tempo、OpenTelemetry SDK
• 割り当てのためのKubecost、IaCのためのTerraform

結果

1. クラウド請求：9か月でイソSLOで-30%（-630kドル/年）
2. MTTR：47分から11分（4分の1）
3. 平均クラスタCPU：14%から51%
4. 吸収トラフィック：キャパシティ追加なしで+35%
5. 推定カーボンフットプリント：-38%（クライアントScope 3レポート）

学んだこと

Karpenterはゲームチェンジャーですが、pod disruption budgetsに厳格さを要求します。ARM64は100%ではなく60%のワークロードで動作：一部のサードパーティC++バイナリは2か月抵抗しました。真の持続可能なレバーは、チームに組み込まれたFinOpsです：離脱後も下落が続くように、社内リレーを2人トレーニングしました。