Smart Sizingとは：Rightsizingを超えたスマートなクラウドへの次のステップ
著者: Thomas Mathew (opens in a new tab) 日付: 2025年12月31日
要約: Kubernetesクラスターは通常、過剰なCPUおよびメモリ要求により30〜40%のリソースを無駄にしています。開発者はパフォーマンス問題を回避するためにリソースを過剰に割り当て、大量の未使用コンピューティングリソースが発生します。手動Rightsizingには数百のワークロード全体で継続的な分析が必要です。Kubernetes VPAは問題の一部を自動化しますが、重要な制限があります。Wave AutoscaleのSmart Sizingは、より優れたメトリクス、実用的な推奨事項、垂直+水平統合スケーリングでこれらのギャップを解決します。
重要なポイント
- Kubernetesクラスターは通常、過剰なCPUおよびメモリ要求により**30〜40%**のリソースを無駄にしています
- 開発者はパフォーマンス問題を回避するためにリソースを過剰に割り当て、大量の未使用コンピューティングリソースが発生します
- 手動Rightsizingには継続的なメトリクス分析、分類、調整が必要です
- Kubernetes VPAは問題の一部を自動化しますが、既知の制限があります
- Wave Autoscaleは、より優れたメトリクス、実用的な推奨事項、統合スケーリングでこれらのギャップを解決します
Kubernetesリソース、今も無駄になっている可能性が高い
あなたのKubernetesクラスターは、おそらく今この瞬間も30〜40%のリソースを無駄にしており、エンジニアはその修正に何時間も費やしています。
Datadogのコンテナ調査によると、 (opens in a new tab) コンテナのほぼ半数が要求したCPUとメモリの3分の1未満しか使用していません。 つまり、クラスター全体で見ると30〜40%レベルのリソースが無駄になっているということです。
これは誰のせいでもありません。 開発者がコンテナリソースを設定する際は、常に安定性を最優先に考えます。
- 実際には200mで十分なCPUに500mを要求し
- 400Miで足りるメモリに1Giを設定する
ことはよくあります。特に早朝に発生するOOMKilledポッドを経験したチームならなおさらです。
問題は、この設定が積み重なることです。 数十、数百のワークロードに同じ方法が適用されると、結局使用しないコンピューティングコストを支払い続けることになります。
最適化を試みようとすると、 エンジニアは機能開発の代わりにメトリクス分析と設定調整に時間を費やすことになります。
コンテナリソース設定が適切かどうかの基準とは
コンテナリソースを評価する基準は意外とシンプルです。
- **実際の使用量が要求値の90〜110%**の範囲内なら理想的
- 90%未満 → リソースを無駄にしている状態
- 110%超過 → パフォーマンス低下や障害リスクがある状態
この記事では、この基準に基づいてKubernetesコンテナを適切にRight Sizeする方法と、規模が大きくなるにつれて自動化が必須になる理由を見ていきます。
手動Rightsizingに必要な作業とは
自動化の話をする前に、現実的に手動Rightsizingがどのような作業を要求するかから見ていきましょう。
ステップ1. 適切なメトリクスの収集
Sysdigのキャパシティプランニングガイド (opens in a new tab)は、kube-state-metricsとcAdvisorを活用したリソース分析を推奨しています。コンテナリソースを適切に分析するには1週間以上のデータが必要で、次のような作業が必要です。
- 最低7〜14日間の連続メトリクスデータ
- CPU、メモリ、ネットワーク使用量の収集
- PrometheusやDatadogなどのツール設定
- ダッシュボードとクエリの直接構成
課題: ワークロードごとに観察基準が異なるという点です。週1回実行されるバッチジョブと24時間リクエストを処理するAPIを同じ基準で見ることはできません。
ステップ2. 過去のパターン分析
- いつ使用量が最も高かったかを把握
- 周期的なパターンがあるか確認
- 一時的な異常値か実際のトラフィック増加かを区別
- 先週のグラフのスパイクが本当のユーザー増加によるものか、一時的なデータ移行によるものかを判断
課題: このプロセスには思ったより多くの分析経験が必要です。
ステップ3. すべてのワークロードの分類
各コンテナを次の3つの状態に分類します。
- 過剰リソース割り当て: 実際の使用量が要求値の90%未満で、不要なコストが発生している状態
- リソース不足: 実際の使用量が要求値の110%超過で、パフォーマンス低下リスクがある状態
- 適切なレベル: 実際の使用量が要求値の90〜110%の範囲内にある理想的な状態
課題: コンテナ数が増えると、この分類作業だけで数日かかります。
ステップ4. 最適なリクエスト値の計算
- P95（95パーセンタイル）基準の使用量から開始
- トラフィック急増に備えた余裕を追加
- ガベージコレクションの影響を考慮
- コンテナ起動時のスパイクを反映
課題: ワークロードのタイプによって計算方法は異なります。
計算式の例:
推奨CPU要求 = (P95 CPU使用量 × バースト乗数) + 起動オーバーヘッド
推奨メモリ要求 = 最大メモリ使用量 + GCオーバーヘッド + 安全バッファステップ5. 適用と反復
- 段階的にデプロイし監視
- パフォーマンス異常がないか見守る
- 問題が発生したら戻す準備
- トラフィックパターンが変わったら → プロセスを繰り返す
- アプリケーションが更新されたら → プロセスを繰り返す
課題: このすべてのプロセスを再び繰り返す必要があります。終わりがありません。
手動Rightsizingの現実
VPAはどの点を改善したのか
この問題を解決するために登場したのがKubernetesのVertical Pod Autoscalerです。
参考: このプロジェクトは当初Googleのエンジニアによって設計され、 (opens in a new tab)現在もGoogleとMicrosoftをはじめとする多くの貢献者 (opens in a new tab)によって積極的に保守されています。
VPAはコンテナの実際の使用量に基づいてCPUとメモリの要求値を自動的に推奨し調整します。
そのおかげで、エンジニアが直接メトリクスを分析して値を計算する負担は軽減されます。
VPAの主な機能
- 自動リソース推奨: 過去の使用データを分析して適切なCPUとメモリの要求値を提案
- 継続的な調整: ワークロードパターンが変わってもそれに合わせて設定を継続的に更新
- 手動作業の削減: スプレッドシート分析やPromQLクエリ作業なしでも運用可能
- 3つの運用モード:
- Offモード: 推奨値のみを提供し、適用はユーザーが直接実行
- Initialモード: ポッド作成時点でのみリソースを設定
- Autoモード: 実行中のポッドのリソースを自動的に調整。ただし、ポッドの再起動が必要
確実な改善
手動Rightsizingに疲れたチームにとって、VPAは明らかに意味のある進歩です。VPAは次の負担を取り除きます:
- 数週間のメトリクスデータの収集と分析
- P95値とバッファ乗数の計算
- 各ワークロードの個別分類
参考: Kubernetesドキュメント (opens in a new tab)は、VPAを「PodのCPUとメモリの予約を自動的に調整してアプリケーションを'right size'するのに役立つ」ソリューションとして説明しています。
VPAがすべての問題を解決していたら、これ以上の代替案は必要なかったでしょう。
しかしVPAでは不十分な理由
制限1. 限定的なメトリクス
VPAはCPUとメモリの使用率のみを基準とします。 しかし、CPU使用率50%だからといって問題がないとは言えません。
**CPU Pressure (PSI) (opens in a new tab)**は、パフォーマンス問題をより正確に示す指標です。しかし、VPAはこの指標を使用しません。
参考: Brendan Gregg - CPU Utilization is Wrong (opens in a new tab)
制限2. ネットワーク認識の欠如
ネットワークトラフィックの増加は、CPUとメモリのスパイクより先に現れることが多いです。
VPAはこれを検出できず、常に事後対応にとどまります。
制限3. HPAとの競合
VPAとHPAはどちらもポッド仕様を変更する方式のため、競合が発生します。VPAドキュメント (opens in a new tab)でも両機能の併用を推奨していません。
Wave Autoscaleが提示するSmart Sizing方式
Wave Autoscaleは、この制限を根本的に異なる方式で解決します。
より正確なシグナルを見る
Wave Autoscaleは次を使用します:
- CPU pressureメトリクス (使用率ではなく実際の競合)
- ネットワークI/Oメトリクスを先行指標として活用
- トラフィック認識サイジングでシステムがリソース必要量を予測
このおかげで、リソース不足を問題が発生した後ではなく、発生する前に検出できます。
すぐに適用できる推奨事項を提供
Smart Sizingは「問題がある可能性があります」という警告で終わりません。
- 現在の設定値と推奨値を並べて比較可能
- リソースがどれだけ過剰または不足しているかを即座に把握
- Change Sizeボタンで変更を安全に適用可能
スプレッドシートも、推測も必要ありません。
垂直と水平のスケーリングを別々に見ない
Wave Autoscaleは、リソース最適化とポッド数調整を1つの流れで扱います。VPAとは異なり、Wave Autoscaleは垂直および水平スケーリングを1つの統合プラットフォームで処理し、一緒に動作します。
| 機能 | VPA + HPA | Wave Autoscale |
|---|---|---|
| 垂直リソース最適化 | ✓ (VPA) | ✓ (Smart Sizing) |
| 水平スケーリング | ✓ (HPA) | ✓ (Autopilot) |
| 一緒に動作するか | ✗ 競合発生 | ✓ 統合 |
| CPU圧力指標活用 | ✗ | ✓ |
| ネットワーク認識 | ✗ | ✓ |
1つのプラットフォーム、完全なカバレッジ:
- 垂直最適化でコンテナリソースを調整
- 水平スケーリングで需要に応じてポッド数を調整
- 共有インテリジェンス: 両方のシステムが互いに情報を共有
クラスター全体を一目で見る
Wave Autoscaleは、クラスター全体に対する完全な洞察を提供します:
- すべてのコンテナの状態を自動的に分類し
- パターンの変化に応じて継続的に更新し
- コスト削減効果をすぐに確認できます
クラスター全体のプロビジョニング状態を示すダッシュボード
リソースを無駄にしているか、リスクにさらされているコンテナを即座に識別
結論. よりスマートに！
Kubernetes Rightsizingは避けられない課題です。 しかし、方法は選択できます。
手動で行うこともできます。ただし、その代償は月に25〜100時間のエンジニアリングリソースです。
VPAは一部を自動化しましたが、メトリクスと拡張方法には明確な制限があります。
Wave Autoscaleはこのギャップを埋めます:
- 実際のパフォーマンスを反映する指標 (CPU pressure、ネットワーク認識)
- 垂直と水平スケーリングを包括する構造
- クラスター全体の可視性
- 実用的な推奨事項
Wave Autoscaleを使用するチームは次のような成果を達成しています:
- 最大2倍速いスケーリング応答
- 最大40%のコスト削減
- 予測ベースのスケーリング
- スマートリソースサイジング
- 優先度ベースのトラフィックシェーピング
Autopilotは予測ベースのスケーリングとSmart Sizingを通じて 運用効率を高めながらも、プラットフォームチームが制御を失わないように設計されています。
Wave Autoscaleは、ML駆動の最適化により2倍速いスケーリング応答と最大40%のコスト削減を実現します。Smart Sizing機能は、統合された垂直および水平スケーリングとともに実用的なリソース推奨事項を提供しながらも、チームが制御を維持できるようにします。