プールのベストプラクティス
この記事では、プールとは何か、およびプールを最適に構成する方法について説明します。 プールの作成については、 「プール構成リファレンス」を参照してください。
注:
ワークロードがサーバレス コンピュートをサポートしている場合、 Databricks では、プールの代わりにサーバレス コンピュートを使用して、常時稼働でスケーラブルなコンピュートを利用することをお勧めします。 Connect to サーバレス コンピュートを参照してください。
プールに関する考慮事項
プールを作成するときは、次の点を考慮してください。
ターゲット ワークロードに基づいて、インスタンスの種類と Databricks ランタイムを使用してプールを作成します。
可能であれば、コストを削減するためにスポットインスタンスをプールに追加します。 スポット プールはワーカー ノードとしてのみ使用します。 ドライバー ノードでは、オンデマンド インスタンスを使用する必要があります。
実行時間が短く、実行時間の要件が厳しいジョブのオンデマンドインスタンスをプールに入力します。
プール タグとクラスター タグを使用して課金を管理します。
プールを事前設定して、クラスターで必要なときにインスタンスを使用できるようにします。
ワークロードに基づいてプールを作成する
組織で一般的に使用するインスタンスの種類と Databricks ランタイムごとにプールを作成することで、インスタンスの取得時間を最小限に抑えることができます。 たとえば、ほとんどの データエンジニアリング クラスターがインスタンスタイプ A を使用し、データサイエンスクラスターがインスタンスタイプ B を使用し、アナリティクスクラスターがインスタンスタイプ C を使用する場合、各インスタンスタイプでプールを作成します。
スポットインスタンスプールの使用
ドライバー ノードとワーカー ノードの要件が異なる場合は、それぞれに異なるプールを使用します。
Databricks では、ドライバー ノードにスポット インスタンスを使用しないことを推奨しています。 ワーカー ノードにスポット プールを使用する場合は、ドライバー タイプとしてオンデマンド プールを選択します。
実行時間が短く、実行時間の要件が厳しいジョブにオンデマンド インスタンスを使用するようにプールを構成します。 オンデマンドインスタンスを使用して、取得したインスタンスがスポット市場で高額入札者に奪われるのを防ぎます。
インタラクティブな開発をサポートするクラスターや、信頼性よりもコスト削減を優先するジョブにスポットインスタンスを使用するようにプールを構成します。
コストと課金を管理するためのタグ プール
プールを正しいコスト・センターにタグ付けすると、コストと使用量のチャージバックを管理できます。 複数のカスタムタグを使用して、複数のコストセンターをプールに関連付けることができます。 ただし、クラスターがプールから作成されるときにタグがどのように伝達されるかを理解することが重要です。 プールのタグは基盤となるクラウドプロバイダーインスタンスに伝達されますが、クラスターのタグは伝達されません。 クラウド・プロバイダーのコンピュート・コストのチャージバックを管理するために必要なすべてのカスタム・タグをプールに適用します。
プール タグとクラスター タグはどちらも Databricks の課金に反映されます。 クラスター タグとプール タグの組み合わせを使用して、Databricks ユニットのチャージバックを管理できます。
詳細については、 「タグを使用して使用状況を監視する」を参照してください。
コストを制御するためのプールの構成
..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 に設定する推奨事項に従っている場合は、スターター ジョブを使用して、新しく作成されたプールにクラスターがアクセスできるインスタンスがあることを確認します。
スターター・ジョブ・アプローチでは、柔軟な実行時間要件を持つジョブを、より厳しいパフォーマンス要件を持つジョブの前、またはユーザーが対話型クラスターの使用を開始する前に実行するようにスケジュールします。 ジョブが終了すると、ジョブに使用されたインスタンスが解放されてプールに戻されます。 [Min Idle instance] 設定を 0 に設定し、[Idle Instance Auto Termination time] を十分な長さに設定して、アイドル状態のインスタンスが後続のジョブで使用可能な状態を維持できるようにします。
スターター ジョブを使用すると、プール インスタンスをスピンアップし、プールにデータを設定し、ダウンストリーム ジョブまたは対話型クラスターで引き続き使用できます。