ベストプラクティス: コンピュートポリシー

警告

この記事はアーカイブされており、製品の現在の状態を反映していない可能性があります。コンピュートポリシーに関する情報については、「コンピュートポリシーの作成と管理」を参照してください。

Databricksコンピュートポリシー Databricksを使用すると、管理者はワークスペースでのコンピュートリソースの作成を制御できます。コンピュートポリシーを効果的に使用すると、管理者は次のことが可能になります。

標準化されたコンピュート構成を強制します。
リソースの過剰な使用を防ぎ、コストを制御します。
コンピュートリソースに正しくタグを付けることで、正確なチャージバックを確保します。
特定のワークロードを対象とした事前構成済みのコンピュート構成をユーザーに提供することで、分析と処理を容易にします。

効果的なオンボーディング、承認、チャージバックのプロセスと組み合わせることで、コンピュートポリシーは Databricks プラットフォームガバナンスの基盤となるコンポーネントとなります。このガイドでは、コンピュートポリシーをガバナンスフレームワークに統合するための優れた計画を作成するのに役立つ推奨事項とベストプラクティスを示します。

ガバナンスは各組織の要件と既存のガバナンスインフラストラクチャに固有のものであるため、この記事ではまず、コンピュートポリシーに一般的に適用される推奨事項について説明します。この記事の最後のセクションでは、環境で発生する可能性のある課題に対処するための具体的な戦略について説明します。

この記事では、コンピュートガバナンスのロールアウトを成功させるための次のベストプラクティスと推奨事項について説明します。

コンピュートポリシーを段階的に導入する計画を作成し、ユーザーが管理された環境に移行できるように支援します。
コンピュートポリシーロールアウトの各フェーズの変更を伝達するための計画を作成します。
コンピュートのガバナンスの課題を特定し、その課題に対処するための戦略を実施します。

コンピュートポリシーロールアウト

コンピュートポリシーを実装すると、ユーザーエクスペリエンスに大きな変化をもたらす可能性があります。 Databricks では、移行を通じてユーザーをガイドするために、段階的なアプローチを推奨しています。

今後の変更を伝え、ユーザーにコンピュート構成をテストする機会を提供します。
ソフト展開を実行します。
さらなるポリシー変更を段階的に導入します。
完全に管理された環境へのハードカットオーバーを実行します。

段階的な展開により、ユーザーは新しいポリシーに慣れ、既存のワークロードの中断を防ぐことができます。次の図は、この推奨プロセスの例です。

コンピュートポリシーロールアウトプラン

以下のセクションでは、これらのステージについて詳しく説明します。

Communicate and test コンピュートポリシー
コンピュートポリシー導入の考慮事項
最終展開

Communicate and test コンピュートポリシー

今後の変更をユーザーに伝えることからプロセスを開始してください。伝達計画には以下を含める必要があります。

今後の変更の詳細。
変更の理由。
ワークロードの移行を成功させるために、ユーザーがすべきこと。
変更に関するフィードバックを提供する方法。
展開の各段階のタイムライン。
段階的展開の各段階の開始時に、その段階に関連する詳細を伝える。

次の図は、段階的展開の伝達計画の例を示しています。

コンピュートポリシーコミュニケーションプラン

プランには、環境とコンピュートポリシー戦略に応じて異なるステージがある場合があります。この例には、次の 4 つのステージが含まれています。

ステージ 1 には、プランをユーザーに伝え、テストを開始することが含まれます。ユーザーは、新しいポリシーに準拠するコンピュートで現在および予想されるワークロードをテストする機会を持つ必要があります。既存のワークロードと計画されたワークロードの問題をプロセスの早い段階で特定する必要があります。
ステージ 2 では、コンピュート tagging ポリシーのロールアウトと共にテストが続行されます。
ステージ3では、コンピュートタイプを導入し、この場合はTシャツのサイズを使用してコンピュートを指定します(たとえば、小、大、特大のコンピュートタイプ)。
ステージ 4 は、コンピュートポリシーの最終ロールアウトと完全なユーザードキュメントです。

また、ユーザーは、初期段階で計画されたコンピュート構成でワークロードをテストする機会を持つ必要があります。このテストは、提案されたポリシーでの実行に問題がある既存のワークロードを特定するのに役立ちます。

コンピュートポリシー導入の考慮事項

コンピュートポリシーの初期展開を計画するときは、現在の管理ポリシーを考慮してください。特に、ユーザーがコンピュートを作成することが制限されている環境から移行するのか、それともよりオープンな環境に移行するのかを検討してください。

制限の厳しい環境

ユーザーがコンピュートを作成するアクセス許可を持っていない環境の場合は、まず、制限的なポリシーとユーザーの有効化プランをロールアウトします。イネーブルメントプランは、コンピュータベースのトレーニング、ワークショップ、またはドキュメントである可能性があります。コンピュートを構成するためのベストプラクティスに関するガイダンスをユーザーに提供することで、プラットフォームを最大限に活用する能力が向上します。ユーザーがプラットフォームのコンプライアンスと能力を示すことで、ポリシーを緩和することができます。

制限のない環境

ポリシーの適用は、制限のない環境ではより困難になる可能性があります。既存のユースケースやコンピュートの中には、ほとんどの場合、新しいポリシーの制約の範囲外にあるものもあるため、テストやソフトロールアウトの段階でこれらを特定することが重要です。

コンピュートの作成アクセス許可または無制限のポリシーへのアクセス権を持つユーザーは、ソフトロールアウト全体を通じてこのポリシーへのアクセスを維持し、すべてのワークロードが引き続き機能するようにします。ユーザーは、ソフトロールアウトを使用して、利用可能になる新しいポリシーですべてのワークロードをテストする必要があります。

ポリシーに関するフィードバックを送信できる場所をユーザーに必ず提供してください。問題が発生した場合は、ユーザーと協力してポリシーを調整したり、新しいポリシーを定義したりします。

最終ロールアウト

期限に達したときに、制限付きユーザーの無制限ポリシーへのアクセスを削除します。これでコンピュートポリシーのロールアウトは完了です。

具体的な課題と戦略

以下は、コンピュートポリシーを適用して特定の課題に対処する例です。これらの戦略の多くは同時に採用できますが、すべてのポリシーに各戦略を適用する必要があります。たとえば、タグ適用戦略を T シャツサイズ戦略と共に使用する場合、各 T シャツポリシーにも custom_tag.* ポリシーが必要になります。

タグの施行

挑戦

ユーザーは自由にコンピュートを作成でき、必要なタグの適用を強制する仕組みはありません。

ソリューション

ユーザーからコンピュート作成権限を取り消します。
コンピュートタグルールを該当するコンピュートポリシーに追加します。コンピュート・タグ・ルールをポリシーに追加するには、 custom_tags.<tag-name> 属性を使用します。値は、無制限のポリシーの下にある任意の値にすることも、 fixed、 allow list、 block list、 regex、または range ポリシーによって制限することもできます。たとえば、正しいチャージバックとコストの帰属を確保するには、許可されたコストセンター値のリストに制限された各ポリシーに COST_CENTER タグを適用します。
JSON
```
{ "custom_tags.COST_CENTER": { "type": "allowlist", "values": ["9999", "9921", "9531"] } }
```
このポリシーを使用するユーザーは、コンピュートを起動するために、9999、9921、または 9531 の COST_CENTER タグを入力する必要があります。

これら 3 つのコストセンターに対して課金できるユーザーにポリシーを割り当てます。ポリシーは、コンピュートポリシー UI またはポリシー APIを使用して、ユーザーまたはグループレベルで割り当てることができます。次の要求本文の例では、営業部門にポリシーを割り当てます。

JSON
{
  "access_control_list": [
    {
      "user_name": "user@mydomain.com",
      "all_permissions": [
        {
          "permission_level": "CAN_USE"
        }
      ]
    },
    {
      "group_name": "sales",
      "all_permissions": [
        {
          "permission_level": "CAN_USE"
        }
      ]
    }
  ]
}

経験の浅いユーザー

挑戦

ユーザーは、コンピュートやクラウドインフラストラクチャのプロビジョニングに慣れていないか、コンピュートの作成オプションに圧倒されています。

ソリューション

コンピュートポリシーを使用して、「T-shirt」サイズのコンピュート構成 (小、中、大のコンピュートなど) を定義します。

T シャツのサイズごとにポリシーを作成します。 Tシャツ size ポリシーは、ユーザーに対する相対的なコンピュートサイズを示し、柔軟なテンプレートまたはゼロオプション構成のいずれかにすることができます。ゼロオプションポリシーまたはローオプションポリシーには、多くの場合、固定ポリシーと非表示のポリシールールがあります。次の例では、 spark_versionの固定値が DBR 7.3 のポリシーを定義しています。 hidden フラグを true に設定すると、このオプションがユーザーに表示されないようになります。
JSON
```
{ "spark_version": { "type": "fixed", "value": "auto:latest-ml", "hidden": true } }
```
フレキシブルテンプレートを定義する場合は、 range、 blocklist、 regex、および unlimited ポリシーポリシーを使用して、上限、非オプションフィールド、および半制限されたポリシーエレメントを設定できます。次の例では、オートスケールノードを最大 25 まで有効にするポリシーを定義しています。この定義を使用して、各 T シャツサイズに上限を設定しながら、ある程度の柔軟性を確保できます。コンピュートテンプレートのアプローチの詳細については、「リソースの過剰な使用」を参照してください。
JSON
```
{ "autoscale.max_workers": { "type": "range", "maxValue": "25", "defaultValue": 5 } }
```
Tシャツサイズのコンピュートを作成できるようにすべきユーザーにポリシーを割り当てます。ポリシーは、ユーザーレベルまたはグループレベルで、ポリシー UI またはポリシーパーミッション APIを使用して割り当てることができます。たとえば、UI を使用してこのポリシーをすべてのユーザーに割り当てるには、次のようにします。
1. ポリシーに移動し、[ 編集 ] を選択します。
2. 「アクセス許可」 タブを選択します。
3. ドロップダウンの 「グループ」 で 「すべてのユーザー」 オプションを選択します。
これらの新しいポリシーのみを使用する必要があるグループから、無制限のポリシーへのアクセスを取り消します。コンピュートポリシーが使用されると、"コンピュート作成" アクセス許可を持つユーザーは、制限のないポリシーにアクセスできるようになります。この権限を持つべきでないユーザーに対しては、この権限を取り消すことが重要です。

コンピュートの作成アクセス許可を取り消すには、「コンピュート作成アクセス許可の構成」を参照してください。

ユースケース固有のポリシー

挑戦

一部のワークロードまたは分析が既存のポリシーと互換性がないか、ユーザーが特定のワークロードの種類の正しいコンピュート構成を知らない。

ソリューション

既存のポリシーではうまく機能しないワークロードが見つかった場合、既存のポリシーを拡張するのではなく、それらのワークロードに特化した新しいポリシーを作成する方が良いでしょう。

これらのポリシーを使用してコンピュートを作成するためには、特定のユースケースに合わせて調整されたポリシーを作成することが役立ちます。これらのポリシーにわかりやすい名前を割り当てて、ユーザーがポリシーを識別しやすくします。たとえば、ワークロードが述語プッシュダウンをサポートするデータソースに対してクエリを実行する場合、ベストプラクティスは、ワーカーの最小値を低くまたはゼロにしてオートスケールを強制する特定のポリシーを構築することです。このポリシーにより、クラウドプロバイダーと Databricks のコストが、クエリのプッシュされたコンポーネントをデータソースがコンピュートするのを待っている間に不必要に増加しないようにします。

ユースケース固有のベストプラクティスを適用するポリシーを作成します。この例では、ワーカーの最小数に対して固定値が 0 のポリシーを定義します。また、このポリシーは、コンピュートがオートスケールされることを強制し、述語プッシュダウンの例のベスト・プラクティスを満たします。
JSON
```
{ "autoscale.min_workers": { "type": "fixed", "value": "0", "hidden": false } }
```
これらのユースケースでコンピュートをビルドする必要があるユーザーにポリシーを割り当てます。ポリシーをユーザーレベルまたはグループレベルで割り当てるには、ポリシー UI または Permissions APIを使用します。たとえば、UI を使用してこのポリシーをデータサイエンティストグループに割り当てるには、次のようにします。
1. ポリシーに移動し、[ 編集 ] を選択します。
2. 「アクセス許可」 タブを選択します。
3. 特定のチームにポリシーを割り当てるには、 「ユーザーまたはグループの選択」 ドロップダウンでチームの名前を選択します。

リソースの過剰な使用

挑戦

ユーザーが不必要に大きなコンピュートを作成し、過剰で高価なリソースを消費しています。これは、多くの場合、次の原因で発生します。

自動スケールのアクティブ化に失敗した。
自動終了ウィンドウの誤った使用。
最小ワーカーノード数が多い
高価なインスタンスタイプ。

ソリューション

コンピュートポリシーを内部承認プロセスと組み合わせると、リソースの制御が可能になり、必要に応じて大規模なコンピュートリソースにアクセスできるようになります。

より大規模またはより柔軟なポリシーへのアクセスを許可するためのレビュープロセスを確立します。レビュープロセスには、より大規模またはより柔軟なコンピュート構成の必要性をサポートする情報を収集するインテークフォームが必要です。プラットフォームの所有権チームは、この情報を評価して、ワークロード要件をサポートする方法を決定する必要があります。次の図は、T シャツのサイズを使用した承認プロセスの例を示しています。
制約を減らし、タグなどのガバナンス項目の制御に重点を置いた、柔軟なポリシーを作成します。柔軟なポリシーの例を以下に示します。

JSON
{
  "autoscale.min_workers": {
    "type": "range",
    "maxValue": 20,
    "defaultValue": 2
  },
  "autoscale.max_workers": {
    "type": "range",
    "maxValue": 100,
    "defaultValue": 8
  },
  "autotermination_minutes": {
    "type": "range",
    "maxValue": 120,
    "defaultValue": 60
  },
  "node_type_id": {
    "type": "blocklist",
    "values": ["n2-highmem-64", "n2-highmem-80", "n1-standard-96", "n2d-standard-128", "n2d-standard-224"],
    "defaultValue": "n2-highmem-8"
  },
  "driver_node_type_id": {
    "type": "blocklist",
    "values": ["n2-highmem-64", "n2-highmem-80", "n1-standard-96", "n2d-standard-128", "n2d-standard-224"],
    "defaultValue": "n2-highmem-8"
  },
  "spark_version": {
    "type": "fixed",
    "value": "auto:latest-ml",
    "hidden": true
  },
  "enable_elastic_disk": {
    "type": "fixed",
    "value": true,
    "hidden": true
  },
  "custom_tags.team": {
    "type": "fixed",
    "value": "product"
  }
}

このポリシーは、ユーザーが次のことを行えるようにすることで柔軟性を提供します。

過度に高価なインスタンスタイプを除くさまざまなインスタンスタイプから選択します。
- 最大 100 ノードまでのクラスターを構成します。
- 自動終了を最大 120 分に設定します。
また、合理的な制限を設け、次の方法でガバナンスを確保します。
- このチームにタグを適用します。
- オートスケールが必要です。
- elastic disk オートスケールの有効化。
- Databricks ランタイムバージョンの指定。
このポリシーは、さまざまなコンピュート構成でジョブを調整する必要がある経験豊富なユーザーに最適であり、承認プロセスに関連付けるポリシーの良い例です。

アップグレードと承認のプロセスを文書化し、ユーザーと共有します。また、柔軟性の向上やコンピュートの大さが必要なワークロードの種類を特定するためのガイダンスを公開することも役立ちます。
ユーザーが承認されたら、ポリシーを割り当てます。ポリシーは、ユーザーレベルまたはグループレベルでポリシー UI を使用して割り当てるか、アクセス許可 APIに要求を送信することで割り当てることができます。
JSON
```
{
  "access_control_list": {
    "user_name": "users_email@yourdomain.com",
    "permission_level": "CAN_USE"
  }
}
```

詳細情報

Databricksのコンピュートポリシーの詳細については、「コンピュートポリシーの作成と管理」および「コンピュートポリシー: クラスターポリシーを使用したフル Admin Control を使用した単純なクラスター作成を許可する」を参照してください。

コンピュート ポリシー ロールアウト​

Communicate and test コンピュート ポリシー​

コンピュート ポリシー導入の考慮事項​

制限の厳しい環境​

制限のない環境​

最終ロールアウト​

具体的な課題と戦略​

タグの施行​

挑戦​

ソリューション​

経験の浅いユーザー​

挑戦​

ソリューション​

ユースケース固有のポリシー​

挑戦​

ソリューション​

リソースの過剰な使用​

挑戦​

ソリューション​

詳細情報​

コンピュートポリシーロールアウト

Communicate and test コンピュートポリシー

コンピュートポリシー導入の考慮事項

制限の厳しい環境

制限のない環境

最終ロールアウト

具体的な課題と戦略

タグの施行

挑戦

ソリューション

経験の浅いユーザー

挑戦

ソリューション

ユースケース固有のポリシー

挑戦

ソリューション

リソースの過剰な使用

挑戦

ソリューション

詳細情報