この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
re:Invent2022 も終了し、オンデマンド動画が配信されているので、気になっていたセッションを視聴しました。
セッション概要
Take the guesswork out of planning with AWS: accurately evaluate the cost impact of your AWS workloads as you grow and save on AWS. Join this chalk talk to learn how you can plan for changes to your workload and simplify your cost estimate. Understand how modifications of your purchase commitments, resource usage, and commercial terms affect your future AWS spend.
↓↓↓ 自動翻訳 ↓↓↓
AWSを使った計画から当てずっぽうをなくす：成長に合わせてAWSワークロードのコストインパクトを正確に評価し、AWSで節約する。このトークセッションでは、ワークロードの変更をどのように計画し、コストの見積もりを簡素化できるかを学びます。購入コミットメント、リソース使用量、商用条件の変更が将来のAWS支出にどのように影響するかを理解します。
セッション内容
AWS の利用計画と予測について考える時に、よく言われること
- Will moving to the cloud be economically beneficial?
（クラウドへの移行は経済的にメリットがあるのか？） - How can I price out my migrations or application builds on AWS?
（AWS でのマイグレーションやアプリケーション構築の価格はどのように決めればよいですか？） - What tools are available to help me forecast my costs?
（コスト予測に役立つツールは？） - How do I evaluate my IT investment decisions?
（IT 投資の意思決定をどのように評価すればよいのか？） - What have other customers done to plan and evaluate IT spends?
（他のお客様は、IT 支出の計画や評価のためにどのようなことをされていますか？）
『所感』
確かに、これらの質問は AWS やクラウドに関わっている方は、聞かれた経験や自身で考え・悩んだテーマの一つではないかと思います。
IT 戦略的投資計画は一度実施すれば終わりではなく継続的に実施されるもの
- 計画： AWS 上でワークロードを展開するのに必要なサービスや量を計画
- 予測： それらのサービス利用を予測、発生する費用と適用する課金モデルを検討し、予算化
- 評価： 定義した予算が適切な範囲内にあるか、超過していないかを評価
『所感』
計画・予測・評価のサイクルを継続的に回していく、個人的には「評価」が非常に重要だと考えています。またこの IT 投資に関するプロセス自体は従来から多くの企業でも実施されていますが、ここに「新しい課金モデル（従量課金）」が入ることで、新しい運用モデルへ更新することが一つのポイントになってくると思います。
シンプルで継続的な計画と予測をするには（クラウドコスト管理を実践するプロセス）
- Establishing your baseline: 予測・評価の基準となるベースラインを作成
(ベースラインの設定) - Forecasting dynamic usage: ワークロード自体の成長や外的要因の変化による動きに対応
(動的な使用状況の予測) - Mechanisms for monitoring: 動的な使用状況の変化を監視・評価するツール利用やメカニズムの確立
(モニタリングの仕組み) - Putting it all together(Intuit ※): 上記をひとまとめにすることで深い洞察を得る
(まとめること)
『所感』
※ 資料上は Inuit と記載されていますが Intuit（直感的に知る、洞察という意味）が近い気がします。（違っていたら恥ずかしい！
Plan(計画)
クラウドコスト計画は Cloud Ops（クラウド運用）の最適化を考えるのと同じ
クラウド財務管理（CFM / FinOps）やクラウド運用を最適化することは、多くの成果が得られる可能性を秘めていますが、それを実現するには適切なガードレールや自動化を確立することが必要となります。
『所感』
ここで紹介されている5つの成果は AWS Cloud Value Framework として AWS を利用することで得られるビジネス価値として紹介されることが多い指標です。今回、ここに「Carbon Savings」が追加されています。
移行時にアーキテクチャを検討するタイミングが、コストや運用計画を検討する機会です
- クラウドへマイグレーションする場合と、新しくクラウドにアプリケーションを構築する場合では、プロセスやツールが異なる
- 移行に必要なデータ収集やワークロードの選択を検討や分析するタイミングでコスト計画についても検討する
- どれだけの利用量が想定されるのか？
- AWS を利用することで得られる費用対効果はどの程度なのか？
- 総所有コスト（TCO）はどの程度になるのか？
- AWS Budgets や AWS Cost Anomaly Detection の設定などのコストガードレールをランディングゾーンに組み込んでおく
『所感』
コストに関する設定や運用設計は、移行（または構築）プロセスの中でも後半になりがちです。アーキテクチャを検討する際に併せて検討し、ガードレールとしてアカウントをデプロイすることが出来れば、運用効率性を高めることが出来そうです。
Forecast(予測)
”予測は常に間違っている” が、いくつかビジネスと計画のリスクへの気づきを与えてくれる
現状のコストと使用状況を把握するところから始まる
タグ付けによりコストオーナー（所有者）の明示化と詳細なコスト状況の把握が行える。チャージバックやレポート作成にも役立ちます。そしてタグ戦略を踏襲したアカウント管理戦略を実施することも重要です。
- Account management strategy
(アカウント管理戦略) - Tagging management at scale
(大規模なタグ付け管理)
『所感』
コスト管理の鉄板な方法といえば、「アカウント分割とタグの活用」ですが、これらは（特に運用開始以降では）、まさに「言うが易し行うが難し」です。そのため、できるだけ上流工程で方針を決め Tag Policy や Config Rules などにより管理を行うのが適切です。
予測には2つの方法論があり、両方が必要
トレンドベースは、既存ワークロードの利用状況から利用量を予測します。ただし、履歴からの推測であり、履歴にないイベントや計画等を捉えることは出来ません。
- Trend-based
- Forward-looking extrapolation of historic time-series data
(過去の時系列データの将来予測への外挿) - Good for forecasting organic growth of existing usage/cost
(既存の使用量/コストの有機的な成長予測に有効)
- Forward-looking extrapolation of historic time-series data
- Driver-based
- Accounts for internal and external business demand drivers
(内部および外部のビジネス需要ドライバーを考慮) - Ideal for dynamic and variable environments
(ダイナミックで変化しやすい環境に最適) - Improved long-term accuracy
(長期的な精度の向上)
- Accounts for internal and external business demand drivers
『所感』
このトレンドベースとドライバーベースの予測方法は個人的にすごく興味深く、わかりやすいものでした。今回のセッションの前に AWS Blog で紹介されています。若干分類などは異なるものの基本的には同様のテーマのため、理解を補完するのに最適です。
トレンドベースと3つのドライバーによる予測
- Organic growth
(有機的成長) - Internal drivers
(内的要因) - External drivers
(外的要因) - Optimization drivers
(最適化要因)
『所感』
Organic growth や Optimization drivers による予測は多くのエンジニアチームでもなされていると思います。Internal や External drivers はビジネスサイドや会社方針等の情報を取り込むことが重要となってくるため、常日頃から関係性を深めていないとエンジニアチームだけでは、この手の予測を行うのは難しいのだなと改めて感じました。
予測に利用可能な AWS サービスや手法
これらの方法によりコストを把握し、ステークホルダーと予測を確立していきます。
- Trend-based forecasting（Organic growth）
- AWS Cost Explorer: すぐ開始出来るサービス（分析期間やデータ状況に注意）
- Amazon Forecast: AWS 情報以外の要素を取り込んだ予測を可能とするサービス
- Driver-based forecasting（NonOrganic growth）
- unit metrics: ビジネス価値を生み出す定量化可能な項目（単位）
- AWS Cost Explorer
- Build your own: Amazon QuickSight 等によるダッシュボード
- AWS Partner Network
『所感』
unit metrics に関しても AWS Blogs で紹介されているものがあります。私には少し耳慣れない部分もあり、、SaaS 界隈で耳にする Unit Economics と置き換えても問題ないかと思います。
Evaluation（評価）
評価を実施するのに必要な要素
KPI を定めて、最適なツールで状況を追跡し、計画時のガードレールを確認してください。
- Define key performance indicators(KPIs)
- Select a cost reporting tool
『所感』
ここでの「ガードレールを確認」には、守られているかというものと、当初に設定した内容が適切であるを確認する2つの意味合いが含まれているのではないかと思います。初期の頃に、設定された内容が必ずしも正しいとは限らないため、その都度適切な内容に修正することも大切なポイントだと思います。
KPI を用いてクラウド利用量・コストを評価する
ここでの KPI は unit metrics を意味します。 単純に値の推移を見るだけではなく、2つの異なるカテゴリで考えることで役立ちます。
- コストベースメトリクス（ ROI を測る）
- ビジネス価値ベースメトリクス（価値を測る）
AWS コストが変動した要因を評価することに役立ちます。
- 費用対効果が下がっている（最適化や SP の適用などのアクションが必要なことを示す）
- ビジネス価値が上がっている（意図した結果で、サービスが適切に成長しているを示す）
『所感』
コストが動的なクラウド環境では、発生した事象の評価方法として unit metrics のような KPI が重要となってきますが、単純に自分たちの行った取り組みを定量的に測定し、客観的に評価することが可能となるのは健全で良いことだと感じました。
組織として運用計画を定義し、運用手順を整備する
ステークホルダーによる横断的なチームを作り、定期的にこれらのプロセスを実行します。
- Estimate & forecast
(見積もりと予測) - Measure variances
(分散・差異の測定) - Root cause analysis
(根本的な原因分析) - Adjust & improve
(調整と改善)
実績と予測に差異が見られた際の標準作業手順を作成し、小さく始めていき、更新しながら徐々に対象やチームを拡大していきます。
- SOP※ considerations
- Which stakeholders need to be notified?
(どのステークホルダーに通知する必要があるか？) - Who will perform RCA?
(誰が RCA を行うか？) - What is the SLA for determining root cause?
(根本原因究明のための SLA は？) - Can we justify the variance?
(差異を正当化できるか？) - Do we need to fix the problem to keep it from recurring?
(再発防止のために問題を修正する必要があるか？)
- Which stakeholders need to be notified?
『所感』
サービス運用・監視と同様で、パフォーマンスやリソースを定期的に振り返る機会やアラート・インシデントに対する運用手順を作成するのと、同じようにコストに関しても実施するというイメージではないかと思います。
※ SOP: Standard Operating Procedures(標準作業手順書）
事例（Intuit Inc.）
Intuit 社のクラウドジャーニー
2016 年から FinOps プログラムを開始し、それから4年間はデータセンターとクラウドが併存する期間として予測し、2020年からはクラウドのみが対象となっています。 この並行期間は、ダブルバブルと呼ばれる二つの対象（データセンターとクラウド）を管理する必要がある点に、注意してください。
分散型説明責任の実践
Intuit 社では数百の開発チームが存在し（数十のビジネスセグメント * 数十の開発チーム）、日々 AWS を利用しています。 それらのチームに適切に説明責任を持たせる（分散型説明責任）ために、1〜4つの予測ユニット（アカウントやタグ、目的に応じた単位）を付与します。また予測ユニットは ゴルディロックスの原理 のように、程よいサイズであることが重要です。
適切な予測を実現するための準備
Kubernetes や Splunk のようなテクノロジーでは、どの部分を誰が利用しているかを正確に把握することが難しいため、Intuit ではシステムの仕組みを理解し、追加のテレメトリーデータを追加している。それらに基づいて適切な利用料を配賦している。
- Resilient structure and lifecycle management are important to ensure the cloud is precisely attributed to the correct groups
(クラウドを正しいグループに正確に帰属させるには、弾力性のある構造とライフサイクル管理が重要です) - The approach should auto-flex through commonplace organizational shifts
(一般的な組織変更にも柔軟に対応できるアプローチであること) - With costs divided properly and landing with the right teams, they'll have a fighting chance at producing an accurate forecast
(コストを適切に配分し、適切なチームを編成することで、正確な予測を立てることができます) - This includes distributing complex shared technologies like Kubernetes, Splunk, or Connect
(これには、Kubernetes、Splunk、Connect などの複雑な共有テクノロジーの配布も含まれます)
予測も一度決めたら終わりではなく更新していく
Cloud360 という機能を開発し、洞察を提供し、クラウドを操作可能なハンドルを提供している。
- Successful forecasting isn't just precise prediction - it includes adjusting course during the active cycle
(予測の成功は正確な予測だけではありません - アクティブサイクル中の軌道修正も含まれます) - Provide insights needed to understand spend trajectory and make the optimal tradeoff of accuracy to forecast vs. other objectives
(支出の軌道を理解し、予測の精度と他の目的との最適なトレードオフを行うために必要なインサイトを提供します) - Example capability: Teams receive configurable alerts when their projected spend is on course to exceed forecast
(機能の例: 予測された支出が予測を上回りそうな場合、チームは設定可能なアラートを受け取ることができます。)
所感
クラウド財務管理の実践は、単純なコスト管理に留まらず、クラウドにより得られるビジネス価値の最大化や自分たちで、ブレーキをかけることやアクセルを踏むこと、そしてクラウドを操縦するためのハンドルを得ることが出来ます。少し壮大な印象を受けてしまいますが、要するに定量化された指標を得られ、状況の可視性や判断の精度を高められると考えると、今度重要視されるテーマの一つなのではないかと感じます。まだまだ理屈が少しわかった程度で、実践的なものは身に付けられていないので、今度も CFM / FinOps 領域についてウォッチしていきたいと思います。
追記
今回の内容に関連する記事が AWS Blog で紹介されていましたので、追記します。