Google Cloudは支出ベースCUDの仕組みを根本から作り直しました。クレジットで相殺する従来方式から、割引価格を直接適用する方式へと切り替わり、対象もメモリ最適化VM、HPC、Cloud Runまで広がっています。昨日の時点で全顧客が新システムへ移行済みです。本記事では、この変更がクラウドコストとFinOpsダッシュボードに何をもたらすのかを整理します。
旧モデルは「請求パズル」だった
オンデマンドコスト、コミットメント料金、クレジットによる相殺額をやりくりしながらCUDの節約額をはじき出した経験はないでしょうか。これがGoogleの従来型・支出ベースCUDの仕組みでした。たとえばオンデマンド支出$100/時間にコミットすると、(46%割引で)コミットメント料金$54/時間を支払い、利用料金を相殺する-$100のクレジットを受け取る——という流れです。計算上は辻褄が合っていても、顧客や財務部門に説明するのは骨が折れる作業でした。
新しいマルチプライスモデルは、この複雑さを一気に解消します。クレジットを介在させる代わりに、Googleは「consumption models(消費モデル)」と呼ばれる仕組みを通じて、割引をSKU価格に直接反映するようになりました。実際の割引後支出額($54/時間)にコミットし、その金額を支払い、利用分は割引価格で計上されます。別建てのクレジットも、頭の中の換算作業も不要です。
この変更により、BigQueryエクスポートに出力されるCUDデータの形式も大きく変わります。自社で構築したFinOpsダッシュボードやコスト配賦システムをお持ちであれば、改修が必要です。私たちDoiTでも同じ道のりを経験してきました。
技術面での変更点
今回の移行で押さえておくべき大きな変更は3つあります。
1. コミットメントの計算方法が反転しました。従来はオンデマンド換算の支出額に対してコミットしていましたが、新モデルでは実際の割引後の時間単価にコミットします。46%割引で$185分のオンデマンド利用をカバーするコミットメントは、これまで「$185/時間のコミットメント」と表現されていましたが、新モデルでは実際に支払う金額である「$100/時間のコミットメント」と表現されます。CUD Recommendationsツールも同様に更新されています。コミットメント額を算出する自動化スクリプトをお持ちであれば、見直しが必要です。
2. BigQueryスキーマに新しいフィールドが追加されました。最大のポイントは、idとdescriptionを含むconsumption_model structです。3年Compute Flexible CUDで利用がカバーされる場合、独立したクレジット行として現れる代わりに、descriptionに "Compute Flexible CUDs 3 Year" と記録されます。さらに、クエリでオンデマンド価格と割引価格を区別しやすくするため、price.list_price、price.effective_price_default、cost_at_list_consumption_model といったフィールドも追加されています。
3. 料金SKUの構造が再編されました。新しいCUD料金SKUは$1/時間で価格設定され、FEE_UTILIZATION_OFFSET という相殺用クレジットタイプとセットになっています。CUDが完全に活用されている場合は、料金と相殺額が打ち消し合ってゼロになります。活用しきれていない場合は、未使用分が課金として表示される仕組みです。これにより、請求データには1つのCUDにつき2行が記録されます。1行は割引価格でカバーされた利用分、もう1行はオンデマンド価格で発生した超過分です。
FEE_UTILIZATION_OFFSET
対象範囲の拡大で広がる節約のチャンス
Compute Flexible CUDは、これまで別種のコミットメントが必要だったり、そもそも割引対象外だったworkloadsまでカバーするようになりました。
メモリ最適化VMがついにFlex CUDの対象に。M1、M2、M3、M4のマシンファミリーがCompute Flexible CUDの対象に加わりました。ただし対象は3年契約のみで、割引率は63%です。ここに重要な落とし穴があります。1年コミットメントの場合、メモリ最適化VMには割引が一切適用されません。未活用のコミットメントが、節約効果ゼロのまま消化されてしまいます。SAP HANAや大規模インメモリデータベースのようなメモリ集約型workloadsを運用している場合、3年コミットメントの魅力は格段に高まります。
HPCファミリーも仲間入り。H3および新登場のH4Dコンピュート最適化ファミリーがFlex CUDの対象となり、1年契約で17%、3年契約で38%の割引が適用されます。現在プレビュー中のH4Dは、第5世代AMD EPYC Turinプロセッサ(192コア)、最大1,488GBメモリ、200Gbps RDMA対応ネットワークを備えた、本格的なコンピュートworkloads向けの「重戦車級」ハードウェアです。
Cloud Runも幅広くカバー。Cloud Runサービス(旧Cloud FunctionsであるCloud Run functionsを含む)のリクエストベース課金が、1年・3年とも17%でCompute Flexible CUDの対象となりました。インスタンスベース課金、ジョブ、ワーカープールについては、引き続き28%/46%の割引が適用されます。サーバーレスworkloadsを大規模に運用しているなら、ユニットエコノミクスへの影響は無視できないはずです。
新しい支出ベースの割引体系をまとめると、次のとおりです。
節約額の見え方が変わる
移行後、FinOpsダッシュボードの「Savings(節約額)」列には、これまでより大幅に小さい数字が並びます。以前-$10.00と表示されていたものが、-$4.50になることもあります。仕組みを理解するまでは、思わずヒヤッとする変化です。
旧モデルでは、オンデマンドコスト全体を相殺するグロスのクレジット額が表示されていました。新モデルが示すのは実際のネット節約額、つまりオンデマンド料金で支払うはずだった金額と、実際に割引価格で支払った金額の差額です。最終的な請求額も実際の節約額も、どちらの方式でもまったく同じ。変わったのは見せ方だけです。
今回の変更で、実際の割引率は一切変わりません。3年Compute Flexible CUDなら汎用コンピュートで46%の節約、1年コミットメントなら28%の節約というのも従来どおりです。お客様の懐から出ていく金額は、移行前後でまったく同じ。Googleが変えたのは節約額の表示方法であって、計算方法ではありません。ここは社内にも明確に伝えておきたいポイントです。
大きなクレジット数値を見慣れているCFOやステークホルダーへの説明も欠かせません。「なぜCUDクレジットが55%も減ったのか」と問われたら、これまでの会計上の相殺額ではなく、実際の節約額が表示されるようになったのだと伝えてください。
よくいただく質問
オプトインしないと、コミットメント額は増えますか?
いいえ。Googleが自動移行を行う際、既存のコミットメントは新モデル下での同等の値に変換されます。$185/時間のコミットメント(オンデマンド換算で表現)をお持ちの場合、$100/時間のコミットメント(実際の割引後支出額)に置き換わります。カバー範囲もコストも同じで、変わるのはラベルだけです。財布から出入りする金額はそのまま、レポートの表示だけが変わります。
移行後、既存のCUDのカバー範囲は狭くなりますか?
いいえ、むしろ逆です。すべての既存CUDは、これまでと少なくとも同じ範囲をカバーし続け、対象拡大によりより多くのSKUをカバーするものもあります。現在Compute Flexible CUDをお持ちなら、Cloud Runのリクエストベース課金、H3/H4Dインスタンス、メモリ最適化VMなど、新たに対象となったworkloadsも自動的にカバーされ始めます。すでに購入済みのコミットメントの活用度がさらに高まるということで、お客様側で何か作業をする必要はありません。
では、実際に何が変わるのですか?
表示とデータ構造です。割引率は変わりません。コミットメントコストも変わりません。カバー範囲は同じか拡大します。変わるのは次の3点です。
- コミットメント額の表現方法
- 請求エクスポートでの節約額の表示形式
- カバー対象となるSKU
変更点はこれだけです。
リソースベースCUDは変更なし
今回の移行で影響を受けない部分も改めて押さえておきましょう。リソースベースの確約利用割引——特定のリージョンとプロジェクトでvCPU、メモリ、GPU、ローカルSSDの数量にコミットするタイプ——は、これまでとまったく同じように動作し続けます。リソース要件が一定で、予測可能な定常的workloadsには、引き続き最適な選択肢です。
主な違いも従来どおりです。
- リソースベースCUDはプロジェクトとリージョンに紐づきます(請求アカウント単位での共有を有効化することは可能です)。
- 支出ベースFlex CUDは、請求アカウント内の対象となるすべての利用に自動的に適用されます。
リソースベースコミットメントは、汎用コンピュートで割引率がやや高め(3年で最大55%、Flexの46%に対して)ですが、より精度の高いキャパシティプランニングが求められます。
多くの組織におすすめしているのは、両者を組み合わせる戦略です。安定して予測可能なベースラインのworkloadsにはリソースベースCUDを、リージョンやマシンタイプで特定しにくい変動的・分散的な利用にはFlex CUDを——これが最適解です。
新しいマルチプライスCUDモデルは、近年で最も大きなGoogle Cloudの請求体系の変更です。対象範囲の拡大と、よりクリーンになったデータモデルは大きな進歩。あとは、その恩恵を最大限に引き出せるよう、社内システムを整える番です。DoiTのサポートをご希望でしたら、ぜひご相談ください。