メインコンテンツまでスキップ

グループへのコンピュート リソースの割り当て

備考

プレビュー

この機能は パブリック プレビュー段階です。

この記事では、 専用 アクセス モードを使用して、グループに割り当てられたコンピュート リソースを作成する方法について説明します。

専用グループ アクセス モードを使用すると、ユーザーは標準アクセス モード クラスターの運用効率を得ると同時に、 Databricks Runtime for ML、 Spark 機械学習ライブラリ (MLlib)、 RDD API、R など、標準アクセス モードでサポートされていない言語とワークロードを安全にサポートできます。

専用のグループ クラスター パブリック プレビューを有効にすると、ワークスペースから新しい簡略化されたコンピュート UI にもアクセスできるようになります。 この新しい UI では、アクセス モードの名前が更新され、コンピュートの設定が簡略化されます。 シンプルフォームを使用してコンピュートを管理するを参照してください。

必要条件​

専用グループアクセスモードを使用するには:

  • ワークスペース管理者は、プレビュー UI を使用してコン ピュート: 専用グループ クラスター プレビューを有効にする必要があります。 Databricks プレビューの管理を参照してください。
  • ワークスペースは Unity Catalog に対して有効になっている必要があります。
  • Databricks Runtime 15.4 以降を使用する必要があります。
  • 割り当てられたグループは、グループ クラスターで使用されるノートブック、 ML エクスペリメント、およびその他のワークスペース アーティファクトを保持できるワークスペース フォルダーに対するCAN MANAGEアクセス許可を持っている必要があります。

専用アクセスモードとは何ですか?​

専用アクセスモードは、シングルユーザーアクセスモードの最新バージョンです。 専用アクセスを使用すると、コンピュート リソースを 1 人のユーザーまたはグループに割り当てて、割り当てられたユーザーのみがコンピュート リソースを使用できるようになります。

ユーザーがグループ専用のコンピュート リソース (a グループ クラスター) に接続している場合、ユーザーのアクセス許可は自動的にグループのアクセス許可にダウンスコープされ、ユーザーはリソースをグループの他のメンバーと安全に共有できます。

グループ専用のコンピュートリソースを作成する​

  1. Databricksワークスペースで、 コンピュート に移動し、 コンピュートを作成 をクリックします。
  2. 詳細設定 セクションを展開します。
  3. アクセス モード で 手動 をクリックし、ドロップダウン メニューから 専用 (旧称: シングルユーザー) を選択します。
  4. シングル ユーザーまたはグループ フィールドで、このリソースに割り当てるグループを選択します。
  5. その他の必要なコンピュート設定を構成し、 作成 をクリックします。

グループ クラスターを管理するためのベスト プラクティス​

グループ クラスターを使用する場合、ユーザーのアクセス許可はグループに限定されるため、 Databricks グループ クラスターで使用する予定のグループごとに/Workspace/Groups/<groupName> フォルダーを作成することをお勧めします。 次に、フォルダに対する CAN MANAGE 権限をグループに割り当てます。 これにより、グループは権限エラーを回避できます。 グループのすべてのノートブックとワークスペース資産は、グループ フォルダーで管理する必要があります。

また、グループ クラスターで実行するには、次のワークロードを変更する必要があります。

  • MLflow: ノートブックをグループ フォルダーから実行するか、 mlflow.set_tracking_uri("/Workspace/Groups/<groupName>")を実行してください。
  • AutoML: AutoML の実行で省略可能な experiment_dir パラメーターを “/Workspace/Groups/<groupName>” に設定します。
  • dbutils.notebook.run: グループに、実行中のノートブックに対する READ 権限があることを確認します。

グループ権限の例​

グループ クラスターを使用してデータ オブジェクトを作成すると、そのグループはオブジェクトの所有者として割り当てられます。

たとえば、ノートブックがグループ クラスターにアタッチされていて、次のコマンドを実行するとします。

SQL
use catalog main;
create schema group_cluster_group_schema;

次に、次のクエリを実行して、スキーマの所有者を確認します。

SQL
describe schema group_cluster_group_schema;

グループ・スキーマの説明例

グループ専用コンピュートのアクティビティの監査​

グループ クラスターがワークロードを実行する場合、次の 2 つの主要な ID が関係します。

  1. グループ クラスターでワークロードを実行しているユーザー
  2. 実際のワークロードアクションの実行にアクセス許可が使用されるグループ

監査ログのシステムテーブルは、これらの ID を次のパラメーターで記録します。

  • identity_metadata.run_by: アクションを実行する認証ユーザー
  • identity_metadata.run_as: アクションに権限が使用される認証グループ。

次のクエリ例では、グループ クラスターで実行されたアクションの ID メタデータをプルアップします。

SQL
select action_name, event_time, user_identity.email, identity_metadata
from system.access.audit
where user_identity.email = "uc-group-cluster-group" AND service_name = "unityCatalog"
order by event_time desc limit 100;

監査ログのシステムテーブル リファレンスで、クエリのその他の例を参照してください。 監査ログシステムテーブルリファレンスを参照してください。

既知の問題​

  • グループ クラスターから作成されたワークスペース ファイルとフォルダは、割り当てられたオブジェクト所有者 Unknownになります。 これにより、これらのオブジェクトに対する後続の操作 ( read、 write、 deleteなど) は、アクセス許可が拒否されたエラーで失敗します。

制限​

専用グループ アクセス モードのパブリック プレビューには、次の既知の制限があります。

  • リネージ システムテーブルは、グループ クラスターで実行されているワークロードの identity_metadata.run_as (認証グループ) または identity_metadata.run_by (認証ユーザー) の ID を記録しません。
  • 顧客ストレージに配信される監査ログには、グループ クラスターで実行されているワークロードの identity_metadata.run_as (認証グループ) または identity_metadata.run_by (認証ユーザー) の ID は記録されません。 ID メタデータを表示するには、 system.access.audit テーブルを使用する必要があります。
  • グループ クラスターにアタッチされている場合、Catalog Explorer は、グループのみがアクセスできるアセットでフィルタリングされません。
  • グループ メンバーではないグループ マネージャーは、グループ クラスターを作成、編集、または削除できません。 ワークスペースの管理者とグループメンバーのみがこれを行うことができます。
  • グループの名前を変更した場合は、グループ名を参照するコンピュート ポリシーを手動で更新する必要があります。
  • グループ クラスターは、ACL が無効になっているワークスペース (isWorkspaceAclsEnabled == false) では、ワークスペース ACL が無効になっている場合、セキュリティとデータ アクセス制御が本質的に欠如しているため、サポートされていません。
  • 現在、 %run コマンドは、グループ クラスターで実行されるときに、グループの権限ではなくユーザーの権限を使用します。 dbutils.notebook.run() などの代替手段は、グループの権限を正しく使用します。
に最終更新