Microsoft FabricでSparkジョブを運用している場合、「More resilient Spark jobs with Efficient Scaledown」は、シャッフルが多いジョブのコスト・失敗率・実行時間のばらつきに関わる重要な更新です。結論から言うと、既存のNotebookやパイプラインを書き換える変更ではありませんが、Native Execution Engineの有効化、Spark Runtime、Autoscale、キャッシュ利用、Private Link環境は早めに確認する必要があります。公式ソース上の分類はNoticeで、破壊的変更というより「プレビュー機能として利用条件と効果を確認すべき更新」と捉えるのが実務的です。
More resilient Spark jobs with Efficient Scaledown は何が変わった？影響範囲と確認ポイント
「More resilient Spark jobs with Efficient Scaledown」は、Microsoft Fabric Sparkで大規模なデータエンジニアリング処理を行う際に、SparkのシャッフルデータをExecutorのローカルディスクに強く依存させないようにする仕組みです。Microsoft Fabric Blogでは、この機能により、クエリ、Notebook、パイプラインを変更せずに、クラスターのスケールダウン、耐障害性、コンピュートコストの改善を狙えると説明されています。([Microsoft Fabric Community][1])
Sparkでは、集計、JOIN、並べ替え、ウィンドウ関数などでデータの再分配が発生します。これがシャッフルです。従来はシャッフルデータがExecutorのローカルディスクに残るため、そのデータを下流処理が読み終えるまでExecutorを解放しづらく、Autoscaleが効きにくい原因になります。Executorが失われるとFetchFailedExceptionやステージ再実行につながることもあります。([Microsoft Fabric Community][1])
Efficient Scaledownは、この問題に対して、シャッフルデータをAzure Blob Storageへ書き出したり、Executor終了前に移行したりすることで、Executorの寿命とシャッフルデータの寿命を切り離します。これにより、アイドル状態のExecutorをより早く解放し、ジョブの再実行や無駄なコンピュート消費を減らす狙いがあります。(Microsoft Learn)
変更点の要点
| 確認項目 | 内容 | 実務上の意味 |
|---|---|---|
| 対象機能 | Efficient Scaledown Preview | 本番適用前に検証環境で確認する |
| 主な対象 | Microsoft Fabric Sparkのデータエンジニアリング、データサイエンス workloads | Lakehouse、Notebook、Spark Job Definition利用者は確認対象 |
| 変更の中心 | シャッフルデータをExecutorローカルから切り離す | Autoscale時の無駄なExecutor保持を減らせる可能性 |
| コード変更 | クエリ、Notebook、パイプラインの変更は不要とされる | 設定確認が主作業になる |
| 前提条件 | Native Execution Engine、Apache Spark 3.5相当以降など | Runtimeや環境設定の確認が必要 |
| 注意点 | Private Link非対応、HNS有効ストレージ非対応などの制限あり | ネットワーク・ストレージ構成によって使えない場合がある |
Efficient Scaledownは、単一の設定だけで成立する機能ではありません。Remote Shuffle Manager、Shuffle Migration、Decision Layer、AQE Shuffle Writeといった複数の仕組みを組み合わせて、シャッフルデータの配置とスケールダウンを制御します。Microsoft Learnでは、Remote Shuffle ManagerがAzure Blob Storageへシャッフルデータを読み書きし、Decision Layerが小さなシャッフルはローカル、大きなシャッフルはリモートへ振り分けると説明されています。(Microsoft Learn)
影響を受けやすい利用者
特に確認すべきなのは、Fabric Sparkで次のような処理を運用しているチームです。
- 大量データのJOIN、GROUP BY、ORDER BYを含むETLジョブがある
- Sparkジョブの実行時間が日によって大きくぶれる
- FetchFailedExceptionやステージ再実行が発生することがある
- Autoscaleを有効にしているのに、期待ほどコストが下がらない
- NotebookやSpark Job Definitionを定期実行している
- Executorのアイドル時間やVM分の消費が気になっている
一方で、小規模なNotebook実行、短時間の検証、シャッフルがほとんど発生しない単純な読み書き処理では、効果が見えにくい可能性があります。特に、コスト削減だけを期待して全ジョブに一律適用するのではなく、シャッフル量が多いジョブから検証するのが現実的です。
すぐ確認したい設定
Efficient Scaledownを使うには、Native Execution Engineが必要です。Microsoft Learnでは、Native Execution EngineはFabric Data Engineering向けの実行エンジンで、Runtime 1.3、つまりApache Spark 3.5相当、およびRuntime 2.0に対応すると説明されています。(Microsoft Learn)
Notebookで試す場合は、次のようなSpark設定を確認します。すでに環境、ワークスペース、Spark Job Definition側で設定している場合は、Notebook内で重複設定しないようにしてください。
# Remote Shuffle Manager
spark.conf.set("spark.remote.shuffle.enabled", "true")
# Decision Layer：ステージ単位でローカル／リモートのシャッフルを判断
spark.conf.set("spark.sql.rsm.decisionlayer.enabled.level", "stage")
# AQE Shuffle Write
spark.conf.set("spark.sql.adaptive.shuffleWrite.enabled", "true")
# Executor終了時のシャッフルブロック移行
spark.conf.set("spark.storage.decommission.shuffleBlocks.enabled", "true")
spark.conf.set("spark.storage.decommission.shuffleBlocks.migrateToFallbackStorage", "true")
# Delta snapshot cacheがスケールダウンを妨げないようにする
spark.conf.set("spark.dynamicAllocation.excludeDeltaSnapshotCache", "true")Microsoft Learnの推奨構成では、シャッフルブロックやFallback Storageのクリーンアップに関する設定も示されています。ストレージコストを抑える観点では、移行だけでなく削除・クリーンアップの設定も合わせて確認した方が安全です。(Microsoft Learn)
管理者が確認すべきチェックリスト
| 確認ポイント | 見るべき場所 | 判断の目安 |
|---|---|---|
| Native Execution Engineが有効か | Fabric環境のAcceleration設定、またはSpark設定 | 無効ならEfficient Scaledownの前提を満たさない |
| Runtimeが対応しているか | Environment、Notebook、Spark Job Definition | Apache Spark 3.5相当以降か確認 |
| Autoscaleを使っているか | Spark compute設定 | 有効ならスケールダウン効果を確認しやすい |
| Private Link環境か | ネットワーク構成 | 現時点の制限に該当する可能性がある |
| シャッフルが多いジョブか | Spark UI、実行履歴、失敗ログ | JOIN、集計、ソートが多いジョブを優先検証 |
| cache()やpersist()を多用しているか | Notebook、ジョブコード | Executor解放でキャッシュ前提の性能が変わる可能性 |
| コスト評価の基準があるか | Capacity Metrics、ジョブ履歴 | 適用前後でVM分、実行時間、失敗回数を比較する |
特に注意したいのはキャッシュです。Microsoft Learnでは、Efficient Scaledownの制限として、preventShutdownExecutorWithCache=falseにより、キャッシュを保持しているExecutorがスケールダウンされる可能性があると説明されています。cache()やpersist()を性能改善の前提にしているNotebookでは、ジョブが失敗しなくても実行時間の傾向が変わる可能性があります。(Microsoft Learn)
運用で失敗しやすいポイント
コスト削減率をそのまま自社環境に当てはめない
Microsoft Fabric Blogでは、TPC-DSベンチマークでコンピュート削減が示されていますが、実際の効果はデータ量、シャッフル量、Autoscale設定、ジョブ間隔、Runtime、キャッシュ利用によって変わります。ベンチマーク値をそのまま社内説明に使うのではなく、自社の代表的なSparkジョブで適用前後を比較することが重要です。([Microsoft Fabric Community][1])
Preview機能を本番に一気に広げない
今回の更新はPreviewです。すぐに全ワークスペースへ展開するより、失敗時の影響が限定できるジョブから試すべきです。まずは、日次バッチや再実行可能なETLなど、検証しやすい処理を選びます。比較する指標は、実行時間だけでなく、リトライ回数、FetchFailedExceptionの発生状況、VM分、ストレージI/O、ジョブ成功率まで含めると判断しやすくなります。
Private Linkやストレージ制限を見落とさない
Microsoft Learnでは、Efficient Scaledownの制限として、Native Execution Engineが必要であること、Remote Shuffle StoreとしてAzure Blob Storageを使うこと、HNS有効のAzure Data Lake Gen2やAzure Private Link環境は現在サポート対象外であることが示されています。ネットワーク分離を強めている環境ほど、先に制限事項を確認してください。(Microsoft Learn)
まず行うべき実務対応
Microsoft Fabric利用者は、次の順で確認すると無駄がありません。
| 優先度 | 対応 | 目的 |
|---|---|---|
| 高 | シャッフルが多く失敗しやすいSparkジョブを洗い出す | 効果が出やすい対象を選ぶ |
| 高 | Native Execution EngineとRuntimeを確認する | 前提条件を満たすか判断する |
| 高 | Private Link、HNS有効ストレージ、キャッシュ利用を確認する | 制限や副作用を避ける |
| 中 | 検証用NotebookまたはSpark Job Definitionで設定を試す | 本番前に動作と性能を確認する |
| 中 | 適用前後のVM分、実行時間、失敗回数を比較する | コスト削減と安定性を数値で判断する |
| 低 | 効果が確認できたジョブから標準設定化する | チーム内の運用ルールに落とし込む |
今回の「More resilient Spark jobs with Efficient Scaledown」は、Sparkコードの書き換えよりも、Fabric Spark環境の運用設計に関わる更新です。特に、シャッフルの多い大規模ETLや定期バッチでは、Autoscaleの効き方、ジョブ失敗時の再実行、コンピュートコストに影響する可能性があります。まずは対象ジョブを絞り、Native Execution Engine、Runtime、ネットワーク制限、キャッシュ利用を確認したうえで、検証環境で適用前後の差を測定してください。
[1]: https://community.fabric.microsoft.com/t5/Fabric-Updates-Blog/More-resilient-Spark-jobs-with-Efficient-Scaledown-Preview/ba-p/5212071 “
More resilient Spark jobs with Efficient Scaledown… – Microsoft Fabric Community
“
コメント