【FinOps】データドリブンな意思決定を目指して

The SRE Backlog: 蔵出し事例共有会
https://layerx.connpass.com/event/394351/

Transcript

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