FinOps について (ちょっと) 本気出して考えてみた

2025/10/20 に実施された「Azure 費用最適化のアプローチとイオンの成果」での発表資料ですー。
#aeon_tech_hub

Transcript

1. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. https://www.progrive.co.jp https://www.progrive.co.jp 2025/10/20 FinOps について (ちょっと) 本気出して考えてみた 株式会社プログライブ コンサルティング Kazuyuki Sakemi (酒見 一幸)
2. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. Summary Azure を中心とした開発や運用自動化のスペシャリストとして、 日系・外資系 SIer や日本マイクロソフトを経験し、現職にて活躍中。 独法や文教業界を中心に、要件定義から設計構築、NW/SV/アプリ 運用までの幅広いプロジェクトに従事。日本マイクロソフトでは、顧客の コスト最適化や人材育成に向けたコンサルティングを中心に、ビジネスの 加速に貢献。2024年08月、Microsoft MVP for Azure に選出。 自己紹介 https://twitter.com/_skmkzyk https://zenn.dev/skmkzyk https://atbex.attokyo.co.jp/blog/001013001/ 酒見 一幸 (Kazuyuki Sakemi) from 株式会社プログライブ コンサルティング https://speakerdeck.com/skmkzyk
3. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. あなたの FinOps はどこから？ 3
4. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. FinOps といえば 4 https://finops-jp.github.io/ja/docs/framework/
5. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. FinOps といえば 5 ◼ なんか継続的な活動っぽい https://finops-jp.github.io/ja/docs/framework/
6. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. なんたら Ops 6 ◼ PDCA + How = XOps https://finops-jp.github.io/ja/docs/framework/ PDCA?
7. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. そういえば DevOps 7 https://ja.wikipedia.org/wiki/DevOps#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Devops-toolchain.svg
8. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. DevOps + Fin? 8 https://ja.wikipedia.org/wiki/DevOps#/media/%E3%83%95%E3%82%A1%E3%82%A4%E3%83%AB:Devops-toolchain.svg + Fin? + Fin?
9. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 日本の SIer という観点でなじみが深いのは 9 要件定義 基本設計 詳細設計 構築 テスト 運用
10. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. あなたの FinOps はどこから？ 10 要件定義 基本設計 詳細設計 構築 テスト 運用 FinOps? FinOps? FinOps?
11. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 運用フェーズの方が FinOps をよくやっている印象 11 要件定義 基本設計 詳細設計 構築 テスト 運用 FinOps? FinOps? FinOps? 予約とか節約プラン (SP) とか = すでに運用しているシステムに対して あまり影響を与えずにコストを下げる
12. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 要件定義における FinOps (の観点) がなぜ大事か 12 要件定義 基本設計 詳細設計 構築 テスト 運用 FinOps? FinOps? FinOps? 要件定義の項目例 (特に非機能要件) • 可用性 → コストと密接に関係する • 拡張性 → コスト最適化の「しやすさ」に関係する • パフォーマンス → インフラストラクチャーの規模そのものに関係する • SLA → SLA って意味ある…？
13. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 非機能要件とコスト最適化 13 可用性 • 2 台構成から 1 台構成にするとコストは下がるが、 耐障害性は下がる • よく「コストの最適化」と言っているのは これを念頭に置いており、 可用性を下げてまでコストを下げる正当性はあるか パフォーマンス • どれくらいの RPS で、 応答時間の目標値をどうするか • 突発的な要求増加にどれほど余裕を見るかは ビジネス側からの要求によって決定する 拡張性 • スケールアウト可能なアーキテクチャーの場合、 2/4/8/16 ではなく、2/4/6/8 と拡張が可能なため、 パフォーマンス要求に最適化しやすい (後述) • Cost optimizability SLA • SLA は高い方がいいかもしれないが、 その分コストは上がる • そもそも自社で内製していないシステムに対する SLA にどこまで意味があるのか • 意味がある SLA vs. 運用レベルを決める SLO
14. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. CPU 使用率 90% と聞いて = メトリックアラートあるあるのイメージ 16 ◼ コスト最適化観点 ⁻ リソースを高効率で使えており、 コストが最適な状態に近いといえる ⁻ ビジネス側と同意した応答時間を満たせていれば 問題ないのでは？ ◼ でも、なんかモヤモヤする気持ち ⁻ 余剰・余裕がないことにより 容易に障害に結び付きそうな不安 ⁻ スケールアウトが可能なアーキテクチャーであれば、 オートスケールなどを取り入れることで自動的に 解消できる ⁻ スケールアップしか取れないのであれば、 右肩上がりを察知し、メンテナンス、対処が必要 コストは最適 or 余裕が無い
15. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. FinOps したい？ 17 ◼ FinOps には技術的な面白さが詰まっている ⁻ 個人的にはとても好き、謎解きみたいで楽しい ◼ 本来求められているのはビジネス価値の最大化であって、FinOps ではない ⁻ あくまで FinOps は手段… ◼ 目指すべき場所は FinOps のない世界…？ ◼ なんど時間を巻き戻しても FinOps の概念が生まれてきてしまう・・・！！！？？？
16. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. Cost Optimizability(造語) 18
17. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. コスト最適化しやすいアーキテクチャー 19 アーキテクチャーの種類によって、コストの最適化のしやすさ (cost optimizability) が異なる Load Balancer VM VM Load Balancer VM VM Load Balancer VM VM VM VM Scale-up/down 戦略 Scale-out/in 戦略 VM 2core/8GiB VM 4core/16GiB 2core/8GiB の VM 2 台でパフォーマンスが足りなくなった際に、 構成変更としては、2 種類の戦略が考えられる 製品例: ADDS、SOFS、MSSQL (Read) 製品例: MSSQL (Write) Scale-out/in: マシン自体を増やしたり、減らしたり Scale-up/down: CPU を増やしたり、減らしたり
18. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 2 つの戦略の違い 20 Scale-up/down 戦略 Scale-out/in 戦略 SKU 変更のために再起動を伴い、ユーザー影響が大きい LB への設定変更は不要 2 → 4 → 8 → 16 といったスケールでしか変更できない ステートレスな構成への変更がほぼ必須 2 → 4 → 6 → 8 といった細かいスケールでの調整が可能 インフラストラクチャー増強の粒度が大きすぎる 細かい調整による最適な cost optimization が可能 Connection draining によりユーザー影響を最小化可能 デメリット メリット デメリット メリット ミドルウェア等によって構成の可否が決まる おおよそほとんどのクラスターは 2 台構成を取れる
19. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 自動的にコストが最適化になるアーキテクチャーに向けて 21 あまり適切ではないのですが、業界的に、分かりやすい例を 1 つ、、、 (特に自宅での) 深夜待機、夜勤対応に対して、賃金をどう払うか (べき論が述べたいわけではないです。。) 21:00 09:00 24:00 翌 06:00 待機時間 対応発生 対応発生 発生した対応の 件数・労働時間に応じて・・・？ 21:00 09:00 24:00 翌 06:00 待機時間 対応がなかった場合は・・・？ 待機時間に応じて・・・？
20. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. その従量課金は何に対する従量課金？ 22 9:00 翌 09:00 18:00 24:00 深夜帯の、ほとんど動いていない時間にコスト支払う意味は・・・？ サーバー負荷のイメージ ユーザーがコストを払いたいのは、そのサーバー・システムが生み出した価値に対してのみで、 特に Azure VM などの IaaS をはじめとした起動時間に対する従量課金ではない 継続的な負荷ではなく、VM の起動速度やシステムの即応性のために 24h 稼働させている、という理由なのであれば、 一定のトレードオフを受け入れ、そのタスク・イベントに応じた従量課金モデルも視野に入ってくる 認証の「回数」に応じた課金、Web の「要求・応答回数」に応じた課金、プログラムの「実行回数」に応じた課金
21. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 「サーバーレス」という選択肢 23 サーバーレスの定義はさまざまなものがあるが、1 つの側面として以下のような特徴を持っている サーバーがない = 常に発生し続けるコストがない or とても低い サーバーレスな Azure サービスのコストの例 従量制課金 無料提供 (月額) 従量課金制 実行時間 400,000 GB 秒 ¥0.002393/GB 秒 総実行回数 100 万実行回数 100 万実行回数あたり ¥29.902 Azure Functions (Consumption) PowerShell の簡単なスクリプトを実行したり、イベント ドリブンな Web アプリケーションが動作する環境 常にコストは「最適化」されている → コスト最適化の余地はもうない → 上の人に聞かれてもドキドキしない
22. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. サーバーレスの懸念点 26 ◼ コストの振れ幅 (cost volatility) が高い = めっちゃ増えたり減ったりする可能性 ⁻ コストの予測性 (cost predictability) が低い = 「このシステムの月額いくらになるの？」に答えづらい VNet (= 帯域幅) のコストを誰も見積もれない、みたいな話 ⁻ 一方、IaaS をベースにしたシステムを構成では、基本的に月額は固定 予約を適用すると、コストの予測性が高いまま、コストを削減できる = いろんな意味で楽 ◼ ほとんどのケースでは IaaS ベースのコストよりは低いコストを達成できる ⁻ が、「現在のシステムの RPS どれくらいですか？」に答えられなければ移行した際のコストはほぼ見積れない ⁻ リスク回避傾向がある組織においてサーバーレス構成が取り入れられない理由の一つだと考えている ⁻ うまくいけば N 円/req が計算できるようになる ◼ (余談) Azure OpenAI Service がサーバーレスでよかった ⁻ 実現の可否はさておき、IaaS で提供されていたら LLM のコスト最適化にみんなが苦しむ未来があった
23. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. コスト最適化にはモダン化が必要、とデジタル庁も言っている 27 ◼ 情報システムの開発運用の安定化およびコスト最適化の観点から、レガシー技術からモダン技術を採用して情 報システムを変更していくことが重要である。 ⁻ ガバメントクラウドにおけるモダン化の定義 | ガバメントクラウドの全般的なガイド | GCASガイド ◼ 2025年現在、上記を実現するモダン技術やこれらを活用したモダンな公共情報システム運用の実践をガバメン トクラウドにおけるモダン化の定義とし、以降に詳細を記載する。 なお、この定義以外のモダン化のあり方についても、今後検討していく。 ⁻ APIベースのシステム構成 ⁻ ステートレスなアーキテクチャ ⁻ マネージドサービスの活用 ⁻ 運用のコード化、自動化 ⁻ サービスレベルの定義、計測
24. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. まとめ 28
25. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. コスト最適化の効きめが高いのは 29 要件定義 基本設計 詳細設計 構築 テスト 運用 よく効く あんまり… よくある
26. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. FinOps もシフトレフト 30 要件定義 基本設計 詳細設計 構築 テスト 運用 FinOps? FinOps? FinOps!
27. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 常にコスト最適 → FinOps しなくてもいい 31 要件定義 基本設計 詳細設計 構築 テスト 運用 FinOps? FinOps? FinOps!?
28. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. FinOps, fin. 32 To be continued…?
29. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 過去のコスト最適化をトピックとしたスライドたち 33 ◼ コスト最適化のはなし with Microsoft Copilot for Azure (January 14, 2024) ⁻ https://speakerdeck.com/skmkzyk/cost-optimization-methods ◼ Microsoft Cost Management の使い方のおさらい (March 21, 2024) ⁻ https://speakerdeck.com/skmkzyk/quick-guide-for-microsoft-cost-management ◼ Microsoft x おれたちのコスト最適化バトル (改) (April 06, 2024) ⁻ https://speakerdeck.com/skmkzyk/cost-optimization-battle そのほかいろいろ Speaker Deck 見て →
30. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. (朗報) Azure Firewall の最小構成が安くなったかも 34 ◼ Generally Available: Prescaling in Azure Firewall (Last modified: 10/16/2025) ⁻ https://azure.microsoft.com/ja-jp/updates/?id=515452 0.11 (USD/h) * 730 (h) = 51.1 (USD) ≒ 7,708.95 (JPY)
31. Copyright (C) ProGrive Consulting Co.,Ltd. All rights reserved. 会社名 株式会社プログライブコンサルティング [ProGrive Consulting Co., Ltd.] お問い合わせ info@progrive.co.jp ~ Expand Your Business ~ ～ビジネスの成長、新たな機会の追求、そして未来を切り開く～