柔軟なノードタイプを使用してコンピュート起動の信頼性を向上

Databricksのクラシックコンピュートリソースは柔軟なノードタイプを使用するため、指定したインスタンスタイプが使用できない場合、コンピュートリソースは代替の互換性のあるインスタンスタイプにフォールバックできます。

この動作により、コンピュート起動中の容量障害 (在庫切れエラー) が減少し、コンピュート起動の信頼性が向上します。フォールバックを備えたスポットインスタンスの場合、フレキシブルノードタイプは、オンデマンドインスタンスにフォールバックする前に、さまざまなインスタンスタイプ間でインスタンスの取得を複数回試みることができます。これにより、オンデマンドではなくスポットとして実行されるインスタンスの割合が高くなり、総コンピュートコストが削減されます。

柔軟なノードタイプの仕組み

コンピュートリソースを起動すると、クラウドプロバイダーが指定したインスタンスタイプの容量を超えて実行することがあります。これにより在庫切れエラーが発生します。

GCP_INSUFFICIENT_CAPACITY

これらのエラーはスポットインスタンスでよく発生しますが、オンデマンドインスタンスでも発生する可能性があります。

柔軟なノードタイプを有効にすると、Databricks は互換性のあるインスタンスタイプの指定されたフォールバックリストを自動的に生成または使用します。優先インスタンスタイプが利用できない場合、Databricks はすぐに失敗するのではなく、これらのバックアップインスタンスタイプを取得しようとします。

ワークスペースで柔軟なノードタイプを有効にする

ワークスペース管理者は、ワークスペース管理設定で柔軟なノードタイプを有効にすることができます。有効にすると、すべての新しいクラシックコンピュートリソースは自動的に代替ノードタイプにフォールバックします。既存の汎用コンピュートリソースは影響を受けません。「既存のワークロードにはどのような影響がありますか?」を参照してください。

ワークスペースで柔軟なノードタイプを有効にするには:

ワークスペース管理者として、設定ページに移動します。
「 コンピュート 」タブをクリックします。
自動フレキシブルノードタイプを有効にする 設定を切り替えます。
- Enabled : すべての新しいクラシックコンピュートリソースは、明示的に無効にしない限り、フレキシブルノードタイプを自動的に使用します。
- 無効 : コンピュートリソース構成で明示的にnode_type_flexibility構成した場合、クラシックコンピュートリソースはフレキシブルノードタイプのみを使用します。

この設定が無効になっている場合でも、ユーザーはカスタムフォールバックリストを使用してworker_node_type_flexibilityまたはdriver_node_type_flexibilityフィールドを明示的に構成することで、個々のコンピュートリソースに対して柔軟なノードタイプを構成できます。ユーザーがこれらのフィールドを設定できないようにするには、ワークスペース管理者はコンピュートポリシーを使用できます。柔軟なノードタイプポリシーの例を参照してください。

カスタムフォールバックリストを指定する

ワークスペースでフレキシブルノードタイプが有効になっている場合、 Databricks新しいコンピュートリソースに対して互換性のあるインスタンスタイプのフォールバックリストを自動的に生成します。

自動的に生成されたフォールバックリストを使用しない場合は、代わりに独自のフォールバックリストを指定できます。さらに、ワークスペースでフレキシブルノードタイプが無効になっている場合でも、コンピュートリソースのカスタムフォールバックリストを指定できます。互換性があるのは特定のインスタンスの種類のみです。フォールバックインスタンスタイプの要件を参照してください。互換性のあるインスタンスタイプのリファレンスについては、柔軟なノードタイプの互換性リファレンスを参照してください。

カスタムフォールバックリストは、 APIを使用してコンピュートを構成する場合にのみサポートされます。リファレンスAPI ドキュメントを参照してください。

たとえば、次の構成では、必要に応じてコンピュートリソースがどのインスタンスタイプにフォールバックするかを指定します。

JSON

  "worker_node_type_flexibility": {
    "alternate_node_type_ids": [
      "n2-highmem-8"
    ]
  },
  "driver_node_type_flexibility": {
    "alternate_node_type_ids": [
      "n2-highmem-8"
    ]
  },

フォールバックインスタンスタイプの要件

フォールバックインスタンスタイプは、コンピュートの優先インスタンスタイプと互換性がある必要があります。フォールバックインスタンスタイプのリストは、次の要件を満たしている必要があります。

優先インスタンスタイプと同じ vCPU 数とメモリ (フォールバックインスタンスには優先インスタンスタイプのメモリの 100% ～ 110% が必要です)
優先インスタンスタイプと同じ数のローカルディスクとディスクサイズ
優先インスタンスタイプと同じ CPU アーキテクチャ (すべて ARM またはすべて x86)
優先インスタンスタイプと同じ OS イメージと Photon サポート
GPU インスタンスタイプはありません (GPU はサポートされていません)
最大 5 つの固有のフォールバックインスタンスタイプ
すべてのインスタンスタイプは、一貫したストレージサポートを備えている必要があります。つまり、すべてが HYPERDISK_BALANCED ストレージをサポートするか、まったくサポートしないかのいずれかです。ローカル SSD の数は、フォールバックリスト内のすべてのインスタンスタイプに対して有効である必要があります。

プールで柔軟なノードタイプを使用する

プールのフォールバックリストをカスタマイズすることもできます。プール APIで、 node_type_flexibilityフィールドを設定してフォールバックインスタンスタイプを指定します。例えば：

JSON
"node_type_flexibility": {
    "alternate_node_type_ids": ["n2-highmem-8"]
  }

プールは、最小のアイドル数を維持するための柔軟なインスタンスタイプの使用をサポートしていません。プールからのコンピュート起動が試行される場合、プールはフォールバックインスタンスタイプを使用して VM を起動することしかできません。 minIdleカウントの事前ウォーミングでは、優先インスタンスタイプのみが使用されます。

取得したインスタンスタイプを表示する

柔軟なノードタイプを使用する場合、コンピュートリソースはさまざまなインスタンスタイプの組み合わせで構成される場合があります。すべてのフォールバックインスタンスタイプは優先タイプと互換性があり、同じ vCPU 数、メモリ、ディスクレイアウト、CPU アーキテクチャ、OS イメージを維持して、ワークロードが正しく実行されるようにします。

コンピュートリソース用に取得されたインスタンスタイプを表示できます。

[コンピュートの詳細] ページで、 [終了] ボタンの横にある 3 つの点をクリックし、 JSON表示] を選択します。
各エグゼキューターのnode_type_idフィールドを確認して、どのインスタンスタイプが実行されているかを確認します。

Get Cluster info APIを使用して、この情報をプログラムで取得することもできます。さらに、システムテーブルへのアクセス権限を持つユーザーは、 node_timelinesテーブルをクエリできます。ノードタイムラインテーブルスキーマを参照してください。

コンピュートリソースでフレキシブルノードタイプを無効にする

注記

Databricks では、特定のインスタンスの種類に厳しい要件がない限り、柔軟なノードの種類を有効にしておくことをお勧めします。

別のインスタンスタイプにフォールバックするのではなく、コンピュートの起動が失敗することを希望する場合は、個々のコンピュートリソースレベルで柔軟なノードの動作を無効にすることができます。これは、 APIを使用する場合にのみサポートされます。フレキシブルノードタイプを無効にするには、コンピュート構成でフレキシブルノードタイプフィールドを空に設定します。例えば：

JSON
"worker_node_type_flexibility": {
  "alternate_node_type_ids": []
},
"driver_node_type_flexibility": {
  "alternate_node_type_ids": []
}

よくある質問

既存のワークロードにはどのような影響がありますか?

既存の汎用コンピュートリソースは変更されません。自動フォールバックを使用するには、設定を有効にした後に新しい汎用コンピュートリソースを作成するか、カスタムフォールバックリストを使用してコンピュートリソースAPI仕様を更新します。

ジョブコンピュートを使用するジョブの場合、実行ごとに新しいコンピュートリソースが作成されるため、既存のジョブの後続の実行では自動的に柔軟なフォールバックが使用されます。

これはインスタンスプールでも機能しますか?

はい。柔軟なノードタイプはインスタンスプールの構成に適用されます。注意すべき点:

最小アイドル状態の一貫性 : プールの最小アイドルインスタンス ( minIdle ) は、プライマリノードタイプを使用して維持されます。プライマリタイプが制約されている場合、クラスター起動要求を通じて起動された新しい VM は、互換性のあるフォールバックノードタイプを使用して実現できます。
プールの編集 : インスタンスプールは作成後に編集できません。カスタムフォールバック設定を変更する場合は、新しいインスタンスプールを作成する必要があります。
API の可視性 : プールでカスタムフォールバックリストを明示的に構成していない限り、 /api/2.0/instance-pools/get応答にはノードタイプの柔軟性は表示されません。インスタンスプールのフォールバック構成を確認するには、サンプルクラスターを作成し、 /api/2.1/clusters/get応答を表示します。

請求はどのように行われますか?

実際に取得したインスタンスタイプの標準 DBU 料金に基づいて課金されます。クラウドプロバイダーとのインスタンスレベルの割引は、コンピュートリソースで使用される一致するインスタンスタイプに自動的に適用されます。

これはワークスペース内のノードタイプクォータとどのように連携しますか?

プライマリノードタイプが「クォータ超過」制限に達したためにコンピュートの起動が失敗した場合でも、フレキシブルノードタイプは互換性のある代替ノードタイプに自動的にフォールバックすることで、起動の信頼性を向上させることができます。ただし、クォータによる障害の場合、Databricks では、フォールバックを主な修正方法ではなく、安全策として扱うことを推奨しています。クラウドプロバイダーにクォータの増加をリクエストして、代替手段に頼ったり、サーバーレスコンピュートを使用したりする前に、 Databricks優先インスタンスタイプを一貫して取得できるようにすることができます。

ワークロードのサブセットに対してのみ柔軟なノードタイプを有効にすることはできますか?

自動生成されたノードタイプのフォールバックは、ワークスペースレベルでのみ構成できます。ただし、特定のワークロードのフォールバック動作を制御するには、次の 2 つのオプションがあります。

(推奨) ワークスペースに対して柔軟なノードタイプを有効にし、そのクラスターの仕様でalternate_node_type_ids空のリスト[]に設定して、特定のクラスターをオプトアウトします。
ワークスペース全体に対して柔軟なノードタイプを無効にし、互換性要件を満たすカスタムフォールバックリストをalternate_node_type_idsに提供して、特定のクラスター仕様を選択します。

柔軟なノードタイプの仕組み​

ワークスペースで柔軟なノードタイプを有効にする​

カスタムフォールバックリストを指定する​

フォールバックインスタンスタイプの要件​

プールで柔軟なノードタイプを使用する​

取得したインスタンスタイプを表示する​

コンピュート リソースでフレキシブル ノード タイプを無効にする​

よくある質問​

既存のワークロードにはどのような影響がありますか?​

これはインスタンス プールでも機能しますか?​

請求はどのように行われますか?​

これはワークスペース内のノード タイプ クォータとどのように連携しますか?​

ワークロードのサブセットに対してのみ柔軟なノード タイプを有効にすることはできますか?​