次の方法で共有

プール構成リファレンス

  • [アーティクル]

この記事では、UI を使ってプールを作成するときに使用できる設定について説明します。 Databricks CLI を使用してプールを作成する方法の詳細については、「Databricks CLI コマンド」を参照してください。 REST API を使用してプールを作成する方法については、「Instance Pools API」を参照してください。

Note

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

プール サイズ

プールを作成する場合、そのサイズを制御するために、アイドル状態インスタンスの最小数、最大キャパシティ、アイドル状態インスタンスの自動終了の 3 つのパラメーターを設定できます。

アイドル状態インスタンスの最小数

プールがアイドル状態を維持するインスタンスの最小数です。 これらのインスタンスは、自動終了設定に関係なく終了しません。 クラスターがプールからアイドル状態のインスタンスを使用すると、Azure Databricks はこの最小数を維持するために追加のインスタンスをプロビジョニングします。

最大容量

プールがプロビジョニングできるインスタンスの最大数です。 この値を設定すると、すべてのインスタンス (アイドル + 使用中) が制限の対象となります。 プールを使用するクラスターが自動スケーリング中にこの数より多くのインスタンスを要求した場合、要求は INSTANCE_POOL_MAX_CAPACITY_FAILURE エラーで失敗します。

この構成は省略可能です。 Azure Databricks は以下の状況でのみ値を設定することを推奨しています。

  • 上限を守る必要のあるインスタンス クォータ がある場合。
  • ある作業セットを別の作業セットの影響から保護したい場合。 たとえば、インスタンスのクォータが 100 で、ジョブを実行する必要のある A と B というチームがあるとします。 最大 50 のプール A と最大 50 のプール B を作成することで、2 つのチームが 100 クォータを公平に共有することができます。
  • コストに上限を設ける必要がある場合。

アイドル状態インスタンスの自動終了

アイドル状態インスタンスの最小数に設定されている値を超えるインスタンスが、プールによって終了される前にアイドル状態でいられる時間 (分) です。

インスタンスの種類

プールは、新しいクラスターのために待機しているアイドル状態のインスタンスと、クラスターを実行している使用中のインスタンスの両方で構成されます。 これらのインスタンスのインスタンス プロバイダーの種類はすべて同じで、プールの作成時に選択されます。

プールのインスタンスの種類は編集できません。 プールに接続されているクラスターでは、ドライバーノードとワーカー ノードに同じインスタンスの種類が使用されます。 インスタンスの種類の異なるファミリは、メモリ集中型やコンピューティング集中型のワークロードなど、異なるユース ケースに適合します。

Azure Databricks は、あるインスタンスの種類のサポートを終了する場合、1 年前から非推奨に関する通知を常に提供しています。

Note

セキュリティ要件にコンピューティングの分離が含まれている場合は、ワーカー タイプとして Standard_F72s_V2 インスタンスを選択してください。 これらのインスタンスの種類は、物理ホスト全体を消費し、たとえば、米国国防総省影響レベル 5 (IL5) のワークロードなどをサポートするために必要な分離レベルを提供する、分離された仮想マシンを表します。

プリロードされた Databricks Runtime バージョン

プール内のアイドル状態のインスタンスに読み込み済みの Databricks Runtime バージョンを選択することで、クラスターの起動速度を上げることができます。 ユーザーがプールでサポートされるクラスターを作成するときに、その Runtime を選択した場合、そのクラスターは、事前読み込み済み Databricks Runtime バージョンを使用していないプールを利用するクラスターよりも迅速に起動します。

このオプションを [なし] に設定すると、クラスターの起動速度が低下します。これは、Databricks Runtime バージョンがオンデマンドでプール内のアイドル状態のインスタンスにダウンロードされるためです。 クラスターがプール内のインスタンスを解放するとき、Databricks Runtime バージョンはそのインスタンスにキャッシュされたままです。 次のクラスターの作成処理で、同じ Databricks Runtime バージョンを使用する場合、このキャッシュ動作の恩恵を受ける可能性はありますが、保証はされません。

事前に読み込まれた Docker イメージ

Instance Pools API を使ってプールを作成する場合、Docker イメージはプールでサポートされます。

プール タグ

プール タグを使用すると、組織内のさまざまなグループが使用するクラウド リソースのコストの監視を容易に行えます。 プールを作成するときに、キーと値のペアとしてタグを指定できます。これらのタグは、Azure Databricks によって VM やディスク ボリュームなどのクラウド リソース、および DBU 使用状況レポートに適用されます。

便宜上、Azure Databricks では各プールに、Vendor、DatabricksInstancePoolId、DatabricksInstancePoolCreatorId の 3 つの既定タグを適用します。 プールの作成時に、カスタム タグを追加することも可能です。 最大 41 個のカスタム タグを追加できます。

カスタム タグ

プールにタグを追加するには、[Create Pool](プールの作成) ページの下部にある [タブ] タブに移動します。 [+ 追加] ボタンをクリックし、キーと値のペアを入力します。

プールを使用するクラスターは、プール構成から既定のタグとカスタム タグを継承します。 プール タグとクラスター タグを組み合わせて使用する方法の詳細については、「タグを使用した使用状況の監視」を参照してください。

ローカル ストレージの自動スケール

多くの場合、特定のジョブに必要となるディスク領域を見積もることは困難です。 作成時に、プールにアタッチするマネージド ディスクのギガバイト数を見積もらずに済むように、Azure Databricks では、すべての Azure Databricks プールでローカル ストレージの自動スケーリングが自動的に有効になります。

ローカル ストレージの自動スケーリングにより、Azure Databricks では、プールのインスタンスでの使用可能な空きディスク領域量を監視します。 インスタンスのディスクが少なくなりすぎると、ディスク領域が枯渇する前に、新しいマネージド ディスクが自動的にアタッチされます。 ディスクは、仮想マシン 1 台につき 5 TB の合計ディスク領域制限 (仮想マシンの初期ローカル ストレージを含む) まで接続されます。

仮想マシンにアタッチされたマネージド ディスクは、仮想マシンが Azure に返された場合にのみデタッチされます。 つまり、マネージド ディスクは、プールの一部である限り、仮想マシンからデタッチされません。

スポット インスタンス

コストを節約するために、[すべてのスポット] のラジオ ボタンのチェックをオンにして、スポット インスタンスの使用を選択できます。

プール内のクラスターは、すべてのノード、ドライバー、ワーカーがスポット インスタンスで起動します (非プール クラスターのハイブリッド オンデマンド ドライバーおよびスポット インスタンス ワーカーは別)。

使用できないためにスポット インスタンスが削除された場合、オンデマンド インスタンスが削除されたインスタンスに置き換えられることはありません。