クラウドFinOps 第2版

―協調的でリアルタイムなクラウド価値の意思決定

[cover photo]
TOPICS
発行年月日
PRINT LENGTH
488
ISBN
978-4-8144-0108-6
原書
Cloud FinOps, 2nd Edition
FORMAT
Print PDF EPUB
Ebook
4,950円
Ebookを購入する
Print
4,950円

FinOpsとは、事前に予測が難しいクラウド利用のコストと価値を継続的に最適化するフレームワークを指します。クラウドの利用が急拡大する中、グローバル企業の多くで取り入れられ、今やクラウドコストを管理するために欠かせない分野へと進化しています。
本書は、FinOpsを推進する中心的存在である「FinOps Foundation」の創設者による、包括的な解説書です。特定のクラウド事業者に拠らず、FinOpsの原則や考え方をしっかり学ぶことができます。
FinOpsの実践には、エンジニアリングチーム、財務チーム、経営陣がその文化をしっかり共有しながら、組織全体で推進していくことが肝要です。本書では、FinOpsを実践する先駆者の成功例と失敗例をもとに、クラウドFinOps文化を組織の中にどのように構築していくかを解説します。また、データ駆動型の意思決定を通じて、効率的かつ効果的なコスト最適化を実践していく方法も提示します。これからスタートするのに役立つロードマップも丁寧に示しています。

目次

日本語版への序文
はじめに

第1部 FinOpsの紹介

1章 FinOpsとは何か?
    1.1 FinOpsの定義
    1.2 FinOpsヒーローの旅
    1.3 FinOpsはどこからきたのか?
    1.4 データ駆動型の意思決定
    1.5 リアルタイムでのフィードバック(いわゆる「プリウス効果」)
    1.6 FinOpsの基本原則
    1.7 FinOpsをいつ始めるべきか?
    1.8 目的を念頭において開始:データ駆動型の意思決定
    1.9 本章の結論

2章 なぜFinOpsが必要なのか?
    2.1 正当な理由でのクラウド利用
    2.2 クラウド支出の加速
    2.3 FinOpsを導入しない場合の影響
        2.3.1 情報に基づく意図的な無視:なぜ今始めるのか?
    2.4 本章の結論

3章 文化的転換とFinOpsチーム
    3.1 デミングのビジネス変革
    3.2 誰がFinOpsを行うのか?
    3.3 なぜ集中型のチームなのか?
    3.4 FinOpsチームがFinOpsを担うのではない
    3.5 FinOpsにおける各チームの役割
        3.5.1 経営層とリーダーシップ
        3.5.2 エンジニアと開発者
        3.5.3 財務担当者
        3.5.4 調達・契約担当者
        3.5.5 プロダクトまたはビジネスチーム
        3.5.6 FinOpsプラクティショナー(実践者)
    3.6 新たな協働方法
    3.7 FinOpsチームはどこに報告をするのか?
    3.8 動機の理解
        3.8.1 エンジニア
        3.8.2 財務担当者
        3.8.3 経営層とリーダーシップ
        3.8.4 調達・契約担当者
    3.9 組織全体にわたるFinOps
    3.10 FinOpsのための人材採用
    3.11 FinOps文化の実践
        3.11.1 動機付けの難しさは今に始まったことではない
        3.11.2 行動の促進要因
        3.11.3 行動の阻害要因
        3.11.4 天秤を有利な方に傾ける
    3.12 本章の結論

4章 FinOpsの共通言語
    4.1 共通用語集の定義
    4.2 基本用語の定義
    4.3 クラウドプロフェッショナルのためのファイナンス用語
    4.4 抽象化による理解促進
    4.5 クラウド用語 対 ビジネス用語
    4.6 DevOpsと財務部門をつなぐ「万能翻訳機」の作成
    4.7 すべての分野に通じる必要はあるか
    4.8 ベンチマーキングとゲーミフィケーション
    4.9 本章の結論

5章 クラウド請求書の解剖学
    5.1 クラウド請求書の種類
    5.2 クラウド請求の複雑さ
    5.3 請求データの基本的な形式
    5.4 時よ、なぜ私を罰するのか?
    5.5 小さな部品の合計
    5.6 クラウド請求データの略史
    5.7 毎時データの重要性
    5.8 「1か月」は1か月ではない
    5.9 「1ドル」は1ドルではない
    5.10 請求に影響を与える2つの要素
    5.11 誰がコストを回避し、誰が料金を低減すべきか?
    5.12 料金低減の一元化
    5.13 なぜ使用量の削減を分散化すべきか
    5.14 本章の結論

6章 FinOpsの導入
    6.1 告白
    6.2 レベルごとに異なる経営層への説明
        6.2.1 FinOps初期の提案
        6.2.2 FinOps進行中の提案
        6.2.3 FinOpsチームを進めるための人員計画の例
    6.3 経営層のスポンサーへの提案
    6.4 経営層に応じた対応
    6.5 FinOps推進者が影響を与えなければならない主要なペルソナ
        6.5.1 CEO
        6.5.2 CTO/CIO
        6.5.3 CFO
        6.5.4 エンジニアリード
    6.6 FinOpsの導入を促進するためのロードマップ
        6.6.1 ステージ1:FinOpsの計画
        6.6.2 ステージ2:FinOps導入に向けたソーシャライジング
        6.6.3 ステージ3:FinOpsのための組織の準備
    6.7 組織アライメントの種類
    6.8 フルタイム、パートタイム、片手間の時間:リソースに関するメモ
    6.9 ゼロから設計された複雑なシステムは決して機能しない
    6.10 本章の結論

7章 FinOps Foundationフレームワーク
    7.1 実践のための運用モデル
    7.2 フレームワークモデル
        7.2.1 原則(Principles)
        7.2.2 ペルソナ(Personas)
        7.2.3 成熟度(Maturity)
        7.2.4 フェーズ(Phases)
    7.3 ドメインとケイパビリティ
        7.3.1 ドメインの構造
        7.3.2 ケイパビリティの構造
    7.4 フレームワークの導入
    7.5 他のフレームワーク/モデルとの関連
    7.6 本章の結論

8章 FinOpsのユーザーインターフェース(UI)
    8.1 内製ツールか、サードパーティープラットフォームか、ネイティブツールか
        8.1.1 ネイティブツールを使用するタイミング
        8.1.2 ツール内製化のタイミング
        8.1.3 サードパーティープラットフォームを利用する理由
    8.2 運用化されたレポーティング
        8.2.1 データの品質
        8.2.2 完璧は善の敵
        8.2.3 レポートのティアリング
        8.2.4 変更の展開
        8.2.5 汎用レポート
    8.3 アクセシビリティ
        8.3.1 色
        8.3.2 視覚的階層
        8.3.3 ユーザビリティと一貫性
        8.3.4 言語
        8.3.5 色と視覚表現の一貫性
        8.3.6 認識 対 記憶
    8.4 心理学的概念
        8.4.1 アンカリング(係留)
        8.4.2 確証バイアス
        8.4.3 フォン・レストルフ効果
        8.4.4 ヒックの法則
    8.5 レポートへの視点
        8.5.1 ペルソナ
        8.5.2 成熟度
        8.5.3 マルチクラウド
    8.6 各ペルソナの「通り道」にデータを置く
        8.6.1 財務部門の「通り道」にあるデータ
        8.6.2 経営層の「通り道」にあるデータ
        8.6.3 エンジニアの「通り道」にあるデータ
        8.6.4 他部門へFinOpsを接続する
    8.7 理解のためにはまず探索
    8.8 本章の結論

第2部 Informフェーズ

9章 FinOpsライフサイクル
    9.1 FinOpsの6原則
        9.1.1 #1:各チームは協力する必要がある
        9.1.2 #2:意思決定はクラウドのビジネス価値に基づいて行う
        9.1.3 #3:すべての人が自分のクラウド使用量に当事者意識を持つ
        9.1.4 #4:FinOpsのレポートはアクセスしやすくタイムリーであるべき
        9.1.5 #5:組織横断の専門チームが中心となりFinOpsを推進する
        9.1.6 #6:クラウドの変動費モデルを活用する
    9.2 FinOpsライフサイクル
        9.2.1 Inform
        9.2.2 Optimize
        9.2.3 Operate
    9.3 考慮事項
    9.4 どこから始めるべきか?
    9.5 すべての答えを見つける必要はない
    9.6 本章の結論

10章 Informフェーズ:あなたの現在地はどこですか?
    10.1 コンテクストのないデータは無意味
    10.2 まず理解すること
    10.3 本フェーズでの組織的な業務
    10.4 透明性とフィードバックループ
    10.5 チームパフォーマンスのベンチマーク
    10.6 理想的なFinOpsとは
    10.7 本章の結論

11章 配賦:すべての費用を割り当てる
    11.1 適切に配賦することの重要性
    11.2 減価償却:発生主義会計の世界
    11.3 監査可能性と会計部門との良好な関係の構築
    11.4 「想定外の支出によるパニック」の転換点
    11.5 共有コストの分配
    11.6 チャージバック 対 ショーバック
    11.7 目的に適したモデルの組み合わせ
    11.8 アカウント、タグ付け、アカウントの組織階層
    11.9 ショーバックモデルの実践
    11.10 チャージバックおよびショーバックを活用する際の考慮事項
    11.11 本章の結論

12章 タグ、ラベル、アカウント、あぁ大変!
    12.1 タグと階層ベースのアプローチ
    12.2 戦略を遂行する
        12.2.1 計画を伝える
        12.2.2 シンプルに保つ
        12.2.3 疑問を明確にする
    12.3 大手3社の配賦オプション比較
    12.4 アカウントとフォルダ、タグとラベルの比較
    12.5 アカウントとプロジェクトをグループに整理する
    12.6 タグとラベル:最も柔軟な配賦オプション
        12.6.1 タグを使用した請求
        12.6.2 タグ付けを早期に開始する
        12.6.3 タグ付け基準を設定するタイミングを決める
        12.6.4 適切なタグの数を選ぶ
        12.6.5 タグ/ラベルの制限内での作業
        12.6.6 タグハイジーンの維持
        12.6.7 タグ状況のレポーティング
        12.6.8 チームにタグを導入してもらう
    12.7 本章の結論

13章 正確な予測
    13.1 クラウド予測の現状
    13.2 予測の手段
    13.3 予測モデル
    13.4 クラウド予測の課題
        13.4.1 手動 対 自動予測
        13.4.2 不正確さ
        13.4.3 粒度
        13.4.4 予測の頻度
        13.4.5 コミュニケーション
        13.4.6 将来のプロジェクト
        13.4.7 コスト見積もり
        13.4.8 コスト最適化が予測に与える影響
    13.5 予測と予算
    13.6 チームごとに予算を管理することの重要性
    13.7 本章の結論

第3部 Optimizeフェーズ

14章 Optimizeフェーズ:目標達成のための調整
    14.1 なぜ目標を設定するのか?
    14.2 最初の目標は適切なコスト配賦
    14.3 節約が目標なのか?
    14.4 鉄のトライアングル:良さ、速さ、安さ
    14.5 OKRを用いた目標達成
        14.5.1 OKRの焦点領域#1:信頼性
        14.5.2 OKRの焦点領域#2:維持可能性
        14.5.3 OKRの焦点領域#3:制御
    14.6 目標を目標線として設定
    14.7 予算の乖離
    14.8 使用量の削減と支出の低減
    14.9 本章の結論

15章 使用量の低減:使用量の最適化
    15.1 クラウド利用の厳しい現実
    15.2 無駄はどこから来るのか?
    15.3 削除/移動による使用量の削減
    15.4 サイズ変更による使用量の削減(ライトサイジング)
    15.5 よくあるライトサイジングの間違い
        15.5.1 平均値やピーク値のみを用いた推奨事項に頼ること
        15.5.2 コンピューティングを超えた範囲のライトサイジングを怠ること
        15.5.3 リソースの「形状」に対処しないこと
        15.5.4 ライトサイジングの前にパフォーマンスをシミュレーションしないこと
        15.5.5 リザーブドインスタンスの不確実性によって躊躇してしまうこと
    15.6 コンピューティングの範囲を超えて:クラウドコストを管理するためのヒント
        15.6.1 ブロックストレージ
        15.6.2 オブジェクトストレージ
        15.6.3 ネットワーキング
    15.7 再設計による使用量の削減
        15.7.1 スケーリング
        15.7.2 スケジュールされたオペレーション
    15.8 リザーブドインスタンスへの影響
    15.9 労力 対 効果
    15.10 サーバーレスコンピューティング
    15.11 すべての無駄が無駄とは限らない
    15.12 成熟した使用量の最適化
    15.13 高度なワークフロー:自動オプトアウトライトサイジング
    15.14 節約の追跡
    15.15 本章の結論

16章 支払いの低減:料金(レート)の最適化
    16.1 コンピューティング料金
        16.1.1 オンデマンド/従量課金制
        16.1.2 スポットリソースの活用
        16.1.3 コミットメント割引
    16.2 ストレージ料金
    16.3 ボリューム/階層型ディスカウント
        16.3.1 使用量ベース
        16.3.2 時間ベース
    16.4 交渉料金
        16.4.1 カスタム料金
        16.4.2 販売者のプライベートオファー
    16.5 BYOLの考慮事項
    16.6 本章の結論

17章 コミットメント割引の理解
    17.1 コミットメント割引の概要
    17.2 コミットメント割引の基本
        17.2.1 コンピューティングインスタンスサイズの柔軟性
        17.2.2 変換とキャンセル
    17.3 3大クラウドが提供する利用コミットメントの概要
    17.4 Amazon Web Services
        17.4.1 RIは何を提供するのか?
        17.4.2 AWSのコミットメントモデル
        17.4.3 AWSのリザーブドインスタンス
        17.4.4 メンバーアカウントのアフィニティ
        17.4.5 スタンダードRI 対 コンバーティブルRI
        17.4.6 インスタンスサイズの柔軟性
        17.4.7 AWSのSavings Plans
        17.4.8 Savings Bundle
    17.5 Microsoft Azure
        17.5.1 Azureの予約
        17.5.2 インスタンスサイズの柔軟性
        17.5.3 Azure節約プラン
    17.6 Google Cloud
        17.6.1 Googleの確約利用割引
        17.6.2 Googleでの時間ではなくコアへの支払い
        17.6.3 Googleの請求とCUDの共有
        17.6.4 Googleの請求先アカウントと所有権
        17.6.5 プロジェクトでのCUD適用
        17.6.6 Googleのフレキシブル確約利用割引
    17.7 本章の結論

18章 コミットメントベースの割引戦略の構築
    18.1 よくある間違い
    18.2 コミットメントベースの割引戦略を構築するためのステップ
        18.2.1 ステップ1:各プログラムの基礎を学ぶ
        18.2.2 ステップ2:クラウドサービス事業者に対するコミットメントのレベルを理解する
        18.2.3 ステップ3:再現可能なコミットメント割引のプロセスを構築する
        18.2.4 ステップ4:定期的かつ頻繁に購入する
        18.2.5 ステップ5:測定して反復する
        18.2.6 ステップ6:前払いのコミットメントコストを適切に割り当てる
    18.3 コミットメント戦略の管理方法
    18.4 ジャストインタイムでのコミットメントの購入
    18.5 サイズの適正化とコミットのタイミング
        18.5.1 ゾーンアプローチ
        18.5.2 誰がコミットメントのコストを負担するのか?
        18.5.3 戦略のヒント
    18.6 本章の結論

19章  持続可能性(サステナビリティ):FinOpsとGreenOpsの連携
    19.1 クラウドの炭素排出量とは何か?
    19.2 スコープ1、2、3の排出量
    19.3 クラウド事業者は環境に優しいのか?
        19.3.1 アクセス
        19.3.2 完全性
        19.3.3 粒度
    19.4 エンジニアとの持続可能性に関する提携
    19.5 FinOpsとGreenOpsの相乗効果とは?
    19.6 GreenOpsによる改善
    19.7 GreenOpsの妨げとなるFinOpsの回避
    19.8 本章の結論

第4部 Operateフェーズ

20章 Operateフェーズ:ビジネスゴールへのチームの適合
    20.1 目標の達成
    20.2 FinOpsチームの人員確保と拡張
    20.3 プロセス
        20.3.1 オンボーディング
        20.3.2 責任
        20.3.3 可視性
        20.3.4 行動
    20.4 責任はいかに組織文化を促進するか
        20.4.1 「アメとムチ」アプローチ
        20.4.2 怠慢への対処
    20.5 Operate(実行)の具体例
    20.6 本章の結論

21章 コスト管理の自動化
    21.1 どのような成果を得たいのか?
    21.2 自動化 対 手動のタスク
    21.3 自動化ツール
        21.3.1 コスト
        21.3.2 その他の考慮事項
        21.3.3 ツールのデプロイ方法
    21.4 自動化との協働
        21.4.1 統合
        21.4.2 自動化ツールのコンフリクト
    21.5 安全性とセキュリティ
    21.6 自動化の始め方
    21.7 自動化するもの
        21.7.1 タグガバナンス
        21.7.2 スケジュールされたリソースの開始/停止
        21.7.3 使用量の削減
    21.8 本章の結論

22章 メトリクス駆動型コスト最適化
    22.1 基本原則
        22.1.1 自動測定
        22.1.2 ターゲット
        22.1.3 達成可能な目標
        22.1.4 データ駆動型
    22.2 メトリクス駆動型 対 ケイデンス駆動型プロセス
    22.3 ターゲットの設定
    22.4 行動を起こす
    22.5 すべてを1つにまとめる
    22.6 本章の結論

23章 コンテナの世界におけるFinOps
    23.1 コンテナ入門
    23.2 コンテナオーケストレーションへの移行
    23.3 コンテナのFinOpsライフサイクル
    23.4 コンテナのInform(可視化)フェーズ
        23.4.1 コスト配賦
        23.4.2 コンテナの割合
        23.4.3 タグ、ラベル、Namespace
    23.5 コンテナのOptimize(最適化)フェーズ
        23.5.1 クラスターの配置
        23.5.2 コンテナ使用量の最適化
        23.5.3 サーバーインスタンス料金の最適化
    23.6 コンテナのOperate(実行)フェーズ
    23.7 サーバーレスコンテナ
    23.8 本章の結論

24章 エンジニアとの協力によるFinOpsの実現
    24.1 「われわれ」と「やつら」の統合
    24.2 エンジニアは何を考えているのか?
    24.3 制約と難問の解決
    24.4 コスト効率に優れたエンジニアリングを可能にするための原則
        24.4.1 #1:コスト削減よりも価値の最大化をする
        24.4.2 #2:同じチームの一員であることを忘れない
        24.4.3 #3:コミュニケーションの改善を優先する
        24.4.4 #4:プロダクト開発の早い段階で財務的制約を導入する
        24.4.5 #5:コントロールではなく、イネーブルメントをする
        24.4.6 #6:リーダーシップの支援は役に立つものではなく、必要不可欠なものである
    24.5 エンジニアの「通り道」にあるデータ
    24.6 エンジニアリングチームとの協力モデル
        24.6.1 直接的な貢献
        24.6.2 間接的な協力
        24.6.3 間接的な協力と的を絞った貢献
    24.7 本章の結論

25章 他のフレームワークとの結び付き
    25.1 総所有コスト(TCO)
    25.2 他の方法論やフレームワークとの併用
        25.2.1 他に誰がいるかを探す
        25.2.2 仲間づくりと目標の共有
        25.2.3 影響力・用語・プロセスの共有
        25.2.4 基盤の共有
        25.2.5 知識の共有
    25.3 本章の結論

26章 FinOpsの悟りの境地:データ駆動型の意思決定
    26.1 ユニットエコノミクスと指標
    26.2 ユニットエコノミクスは必ずしも収益と関連させる必要はない
    26.3 ユニットエコノミクス指標の計算
    26.4 支出は良いが、浪費は良くない
    26.5 アクティビティベースのコスト計算
    26.6 鉄のトライアングルへの回帰
    26.7 ユニットエコノミクスの計算式に欠けているものとは?
    26.8 FinOpsをやりきった状態とは?
    26.9 本章の結論

27章 「秘密の材料」、それはあなた自身
    27.1 実際のアクションへ

あとがき―優先すべきこと(J.R.より)
訳者あとがき
索 引