コンピューティング パフォーマンスを構成する

コンピューティング リソースを構成するには、パフォーマンス要件とコストに関する考慮事項のバランスを取る必要があります。 過剰プロビジョニングでは不要な費用が発生しますが、プロビジョニング不足によって安定性の問題が発生し、クエリの実行速度が低下する可能性があります。 コンピューティング設定を構成する方法を理解すると、ワークロードのリソースを最適化するのに役立ちます。

コンピューティング リソース コンポーネントについて

コンピューティングのパフォーマンスは、3 つの主要な要因が連携して動作するかどうかによって異なります。 各要因は、ワークロードの実行効率とコストに影響します。

Executor コアの合計数 によって、データの処理に使用できる最大並列処理が決まります。 コア数が多いほど、Spark はより多くのタスクを同時に処理できます。 それぞれ 4 コアを持つ 8 個のワーカーを持つクラスターでは、並列処理用に合計 32 コアが提供されます。

Executor メモリの合計 は、ディスクにスピルする前にメモリ内で処理できるデータの量に影響します。 結合や集計などのメモリを集中的に使用する操作は、より大きなメモリ構成の利点があります。 メモリが不足すると、Spark によってデータがディスクに書き込まれ、パフォーマンスが大幅に低下します。

ローカル ストレージ は、シャッフル操作とキャッシュのための一時的な領域を提供します。 シャッフル操作中、Spark はワーカー ノード上のローカル ディスクに中間データを書き込みます。 高速ローカル ストレージにより、これらの操作に費やす時間が短縮されます。

コンピューティング コンポーネントを理解することで、ノードの種類とクラスター サイズに関する情報に基づいた意思決定を行うことができます。

ノードの種類とクラスター サイズを構成する

ノード タイプの選択は、パフォーマンスとコストの両方に直接影響します。 インスタンス ファミリが異なると、ワークロードの特性が異なります。

メモリ最適化インスタンスは、 メモリ内に留まる必要がある大規模な 結合、 集計、またはデータを含むワークロードに適しています。 これらのインスタンスはコアあたりより多くの RAM を提供するため、ディスクにデータが流出する可能性が低くなります。 たとえば、メモリ内分析に最適な高いメモリ対コア比を提供する E シリーズ VM があります。

コンピューティング最適化インスタンスは、 複雑な 計算 を実行するワークロードに適していますが、大量のメモリは必要ありません。 単純な変換を使用する ETL ジョブは、多くの場合、これらのインスタンスで効率的に実行されます。 たとえば、低いメモリ比で高い CPU パフォーマンスを提供する F シリーズ VM が挙げられます。

ストレージ最適化インスタンスは、 同じデータを繰り返し読み取ったり、 高速なローカル ディスク アクセスを必要とするワークロードに役立ちます。 キャッシュが有効になっているデータ分析ワークロードは、これらのインスタンスでパフォーマンスが向上します。 たとえば、高い I/O ワークロードに対して高速なローカル NVMe ストレージを提供する L シリーズ VM が挙げられます。

GPU アクセラレーションインスタンスは、機械学習、ディープ ラーニング、画像処理などの計算負荷の高いワークロード用に設計されたグラフィックス処理装置を提供します。 これらのインスタンスは、CPU 専用クラスターと比較して 10 ~ 100 倍のモデル トレーニングを高速化できます。 たとえば、NVIDIA GPU を搭載 した NC シリーズ および ND シリーズ の VM が挙げられます。 GPU インスタンスには Databricks Runtime ML が 必要であり、ニューラル ネットワークのトレーニング、大規模な言語モデルの微調整、複雑なモデルでの推論の実行などのタスクに最適です。

ワーカー数とインスタンス サイズのバランスは、ワークロードによってパフォーマンスに異なる影響を与えます。 16 コアと 128 GB の RAM を持つ 2 つのワーカーは、それぞれ 4 コアと 32 GB の RAM を持つ 8 つのワーカーと同じ合計コンピューティングとメモリを提供します。 ただし、少数で大規模なワーカーを使用する構成は、シャッフル操作中のネットワーク トラフィックを減少させますが、多くの小規模なワーカーは、非常に分散されたワークロードに対してより良い並列処理を提供できます。

シャッフル操作が多い分析ワークロードでは、通常、より少ない数の大きなワーカーを使用する方がパフォーマンスが向上します。 並列処理が高い利点を持つ単純なバッチ処理の場合、 より小規模なワーカー の方がコスト効率が高くなる可能性があります。

フレキシブル ノード タイプを使用する

Azure Databricksがコンピューティング リソースを起動すると、クラウド プロバイダーで、指定したインスタンスの種類の容量が不足することがあります。 これにより、 CLOUD_PROVIDER_RESOURCE_STOCKOUT エラーが発生し、警告なしでジョブの実行が遅延または失敗する可能性があります。

フレキシブル ノード タイプは、優先する型 が使用できない場合に、互換性のある代替インスタンスの種類に自動的にフォールバックすることで、これに対処します。 互換性のある代替手段は、プライマリ インスタンスの種類と同じ vCPU 数、メモリ (100 ~ 110%内)、ローカル ディスク構成、CPU アーキテクチャ、OS イメージのサポートを共有し、どの種類が取得されたかにかかわらずワークロードが正しく実行されるようにします。

ワークスペース管理者は、ワークスペースのコンピューティング管理者設定で [自動フレキシブル ノードの種類を有効にする] を切り替えることで、この機能を有効にします。 有効にすると、すべての新しいクラシック コンピューティング リソースでフォールバック インスタンスの種類が自動的に使用されます。 これはスポット インスタンスにとって特に重要です。フレキシブル ノード タイプは、オンデマンドにフォールバックする前に複数の互換性のある種類の間で取得を試みることができ、使用されるスポット インスタンスの割合が増加し、合計コンピューティング コストが削減されます。

厳密なインスタンスの種類の要件を持つワークロードの場合は、クラスター API を使用して空のリストに alternate_node_type_ids を設定することで、個々のコンピューティング リソースの柔軟なノードの種類を無効にすることができます。 自動選択に依存するのではなく、使用する代替型を制御する場合は、API を使用してカスタム フォールバック リストを指定することもできます。

オートスケーリングの構成

自動スケールでは、ワークロードの需要に基づいてワーカーの数が調整され、コストを制御しながらパフォーマンスを維持するのに役立ちます。

自動スケールを有効にする場合は、ワーカーの最小数と最大数を設定します。 Azure Databricks はワークロード要件を監視し、必要に応じ、指定した最大値までワーカーを追加します。 需要が減少すると、労働者は最小限まで減らされます。

Azure Databricks では 、自動スケーリングを 有効にすると、既定で最適化された自動スケーリングが使用されます。 最適化された自動スケールは、最小から最大の 2 ステップで迅速にスケールアップします。 シャッフル ファイルの状態を監視することで、クラスターがアイドル状態でない場合でもスケール ダウンできます。 ジョブ コンピューティングでは、40 秒ごとに使用率が評価されます。 万能コンピューティングでは、150 秒ごとにチェックされます。

実行中にリソースのニーズが変動するワークロードの自動スケーリングを検討してください。 データ探索セッションは、多くの場合、小規模なデータ サンプルから始まり、後で大規模なデータセットを処理します。 自動スケールでは、大規模なデータセットを処理するときにワーカーが追加され、小さいサンプルに戻ったときに削除されます。

一貫したリソース使用量を維持する予測可能なワークロードの場合、固定数のワーカーは、多くの場合、より安定したパフォーマンスとよりシンプルな容量計画を提供します。 スケーリングの決定のオーバーヘッドは、安定した状態のワークロードのパフォーマンスにわずかに影響する可能性があります。

自動スケールは、インスタンス プールで特に適切に機能します。 最小ワーカーをプール内の最小アイドル インスタンスと同じかそれ以下に設定します。 これにより、インスタンスが既にプロビジョニングされ、準備ができているため、迅速なスケーリングが保証されます。

終了設定を構成する

自動終了により、スケジュールされたワークロードの可用性を維持しながら、アイドル状態のコンピューティング リソースで不要なコストが蓄積されるのを防ぐことができます。

自動終了を構成する場合は、非アクティブ期間を分単位で指定します。 クラスターでこの期間を超えるコマンドが実行されていない場合、Azure Databricks によってクラスターが終了されます。 クラスター構成は、必要に応じて再起動できます。

データ分析などの対話型ワークロードの場合は、一般的なセッション パターンに基づいて終了期間を設定します。 45 分のタイムアウトはほとんどのユース ケースに適しています。データ エンジニアは、クラスターを何時間もアイドル状態にすることなく、クエリ間で結果を確認する時間を与えます。

ジョブ コンピューティングの場合、自動終了はジョブの完了後に行われます。 次回のスケジュールされた実行が開始されると、クラスターが自動的に開始されるため、スタートアップを手動で管理する必要はありません。

スポット インスタンスはコストを 削減しますが、可用性のトレードオフが伴います。 他の場所で容量が必要な場合、Azure はスポット インスタンスを再利用できます。 ワーカー ノードの場合、スポット インスタンスは適切に機能します。これは、Azure Databricks/Spark がワーカーエラーを処理できるためです。 ただし、ドライバー ノードには常にオンデマンド インスタンスを使用します。 ドライバーが回収されると、クラスター全体に障害が発生します。

スポット インスタンスを使用する際にタスクの失敗を減らすために、停止を有効にします。 スポットインスタンスがプリエンプション通知を受け取ると、停止プロセスでは、インスタンスが終了する前に、シャッフルされたデータやキャッシュされたデータを健全なワーカーに移行します。 これにより、失われたデータを再計算する必要が減ります。

インスタンス プールを使用する

インスタンス プールは、一連のアイドル状態のインスタンスをすぐに使用できるように維持し、クラスターの起動時間を分から秒に短縮します。

一般的な同時実行クラスターのニーズに合わせて 、アイドル状態の最小インスタンス を構成します。 3 つのノートブックを同時に定期的に実行する場合は、少なくとも 3 つのアイドル 状態のインスタンスを維持します。 これらのインスタンスは、使用されていない場合でも使用でき、インスタント クラスターの起動を提供します。

最大容量を設定してコストを制御し、1 つのワークロードが使用可能なすべてのリソースを消費しないようにします。 複数のチームがワークスペースを共有する場合、最大容量設定のプールによって、公平なリソースの分散が保証されます。 たとえば、100 インスタンスのクォータでは、それぞれ 2 つのチームに対して最大 50 インスタンスのプールを 2 つ作成できます。

アイドル 状態のインスタンスの自動終了設定では、指定した期間以降の最小アイドル数を超えるインスタンスが削除されます。 最小アイドル時間を 3 に設定し、自動終了を 30 分に設定した場合、8 インスタンスまでスケールアップするプールは、非アクティブ状態が 30 分後に 3 インスタンスに戻ります。

プール インスタンスに Databricks Runtime バージョンを事前に読み込むと、クラスターの起動がさらに高速化されます。 クラスターを作成するときに、事前に読み込まれたランタイムを選択すると、ランタイムが既にアイドル 状態のインスタンスにインストールされているため、クラスターはほぼ直ちに起動します。

プールは、クラスターの作成と終了のサイクルが頻繁に発生するワークロードに最適です。 1 日を通してクラスターを作成および破棄する開発チームでは、時間の大幅な節約が見受けられます。 専用の長時間実行クラスターで実行されるプロダクションジョブは、プールからあまり恩恵を受けません。

コストとパフォーマンスのバランスを取る

コストとパフォーマンスのバランスを適切に実現するには、ワークロードの特性を理解し、それに応じて構成を調整する必要があります。

保守的な設定から始めて、パフォーマンスを監視します。 ディスクへのスピルが頻繁に発生する場合や、クエリの実行速度が遅い場合は、メモリまたはコアの数を増やします。 使用率が低いままの場合は、クラスター サイズを小さくするか、自動スケールを有効にします。

ワークロードでサポートされている場合は、サーバーレス コンピューティングを使用します。 サーバーレスは構成の決定を排除し、必要に応じて自動的にスケーリングし、多くの場合、手動で調整することなく最適なコスト パフォーマンスバランスを提供します。

定期的な監視は、最適化の機会を特定するのに役立ちます。 クラスター メトリックを確認して、プロビジョニングされた容量と比較した実際の使用率を確認します。 想定ではなく、観察されたパターンに基づいてノードの種類、ワーカー数、またはスケーリング設定を調整します。