背景・目的
【Databricks】Unity Catalogのタグを整理してみたでは、Unity Catalogで管理されるオブジェクトをタグで管理する方法を確認してみました。
今回は、リソースに対してタグを使用した監視方法に焦点を当てて整理してみます。
まとめ
下記の特徴があります。
| 特徴 | 説明 |
|---|---|
| 対象 | ワークスペース、クラスター、プールにタグ付けできる。 |
| インターフェイス | UIとAPI。ただし、ワークスペースはUIではできない |
| Propagation | ・DatabricksのDBU Usage ・AWS EC2、EBS |
| 注意点 | Nameキーは使用しない。クラスタを停止できない。 |
| 制約 | ・ISO 8859-1のみ ・タグのキーとバリューを変更した場合は、クラスタの再起動、プールの拡張後に反映される。（動的に実行中には変わらない） ・反映まで最大1Hかかる ・ワークスペースリソースに割り当てられるタグは20個まで |
概要
クラスター、プール、ワークスペースのタグを使用した使用状況の監視を元に整理します。
コストを監視し、Databricks の使用状況を組織の部署とチームに正確に帰属させるには (チャージバックなど)、ワークスペース、クラスター、プールにタグを付けることができます。 これらのタグは、詳細な DBU 使用状況レポート と、コスト分析のために AWS EC2 および AWS EBS インスタンスの両方に伝達されます。
- ワークスペース、クラスター、プールにタグ付けできる。
- DBU Usage、AWS EC2、EBSにPropagateされる
タグ付けされたオブジェクトとリソース
Databricks によって管理される次のオブジェクトにカスタム タグを追加できます。
| オブジェクト | UI | API |
|---|---|---|
| ワークスペース | - | ◯ |
| プール | ◯ | ◯ |
| クラスター | ◯ | ◯ |
下記に怖い記載がある。Nameをつけると正常に動作できない。※クラスタが終了されずコストが発生し続けるとのこと。
これなら入力できないようにしてほしい。
タグのPropagation
※出典：クラスター、プール、ワークスペースのタグを使用した使用状況の監視
タグは、クラスターがプールから作成されたかどうかに応じて、異なる方法で AWS EC2 インスタンスに伝達されます。
クラスターがプールから作成された場合、その EC2 インスタンスはカスタムおよびデフォルトのワークスペースタグとプールタグのみを継承し、クラスタータグは継承しません。 したがって、プールからクラスターを作成する場合は、必要なすべてのカスタムクラスタータグをワークスペースまたはプールに割り当ててください。
- プールから作成すると、クラスタータグは継承しない。必要なカスタムクラスタータグをワークスペースまたはプールに割り当てること
クラスターがプールから作成されていない場合、そのタグは期待どおりに EC2 インスタンスに伝播されます。
- プールから作成されない場合、EC2インスタンスにPropagateされる
クラスター タグとプール タグはどちらも、クラスターがプールから作成されたかどうかに関係なく、 DBU 使用状況レポートに伝達されます。
- DBU使用状況レポートにはPropagateされる。
タグ名の競合がある場合、Databricks の既定のタグはカスタム タグよりも優先され、プール タグはクラスター タグよりも優先されます。
- 競合がある場合に、既定タグが優先される。（Nameは？？）
制限
- タグのキーと値には、ISO 8859-1 (latin1) セットの文字のみを含めることができます。 他の文字を含むタグは無視されます。
- タグキーの名前または値を変更した場合、これらの変更はクラスターの再起動またはプールの拡張後にのみ適用されます。
- クラスターのカスタムタグがプールのカスタムタグと競合する場合、クラスターを作成できません。
- 変更後、カスタムワークスペースタグが反映されるまでに最大 1 時間かかる場合があります。
- ワークスペース リソースに割り当てることができるタグは 20 個までです。
- ISO 8859-1のみ
- タグのキーとバリューを変更した場合は、クラスタの再起動、プールの拡張後に反映される。（動的に実行中には変わらない）
- 反映まで最大1Hかかる
- ワークスペースリソースに割り当てられるタグは20個まで
ポリシーによるタグの適用
- 適用可能なコンピュート・ポリシーにコンピュート・タグ・ルールを追加する。
- コンピュートタグルールをポリシーに追加するには、 custom_tags. 属性を使用
- 下記のように定義することで、9999、9921、9531のいずれかの入力を起動時に必須にすることが可能。
{"custom_tags.COST_CENTER": {"type":"allowlist", "values":["9999", "9921", "9531" ]}} - 上記の３つのコストセンターに対して課金できるユーザにポリシーを割り当てる
- ポリシーは、APIやコンピュートポリシーUIから行う。
- 下記は、salesグループまたは、個別のユーザに権限を付与している。
{ "access_control_list": [ { "user_name": "user@mydomain.com", "all_permissions": [ { "permission_level": "CAN_USE" } ] }, { "group_name": "sales", "all_permissions": [ { "permission_level": "CAN_USE" } ] } ] }
実践
Compute Policiesを作成する
-
ワークスペースにサインインします。
-
ナビゲーションペインで「Compute」をクリックします。
-
①「Policies」タブをクリックし、②「Create policy」をクリックします。
-
PolicyとNameを設定し 「Create」をクリックします。
ComputeにPolicyをアタッチ
-
①「All-purpose compute」タブをクリックし、②「Create compute」をクリックします。
-
Policyで、上記で作成したPolicyを選択し、「Confirm」をクリックします。
- COST_CENTERタグが追加されました。デフォルトでSalesが入っています。
-
「Create compute」をクリックします。
-
起動しました。
-
EC2インスタンスに、タグ「COST_CENTER：sales」が付与されていることが確認できました。
Usage
- Manage Accountにサインインします。
- ナビゲーションペインで「Usage」をクリックします。
- 作成したタグ「COST_CENTER」をクリックします。
- 確認できました。
考察
DatabricksのクラスタリソースにCompute Policiesを用いてタグを適用する方法を試してみました。
この方法によって、部門ごとの利用状況を分析できるため、今後も積極的に活用していきたいと考えています。
参考