「FinOpsとK8s」に関連した編集部お薦め記事

Expediaがインフラ設定の“闇”を解明した方法　年間2000万ドル削減の裏側

費用60％削減も可能　クラウドの無駄を断つFinOps活用5事例

　Kubernetesのコスト管理は非常に難しい。その理由は、Kubernetes自体の複雑さにある。企業には、従来のFinOps戦略を超えた独自の最適化戦術が求められる。主な障壁は以下の通りだ。

　第一に、環境が極めて動的であること。ワークロードが常に移動し続けるためだ。リソース利用パターンの変化などに応じてアプリケーションをサーバ間で移行できる点はKubernetesの強みだが、これがコスト追跡を困難にしている。ワークロード単位の支出を把握するには、どのサーバがどのワークロードをホストし、どれだけのリソースを消費しているかをリアルタイムで特定しなければならない。

　第二に、デプロイモデルが多様である。Kubernetesの構築には大きく3つの選択肢がある。

• オンプレミスやプライベートクラウドによる自社インフラへのデプロイ
• パブリッククラウド上の仮想マシン（VM）によるセルフマネージド構成
• 「Amazon EKS」や「Azure AKS」のような完全マネージドサービスの利用

　各アーキテクチャはそれぞれコスト変数が異なる。オンプレミスではハードウェア購入という資本投資が主な検討事項だが、クラウドでは利用したインフラに対する月額料金が基本となる。料金体系が多様なので、あるデプロイモデルで有効な管理戦略が他でも通用するとは限らない。

　第三に、プロジェクトやチーム間でのリソース共有がある。FinOpsの目標は支出を特定のチームやプロジェクトにひも付けることだが、Kubernetesでは1つのクラスタを複数のチームが共有することが多いのできめ細かな追跡が難しい。ワークロードの移動やスケールアップダウンに合わせてコストを追跡するには高度な管理プロセスが必要になる。

　最後に、標準のコスト監視機能の欠如だ。KubernetesはCPUやメモリの使用量を報告できるが、それを金額としてのコストに変換する機能はネイティブでは提供していない。

FinOpsとKubernetesの乖離

　これまでKubernetesは企業のFinOps戦略で例外的な存在だった。理論上、FinOpsはあらゆるITプラットフォームの価値を最適化できる。だが実際には、クラウドベースのVMやデータベースの方が支出の管理と最適化が容易だった。

　問題はKubernetes自体の複雑さだけではない。Kubernetes向けのFinOpsツールが他のプラットフォーム向けに比べて限られている点も挙げられる。例えば、主要なパブリッククラウドは「AWS Cost Explorer」のような標準のコスト管理ツールを提供している。しかし、これらがKubernetesについて報告するのはごく基本的なデータのみだ。

KubernetesのFinOpsの失敗例

　企業が意図せず予算を浪費してしまう典型的な例は以下のようなものだ。

• ノードの過剰配置：ワークロードを支えるために必要な数を超えてノードを配置しているケース。一部のノードがアイドル状態でも企業はその全ての料金を支払わなければならない
• リソース予約の過多：コンテナで実際に必要な量よりも多くのCPUやメモリを予約しているケース。ワークロードが使っていないリソースにもコストが発生する
• 不適切なインスタンスタイプ：コスト効率の高い「リザーブドインスタンス」を活用せず、標準の従量課金制インスタンスを使い続けているケース
• レプリカ設定の問題：信頼性要件を超えて必要以上に多くのアプリケーションレプリカをデプロイしているケース。可用性は高まるが、リソースを過剰に消費する
• 未使用の永続ボリューム：すでに使われていない永続ボリューム（PV）が残っているケース。ストレージリソースを無駄にしないよう、不要になったPVは削除すべきである

Kubernetesの支出を改善するためのベストプラクティス

　Kubernetesの投資対効果（ROI）を最大化することは十分に可能だ。そのためには、専用の手法やツールを導入する必要がある。

　まずはサーバコストの削減だ。最もシンプルで影響が大きいのは、低コストなサーバへの切り替えである。クラウド環境では、長期利用を前提に割引を受けられるリザーブドインスタンスの利用が理にかなっている。また、可用性要件が低いテスト環境やAIモデルのトレーニングなどでは、大幅な割引がある「スポットインスタンス」の活用も検討に値する。

　次に、リソースの「クオータ（割り当て）」と「リミット（制限）」の見直しだ。これらは特定のリソースをワークロードに割り当て独占を防ぐための機能だが、設定が不適切だと無駄が生じる。定期的に実際の消費データと比較し、使用量よりもクオータが大幅に高い場合は調整が必要だ。

　孤立したリソースの削除も必要だ。Kubernetesは不要になった永続ボリュームなどを自動的に削除しない。コマンドラインツール「kubectl」を用いた手動監査や、自動で孤立リソースを特定する管理ツールの活用が有効だ。

　また、チームやプロジェクトごとに「ネームスペース」を分けることも推奨される。ネームスペースごとにリソース管理やコスト追跡のポリシーを適用すれば、実験的ワークロードには安価なサーバを、ミッションクリティカルな業務には高性能なノードを割り当てるといった柔軟な運用が可能になる。

　オートスケーリングの有効化も重要だ。需要の変化に応じてリソース構成を自動変更する機能には、ポッドの数を増減させる「HPA（水平ポッドオートスカラー）」、リソース割り当てを調整する「VPA（垂直ポッドオートスカラー）」、ノードを追加・削除する「クラスタオートスカラー」の3種類がある。これらを有効にすることで、リソースの割り当てと実際の使用量のバランスを適性に保つことができる。

　最後に、コスト管理ツールの導入だ。Kubernetes自体には機能がないが、オープンソースの「Kubecost」などの外部ツールがその役割を果たす。支出メトリクスを自動追跡し、設定したしきい値を超えた際に警告を発するほか、最適化のための推奨事項を提示してくれる。