プールのベストプラクティス

この記事では、プールとは何か、およびプールを最適に構成する方法について説明します。プールの作成については、「プール構成リファレンス」を参照してください。

プールに関する考慮事項

プールを作成するときは、次の点を考慮してください。

ターゲットワークロードに基づいて、インスタンスの種類と Databricks ランタイムを使用してプールを作成します。
可能であれば、コストを削減するために、プールにプリエンプティブ VM インスタンスを追加します。ワーカーノードとしてプリエンプティブ VM プールのみを使用します。ドライバーノードでは、オンデマンドインスタンスを使用する必要があります。
実行時間が短く、実行時間の要件が厳しいジョブのオンデマンドインスタンスをプールに入力します。
プールタグとクラスタータグを使用して課金を管理します。
プールを事前設定して、クラスターで必要なときにインスタンスを使用できるようにします。

ワークロードに基づいてプールを作成する

組織で一般的に使用するインスタンスの種類と Databricks ランタイムごとにプールを作成することで、インスタンスの取得時間を最小限に抑えることができます。たとえば、ほとんどのデータエンジニアリングクラスターがインスタンスタイプ A を使用し、データサイエンスクラスターがインスタンスタイプ B を使用し、アナリティクスクラスターがインスタンスタイプ C を使用する場合、各インスタンスタイプでプールを作成します。

プリエンプティブ VM インスタンスプールの使用

ドライバーノードとワーカーノードの要件が異なる場合は、それぞれに異なるプールを使用します。

Databricks では、ドライバーノードにプリエンプティブ VM インスタンスを使用しないことを推奨しています。ワーカーノードにプリエンプティブ VM プールを使用する場合は、ドライバータイプとしてオンデマンドプールを選択します。

実行時間が短く、実行時間の要件が厳しいジョブにオンデマンドインスタンスを使用するようにプールを構成します。これは、プリエンプティブルVMインスタンスは、システムイベントによっていつでも停止できるためです。

対話型開発をサポートするクラスターや、信頼性よりもコスト削減を優先するジョブにプリエンプティブル VM インスタンスを使用するようにプールを構成します。

コストと課金を管理するためのタグプール

プールを正しいコスト・センターにタグ付けすると、コストと使用量のチャージバックを管理できます。複数のカスタムタグを使用して、複数のコストセンターをプールに関連付けることができます。ただし、クラスターがプールから作成されるときにタグがどのように伝達されるかを理解することが重要です。プールのタグは基盤となるクラウドプロバイダーインスタンスに伝達されますが、クラスターのタグは伝達されません。クラウド・プロバイダーのコンピュート・コストのチャージバックを管理するために必要なすべてのカスタム・タグをプールに適用します。

プールタグとクラスタータグはどちらも Databricks の課金に反映されます。クラスタータグとプールタグの組み合わせを使用して、Databricks ユニットのチャージバックを管理できます。

詳細については、「タグを使用して使用状況を監視する」を参照してください。

コストを制御するためのプールの構成

プールのコストを制御するには、 Min Idle インスタンスを 0 に設定して、作業を行っていない実行中のインスタンスに対して料金が発生しないようにします。トレードオフは、クラスターが新しいインスタンスを取得する必要がある場合に時間が長くなる可能性があります。

..azure-aws の

You can use the following configuration options to help control the cost of pools:

- Set the [Min Idle](/compute/pools.md#minimum-idle-instances) instances to 0 to avoid paying for running instances that aren’t doing work. The tradeoff is a possible increase in time when a cluster needs to acquire a new instance.
- Set the [Max Capacity](/compute/pools.md#maximum-capacity) based on anticipated usage. This sets the ceiling for the maximum number of used and idle instances in the pool. If a job or cluster requests an instance from a pool at its maximum capacity, the request fails, and the cluster doesn't acquire more instances. Therefore, Databricks recommends that you set the maximum capacity only if there is a strict instance quota or budget constraint.
- Set the [Idle Instance Auto Termination](/compute/pools.md#idle-instance-auto-termination) time to provide a buffer between when the instance is released from the cluster and when it’s dropped from the pool. Set this to a period that allows you to minimize cost while ensuring the availability of instances for scheduled jobs. For example, job A is scheduled to run at 8:00 AM and takes 40 minutes to complete. Job B is scheduled to run at 9:00 AM and takes 30 minutes to complete. Set the Idle Instance Auto Termination value to 20 minutes to ensure that instances returned to the pool when job A completes are available when job B starts. Unless they are claimed by another cluster, those instances are terminated 20 minutes after job B ends.

プールの事前設定

プールを最大限に活用するために、新しく作成したプールを事前に設定することができます。プール構成で [最小アイドル インスタンス数] を 0 より大きく設定します。または、この値を 0 に設定する推奨事項に従っている場合は、スタータージョブを使用して、新しく作成されたプールにクラスターがアクセスできるインスタンスがあることを確認します。

スタータージョブアプローチでは、より厳しいパフォーマンス要件を持つジョブの前、またはユーザーがインタラクティブクラスターの使用を開始する前に、柔軟な実行時間要件を持つジョブを実行するようにスケジュールします。ジョブが終了すると、ジョブに使用されたインスタンスはプールに戻されます。

スタータージョブを使用すると、プールインスタンスをスピンアップし、プールにデータを設定し、ダウンストリームジョブまたは対話型クラスターで引き続き使用できます。