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

警告

この記事はアーカイブ保存されており、内容が製品の現在の状態とは異なる場合があります。コンピューティングポリシーについては、「コンピューティングポリシーの作成と管理」をご覧ください。

Azure Databricks コンピューティングポリシーを使用すると、管理者は Azure Databricks ワークスペースでコンピューティングリソースの作成をコントロールできます。コンピューティングポリシーを効果的に使用することで、管理者は次のことができます。

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

コンピューティングポリシーは、有効なオンボード、承認、およびチャージバックプロセスと組み合わせることで、Azure Databricks プラットフォームガバナンスの基本コンポーネントになることができます。このガイドでは、コンピューティングポリシーをガバナンスフレームワークに統合するための適切なプランを作成するための推奨事項とベストプラクティスについて説明します。

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

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

ユーザーが管理された環境に移行できるように、フェーズでコンピューティングポリシーを導入するためのプランを作成します。
コンピューティングポリシーのロールアウトの各フェーズについて、変更を伝達するためのプランを作成します。
コンピューティングガバナンスの課題を特定し、それらの課題に対処するための戦略を実装します。

コンピューティングポリシーのロールアウト

コンピューティングポリシーを実装すると、ユーザーエクスペリエンスに大きな変化が生じる可能性があります。 Databricks は、ユーザーが移行を進めるのを支援する段階的アプローチを推奨しています。

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

フェーズロールアウトを行うと、ユーザーは新しいポリシーを理解し、既存のワークロードの中断を防ぐことができます。この推奨プロセスの例を次の図に示します。

コンピューティングポリシーのロールアウト計画

コンピューティングポリシーの通信とテスト

今後の変更をユーザーに伝えることにより、プロセスを開始します。通信の計画には、次を含める必要があります。

今後の変更に関する詳細。
これらの変更が発生する理由。
ワークロードを正常に移行するためにユーザーが行う必要があること。
変更に関するフィードバックを提供する方法。
ロールアウトの各ステージのタイムライン。
フェーズロールアウトの各ステージの開始時に、そのステージに関連する詳細情報を伝達します。

次の図は、フェーズロールアウトの通信の計画の例を示しています。

コンピューティングポリシー通信プラン

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

ステージ 1 では、ユーザーへのプランの通信とテストの開始について説明します。ユーザーは、新しいポリシーに準拠するコンピューティングで、現在および予想されるワークロードをテストする機会を持っている必要があります。プロセスの早い段階で、既存のワークロードと予定されているワークロードに関する問題を特定する必要があります。
ステージ 2 は、コンピューティングのタグ付けポリシーのロールアウトと共に、テストを続行します。
ステージ 3 では、コンピューティングの種類が導入されています。この例では、小規模、大規模、または特大のコンピューティングの種類など、T シャツサイズを使用してコンピューティングを指定しています。
ステージ 4 は、完全なユーザードキュメントと共に、コンピューティングポリシーの最終的なロールアウトです。

また、初期のステージで計画されたコンピューティング構成を使用してワークロードをテストすることもできます。このテストは、提案されたポリシーでの実行に問題がある既存のワークロードを特定するのに役立ちます。

コンピューティングポリシーの導入に関する考慮事項

コンピューティングポリシーの初期デプロイを計画するときは、現在の管理ポリシーについて検討してください。特に、ユーザーがコンピューティングの作成を制限されている環境から移行するか、よりオープンな環境から移行するかを検討します。

制限の厳しい環境

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

無制限の環境

制限のない環境では、ポリシーの適用がより困難になることがあります。一部の既存のユースケースとコンピューティングは、ほぼ常に新しいポリシーの制約の範囲外になるため、テスト段階またはソフトロールアウト段階でこれらを識別することが重要です。

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

ポリシーに関するフィードバックを送信するための場所をユーザーに提供してください。問題が発生したときに、ユーザーと協力してポリシーを改良するか、新しいポリシーを定義します。

最終的なロールアウト

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

特定の課題 & 戦略

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

タグの適用

課題

ユーザーはコンピューティングを自由に作成できます。また、必要なタグの適用を強制するメカニズムはありません。

解決策

ユーザーから計算リソース作成権限を取り消します。
該当するコンピューティングポリシーにコンピューティングタグルールを追加します。コンピューティングタグルールをポリシーに追加するには、custom_tags.<tag-name> 属性を使用します。値は無制限のポリシーの下で何でもかまいません。または、固定、許可リスト、ブロックリスト、正規表現、または範囲ポリシーによって制限できます。たとえば、適切なチャージバックとコスト属性を確保するには、許可されているコストセンター値の一覧に制限された各ポリシーに COST_CENTER タグを適用します。
```
{ "custom_tags.COST_CENTER": { "type": "allowlist", "values": ["9999", "9921", "9531"] } }
```
このポリシーを使用するすべてのユーザーは、コンピューティングを起動するために、COST_CENTER タグに 9999、9921、または 9531 を入力する必要があります。
これら 3 つのコストセンターに対して課金できるユーザーにポリシーを割り当てます。ポリシーは、コンピューティングポリシー UI またはポリシー API を使用して、ユーザーまたはグループレベルで割り当てることができます。次の要求本文の例では、営業部門にポリシーを割り当てています。
```
{
  "access_control_list": [
    {
      "user_name": "user@mydomain.com",
      "all_permissions": [
        {
          "permission_level": "CAN_USE"
        }
      ]
    },
    {
      "group_name": "sales",
      "all_permissions": [
        {
          "permission_level": "CAN_USE"
        }
      ]
    }
  ]
}
```

経験のないユーザー

課題

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

解決策

コンピューティングポリシーを使用して、"T シャツ" サイズのコンピューティング構成 (たとえば、小、中、大のコンピューティング) を定義します。

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

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

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

課題

一部のワークロードまたは分析は、既存のポリシーと互換性がないか、ユーザーが特定のワークロードの種類に対する正しいコンピューティング構成を知りません。

解決策

既存のポリシーでうまく機能しないワークロードが見つかる場合は、多くの場合、既存のポリシーを拡張するのではなく、それらのワークロードを対象とする新しいポリシーを作成することをお勧めします。

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

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

リソースの過剰な使用

課題

ユーザーは不必要に大規模なコンピューティングを作成し、過剰で高価なリソースを利用しています。これは多くの場合以下の原因で発生します。

自動スケールのアクティブ化の失敗。
自動終了ウィンドウの誤使用。
最小ワーカーノード数が多い。
コストの高いインスタンスの種類。

解決策

コンピューティングポリシーと内部承認プロセスを組み合わせると、リソースをコントロールできる一方で、必要に応じて大規模なコンピューティングリソースにアクセスすることもできます。

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

{
  "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": ["Standard_E16s_v3", "Standard_E64as_v4", "Standard_E96as_v4", "Standard_E48as_v4"],
    "defaultValue": "Standard_L8s"
  },
  "driver_node_type_id": {
    "type": "blocklist",
    "values": ["Standard_E16s_v3", "Standard_E64as_v4", "Standard_E96as_v4", "Standard_E48as_v4"],
    "defaultValue": "Standard_L8s_v2"
  },
  "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"
  }
}

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

詳細情報

Azure Databricks でのコンピューティングポリシーの詳細については、「コンピューティングポリシーの作成と管理」と、コンピューティングポリシーに関するブログ「クラスターポリシーを使用した完全な管理者コントロールによるシンプルなクラスター作成を許可する」を参照してください。

フィードバック

このページはお役に立ちましたか?

Last updated on 2024-12-17

次の方法で共有

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

コンピューティング ポリシーのロールアウト