フリーが乗り越えてきたFinOpsの壁〜でもまだ一合目〜

Transcript

1. フリーが乗り越えてきた FinOpsの壁〜でもまだ一合目〜 2026.3.19 Tamachi.sre #3
2. 2 北川 卓図 SRE本部 Platform部 CloudGovernanceチーム Gotanda/Osakiから来ました。 よろしくお願いします！ 経歴 • 2010年〜2023年 SIer複数社経験 ◦ VM、OracleDB、Microsoft Azure、AWS • 2024年〜2025年 化粧品メーカー CCoE ◦ FinOps、DevSecOps推進 • 2026年1月 フリー株式会社 Join ◦ FinOps推進 JAWS-UG 彩の国埼玉支部運営もしてます
3. スモールビジネスを、世界の主役に。
4. 　 電⼦稟議 経費精算 債権債務 管理 ⼈事労務 電⼦契約 固定資産 請求管理 会計 ⼯数管理 販売管理 会計‧⼈事労務‧販売管理を核とした 統合型経営プラットフォーム
5. フリーでの FinOps推進
6. 6 FinOps Principals Teams need to collaborate Business value drives technology decisions FinOps data should be accessible, timely, and accurate FinOps should be enabled centrally Take advantage of the variable cost model of the cloud Everyone takes ownership for their technology usage https://www.finops.org/framework/principles/
7. 7 FinOps推進に向けての障壁 フリーでは FinOpsを推進するにあたり以下の壁がありました ①CostExplorerの壁 ②タグ表記の揺らぎの壁 ③コストオーナーシップ醸 成の壁
8. ①CostExplorerの壁
9. 9 ここで超　問題です CostExplorerの料金はRI/SP購入前の料金 でしょうか RI/SP購入後の料金 でしょうか
10. 10 答えは、、 RI/SP購入後の料金 です
11. 11 CostExplorer運用の苦労した点 • 知りたい金額は オンデマンド料金 (RI/SP購入前)の金額 ◦ ビジネスロードマップが反映されるのは RI/SP購入前の金額 ◦ RI/SPを組織内横断で購入しているとプロジェクト間の割引率のコントロールができない ◦ RI/SP購入後の情報だとプロダクトチームが理解が追いつかない • 金額高騰の リソース名を確認 できない ◦ CostExplorerで分かるのはどの AWSサービスで、どの使用タイプで金額が増減したか ◦ リソース名やリソース ARNをグラフ表示はしてくれない • フィルタリング条件が人依存 ◦ 全ての人に一律の金額情報を提供するのが難しい 代替のサービスを用意
12. 12 対処方法 オンデマンド料金を確認 リソース名を確認 Looker Studio コストレポート
13. 13 構成イメージ図 CUR Athena コストレポート Digdag Looker Studio オンデマンド料金 確認OK リソース名 /ARN 確認OK
14. ②タグ表記の揺らぎの壁
15. 15 タグ表記の揺らぎとは あるあるかと思いますが、統制していないとこのようなタグが多発しますよね FreeeKaikei Freee_Kaikei freee-kaikei freeekaikei Freekaikei FREEE_KAIKEI FREEEKAIKEI ※タグ名は例です。
16. 16 問題点 タグ表記の揺らぎを放置していると、、、 • タグによる フィルタリングや検索が難しい • コスト管理が難しい ◦ CostExplorerなどでコストを確認する際に集計の正確性が低くなる • 自動化が難しくなる ◦ タグによる開発環境の停止など、タグによる制御を行っている場合、対象から漏れたり、機能が意図通りに動作しなく なる可能性がある • セキュリティ /コンプライアンスリスク ◦ IAMポリシーや SCPによる設定などのポリシーが適用されない可能性があり、セキュリティリスクや監査で問題になる 可能性がある • 認知負荷が高くオペレーションの悪循環 に陥る ◦ どのタグをつけてよいか不明確になり、同じプロジェクトの目についたタグをコピペすると、更に揺らぎは解消されず、 色々なタグにそこそこの量のリソースが紐づくようになる。 FinOps推進の足枷になる
17. 17 既存リソースに対する対処 CUR マッピング表 Before→Afterのタグ値を記載 Athena コストレポート Afterのタグ情報で統一して記載 • タグ命名規則を定義しドキュメントで公開 ◦ 一文字目は大文字、ハイフンやアンダーバーは使用しない、など • 命名規則に沿わない過去のタグの修正は随時実施 • タグを修正しても連続したデータとして確認できるようにマッピング表を作成
18. 18 新規リソースに対する対処 • 辞書リストによる登録を開始 ◦ 使用したいタグ情報をリポジトリ管理。プロダクトチームから PRあげてSREチームがレビュー • 辞書リストにないタグ情報は TFLintによりPolicy Check Errorを発生させるように実装 ◦ 辞書リストに載っているかの Checkを自動で行う • ただ、Errorは出すものの Errorを無視してリソースを作成することは可能にしている ◦ 全てのプロダクトに対してタグ統制が完了してないのと障害時のオペレーションを考慮
19. ③ コストオーナーシップ醸成の壁
20. 20 当初はコスト管理がチームに属人化していました プロダクトチームがクラウドコストを見ることはなく CloudGovernanceチームが仲介としてコスト確認をしている状態 財務チーム CloudGovernanceチーム プロダクトチーム 予算策定依頼 予算策定、予算見通し修正 コスト増加時の連絡、許可 コスト増加承認 実績確認 ボトルネック
21. 21 2026年より取り組んだこと ①プロダクトチームの部長クラスに、改めて AWSコスト管理移管していく説明会を開催 ② 毎月のコストレポートを確認するところから、スモールスタートで定常業務化してもらう ③ コストレポートをチーム単位でフィルタリングできるように改善
22. 22 プロダクトチームがコストを「知る」ところからスタート 財務チーム CloudGovernanceチーム プロダクトチーム 予算策定依頼 予算策定、予算見通し修正 コスト実績 定常確認 実績確認 改良・改善 コスト増加時の連絡、許可 コスト増加承認 コスト増加時の 判断材料を得る 自主的にコスト 最適化を検討
23. 23 目指す姿 理想は予算策定、予算見通し まで プロダクトチームが ストレスなく 出来るようにする！ 予算策定依頼 予算策定 予算見通し修正 財務チーム プロダクト チーム CloudGovernanceチーム 実績確認 予算管理 PLコスト確認 ブラッシュアップ 予算集計結果 連携
24. 24 FinOpsを組織に根付かせるには まだまだ課題だらけ 皆さんの知見も是非お聞かせください！
25. スモールビジネスを、世界の主役に。