システムのダウンサイジングで固定費削減

統計によると、企業のクラウド支出の28〜32%が未使用リソースや過剰プロビジョニングに起因する無駄と言われています¹ ²。データセンターに目を向けても、常時稼働サーバのCPU使用率中央値が20%未満に留まる調査は珍しくありません³。これらは一度選んだスペックが惰性的に固定費化し、全社の利益率を静かに侵食していく現象です。私はこの問題を「ダウンサイジング＝壊さずに削る」設計課題として扱います。すなわち、SLO（サービスレベル目標）と体験品質を下げずに、過剰な容量と高額なランク・プラン・ライセンスを体系的に縮小することです。ここでは費用最適化と効果測定を両立させるために、設計、技術、測定、合意形成の順で実務的に掘り下げます。

ダウンサイジングは「固定費の構造」を変える設計課題

ダウンサイジングは単に小さなマシンへ移す作業ではありません。ベースラインの可視化、エラーバジェット（許容できる失敗の余白）に基づく品質の下限設定、業務のピークと平常を分離した容量モデル、そして可変費化できる領域の抽出という順番で、固定費として積み上がっている要素を構造的に組み替えます。私はまず、1カ月の請求と実測メトリクスを同じ時間解像度で並べ、どのリソースが何のサービス価値に紐づくのかを「1リクエストあたり」「1テナントあたり」「1ジョブあたり」の単位経済性に変換します。これにより、CPU、メモリ、IOPS、スループット、Egress、ライセンス・コア数といった物理量が、SLOとコストの両軸で論じられるようになります。

次に、SLOとコストの等式を作ります。例えばp95レイテンシ（全リクエストの95%が収まる遅延）150ms、エラーレート0.1%以下というSLOを維持しつつ、平均CPU使用率を45〜65%の帯に収める構成を「目標帯」と定義します。これより低い利用率は過剰、これより高い利用率はSLOリスクと明確化し、その帯に入るように垂直・水平の縮小を試算します。ここで有効なのが、必要vCPU数を推計する簡便式です。必要vCPU≒(リクエスト毎CPU時間×QPS)/(1vCPU当たり処理能力×目標利用率)。このあたりの数値化ができると、「このサービスはm5.4xlarge一台で余裕」という感覚的な会話から、「m6g.large×2に分割してもp95は維持できる」といった定量的な比較へと進みます。

ベースライン計測とタグ付けで“どこを削るか”を特定する

タグ付けの一貫性が弱いと、費用は削れません。サービス、オーナー、環境、コンポーネント、SLOをキーにしたタグ体系をまず整え、メトリクスと課金項目を同じタグで突き合わせます。1週間のピークと平常を切り出して、CPU、メモリ、ディスク、ネットワークの利用率の「底」と「天井」を測ると、常時過剰な部分が輪郭を見せます。例えば、平常時CPU15%以下で、週次バッチの2時間だけ70%に張り付くようなワークロードは、常時大きなマシンに載せず、平常を小さく、短時間だけ水増しする構成が効きます。

「壊さずに削る」の基準をエラーバジェットで定義する

短期の費用指標は強力ですが、品質を壊しては元も子もありません。そこで役に立つのがエラーバジェットです。SLO99.9%なら1カ月の許容障害時間は約43分です⁴。この枠内で行うダウンサイジング実験なら、意図的に小さくしても「合意されたリスク」になります。私はまずカナリアで10%トラフィックを小さな構成へ流し、p95/p99、スロットリング、GC時間（ガーベジコレクション）、DB待ちを監視しながら、CPUとメモリの目標帯に収束させます。テストで耐えた構成を段階的に本番へ広げると、SLOを崩さずに固定費の圧縮が実現します。

技術アプローチ：コンピュート、データ、ネットワーク、ライセンス

技術的な打ち手は多岐にわたりますが、原理は同じで、過剰なヘッドルームを数値で可視化して縮め、必要な弾力性は別の仕組みで確保します。コンピュートでは、インスタンスタイプの世代・アーキテクチャ変更、水平分割、コンテナのRequests/Limits（保証/上限）の是正が核になります。たとえば1台の大きなx86から、同等スループットが出るArm世代の小型インスタンスへ複数台で移すと、クロック単価と割引の両面で効くことが多いです。公開事例でも、プロファイリングでCPUあたりの処理量が同等であることを確認した上で、平均CPUを50%台に保つよう台数とサイズを選び直すことで、インスタンス費用の大幅な圧縮につながったと報告されています（効果はワークロードに依存します）。

コンテナとVMのライトサイジングはRequestsの是正から

Kubernetesでは、Requests過大がノードの空き断片を増やし、ノード数＝固定費を膨らませます。実測CPU/メモリのp95を基準にRequestsを引き下げ、Limitsはスパイク時の安全域に留めると、ノード密度が上がります⁵。HPA（Horizontal Pod Autoscaler）のターゲット利用率を50〜60%に置き、スケールダウンのクールダウンを短くし、ノード自体の最小台数を一段下げるだけでも、ノード時間は目に見えて減ることが多いです⁹。実際、30%程度のノード時間削減とレイテンシ維持を両立した公開事例もあります。

データベースとストレージは“階級”を落とす設計で効かせる

IOPS前提の上位プランを使い続けていると、固定費が雪だるま式になります。ワークロードのIOパターンを分解し、ホットセットは高速、コールドデータは低単価へと階層化するのが王道です。プロビジョンドIOPSから汎用ディスクへの移行、ログとスナップショットの保持期間短縮、圧縮とパーティションでの読み取り削減、読み取りが多いワークロードのリードレプリカ統合など、どれも地味ですが積み上げの効果が大きい。RDBのストレージクラス見直しやインデックス最適化、アーカイブ層の導入で月額ストレージ費用が大幅に下がったという報告もあり、アプリ側のキャッシュヒット率改善がDB接続数のピーク低減につながるケースも見られます⁶。

ネットワークとCDNは通信の“向き”を変えて課金を減らす

クラウドの外向き転送料は、見落としがちな固定費です⁷。アセットの圧縮やキャッシュ長寿命化は当然として、クロスAZ通信の分散を見直し、同一AZ内で完結する割合を高めると、転送料とレイテンシが同時に下がります⁸。さらに、画像・動画のトランスコードをエッジで行う構成に切り替えると、オリジンのアウトバウンドが減り、CDN費用は横ばいでもオリジン側の通信費を抑えられることがあります。

ソフトウェアライセンスはコア数と同時起動数で削る

コア単位課金や同時接続課金のミドルウェアは、vCPU削減とワーカープロセスの集約で固定費が動きます。JVMのヒープとGC設定を見直してプロセスをまとめ、vCPUを減らしたVMへ移す、あるいはランタイムを軽いものへ載せ替えるだけでも、年間ライセンス負担の見直しに直結します。SLOに効く範囲でワーカープールを縮め、スロットリングの閾値とバックプレッシャーの挙動を事前に検証しておくと、業務時間帯の安全性も担保できます。効果の幅は環境に左右されますが、数十％規模の改善が報告されることもあります。

経済効果の測定と“効果指標”の見せ方

意思決定を動かすのは、費用の変化がSLOと同じ画面で語られることです。私は、ベースライン費用、実験構成費用、差分、SLO遵守率、ユーザー体験の代理指標（例えばCVRやDAUの変化）を同一期間で並べ、金額と体験の両面で“変わらない”ことを示します。月次レベルの効果だけでなく、回収期間と12カ月の累計インパクトも添えると、ビジネス側に響きます。なお、以下の金額や割合は試算例であり、実際の効果はワークロードと交渉条件に依存します。例えば、月次1,200万円のインフラ・ライセンス費用を見直して880万円相当に抑制できた場合、差額は320万円、移行費用が300万円なら回収期間は概ね数カ月、12カ月累計の粗利改善は数千万円規模という語り方が可能です。

ケーススタディ：中規模SaaSのダウンサイジング（モデルケース）

月間2億リクエストを処理する中規模SaaSを想定したモデルケースを紹介します（数値は公開情報に基づく一般的なパターンを組み合わせた試算であり、実績ではありません）。開始時点の固定費はインフラとライセンス合計で月1,200万円、SLOは可用性99.9%、p95レイテンシ150ms。可視化の結果、平常時CPUが20%近辺のサービスが複数あり、夜間のバッチが容量の見かけを歪めていると仮定します。コンピュートはx86の大型からArm世代の小型へ分割し、Requests/Limitsをp95基準に是正、HPAのターゲットを55%へ設定。データはホット・ウォーム・コールドの三層化、RDBは汎用ストレージへ移し、読み取り集中のテーブルをインデックス再設計で分散。ネットワークは同一AZ内トラフィックの比率を上げ、CDNの画像変換をエッジ側に寄せます。加えて、JVMのヒープを見直しワーカーを集約、vCPU課金のライセンスを抑制。段階的リリースののち、インフラ費は数十％規模で低下し、RDSやストレージ、ネットワーク、ライセンスもそれぞれ二桁％の改善が見込める一方、p95は維持または改善、SLO遵守率も99.9%台を継続できる、という結果が期待できます（実際の効果は検証により確認が必要）。

リスク管理と運用：安全に小さくし続けるための作法

ダウンサイジングは“やって終わり”ではありません。ソフトウェアは成長し、トラフィックは季節で変わります。したがって、容量の見直しは四半期ごとの定常運用に落とし込むべきです。私は、主要サービスのCPUとメモリの目標帯、DBのIOPS帯、ネットワークのピークとボトム、そしてSLOの遵守率を定例でレビューし、次の縮小候補を毎回ひとつだけ選びます。選んだ対象は必ずステージングで負荷再現し、カナリアで段階的に展開し、最小構成のフロアを定義しておきます。障害時は速やかに元のサイズへ戻せるよう、IaCのパラメータは切り替えだけで反映できる形にしておくと、心理的安全性が上がります。

運用の現場では、ブラウンアウトの設計も効きます。バックグラウンドの重い処理を混雑時に自動で遅延させる、サムネイル生成を再要求に回す、推薦など重い付加価値機能を混雑時に段階的に簡易化するなど、体験を壊さずに計算資源を浮かせる工夫です。これにより、最小構成をさらに一段下げても、実際の混雑時にSLOを守りやすくなります。計画外のトラフィックが乗った際のフェイルセーフとしても機能します。

実行ロードマップの目安と組織への浸透

初回の全体見直しは8〜12週間を目安にすると、現実的で安全です。最初の2週間でタグとメトリクスを整え、次の2〜4週間でコンピュートとデータの縮小候補を選び、以降はサービス単位で計測と実験、展開を繰り返します。財務との合意形成には、月次の削減額、回収期間、12カ月の累計効果を、SLO遵守率と並べて定例で共有し続けるのが効果的です。現場のモチベーションには、見直しで生まれた余剰分の一部を改善施策へ再投資するルールが効きます。削った分だけ新しい価値に回る設計が、持続的な費用最適化を文化に変えていきます。

まとめ：削ることで、俊敏さと余白を取り戻す

固定費は、気づかないうちに事業の動き方を縛ります。ダウンサイジングは、単に費用を下げるだけでなく、必要なところへ素早く資源を振り向ける自由度を取り戻す取り組みです。SLOを堅持しつつ、ベースラインを測り、目標帯へ合わせ、実験で裏付け、数値で語る。この小さな反復が、数十％規模の最適化と意思決定の速度向上の両方を連れてきます。次のスプリントで、ひとつだけ対象を選ぶなら、どこを小さくしますか。計測ダッシュボードを開き、関係者を集め、最初の90分を確保するだけで、最初の効果指標は動き始めます。削った分の余白は、新しい価値の実験に使いましょう。

参考文献

1. Flexera. State of the Cloud Report. https://info.flexera.com/CM-REPORT-State-of-the-Cloud
2. Flexera. State of the Cloud Report – Wasted Cloud Spend. https://info.flexera.com/CM-REPORT-State-of-the-Cloud#:~:text=engineering%2C%20finance%20and%20business%20teams,that%20continues%20to%20be%20wasted
3. CAST AI. New CAST AI Cloud Optimization Analysis Finds Companies Overspend by 60 Percent Due to Overprovisioning Containerized Applications. https://cast.ai/press-release/new-cast-ai-cloud-optimization-analysis-finds-companies-overspend-by-60-percent-due-to-overprovisioning-containerized-applications
4. Atlassian. Error budget: definition and examples. https://www.atlassian.com/incident-management/kpis/error-budget
5. Kubecost. Kubernetes Resource Optimization. https://www.kubecost.com/kubernetes-cost-optimization/kubernetes-resource-optimization/
6. AWS Cloud Financial Management Blog. Putting AWS re:Invent 2021 cost optimization announcements into practice. https://aws.amazon.com/blogs/aws-cloud-financial-management/putting-aws-reinvent-2021-cost-optimization-announcements-into-practice
7. AWS Architecture Blog. Overview of data transfer costs for common architectures. https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures
8. AWS Architecture Blog. Overview of data transfer costs for common architectures – same-AZ vs multi-AZ. https://aws.amazon.com/blogs/architecture/overview-of-data-transfer-costs-for-common-architectures/#:~:text=Data%20transfer%20within%20the%20same,deploy%20in%20multiple%20Availability%20Zones
9. Kubecost. Kubernetes Resource Optimization — Key concepts. https://www.kubecost.com/kubernetes-cost-optimization/kubernetes-resource-optimization/#:~:text=Summary%20of%20key%20Kubernetes%20resource,optimization%20concepts