グループにコンピュートリソースを割り当てる

プレビュー

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

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

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

要件

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

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

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

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

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

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

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

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

グループクラスタリングを使用する場合、ユーザーのアクセス許可はグループに限定されるため、 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 権限があることを確認します。

グループ権限の例

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

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

use catalog main;
create schema group_cluster_group_schema;

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

describe schema group_cluster_group_schema;

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

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

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

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

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

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

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;

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

制限事項

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

リネージシステムテーブルは、グループクラスタリングで実行されているワークロードの 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() などの代替手段は、グループの権限を正しく使用します。