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

コストを監視し、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 個までです。

タグ付けのベストプラクティス

タグは手動で入力できるため、組織ではキーと値のペアを標準化する必要があります。 Databricks では、すべてのユーザーと共有できるキーと値の命名に関するビジネスポリシーを作成することをお勧めします。
すべてのリソースには、使用量をビジネスユニットまたはプロジェクトに帰属させる一般的なキーでタグ付けする必要があります。たとえば、財務チームが年間予算用に作成したジョブコンピュートリソースには、 business-unit:finance タグと project:annual-budgetタグが含まれる場合があります。
より詳細な知見を得るには、特異性の高いキーを使用してタグを割り当てます。たとえば、ロール、製品、サービス、または顧客に基づいてキーを作成できます。
該当する場合、ワークスペース管理者は、コンピュートポリシーと予算ポリシーを使用してタグを適用する必要があります。カスタムタグの適用をご覧ください。

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 ) を参照してください。