TROCCOで始めるクラウドコストを民主化するためのFinOps

ゆるSRE勉強会 #16 - connpass
https://yuru-sre.connpass.com/event/388731/

Transcript

1. TROCCOで始める クラウドコストを民主化するためのFinOps 2026.05.29 ゆるSRE勉強会 #16 Hiroki Takatsuka (@tk3fftk)
2. Hiroki Takatsuka @tk3fftk primeNumber (2022 〜 ) • TROCCO / COMETA SRE, Engineering Manager • Security Team ⽴ち上げ → 兼務メンバー • Corporate SRE ⽴ち上げ 最近はFinOpsとか ヤフー株式会社 (2016 〜 2022) • CI/CD プラットフォーム Screwdriver.cd の SRE, Engineering Manager 猫はアルくんです、かわいいですね。 今年の1⽉に兵庫県⻄宮市に引っ越しました🚅 関⻄SREコミュニティ⽴ち上げ企画中🚀
3. AGENDA 3 1. FinOpsについて 2. FOCUSについて 3. pNにおけるTROCCOを用いたFinOpsデータパイプラインの実装 4. まとめとか宣伝とか (今日の話はSRE NEXT CfP落選ネタ圧縮版です🐧)
4. 4 FinOpsについて
5. 知ってるようで知らない「FinOps」とは FinOps Foundation による定義 (訳) FinOpsとは、エンジニアリング、ファイナンス、ビジネスの各チームが連携することで、 テクノロジーのビジネス価値を最大化し、データに基づくタイムリーな意思決定を可能にし、 テクノロジー投資に対する説明責任を確立するためのフレームワークであり、文化的な実践 語源 Finance + DevOps = FinOps ビジネスとエンジニアリングの コミュニケーションと協働を 強調した混成語 ENGINEERING 速度・コスト・品 質のトレードオフ を意識した設計と 運用 FINANCE テクノロジー投資 の可視化とアカウ ンタビリティ(説明 責任)の確立 BUSINESS 投資先とタイミン グを判断する経営 レベルの意思決定 FinOpsの目的はコスト削減ではなく、テクノロジーへの投資から最大の価値を引き出し、効率的な成長を駆動すること 出典：FinOps Foundation, What is FinOps? 5
6. 6 FinOps Frameworkの曼荼羅みたいなやつ What is FinOps?
7. 7 • 各チームは協力する必要がある • 意思決定はクラウドのビジネス価値に基づいて行う • すべての人が自分のクラウド使用量に当事者意識を持つ • FinOpsのレポートはアクセスしやすくタイムリーであるべき • 組織横断の専門チームが中心となりFinOpsを推進する • クラウドの変動費モデルを活用する FinOpsの6原則 FinOps Principles より(訳は クラウドFinOps 第2版 より)
8. FinOpsの3つのフェーズ Inform → Optimize → Operate の3つのフェーズを反復的に行う サイクルを繰り返すたびに精度と効果を高めていく (ここはアジャイルっぽいね) 01 PHASE Inform 可視化と按分 クラウド支出を可視化し、責任 部門ごとに按分する。意思決定 の前提となる「見える化」 02 PHASE Optimize 最適化 可視化されたデータをもとに、 レートと使用量の両面から無駄 を取り除きコスト効率を高める 03 PHASE Operate 継続的運用 意思決定とアクションを組織の 運用プロセスに組み込み、ビジ ネス目標と整合させ続ける 出典：FinOps Foundation, FinOps Framework — Phases 8
9. 9 primeNumberではFinOpsをどう捉えているか • FinOpsは「何にいくらかかっているかを可視化し、それをもとにステークホルダーと ともに意思決定や改善を進めていくための取り組み 」という解釈をした ◦ コスト削減 == FinOpsではない (減らせる部分を減らすのはとてもだいじ) ◦ 現場の担当者が自分たちでコストというデータを意思決定や説明に利用できる状態にできる のが理想だが、まずは推進者 (SREチーム) がガッとやる • 社内ではFinOpsを「クラウドコストを民主化する」と言い換えて推進していた
10. 10 Q. FinOpsって大企業がやるやつで、pNの規模だといらんのでは？ スタートアップでも、というかスタートアップだからこそやるべきと感じた • 比較的資本が限られているので、無駄を減らしつつ効果的に投入する必要がある • 意思決定のためのデータを得るサイクルが請求書ベースでは遅いかつ荒くないか？ ◦ 例えば、AWSなら1ヶ月ごと/アカウントごとのレベルでしか見れない • 「お金」は業種問わず普遍的かつ定量的な共通言語になる
11. 11 Q. なんでSREがFinOpsをやるんですか？ SRE 信頼性とコスト(開発リソース)のバランス コスト (開発リソース)をかければ信頼性は上げら れるが、どこまでかけるかの基準が必要 👉 SLOを定義し、エラーバジェットで 機能開発と信頼性向上のバランスを取る 開発リソースについては、主にプロダクトや開発 組織とコミュニケーションをとる FinOps 信頼性とコスト(お金)のバランス コスト (お金) をかければ信頼性は上げられる(場合 がある)が、どこまでかけるかの基準が必要 👉 FinOpsで可視化して議論し、予算(バ ジェット)を確保してバランスを取る お金については、プロダクトや開発組織だけでな く、経営層・経営企画層とコミュニケーションす るケースもあるはず 加えて、クラウドコストを起点に、SREがビジネスの意思決定に関わっていく ビジネス側との強調を深めるための取り組みのひとつにできるのではないか？ SREこそFinOpsをやるべき、SREプラクティスとFinOpsの類似性があるのではないか
12. 12 • FinOpsにおいて、まず取り組むべきはInformフェーズ ◦ 「現在地を知る」つまり可観測性の確保 (いつもの一番下のヤツだね！) • Informフェーズは、データエンジニアリングの概念が適用できる 1. ステークホルダーを巻き込み、見るべきデータを選定する 2. (コスト)データを集めて加工する 3. データを可視化してステークホルダーが見えるところに置く • つまり、ツールとしてはModern Data Stackが利用できる ◦ pNにおいては、TROCCOやdbt、BigQuery、Data Studioなど Modern Data Stack: データを収集、保存、処理、分析するためのクラウドベースのツールと技術群およびそのアーキテクチャ思想 「方向性と使える道具は分かった、でもデータモデリングとか経験ないよ」 👉 FinOps Foundationで提唱されているFOCUSという仕様がある FinOpsとデータエンジニアリング SRE本 Part III. Practicesより
13. 13 FOCUSについて
14. Copyright 2019-2025 FinOps Foundation – All rights reserved FinOps Open Cost and Usage Specification Intro to FinOps 2026 より引用
15. 15 • ベンダーごとにバラバラなコストデータを共通の形式で扱えるようにする標準仕様 ◦ Open hogehoge のFinOps版のようなイメージ • FOCUS v1.3では13 + 65、v1.2では57のカラムから構成される ◦ こんなかんじのカラムがあるよ👉 • GitLab, Zoom, Heinekenなどでも採用されている FOCUS (Finops Open Cost & Usage Specification) FOCUS Column Library FOCUS & GitLab: What is FOCUS, and How to Adopt It
16. 16 ベンダー各社がFOCUSへの対応を行っている https://data.finops.org/wp-content/uploads/2026/02/FinOps-Foundation-State-of-FinOps-2026-Summit-Slides.pdf
17. 17 primeNumberにおけるTROCCOを用いた FinOpsデータパイプラインの実装
18. 18 1. ステークホルダーとの期待値すり合わせ ◦ PdM, VPoE, CXO, 経営企画とダッシュボードのモックを元にすり合わせ ◦ 結果として利用コストだけでなく「売上との対比が必須」というFBをもらった ▪ 売上データってどこから取ればいい？ → 経営企画の方から売上管理データのレクチャーをもらう 2. 実装 (詳細は後述) ◦ TROCCO, dbt, BigQuery, Data Studio, Terraformを利用して構築 ◦ AWSが対応しているFOCUS v1.2にすべて合わせる ◦ 事業部やプロダクトとデータを紐づけるためのデータ管理 3. 展開 ◦ ステークホルダー向けにダッシュボードの定期メール配信 ◦ 開発組織向けには開発定例で持ち回りで確認してもらう枠を設けさせてもらった primeNumberにおけるFinOps実践の流れ
19. 19 点在するデータの「統合」を自動化。 「統合」を軸にデータ基盤の構築や運用を支援するSaaSプロダクト。 TROCCOとは データをビジネスに活用するまでのステップ © primeNumber Inc. primeNumber 会社説明資料/primeNumber-introduction より
20. 20 TROCCOはデータ統合工程の大半を自動化 従来、データエンジニアが手動でおこなっていたデータ統合の工程をTROCCOで 自動化することにより、企業は、迅速に蓄積や可視化といったデータ活用の次フェーズへの移行が 可能になります。 業務・サービス 要件確認 データソース仕様 調査・学習 データソース選定 (入力テーブル・ファイル・ API等) カラム内容・ 仕様確認 サンプルチェック 認証情報取得 セキュリティ・ パフォーマンス要件確認 出力結果・エラーなど 通知監視 ETL/ELTシステム 設計・開発・検証 サーバーなど 環境構築 実行 ジョブ実装・ スケジューリング 分析データマート生成 サーバーメンテナンス 出力データ確認 （異常検知） BIなどのデータ更新 ETL/ELTメンテナンス (APIバージョンアップ・列追加など ) 統合後データ活用 オリジナルワークフロー 機能を提供 セキュアでスケーラブルな 環境を標準提供 CSによる エラーハンドリングサポート 高水準のSLAを提供 自動更新・自動スキーマ追従 Googleアカウントなどによる 簡単・セキュアな認証 データ統合工程詳細 TROCCO®が自動化できる工程 © primeNumber Inc. primeNumber 会社説明資料/primeNumber-introduction より
21. © primeNumber Inc. 21 TROCCOの機能スタック 運用支援 機能 データ転送機能 (use Embulk) Transform系機能 (スクラッチ & use dbt) ワークフロー機能 (スクラッチ) 日夜動き続ける①ジョブ系の機能と、その②管理を支える機能に大別 2 1 PaaSとSaaSの境目で信頼性と開発速度を両立する 〜TROCCO®のこれまでとこれから〜 より
22. 22 primeNumberにおけるFinOps実践の流れ 1. ステークホルダーとの期待値すり合わせ ◦ PdM, VPoE, CXO, 経営企画とダッシュボードのモックを元にすり合わせ ◦ 結果として利用コストだけでなく「売上との対比が必須」というFBをもらった ▪ 売上データってどこから取ればいい？ → 経営企画の方から売上管理データのレクチャーをもらう 2. 実装 (詳細は後述) ◦ TROCCO, dbt, BigQuery, Data Studio, Terraformを利用して構築 ◦ AWSが対応しているFOCUS v1.2にすべて合わせる ◦ 事業部やプロダクトとデータを紐づけるためのデータ管理 3. 展開 ◦ ステークホルダー向けにダッシュボードの定期メール配信 ◦ 開発組織向けには開発定例で持ち回りで確認してもらう枠を設けさせてもらった
23. 23 FinOpsデータパイプライン実装 (全体像)
24. 24 • AWS(コストとRI/SP), GitHub, Snowflake, Databricks + 売上データが初回の対象 ◦ Snoflake, Databricksに関しては利用は少ないもののコスト課題が出たため再発防止のため • AWSが公式にFOCUS v1.2に対応しているため、そこに合わせてv1.2を採用することに決定 ◦ FOCUS 1.2 with AWS columns - AWS Data Exports ▪ 微妙に定義から外れているデータがあり加工が必要だった😇 • 売上データはエクセルをGASで加工したスプシをBigQueryの外部テーブルとした ◦ これがまた結構苦労したやつなんですが、時間の都合上割愛 FinOpsデータパイプライン実装 (Data Source)
25. 25 TROCCOで各種Data SourceからBigQueryに転送するジョブとワークフローを定義 • 転送元S3(AWS FOCUS v1.2), 転送元Snowflake, 転送元Databricksを利用 • 一部 TROCCOのカスタムコネクタ (REST APIで独自コネクタを作れる) を利用 ◦ GitHub (TROCCOにGraphQLコネクタはあるがREST APIのコネクタはなかった😭) ◦ AWS RI/SPに関してはLambda + API GWを構築して取得 FinOpsデータパイプライン実装 (Rawデータ取得)
26. 26 dbtでFOCUSへの変換を定義し、TROCCO上で実行 (dbt: Data Build Tool, データ変換をコードで記述できる) • SCD Type 2対応可能 (TROCCOも最近対応したけど使えないケースだった😭) • AIとの相性の良さ ◦ dbtに慣れてなくてもdbtベストプラクティスを参照しながら変換コードが書ける ◦ データ品質テストの作成 with AI ▪ 変換したデータに対して、型システム外のフォーマットや値に関するテストが書ける ▪ FOCUSの定義から書け、かつ各Providerで使い回せるテストになる FinOpsデータパイプライン実装 (FOCUSへの変換)
27. 27 FOCUSのカラム定義 -> generic testの例 FOCUS Specification v1.2
28. 28 • Data Studio (旧Looker Studio) でダッシュボード作成 • 表現力が足りないものはカスタムクエリで頑張る ◦ COMETA AIを使って作成 FinOpsデータパイプライン実装 (可視化)
29. 29 • Databricksのコスト圧縮 ◦ Databricksなんもわからんけど、使ってなさそうなリソースの存在に気づいて消せた • 経理チームからのフィードバック FinOpsをやってみた成果
30. 30 👍 pros • データモデリングが不要になる • 分析クエリの共通化や転用が容易 ◦ BI上でデータソースだけ切り替えればそのままグラフ化できる ◦ 適切なデータさえ入っていれば、公式のクエリ集にあるクエリもそのまま使える 😭 cons • かなりの数のカラムを用意しデータを入れる必要があるが、全部は使わない ◦ SaaSによってはデータがうまく用意できない可能性もある • 対応しているベンダーが少ない、またはFOCUS Versionが古い • FOCUS Version追従が結構つらそう FOCUS を使ってみて感じた pros/cons
31. 31 まとめとか宣伝とか
32. 32 • FinOpsの目的はコスト削減ではなく、テクノロジーへの投資から最大の価値を引き 出し、効率的な成長を駆動すること • SREがSLOで信頼性と開発リソースのバランスを取るのと同じ構造で、信頼性とコ ストのバランスを議論できるよう、FinOpsにも取り組むべき • FOCUSを使えばデータモデリング不要、分析クエリも共通化できる • TROCCOとdbtを使えば、データ転送とデータ加工をマネージドな環境で動かせる し、AIを活用してデータパイプラインを構築できる まとめ
33. 33 • クラウドFinOps 第2版 ◦ 日本語で網羅的に読める書籍 • What is FinOps? ◦ 公式ドキュメント • State of FinOps 2026 Report ◦ FinOpsの現在地的なやつ • FinOps Foundation「FinOps認定プラクティショ ナー」認定試験＋トレーニングコース日本語版の 提供を開始 ◦ 最近日本語で受けられるようになったぽい FYI: FinOpsについてもっと体系的に知りたい場合は
34. 34 宣伝: TROCCO、無料トライアル + フリープランあります！