成長と拡大を支える FinOps 実践記

Transcript

1. 成⻑と拡⼤を⽀える FinOps 実践記 2026/11/05@LF Japan Community Day 2026 Fukuoka 株式会社ヌーラボ ⼆橋 宣友（@futahashi）
2. ⼆橋 宣友 • Principal Engineer / AWS Alliance Lead @株式会社ヌーラボ • 技術顧問 @ホライズンテクノロジー株式会社 など • 2026 Datadog Ambassador • 2022 & 2023 APN AWS Top Engineers (Software) • 2023 Japan AWS All Certifications Engineers @futahashi 2
3. 私の役割と⽴ち位置 クラウドとオブザーバビリティを武器に現場で動く仕組みを作り組織横断の課題を解決する Product SRE FinOps Security 認証と契約の共通基盤 全社のクラウド費⽤ 全社の防御と統制 オブザーバビリティ 可視化 配賦 ログ集約 脅威検知 インシデント対応 異常検知 予算管理 構成監査 統制 コスト最適化 契約管理 SIEM 監査対応 SLO Kubernetes IaC SRE とセキュリティの現場を知る⽴場で FinOps を進める 03
4. 会社概要 会社概要 社名 株式会社ヌーラボ 設⽴ 2004年3⽉ 所在地 福岡県福岡市中央区天神⼀丁⽬11番1号 ONE FUKUOKA BLDG. 7階 従業員数 主要株主 国内拠点 海外⼦会社 207名（2026年3月31日現在、グループ全体） 橋本 正徳：1,554,245株（23.9%） 田端 辰輔：1,497,900株（23.1%） 東京事務所 Nulab USA,Inc.( ニューヨーク ) Nulab Netherlands B.V. ( アムステルダム ) 注記：Nulab Singapore Pte.Ltd.( シンガポール )社は2024年9月清算結了 Nulab USA、Nulab Netherlands B.V.は清算手続き中。 4
5. サービス概要 チームで働くすべての⼈に、コラボレーションツールを開発・提供 プロジェクト・タスク管理ツール ヌーラボサービスの セキュリティとガバナンスを強化 オンラインホワイトボードツール ワークフロー⾃動化ツー ル ✔ タスク・課題の管理 ✔ 業務をワークフロー化 ✔ リアルタイム共同編集 ✔ SAML認証によるシングルサインオン ✔ 進捗の可視化と共有 ✔ 定型業務を確実に⾃動化 ✔ 図やレイアウトによる情報共有 ✔ アカウントの⼀元管理 ✔ バージョン管理・開発連携 ✔ Backlogとシームレスに繋がる ✔ テンプレート・図形による表現 ✔ 監査ログによる利⽤状況の可視化 ✔ ナレッジ共有 ✔ 業務の流れを⾒える化・改善 ✔ チーム内外への共有 ✔ モバイル・タブレット対応
6. コミュニティからはじまったヌーラボ 始まり 今も続けていること Backlog はコミュニティで 試され⼝コミで広がった 地域に場をつくり 情熱を世界に発信する これからも地元福岡を中⼼にコミュニティと世界への貢献を続ける 06
7. FinOps とコミュニティと私 費⽤は個⼈の善意で保たれていた 課題 費⽤を⾒るかどうかはチーム次第 書籍や資格でフレームワークを学んだ 学習 『クラウド FinOps』、Framework、Certification コミュニティ コミュニティが実践知と熱量をくれた FinOps X、Japan FinOps Meetup 福岡で FinOps に取り組む⼈が⾝近な実践から学べるようにしたい 07
8. はじめに FinOps とは 08
9. FinOps とは ⽇々の実践 ⽣まれるもの 財務 事業 技術のビジネス価値の最⼤化 使った費⽤を価値につなげる 同じデータを⾒て ⽀出をタイムリーに決める 財務上の説明責任 エンジニアリング 使った⼈が費⽤を説明できる FinOps の⽬的はコスト削減でなく技術のビジネス価値を最⼤にすること 09
10. FinOps の原則 1 チームは協働する Teams need to collaborate 2 ビジネス価値が技術の判断を動かす Business value drives technology decisions 3 全員が⾃分の技術利⽤に責任を持つ Everyone takes ownership for their technology usage 4 データは誰でも⾒られ、速く、正確に FinOps data should be accessible, timely, and accurate 5 FinOps は中央チームがイネーブルする FinOps should be enabled centrally 6 クラウドの変動費モデルを活かす Take advantage of the variable cost model of the cloud FinOps Framework は 6 つの原則で実践の⽅針を⽰す 10
11. 本題 コスト最適化は誰の仕事か 11
12. コスト最適化は誰の仕事か 1 チームは協働する Teams need to collaborate 2 ビジネス価値が技術の判断を動かす Business value drives technology decisions 3 全員が⾃分の技術利⽤に責任を持つ Everyone takes ownership for their technology usage 4 データは誰でも⾒られ、速く、正確に FinOps data should be accessible, timely, and accurate 5 FinOps は中央チームがイネーブルする FinOps should be enabled centrally 6 クラウドの変動費モデルを活かす Take advantage of the variable cost model of the cloud 原則ではコスト最適化は使う⼈の仕事で中央のチームはそれを⽀える 12
13. そこで FinOps チームを組成 2024 年度まで 2025 年度以降 財務 事業 財務 横断する役がいない 事業 費⽤は個⼈の善意で保たれていた FinOps チーム （兼務・仮想） エンジニアリング エンジニアリング チーム チーム チーム チーム チーム チーム チーム チーム 横断する役を置き財務と事業とエンジニアリングをつなぐ形を⽬指した 13
14. しかしチームを作るだけでは回らない 担当チーム FinOps チーム（兼務・仮想） 構成が複雑で原因を追いにくい 調査 担当外で構成と経緯が分からない 効果と影響の調査に専⾨知識が要る 評価 効果と影響を⾒極める知⾒が⾜りない 安定稼働しているものを変えにくい 変更 変える権限がなく提案⽌まり 納期やセキュリティ対応が先に来る 時間 兼務で本業が優先になる 課題は⾒えるのに遂⾏までの負担が重く⼿が回らなかった 14
15. 役割分担の再設計 原則 3 全員が⾃分の技術利⽤に責任を持つ 担当チーム 原則 5 FinOps は中央チームがイネーブルする FinOps チーム ⾃分の費⽤に責任を持つ データと仕組みで⽀える 原因を調べる 原因を調べる 提案をまとめる 提案をまとめる 効果と影響を確かめる 効果と影響を確かめる 承認する 実施する （⼀部を代理で）実施する 判断は担当チームに残し調べて確かめるまでを FinOps チームが引き取った 15
16. 戦略の全体像 原因を追いにくい 専⾨知識が要る 1 データを横断して 2 専⾨家の知⾒を 原因を掘り下げる AI で再現する 事例 1 費⽤増の原因調査 事例 2 Graviton 移⾏の深掘り 事例 3 予算を運⽤に組み込む 4 横断の⼟台 事例 4 コストアラートのトリ アージ 事例 5 コミットメント割引 データ集約 タグ付けと統制 安定稼働を変えにくい 3 改善策の効果と影響 まで確かめる 事例 6 未使⽤リソースの削除 事例 7 ⾒込みを実測で確かめる 安全な読み書きの権限 FinOps チームが調べ切り最⼩限の負担で遂⾏につなげる 16
17. 戦略 1 データを横断して原因を掘り下げる 事例 1 費⽤増の原因調査 事例 2 Graviton 移⾏の深掘り 事例 3 予算を運⽤に組み込む 17
18. 事例 1 費⽤増の原因調査 1 請求 CloudFront の費⽤が急増 2 リソース 急増したアカウントとリソースを特定 3 メトリクス 全体の件数は横ばいで転送量だけ急増 4 ログ・トレース API 別ではお知らせ API だけ急増 5 結論 規約改定の通知で普段来ない⼈がアクセス キャッシュのないブラウザが全部を取得 請求からメトリクスとログやトレースまでつないで原因を特定した 18
19. 事例 2 Graviton 移⾏の先の最適化 ① Graviton への移⾏ 実施したこと 移⾏後の CPU 使⽤量の減少率 EKS のノードを Graviton（Arm）に移⾏ A〜D −46% 〜 −60% E・F −15% 〜 −33% G −1% ほとんど減らない 結果 全体の CPU 使⽤量 −15% 応答時間 −15% サービス別の CPU 使⽤量の内訳 A〜F G G が全体の約 2 3 を占める 最も CPU を使うサービス G では移⾏だけではほとんど減らなかった 19
20. 事例 2 Graviton 移⾏の先の最適化 ② CPU を使っている処理を深掘る API 別の CPU 時間 最も重い API の中⾝ 原因：当時の環境では SHA-512 の⾼速化設定（UseSHA512Intrinsics）が無効だった プロファイラで CPU 時間の⼤半はある API のハッシュ計算だと分かった 20
21. 事例 2 Graviton 移⾏の先の最適化 ③ 修正して計測する JVM の SHA-512 ⾼速化設定を有効化：-XX:+UseSHA512Intrinsics API の応答時間 Pod の CPU 使⽤量 EC2 の費⽤（定価・1 ⽇） 応答時間 Pod の CPU 使⽤量 ノード台数 EC2 の費⽤ −67% −45% −37% −30% 原因まで掘り切れば鉄の三⾓形は崩せる 21
22. 事例 3 経理の予算を⽇々の運⽤に組み込む 経理の予算 タイムリーな可視化と共有 エンジニアの⽇々の運⽤ 部⾨やプロダクトの予算 予算と実績と予測を同じ画⾯で⾒る 予算を超えそうなら早めに気づく ⽉初：予算を超過 ⽉末：早めの対応で軌道修正 以前 現在 ⽉ 1 回の定例で実績を振り返る 毎⽇の予測で超える前に動く ズレが⼤きくなる前に⼿を打ち予算内に着地させる 22
23. 戦略 2 専⾨家の知⾒を AI で再現する 事例 4 コストアラートのトリアージ 事例 5 コミットメント割引 23
24. 事例 4 コストアラートのトリアージ 以前：⼈が AI に調査を依頼 現在：AI が先に調査して⼈に報告 コストのアラート コストのアラート ⼈間 エージェント 指⽰ 結果 エージェント 何が増えたか 原因の特定 結果 ⼈間 意図どおりかを 確認 AI が先に調べ⼈は意図どおりかを確かめるだけになる 24
25. 事例 5 コミットメント割引 ① 共通の⽅針と基準で全体と各アカウントを可視化する 購⼊⽅針の例 全体の傾向と各アカウントの状況を確認 期間は 1 年 3 年は管理と予測が複雑化する EC2／Fargate：Compute Savings Plans 構成変更や移⾏をしても割引が続く RDS／ElastiCache など：RI を購⼊ 継続利⽤を確認し世代更新は期限に合わせる 購⼊・更新時は担当チームが計画を確認 移⾏や世代更新も踏まえて判断する 全体も各アカウントも⼀つのダッシュボードで把握 共通の基準で状況を把握し⽀援が必要なチームを⾒つける 25
26. 事例 5 コミットメント割引 ② 購⼊・更新案を届けて実⾏につなげる 購⼊・更新の機会を検知 エージェントが調査・提案 担当チームが判断・購⼊ 契約の満了 ⽅針と利⽤・契約状況を調査 提案を今後の計画と照らす 新たな購⼊余地 購⼊・更新案を作成 購⼊・変更・⾒送りを判断 FinOps 監視を整備 提案から購⼊に進んだ ⽅針とエージェントを改善 14 アカウントのうち 9 は未活⽤（更新漏れ／未使⽤） 各チームは届いた提案から購⼊を判断する 26
27. 戦略 3 改善策の効果と影響まで確かめる 事例 6 未使⽤リソースの削除 事例 7 ⾒込みを実測で確かめる 27
28. 事例 6 未使⽤リソースの発⾒を削除につなげる 全アカウントから⾃動収集 FinOps が確かめてつなぐ 担当チームが承認して削除 未使⽤の候補と費⽤を出す 優先度と妥当性を確認 利⽤予定を確認して承認 エージェントが 持ち主と経緯を調べる 担当チームへ提案 承認後に削除 実⾏は FinOps または 担当チーム 関与したアカウント 未接続ディスク ロググループ NAT Gateway 6 9個 109 個 7個 未使⽤リソースの基準を設け実施まで FinOps が仕組みで担う 28
29. 事例 7 ⾒込みを実測で確かめる ① 施策の効果と影響を実測する 施策 ログの配信経路の変更 変更前 出⼒ 変更後 出⼒ ✕ 配信 ⾒込み 保管 転送 ✕ 監視基盤 保管 転送 監視基盤 経路を変えれば費⽤が減り ピーク時の⽋損も消える 実測 費⽤は⾒込みどおり減った ピーク時の配信の⽋損は 0 想定外のスパイクでログが⽋損 判断 不要なログを出⼒側で抑⽌ 変更前後で測り続けるから効果の確認も悪化への対応も早い 29
30. 事例 7 ⾒込みを実測で確かめる ② 更新や⾒送りを実測で決める ケース 1 更新した契約 実測 更新前のコミットを⼤幅に超過 判断 ⾃動更新の前に実績へ⾒直し ケース 2 ⾒送った利⽤ ⾒込み 料⾦表と問い合わせで⾒積もる 実測 導⼊の初期に ⾒積もりにない従量の費⽤ 判断 すぐに⾒送り実測値で再検討 利⽤の変化を測り続け契約や導⼊の判断に反映する 30
31. 戦略 4 横断の⼟台 データ集約 タグ付けと統制 安全な読み書きの権限 31
32. 横断の⼟台 データ集約 タグ 請求 ログ 監査ログ メトリクス データ基盤 可視化・分析・監視 リソースにタグ付け タグの統制と補正 トレース タグ付け⽅針の⽂書化 修正を依頼 調査 担当の承認 不要なリソースを削除 権限 読み取り 全アカウント 書き込み リソース削除（⼀部のみ） 横断の⼟台により FinOps 主導で調査から遂⾏まで速く確実に進む 32
33. 振り返りとまとめ 33
34. 成果 年間換算の削減額 主導した活動 越境 40 件 他チームへ提案し進めた改善 契約 2025 年 4 ⽉以降に私が主導した施策のみ 14 件 コミットメント割引などの契約 ※単純なボリュームディスカウント契約での削減を除く 範囲 全社の AWS アカウント 約 40 個 FinOps チーム（兼務・仮想・1 ⼈）で越境してコスト最適化が回り始めた 34
35. 振り返り チームにしか分からないこと FinOps チームの提案 担当チームの事情 結果 割引の 購⼊ 利⽤実績と既存契約から 購⼊・更新する案 退役予定の DB 削除予定の環境 2 チームは⼀部を 外して購⼊ CI の 転送費 CI ⽤イメージを転送費の かからない置き場に移す案 標準の仕組みで環境を 作れるので取得は不要 取得をやめて 転送費⽤はなくなり CI も少し速く 担当チームへの最終確認を経て施策は最善の形になる 35
36. 振り返り FinOps チームの関わり⽅の変化 以前 現在 担当チームに調査と対応を依頼 データは FinOps が調べ切り チームには最終確認だけ ⽀援範囲 基盤と課題の提供 提案から遂⾏まで⽀える ⽂化醸成 啓発や勉強会で意識を向上 実⾏を積み重ね育てる 調査 ⼟台づくりから遂⾏まで⽀え実⾏の積み重ねで⽂化を育てる 36
37. まとめ 戦略の全体像 1 データを横断して 2 専⾨家の知⾒を 原因を掘り下げる AI で再現する 3 改善策の効果と影響 まで確かめる 請求データと テレメトリーをつなぐ ⽅針とノウハウを⽂書にし 検知と提案を仕組みに任せる 推奨や⾒積もりで⽌めず 効果と影響まで調べ切る 請求の変化から 具体のコードまでたどれる ⼈は確認と判断だけに 回れる 安全に実⾏し すぐ対応できる 4 横断の⼟台 データ集約 タグと統制 安全な権限 壁を越えて深く掘り遂⾏まで届ける FinOps チームが調べ切り最⼩限の負担で遂⾏につなげる 37
38. ご清聴ありがとうございました 🍜 話の替え⽟（おかわり）は是⾮懇親会で！ 38