Best practices: pools | Databricks on AWS [2021/9/22時点]の翻訳です。

クラスターは、ノートブックやジョブを実行するための計算リソースや設定を提供します。クラスターは、要望に応じてクラウドプロバイダーが配備するインスタンス上で実行されます。Databricksプラットフォームは、あなたの分析インフラストラクチャを管理するための効率的かつコスト効果の高い方法を提供します。本書では、新規クラスターの作成、あるいは、既存クラスターをスケールアップする際の以下のような課題にどのように取り組むのかを説明します。

Databricksジョブの実行時間は、インスタンスを配備し、新規クラスターを起動する時間よりも短いかもしれません。
クラスターのオートスケーリングが有効化されている際、クラウドプロバイダーが新規インスタンスを配備するのに時間を要します。これは、ジョブのパフォーマンス要件や変化するワークロードに対してネガティブなインパクトを与えます。

Databricksのプールは、一連の利用可能なインスタンスを保持することで、クラスターの起動時間、スケールアップ時間を削減します。

ドライバーノードとワーカーノードに異なるプールを指定することもできます。

プールの説明と、推奨の設定については、以下の動画をご覧ください。

以下の図に示しているように、プールにアタッチされたクラスターがインスタンスを必要とした際、まず初めに、プールで利用可能なインスタンスの一つを配置しようとします。プールに利用可能なインスタンスが無い場合には、クラスターの要求に応えられるようにクラウドプロバイダーから新規インスタンスを確保することでプールを拡張します。クラスターがインスタンスを解放した際には、インスタンスはプールに返却され、他のクラスターが利用できるようになります。プールにアタッチされたクラスターのみがプールのインスタンスを利用できます。

本書では、プールを使う際に、ベストなパフォーマンス、最低限のコストを達成できるようにする以下のベストプラクティスを議論します。

ターゲットのワークロードに応じたインスタンスタイプ、Databricksランタイムを用いたプールを作成する。
可能であれば、コストを削減するためにスポットインスタンスでプールを構成する。
短い実行時間、厳密な時間の要件があるジョブに対しては、オンデマンドインスタンスでプールを構成する。
課金管理のためにプールタグとクラスタータグを活用する。
コストを最小化するためにプールの設定オプションを活用する。
クラスターがインスタンスを必要とした際、確実にインスタンスを利用できるように事前にプールのインスタンスを確保しておく。

ワークロードに応じたプールを作成する

ドライバーノードとワーカーノードに異なる要件があるのであれば、それぞれにプールを作成します。

あなたの組織で共通して利用するインスタンスタイプ、Databricksランタイムでそれぞれのプールを作成することで、インスタンスの確保に要する時間を最小化することができます。例えば、多くのデータエンジニアリング用クラスターがインスタンスタイプAを使用し、データサイエンス用クラスターがインスタンスタイプB、アナリティクス用クラスターがインスタンスタイプCを使っているのであれば、それぞれのインスタンスタイプでプールを構成します。

実行時間が短く、厳密な時間の要件があるジョブに対しては、オンデマンドインスタンスを使うようにプールを設定します。スポットマーケットのビッディングによって、確保したインスタンスが失われることを避けるためには、オンデマンドインスタンスを使用します。

信頼性よりもコストの優先度が高いインタラクティブな開発、ジョブにおいては、スポットインスタンスを使用するようにプールを設定します。

コスト、課金を管理するためにプールにタグ付けする

コストと使用料のチャージバックを管理するために、プールを適切なコストセンターにタグ付けします。プールに対して複数のコストセンターを関連づける複数のカスタムタグを使用することができます。しかし、プールからクラスターを作成する際に、どのようにタグが伝播するのかを理解することが重要です。以下の図に示すように、プールのタグは背後にあるクラウドプロバイダーのインスタンスに伝搬しますが、クラスタータグは伝搬しません。クラウドプロバイダーの計算コストのチャージバックを管理するのに必要な全てのカスタムタグを、プールに適用してください。

プールタグとクラスタータグの両方はDatabricksの課金に伝搬します。Databricksユニット(DBU)のチャージバックを管理するために、クラスタータグとプールタグを組み合わせて活用することができます。

より詳細に関しては、Monitor usage using cluster and pool tagsをご覧ください。

コストをコントロールするためにプールを設定する

プールのコストをコントロールするために、以下の設定オプションを活用することができます。

処理を行なっていない実行中のインスタンスの課金を避けるために、Min Idle instancesを0に設定します。クラスターが新規インスタンスを必要とした際に要する時間とのトレードオフがあります。
クラスターからインスタンスがリリースされた時間と、プールから削除されるまで時間の間のバッファを設けるためにIdle Instance Auto Terminationを設定します。スケジュールされたジョブの可用性を保証しつつも、コストを最小化することができる期間に、この値を設定することができます。例えば、8:00AMにスケジュールされたジョブAが処理に40分かかり、9:00AMにスケジュールされたジョブBが処理に30分かかる場合には、Idle Instance Auto Terminationの値を20分に設定することで、ジョブAが処理を完了した際にプールに返却されるインスタンスをジョブBが使用できるようにすることができます。他のクラスターから要求されない限り、ジョブBの終了後20分が経過した時点で停止されます。
予想される使用量に応じてMax Capacityを設定します。これによって、プールで使用されるアイドル状態のインスタンスの上限値に制限を設けることができます。キャパシティの上限に達しているプールに対して、ジョブやクラスターがリクエストを行った際にはリクエストは失敗し、クラスターは追加インスタンスを獲得することはできません。このため、厳密なインスタンスのクォータの制限や予算の制約がある場合にのみ、キャパシティの最大値を設定することをお勧めします。

事前確保済みプール

プールのメリットを完全に享受するために、新規に作成するプールのインスタンスを事前に確保しておくことができます。プールの設定でMin Idle instancesを0より大きい値に設定してください。あるいは、この値を0に設定し、クラスターがアクセスする際にインスタンスを利用できるように、スタータージョブを使用するというプラクティスに従うこともできます。

スタータージョブアプローチにおいては、より気密なパフォーマンス要件を持つジョブや、ユーザーがインタラクティブクラスターを利用する前に、実行時間の要件が厳しく無いジョブをスケジュールします。ジョブが終了すると、ジョブで使用されたインスタンスはプールに返却されます。Min Idle instanceを0に設定し、後続のジョブでインスタンスを利用し続けられるように、Idle Instance Auto Terminationを大きい値に設定します。

スタータージョブを用いることで、プールのインスタンスは起動状態になり、プールに蓄積され、後段のジョブやインタラクティブクラスターでインスタンスを利用できるようになります。

より詳細を学ぶには

詳細はDatabricksのプールを参照ください。

Databricks 無料トライアル

Databricks 無料トライアル