コミットメントは動く標的。純正レコメンダーでは追えない。だから自分たちで作った。

エンジンが数字を導き出す仕組み

実はエンジンは2つあります。AWS Savings Plans用と、Google Cloudの確約利用割引(CUD)用です。コードは別々です。2つのクラウドではコミットメントの価格設定と適用方法が本質的に異なり、同じものとして扱えば精度を犠牲にすることになるからです。ただし、根底にある考え方は共通です。

すべては生の使用データから始まります。ルックバック期間中にコミットメントが適用され得る支出を、1時間単位ですべて取り込みます。60日間のウィンドウなら、約1,440時間分の正確な金額を個別に見ることになります。非常に忙しい時間帯もあれば、特に週末の落ち込みが来ると完全に静まり返る時間帯もあります。この激しく変動する形状をどう扱うかが、本当の課題です。

次に、すでに保有しているものを差し引きます。有効なSavings PlansやCUDがあれば、クラウドプロバイダーと同じ方法——割引率の高いものから順に——で各時間に適用します。既存のプランがすでにカバーしている分は対象外です。残ったものが、新しいコミットメントでまだ節約できる支出です。

すでに適用されているあらゆる割引も考慮します。交渉済みの契約価格。Google Cloudの継続利用割引。DoiTのFlexsaveを利用している場合は、そのカバレッジも。コミットメントは、今実際に支払っている価格を下回って初めて意味を持ちます。だから比較対象は定価ではなく、実際の支払価格なのです。

エンジンが2つに分かれているのは、AWSとGoogle Cloudでは請求データの公開方法が異なり、コミットメントの適用ルールも独自だからです。ただし原則は共通しています。コミットメントは、請求書に載ることのない定価ではなく、実際に支払っている価格と比較して評価する、ということです。

ここからが本題です。

購入し得る時間単位のコミットメントをひとつ選んでみてください。対象期間中に支払うのは2つです。コミットメント自体の料金——使っても使わなくても、毎時間発生します。それに加えて、忙しい時間帯にあふれ出るオンデマンド支出。この2つを合計したものが、そのコミットメント水準での総コストです。

簡単な例を挙げます。ある1時間に100ドルの対象支出があり、わかりやすく40%割引で毎時30ドルをコミットしているとします。この30ドルで50ドル分のオンデマンド使用がカバーされます。つまりコミットメントに30ドル、残りにオンデマンドで50ドル、合計80ドル。100ドルではなく。ここまでは順調です。では、対象支出が40ドルしかない静かな時間帯はどうでしょう。30ドルで変わらず50ドル分のカバレッジを買っていますが、カバーする対象は40ドルしかありません。支払いは30ドル、節約は10ドル、そしてコミットメントの一部はただ遊んでいます。レコメンダーはこの計算をウィンドウ内のすべての時間に対して行い、合計します。さらに、推奨し得るすべてのコミットメント水準について同じ計算を行い、どれが最も節約できるかを調べます。

この総コストをコミットメントの規模に対してプロットすると、お椀型の曲線になります。お椀の底がスイートスポット、つまり総請求額が最も低くなるコミットメントです。

左側はコミット不足の領域です。コミットメントを1ドル増やすごとに、1ドル以上のオンデマンド支出が置き換わるため、総コストは下がります。右側はコミット過剰の領域です。静かな時間帯に余剰のコミットメントが遊休状態になるため、総コストは再び上がります。

お椀の底は、コミットをあと1ドル増やすと、節約額より支払いのほうが大きくなる転換点です。これが最適なコミットメントです。私たちは、1セント刻みですべての値を試して最安を探すような方法は取りません。曲線の形状が転換点の位置を教えてくれるので、その点に直行します。

次にリスクポリシーを選びます。Conservative、Balanced、Max Savings、あるいは独自に定義したもの。それぞれが最適コミットメントの一定割合——65%、80%、90%——を採用し、使用量が落ち込む週に備えた余裕を残します。カスタムポリシーはさらに踏み込めます。お客様ごとに最大10個まで、それぞれ独自のカバレッジ目標と購入ステップを設定できるため、推奨はクラウドベンダーが用意した3つのプリセットではなく、あなたのルールに従います。この余裕がなぜ重要か、そしてなぜ一括ではなく段階的に購入するのかについては、サイジング問題を扱った以前の記事で詳しく書きました。

その上に、いくつかの調整つまみがあります。実際の購入から学んだことに応じて、私たちはこれを調整します。その役割は、推奨値を最適コミットメント値よりも慎重な側に保つことです。

たとえば、お椀の底が平坦に見えるケースがあります。ひとつの正確な数字ではなく、ある範囲のコミットメントがほぼ同額の節約をもたらすのです。計算上は迷わず最大のものを選ぶことになりますが、私たちはそうしません。複数のサイズがほぼ同じ節約をもたらすなら、最小のものを選びます。節約額は同じで、固定される資金は少なく、来月workloadが消えても余裕が残ります。

調整つまみによって、本番環境で観察した事象にも対応できます。ウィンドウ期間中にアカウントの使用量が下降傾向なら、推奨は小さめに傾きます。購入がモデルの予想より役に立たなかった場合は、そこから学習し、次の推奨はより慎重になります。

そして、エンジンが自社製だからこそ、お客様から具体的な要望——たとえば「使用率が70%を下回らないようにしてほしい」や「第3四半期にアカウントを統合するので余裕を残してほしい」——があれば、それに応えられます。AWSやGoogleに、あなたのルールでレコメンダーを動かすよう頼むことはできません。でも私たちには頼めますし、独自のポリシーを作成すれば、私たちはそれに従います。

クラウドと一致する部分

違いの話をする前に、信頼の話をしましょう。もし当社の数字がクラウドの数字と大きく離れていたら、どちらが間違っているのかと問われて当然です。

だから検証しました。

まず正しくなければならないことが1つあります。そうでなければ比較全体がノイズになります。両方のレコメンダーが同じ日数の使用量を見ていること、です。すべてのレコメンダーは、ルックバックウィンドウ、つまり過去の一定期間の時間データに基づいてサイジングします。AWSでは過去60日まで選択できます。当社エンジンは任意の期間に設定できます。2つのウィンドウが数日でもずれていれば数字は違ってきますが、その差は手法とは無関係で、日付の問題でしかありません。そこで以下のすべての比較では、AWSやGoogleが使用したのとまったく同じ開始日・終了日に当社エンジンを合わせました。入力する日数を揃えてから、出力を比較するのです。

AWSでは、複数のアカウントでAWS Purchase Analyzerと当社エンジンを比較しました。すべての組み合わせをテストしています。1年と3年の期間、前払いなし、一部前払い、全額前払い。ルックバックウィンドウは両者で同一です。当社の推奨コミットメントは、すべてのケースでAWSの数字の1%以内に収まりました。また、スケールに耐えることを確認するため、AWSをご利用の当社最大規模のお客様でもエンジンを実行しました。問題なく動作します。

Google Cloudでは、GCPコンソールに表示される推奨と比較しました。標準価格の請求アカウントでは、テストした8つのコミットメントスコープすべてで、セント単位までGoogleと一致しました。これには、Compute Flexible CUD、Memorystore、各リージョンのCloud SQLが含まれます。交渉済み割引のあるアカウントでは、1%以内でした。

クラウド	アカウントタイプ	テストしたスコープ数	クラウドの数字との比較
AWS	中規模の支払いアカウント、すべての期間・支払いオプションの組み合わせ	6	1%以内
AWS	当社最大のお客様	6	問題なく動作、1%以内
Google Cloud	標準価格	8	セント単位で完全一致
Google Cloud	交渉済み割引	8	1%以内

ポイントはシンプルです。同じ質問をすれば、同じ答えが返ってきます。多く売りつけるために数字を水増ししている者は、誰もいません。

では、なぜ自社で作ったのか。

クラウドが止まるところから、その先へ

以下は、お客様が実際に尋ねる質問です。いずれの場合も、クラウドのレコメンダーは答えられないか、長く待たせるかのどちらかです。詳細の前に、要点を表にまとめます。

	AWS	Google Cloud	DoiT
推奨の精度	ベースライン	ベースライン	両者の1%以内
すべての期間・支払いオプションをオンデマンドで	1日20回の分析、1件ずつ	一部のシナリオのみ	全組み合わせを20秒以内
同期API	非同期ジョブ、数分間ポーリング	提供なし	あり
数字が動いた理由の説明	不可	不可	可能、請求データの行レベルまで
アカウントやSKUによるスコープ指定	不可	不可	可能
カスタム日付範囲	一部のみ	一部のみ	可能
購入日のクラウドAPIからの独立性	なし	なし	あり、請求データを直接読み取り
自動化された段階的購入	なし	なし	あり
期限切れコミットメント	期限切れ後に再推奨	期限切れ後に再推奨	期限前に代替をサイジングしスケジュール
人による使用率モニタリング	なし	なし	あり、DoiT専任チーム

「決める前に、1年と3年、前払いなしと全額前払い、3つのリスクレベルを比較したい」

AWSでは、それぞれが個別の分析になります。Purchase Analyzerで実行できるのは、支払いアカウントあたり1日20回の分析まで。各分析には数秒から数分かかり、1件ずつしか実行できません。1つの支払いアカウントの全体像を見るには、AWSが1日に許可する以上の分析が必要です。だからいくつかを選び、待ち、正しく選べたことを祈るしかありません。

Google Cloudはこの点では柔軟です。コンソールでは異なるルックバック期間でシナリオを構築でき、特定の日付の除外もできます。便利です。しかし、そこまでです。Googleが考えたオプションを、Googleの条件で使えるだけで、そのリストの外に出たければ自力でやるしかありません。

当社エンジンは、支払いアカウントのすべての組み合わせを20秒以内に生成します。何度でも実行できます。

「推奨を自社ツールに組み込みたい」

AWSのレコメンダーは非同期ジョブです。開始してから、数秒〜数分後に終わるまでポーリングし続けます。その上に信頼できるパイプラインを構築するのは手間がかかり、1日の上限も変わらず適用されます。

Google Cloudコンソールの推奨は読むために作られており、購入ワークフローに流し込むためのものではありません。

当社のものは同期REST APIで、DoiT Cloud Intelligence APIの一部です。APIキーでエンドポイントを呼び出すと、同じレスポンスで推奨が返ってきます。AWSでもGoogle Cloudでも同じ形式なので、1つの統合で両方をカバーできます。毎日の推奨をSlackに投稿する、しきい値を超えて動いたらチケットを起票する、他のコストデータと並べて自社のFinOpsダッシュボードに取り込む、といったことが可能です。

さらに、シンプルな同期APIなので、ダッシュボードと同じくらい簡単にAIアシスタントにも接続できます。Claudeでも、普段お使いのものでも接続して、言葉で尋ねてください。「us-east1のCloud SQLの推奨は?」「次のコミットメントはいつ期限切れ?」「先月、コンピュートのコミットメントでいくら節約できた?」。コンソールに同じことを聞いてみてください。

すべてが事前計算済みでもあります。すべてのオプション、すべてのポリシー、すべてのアカウントを、1日1回。だから、あなたやアシスタントが尋ねたとき、キューに入ることも、レート制限されることも、オプションごとに待たされることもありません。答えはすでにそこにあります。

「なぜ先週から数字が変わったのか?」

あるAWS支払いアカウントの推奨が、1週間のうちにかなり異なる2つの水準の間を動くのを、私たちは観察しました。使用量に、それを説明するものは何もありませんでした。私たちの見立てでは、ローリングウィンドウと、問い合わせる曜日が原因と考えられます。しかし確信は持てません。Purchase Analyzerは、検証できるほど明確に計算過程を示さないからです。

当社エンジンが出すすべての数字は、請求データの行まで遡れます。お客様から推奨が動いた理由を聞かれたら、どの時間帯がどれだけ変わったかをお見せできます。多くの場合、答えは単純です。夜間のバッチジョブが止まった、木曜日に新しい環境が稼働した、など。いずれにせよ、はぐらかされることなく、答えが得られます。

「そのアカウントは廃止予定なので無視してほしい」

あるいは「このSKUは除外してほしい、そのworkloadは移行中だから」。あるいは「デフォルトのウィンドウではなく、前四半期でサイジングしてほしい」。

どちらのクラウドも、アカウント別、SKU別、明示的な期間別に推奨のスコープを指定することはできません。支払いアカウント全体に対する1つの答えを、クラウド側が選んだウィンドウで受け取るだけです。

当社エンジンは3つすべてに対応します。アカウントの除外。特定SKUの一部除外。開始日と終了日の独自設定。対象範囲の指定も細かくできます。そもそもどのリンクアカウントやプロジェクトをコミットメントの対象とするかは設定項目であり、エンジンはその範囲だけを基にサイジングします。現在は当社が設定を行いますが、セルフサービスでの操作も近日提供予定です。その先には、どちらのコンソールも公開していない調整項目がさらにあります。

率直に補足すると、現時点でこれらはコンソール上のセルフサービスのボタンではありません。除外対象や使用する日付をDoiTチームにお伝えいただければ、その設定でエンジンを実行します。重要なのは、そもそもそれが可能であること、そして答えがその日のうちに返ってくることです。そして、これらはすべて視野に入っています。調整つまみをお客様の手に委ね、すべてをご自身で制御できるようにするつもりです。

「購入日にCost Explorerがダウンしていたら?」

エッジケースに聞こえるかもしれませんが、実際に起きるまでの話です。コミットメントのサイジングは一度きりの仕事ではありません。サイジングの記事で論じたとおり、使用量が足元で変化する中、毎週当て続けなければならない動く標的です。しかも標的は増えていきます。2つのクラウド、コンピュートとデータベース、複数のリージョン、それぞれに独自のコミットメントと期限日。これは週1回の意思決定ではありません。1件ではなく12件の意思決定です。

外部ジョブに依存するレコメンダーは、どこかで一手を落とす可能性があります。APIが遅い、レート制限されている、障害発生中であれば、その週の購入は行われません。当社のものは請求データを直接読み取ります。待たされる外部要素は何もありません。

「付きっきりで面倒を見たくない」

実は、これこそが「なぜあなたたちのツールが必要なのか」に対する本当の答えです。

推奨は、誰かがそれに基づいて行動して初めて役に立ちます。当社エンジンの推奨は、自動化された段階的購入の仕組みに直接つながっています。購入は裏側で、お客様が管理するペースで、選択したポリシーに応じたステップサイズで実行されます。そしてDoiTの専任チームが、すべてのコミットメントの使用率を監視しています。遊休状態になり始めたものがあれば、請求書上の無駄になる前に捕捉します。AWSでは、返却可能な期間内にSavings Planを返却することさえあります。

期限切れも同じように処理されます。プランの期限が近づくと、次の推奨はすでにそれがなくなった前提で計算され、旧プランが終了する瞬間に代替が開始されるようスケジュールされます。誰かが気づくまでの1週間、カバレッジが落ちることはありません。クラウドのレコメンダーは、ギャップが開いた後にしか認識できません。

まもなく、現在すでに選択できるリスクポリシーに加えて、購入ペースのポリシーもお客様自身で定義できるようになります。