支払ったぶんだけ得る: チャージバック プロセスの設計原則
Google Cloud Japan Team
※この投稿は米国時間 2023 年 2 月 1 日に、Google Cloud blog に投稿されたものの抄訳です。
チャージバック プロセスの設計原則
大規模な組織では、クラウド フットプリントが拡大するにつれ、費用を効果的に管理することが重要になります。各ワークロードの実行費用と、そのワークロードがビジネスにもたらす価値をよく理解すると、組織はクラウドの利用効率に自信を持つことができます。財務説明責任と費用効率の推進に成功している多くのお客様が Cloud FinOps フレームワークを採用しているのは、このためです。
Cloud FinOps の重要な機能として、チャージバックが挙げられます。これは、クラウド利用を組織内の利用者にマッピングし、クラウド サービス費用を回収しやすくするプロセスです。これにより、個々のチームがクラウド利用に責任を持つようになり、インセンティブが共有され、透明性が得られます。お客様の選択したビジネス インテリジェンス ツールを使用して、Cloud Billing からエクスポートされた詳細な課金データと組織のデータを組み合わせることで、チャージバックをうまく実装できたお客様もいらっしゃいます。
チャージバック プロセスを構築したことがないクラウド アーキテクトの方がほとんどかと思います。このブログ投稿では、Google Cloud で効果的なチャージバック プロセスを設計する際のおすすめの方法を紹介します。
チャージバックの粒度を決定する
大規模な組織は、クラウドの使用量を割り当てる際の粒度を選択する必要があります。通常、使用費用はチームまたは組織部門ごとに割り当てられますが、さらに細かい、またはより大まかなアプローチを選択することもできます。正解はありません。より広範なビジネス目標に合ったレベルで費用を割り当てることが大切です。
利用者ワークロードとプラットフォーム サービスを区別する
通常、大規模な組織ではワークロードが 2 種類あります。1 つのチームが完全に所有する利用者ワークロードと、マルチテナント サービスを組織内の利用者に提供するプラットフォーム ワークロードです。費用割り当ては、ワークロードの種類ごとに異なる扱いをする必要があります。一般的に、利用者ワークロードは、チャージバックにおいて全体を 1 つのチームに割り当てることができます。その一方でプラットフォーム サービスは、テナント利用ごとに分け、それに応じて割り当てる必要があります。
プロジェクトとリソースにラベルを付けて使用量を区別する
別々のチームに割り当てる必要のある使用量を区別するには、ラベルまたはタグを使用します。ラベルは、リソースを整理するために適用できる Key-Value ペアです。こうしたラベルは Cloud Billing データのエクスポートに含まれるため、リソース使用量をコストセンターまたはチームに割り当てるために効果的に使用できます。
チャージバックを効率的な支出を促進するインセンティブとして使用する
大規模な組織のチャージバック システムの設計とは、結局のところ、チームがクラウド費用をプロアクティブにモニタリングするためのインセンティブを設計することです。この視点は、さまざまな使用量の割り当てを決定するために使用する必要があります。あるチームに、別のチームが所有し運用している使用量を割り当てると、支出を削減するインセンティブがなくなるため、リソースの効率的な使用にはつながりません。
プロダクトの料金構成に合わせたアトリビューション
Google Cloud サービスの課金方法はさまざまです。使用量ベースの包括料金を使用しているものもあれば、さまざまな使用量について詳細な SKU 内訳を設定しているものもあります。一般的に、あるサービスの使用量は、その課金方法と同じ方法で割り当てることが最も簡単かつ効果的です。たとえば Cloud Storage の料金は、データ ストレージ、データアクセス、ネットワーク使用量の 3 つに分けられています。
BigQuery への Cloud Billing データのエクスポートを使用する
支出をグループ化して割り当て、コストセンターのデータと統合するには、BigQuery への Cloud Billing データのエクスポートを有効にすることをおすすめします。利用できるレポートは、標準的な使用料金データ、詳細な使用料金データ、料金データの 3 種類です。特に、詳細な使用料金データは、プラットフォーム サービスの詳細な支出を割り当てる際に便利です。料金データには、お客様の請求先アカウントに適用される SKU レベルの料金情報が含まれ、割引カスタム料金でワークロードの料金見積もりを作成する際に便利です。
アトリビューションが必要な費用を決定する
すべての費用をチームに関連付ける必要はありません。複雑にならないように、ネットワーク（下り、外向き）のような共有リソースを組織レベルで割り当てることを選ぶ組織もあります。通常は、費用の割り当て比率が高くなるほど、チームが効率的に支出を管理するインセンティブが強くなります。ただし、共有リソースを多く割り当てるようにすると、チャージバック システムの複雑さが増します。
BigQuery
BigQuery は、大規模な組織が費用対効果の高い分析、機械学習、BI に使用するサーバーレス データ ウェアハウスです。大規模な組織では通常、専用の処理能力に対する定額のコミットメントを使用します。定額のスロット コミットメントでは毎月の費用が安定しますが、組織内の利用者に費用を関連付けることが難しくなることがあります。
使用する課金モデルを明確にする
BigQuery の料金は、分析料金、ストレージ料金の 2 つに分けられています。分析料金では、BigQuery 内でのクエリの実行はオンデマンド料金または定額料金となります。オンデマンド料金では従量課金モデルにできます。予約のためにスロットを購入し、その予約内のすべてのクエリでスロットを共有するという定額料金モデルと比較して、チャージバックが簡素化されます。詳細については、BigQuery リソースの整理をご覧ください。
定額スロット使用量のアトリビューション
BigQuery に定額料金を使用している場合、クエリジョブのチャージバックは、各チームまたはプロジェクトのクエリジョブで使用したスロットミリ秒の合計から算出できます。このデータは、Cloud Billing データの「Analysis Slots Attribution」項目か、BigQuery 自体の INFORMATION_SCHEMA テーブルで把握できます。利用したスロット リソースの合計で予約費用をチャージバックすることで、チームに対して、予約を適正化し、本番環境ワークロードでアイドル スロット使用量に依存しないよう促すことができます。
共有予約を検討する
組織が BigQuery で実行するクエリの大部分は、データを分析するためのもの（クエリジョブ）です。ただし大規模な組織では、予測可能なパフォーマンスを提供するために、読み込みジョブにスロットを使用することもあります。組織によっては、予約階層の最上位にあるスロットの「デフォルト」プールを使用して、規模の大きなクエリに共有スロットを提供することもあります。このようなスロット予約は、個々のクエリレベルでしか組織内のチームに関連付けることができません。簡単にするために、クエリリソース使用量に比例して予約を割り当てるのではなく、予約を中央チームに関連付けることもできます。
マルチテナント GKE クラスタ
Google Kubernetes Engine では、自動のプロビジョニングと管理や、Pod とクラスタの自動スケーリングをサポートしており、エンタープライズ規模の Kubernetes クラスタを簡単に運用できます。大規模な組織では、クラウドのコンピューティング リソースに対するプロビジョニングされたアクセス権を組織内の利用者に提供するために、（場合によっては数千ノード規模の）マルチテナント GKE クラスタを運用することがよくあります。こうしたマルチテナント クラスタでは、リソース使用量を組織内の利用者に関連付ける前に、まずリソース使用量を収集し、エクスポートする必要があります。
使用量の区別方法を選択する
Kubernetes クラスタでは、個々の Pod がクラスタに対してリソース リクエストを行い、それがスケジュール決定に使用されます。一度スケジュールされると、実際のリソース使用量はクラスタで追跡できます。マルチテナント クラスタでは、さまざまなチームのワークロード使用量を追跡し、使用量をチャージバックできるようにする方法が必要です。GKE では、Kubernetes の Namespace、ラベル、またはその組み合わせを使用して、リソース使用量を区別できます。
GKE の費用割り当てを有効にする
費用割り当ては、クラスタで実行されているワークロードのリソース リクエストに関する情報を追跡します。現在のところ、費用割り当ては、クラスタの Compute Engine VM インスタンスのコア、RAM、GPU のリクエストに関する情報を収集します。このデータは BigQuery にエクスポートされます。そこでクエリし、チャージバック システムに組み込むことができます。GKE の費用割り当てデータは、利用したリソースではなくリソース リクエストに基づいています。GKE クラスタで利用したリソースに関するデータをエクスポートするには、クラスタの使用状況測定を使用します。
使用量を費用情報にマッピングする
使用状況測定はリソースの使用量に関する情報をエクスポートしますが、費用のデータは含まれません。Namespace またはラベルで分けられた費用情報をクエリするには、エクスポートされたリソース使用量データと各 SKU の Google Cloud Billing エクスポート データを結合します。このようなクエリの例は、こちらで公開されています。
チャージバックする使用量情報を決定する
Kubernetes で実行されている Pod には、リソース リクエスト、リソース上限、リソース使用量という 3 種類の使用量情報が含まれています。リクエストは、Pod にリクエストされ Kubernetes によって予約されたリソースを表します。リソース使用量を利用者にチャージバックする場合、Pod のリソース リクエストが過度に高く設定され、リソースの取り残しやクラスタの利用不足につながる可能性があります。このため、一部のお客様はリソース リクエストをチャージバックすることで、利用者にワークロード リクエストを適正化するインセンティブを与えています。
未割り当てリソースを考慮する
未割り当てリソースとは、クラスタで実行されているワークロードによって使用されないままになっているクラスタ リソースのことです。クラスタが静的にプロビジョニングされているか、自動スケーリングを使用して垂直方向にスケーリングしているかにかかわらず、クラスタには未割り当てリソースが存在します。このような未割り当てリソースは GKE 使用状況測定に含まれ、中央チームに割り当てるか、クラスタを使用するすべてのチームに比例的に分散させることができます。
Compute Engine のコミットメント
Compute Engine は、Google のインフラストラクチャで安全かつカスタマイズ可能な仮想マシンをお客様に提供し、さまざまなワークロードに対応するさまざまな仮想マシンタイプにアクセスできるようにします。規模の大きな組織は通常、Compute Engine のリソースの使用において予測可能かつ一貫したベースラインがあり、確約利用割引で費用を削減します。確約利用割引は、継続的な使用に対して大幅な割引を行いますが、組織内の利用者に費用を関連付けるプロセスが複雑になる可能性があります。
確約利用割引の共有を使用する
デフォルトでは、確約利用割引は、購入源であるプロジェクトにのみ適用されます。費用削減を最大化するために、多くの組織が確約利用割引の共有を有効にしており、Cloud 請求先アカウントにリンクされているすべてのプロジェクトに確約利用割引を適用できるようにしています。これにより、確約されたリソースに一致するプロジェクトの使用量をコミットメントに関連付けることができるため、コミットメントの利用が増え、全体的な費用が削減されます。
コミットメント アトリビューションを使用する
アトリビューションとは、Cloud 請求先アカウント レベルで共有されるリソース特典とコミットメント費用を、プロジェクト間でどのように分割するかということです。コミットメントがアトリビューションなしの場合、利用料金とクレジットは、プロジェクトが対象となる使用量を利用する際に適用されます。比例アトリビューションを使用する場合、クレジットと利用料金は、各プロジェクトによる、対象となる使用量の合計に比例して適用されます。最後に、優先アトリビューションを使用する場合、クレジットと利用料金は、指定した配分に基づいて適用されます。詳細については、確約利用割引の料金とクレジットのアトリビューションをご覧ください。
共有ネットワーク
大規模な組織の多くが、オンプレミス ホストと Google Cloud の間のプライベート接続に Dedicated Interconnect を使用しています。通常、このネットワーク インフラストラクチャは一元化され、組織内のチームで共有されているため、効果的にチャージバックするには配分する必要があります。
共有ネットワーク料金のアトリビューション
Dedicated Interconnect は、Interconnect 接続と VLAN アタッチメントの両方に対して 1 時間単位で課金され、使用量はリソースを所有するプロジェクトに関連付けられます。Interconnect での下り（外向き）にも料金が発生し、これは VLAN アタッチメントを所有するプロジェクトに関連付けられます。ネットワークの設定によっては、利用者のプロジェクトは、Dedicated Interconnect を介してオンプレミスにルーティングされるトラフィックを生成しますが、Interconnect 接続や VLAN アタッチメントを所有しない場合があります。この場合、トラフィック使用量を正確に反映させるために、Dedicated Interconnect の使用量を利用者のプロジェクトに手動で関連付ける必要があります。
支払ったぶんだけ得る
効果的なチャージバック プロセスを設計し実装することで、組織内のチームは使用するリソースの費用をプロアクティブにモニタリングし、ワークロードを効率的に運用できるようになります。Google Cloud は、チャージバック プロセスを構築するために使用できる詳細な課金情報へのアクセスを提供しますが、これを効果的にするためのヒントとコツがいくつかあります。
Cloud Finops と Google Cloud の費用管理について詳しくは、以下のリソースをご覧ください。
- カスタマー エンジニア Harrison Sweeney
- カスタマー エンジニア Alex Gronbach
