Share
Embed
Slide 1
Slide 1 text
【FinOps】データドリブンな意思決定を⽬指して
The SRE Backlog: 蔵出し事例共有会
Slide 2
Slide 2 text
2
● Kaita Nakamura (@z63d_)
● 株式会社primeNumber
● SRE
● 好きな技術: コンテナ、Kubernetes
● Raycast Community Japan
● Raycast Ambassador
⾃⼰紹介
Slide 3
Slide 3 text
3
● なぜ FinOps をやるのか
● FinOps の実践のひとつとして参考になれば
○ 何から始めれば良いか分からない
○ ⾃⾝の組織にも適⽤できるかも
伝えたいこと
Slide 4
Slide 4 text
4
● FinOps とは
● なぜ FinOps をやるのか
● primeNumber における FinOps の実践
○ Inform - ゴールの確認
○ Inform - 実現⽅法の検討
○ Inform - 実装
● FOCUS に関する tips
● FinOps をはじめたことによる効果
● 今後について
アジェンダ
Slide 5
Slide 5 text
5
FinOps とは
Slide 6
Slide 6 text
6
● コスト最適化‧削減 ？
● コスト異常検知によるリスク低減 ？
● コミットメント（AWS の RI/SP など）による割引活⽤？
● コストレポート分析？
● コストを意識したアーキテクチャ設計？
● タグやラベルなどのメタデータ付与によるコスト状況可視化？
FinOps とは 🤔
Slide 7
Slide 7 text
7
FinOps
FinOps は、テクノロジーのビジネス価値を最⼤化し、
データに基づいたタイムリーな意思決定を可能にし、
エンジニアリング、財務、ビジネスチーム間のコラボレーションを通じて
財務上の説明責任を⽣み出す、
運⽤フレームワークおよび⽂化的実践です。
https://www.finops.org/framework/
翻訳 by 私
テクノロジー: Public Cloud, Data Cloud Platforms, SaaS, Data Center, AI
https://www.finops.org/framework/technology-categories/
Slide 8
Slide 8 text
8
以下を達成するためのフレームワーク‧⽂化醸成
● データドリブンな意思決定をもとにテクノロジーへの投資を⾏い、
ROI（投資利益率）を最⼤化する
○ データドリブンな意思決定: コスト‧品質‧スピード等のトレードオフにより決定
● チーム間のコラボレーションを通じて、各⾃がコストに対する
オーナーシップを持つ
○ コラボレーション: コンテキスト（各チームが持っている情報）の共有、意思決定
○ オーナーシップを持つ: いくら使っていて、それがビジネスにどう貢献しているか
説明できる状態
⾃分なりの FinOps の理解
Slide 9
Slide 9 text
9
● FinOps Scopes
● FinOps Principles
● FinOps Personas
● FinOps Phases
● FinOps Maturity Model
● FinOps Domains
● FinOps Capabilities
● Technology Categories
FinOps Framework
https://www.finops.org/framework/
Slide 10
Slide 10 text
10
FinOps Capabilities（FinOps を実現する how）に
Inform、Optimize、Operate の 3 つのフェーズを通して反復的に取り組む
● Inform（可視化）
● Optimize（最適化）
● Operate（継続的な改善）
FinOps Phases
https://www.finops.org/framework/phases/
Slide 11
Slide 11 text
11
なぜ FinOps をやるのか
Slide 12
Slide 12 text
12
コスト構造（いつ‧どこで‧何に‧いくら使っているのかなどの全体像）を
正確に把握できていない
● 複数の Public Cloud や SaaS
○ AWS, GitHub Actions など...
○ 開発している SaaS の特性上、検証環境などで利⽤している
サービスが多い
● 複数の事業
○ SaaS 提供‧コンサルなど
● 請求データの粒度‧頻度
○ 財務がコストを⽉次（請求書）で⾒ていてタイムラグがある
コスト構造の把握ができていない問題
Slide 13
Slide 13 text
13
コスト構造の可視化ができていないと、
（ROI 最⼤化のための）適切な投資ができているかの評価が難しい
なぜ primeNumber では FinOps をやるのか
ROI 最⼤化には
コスト構造を可視化して（= データドリブンな意思決定が可能な状態）、
効果的な投資‧コスト削減施策を⾏う⽅法もあると考えた
これを可能にする⼿段の1つが FinOps
※ ⼀⽅で、明確にコスト削減できる部分への⾒直しも取り組んでいる
Slide 14
Slide 14 text
14
primeNumber における FinOps の実践
Slide 15
Slide 15 text
15
コスト構造を可視化をするために、
まずは FinOps Phases の Inform に取り組む必要があると考えた
● Inform（可視化） ← 今回話すこと
● Optimize（最適化）
● Operate（継続的な改善）
FinOps 何に取り組むか
Slide 16
Slide 16 text
16
コスト構造の可視化には以下の要素が必要そう
● ベンダー横断でのコスト可視化
● 事業等のディメンション
● 細かい粒度‧⾼い頻度のデータ
各ベンダーの機能では不⾜
（使わないというわけではない）
● ベンダー横断で⾒れない
● 権限がある⼈しか⾒れない
例: AWS Cost Explorer
FinOps 具体的に何をするか
Slide 17
Slide 17 text
17
● ゴールの確認
● 実現⽅法の検討
● 実装
Inform への取り組みの流れ
Slide 18
Slide 18 text
18
Inform - ゴールの確認
Slide 19
Slide 19 text
19
コスト構造を可視化するためにダッシュボードを作成しようと考えた。
ダッシュボード作成にあたり、社内のステークホルダーとの認識合わせを実
施した。
ステークホルダーとの認識合わせ
Slide 20
Slide 20 text
20
● 各ロール（経営企画, 経理, CTO/VPoE, PdM... など）の⽬的‧関⼼事項な
どの認識合わせ
○ 何のためにどんな情報が必要か
● 何のデータがどんな粒度‧頻度で必要か
● ダッシュボードのモックによる完成イメージの共有
ステークホルダーとの認識合わせ
ダッシュボードに必要な要素
● ベンダーを横断した請求データ
○ プロダクト‧事業といったディメンションで可視化
● 売上対コスト⽐率
○ 請求データ以外にも売上データが必要
Slide 21
Slide 21 text
21
最終的に作成したダッシュボード
以下のページで構成
● 各ベンダー‧ベンダー横断のコスト
● 売上
● 売上対コスト⽐率
作成したダッシュボード
Slide 22
Slide 22 text
22
Inform - 実現⽅法の検討
Slide 23
Slide 23 text
23
ベンダーを横断した請求データ + 売上対コスト⽐率 のダッシュボード作成
以下の3ステップで実現できると考えた
1. [設計] 請求データのスキーマ
2. [実装] データ基盤の構築（請求データ取得や変換）
3. [実装] ダッシュボード作成
→ 1 に課題があった
実現までのステップ
Slide 24
Slide 24 text
24
当然だが、ベンダーごとに請求データのスキーマは異なる
例えば GitHub と Snowflake の請求データを⽐較すると...
請求データのスキーマの差分
Snowflake
● USAGE_IN_CURRENCY (請求額)
● USAGE_DATE (⽇付)
● RATING_TYPE (料⾦体系)
● SERVICE_TYPE (サービスタイプ)
● ...
GitHub
● netAmount (割引後請求額)
● grossAmount (割引前請求額)
● date (⽇付)
● product (製品名)
● ...
Slide 25
Slide 25 text
25
各ベンダーの請求データのスキーマを統⼀することで以下が実現できそう
● ベンダーを横断した請求データの可視化
○ 各ベンダーごとの分析クエリ等が不要 & 包括的な分析
○ ⼀貫したスキーマ‧分析による正確な意思決定に繋がる
● 新しいベンダーの統合
○ 毎回クエリを考える必要がない
逆に各ベンダーの請求データのスキーマが異なると実現が難しい
なぜ請求データのスキーマ設計が必要か
Slide 26
Slide 26 text
26
スキーマ設計にはデータエンジニアリングの⽂脈では
データモデリングという作業が必要だが...
● SRE チームが普段やらない作業のため難度が⾼い
○ やるとしても⼯数が必要
○ 精度⾼く⾏えるか？⼿戻りが発⽣しないか？
● ⾒たい情報が変わる‧新しいベンダーの追加などが発⽣すると、
カラムの追加などのスキーマ⾃体のメンテナンスが必要になるかも
データモデリング
Slide 27
Slide 27 text
27
ベンダー間で請求データを標準化するための仕様
https://focus.finops.org/what-is-focus/
GitLab や Zoom が採⽤している
（OpenTelemetry 的なベンダー⾮依存の標準仕様）
FOCUS
Slide 28
Slide 28 text
28
弊社では FOCUS v1.2 を使⽤しました
（AWS Data Exports が FOCUS v1.2 に対応していたため）
最新は FOCUS v1.4
FOCUS のバージョン
Slide 29
Slide 29 text
29
FOCUS 1.2 は 57 カラム
例えば、コスト系だけでも複数カラム存在する
● ListCost
○ 定価
● ContractedCost
○ 交渉による割引を反映した価格
● BilledCost
○ 請求額
● EffectiveCost
○ 前払い分（コミットメントなど）を適⽤期間で再配賦したコスト
他にも
BillingCurrency（通貨）、ChargePeriodStart（課⾦開始⽇）、ChargePeriodEnd（課⾦終了⽇）...
FOCUS カラム
Slide 30
Slide 30 text
30
FOCUS カラムへのマッピング‧適切な変換 などをする必要はあるが、
データモデリングより圧倒的に簡単にスキーマの統⼀が可能
※ マッピングは⼀例
FOCUS を使ったスキーマの統⼀
ChargePeriodStart
開始日
ChargePeriodEnd
終了日
BilledCost
請求額
ServiceCategory
サービスカテゴリー
ListCost
定価
FOCUS 1.2 Snowflake
GitHub
USAGE_IN_CURRENCY
netAmount
USAGE_DATE
RATING_TYPE
SERVICE_TYPE
grossAmount
product
date
ServiceName
サービス名
USAGE_DATE
date
product
USAGE_IN_CURRENCY
Slide 31
Slide 31 text
31
Inform - 実装
Slide 32
Slide 32 text
32
● DWH: BigQuery
○ データ格納先
● データ転送 + パイプライン構築: TROCCO
○ 各ベンダーからの請求データの転送
○ 全体のパイプライン構築
● データ変換: dbt core
○ SQL や Jinja を使った構⽂で、table に⼊っているデータを変換することが可能
○ 請求データを FOCUS へ変換
● ダッシュボード: Data Studio（旧 Looker Studio）
○ BigQuery のデータの参照
使⽤したツール
Slide 33
Slide 33 text
33
33
データ基盤の構築
Slide 34
Slide 34 text
34
データ転送 → データ変換 の流れ
データ基盤の構成（超簡略化 version）
Slide 35
Slide 35 text
35
データ転送 → データ変換 の流れ
データ基盤の構成
Slide 36
Slide 36 text
36
TROCCO を使って各ベンダーの請求データを BigQuery に転送
請求データ転送
● AWS:
Data Exports で S3 に export
→ BigQuery
● GitHub:
Billing usage API → BigQuery
Slide 37
Slide 37 text
37
dbt を使って段階的にベンダー独⾃スキーマから FOCUS スキーマへデータ変換
請求データ変換
Slide 38
Slide 38 text
38
dbt を使って各ベンダーの FOCUS データを結合
請求データ結合
Slide 39
Slide 39 text
39
Google Sheets を BigQuery の external table で参照
売上データ
Slide 40
Slide 40 text
40
40
ダッシュボード作成
Slide 41
Slide 41 text
41
Data Studio（旧 Looker Studio）で
BigQuery のデータを参照
ダッシュボード
Slide 42
Slide 42 text
42
FOCUS に関する tips
Slide 43
Slide 43 text
43
● 仕様にあるカラム以外のカスタムカラムを追加できる
● 例: x_CustomColumn
● 追加したカラム
○ 事業
○ プロダクト
○ primary key ※ 詳細後述
カスタムカラム
Slide 44
Slide 44 text
44
● FOCUS の仕様には primary key となるカラムが存在しないため、
カスタムカラムで追加する必要がある（はず）
● primary key がないと⽇々追加されるデータの差分更新などができない
surrogate key
複数のカラムをハッシュ化した unique な値を⽣成して、
primary key として扱う
https://www.getdbt.com/blog/guide-to-surrogate-key
primary key
Slide 45
Slide 45 text
45
FinOps をはじめたことによる効果
Slide 46
Slide 46 text
46
● ダッシュボードによりコスト構造が分かり、
コストについて論理的に話せる
● ダッシュボード分かりやすい
社内のフィードバック
Slide 47
Slide 47 text
47
● 週次の開発定例でダッシュボードを⾒る時間を設けた
○ “コストにオーナーシップを持つ” 状態をつくる
○ “コスト変動の要因はなんだろう” “これは不要なんじゃないか”
といった話が出るようになった
○ 実際に不要なコスト削減への動きに繋がった
● 週次でダッシュボードのレポートを配信
FinOps ⽂化醸成の取り組み
Slide 48
Slide 48 text
48
今後について
Slide 49
Slide 49 text
49
● ダッシュボードに対象のベンダーの追加
○ Google Cloud, Blacksmith など
● コストと売上の頻度が違う問題を解消
○ コストは⽇次、売上は⽉次
○ ⽉次の粒度でないと売上とコストの⽐率がいい感じに⾒れない
○ 売上の按分などが必要
● コストの粒度の細分化やドリルダウン
○ 例: プロダクトの機能ごと
● FinOps ⽂化の浸透
やりたいこと
Slide 50
Slide 50 text
50
今回の内容は FinOps の実践のひとつの例
⾃⾝の組織に適した FinOps があるはず
（DevOps の実装の⼀つが SRE であるのと似ている）
さいごに
Slide 51
Slide 51 text
Thank you!