コンピュートcommitmentポートフォリオ、使いこなせていますか?

commitment割引は複雑で、多大な時間とコストを要します。

commitment割引は複雑で、多大な時間とコストを要します。自動化を活用すれば、最小限の労力とリスクで節約効果を引き出せます。

パブリッククラウドが登場して以来、ユーザーは支出を最適化し、クラウドコストの暴走を防ぐ新たな手立てを模索し続けてきました。ストレージやデータベースの利用最適化も確かに有効ですが、パブリッククラウドのコスト削減で最大のチャンスとなるのは、コンピュート支出の最適化です。コンピュートコストはクラウド利用料全体の50〜80%を占めるのが一般的で、全体コスト削減を目指すうえで最優先で取り組むべき領域であることは言うまでもありません。

朗報は、Amazon Web Services(AWS)やGoogle Cloud Platform(GCP)といったパブリッククラウドプロバイダーが、1年または3年の期間で一定の使用量をコミットできるユーザーに対し、大幅なコンピュート割引を提供していることです(当然ながら、commitment期間が長いほど割引率は高くなります)。

一方で残念な知らせは、こうしたcommitment割引を活用するうえで、主に2つの課題があることです:

1. 今後1年または3年のコンピュート需要を正確に予測すること
2. commitment期間中、目標を達成できるよう使用量を管理すること

これらのハードルは、まだ若く、クラウドベースのシステムやアプリケーションを拡張中のデジタルネイティブ企業にとって、とりわけ厳しいものです。commitmentポートフォリオへの投資に伴うリスクや管理負荷を引き受けるリソースや余力がないうえに、3年後はおろか3か月後の自社のニーズすら見通しにくいからです。また、複数チームにインフラやcommitmentのニーズが分散している大企業にとっても、それらを横断したコスト管理は頭の痛い問題となります。

コンピュート需要を予測する

組織の体制によっては、パブリッククラウドのインフラ予測を単一チームが担うこともあれば、それぞれのプロジェクトやニーズに応じて複数チームで分担することもあります。

体制がどうであれ、長期間にわたって一定レベルのコンピュート使用量にコミットすることには大きなリスクが伴います。commitmentを過剰に確保すれば、未使用のコンピュートインスタンスにムダなコストを払うことになり、逆に不足すればオンデマンドインスタンスの割高な料金を支払うことになるからです。

コミットするマシンタイプやリージョンを具体的に指定するなど、コンピュートcommitmentをより精緻に設定すれば、クラウドプロバイダーから受けられる割引も大きくなります。ただし、commitmentを購入する際には柔軟性も非常に重要です。パブリッククラウドは進化のスピードが速く、ソフトウェアやビジネスモデルの変化に応じて環境を再構成しなければならない場面が出てきます。その際、柔軟性のないcommitmentを抱えていると、コストを丸ごと負担せざるを得なくなる恐れがあります。

購入できるcommitmentの種類とそれぞれの柔軟性を見ていく前に、まずコンピュート需要を予測する際に押さえておきたいポイントを整理しましょう:

• 社内の利用範囲

このcommitmentを誰が活用するのか?DevOps組織内の複数チームで共有するのか、それともチームごとに個別に購入する方が望ましいのか?

• commitment期間

どの程度先までコミットできるのか?使用量の見通しに自信があり、仕様も一貫しているなら、予測の一定割合(例:50%)をベースラインとして3年commitmentを締結し、節約効果を最大化することも検討に値します。残りは1年commitmentやオンデマンドインスタンスを組み合わせて補えばよいでしょう。

• サービス

シンプルなIaaS型コンピュート(EC2やGCEなど)だけで足りるのか?コンテナを使うのか?サーバーレスは?Kubernetesは?利用する場合、これらをすべて同じcommitmentでカバーできるのか、それとも複数のcommitmentに分けるべきなのか?分散させれば柔軟性は増しますが、その分管理負担も増す点に注意が必要です。

• マシンタイプ

デジタルサービスを構築するにあたり、各チームに必要となるマシンタイプとサイズは?そして、そのニーズが今後1〜3年で変化する可能性はあるか?

• リージョン

マシンを稼働させるリージョンを決めるのは、当面は比較的シンプルな作業かもしれませんが、ビジネスやユーザーベースが新市場へ広がるにつれ、これは重荷になっていきます。利用リージョンが今後変わる可能性があるかを見極める必要があります。変わるとすれば、現在のcommitmentでその柔軟性を確保できるのか、それとも成長に対応するため追加のcommitmentが必要になるのか?

これらの問いに答えを出したら、次はどの種類のcommitmentを購入するかを決めます。AWSとGCPはいずれも、柔軟性のレベルが異なる複数のコンピュートcommitmentプランを提供しています。これらは大きく2つのグループに分けられます:

1. リソースベースのcommitment:事前に決めた仕様に基づいて一定量の使用を約束するものです。AWSではReserved Instances(RIs)やConvertible RIs、GCPではCommitted Use Discounts(CUDs)がこれに該当します。
2. 支出ベースのcommitment:リソース仕様にとらわれず、一定の支出額にコミットできるものです。柔軟性が高い分、割引率は小さくなります。AWSではSavings Plans(SPs)、GCPではFlexCUDsとして分類されます。

クリックで拡大表示

上の図のとおり、利用しているパブリッククラウドと、それぞれが備える柔軟性の幅によって、自社のニーズに最適な選択肢を見極めるための多彩なオプションが存在します。

AWSユーザーの場合、過剰確保で生じた未使用のStandard RIsをAWS Marketplaceで再販し、コストを回収できる可能性がある点も、複雑さに拍車をかける要因です。とはいえ、特定のworkloadsに見合う買い手が必ず見つかる保証はありませんし、たとえ見つかったとしても、販売プロセス自体が担当者の業務負担と時間コストをさらに増やすことになります。

commitmentの管理と追跡

コンピュート需要を予測し、その見通しに沿ってcommitmentを購入したからといって、仕事はそこで終わりではありません。commitmentポートフォリオの管理は、購入前の予測と同じくらい、いやそれ以上に重要です。なぜなら、どれほど予測やプロビジョニングが的確でも、環境にはほぼ必ず変更が必要となり、新たなニーズに応じてポートフォリオに追加のcommitmentを購入する場面が出てくるからです。

これを踏まえ、commitmentのライフサイクル全体を通じて意識しておきたいポイントを見ていきましょう:

• commitmentとオンデマンドworkloadsのバランス

予測のセクションでも少し触れましたが、コンピュート需要が拡大するにつれ、どこまでを1年または3年のcommitmentでカバーし、どこからをオンデマンド購入に委ねるかを判断する必要があります。

• リージョンの拡大

事業やサービス提供は拡大していませんか?新たな市場のユーザーへ届けようとしていませんか?その場合、すでに支出ベースのcommitment(AWSのCompute SPやGCPのFlexCUDなど)でカバーされていない限り、新たなリージョンに対応するためのcommitmentを追加で購入する必要が出てくるはずです。

• 使用状況の継続的な追跡とモニタリング

commitmentのライフサイクル全体を通じて、使用目標に対して順調に進捗しているかを把握することが重要です。ユーザーベースの変動やビジネスモデル特有の季節性によって期間中の使用量にばらつきがあると、進捗の判断は容易ではありません。いずれにせよ、プロビジョン量を超過して超過料金を課されそうなのか(あるいは追加分をカバーする新たなcommitmentを購入すべきか)、それとも期間終了時にworkloadsが使い切れずに残りそうなのかを、把握しておきたいところです。

• 更新

commitmentを追跡しながら、期限切れの際にどう対応するか――新たに買い直すのか、構成を見直すのか、そのまま失効させるのか――を判断する必要があります。ポートフォリオが拡大し、年間を通じて更新日や失効日がバラバラに分散するようになれば、当然ながらこの課題はさらに大きくなります。

「ラクできるボタン」はないの?

ここまでの検討事項の多さに頭がクラクラしているとしたら、それはあなただけではありません。commitmentポートフォリオの管理はあまりに負担が大きく、リスクも顕著なため、多くの企業は最初から手を出さず、コストが高くついてもオンデマンドworkloadsだけで運用することを選んでいます。

しかし、コンピュートcommitmentは自動化でき、そのプロセスでリスクと管理負荷の両方を取り除けます。DoiT Flexsave™は、まさにこの目的のために開発されました。機械学習を活用するFlexsaveは、継続的なコンピュート支出を分析し、既存の割引(SPs、RIs、Spot、Enterprise Discount Programsなど)でカバーされていないAWS workloadsを特定。それらのオンデマンドworkloadsに、1年分のSavings Planに相当する割引を自動で適用します。

「Flexsaveがなければ、commitmentベースの割引はおそらく一切活用できなかったでしょう。今では、ほぼ手間ゼロで節約効果を享受できています。」 – Kyâne Pichou氏

この仕組みはここ数年で、数百社にのぼるFlexsave利用企業に対し、数百万ドル規模の節約を生み出してきました。EコマースプラットフォームのPhenixもその一例で、Flexsave導入以降、オンデマンドコンピュートworkloadsで25%超のコスト削減を実現しています。「Flexsaveがなければ、commitmentベースの割引はおそらく一切活用できなかったでしょう。今では、ほぼ手間ゼロで節約効果を享受できています」と、DevOpsリーダーのKyâne Pichou氏は語ります。「オンにするだけで、あとは存在を忘れていられる。おかげで、Phenixプラットフォームの他の機能開発に集中できています。」

こうした1年分の割引レートが、オンデマンドコンピュート支出を大きく引き下げます。さらに、Flexsaveは既存のcommitmentと並行して機能するため、すでに受けている割引を失う心配もありません。実際、多くのDoiTのお客様は、節約効果を最大化するためにコンピュート需要の一部を3年commitmentで押さえつつ、残りをFlexsaveの1年相当の割引でカバーする運用を続けています。

DoiTの他の製品・サービスと同じく、Flexsaveも利用料は無料で、コード変更やダウンタイムなしに、素早く簡単にセットアップできます。

Flexsaveや、DoiTが推奨するその他のクラウドコスト最適化戦略について詳しく知りたい方は、今すぐエキスパートにお問い合わせください。