プール構成リファレンス

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

注:

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

プールサイズ

プールを作成するときに、そのサイズを制御するために、最小アイドル インスタンス、最大容量、アイドル インスタンスの自動終了の 3 つのパラメーターを設定できます。

最小アイドル インスタンス数(Minimum Idle Instances)

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

最大容量

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

この構成は オプションです。 Databricks では、次の状況でのみ値を設定することをお勧めします。

  • インスタンスクォータを下回っ たままにする必要がある

  • 1 つの作業セットが別の作業セットに影響を与えないように保護する必要があります。 たとえば、インスタンスクォータが 100 で、ジョブを実行する必要があるチーム A と B があるとします。 最大 50 のプール A と最大 50 のプール B を作成して、2 つのチームが 100 のクォータを公平に分担できます。

  • コストに上限を設ける必要があります。

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

[最小アイドル インスタンス数] で設定された値を超えると、インスタンスがプールによって終了されるまでにアイドル状態になる時間 (分単位)。

インスタンスタイプ

プールは、新しいクラスターの準備ができているアイドル状態のインスタンスと、稼働中のクラスターで使用されているインスタンスの両方で構成されます。 これらのインスタンスはすべて、プールの作成時に選択された同じインスタンス プロバイダー タイプです。

プールのインスタンスタイプは編集できません。 プールにアタッチされたクラスターは、ドライバーノードとワーカーノードに同じインスタンスタイプを使用します。 インスタンスタイプの異なるファミリーは、メモリ集中型ワークロードやコンピュート集中型ワークロードなど、さまざまなユースケースに適合します。

Databricks では、インスタンスの種類のサポートを停止する前に、常に 1 年前に非推奨の通知が提供されます。

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

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

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

プリロードされたDockerイメージ

Dockerイメージは、 インスタンス・プールAPI を使用してプールを作成する場合、プールでサポートされます。

プール タグ

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

便宜上、Databricks では、 VendorDatabricksInstancePoolIdDatabricksInstancePoolCreatorIdの 3 つのデフォルト タグが各プールに適用されます。 プールの作成時にカスタムタグを追加することもできます。 最大 43 個のカスタム タグを追加できます。

カスタムタグ

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

プールベースのクラスターは、プール構成から デフォルト とカスタム タグを継承します。 プール タグとクラスタータグがどのように連携するかの詳細については、 「タグを使用した使用状況の監視」を参照してください。

AWSの構成

プールの AWS インスタンスを設定するときに、アベイラビリティーゾーン (AZ)、スポットインスタンスを使用するかどうか、最大スポット料金、EBS ボリュームのタイプとサイズを選択できます。 プールに接続されているすべてのクラスターは、これらの構成を継承します。

可用性ゾーン

プールに特定の AZ を選択することは、主に、組織が特定のアベイラビリティーゾーンでリザーブドインスタンスを購入している場合に便利です。 AZ の詳細については、「 AWS アベイラビリティーゾーン」を参照してください。

自動 AZ とプール

プールでフリート インスタンス タイプを使用する場合は、可用性ゾーンとして自動を選択できます。 自動 AZ を使用する場合、可用性ゾーンは利用可能なクラウド プロバイダーの容量に基づいて自動的に選択されます。 プールは、ゼロからのスケールアップ イベントの直前に最適な AZ に移動され、プールが空でない間は 1 つの AZ に固定されたままになります。 詳細については、 「AWS フリート インスタンス タイプ」を参照してください。

プールにアタッチしたクラスターは、プールのアベイラビリティーゾーンを継承します。 プール内の個々のクラスターにアベイラビリティーゾーンを指定することはできません。

スポットインスタンス

プールでスポットインスタンスを使用するかどうかを指定できます。 プールは、すべてスポットインスタンスまたはすべてオンデマンドインスタンスのいずれかです。

また、スポットインスタンスの起動時に使用する最大スポット料金を設定することもできます。 これは、対応するオンデマンド価格のパーセンテージとして設定されます。 既定では、Databricks は最大スポット価格をオンデマンド価格の 100% に設定します。 AWSスポット価格を参照してください。

EBS ボリューム

Databricks では、次のようにすべてのインスタンスに EBS ボリュームがプロビジョニングされます。

  • 30 GB の暗号化されていない EBS インスタンスのルートボリュームは、ホスト オペレーティング システムと Databricks 内部サービスによってのみ使用されます。

  • Spark ワーカーによって使用される 150 GB の暗号化された EBS コンテナーのルートボリューム。 このホストされた Spark サービスとログ。

  • (HIPAA のみ) Databricks 内部サービスのログを格納する 75 GB の暗号化された EBS ワーカー ログ ボリューム。

EBS シャッフルボリュームの追加

シャッフルボリュームを追加するには、[EBS Volume Type] ドロップダウンリストで [汎用SSDボリューム] を選択します。

デフォルトでは、Sparkシャッフル出力はインスタンスのローカル・ディスクに送られます。 ローカルディスクを持たないインスタンスタイプの場合、または Spark シャッフルのストレージ容量を増やす場合は、追加の EBS ボリュームを指定できます。 これは、大きなシャッフル出力を生成する Spark ジョブを実行するときに、ディスク領域不足エラーを防ぐのに特に役立ちます。

Databricks は、オンデマンドインスタンスとスポットインスタンスの両方でこれらの EBS ボリュームを暗号化します。 詳細については、AWS EBS ボリュームを参照してください。

AWS EBSの制限

AWS EBS の制限が、すべてのプール内のすべてのインスタンスのランタイム要件を満たすのに十分な高さであることを確認します。 デフォルトの EBS 制限とその変更方法については、「 Amazon Elastic Block Store (EBS) の制限」を参照してください。

オートスケール local storage

プール作成時に固定数の EBS ボリュームを割り当てない場合は、オートスケールローカルストレージを使用します。 オートスケール ローカル ストレージを使用すると、Databricks はプールの Spark ワーカーで使用可能な空きディスク領域の量を監視します。 ワーカーの実行がディスクの少なすぎる状態になると、Databricks は、ディスク領域が不足する前に、新しい EBS ボリュームをワーカーに自動的にアタッチします。 EBS ボリュームは、インスタンスあたり (インスタンスのローカルストレージを含む) の合計ディスク容量が 5 TB まで制限されてアタッチされます。

オートスケールストレージを設定するには、[ Enable autoscale local storage] (オートスケールローカルストレージを有効にする) を選択します。

インスタンスにアタッチされた EBS ボリュームは、インスタンスが AWS に返されたときにのみデタッチされます。 つまり、EBS ボリュームは、プール内にある限りインスタンスから切り離されることはありません。 EBS の使用量を削減するには、Databricks ではプール サイズを構成することをお勧めします。

注:

  • Databricks では、スループット最適化 HDD (st1) を使用して、インスタンスのローカル ストレージを拡張します。 これらのボリュームの デフォルトの AWS 容量制限 は 20 TiB です。 この制限に達しないようにするには、管理者は使用要件に基づいてこの制限の引き上げを要求する必要があります。

  • オートスケールのローカル ストレージを使用する場合は、アカウントの作成に使用する IAM ロールまたはキーに、権限ec2:AttachVolumeec2:CreateVolumeec2:DeleteVolume 、およびec2:DescribeVolumesを含める必要があります。 既存の IAM ロールまたはキーを更新する権限の完全なリストと手順については、 「ワークスペース デプロイメント用の IAM ロールを作成する」を参照してください。