プールのベストプラクティス
この記事では、プールの概要と、プールを最適に構成する方法について説明します。 プールの作成に関する情報については、「 プール設定リファレンス」を参照してください。
ワークロードがサーバレス コンピュートをサポートしている場合、 Databricks では、プールの代わりにサーバレス コンピュートを使用して、常時稼働でスケーラブルなコンピュートを利用することをお勧めします。 Connect to サーバレス コンピュートを参照してください。
プールに関する考慮事項
プールを作成する際には、次の点を考慮してください。
- ターゲットワークロードに基づいて、インスタンスタイプと Databricks ランタイムを使用してプールを作成します。
- 可能であれば、スポットインスタンスをプールに追加してコストを削減します。 スポット プールはワーカー ノードとしてのみ使用します。 ドライバーノードは、オンデマンドインスタンスを使用する必要があります。
- 実行時間が短く、実行時間の要件が厳しいジョブのオンデマンドインスタンスをプールに入力します。
- プール タグとクラスタータグを使用して請求を管理します。
- プールを事前に設定して、クラスターで必要なときにインスタンスが使用可能であることを確認します。
ワークロードに基づくプールの作成
組織で一般的に使用するインスタンスの種類と Databricks ランタイムごとにプールを作成することで、インスタンスの取得時間を最小限に抑えることができます。 たとえば、ほとんどの データエンジニアリング クラスターがインスタンスタイプ A を使用し、データサイエンスクラスターがインスタンスタイプ B を使用し、アナリティクスクラスターがインスタンスタイプ C を使用する場合、各インスタンスタイプでプールを作成します。
スポットインスタンスプールの使用
ドライバーノードとワーカーノードの要件が異なる場合は、それぞれに異なるプールを使用します。
Databricks では、ドライバー ノードにスポット インスタンスを使用しないことをお勧めします。 ワーカーノードにスポットプールを使用する場合は、 ドライバータイプ としてオンデマンドプールを選択します。
実行時間が短く、実行時間の要件が厳しいジョブにオンデマンドインスタンスを使用するようにプールを構成します。 オンデマンドインスタンスを使用して、取得したインスタンスがスポットマーケットで上位の入札者に失われるのを防ぎます。
インタラクティブな開発をサポートするスポットインスタンスをクラスターに使用するようにプールを設定するか、信頼性よりもコスト削減を優先するジョブを設定します。
タグ プールを使用してコストと課金を管理する
プールを正しいコストセンターにタグ付けすると、コストと使用量のチャージバックを管理できます。 複数のカスタムタグを使用して、複数のコストセンターをプールに関連付けることができます。 ただし、プールからクラスターを作成するときにタグがどのように伝達されるかを理解することが重要です。 プールのタグは基になるクラウド プロバイダー インスタンスに伝達されますが、クラスターのタグは伝達されません。 クラウドプロバイダーのコンピュートコストのチャージバックを管理するために必要なすべてのカスタムタグをプールに適用します。
プール タグとクラスタータグはどちらも Databricks 請求に反映されます。 クラスタータグとプールタグの組み合わせを使用して、 Databricks ユニットのチャージバックを管理できます。
詳細については、「 タグを使用した属性の使用」をご参照ください。
コストを制御するためのプールの構成
次の構成オプションを使用して、プールのコストを制御することができます。
- [Min Idle] インスタンスを 0 に設定して、作業を行っていない実行中のインスタンスに対する支払いを回避します。トレードオフは、クラスターが新しいインスタンスを取得する必要がある場合に時間が増加する可能性があることです。
- 予想される使用量に基づいて 最大容量 を設定します。 これにより、プール内の使用済みインスタンスとアイドル状態のインスタンスの最大数の上限が設定されます。 ジョブまたはクラスターが最大容量でプールからインスタンスを要求した場合、リクエストは失敗し、クラスターはそれ以上のインスタンスを取得しません。 そのため、Databricks では、インスタンスのクォータまたは予算の制約が厳密な場合にのみ、最大容量を設定することをお勧めします。
- アイドル インスタンスの自動終了時間を設定して、インスタンスがクラスターから解放されてからプールからドロップされるまでの間にバッファーを提供します。これを、スケジュールされたジョブのインスタンスの可用性を確保しながらコストを最小限に抑えることができる期間に設定します。 たとえば、ジョブ A が午前 8:00 に実行されるようにスケジュールされており、完了するまでに 40 分かかるとします。 ジョブ B は午前 9:00 に実行するようにスケジュールされており、完了するまでに 30 分かかります。 「アイドル・インスタンス自動終了」の値を 20 分に設定して、ジョブ A の完了時にプールに戻されたインスタンスが、ジョブ B の開始時に使用可能になるようにします。 別のクラスターによって要求されない限り、これらのインスタンスはジョブ B の終了から 20 分後に終了します。
プールの事前設定
プールを最大限に活用するために、新しく作成したプールを事前に設定できます。 プール構成で [最小アイドル] インスタンスを 0 より大きく設定します。 または、この値を 0 に設定する推奨事項に従っている場合は、スターター ジョブを使用して、新しく作成されたプールに、クラスターがアクセスできるインスタンスがあることを確認します。
スターター ジョブ アプローチでは、柔軟な実行時間要件を持つジョブを、より厳しいパフォーマンス要件を持つジョブの前、またはユーザーが対話型クラスターの使用を開始する前に実行するようにスケジュールします。 ジョブが終了すると、ジョブに使用されたインスタンスはプールに解放されます。 [Min Idle instance setting (最小アイドルインスタンス設定)] を 0 に設定し、[ Idle Instance Auto Termination (アイドルインスタンス自動終了 )] 時間を十分に長く設定して、アイドルインスタンスが後続のジョブで引き続き使用できるようにします。
スターター ジョブを使用すると、プール インスタンスをスピンアップしてプールに格納し、ダウンストリーム ジョブまたは対話型クラスターで使用できる状態を維持できます。