最適化に手間がかかりすぎるなら、労力をかけずにクラウドコストを削減する方法を選びましょう。
コスト最適化が割に合わないと感じたら、手間をかけずにクラウドコストを削減する道を
パブリッククラウドはスケーラビリティ、信頼性、柔軟性に優れていますが、それでも「タダで使える」わけではありません。Amazon Web ServicesやGoogle Cloudといったクラウドプロバイダーでは、必要なときに必要なだけコンピューティングリソースやサービスを利用し、その分だけ支払うことができます。しかし、純粋にオンデマンドで使い続けるとコストはかさみ、やがてパブリッククラウドの利用そのものが採算に合わなくなってしまいます。
クラウド支出をうまく管理する方法としては、利用量や支出額を事前にコミットする、あるいは大幅に割引されたSpotインスタンスを活用するなど、さまざまな選択肢があります。ただし、いずれのコスト最適化戦略も、適切に運用するには時間とリソースが欠かせません。問われるのは「いくら節約できるか」ではなく、「その成果は労力に見合うのか」という点です。
本記事では、この2つの戦略の中身を整理し、組織にとって労力に見合うかたちで最適化する方法を見ていきます。
コンピュートのコミットメント / リザベーション
コンピュートはクラウド請求額の半分以上を占めるのが一般的で、ここを最適化できれば支出全体への効果が最も大きくなります。だからこそAWSをはじめとするパブリッククラウドプロバイダーは、利用量を事前にリザーブまたはコミットすることと引き換えに大幅な割引を提供しているのです。AWSではReserved InstancesやSavings Plansとして知られるこれらのcommitmentプログラムは1年契約と3年契約があり、当然ながら3年コミットメントが最大の割引率となります。
ただし、こうした節約機会を活かすには、コミットメント期間中の利用量を高い精度で予測する必要があります。過剰にプロビジョニングして必要以上の利用量をリザーブしてしまえば、使われないworkloadsに無駄な費用を払うことになります(かつてのデータセンター利用やCapEx支出モデルを思い起こさせる事態です)。逆にプロビジョニングが足りず、後からインスタンスが追加で必要になれば、新たなコミットメントのために予測とプロビジョニングをやり直すか、はるかに高いオンデマンド料金を支払うはめになります。
さらに事態を複雑にするのが、コミットメントの条件に織り込みにくい以下のような変数の数々です。
- アプリのコンピュート要件を増減させるコード変更
- 新製品・新サービスのヒットやバズの可能性
- インフレやサプライチェーンの動向など、コントロール不能ながらクラウド利用に影響を及ぼすマクロ経済要因
結果として多くの企業は、最低限のベースラインを確保するために3年コミットメントでできるだけ多くをリザーブし、その上にアプリケーションが必要とするVMタイプ、サイズ、リージョンに合わせた1年リザベーションを積み増していくのが一般的です。
こうして生まれるのは、対象workload、仕様、有効期限を1年を通して追跡・管理しなければならない、絶えず変化する割引カレンダーです。これを担うには、少なくとも1名の専任者、場合によってはチーム単位での体制が必要になります。担当者にはクラウドの専門知識に加え、利用状況をビジネス全体の目標に結びつける力が求められます。当然ながら、こうした専門チームの採用・育成・定着にかかるコストは、節約効果を打ち消してしまいかねません。
これは多くの組織にとって大きな壁であり、リソースが限られ成長重視の若い企業にとってはなおさらです。多くのスタートアップは、限られたDevOpsリソースの時間と注意をコミットメント管理に割く余裕がなく、コストや利用量の管理よりも開発と成長に集中する道を選びます。
規模が大きく資金力もあり、デジタル成熟度の高い企業であっても、commitment portfolioの管理には苦戦します。クラウド環境が複雑になるほど、組織内のチームごとにコンピュート需要や消費レートが異なり、プロビジョニングやクラウド利用追跡の責任範囲が変わり、チーム間の環境の違いも大きくなるため、管理の手間は一段と増していきます。
クラウド環境が複雑になるほど、管理の難易度は上がっていきます。
Spotインスタンス
AWSでクラウド支出を抑える最も効果的な方法のひとつが、可能な限りSpotインスタンスを活用することです。オンデマンド料金から最大90%の節約が可能で、3年コミットメントを上回る割引が得られますが、見逃せない条件があります。Spotインスタンスは未使用のオンデマンドインスタンスを直前に売り出すもの(閉店間際のパン屋が売れ残りを処分するイメージです)で、わずか2分前の通知でクラウドプロバイダーが回収してしまう可能性があるのです。このため、多くの担当者がSpotインスタンスの導入をためらいます。アプリケーションの稼働時間と節約のトレードオフでは、稼働時間を優先してしまいがちだからです。
AWSではAuto Scaling Group(ASG)を使ってSpotインスタンスを管理できますが、その活用には、要求するインスタンスタイプやアベイラビリティゾーンについてある程度の柔軟性が欠かせません。希望どおりの仕様で常に空きがあるとは限らないからです。さらにASGは手動で構成する必要があり、コンピュートニーズが目立った中断なく満たされ続けるよう、定期的なチューニングも欠かせません。これもまた手間のかかる作業で、設定を誤ればそもそも動作しないこともあります。
Spotインスタンスには明らかな制約がありますが、活用を最適化する戦略は存在します。そのひとつがキャパシティリバランシングで、AWSのInstance Rebalance Recommendationsをもとに可用性の維持を支援します。Spotインスタンスが停止されそうなときに事前のシグナルを送る仕組みで、AWS標準の2分前警告に比べると大きな助けになります。ただし、その変更に対応できる担当者がいることが前提です。
その労力に見合う価値はあるのか?
残念ながら、これらのコスト最適化戦略をすべて管理するのにいくらかかるかを示す魔法の公式はありません。クラウド環境の規模と複雑さ、現在および将来のビジネス目標、そして組織内で活用できる専門知識の量に大きく左右されます。たとえば、ある程度オーバーコミットして低単価で抑えるほうが、アンダーコミットして残りをオンデマンドで賄うより安いのか? 後者を選ぶ場合、より大きなコミットメントで得られる節約額と引き換えに得る柔軟性には、どれほどの価値があるのか?
もう一歩踏み込めば、自社のチームでこれらのプログラムを計画・運用できるのか、それとも必要なスキルと専門知識を持つ人材を新たに採用する必要があるのか? 採用する場合、それは運用予算の最善の使い道なのか、それともプロダクト開発やGo-to-Market戦略に振り向けるほうが有意義なのか?
多くの企業は、こうした問いと、その答えを出すために費やす時間こそが割に合わないと判断します。そう考えるのも無理はありません。長期コミットメントは、当初の予測に含まれていなかった新規プロジェクトや機能のリリースを、リソースが新たにプロビジョニングできるまで保留させるなど、エンジニアリングの柔軟性を犠牲にすることが少なくないからです。1年以上前に下された運用予算の判断にプロダクトロードマップが縛られても、本当に構わないでしょうか?
とはいえ、こうした課題には別の解決策があり、インフラチームの時間とエネルギーを過度に奪うことなく、必要なコスト削減を実現できます。
1年以上前に下された運用予算の判断にプロダクトロードマップが縛られても、本当に構わないでしょうか?
DoiT Flexsaveは、コンピュート割引を自動で管理することで、コミットメント管理の課題を解決します。機械学習によってクラウド利用状況を継続的にモニタリングし、既存のコミットメントでカバーされていないコンピュートインスタンスを特定。該当するworkloadsに1年契約の割引率を適用し、カバレッジのギャップを埋めます。これにより、インフラコスト高騰を心配することなく、オンデマンド利用ならではの柔軟性を享受できます。節約を最大化したい場合は3年コミットメントを好きなだけ購入し、残りをFlexsaveに任せることも可能です。
一方、DoiT Spot Scalingは、中断を気にせずAWS Spotインスタンス上でworkloadsを安定稼働させるための仕組みです。ASGを自律的にモニタリングし、ベストプラクティスに沿った構成を提案。条件が合えばオンデマンドインスタンスを大幅割引のSpotインスタンスに置き換え、市場でSpotのキャパシティがゼロの状況ではオンデマンドにフォールバックします。さらにSpot Scalingは、節約額を_すべて_お客様の手元に残せる、市場で唯一のソリューションです。コミッションは一切いただきません。
DoiTが推奨するコスト最適化戦略について詳しく知りたい方は、今すぐ専門家にお問い合わせいただくか、最新のebookThe Cost Conscious Cloudをご覧ください。