次の方法で共有

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

  • [アーティクル]

重要

この機能はパブリック プレビュー段階にあります。

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

専用グループ アクセス モードを使うと、ユーザーは標準アクセス モード クラスターの運用効率を実現しながら、Databricks Runtime for ML、Spark Machine Learning Library (MLlib)、RDD API、R などの、標準アクセス モードではサポートされていない言語とワークロードも安全にサポートできます。

専用グループ クラスター (パブリック プレビュー) を有効にすると、ワークスペースは新しい簡素になったコンピューティング UI にもアクセスできるようになります。 この新しい UI では、アクセス モードの名前が更新され、コンピューティング設定が簡単になっています。 「シンプルなフォームを使用してコンピューティングを管理する」をご覧ください。

必要条件

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

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

専用アクセス モードとは

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

ユーザーがグループ専用のコンピューティング リソース (グループ クラスター) に接続されている場合、ユーザーのアクセス許可はグループのアクセス許可のスコープまで自動的に引き下げられ、ユーザーはグループの他のメンバーとリソースを安全に共有できるようになります。

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

  1. Azure 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 アクセス許可をグループが持つようにします。

グループのアクセス許可の例

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

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

use catalog main;
create schema group_cluster_group_schema;

それから、次のクエリを実行してスキーマの所有者を調べます。

describe schema group_cluster_group_schema;

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

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

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

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

監査ログ システム テーブルでは、次のパラメーターでこれらの 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;

他のクエリの例については、監査ログ システム テーブルのリファレンスを参照してください。 「監査ログ システム テーブル リファレンス」をご覧ください。

既知の問題

  • グループ クラスターから作成されたワークスペース ファイルとフォルダーでは、割り当てられたオブジェクト所有者が 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 テーブルを使う必要があります。
  • グループ クラスターにアタッチされている場合、カタログ エクスプローラーでは、そのグループのみがアクセスできる資産でのフィルター処理は行われません。
  • グループ メンバーではないグループ マネージャーは、グループ クラスターを作成、編集、または削除できません。 これを行うことができるのは、ワークスペース管理者とグループ メンバーだけです。
  • グループの名前が変更された場合は、そのグループ名を参照しているコンピューティング ポリシーを手動で更新する必要があります。
  • ワークスペース ACL が無効になっているときは、セキュリティとデータ アクセスの制御が本質的に行われないため、ACL が無効になっている (isWorkspaceAclsEnabled == false) ワークスペースでは、グループ クラスターはサポートされません。
  • 現在、%run コマンドがグループ クラスターで実行されるときは、グループのアクセス許可ではなく、ユーザーのアクセス許可が使われます。 グループのアクセス許可を正しく使用する代替手段として、dbutils.notebook.run() などがあります。