Databricks Compute Access Modesを正しく選ぶ: Single User / Shared / No Isolation

Databricksのクラスタ（Compute）を作成する際、最初に選択を求められるのがAccess Modeです。 Access Modeはクラスタの分離レベルとUnity Catalog対応を決定し、一度起動すると変更できません。 選択を誤ると「Unity CatalogのテーブルにアクセスできないMLプロジェクトのクラスタ」や 「セキュリティ監査に引っかかる共有クラスタ」が生まれるため、管理者・開発者の双方が正しく理解すべきトピックです。

この記事では、3つのAccess Mode（Single User / Shared / No Isolation Shared）の技術的な違いを 比較表で整理し、Unity Catalog環境での推奨構成、ジョブクラスタと対話型クラスタの使い分け、 そしてDatabricks認定試験で出題されるパターンを網羅します。

3つのAccess Modeの概要

Databricksのクラスタには3種類のAccess Modeがあります。それぞれのモードはプロセス分離の強度が異なり、 使える機能と制約も変わります。

• Single User Mode: 1人のユーザーまたは1つのService Principalがクラスタを排他的に使用する。 最も制約が少なく、すべてのDatabricks機能が利用可能。Unity Catalog対応。
• Shared Mode: 複数ユーザーが同一クラスタを共有する。プロセスレベルの分離が行われ、 各ユーザーのコードは他ユーザーから隔離される。Unity Catalog対応。ただし機能制約あり。
• No Isolation Shared Mode: 複数ユーザーが同一プロセス空間でコードを実行する。 分離なし。Unity Catalog非対応。新規環境では非推奨。

3モード比較表

Single User Mode の詳細

Single User Modeはクラスタ作成時に「割り当てるユーザー」を1人指定し、そのユーザーだけがクラスタを利用できます。 他のユーザーがアタッチしようとするとエラーになります。

排他利用のためプロセス分離は不要で、RDD API、カスタムJARライブラリ、init scripts、 MLランタイム（GPU含む）など、Databricksの全機能を制約なく使用できます。 Unity Catalog環境では、Single User Modeが最も推奨される選択肢です。

Single User Modeのコスト上のトレードオフは「クラスタの共有ができない」点です。 10人のチームが同時作業するとき、全員がSingle Userクラスタを起動するとクラスタ数が10台に膨らみます。 この課題はクラスタポリシーでインスタンスタイプやオートターミネーション時間を制限し、 さらにServerless Computeを活用することで緩和できます。

Shared Mode の詳細と制約

Shared Modeは複数ユーザーが1つのクラスタを共有しつつ、プロセスレベルの分離で安全性を確保します。 Unity Catalogにも対応しているため、コスト効率を重視する対話型ワークロードに適しています。

ただし、プロセス分離のために以下の機能制約があります。

• RDD APIが利用不可: DataFrame APIのみ。レガシーなRDDコードの実行は不可
• MLランタイム非対応: ML系ライブラリ（mlflow.pyfunc、分散学習など）のためのMLクラスタはSingle User Modeが必須
• init scriptsの制限: クラスタスコープのinit scriptsは利用不可。管理者が設定したglobal init scriptsのみ
• カスタムライブラリの制限: クラスタレベルのライブラリインストールは不可。ノートブック内の%pip installのみ
• Spark Configの制限: セキュリティに影響するSpark設定の変更は制限される

Shared Modeは「SQLアナリストが中心のチーム」「コスト効率を最優先する軽量な探索分析」に適しています。 機械学習やRDDベースの処理が必要な場合はSingle User Modeを選択してください。

No Isolation Shared Mode（非推奨）

No Isolation Shared Modeは複数ユーザーが同一のJVMプロセス内でコードを実行するため、 ユーザー間のデータ分離が一切ありません。あるユーザーのPythonコードが他ユーザーの変数空間にアクセスしたり、 環境変数に設定された認証情報を読み取ったりするリスクがあります。

Unity Catalogでは細粒度のアクセス制御（テーブルごとのGRANT/REVOKE）を行いますが、 No Isolation Modeではプロセスレベルの分離がないため、Unity Catalogの権限境界を維持できません。 そのためUnity Catalog非対応であり、Databricksは新規環境での利用を推奨していません。

既存のNo Isolation Shared Modeクラスタを運用している場合、以下の移行パスが推奨されます。

• MLワークロード → Single User Mode + MLランタイムへ移行
• SQL/軽量分析 → Shared Modeへ移行
• RDDコード → Single User Mode + DataFrame APIへのリライト検討

ジョブクラスタ vs 対話型クラスタでの選択ガイド

Unity Catalog前提でのベストプラクティス

Unity Catalogを有効化した環境では、Access Modeの選択がデータガバナンスの基盤になります。 以下の設計原則を推奨します。

• デフォルトはSingle User Mode: Cluster Policyで新規クラスタのAccess ModeをSingle Userに固定し、 ユーザーが意図せずNo Isolationクラスタを作成するのを防止する
• Shared Modeは限定利用: SQLアナリストチームなど、RDD/MLが不要なグループだけにShared Mode用のPolicyを割り当てる
• No Isolation Shared Modeの新規作成を禁止: Cluster Policyでaccess_modeをfixed値に設定し、No Isolationの選択肢を排除する
• ジョブクラスタはService Principal + Single User: 人間のユーザーではなくService Principalをクラスタに割り当て、 最小権限で本番ジョブを実行する

# Cluster PolicyでAccess Modeを制限する定義例
{
  "spark_conf.spark.databricks.cluster.profile": {
    "type": "fixed",
    "value": "singleNode",
    "hidden": true
  },
  "access_mode": {
    "type": "allowlist",
    "values": ["SINGLE_USER", "USER_ISOLATION"],
    "defaultValue": "SINGLE_USER"
  }
}

試験で問われるポイント

Access Modesは Data Engineer Associate、Platform Administration 関連のドメインで出題されます。 以下のパターンを整理しておきましょう。

• 「Unity CatalogのテーブルにアクセスするにはどのAccess Modeが必要か」→ Single User または Shared（No Isolationは不可）
• 「MLランタイムを使うにはどのAccess Modeが必要か」→ Single User Mode のみ
• 「RDD APIを使えるAccess Modeはどれか」→ Single User または No Isolation Shared（Sharedでは不可）
• 「複数ユーザーが安全にクラスタを共有するにはどのモードか」→ Shared Mode（プロセス分離あり）
• 「クラスタのAccess Modeは起動後に変更できるか」→ 変更不可。新しいクラスタを作り直す必要がある

問題で確認

よくある質問