このポストについて
書籍『クラウドFinOps 第2版』を読んだところ、FinOps にデータマネジメントやデータエンジニアリングに深く関連する内容があるということがわかったのでまとめてみる。
書籍について
2025年3月に出版。
ちなみに原著の初版は2019年、第2版は2023年。
タイトルのとおり FinOps (後述) について書かれた書籍となっている。
著者は両名とも FinOps Foundation の関係者であり、本文中にも随所に FinOps Foundation についての記載が出てくる。
私はデータエンジニア、ソフトウェアエンジニアとして日々 AWS その他のクラウドサービスを利用している。
クラウドサービス上に例えばデータ基盤等を構築し、ビジネス上の価値を提供している。
その一方でクラウドを使うということは料金的な意味でのコストがかかるということでもある。
もちろん支払うコストは少ない方がいい。
それは分かるのだが、それ以上のクラウドコストについての体系的な考え方を持ち合わせていなかった。
毎日それなりの額を使ってるのにね。
というのが本書を読もうと思った理由だった。
FinOps とは
定義
これを書いている2025年8月現在における FinOps Foundation での定義は以下のようになっている。1
“FinOps is an operational framework and cultural practice which maximizes the business value of cloud and technology, enables timely data-driven decision making, and creates financial accountability through collaboration between engineering, finance, and business teams.”
(訳)
“FinOpsは、クラウドとテクノロジーのビジネス価値を最大化し、データ駆動型の意思決定を迅速に行うことを可能にし、エンジニアリング、財務、ビジネスチーム間の協業を通じて財務的な責任を確立する、運用フレームワークおよび文化的な実践です”
基本原則
また FinOps には経験則から得られた 基本原則 がある。
- 各チームは協力する必要がある
- 事業価値が技術的な意思決定を駆動する
- すべての人が自分の技術利用にオーナーシップを持つ
- FinOps のデータはアクセスしやすく、タイムリーかつ正確であるべき
- FinOps は中央集権的に実施されるべき
- クラウドの変動費モデルを活用する
各チームは協力する必要がある
FinOps は技術レイヤーだけの話ではなく、組織全体を巻き込む文化的な変革活動。
財務、技術、ビジネスの各部門や経営層が協力し合い、部門横断的な連携が不可欠となる。
事業価値が技術的な意思決定を駆動する
本書を読む前は FinOps というと節約テクのようなイメージがあったがそうではなかった。
コスト削減だけではなく、クラウド支出から最大のビジネス価値を引き出すことを目的にしている。
したがってビジネス上のメリットがある場合はあえて高いコストを払う選択をすることも許容されている。
すべての人が自分の技術利用にオーナーシップを持つ
クラウドを使う各チームは支出とそこから得られる価値に責任を持つ。
エンジニアチームはコスト配賦によりクラウドの利用と支出について財務面の説明責任とアーキテクチャの決定権を持つ。
FinOps のデータはアクセスしやすく、タイムリーかつ正確であるべき
データ駆動で意思決定を行うのが FinOps の核と言える。
例えば各チームにおいて near real time にコストが分かるとプリウス効果 2 により、エンジニアに良い行動変化が促されるらしい。
月次や四半期単位だと遅い。
FinOps は中央集権的に実施されるべき
FinOps の推進には組織横断の FinOps チームが必要。
財務と技術の部門間の橋渡し役を担い、FinOps 文化の浸透をリードする。
コミットメントベースの割引 3 の購入、レポートやコスト削減のための推奨事項の提供は中央 FinOps チームが行うことになる。
クラウドの変動費モデルを活用する
クラウドの変動費モデルはリスクではなく価値提供の機会と見る。
クラウドコストに対する随時の予測、計画、予算確保などを行う。
クラウドの支出は 使用量 × 料金 4 の単純な公式で表される。
クラウドの支出を最適化するために使用量は各チームが不要なリソースの停止やダウンサイジングなどで削減し、時間・リソースあたりの料金は中央の FinOps チームがコミットメント割引などで削減する。
データマネジメント、データエンジニアリングとの関連性
本書を読んでデータエンジニアはアプリケーションエンジニア等より FinOps との関連があると思った。
データエンジニア目線で見た FinOps とデータマネジメント、データエンジニアリングとの関連性について考えてみる。
データ領域における FinOps の導入
データ領域、例えばデータ基盤の開発・運用についてもクラウドのコストがかかる。
データ基盤は組織においても扱うデータの規模が大きく、少なくないコストがかかることも多い。
よって当然本書に書かれているような FinOps の文化や運用に組み込まれて実践した方がいい。
例えばコスト最適化について考えてみる。
Databricks, Snowflake 等で構築されるモダンなデータ基盤にかかるクラウドコストとしては、データ保存のストレージコストと ELT などのコンピュートコストが大きなところだろう。
AWS 上に構築された Databricks 環境であれば次のようなコスト最適化が考えられる。
- 使用量の削減
- ストレージコスト
- データライフサイクルにおける削除条件を定義し、クラウドストレージ (S3) から定期的に不要となったデータを削除する
- データの圧縮形式を検討する
- コンピュートコスト
- 現在使用されていないデータの更新を停止する
- SQL のワークロードには SQL に最適化された SQL warehouse を使用する
- 数秒で起動・スケールアップできる (= 起動のための時間に料金がかからない) serverless SQL warehouse 等を利用する
- ストレージコスト
- 料金の削減
- ストレージコスト
- すぐに参照されることのない古いデータを S3 Glacier Deep Archive などのより安価なストレージクラスにアーカイブする 5
- コンピュートコスト
- serverless のコンピュートが使えない場合は spot instance やコミットメント割引の利用を検討する
- ストレージコスト
コスト最適化のベストプラクティス | Databricks Documentation も読んでおきたい。
クラウド請求データの処理
FinOps のフェーズによってクラウド請求データをどこから取得するかが異なる。
初期においてはクラウド事業者から送られてくる請求明細書や AWS Cost Explorer 等のネイティブツールを見ていればよいが、高度な FinOps 運用をするためにはより詳細で粒度が小さい請求データが必要となる。
例えば AWS では CUR (Cost and User Report) として詳細な請求データが提供されている。
大規模にクラウドを利用している組織では月間数十億行になることもあるとのこと。
FinOps 運用ではこれを near real time で処理し、各チームが閲覧するレポートにしたい。
これは正にデータ基盤におけるデータパイプラインの処理ということになり、いわゆる一般的なデータパイプラインの処理として当てはめることができるだろう。
当然ここではデータ品質や BI 等の要素も考えることになる。
データ品質が悪いとエンジニアはレポートを信用できなくなり、FinOps が浸透しなくなってしまう。
ただし本書では FinOps 導入初期においては自前でデータ処理するよりも FinOps 系のツールやサービスなど third party 製品や OSS 等を使用することを推奨している。
自前で FinOps データパイプラインを実装するのは、ある程度 FinOps にこなれてからがいい。
(自前で実装するとたぶん ELT のクエリは複雑になる)
データマネジメントとの類似点
FinOps は組織の文化的変革であり、その実装とプロセスには経営層の賛同が必要とのことである。
DMBOK においてデータマネジメントについても似たようなことが書いてあったのを思い出した。
本書の第3章「文化的転換とFinOpsチーム」や第6章「FinOpsの導入」においてどうやって組織に新しい文化をインストールするかについて書かれており、データマネジメントの導入においても参考にできそうだと思った。
例えば第6章では FinOps の成熟度ごとに経営層にどうやって説明するかについて記載されている。
まとめ
『クラウドFinOps 第2版』、読むのに時間かかったけどクラウドという常に課金される世界におけるコストについての考え方を知ることができたのは良かった。
自分たちが使っているお金のことはわかっておいた方がいい。
そしてデータエンジニアとの関わりも深そうだということがわかった。
余談だけど、データ基盤はコストセンターと見られることが多いと何かで読んだけど、例えば FinOps に絡めることで利益への貢献を訴えることもできるかもしれない。
原著が書かれた時点から FinOps の定義も基本原則も少し変更が入っているらしく、本書と FinOps Foundation のサイトを見比べると若干の違いがあることが分かる。 ↩︎
「プリウス効果」とはハイブリッドカーのプリウスに乗るとエコな運転になる効果のこと。運転席のダッシュボードでリアルタイムに現在の消費電力がわかるようになっており、運転手はそれを見て消費電力が少ない運転をするようになるらしい。 ↩︎
クラウド事業者における Savings Plan, Reserved Instance, 確約利用割引など、一定量のリソース利用料を事前コミットすることで当該リソースを通常より割り引かれた価格で利用できること。奥が深く、難しい。 ↩︎
「料金」というのは本書ではインスタンスやストレージの時間あたりの料金のこと。この記事でも本書に合わせて単に料金と呼ぶことにする。 ↩︎