柔軟なノードタイプの一般提供が開始されました

特定のコンピュートキャパシティを確保することは、特にトラフィックが多い（そしてプレッシャーが高い）期間には困難な場合があります。データエンジニアやプラットフォーム管理者は、クラウドプロバイダーが特定のインスタンスタイプのリクエストに応じられないためにクラスターの起動が失敗する際に発生する、容量不足、すなわち"stockout"エラーのフラストレーションをよくご存じです。

次のような場合です。

• AWS_INSUFFICIENT_INSTANCE_CAPACITY_FAILURE
• Azure でのCLOUD_PROVIDER_RESOURCE_STOCKOUT、または
• GCP_INSUFFICIENT_CAPACITY、

これらのエラーは、特にアップタイムが最も重要となるビジネスクリティカルな期間において、重要なワークロードを中断させます。

フレキシブルノードタイプとは？

従来、Databricks クラスターでは、すべてのノードが設定で指定されたものとまったく同じインスタンス タイプである必要がありました。その特定のタイプが利用できない場合、クラスターの起動は失敗していました。

柔軟なノードタイプはこの制約を取り除きます。優先インスタンスタイプが利用できない場合、Databricks は同じコンピューティングシェイプを持つ互換性のある代替タイプに自動的にフォールバックします。つまり、クラスターは完全に失敗するのではなく、類似のインスタンスタイプを組み合わせて正常に起動します。

より厳密な制御が必要なチームは、API を通じてカスタム フォールバック リストを定義することもできます。これには、試行するインスタンス タイプとその順序が含まれます。

主なメリット

ピーク時のクラスター起動失敗が減少
柔軟なノードタイプは、容量関連の障害の頻度と深刻度の両方を低減します。クラウドプロバイダーが優先インスタンスタイプを履行できない場合、Databricksは互換性のある代替手段に自動的にフォールバックし、エラーを出さずにクラスターを起動できるようにします。

最適化されたスポットインスタンスの使用
Spot-with-fallback で構成されたクラスターの場合、フレキシブル ノード タイプは、オンデマンド インスタンスに戻る前に、フォールバック リスト全体にわたってスポット キャパシティの取得を試みます。これにより、Spotで実行されるクラスターの割合が増え、起動の成功を優先しながらコンピュートコストを削減できます。

明確な可視性と正確な制御
チームは、node_timelineシステムテーブルを使用して、どのノードタイプが取得されたかを正確に調べることができます。さらに、API を介してカスタム フォールバック順序を定義できるため、コストとパフォーマンスの動作を正確に制御できます。

クイックスタート

ワークスペース管理者は、管理者設定でこの機能を簡単に有効にできます (ドキュメント: AWS、Azure、GCP)。その後、この機能はすべての新しいクラスターの起動にすぐに適用されます。長時間実行クラスターは次回の再起動でこの機能を採用し、既存のジョブ用に作成された将来のジョブクラスターも自動的にこの機能を利用します。

カスタムfallbackリストは、ワークスペースの設定とは別にAPIを介して構成できます。

追加情報
インスタンスプール、請求、ノードタイプのクォータ、および選択的な有効化/無効化によるフレキシブルノードタイプの構成の詳細については、ドキュメントを参照してください (Docs: AWS、 Azure、 GCP)。

フレキシブル ノード タイプは、データ プラットフォームの回復力とコスト効率を向上させるように設計されています。管理者は、ドキュメントの手順に従って、ワークスペースの管理者設定でこの機能を本日ワンクリックで有効にできます。

(このブログ記事はAI翻訳ツールを使用して翻訳されています) 原文記事