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