プール構成リファレンス

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

プールサイズと自動終了

プールを作成するときに、そのサイズを制御するために、最小アイドルインスタンス、最大容量、アイドルインスタンスの自動終了の 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 では、 Vendor、 DatabricksInstancePoolId、 DatabricksInstancePoolCreatorIdの 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:AttachVolume、 ec2:CreateVolume、 ec2:DeleteVolume、 ec2:DescribeVolumesのアクセス許可が含まれている必要があります。アクセス許可の完全なリストと、既存の IAMロールまたはキーを更新する方法については、「ワークスペースデプロイ用の IAMロールを作成する」を参照してください。