次の方法で共有

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

  • [アーティクル]

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

Note

ワークロードでサーバーレス コンピューティングがサポートされている場合、Databricks では、プールではなくサーバーレス コンピューティングを使用して、常時稼働のスケーラブルなコンピューティングを利用することをお勧めします。 「サーバーレス コンピューティングに接続する」を参照してください。

プールに関する考慮事項

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

  • 対象のワークロードに基づいて、インスタンスの種類と Azure Databricks ランタイムを使用してプールを作成する。
  • 可能であれば、プールにスポット インスタンスを設定してコストを削減する。 スポット プールのみをワーカー ノードとして使用します。 ドライバー ノードでは、オンデマンド インスタンスを使用する必要があります。
  • 実行時間が短いジョブおよび実行時間の要件が厳しいジョブ用として、プールにオンデマンドのインスタンスを設定する。
  • プール タグとクラスター タグを使用して課金を管理する。
  • プールを事前設定して、クラスターでインスタンスが必要になったときに確実に使用できるようにする。

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

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

スポット インスタンス プールの使用

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

Azure Databricks では、ドライバー ノードにスポット インスタンスを使用しないことをお勧めします。 ワーカー ノードにスポット プールを使用する場合は、ドライバーの種類としてオンデマンド プールを選択します。

実行時間が短いジョブ、および実行時間の要件が厳しいジョブにオンデマンドのインスタンスを使用するようにプールを構成します。 オンデマンドのインスタンスを使用して、取得したインスタンスがスポット市場の上位入札者に奪われるのを防ぎます。

対話型の開発をサポートするクラスターまたは信頼性よりもコスト削減を優先するジョブにはスポット インスタンスを使用するようにプールを構成します。

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

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

プール タグとクラスター タグはどちらも Azure Databricks の課金に反映されます。 クラスター タグとプール タグの組み合わせを使用して、Azure 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.

プールを事前に設定する

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

スターター ジョブ アプローチを使用して、パフォーマンス要件が厳しいジョブの前、またはユーザーが対話型クラスターの使用を開始する前に、実行時間要件が柔軟なジョブを実行するようにスケジュールします。 ジョブが完了すると、そのジョブに使用されていたインスタンスは解放され、プールに戻されます。 Min Idle インスタンス設定を 0 に設定し、アイドル状態のインスタンスの自動終了の時間を十分に長く設定して、アイドル状態のインスタンスが確実に後続のジョブで引き続き使用できるようにします。

スターター ジョブを使用すると、プール インスタンスを起動し、プールを設定し、ダウンストリーム ジョブまたは対話型クラスターで引き続き使用できるようにすることができます。