この記事では、拡張自動スケーリングを使用して、Azure Databricks で Lakeflow 宣言パイプラインを最適化する方法について説明します。
拡張自動スケールは、すべての新しいパイプラインに対して既定で有効になっています。 サーバーレス パイプラインでは、垂直方向の自動スケーリングも使用されます。 垂直自動スケールとは何かを参照してください
サーバーレス パイプラインの場合、拡張自動スケールは常にオンになっており、無効にすることはできません。 サーバーレス パイプラインの構成を参照してください。
拡張自動スケーリングとは何ですか
Databricks の拡張自動スケーリングでは、ワークロード ボリュームに基づいてクラスター リソースを自動的に割り当てることでクラスターの使用率が最適化され、パイプラインのデータ処理待機時間への影響は最小限に抑えられます。
次の機能により、Azure Databricks クラスターの自動スケール機能 が強化されました。
- 拡張自動スケーリングでは、ストリーミング ワークロードの最適化が実装され、バッチ ワークロードのパフォーマンスを向上させるための機能強化が追加されます。 自動スケールの強化により、ワークロードの変化に合わせてマシンを追加または削除することで、コストが最適化されます。
- 拡張された自動スケールでは、使用率が不足しているノードが事前にシャットダウンされ、シャットダウン中に失敗したタスクがないことを保証します。 既存のクラスター自動スケール機能は、ノードがアイドル状態の場合にのみノードをスケールダウンします。
拡張自動スケーリングは、Lakeflow 宣言型パイプライン UI で新しいパイプラインを作成するときの既定の自動スケール モードです。 UI でパイプライン設定を編集することで、既存のパイプラインの拡張自動スケールを有効にすることができます。 Lakeflow 宣言型パイプライン API を使用してパイプラインを作成または編集するときに、拡張自動スケーリングを有効にすることもできます。
拡張自動スケールでは、スケールアップまたはスケールダウンの決定を行うためにどのメトリックが使用されますか?
拡張自動スケールでは、次の 2 つのメトリックを使用して、スケールアップまたはスケールダウンを決定します。
- タスク スロットの使用率: これは、クラスターで使用可能なタスク スロットの合計に対するビジー タスク スロットの数の平均比率です。
- タスク キューのサイズ: タスク スロットで実行されるのを待機しているタスクの数です。
Lakeflow 宣言型パイプラインの高度化したオートスケーリングを有効にする
拡張自動スケーリングは、Lakeflow 宣言型パイプライン UI で新しいパイプラインを作成するときの既定の自動スケール モードです。 UI でパイプライン設定を編集することで、既存のパイプラインの拡張自動スケールを有効にすることができます。 Lakeflow 宣言型パイプライン API を使用してパイプラインを作成または編集するときに、拡張自動スケーリングを有効にすることもできます。
拡張自動スケールを使用するには、次のいずれかの操作を行います。
- Lakeflow 宣言型パイプライン UI でパイプラインを作成または編集するときに、[ クラスター モード ] を [拡張自動スケール ] に設定します。
-
autoscale
設定をパイプライン クラスター構成に追加し、mode
フィールドをENHANCED
に設定します。 「Lakeflow 宣言パイプラインのクラシック コンピューティングを構成する」を参照してください。
運用パイプラインの拡張自動スケールを構成する場合は、次のガイドラインを使用します。
-
Min workers
設定は既定値のままにします。 -
Max workers
設定を、予算とパイプラインの優先順位に基づいて値に設定します。
次の例では、少なくとも 5 つのワーカーと最大 10 個のワーカーで拡張自動スケール クラスターを構成します。
max_workers
は、 min_workers
以上である必要があります。
Note
- 拡張自動スケールは、
updates
クラスターでのみ使用できます。 旧式のオートスケーリングは、maintenance
クラスターに使用されています。 -
autoscale
構成には、次の 2 つのモードがあります。-
LEGACY
: クラスターの自動スケーリングを使用します。 -
ENHANCED
: 拡張機能のあるオートスケーリングを使用します。
-
{
"clusters": [
{
"autoscale": {
"min_workers": 5,
"max_workers": 10,
"mode": "ENHANCED"
}
}
]
}
パイプラインが継続的な実行用に構成されている場合は、自動スケール構成の変更後に自動的に再起動されます。 再起動後、待機時間が短くなることが予想されます。 この待機時間の短い期間に続いて、 autoscale
構成に基づいてクラスター サイズを更新し、パイプラインの待機時間を以前の待機時間の特性に戻す必要があります。
拡張自動スケーリングを使用するパイプラインのコストを制限する
Note
サーバーレス パイプラインのワーカーを構成することはできません。
パイプラインの [コンピューティング] ペインで Max workers パラメーターを設定すると、自動スケールの上限が設定されます。 使用可能なワーカーの数を減らすと、一部のワークロードの待機時間が長くなる可能性がありますが、コンピューティング集中型の操作中にコンピューティング リソース のコストが急増するのを防ぐことができます。
Databricks では、特定のニーズに応じたコストと遅延のトレードオフのバランスを取るために、最大ワーカー数の設定を調整することをお勧めします。
拡張された自動スケーリングが有効なクラシックパイプラインを監視する
Lakeflow 宣言型パイプラインのユーザー インターフェイスのイベント ログを使用して、クラシック パイプラインの拡張自動スケール メトリックを監視できます。 拡張自動スケーリング イベントには、autoscale
のイベントタイプがあります。 イベントの例を次に示します。
Event | Message |
---|---|
クラスターのサイズ変更要求が開始されました | Scaling [up or down] to <y> executors from current cluster size of <x> |
クラスターのサイズ変更要求に成功しました | Achieved cluster size <x> for cluster <cluster-id> with status SUCCEEDED |
クラスターのサイズ変更要求が部分的に成功しました | Achieved cluster size <x> for cluster <cluster-id> with status PARTIALLY_SUCCEEDED |
クラスターのサイズ変更要求に失敗しました | Achieved cluster size <x> for cluster <cluster-id> with status FAILED |
また、イベント ログに直接クエリを実行して、拡張自動スケール イベントを表示することもできます。
- イベント ログに対してバックログ メトリックのクエリを実行するには、「 ストリーミング期間を最適化するためのデータ バックログの監視」を参照してください。
- 拡張自動スケーリング操作中にクラスターのサイズ変更要求と応答を監視するには、「 クラシック コンピューティングを最適化するための自動スケール イベントの監視」を参照してください。
垂直方向の自動スケールとは?
サーバーレス パイプラインは、Databricks によって提供される水平自動スケーリングに追加され、メモリ不足エラーのために失敗することなく Lakeflow 宣言パイプラインを実行できる最もコスト効率の高いインスタンスの種類を自動的に割り当てることによって、自動スケーリングが強化されました。 垂直方向の自動スケールは、パイプライン更新を実行するためにより大きなインスタンスの種類が必要な場合にスケールアップします。また、より小さいインスタンスの種類で更新を実行できる場合はスケールダウンします。 垂直方向の自動スケールでは、ドライバー ノード、ワーカー ノード、またはドライバーノードとワーカー ノードの両方をスケールアップまたはスケールダウンするかどうかを決定します。
垂直自動スケーリングは、Databricks SQL マテリアライズド ビューやストリーミング テーブルで使用されるパイプラインを含め、すべてのサーバーレス Lakeflow 宣言パイプラインに使用されます。
垂直方向の自動スケーリングは、メモリ不足エラーが原因で失敗したパイプラインの更新を検出することによって機能します。 垂直方向の自動スケーリングでは、失敗した更新プログラムから収集されたメモリ不足データに基づいてこれらのエラーが検出されると、より大きなインスタンスの種類が割り当てられます。 運用モードでは、新しいコンピューティング リソースを使用する新しい更新が自動的に開始されます。 開発モードでは、新しい更新プログラムを手動で開始するときに、新しいコンピューティング リソースが使用されます。
垂直自動スケーリングによって、割り当てられたインスタンスのメモリが一貫して使用率が低いことが検出されると、次のパイプライン更新で使用するインスタンスの種類がスケールダウンされます。