はじめに
2023年は記録的な円安の年となりました。
筆者にとってもっとも円安の影響を感じたのが、クラウド費用でした。主要なクラウドサービスはドル払いなのが痛いです。
別に使っていた国産サービスも原油高、円安の影響を間接的に受けての値上げがあり、総じてインフラ費が膨らんだ一年になりした。
対策として、しばらくは日銀さんの円高マジックを期待していましたが、ダメそうなので2023年秋、Google Cloudの「確約利用割引」 を検討・適用してみました。本記事はそのメモから要点をまとめたものです。
確約利用割引について、Zennには以下の記事があります。
内容的には先行記事との重なる部分も多いですが、ユースケースのひとつとして参考になればと、投稿しています。
おことわり
Context
- 本記事は、2023年秋にGoogle Cloudの確約割引を検討・適用した経験に基づいています。
- Compute Engineを5年以上使用。
- 社内業務の基幹システムに使用。
- Cloud SQLへの引越し後、1年弱を経過。
- 長年運用した成熟システムでの利用。
- 社内のインフラ費用が増加傾向。不要リソースの整理など、費用削減の一環として確約利用割引を検討した。
- 社内システムはGoogle CloudのほかAWSも使用。
- 筆者のメイン業務はFinOpsではなく、チームにJoinして1年。前提知識はあまりない。
- 本記事は昨年の自分を読者として想定。
- 「べき」の使用など、文体がややdidacticな（説教ぽい）のはそのためです。
1. 用語編
なにごとも名を正すところから。英語がオリジナル言語なので、英語名も併記しています。
確約利用割引 Committed use discounts (CUDs)
特定の期間に最小限のリソースを使用することのコミットメントと引き換えに、割引料金が適用されます。
https://cloud.google.com/docs/cuds?hl=ja
「前もって〜年の間、毎月n円分を支払う約束をする代わりに割引を受けられる」仕組みです。
- 期間は1年または3年
- キャンセル不可
- 使えるサービス、SKU（後述）が指定されている
- 割引の対象となる使用量は1時間あたりの算出
- 「毎月n円分」のところは厳密には「毎時n円分」が正確です。
- たとえば、1日の間に使用量が変動する場合はややこしくなります。
- 約束した分を使いきれなかった場合は無駄になります。
- 引き落としは月々
コミットメント
「確約利用割引」の「確約」に当たる部分ですが、「約束」くらいに捉えるのがわかりやすいです。
具体的には「〜年の間、●●というサービスに毎月n円分を支払う」約束に当たります。
文脈によっては、「使用量のうち割引が適用される部分」と読むとわかりやすい場合があります。
オンデマンド料金
コミットメント分の超過使用分に課せられる料金を、CUDの文脈ではオンデマンド料金と言います。つまり、割引を適用しない場合の通常価格です。
継続利用割引 Sustained use discounts（SUDs）
名称がややこしいのですが、Compute EngineにはCUDと別体系の「継続利用割引」が存在します。
Compute Engine では、請求月の 25% 以上使用され、他の割引が適用されていないリソースに対して継続利用割引（SUD）が適用されます。
インスタンスをずっと起動させていると、月の後半にかけて割引が適用されていく仕組み。
他の割引が適用されていないリソースに対して
とある通り、CUDと重複して割引適用することはできません。
SUDもCUDもオンデマンド料金に対する割引ですが、違いは
- SUDはCompute Engine限定
- SUDは1ヶ月の範囲内での割引。CUDは1年または3年。
- SUDは月初めと月末で割引率が変わる。CUDは一定。
といったところでしょうか。
上記公式ドキュメントより
最小管理単位 Stock Keeping Unit (SKU)
N1 Predefined Instance Core running in Japanのような、課金項目を指します。
CUDが適用されるSKUには指定があるため、料金レポートでSKUを指定し、対象項目でいくらかかっているか把握する必要があります。
費用ベース Spend-based commitments / リソースベースResource-based commitments
コミットメントする対象になる使用量は「費用（ドル）」または「リソース」の2通りがあります。
費用ベース Spend-based commitments
執筆時点で下記のサービスで利用可能です。
- AlloyDB for PostgreSQL
- Bigtable
- Cloud Run
- Spanner
- Cloud SQL
-
Compute Engine
- フレキシブル確約利用割引 と別名がついています。
- Google Cloud VMware Engine
- Google Kubernetes Engine (Autopilot)
- Memorystore
具体的な例をとるならば、費用ベースのコミットメントは、
「〜年の間、asia-northeast1リージョンのCloud SQLに、1時間あたりのオンデマンド料金n円分を毎月支払う」
という形式です。
- リージョン横断／特定のリージョン
- サービスによります。たとえば、Compute Engineはリージョン横断、Cloud SQLは特定リージョンです。
- マシンタイプ、インスタンスタイプを問わない
- 請求先アカウントの複数プロジェクトで共有できる
が特徴です。
ひとくちに費用ベースCUDといってもサービスごとに詳細は異なりますので、適用前に調査が必要です。
リソースベース Resource-based commitments
執筆時点でリソースベースのCUDが利用できるのはCompute Engineのみです。
リソースベースの場合、たとえば
「〜年の間、asia-northeast1（東京）にあるN1のメモリ8GB分を支払う」
といったコミットメントになります。
実際の購入画面：Compute Engine > 確約利用割引
- 特定のリージョン
- 特定のマシンタイプ
- 対象リソースはvCPU、メモリ、GPU、ローカルSSD
- 適用範囲はデフォルトではプロジェクト内。同じ請求先の別のプロジェクトに適用する場合は、「確約利用割引の共有を有効」にする必要がある。
費用ベースに対するメリットとしては割引率が高いこと。
デメリットは、リージョン、マシンタイプ依存であるため変更に弱いこと、見積もりに技術が要ること、適切に適用し続けるためにはリソースの管理が求められることなど。
フレキシブル確約利用割引 Flexible CUDs
Compute Engineには「フレキシブル確約利用割引」があります。これは「Compute Engineにおける費用ベースCUD」と同義です。
2. 準備編
以下、Compute EngineとCloud SQLにCUDを適用する前提です。
割引検討前にリソースの整理をする
費用ベースの場合、確約は1時間あたりのコストに対して行います。したがって先に1時間あたりのコストを正常化しておかないと、最適化されたコミットメント金額を算出できません。
具体的には確約を適応したあとに、無駄リソースが残っていてそれを削減をした場合、その分のコミットメントが浮いてしまい、割引率が下がります。
また、Compute Engineのリソースベースの確約を見積もる場合は、マシンタイプが問題になってくるため、どのリージョンでどのタイプをどの構成で使っていて、いくらかかっているかを整理しておくべきです。
整理の際はFinOps hubの推奨事項が参考になります。
サービスごとのCUDを調べる
同じCUDでもサービスごとに注意すべき細目があります。具体例として、Cloud SQLとCompute Engineのケースを比較します。
Cloud SQLの場合
費用ベースかリソースベースか
Cloud SQLの場合は、費用ベース一択です。
割引対象となるSKU
Cloud SQL のコミットメントは、永続ディスクのスナップショット、ストレージ、IP アドレス、下り（外向き）ネットワーク、ライセンスには適用されません。
とあるように、対象外となる項目があります。したがって「Cloud SQLの使用額 = コミットメントの額」とするとコミットメントが浮きます。
また、Cloud SQLの場合、割引適用できるリージョンは固定です。
お支払い > 確約利用割引の分析（CUD分析） から、コミットメントできるオンデマンド費用を確認できます。
お支払い > 確約利用割引の分析（CUD分析）
これはCUD適用後のグラフ（緑がCUDの適用範囲）
具体的にCUDの対象となるSKUのリストは見つけられなかったのですが、筆者は上記に従って今のところ問題は出ていません。
結論としては推奨事項に従えば良さそうですが、後でサービスを追加したり変更したりする際にCUDを効果的に使えるように、なぜその推奨額になるのか、調べておくべきだと思います。
割引率
オンデマンド料金に対し、1 年間の確約の場合は 25% の割引、3 年間の確約の場合は 52% の割引がそれぞれ適用
となります。
実際の割引額は お支払い > 確約利用割引（CUD） から確約購入画面に進み、見積もりを見るのが早いです。入力額は1時間あたりの金額です。
お支払い > 確約利用割引（CUD）
Compute Engineの場合
Cloud SQLに比べ、選択肢が増え、難易度が上がります。
費用ベースかリソースベースか
Compute Engineの割引は、
- リソースベースのCUD
- フレキシブル確約利用割引（費用ベースのCUD）
の2種類が選べます。 大雑把にまとめるとpro/conは下記のように比較できます。
| 項目 | リソースベースのCUD | フレキシブル確約利用割引 （費用ベースのCUD） |
|---|---|---|
| リージョン | ▲ 固定 | ○ マルチ |
| マシンタイプ | ▲ 特定のマシンタイプ | ○ 対象マシンタイプ間で移動可能 |
| 割引率 | ◎ 高い | ○ リソースベースに劣るが高い |
| 管理コスト | ▲ 高い。リソース追加・変更がしにくい | ○ リソースの追加、変更がしやすい |
継続利用割引 Sustained use discountsの確認
前述の通り、SUDとCUDは重複しません。
すでにSUDが適用されているCompute Engine（N1、N2、N2D、C2、M1、M2）にCUDを適用すると、CUDでカバーされる分はSUDが効かなくなりますので、CUDによる割引率が目減りします。
具体的な検証はしていませんが、SUDは最大30%の割引なので、フレキシブル確約利用割引を1年適用する場合、割引率が劣後するシナリオもありそうです。
実際にSUDが適用されていた時期のN1のコスト
割引率
フレキシブル確約利用割引
フレキシブル確約利用割引の場合は、
1 年コミットメントで確約した時間あたりの使用額に対して 28% 割引
3 年コミットメントで確約した時間当たりの使用額に対して 46% 割引
これも実際にお支払い > 確約利用割引の分析で推奨事項を見るのが手っ取り早いです。
注意点として、表示される見積もりの割引額はSUDを考慮していません。SUDが適用されている場合は、見積もりの割引額より割引幅は小さくなります。（筆者の場合はそうでした。）
念のため料金レポートでSKUを指定して確認することをお勧めします。
対象となるSKUは下記で確認できます。vCPU またはメモリに対してのみでリソースベースと差異があります。
リソースベース
リソースベースの場合は、ケースバイケースなので、実際にコミットメント購入画面の見積もりを見ることをお勧めします。
筆者が試したときはCPU、RAMともに1年：37%／3年：55%でした。当然ながら制約が強い分、Flexible CUDより割引率が高くなっています。
Compute Engine > 確約利用割引から、購入するリソースを指定すると見積もりがでます。
確約利用割引-$54.38
どのリソースを確約するかは、Compute Engineのページや料金レポートでSKUを指定して決めていく必要があります。
1年か3年か
確約期間は1年か3年かを選択できます。違いはもちろん割引率です。
IT業界の3年というと、disruptiveな技術はいくらでも出てくる余地があります。Google Cloud内に限っても価格やモデルが変わるでしょう。1年確約がよいか3年確約がよいかを予想するのは、先物取引としてかなり難しい印象です。
これを弁えた上で、社内のリソースや事業計画と照らしたり、上手くいかないケースを想定した上で、振り返りのできる決裁記録を残して、いまベストだと思う方にするしかないと思います。
3年にするにもコミットメントの量を控えめにしてリスクヘッジすることも選択肢です。ただし、あまり細かく調整したり、時期をずらすと管理が大変になります。
他社ベンダーの同様の確約割引と比較する
CUDのトレードオフは当然ながら、そのサービスプロバイダにロックインされること。
筆者はAWSのRDSやAuroraを確約したケースと費用を比較し、Cloud SQLの方が高くならないか、決裁前に確認しました。
競争原理が働くので移行コスト込みで価格優位なサービスはなかなかないとは思いますが、後悔しないように確認しておくべきところです。
社内外の第三者に相談する
考えることの多いCUDですが、いざ適用してみるまで確実なテストが難しく、誤適用の場合にキャンセルもできません。（お試し適用があるといいのに...）
筆者の場合はGoogle Cloudを契約しているリセーラー（代理店）にも確認をしてもらいました。
また、公式ドキュメントを読み込むのはもちろんですが、実際に適用したユーザーの記事も心理的な助けになりました。
1年か3年かは、上司はもちろんIT事業部外の経営サイドともよく確認した上で適用しました。
これらは多面的にリスクアセスメントして最適な確約プランを選ぶことも目的のひとつですが、個人的には後で認識違いがないように合意をしっかりとっておくことを重要視しました。
3. 適用編
支払いは毎月
前述のようにコミットメントの支払いは一括ではなく、毎月です。
単月のキャッシュフローが歪む心配はありません。また、ドル円の為替影響も分散されます。
単月にドンと費用が乗らず、見かけ上はこれまでのGoogle Cloudの請求費用が安くなるだけなので、経理さんとの連携は楽でした。
Coverageはすぐには反映されない
お支払い > 確約利用割引（CUD） からCUDの適用状況を確認できます。
コミットメント分をしっかり使えているかは、Trailng 30-day utilization でチェックできます。
これらの指標は適用直後は安定しません。先行記事にも
確約利用割引を購入した翌日に費用のレポートを確認したら、Cloud SQLの方だけ対象範囲が0%だったので、設定をミスって会社のお金を溶かしたかと思って焦りました。
https://zenn.dev/team_zenn/articles/zenn-used-cud
とありますが、私も「設定をミスって会社のお金を溶かしたかと思」いました。数日後に確認すると反映されていました。
すぐには反映されないことを先に知っておくと安心できますね。1週間経っても反映されなかった場合は焦りましょう。
リソースを追加・変更する場合は割引対象サービスに注意
CUDは、サービスの費用の全額ではなく、一部の費用に対してのみ適用されるケースがあります。
たとえば、Cloud SQLのCUDの場合、先述の通りスナップショットには適用されません。
したがって、余ったコミットメントを埋めるつもりでスナップショット作成、などしないように注意が必要です。
とりわけ、Compute EngineのリソースベースCUDを選択した場合、追加・変更がシビアになります。例として、マシンタイプをグレードアップするとCUDが外れます。
適用期限はGoogleカレンダー等にメモ
あえて書くまでもないですが、1年後、3年後に覚えているか、またチームに在籍しているかもわからないので、CUDの期限を通知付きのチームカレンダーにメモをしておきましょう。適用時の判断記録（GitHub Issueなど）のリンクをあわせてメモすると将来の継続／見直し判断の助けになります。
実際、筆者もリソース調査の過程で人知れず期限切れしていた3年確約を見つけました。
リソースベースの場合、リージョンやマシンタイプを間違えるとCUD対象外になるので、CUDの内容がチーム内で共有されていることが重要です。これも実際にマシンタイプをN1からN2にアップグレードして、確約が外れているケースを目の当たりにしました。
おわりに
CUD適用に当たって、昨年の自分に教えたかった事項をまとめました。
長期で大きな金額が絡むわりに用語や必要知識も多く、適用にドキドキするCUDですが、うまく適用できた際の割引インパクトは大きいです。（費用ベースの場合、1年でおよそ30%、3年で半額）
FinOps hubの登場でCUDもより適用しやすくなっていますので、気になった方は、それぞれのユースケースに沿って一度検討してみてください。
参考記事
- 公式ドキュメント各種（記事内に記載）
- 「【請求管理】Google Cloud BillingのFinOps hubで効率的に費用の削減を行う」
- 「Google Cloudの利用費を節約できる確約利用割引を購入してみた」
- 本記事で扱わなかったCloud Runの事例を掲載されています。
Discussion