タグを使用して使用状況を監視する

コストを監視し、Databricks の使用量を組織のビジネスユニットやチームに正確に割り当てる(チャージバックのためなど)には、ワークスペースやコンピュートリソースにカスタムタグを追加します。 Databricks では、システムテーブル (パブリックプレビュー) を使用して使用状況データを表示することを推奨しています。 課金利用システムテーブルリファレンスを参照してください。

これらのタグは、使用状況ログと、コスト分析のために AWS EC2 および AWS EBS インスタンスの両方に伝播されます。 : タグ データはグローバルにレプリケートできます。 リソースのセキュリティを損なう可能性のあるタグ名や値は使用しないでください。 たとえば、個人情報や機密情報を含むタグ名は使用しないでください。

タグ付けされたオブジェクトとリソース

Databricks によって管理される次のオブジェクトにカスタム タグを追加できます。

オブジェクト

タグ付けインターフェース(UI)

タグ付けインターフェース (API)

ワークスペース

N/A

アカウントAPI

プール

Databricks ワークスペースのプール UI

インスタンスプール API

All-purposeとジョブコンピュート

Databricks ワークスペースのコンピュート UI

クラスター API

SQLウェアハウス

Databricks ワークスペースの SQL ウェアハウス UI

ウェアハウスAPI

警告

キーNameを持つカスタム タグをクラスターに割り当てないでください。 すべてのクラスターにはタグNameがあり、その値は Databricks によって設定されます。 キーNameに関連付けられた値を変更すると、クラスターは Databricks によって追跡できなくなります。 その結果、クラスターはアイドル状態になった後も終了されず、使用コストが発生し続ける可能性があります。

デフォルトタグ

Databricks 、汎用コンピュートに次の デフォルト タグを追加します。

タグキー

Vendor

定数値: Databricks

ClusterId

クラスターの Databricks 内部 ID

ClusterName

クラスターの名前

Creator

クラスターを作成したユーザーのユーザー名(Eメールアドレス)

ジョブ クラスターでは、 Databricks次の デフォルト タグも適用されます。

タグキー

RunName

ジョブ名

JobId

ジョブID

Databricks は、すべてのプールに次のデフォルト タグを追加します。

タグキー

Vendor

定数値: Databricks

DatabricksInstancePoolCreatorId

プールを作成したユーザーの Databricks 内部 ID

DatabricksInstancePoolId

プールの Databricks 内部 ID

レイクハウスモニタリングで使用されるコンピュートでは、Databricks は次のタグも適用します。

タグキー

LakehouseMonitoring

LakehouseMonitoringTableId

監視対象テーブルの ID

LakehouseMonitoringWorkspaceId

モニターが作成されたワークスペースのID

LakehouseMonitoringMetastoreId

監視対象テーブルが存在するメタストアの ID

タグ サーバレス コンピュート workloads

サーバレス コンピュートの使用状況をユーザー、グループ、またはプロジェクトに帰属させるには、budget ポリシーを使用できます。 ユーザに予算ポリシーが割り当てられると、そのユーザのサーバレス使用量は、ポリシーのタグとともに自動的にタグ付けされます。 Attribute サーバレス usage with budget ポリシーを参照してください。

タグの伝播

クラスターがプールから作成されたかどうかに応じて、タグは AWS EC2 インスタンスに異なる方法で伝播されます。

クラスターとプールのタグの伝播

クラスターがプールから作成される場合、そのEC2インスタンスはクラスタータグではなく、カスタムの デフォルト ワークスペース タグとプール タグのみを継承します。 したがって、プールから クラスター を作成する場合は、ワークスペースまたはプールに必要なカスタム クラスタータグをすべて割り当てるようにしてください。

クラスターがプールから作成されていない場合、そのタグは期待どおりに EC2 インスタンスに伝播されます。

クラスター と プール タグ は両方とも、 クラスター がプールから作成されたかどうかに関係なく、 DBU使用状況レポートに伝播されます。

タグ名が競合する場合は、 Databricksデフォルト タグがカスタム タグよりも優先され、プール タグがクラスタータグよりも優先されます。

制限事項

  • タグのキーと値には、文字、スペース、数字、または文字 +-=._:/@のみを含めることができます。 他の文字を含むタグは無効です。

  • タグ キーの名前または値を変更した場合、これらの変更はクラスターの再起動またはプールの拡張後にのみ適用されます。

  • クラスターのカスタム タグがプールのカスタム タグと競合する場合、クラスターを作成できません。

  • 変更後、カスタム ワークスペース タグが反映されるまでに最大 1 時間かかる場合があります。

  • ワークスペース リソースに割り当てることができるタグは 20 個までです。

ポリシーによるタグの適用

コンピュート ポリシーを使用して、クラスターにタグを適用できます。 詳細については、 「カスタム タグの適用」を参照してください。

IAMロールによるタグの強制

コンピュートリソースの作成時に特定のタグが常に入力されるようにするには、アカウントのプライマリIAM IAM ロール (アカウントのセットアップ時に作成されたもの。アクセスが必要な場合はAWS 管理者に問い合わせてください) に特定の ポリシーを適用します。IAM ポリシーには、必須のタグキーとオプションの値に対する明示的なDeny ステートメントを含める必要があります。 許可された値のいずれかを持つ必須タグが指定されていない場合、クラスターの作成は失敗します

たとえば、 DepartmentタグとProjectタグを適用し、前者には指定された値のみを許可し、後者には自由形式の空でない値を許可する場合は、次のような IAM ポリシーを適用できます。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "MandateLaunchWithTag1",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateTags"
      ],
      "Resource": "arn:aws:ec2:region:accountId:instance/*",
      "Condition": {
        "StringNotEqualsIgnoreCase": {
          "aws:RequestTag/Department": [
              "Deptt1", "Deptt2", "Deptt3"
          ]
        }
      }
    },
    {
      "Sid": "MandateLaunchWithTag2",
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "ec2:CreateTags"
      ],
      "Resource": "arn:aws:ec2:region:accountId:instance/*",
      "Condition": {
        "StringNotLike": {
          "aws:RequestTag/Project": "?*"
        }
      }
    }
  ]
}

オンデマンド インスタンスのみ、スポット インスタンスのみ、またはその両方を持つクラスターがあるシナリオを効果的にカバーするには、各タグに対してec2:RunInstancesアクションとec2:CreateTagsアクションの両方が必要です。

ヒント

Databricks では、タグごとに個別のポリシー ステートメントを追加することをお勧めします。 全体的なポリシーは長くなる可能性がありますが、デバッグが容易になります。 ポリシーで使用できる演算子のリストについては、 IAMポリシー条件演算子リファレンスを参照してください。

IAM ポリシーによるクラスター作成エラーには、次で始まるencoded error messageが表示されます:

Cloud Provider Launch Failure: A cloud provider error was encountered while setting up the cluster.

承認ステータスの詳細は、アクションを要求したユーザーが表示すべきではない特権情報となる可能性があるため、メッセージがエンコードされます。 このようなメッセージをデコードする方法については、 DecodeAuthorizationMessage API (またはCLI ) を参照してください。