プール構成リファレンス

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

注記

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

プールサイズ

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

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

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

最大容量

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

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

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

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

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

インスタンスタイプ

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

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

Databricks は、インスタンスタイプのサポートを終了する前に、常に 1 年間の廃止通知を提供します。

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

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

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

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

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

プールタグ

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

便宜上、Databricks は各プールに 3 つのデフォルトタグ ( Vendor、 DatabricksInstancePoolId、および DatabricksInstancePoolCreatorId. プールの作成時にカスタムタグを追加することもできます。 最大 43 個のカスタムタグを追加できます。

カスタムタグ

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

プール-バッキング クラスターは、プール構成からデフォルト タグとカスタム タグを継承します。 プール タグとクラスタータグの連携の詳細については、「 タグを使用した属性の使用」を参照してください。

AWS の設定

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

可用性ゾーン

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

プールを使用した Auto-AZ

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

プールにアタッチするクラスターは、プールの可用性ゾーンを継承します。 プール内の個々のクラスターの可用性ゾーンを指定することはできません。

スポットインスタンス

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

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

EBS ボリューム

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

• ホストオペレーティングシステムと Databricks 内部サービスによってのみ使用される 30 GB の暗号化されていない EBS インスタンスルートボリューム。
• Sparkワーカーが使用する150 GBの暗号化されたEBSコンテナルートボリューム。これは、Sparkサービスとログをホストします。
• （HIPAAのみ）Databricks内部サービスのログを保存する75 GBの暗号化されたEBSワーカーログボリューム。

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

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

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

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

AWS EBS の制限

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

オートスケール Local Storage

プールの作成時に固定数の EBS ボリュームを割り当てない場合は、 オートスケール ローカル ストレージ. オートスケールのローカルストレージで、 Databricks は無料の量を監視します プールの Spark ワーカーで使用可能なディスク容量。 ワーカーが低すぎる実行を開始した場合 disk、 Databricks は、新しい EBS ボリュームをワーカーに自動的にアタッチしてから、ディスクから実行します 間。 EBS ボリュームは、インスタンスあたり合計ディスク容量が 5 TB に制限されてアタッチされます (インスタンスのローカルストレージを含む)。

ストレージのオートスケールを設定するには、[ ローカルストレージのオートスケールを有効化 ] を選択します。

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

注記

• Databricks は Amazon EBS GP3 ボリュームを使用して、インスタンスのローカルストレージを拡張します。 これらのボリュームの デフォルトの AWS 容量制限 は 50 TiB です。 この制限に達しないようにするには、管理者は使用要件に基づいてこの制限の引き上げをリクエストする必要があります。
• オートスケール ローカル ストレージを使用する場合は、アカウントの作成に使用する IAMロールまたはキーに、ec2:AttachVolume、ec2:CreateVolume、ec2:DeleteVolume、およびec2:DescribeVolumesの権限が含まれている必要があります。 アクセス許可の完全な一覧と、既存の IAMロールまたはキーを更新する方法については、「 ワークスペース デプロイ用の IAMロールを作成する」を参照してください。