Databricks Cluster Policies完全ガイド｜コスト統制・権限制御・標準化

Databricksの環境が大きくなると、「誰でも好きなクラスタを自由に作れる」状態がコスト管理と運用品質の両面でリスクになります。 Cluster Policyは、クラスタ作成時に使えるパラメータを管理者が事前に定義・制限する仕組みです。 ユーザーに必要な柔軟性は残しつつ、インスタンスタイプ・ノード数・オートスケーリング範囲・タグなどを統制できます。

この記事では、Cluster Policyの仕組み、定義の書き方、コスト統制・権限制御・標準化の3つの実務観点、 そしてDatabricks認定試験で問われるポイントを整理します。

Cluster Policyとは何か

Cluster Policyは、JSON形式で定義するクラスタ設定のテンプレートです。 ワークスペース管理者がPolicyを作成し、ユーザーやグループに対して「このPolicyを使ってクラスタを作成せよ」と割り当てます。 ユーザーはPolicy内で許可された範囲でのみクラスタを構成でき、範囲外の設定はUI上でグレーアウトされるか、API呼び出し時にエラーになります。

Policyが制御できる代表的なパラメータは以下の通りです。

Policy定義の基本構造

Policy定義はJSON形式で、各パラメータに対して制約の種類（fixed / range / allowlist / regex など）を指定します。 以下は実務でよく使われるパターンの骨格です。

{
  "spark_version": {
    "type": "regex",
    "pattern": "14\\.3\\.x-scala.*",
    "defaultValue": "14.3.x-scala2.12"
  },
  "node_type_id": {
    "type": "allowlist",
    "values": ["i3.xlarge", "i3.2xlarge", "m5.xlarge"],
    "defaultValue": "i3.xlarge"
  },
  "num_workers": {
    "type": "range",
    "minValue": 1,
    "maxValue": 8,
    "defaultValue": 2
  },
  "autoscale.min_workers": {
    "type": "range",
    "minValue": 1,
    "maxValue": 4
  },
  "autoscale.max_workers": {
    "type": "range",
    "minValue": 2,
    "maxValue": 8
  },
  "custom_tags.CostCenter": {
    "type": "fixed",
    "value": "engineering"
  },
  "autotermination_minutes": {
    "type": "range",
    "minValue": 10,
    "maxValue": 120,
    "defaultValue": 30
  }
}

この定義では、Runtimeは14.3.x系のみ、ノードタイプは3種類から選択、ワーカー数は1〜8、 自動終了は10〜120分（デフォルト30分）、CostCenterタグは"engineering"で固定です。 ユーザーはこの範囲内でクラスタを構成できます。

コスト統制への活用

Cluster Policyを導入する最大の動機はコスト統制です。特にチームが10人を超えると、 「誰かが巨大なクラスタを起動して放置した」「GPUインスタンスを検証で使ったまま終了し忘れた」 といった事故が起きやすくなります。

コスト統制に効くPolicy設定は主に3つあります。

• ワーカーノード数の上限設定（num_workers.maxValue）
• 自動終了時間の最小値強制（autotermination_minutes.minValue）
• 高額インスタンスタイプの排除（node_type_id.allowlistからGPU系を除外）

これらを組み合わせると、「最大8ノード・30分で自動終了・GPUなし」のような制約をPolicyレベルで強制でき、 ユーザーがうっかり巨大クラスタを放置するリスクを構造的に排除できます。

権限制御とPolicyの割り当て

Policyは作成しただけでは効果がありません。ユーザーやグループに「どのPolicyを使えるか」を割り当てる必要があります。 割り当てにはDatabricksのアクセス制御（ACL）を使います。

• CAN_USE: そのPolicyを使ってクラスタを作成できる
• CAN_MANAGE: Policyの定義自体を編集できる

実務では「開発者グループにはコスト制限付きPolicy」「MLチームにはGPU許可Policy」「管理者は制限なし」 のように、ロールに応じたPolicyを割り当てます。Unrestricted Policy（制限なしPolicy）への CAN_USEを持つユーザーは事実上なんでも作れるため、これを付与する対象は厳選する必要があります。

クラスタ構成の標準化

PolicyはコストだけでなくEnvironmentの統制にも使えます。 「全チームが同じRuntimeバージョンを使う」「必ずLTSを使う」「Photonを有効にする」 「特定のSpark設定を強制する」といったルールをPolicyで定義すると、 「環境差異で動かない」「バージョン違いでバグが再現しない」といった問題を減らせます。

タグの必須化もPolicy経由で行えます。コスト配賦（チャージバック）を行う組織では、 CostCenterやProjectタグを必須にしておくと、後から「どのチームがいくら使ったか」を 正確にトラッキングできます。タグなしのクラスタが作成されること自体を防げるのがPolicyの利点です。

Job ClusterとAll-Purpose Clusterへの適用

Cluster PolicyはAll-Purpose Cluster（対話型）だけでなく、Job Cluster（ジョブ実行用）にも適用できます。 ジョブ定義時に使用するPolicyを指定すると、そのジョブが起動するクラスタがPolicy制約に従います。

実務上、Job Clusterの方がコストインパクトが大きい場合が多く（夜間バッチで大量ノードを使うケースなど）、 ジョブ向けPolicyを別途定義して「本番バッチは最大16ノード」「開発バッチは最大4ノード」のように 分けるのが一般的です。

試験で問われるポイント

Databricks認定試験では、Cluster Policyそのものの定義構文を書かせる問題はほぼ出ません。 代わりに、以下のような「どの機能で何を実現するか」の判断が問われます。

• 「ユーザーが作成できるクラスタのサイズを制限したい」→ Cluster Policy
• 「クラスタの起動時間を短縮したい」→ Instance Pool（Policyとは別）
• 「コスト配賦のためにタグを必須にしたい」→ Cluster Policy + custom_tags
• 「特定のRuntimeバージョンのみ許可したい」→ Cluster Policy + spark_version
• 「管理者以外がGPUクラスタを作れないようにしたい」→ Cluster Policy + node_type_id allowlist

試験では「Instance Pool」「Cluster Policy」「Permissions」を混同させる選択肢が出やすいので、 それぞれの目的の違いを整理しておくことが重要です。

問題で確認

よくある質問