FinOps（クラウドコスト最適化）

FinOpsとは何をする営みか

FinOps は、クラウド支出をエンジニアリング・財務・ビジネスの三者が共同で管理する運用文化とプロセスです。単発のコスト削減施策ではなく、「可視化（Inform）→最適化（Optimize）→運用（Operate）」を回し続ける反復ループとして定義されます（FinOps Foundationの標準的な三フェーズ）。

なぜこのループが要るのか。オンプレでは資本支出（CapEx）として事前承認・固定化されていた計算資源が、クラウドでは従量課金の運用支出（OpEx）に変わり、誰でも数クリックで支出を発生させられるようになったためです。この権限分散は俊敏性を生む一方、「誰が・何のために・いくら使ったか」を追跡する仕組みがなければ、請求は容易に制御不能になります。FinOpsはこの分散したコスト決定権に、可視性と説明責任を取り戻す枠組みです。

可視化の起点：タグ付けによるコスト配賦

FinOpsの第一関門は**コスト配賦（Cost Allocation）**です。クラウド請求書は既定では「どのサービスに」いくら使ったかしか示さず、「どのチーム・どのプロダクト・どの環境が」使ったかを答えません。これを埋めるのがタグ（AWSの場合）やラベル（GCP/Kubernetesの場合）です。

実務では最低限、次の軸でタグ付けを強制します。

必須タグの例
  cost-center   : 予算を持つ組織単位（部門・チーム）
  environment   : prod / staging / dev
  service       : プロダクト・マイクロサービス名
  owner         : 責任者またはSlackチャンネル

タグ付けが崩壊すると発生するのが**共有コスト（Shared Cost）**の問題です。マネージドNAT Gateway、共有のロードバランサ、Kubernetesのコントロールプレーンのように複数チームが相乗りする資源は、単純なタグでは1チームに帰属できません。これらは使用量に応じた按分ルール（例：転送バイト数比、Pod数比）を事前に合意し、配賦アルゴリズムとして明文化しておく必要があります。按分ルールが恣意的だと、チームは「自分のせいではない」と最適化のインセンティブを失い、FinOpsループ全体が機能不全に陥ります。

購入オプションの使い分け：オンデマンド・リザーブド・スポット

可視化ができて初めて、最適化の中心である購入オプションの選択に進めます。クラウドの計算資源は大きく3種類の価格モデルを持ちます。

リザーブド／Savings Plansは本質的に**「将来の一定使用量を先払いで約束する保険契約」です。需要予測（キャパシティモデリングで導いた基準水準）に対してコミット量を合わせ込みます。ここで過大にコミットすると、需要が予測を下回った際に使わない容量にも払い続ける**（アンダーユーティライズ）ことになり、逆に過小だと超過分がオンデマンド単価にこぼれて割引効果が薄れます。実務ではベースロードの70〜80%程度をコミットし、残りの変動分をオンデマンドやスポットで賄う「ベース＋バースト」戦略が定石です。

スポットは「中断される可能性を代償に、余剰容量を安く借りる」契約です。中断は需給ひっ迫時にクラウド事業者側の都合で発生するため、アプリケーション側が中断に耐えられる設計になっているかが採用可否を決めます。具体的には、状態を持たない、チェックポイントから再開できる、グレースフルシャットダウンで中断通知を受けて安全に離脱できる、といった性質です。クラスタオートスケーラでスポットノードプールを混在させる場合も、退避不能なポッドや状態を持つワークロードをオンデマンドノードに固定し、スポットは水平スケール可能な部分にのみ割り当てるのが安全な設計です。

コストと信頼性のトレードオフを定量化する

FinOpsが技術的に難しいのは、コスト削減がしばしば信頼性を直接毀損する形で効いてしまう点です。代表的な緊張関係を挙げます。

• 冗長度の削減：マルチAZ・マルチリージョンの複製数を減らせば費用は線形に減るが、障害時の復旧能力も同時に落ちる。
• 利用率の引き上げ：サーバーの平均利用率を上げるほど台数当たりコストは下がるが、待ち行列理論により応答時間は非線形に悪化する（キャパシティモデリングの1/(1−利用率)の関係）。
• スポットへの依存度：スポット比率を上げるほど平均コストは下がるが、同時中断（クラウド全体の需給ひっ迫時）が起きた際の可用性リスクは上がる。

このトレードオフを恣意的な判断にしないための橋渡しがエラーバジェットです。SLOとエラーバジェットで「どこまでの信頼性低下が許容範囲か」を先に数値化しておけば、コスト削減施策がバジェットを食いつぶす速度を測定でき、「削ってよい冗長度」と「削ってはいけない冗長度」を財務判断ではなく設計上の制約として線引きできます。FinOpsの意思決定は、単価だけでなく「その削減が可用性リスクとして何ポイントのエラーバジェットに相当するか」まで含めて評価する必要があります。

まとめ

• FinOpsは可視化・最適化・運用を反復するループであり、タグ付けによるコスト配賦が土台。共有コストの按分ルールを事前合意しないとインセンティブが機能しない。
• 購入オプションはリザーブド＝需要予測へのコミット保険、スポット＝中断耐性と引き換えの割引という性質の違いで使い分ける。
• コスト削減は冗長度・利用率・スポット比率のいずれを動かしても信頼性に跳ね返るため、エラーバジェットを介して定量的なトレードオフとして扱う。
• キャパシティプランニングが「足りるか」を問うのに対し、FinOpsは同じ資源配分の「買い方・払い方が最適か」を問う、補完的だが別軸の最適化である。