💵

ヌーラボにおける Cloud FinOps の取り組み

2024/12/12に公開

みなさん、ヌーラボの松浦です。
最近は娘の幼稚園の送り迎えをしながら、ママ友とのお付き合いに慣れず、悪戦苦闘する日々を過ごしています。
さて、2024年10月よりヌーラボでの役割が変わり、現在はReliability Engineering部の部長として、部門メンバーと共に顧客体験と開発者体験の継続的な向上に向けた改善に取り組んでいます。

今回は、「ヌーラボブログリレー2024」の一環として、ヌーラボでのCloud FinOpsへの取り組みについてご紹介いたします。

alt_text

※文中の Cloud FinOps は社内での取り組みの命名として使っているものになります。FinOps のみの表記は引用元に準拠しています。

Cloud FinOps 始めるまでの経緯

FinOps is everyone’s job.
これは、FinOps X ‘24のキーノートでFinOps FoundationのJ.R. Storment氏が登壇中にスライドで使用した言葉であり、重要なテーマの中でも特に印象に残った言葉でした。他にも、FinOpsが過去1年間でどのように進化してきたのかについて、次の6つの重要なテーマを含めて説明されているので、気になる方はぜひ動画を確認してみてください。

  • FinOps is everyone’s job(FinOpsは全員の仕事である)
  • Cost-aware product decisions(設計の初期段階からコストを意識した意思決定を)
  • Beyond public cloud(パブリッククラウドの枠を超えて)
  • Carbon-aware FinOps(カーボンも意識したFinOps)
  • FinOps your AI(AIへFinOpsを、AIをFinOpsへ)
  • Change is constant(常に変化していて終わりはない)

ヌーラボではコスト意識を重要視していますが、コストへの意識に人やチーム間でばらつきがあるという課題を抱えていると考えています。

そのため、2024年4月から一部の部門メンバーとともに、ワーキンググループとしてCloud FinOpsの取り組みを小規模ながら開始しています。

alt_text

※2024年8月に Japan FinOps Meetup #2 があり、そちらに参加して FinOps Foundation のJ.R. Storment氏のキーノートを聞いてきました。

Cloud FinOpsのワーキンググループで議論を重ね、まずは情報収集から取り組みを開始しました。いくつかの情報を参考にしましたが、特にGoogleのブログをよく読み、「Cloud FinOpsチームを構築する際に考慮すべき5つの重要事項」を重点的に押さえました。その上で、「現場からのFinOps: FinOpsロードマップを構築する方法」を参考にしながら、Cloud FinOpsの取り組みを進めることにしました。

※ヌーラボではAWSを主に使用していますが、Googleの記事を参考にしています。同様の仕組みがAWSにもあるため、引用元の内容を随時読み替えながら活用しています。

ステークホルダーを定義する

ステークホルダーの出発点としては、以下の分野から2~3人の個人を選ぶことが推奨されていますが、ヌーラボにはステークホルダーになりうる人材が揃っています。Cloud FinOpsの取り組みは会社全体での取り組みとして、組織全体にフローとして流れる形を目指すことが重要だと考えています。そのためにも現状把握が必要であり、まずは社内のステークホルダー候補を特定する段階を完了し、次のステップへ進んでいます。

  • FinOps / CCoE(存在する場合)
  • エンジニアリング
  • プラットフォーム
  • ビジネス
  • 財務

Cloud FinOps憲章の作成

事前にやったこと

ワーキンググループでの検討を進める中で、まずはFinOpsの理解に時間を割き、議論を深めました。他でも指摘されているように、FinOpsの目的は単なるコスト最適化ではありません。早期に適切なプラクティスを導入することで、大きな恩恵を得られると考えています。

特に、以下の点が重要であると確認しました

  • ツールの選定・整備
  • 組織体制・文化の構築
  • 継続的な運用の確立

また、単にコストを削減するのではなく、ビジネス価値を最大化するためには「どこに投資すればよいのか」を把握する必要があります。Cloud FinOps文化を確立することは大きな目標であり、その実現に向けて「Why(目的)」を明確にし、ステークホルダーを巻き込む重要性を再確認しました。

さらに、現在Reliability Engineering部がクラウドの利用料金を一手に担っている状況から脱却し、アカウンタビリティを適切に分散させる仕組みが必要であるという意見も議論されました。

様々な議論を重ねた結果、以下の内容でCloud FinOps憲章を策定しました。


目標

ヌーラボにおける Cloud FinOps 文化の確立を行う

  • クラウドコスト管理の透明性を高め、リアルタイムで全員がアクセスできるコスト情報を提供する。
  • クラウドコストを最小限に抑えるよりもビジネス価値の向上を優先するコスト意識を重要視する文化を育成する。
  • クラウドテクノロジを使用してビジネス価値を加速し、推進するためのアカウンタビリティと部門間のコラボレーションの文化を育成する。
  • 継続的な学習と改善を奨励し、最新のベストプラクティスを取り入れる文化を育む。

目的

  1. ビジネス価値の最大化
    1. クラウドサービスのコストを適切に管理し、無駄を排除することでビジネス価値を最大化する。
    2. コスト削減だけでなく、効果的な投資を行い、全体の価値を高める。
  2. 迅速なデリバリーの支援
    3. コスト管理を通じてリソースの最適な配置を行い、プロジェクトのデリバリー速度を向上させる。
    4. 信頼性と拡張性を確保し、ビジネスニーズに迅速に対応できる環境を提供する。
  3. 財務上のアカウンタビリティの確立
    5. クラウドコストに対する明確なアカウンタビリティを確立し、各チームがコスト管理の責任を持つ。
    6. 透明性を確保し、経営層やステークホルダーに対して信頼性のある財務報告を提供する。
  4. 継続的な改善とイノベーションの促進
    7. 定期的なレビューとフィードバックを通じて、コスト管理プロセスを継続的に改善する。
    8. 新しい技術やツールを評価し、メリット・デメリットを考慮した上で導入し、クラウドコスト管理の効率を高める。
  5. 統一されたアプローチの導入
    9. 組織全体で統一されたFinOpsの指標やツールを活用し、標準化されたアプローチを確立する。
    10. 各チームが同じフレームワーク内でコスト管理を行い、整合性を保つ。

成熟度モデルでの評価

現場からのFinOps: FinOpsロードマップを構築する方法」に記載されている「ステップ3: 7つの中核能力に照らして評価する」を活用して評価を行いました。事前の予想では、ほとんどがCrawlだと思っていましたが、実際に評価してみると、意外にもWalkの状態が多いという印象を受けました。

※ChatGPTを使って日本語に翻訳しています。

Crawl Walk Run 現在の位置
費用の割り当て クラウドコストの割り当ては消費計算なしで行われ、固定費計算(例: 売上/従業員数)に基づいており、実際に事業のどの分野がクラウドを利用しているかは反映されていない。 組織全体で包括的な「ショーバック」を実現。チームや部門がクラウドの利用状況を確認できるよう自動化されているが、一部のクラウドコストは未割り当てのまま。 共有リソースを含むクラウドコストのほぼ100%が透明性を持って割り当てられており、財務責任を促進。違反は迅速に是正される。 Walk
報告 専用のレポートがなく、支出報告は請求書に依存している。多くの個人がコンソールレポートへのアクセスを持たない。 主要なクラウド利用者およびリーダーシップ向けにターゲットコストレポートが存在し、自動化されている。クラウドを利用する全てのユーザーがリアルタイムに近い形で支出を確認できるようにすることで、レポートの利用率が向上。 クラウドの全ユーザー向けにターゲットレポートが提供され、KPIを取り入れてチームがコスト意識を持つように促す。自動化されており、クラウド支出に関する単一の信頼できる情報源が確立され、レポートのカスタマイズも容易。 Walk
料金の効率 Google Cloud の割引の利用は極めて限定的。 Google Cloud の割引を活用するための戦略が存在し、潜在的な節約効果が大きい主要プロジェクトで利用されている。この取り組みは主に中央チームによって推進される場合が多い。 組織全体で割引が包括的に活用されている。エンジニアリング、財務、FinOps チーム間で割引の活用方法について認識が共有され、ワークロードチームが促されることなく割引を実装している。 Walk
アーキテクチャの効率 移行や運用中のワークロードにおいて、コスト効率が考慮されていない(例: 再構築や PaaS サービスのコスト効率的な利用の未検討)。 コストを意識したアーキテクチャを通じて効率化が定義されており、ワークロードタイプや特定の製品に基づいた明確な基準が存在。 コストを意識したアーキテクチャ設計パターンが一連の基準として定義され、エンジニアリングチームが組織全体で最適化を促されることなく実施している。 Crawl
トレーニングとスキル習得 FinOps 実践に関するスキル向上のための組織的な取り組みがない。 費用の責任と FinOps 実践に関するトレーニングが存在し、組織戦略に基づいている。知識バンクや定期的なスキルトレーニングセッションを通じて提供される。 コミュニティイベントや正式なスキルトレーニングコースを含むトレーニングが整備され、個人が自己学習の責任を広く負い、チーム間でベストプラクティスを自主的に共有。外部組織(例: FinOps Foundation)にも貢献している場合がある。 Crawl
インセンティブの提供 コスト削減の成果を追跡したり祝ったりすることはなく、コストを積極的に考慮するチームへの注目もされていない。 コスト/価値の最適化成果を奨励・報奨する戦略が存在し、一部の目標/OKR が設定され、主要な成功事例が祝われている。 成果が広く認知され、チームや個人の貢献が評価されている。成功を祝う文化が確立されており、それは指導層によるものだけでなく、従業員自身によっても行われている。成果は広く可視化され、具体的な報酬にも繋がっている。 Crawl
アカウンタビリティ クラウド支出の責任文化が存在しない。 大半のワークロードチームは、クラウド利用が事業に与える財務的影響を理解しているが、コスト意識を促進する責任は主に中央チームに依存している。 クラウド支出を最大限に活用することが組織全体の責任と見なされており、従業員の行動や意思決定に反映されている(常にコストを意識した意思決定を行う)。 Walk

現在進めていること

成熟度モデルでの評価を終えて7つの項目のうち何から重要視するか決めました。以下の順番で取り組んでいくことを決めています。

  • 報告
  • アカウンタビリティ
  • 費用の割り当て
  • アーキテクチャの効率
  • 料金の効率
  • トレーニングとスキル習得
  • インセンティブの提供

直近では報告の部分から取り組みを進めていますが、現在は各プロダクトで異なる方法で行われている予算管理の統一にも取り組んでいます。

これからのCloud FinOpsの取組みで大事にしたいこと

成熟度モデルを参考にしながら現在の状況を確認し、何に取り組むべきかをチェックしつつ進めていく方針です。FinOpsの本質は文化の構築にあります。たとえば、現状の評価を実施すると多くの課題が見つかるかもしれませんが、外部に委託すると短期的な成果は得られる一方で、内部メンバーが学習機会を失う可能性があります。

私たちはAWSとエンタープライズ契約を結んでいるため、AWSにしっかり相談しながら、内部メンバーの成長につながる取り組みを進めていきたいと考えています。その結果、「ヌーラボにおけるCloud FinOps文化の確立」を目指します。

参考資料

Discussion