LoginSignup
1
0

More than 1 year has passed since last update.

@taka_yayoi(Takaaki Yayoi)inデータブリックス・ジャパン株式会社

ベストプラクティス：Databricksのクラスターポリシー

Last updated at Posted at 2022-11-03

Best practices: Cluster policies | Databricks on AWS [2022/9/19時点]の翻訳です。

本書は抄訳であり内容の正確性を保証するものではありません。正確な内容に関しては原文を参照ください。

プレビュー
本機能はパブリックプレビューです。

Databricksのクラスターポリシーを用いることで、管理者はDatabricksワークスペースのクラスターリソースの作成に対するコントロールを行うことができる様になります。クラスターポリシーを効果的に活用することで管理者は以下のことを行うことができます。

  • 標準化されたクラスター設定の強制。
  • 過度なリソース使用の回避とコストコントロール。
  • クラスターに適切にタグをつけることで正確な課金按分を実現。
  • 特定のワークロードをターゲットとした事前設定済みクラスターをユーザーに提供することで分析や処理を促進。

クラスターポリシーのイントロダクションと設定の推奨に関しては、Databricksクラスターポリシーの動画をご覧ください。

効果的なオンボーディング、承認、課金プロセスを組み合わせることで、クラスターポリシーはDatabricksプラットフォームガバナンスの重要なコンポーネントとなり得ます。このガイドでは、皆様のガバナンスフレームワークにクラスターポリシーを組み込むために成功するプランを作成すことを手助けする推奨事項とベストプラクティスを説明します。

ガバナンスは企業の要件や既存のガバナンスインフラストラクチャにユニークなものなので、本書はクラスターポリシーに共通して適用される推奨事項をカバーするところからスタートします。本書の最後のセクションでは、皆様自身の環境で直面するであろう課題に取り組むための固有の戦略を議論します。

本書では、クラスターのガバナンスをロールアウトを成功させるための以下のベストプラクティスと推奨事項を議論します。

  • ガバナンスが効いた環境にユーザーが移行することを支援するために、フェーズ分けしてクラスターポリシーを導入するプランの作成。
  • クラスターポリシーのロールアウトのそれぞれのフェーズにおける変更に関するコミュニケーションのプランの作成。
  • クラスターガバナンスの課題の特定と、それらの課題に取り組むための戦略の実装。

クラスターポリシーのロールアウト

クラスターポリシーの実装は、ユーザーエクスペリエンスに大幅な変更をもたらす場合があります。移行を通じてユーザーをガイドするために、フェーズ分けされたアプローチをお勧めします。

  • 間も無く反映される変更に関するコミュニケーションを行い、ユーザーがクラスター設定をテストする機会を提供する。
  • ソフトロールアウトの実行。
  • 更なるポリシー変更をインクリメンタルに導入。
  • 全体的にガバナンスが効いた環境へのハードガットオーバーの実行。

フェーズ分けされたロールアウトを行うことで、ユーザーは新たにポリシーに慣れることができ、既存ワークロードの破壊を避けることができます。以下の図では、この推奨フェーズの例を示しています。

以下のセクションでは、これらのステージにおける詳細情報を示しています。

クラスターポリシーに関するコミュニケーションとテスト

間も無く反映される変更に関してユーザーとコミュニケーションするところからプロセスをスタートします。

  • 反映される変更の詳細。
  • なぜこれらの変更が行われるのか。
  • ワークロードを適切に移行するためにユーザーは何をする必要があるのか。
  • 変更に対するフィードバックをどの様に提供するのか。
  • ロールアウトのそれぞれのステージのタイムライン。
  • フェーズ分けされたロールアウトのそれぞれのステージを開始する際の、当該ステージに関するより詳細な情報のコミュニケーション。

以下の図では、フェーズ分けされたロールアウトのコミュニケーションプランのサンプルを示しています。

お使いの環境やクラスターポリシーの戦略に応じて、あなたのプランにおいては異なるステージを持つことになるかと思います。このサンプルでは以下の4ステージが含まれています。

  • ステージ1には、ユーザーへのプランの説明とテストの開始が含まれます。ユーザーには、新たなポリシーに準拠したクラスターで現在と将来のワークロードをテストする機会を提供すべきです。このプロセスの早い段階で既存、あるいは計画されたワークロードにおけるいかなる問題を特定したいと考えるでしょう。
  • ステージ2では、クラスタータグ付けポリシーのロールアウトに沿ってテストを継続します。
  • ステージ3では、small、large、X-largeクラスタータイプの様なTシャツサイズを用いたクラスタータイプを導入します。
  • ステージ4では、ユーザードキュメントの完成とともにクラスターポリシーの最終ロールアウトを行います。

また、ユーザーは初期ステージにおいて計画されているクラスター設定を用いて自身のワークロードをテストする機会を持つべきです。このテストによって、提案されたポリシーを用いて既存のワークロードを実行する際の問題の特定を行うことができます。

クラスターポリシー導入における検討事項

クラスターポリシーの初期デプロイメントを計画する際には、現在の管理ポリシーを確認してください。特に、ユーザーがクラスターを作成でき、よりオープンな環境から、制限のある環境に移行しようとしているのかどうかを確認してください。

制限環境

ユーザーがクラスター作成権限を持つことのない環境の場合、ユーザーのイネーブルメントのプランとともに制限ポリシーをロールアウトすることからスタートします。イネーブルメントプランには、コンピューターベースのトレーニング、ワークショップやドキュメントが含まれます。ユーザーに対してクラスター設定のベストプラクティスにおけるガイドを提供することで、プラットフォームを完全に活用できる能力を改善することができます。プラットフォームによってコンプライアンスと競争優位性を示すに従い、ポリシーを緩和することができます。

制限のない環境

制限のない環境においては、ポリシーの適用はより困難なものとなります。いくつかの既存ユースケースとクラスターは、多くの場合新たなポリシーの制約に収まらないので、テストにおけるこれらの特定とソフトロールアウトステージが重要となります。

すべてのワークロードが稼働を続けられる様に、クラスター作成権限や制限なしポリシーへのアクセス権を持つユーザーには、ソフトロールアウトにおいてはそのポリシーへのアクセスを維持します。ユーザーは、利用できる様になる新たなポリシーを用いて自身のすべてのワークロードをテストするために、ソフトロールアウトを活用すべきです。

ユーザーがポリシーに関するフィードバックできる場を設ける様にしてください。問題が生じた際には、ポリシーを改善あるいは新たなポリシーを定義するためにユーザーと協力してください。

最終ロールアウト

デッドラインに達したら、制限ユーザーに対する制限なしポリシーへのアクセスを削除します。これでクラスターポリシーのロールアウトが完了します。

特定の課題と戦略

特定の課題に対応するためにクラスターポリシーを適用する例を以下に示します。これらの戦略の多くは同時に適用することができますが、すべてのポリシー対してそれぞれの戦略を適用する必要があります。例えば、タグ強制戦略とTシャツサイズ戦略を使用する場合には、それぞれのTシャツポリシーにもcustom_tag.*ポリシーが必要になります。

タグの強制

課題

ユーザーは自由にクラスターを作成することができ、必要なタグを強制するメカニズムがありません。

ソリューション

  1. ユーザーからクラスター作成権限を剥奪します。

  2. 適用可能なクラスターポリシーすべてにクラスタータグのルールを追加します。ポリシーにクラスタータグのルールを追加するには、custom_tags.<tag-name>属性を使用します。無制限ポリシーの下で任意の値にすることも、固定ポリシー、許可リストポリシー、ブロックリストポリシー、正規表現ポリシー、レンジポリシーを用いて制限をかけることもできます。例えば、適切な費用按分やコスト割り当てを確実に行うために、許可されたコストセンターの値のリストに制限される様に、それぞれのポリシーでCOST_CENTERタグを強制します。

    JSON
    {"custom_tags.COST_CENTER": {"type":"allowlist", "values":["9999", "9921", "9531" ]}}

    このポリシーを使うすべてのユーザーは、クラスターを起動するためには9999、9921、9531の値のCOST_CENTERを指定しなくてはなりません。

  3. これら3つのコストセンターに対して課金をされるユーザーに対してクラスターポリシーを割り当てます。クラスターポリシーのUIあるいは/permissions/cluster-policies/{cluster_policy_id}エンドポイントを通じて、ユーザーかグループにポリシーを割り当てることができます。以下の例では、リクエスト本体でセールス部門にポリシーを割り当てています。

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

経験の少ないユーザー

課題

ユーザーはクラスターやクラウドインフラストラクチャの配備に不慣れであるか、クラスター作成のオプションに圧倒されています。

ソリューション

small、medium、largeクラスターの様な「Tシャツ」サイズのクラスター設定を定義するクラスターポリシーを使います。

  1. それぞれのTシャツサイズのポリシーを作成します。Tシャツサイズポリシーは、ユーザーに対する相対的なクラスターサイズを示すものであり、柔軟なテンプレートから設定オプションなしのものでも構いません。ゼロオプションや少数のオプションのポリシーは、多くの場合は固定かつ非表示ポリシールールを持ちます。以下例では、spark_versionにDBR 7.3の固定値を持つポリシーを定義しています。hiddenフラグをtrueに設定すると、このオプションはユーザーに表示されなくなります。

    JSON
    {"spark_version": { "type": "fixed", "value": "7.3.x-scala2.12", "hidden": true }}

    柔軟なテンプレートを定義する際には、上限値や必須フィールド、準制限ポリシー要素を設定するために、レンジポリシー、許可リストポリシー、ブロックリストポリシー、正規表現ポリシー、無制限ポリシーのを使用することができます。以下の例では、ノードのオートスケーリングを最大25にするポリシーを定義しています。ある程度の柔軟性を提供しつつもそれぞれのTシャツサイズの上限値を設定するためにこの定義を使うことができます。クラスターテンプレートアプローチの詳細については、過度なリソース使用をご覧ください。

    JSON
    {"autoscale.max_workers": { "type": "range", "maxValue": "25", "defaultValue": 5}}

  2. Tシャツサイズのクラスターを作成できるユーザーにポリシーを割り当てます。ポリシーは、クラスターポリシーのUIかCluster Policy Permissions APIを通じてユーザー、グループに割り当てることができます。例えば、UIですべてのユーザーにこのポリシーを割り当てるには以下を実行します。

    1. クラスターポリシーに移動し、Editを選択します。
    2. Permissionsタブを選択します。
    3. ドロップダウンのGroupsでall usersを選択します。

  3. これらの新たなポリシーのみを使用すべきグループから無制限ポリシーへのアクセスを剥奪します。クラスターポリシーを使用する際に、「クラスター作成」権限へのアクセス権を持っているとユーザーは無制限ポリシーにアクセスできてしまいます。無制限ポリシーにアクセスさせないユーザーからはこのアクセス権を剥奪することが重要です。

    クラスター作成権限の剥奪に関しては、Configure cluster creation permissionをご覧ください。

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

課題

いくつかのワークロードや分析が既存のポリシーに合致しない、あるいは特定のタイプのワークロードに適したクラスター設定をユーザーが知りません。

ソリューション

既存のポリシーでワークロードがうまく動作しない場合には、多くの場合は既存のポリシーを拡張するのではなく、これらのワークロードをターゲットとした新たなポリシーを作成する方が良いです。

これらのポリシーを使ってユーザーがクラスターを作成できる様に、特定のユーズケースにチューニングしたポリシーを作成することが役立ちます。ユーザーが特定しやすい様に、これらのポリシーには説明的な名称を割り当てます。例えば、ワークロードが述語プッシュダウンをサポートするデータソースにクエリーを行うのであれば、ワーカーノードの最小値がゼロあるいは少ない数であるオートスケーリングを強制する固有のポリシーを作成することがベストプラクティスとなります。このポリシーによって、クエリーのプッシュダンされたコンポーネントをデータソースが計算するのを待つ間に、クラウドプロバイダーとDatabricksのコストが不必要に増加しないことを保証することができます。

  1. ユースケース固有のベストプラクティスの活用を強制するポリシーを作成します。このサンプルでは、ワーカーの最小数が固定値0であるポリシーを定義しています。また、このポリシーは、述語プッシュダウンのベストプラクティスを満足する様にクラスターがオートスケールすることを強制します。

    JSON
    {"autoscale.min_workers": { "type": "fixed", "value": "0", "hidden": false }}

  2. これらのユースケース向けのクラスターを作成する必要があるユーザーにポリシーを割り当てます。ポリシーは、クラスターポリシーのUIかPermissions API 2.0を通じてユーザー、グループに割り当てることができます。例えば、UIですべてのユーザーにこのポリシーを割り当てるには以下を実行します。

    1. クラスターポリシーに移動し、Editを選択します。
    2. Permissionsタブを選択します。
    3. ドロップダウンのGroupsでall usersを選択します。

過度なリソース使用

課題

ユーザーが不必要に大きなクラスターを作成し、過度に高価なリソースを消費しています。これは多くの場合、以下の要因で引き起こされます。

  • オートスケーリングの有効化に失敗。
  • 自動停止ウィンドウの不適切な利用。
  • 最小ワーカーノード数が大きすぎる。
  • 高価なインスタンスタイプ。

ソリューション

内部承認プロセスとクラスターポリシーを組み合わせることで、必要な際には大規模な計算リソースへのアクセスを提供しつつも、リソースに対するコントロールを実現することができます。

  1. より大規模あるいはより柔軟なポリシーへのアクセスを許可するレビュープロセスを確立します。レビュープロセスでは、大規模クラスターあるいは柔軟なクラスター構成を必要性をサポートする情報の収集する取り込み口を設けるべきです。プラットフォームノーなーシップを持つチームは、ワークロードの要件をどの様にサポートするのかを決定するためにこの情報を評価すべきです。以下の図では、Tシャツサイジングを用いたサンプルの承認プロセスを説明しています。

  2. 制約の少ないより柔軟なポリシーを作成し、タグの様なガバナンス項目のコントロールにフォーカスします。柔軟なポリシーのサンプルを示します。

    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": ["z1d.12xlarge", "z1d.6xlarge", "r5d.16xlarge", "r5a.24xlarge", "c5.24xlarge"],
    "defaultValue": "i3.xlarge"
  },
  "driver_node_type_id": {
    "type": "blocklist",
    "values": ["z1d.12xlarge", "z1d.6xlarge", "r5d.16xlarge", "r5a.24xlarge", "c5.24xlarge"],
    "defaultValue": "i3.xlarge"
  },
  "spark_version": {
    "type": "fixed",
    "value": "7.3-scala2.12",
    "hidden": true
  },
  "enable_elastic_disk": {
    "type": "fixed",
    "value": true,
    "hidden": true
  },
  "custom_tags.team": {
    "type": "fixed",
    "value": "product"
  }
}

    このポリシーは、ユーザーが以下のことを行うことができる柔軟性を提供します。

    • あまりに高価なものを除いた一連のインスタンスタイプの選択。
    • 100ノードまでのクラスターの設定。
    • 最大120分の自動停止の設定。

    また、以下によって合理性のある制限とガバナンスを保証します。

    • このチーム向けのタグの強制。
    • オートスケーリングの要求。
    • 弾力性のあるディスクオートスケーリングの有効化。
    • Databricksランタイムバージョンの指定。

    このポリシーは、さまざまなクラスターで自分のジョブをチューニングする必要がある経験豊富なユーザーには理想的なものであり、承認プロセスと関連づけるには良いサンプルのポリシーとなります。

  3. アップグレード、承認プロセスのドキュメントを作成し、ユーザーと共有します。また、より柔軟性のある、あるいはより大規模なクラスターを必要とする可能性のあるワークロードのタイプを特定するためのガイドを公開することも有効的です。

  4. ユーザーが承認されたら、ポリシーを割り当てます。ポリシーは、クラスターポリシーのUIかPermissions API 2.0を通じてユーザー、グループに割り当てることができます。

    JSON
    {
    "access_control_list": {
      "user_name": "users_email@yourdomain.com",
      "permission_level": "CAN_USE"
    }
}

詳細を学ぶ

Databricksにおけるクラスターポリシーの詳細に関しては、Databricksクラスターポリシーの管理 - Qiitaと、クラスターポリシーに関するブログ記事Allow Simple Cluster Creation with Full Admin Control Using Cluster Policiesをご覧ください。

Databricks 無料トライアル

Databricks 無料トライアル

1
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
0