タグを使用した属性の使用
この記事では、カスタム タグとデフォルト タグを使用して、ワークロードを特定のワークスペース、チーム、プロジェクト、およびユーザーに帰属させる方法について説明します。
コストを監視し、 Databricks 使用量を正確に属性付けするために、ワークロードとコンピュート リソースにカスタム タグを追加できます。 Databricks では、システムテーブルを使用して使用状況データを表示することをお勧めします。 「課金利用 システムテーブル リファレンス」を参照してください。
これらのタグは、使用状況ログと、コスト分析のために AWS EC2 および AWS EBS インスタンスの両方に伝播されます。 注 : タグ データはグローバルにレプリケートできます。 リソースのセキュリティを損なう可能性のあるタグ名や値は使用しないでください。 たとえば、個人情報や機密情報を含むタグ名は使用しないでください。
タグ付けされたオブジェクトとリソース
Databricks によって管理される次のオブジェクトにカスタム タグを追加できます。
オブジェクト | タグ付けインターフェイス (UI) | タグ付けインターフェイス (API) |
---|---|---|
ワークスペース | N/A | |
プール | Databricks ワークスペースのプール UI | |
All-purposeとジョブコンピュート | Databricks ワークスペースのコンピュート UI | |
SQLウェアハウス | Databricks ワークスペースの SQL ウェアハウス UI |
キー Name
を持つカスタム タグをクラスターに割り当てないでください。 すべてのクラスターには、 Databricksによって値が設定されるタグ Name
があります。 キー Name
に関連付けられた値を変更すると、クラスターは Databricksで追跡できなくなります。 その結果、クラスターはアイドル状態になった後に終了せず、引き続き使用コストが発生します。
デフォルトのタグ
Databricks は、次のデフォルト タグを汎用コンピュートに追加します。
タグキー | 値 |
---|---|
| 定数値: |
| Databricks クラスターの内部 ID |
| クラスターの名前 |
| クラスターを作成したユーザーのユーザー名(Eメールアドレス) |
ジョブ クラスターでは、 Databricks は次のデフォルト タグも適用します。
タグキー | 値 |
---|---|
| ジョブ名 |
| ジョブID |
Databricks 、すべてのプールに次のデフォルト タグを追加します。
タグキー | 値 |
---|---|
| 定数値: |
| プールを作成したユーザーの Databricks 内部 ID |
| プールの Databricks 内部 ID |
レイクハウスモニタリングで使用されるコンピュートでは、Databricks は次のタグも適用します。
タグキー | 値 |
---|---|
| True |
| 監視対象のテーブルの ID |
| モニターが作成されたワークスペースの ID |
| 監視対象テーブルが存在するメタストアの ID |
Tag サーバレス コンピュート workloads
プレビュー
この機能は パブリック プレビュー段階です。
サーバレス コンピュートの使用状況をユーザー、グループ、またはプロジェクトに帰属させるには、サーバレス 予算ポリシーを使用できます。 ユーザーにサーバレス 予算ポリシーが割り当てられると、そのユーザーのサーバレス usage はポリシーのタグで自動的にタグ付けされます。 「サーバレス 予算ポリシーでの属性の使用」を参照してください。
タグの伝播
タグは、クラスターがプールから作成されたかどうかによって、 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) を参照してください。