クラウド費用の最適化: 成功し続けるための諸原則
Google Cloud Japan Team
※この投稿は米国時間 2020 年 5 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。
クラウドは単なるコストセンターではありません。クラウドに移行することで、グローバルな規模でイノベーションを実現し、新機能をすばやくリリースして製品化までの時間を短縮し、お客様のニーズに迅速に対応して競争上の優位を促進できます。そのため、多くの企業が自組織のデジタル戦略を可能な限り早急に変革しようとしています。ただし、クラウドを迅速に採用することが理に適っているとはいえ、アプリケーションをクラウドに移行またはデプロイするにあたっては、事前に時間をかけて重要な概念を考察しておくことも重要です。また、アプリケーションがすでにクラウドにある場合も、環境を改めて見直し、ベスト プラクティスに準拠していることを確認することをおすすめします。目標は、クラウド リソースを最も効果的かつ効率的に利用することを念頭に置きながら、費用を最適化すると同時に、ビジネス価値を最大限まで高めることです。
Google は、複雑なビジネス環境に置かれている数社のお客様の取り組みに協力し、次世代のアプリケーションとサービスを Google Cloud 上にいち早く導入してきました。費用の最適化は、数多くのツールやテクニックを活用して進めることができます。ただし、ツールでできることには限界があります。Google は、クラウドを最大限に活用するには、組織の規模を問わず、準拠すべき基本原則がいくつか存在すると考えています。
今回のブログ記事では、皆様が適切な規模で効果的にデプロイを進められるよう、これらの概念のいくつかを紹介します。次に、3 種類のクラウド費用最適化ツールについても検討し、費用最適化プロジェクトの優先順位を定めるためのフレームワークを提示します。いっそうの最適化を目指すには、ダウンロード可能な電子書籍『クラウド利用時におけるコスト最適化の原則』をご覧ください。Google Cloud のコンピューティング、ネットワーキング、ストレージ、データ分析の費用を最適化するうえで規範となるアドバイスをはじめ、最適化をテーマとして好評をいただいたブログ記事を再編し、1 冊にまとめています。
費用の最適化は人とプロセスの両面で進める
テクノロジーに関して全般的に言えることですが、どれほど優れた基準であっても、準拠されなければ効果がありません。取り組みを妨げているのは、往々にして、テクノロジーではなく、取り組みに関わる人とプロセスの限界です。費用の最適化は、エグゼクティブ チーム、プロジェクト責任者、財務部門、サイト信頼性エンジニア(SRE)のすべてが一体となって進めることで効果が表れます。最初のステップとして、これらの重要な関係者が集い、自社に関する一連の基準を定めます。これは、目標となるサービスレベルの生産性、信頼性、パフォーマンスについて概略を示すものです。このイニシアチブに着手するにあたっては、専門家チームを編成することを強くおすすめします。
クラウドの充実した費用可視化機能を利用する
クラウド環境の大きなメリットは、使用状況のデータを把握するための機能が充実していることです。各クラウド サービスはトラッキングの対象であり、個別に測定できます。この点は諸刃の剣にもなり得ます。現在の SKU は数万種にものぼるため、どのサービスを誰が何の目的で購入しているのかがわからない場合、クラウドにデプロイされているアプリケーションやサービスの総所有コスト(TCO)を把握することは難しくなります。
これは、オンプレミスの設備投資(CapEx)からクラウドベースの運用経費(OpEx)への転換を開始する際に起こりがちな問題です。かつては、中央の財務部門が固定的な予算を設定した後、必要なリソースを調達していました。次月、次四半期、次年度、あるいは複数年度のニーズを予測する際の基準は、過去の成長実績といった指標でした。社内の関係者全員が協議して必要か否かを見定めるまで、購入が進められることはありませんでした。
OpEx 環境であれば、エンジニアリング チームがリソースを必要に応じて起動し、最適な形でサービスを実行できます。Google の認識では、クラウドをすでに利用している多くのお客様の環境で、クラウドが西部劇の舞台のような無法地帯と化していることが少なくありません。エンジニアが、予算やアラートの設定、リソースの適切なラベル付け、エンジニアリング上や財務上の観点からの頻繁な費用確認といったガードレールを標準化しない状態でリソースを起動しているのです。そうした状態は開発期間の短縮を促すとはいえ、サービスの費用対価値の方程式(本来、支出の最適化よりもサービスから得られる価値の方がはるかに重要)を効果的に導き出すための出発点としては、あまり好ましくありません。お客様の側で頭痛の種となっているように見受けられるのが、開発環境と本番環境で進められるそれぞれのプロジェクトの費用の見極めです。これは、標準化されたラベル付けの慣行が存在していないことが原因となっています。また、パフォーマンス上の問題を避けるためにエンジニアがインスタンスを必要以上にプロビジョニングした結果、ピーク以外の時間帯に、大幅なオーバーヘッドが生じているにすぎないケースも見られます。これは、長期的にはリソースの浪費につながります。クラウドの費用を最適化するにあたっては、利用できるリソースのタイプとそれをデプロイするタイミングに関して、全社的な基準を定めることが最も重要です。
Google はこのような動きを再三見てきましたが、クラウドが持つ弾力性という最も大きな特長の一つが問題であると受け止められる向きがあるのは残念です。請求金額が予想外に急増した際、そうした費用の増大が懸念事項と捉えられることがあります。費用を投じた成果は、トランザクション処理件数やサービス提供ユーザー数といったビジネス指標に表れます。この点を考慮しない限り、クラウドの請求金額を解釈するための背景情報を見落としていることになります。多くの場合、費用が増大していることを発見し、その増大の原因が特定のビジネス オーナーまたはグループにあると判断することまでは容易です。しかし、プロジェクト オーナーに具体的な推奨事項を提示するための背景情報が十分にないのです。サービスの対象となるお客様が増加したためにチームの支出が増大しているのであれば、好ましい状況と言えます。逆に、CPU 負荷が大きく必要のない VM を担当者がシャットダウンし忘れて、週末の間、不要なトラフィックがオーストラリアに送信され続けていたために請求金額が増大している場合もあります。
この問題を解決する手立ての 1 つは、ビジネス上のニーズに応じて費用を整理し、体系化することです。これにより、 Cloud Billing のレポートでサービスを掘り下げ、費用の状況を一目でつかむことができます。ラベルを利用して部門別またはチーム別の費用を割り出し、カスタム ダッシュボードを作成して、よりきめ細かく自社環境の費用を確認することも可能です。このアプローチでは、事前定義のビジネス指標に基づいてリソースにラベルを付けた後、支出額を時系列でトラックできます。長期的には、「Compute Engine に関する先月の支出は $X であった」ではなく、「$Y の収益をもたらすお客様にサービスを提供するために $X の費用が生じている」と把握することが目標です。最終的には、このタイプの分析をすることが目標です。
クラウドの大きな特長の 1 つは、製品化までの時間の短縮を目指して機能をすばやくリリースできることです。この弾力性を活かして、ほんの数分でワークロードをデプロイできます。従来のオンプレミス環境で、何か月もの間待たされていたのとは対照的です。企業によっては、自社ビジネスの実際の成長速度を把握していないことがあります。したがって、費用を可視化するためのモデルを事前に確立しておくことが欠かせません。また、サービスあたりの費用という単純な指標から脱却すれば、プロジェクトごとのパフォーマンスの指標として、収益性などの新たなビジネス指標を測定できるようになります。
価値と費用の違いを理解する
複合的なクラウド システムの構築を目標とするのは、単に費用を削減するためではありません。ここで、たとえ話として、健康作りの目標を設定したとしましょう。多くの人は、より健康な身体を作り上げようとする場合、体重を落とすことに意識を向けます。しかし、体重が減少すること自体は、常に好ましい指標であるとは限りません。体調不良や脱水症状の結果として体重が減少している可能性もあります。体重の減少といった指標を私たちが目標として掲げる場合、実際に関心を寄せているのは、自分の健康全般、見た目、あるいは子供たちと遊ぶ、長生きする、ダンスするなどの活動を楽しめることです。それと同様に、一口に費用の最適化と言っても、費用の削減にとどまるものではありません。支出の無駄を洗い出し、あらゆる支出の価値を最大限に高める取り組みになります。
また、きわめて先進的なお客様は、コストカットの数字に固執することなく、運用の全般的な健全性を見据えて、さまざまな事項を自問しています。
お客様(ユニット)に実際に提供しているものは何だろうか?
提供するためにどの程度の費用が生じているのか、それだけを提供すれば済むのか?
もたらされるユニットごとに、関連する支出すべてを最適化するにはどうすればよいか?
端的に言えば、取り組みをさらに推し進めて、独自のユニット エコノミクス モデルを創り上げているのです。このようなお客様は、上記の重要な質問を自問することから始め、それに答えるためのシステムを構築し、自分の行動を吟味します。このような取り組みは、初心者のお客様にはあまり見受けられませんが、ある程度経験を積んだお客様の多くは、将来に向けてシステムの設計を進める中で、これらの概念のいくつかを採り入れています。
標準化されたプロセスを当初から導入する
これらの推奨事項を常に確実に導入するには、体系的な設計と適用が欠かせません。クラウド リソースをデプロイする前に、Terraform や Cloud Deployment Manager などの自動化ツールを利用して、ガードレールをあらかじめ構築しておくことが有効です。さかのぼって基準を適用する方がはるかに難しくなるからです。Google は、タグ付けされていないリソースを遮断したり遮断を迫ったりする IT オペレーション部門から、基準を遵守しないことで表彰に値するような頑固な社員まで、あらゆる事態を目の当たりにしてきました(ピザ 1 枚でも、トロフィでも、ピザ型トロフィでもなんでも褒められて、賞品をもらえれば嬉しく思うものです)。
早い段階で標準化することが望ましい最適化プロセスには、たとえばどのようなものがあるでしょうか。まずリソースのデプロイが挙げられます。あらゆるエンジニアが、あらゆる量のあらゆるリソースをデプロイできなければならないのでしょうか。おそらくはノーです。これは、事前に基準を確立することによって大きな差異を生み出せる領域であると Google は認識しています。
効果的なコスト管理には、リソースの体系化も重要です。当初の要件を満たす最もシンプルな構造を採用した後、要件の発展に応じて、リソースの階層を調整していくことをおすすめします。設定ウィザードを利用すると、推奨事項を確認しながら、手順に沿って最適な環境を構築できます。このリソース階層では、プロジェクト、フォルダ、ラベルを利用してリソースの論理グループを作成すると、管理上や費用配分上の要件に対応できます。
コスト管理が関心事項となっている組織の場合、リソース階層で最優先となる事項はリソースのラベル付けです。特定のビジネス、サービス、ユニット、リーダーなどがどの程度のコスト因子であるかについては、基本的にはお客様が規定します。リソースをラベル付けしない場合は、特定の対象にどの程度の費用が生じるかを解明することがきわめて難しくなります。望ましいのは、Compute Engine に関して $36,000 の支出が生じたと表現することよりも、先月、400,000 人のユーザーにミームを配信するために $36,000 の支出が生じたと表現できることです。
2 つ目の表現は、1 つ目よりもはるかに本質を突いたものとなっています。エンジニアリング担当および財務担当のチームと共同で標準化されたラベルを作成し、可能な限り多くのリソースをラベル付けすることを強くおすすめします。
結果を確認して最適なものを繰り返し適用する
しかるべきチームとのミーティングを定期的に設定して、使用状況のトレンドをレビューし、必要に応じて予測を調整することを慣行としてください。Cloud Billing のコンソールでは、クラウドに関する支出を簡単な手順で定期的にレビューし、監査できます。一方、カスタム ダッシュボードでは、よりきめ細かく費用を把握できます。支出の可視化と併せて、定期的なレビューや適切なユニット エコノミクスを導入していない場合は、請求金額が急増した場合に対応が後手後手に回らざるを得なくなります。
変更の少ない環境を運用している場合、戦略を微調整する機会は、Google Cloud に新しい機能が実装された、自社の製品ロードマップに関してビジネス上の変更が生じたなど、状況に依存します。したがって、支出のレビュー頻度を減らすことが可能です。これに対して、多数の新規アプリケーションをデプロイし、月ごとに 100 万ドル単位の支出が生じている環境では、少額の投資で費用のレビュー頻度を上げることによって、短期間のうちに大きな節減を果たせる可能性があります。1 日 1 回という頻度でミーティングを設定し、予測を調整している先進的なお客様も存在します。1 か月あたりの支出が数百万ドルに達している環境では、合計の請求金額がわずか数パーセント変化しただけでも、新たなテクノロジーの試験運用やエンジニアの増員といった事案に投じるための資金が流出する事態を招きかねません。
本当の意味でクラウドを効率的に運用し、その価値を最大限に高めるには、さまざまな背景を持つ複数のチームが共同して、具体的なビジネスニーズに合わせたシステムの設計に取り組みます。レビューの頻度は、クラウドでのシステム構築と支出のスピードに基づいて定めることをおすすめします。費用、スピード、品質を測定するために一般的に利用されているフレームワークとしては、鉄の三角形があります。複数のチームと連携して合意を形成し、自社のビジネスで効果を発揮するフレームワークを確立してください。その結果を出発点として、投入する資金を絞ることも、さらに多くの資金を投入することもできます。
費用の最適化に向けた取り組みのためのツール
クラウドの費用を最適化するためのアプローチをしっかりと把握した後は、各種ツールの検討に着手します。概略としては、大きく分けて 3 種類のツールを利用し、Google Cloud のコスト管理を進めることになります。
費用の可視化: これには、支出の詳細な内訳、個別のサービスの請求状況を把握することに加え、ビジネス成果を達成するための具体的な支出額(およびその理由)を表示できることを含みます。ここで念頭に置くべき重要な機能は、共同の説明責任の割り当て、頻繁な費用レビュー、トレンドの分析、ほぼリアルタイムでの操作結果の視覚的表示が可能であることです。リソースを整理するための標準化された戦略に沿って進めると、組織の運用体制に費用を正確にマッピングして、ショーバックやチャージバックのモデルを作成できます。また、予算アラートや割り当てといったコスト管理の機能を利用して、時間の経過に伴って生じる費用を常にチェックすることも可能です。
リソースの使用状況の最適化: これは、使用状況を最適化して環境に潜んでいる無駄を削減することです。環境のコストとパフォーマンスが最適な配分で折り合う、一連の基準を導入することが目標になります。この基準は、アイドル状態のリソースの有無、アプリのデプロイ先として現状よりも適切なサービスの有無、場合によっては、カスタム VM 構成を投入することの妥当性を見きわめるにあたって、状況を見通すためのレンズになるものです。無駄の回避に成功している企業のほとんどは、リソースの最適化を一元化せずに進めていま
す。これは、通常、ワークロードの状況に精通している個々のアプリケーションのオーナーがリソースのシャットダウンまたはリサイズを担う適任者であるためです。また、VM インスタンスのプロビジョニングの過不足、アイドル状態のリソースといった問題点の洗い出しには、Recommender も活用できます。最適化によって良好な成果を挙げるうえで目標になるのは、それらの推奨事項がチームに自動的に提示されるようにすることです。価格設定の効率化: これには、継続利用割引、確約利用割引、定額料金、秒単位の課金、使用量に応じたその他の割引などの適用を受けて、特定のサービスの料金を最適化する機能を含みます。これらの機能を最大限に活用するには、すべての事業部門にわたって対象範囲を最適化すると同時に無駄の生じるリスクを低減できるよう、クラウド センター オブ エクセレンス(CCoE)やファイナンス運用(FinOps)チームなどの一元化されたチームを社内に設置します。これは、クラウドへの移行前に加え、本稼働後も定期的なレビューを継続すべき事項です。
人とプロセスの両方を検討することは、基準が有用なものでありビジネスニーズに合致していることを確認するうえで、大いに意義があります。同様に、Google Cloud が備えている費用の可視化機能、リソースの使用状況の最適化機能、価格設定の効率化機能を理解することは、すべてのテクノロジーとチームにわたって費用を最適化するうえで欠かせない手立てになります。
推奨事項の優先順位を決定する方法
競合するイニシアチブが数多く存在している状況では、費用の最適化に関する推奨事項を優先的に実践することや、最適化の取り組みをレビューする時間を安定的に確保することが難しい場合もあります。チームで優先順位を定めるには、潜在的な費用節減額に加えて、エンジニアリングの作業量も把握できれば有用です。長年にわたってイノベーションと移行速度のみに焦点を絞り、不適切な最適化の慣行が時間の経過とともに積み重なって、著しい無駄につながっているお客様も存在しています。それらの用途に消えた資金は、新機能の開発や追加インフラストラクチャの購入に、あるいは機能の開発期間の短縮に向けたエンジニアの雇用拡大に充てることも可能であったはずです。費用と開発期間の最適なバランスを見つけ出し、ある方向性を別の方向性よりも過度に追求した場合に表れる影響を理解することが重要になります。
費用の最適化に関して、ある推奨事項を別の推奨事項よりも優先して実践できるようにするには、次の 2 つの特性を評価したうえで、推奨事項にタグを設定することをおすすめします。
作業量: リソースの調整をつけ、費用の最適化に関する推奨事項を実践するために必要な推定の作業規模(単位は週)。
節減額: 費用の最適化に関する推奨事項を実践した場合に実現できる推定の節減規模(単位はサービスごとの節減率)。
費用節減の手段によってどの程度の額を節減できるかについては、テストの実施前に厳密な精度で常に推定できるわけではありませんが、取り組みごとに、得られた情報を活かして推定してみることが重要です。たとえば、プロジェクト X の Cloud Storage について、ある変更によって 60% の節減率を達成できる可能性があるとわかれば、優先順位のマトリクスに反映し、チームでのエンジニアリング上の優先順位を確立するには十分です。場合によっては、実際の節減額を推定できることもあります。特に購入時には、実際のインフラストラクチャで使用する量を基に確約利用割引などを活用すれば、FinOps チームが潜在的な節減額を推定できます。これを実践することで、チームは、エンジニアリングの方向性を明確に把握した上で判断を下すことができます。また、組織文化という観点からも、チームが集中して作業に取り組むことができるようになります。
原則から実践へ
クラウドの費用の最適化は、チェックリストで事足りるものではなく、意識のあり方を問われる取り組みです。取り組みを順調に進められるよう、戦略的に検討し、確固たるプロセスを確立すれば最大限の成果を得られるでしょう。その一方で、採り入れることによって請求金額を抑制できるサービス固有の手順も数多く存在します。より戦術的なアドバイスについては、Google Cloud のコンピューティング、ストレージ、ネットワーキング、データ分析、サーバーレス アプリケーションに関する節減の方法を取り上げたそれぞれの記事をご覧ください。手元で参照できる資料としては、これらのトピックのいくつかを 1 冊にまとめた電子書籍『クラウド利用時におけるコスト最適化の原則』をダウンロードしてご覧ください。
- By プロフェッショナル サービス担当テクニカル アカウント マネージャー Justin Lerma、Pathik Sharma