はじめに
2024年8月に開催されたイベント「みんなの考えた最強のデータ基盤アーキテクチャ2024前半おまとめ拡大版SP！」にて、AzureにおけるDatabricksのコスト管理方法がLTで取り上げられていました。
LTでは「Databricksワークスペースを用途別に分離する」ことでコスト管理をする方法についてが言及され、具体的には各ワークスペースを別々のAzure Resource Groupに所属させて管理する方法が紹介されていました。
この方法に加え、Databricksのドキュメントではタグを使用した使用量の監視方法が紹介されています。
本稿では、このカスタムタグによる使用量の監視方法とカスタムタグの付与を強制する方法について解説します。
なお、執筆時点でサーバレスには以下の制限があるため、本稿はクラシックコンピュート（従来のコンピュート）を対象とします：
カスタムタグを使用した使用量監視
公式ドキュメントによると、Key-Value形式のカスタムタグを利用して使用量をモニタリングできます。
Databricksコンピュートに付与したカスタムタグには以下の特徴があります。
- Databricksの使用量システムテーブル
system.billing.usageのcustom_tagsカラムに記録される。参考 - パブリッククラウドの仮想マシン/ブロックストレージに伝播する。参考
これらの特徴により、DatabricksにおけるDBU消費量とパブリッククラウドにおけるコンピュート使用料をカスタムタグのKey-Value別に集計可能です。
説明の円滑化のため、筆者が利用しているカスタムタグKeyを例示します。
-
OwnerEmailAddress：リソース所有者のメールアドレス- 所有者別の使用量（料）集計に利用
- リソースの棚卸時に便利
-
Project：プロジェクト名- プロジェクト別の使用量（料）集計に利用
-
IaC：IaCを管理しているリポジトリのURL- リソースの棚卸時に便利
以降、カスタムタグKeyOwnerEmailAddressを例に説明します。
Databricks DBU消費量の監視
DatabricksコンピュートリソースにカスタムタグOwnerEmailAddressを付与していれば、Databricksの使用量システムテーブルsystem.billing.usageから、このValueを取り出すことができます。
これを利用し、Databricks DBU消費量をカスタムタグOwnerEmailAddressのValue別に集計する場合、以下のようなクエリになります。
SELECT
usage_date -- 使用日
,custom_tags.OwnerEmailAddress AS user -- タグKey OwnerEmailAddress にセットした Valueを取得
,sku_name -- sku
,SUM(usage_quantity) AS usage -- 使用量の合計
FROM
system.billing.usage -- 使用量システムテーブル
WHERE
usage_date >= CURRENT_DATE() - INTERVAL 30 DAYS
AND
custom_tags.OwnerEmailAddress IS NOT NULL
GROUP BY
usage_date
,custom_tags.OwnerEmailAddress
,sku_name
ORDER BY
usage_date DESC
パブリッククラウドリソース（コンピュート類）使用料の監視
DatabricksコンピュートリソースにカスタムタグOwnerEmailAddressを付与すると、パブリッククラウド環境に作成される仮想マシンやブロックストレージなどの各リソースにもタグが伝播されます。
そのため、各パブリッククラウドが提供するコスト確認用サービス等を利用し、このタグのValue別に集計が可能です。
コンピュートポリシーによりカスタムタグを強制する
消費量（料）監視に有用なカスタムタグですが、このカスタムタグの付与は通常任意となっています。
しかし、Databricksコンピュートポリシーを適用することによって、コンピュートリソースに対するカスタムタグの付与を強制することが可能です。（より正確には、ポリシーを満たさないコンピュートの作成を制限できます。）
例えば、カスタムタグ OwnerEmailAddressKeyの付与と、Valueに入力可能な値の制約（ここでは、{任意の文字}@example.com）を行うポリシー定義は以下です。
{
"custom_tags.OwnerEmailAddress": {
"type": "regex",
"defaultValue": "@example.com",
"pattern": "^.+@example.com$"
}
}
このポリシー定義の動作を確かめてみましょう。
デフォルトで提供されている Personal Computeポリシーに、上記のポリシー定義をオーバーライドしたArticle Sampleポリシーを新規作成しました。
このArticle Sampleポリシーを利用し、コンソールからコンピュートの作成を試みた結果が以下です。
以下が特徴です。
- ポリシー定義に記載したタグKey
OwnerEmailAddressが自動でセットされている。 - ポリシー定義に記載したデフォルトValue
@example.comが自動でセットされている。 - Valueがポリシー定義の条件を満たしていないと警告されている。
- （Valueが条件を満たしていないため）クラスタ作成ボタンが非アクティブになっている。
これを修正し、Valueがポリシー定義の条件を満たすとクラスタ作成ボタンがアクティブとなります。
カスタムタグに限らずコンピュートポリシーではコンピュートに関する様々な制限を定義可能です。
詳しくは、以下のドキュメントを参照ください。
注意点として、ポリシーを使用したコンピュート作成後に、ポリシーを編集した場合、作成済のコンピュートは編集後のポリシーに準拠するわけではありません。
この問題の対処のため、コンピュートがポリシーを満たしているかを確認する機能がリリースされています。
詳しくは以下のドキュメントを参照ください。
まとめ
本稿では、カスタムタグを用いた使用量（料）監視とコンピュートポリシーによるカスタムタグの付与の強制について解説しました。
使用量（料）の監視のみならず、管理という意味でもカスタムタグは有用なので、積極的な活用をおすすめします。
また、冒頭でも触れましたが、サーバレスについては、カスタムタグやコンピュートポリシーの使用に制限がある点にご注意ください。
Discussion