Fabric Spark の容量とクラスターの計画

この記事では、開発、移行、運用のシナリオを対象に、Microsoft Fabric で Spark ワークロードの容量とコンピューティングを計画するための実用的なガイダンスを提供します。

サイズ変更のガイドライン

このセクションでは、FabricにおけるSparkワークロードのサイズ設定や設定に関する実践的なガイダンスを提供します。 新規開発、Azure Synapseからの移行、本番環境での容量調整などのシナリオをカバーしています。

シナリオ: Fabric は初めてであり、容量計画に関するガイダンスが必要です。

試用容量から始める: Fabric を初めて使用する場合は、試用容量から開始します。 F4 容量 (4 容量ユニット) または F64 容量 (64 容量ユニット) のどちらかの処理能力を 60 日間提供します。 このセットアップは、Spark ワークロードの開発とテストに最適です。 必要な容量を見積もるには、「容量サイズの計画」と「Fabric SKU Estimator (preview)」をご覧ください。

スターター プールとカスタム プールの選択: 

スターター プール: 通常は、Spark ワークロードにスターター プールを使用します。 Fabricはこれらのプールを事前プロビジョニングし、迅速なセッション開始時間を保証します。 カスタム ライブラリ、マネージド プライベート エンドポイント (MPE)、または Private Link (PL) を必要としない開発環境に最適です。 スターター プールを使用すると、開発者の生産性を大幅に向上させることができます。

カスタム プール: マネージド プライベート エンドポイント (MPE) または Private Link (PL) を有効にする場合は、カスタム プールを使用します。 

スターター プールとカスタム プールの詳細については、 データ エンジニアリングおよびデータ サイエンス用の Apache Spark コンピューティングに関するドキュメントを参照してください。  

Spark Notebook のプロファイリング: 

• Fabric で Spark アプリケーションを監視するには、次を使用できます。

  • Spark History Server: 単一のアプリケーションの詳細をドリルダウンし、より詳細なステージ レベル、タスク レベル、スキュー、論理プラン、物理プランをドリルダウンします。

  • リソース使用状況 UI: 各ステージの後にスケールアップまたはスケールダウンされた Executor の使用率と Executor の数を分析します。

  • 監視ユーザーインターフェース: 高度なノートブック、Spark ジョブ定義 (SJD)、およびパイプラインの実行に関する詳細情報（実行時間、状態、送信者など）の30日間のメトリック。監視ユーザーインターフェースは、アプリケーション間の可視性を高めるために役立ちます。

  • 診断エミッタ拡張機能: Azure ログ分析、Azure Storage、Azure イベント ハブなどのターゲットにログを出力します。 これは、長期的な傾向分析に最適です。

• 一般に、 スターター プール (中程度の Spark プール (8 仮想コアと 64 GB メモリ)) を使用してアプリケーションのプロファイリングを開始します。 少なくとも 1 つのノードから始めて、実行時間を確認します。 

• リソースの使用状況を確認するには、Spark リソース使用状況 UI に移動します。 リソース使用量 UI で、割り当てられたインスタンスがタスクの数が最も多いステージ内の最大インスタンスより少ない場合は、割り当てられたインスタンスに合わせて Spark 自動スケールの最大ノード数を減らします。  

  

• 最大インスタンスと割り当てられたインスタンスが重複する場合は、並列処理を強化し、パフォーマンスを向上させるために、最大ノード構成を増やすことを検討してください。 

  

データ スキューの処理:

• データスキューを検出した場合、リソースを追加するだけでは役に立たない可能性があります。 不均等なデータ分散によってスキューが発生した場合のパーティション分割などの手法を使用して、スキューに対処します。
• スキューの特定と対処に関するガイダンスについては、 このシリーズの開発と監視 に関する記事を参照してください。 

使用率の評価: 容量メトリック アプリを使用して使用率を評価し、ワークロードに最適な容量サイズを見積もります。 詳細については、 Apache Spark の容量消費の監視 に関するドキュメントを参照してください。 試用容量の使用率を分析した後、PoC に適した従量課金制容量を選択し、予約 (RI) または自動スケール課金によってサポートされる容量に移行します。 RI は 1 年間のコミットメントです。 従量課金制の容量はいつでも取り消すことができます。 RI では、従量課金制容量と比較して約 40% 割引が提供されます。

シナリオ: 従量課金制の容量で Spark ワークロードを実行する。 選択する最適な容量モデルは何ですか?

従量課金制の容量で Spark ワークロードを実行している場合は、自動スケールへの移行を検討してください。 自動スケールは、従量課金制と同様の契約の柔軟性を提供しながら、制限のリスクを回避するという利点があります。 ただし、リソースが不足している場合、ジョブはより低コストでキューに登録されます。

また、安定したワークロード用の予約を使用し、より多くの可変ワークロードに対して自動スケーリングを使用するハイブリッド モデルを検討することもできます。 予約は、容量が十分に利用されている限り (契約期間の平均で 75% を超える) 限り、最適なコスト パフォーマンスを提供します。

一般に、前に説明したオプションよりも従量課金制を好む理由はあまりありません。

• 既に、Pay-as-you-go方式で稼働している、従量課金制の容量があります。これには、Spark以外のワークロードを実行するための余裕がありますので、この容量で追加のSparkジョブを実行することが可能です。容量にジョブを追加する際の限界コストは0ですが、あまりにも多くのジョブを追加すると、負荷がかかり、調整が必要になる場合があります。 ここでも、可能であればコストを削減して1年間予約することを検討する必要があります。

• 短期間の PoC または開発プロジェクトがあり、コストの予測可能性はコスト効率よりも重要であり、容量は毎月一定の金額を支払います。 容量を使い過ぎた場合、追加料金は発生せず、その代わりに制限されます。 自動スケーリングでは、使用した内容に対して課金されるため、開発環境で不適切なコードが実行された場合にコストオーバーランが発生する可能性があります。 予算が厳しく管理されている開発プロジェクトの場合、これは価値のあるトレードオフになる可能性があります。

リソースの使用状況をさらに最適化するには:

• 1 つの 高コンカレンシー の Spark セッションで複数の Spark Notebook を実行して、リソースの使用を最適化できます。

• ネイティブ実行エンジン (NEE) を有効にして、パフォーマンスを大幅に向上させます。

シナリオ:ワークロードをAzure SynapseからFabricに移行する場合。

Azure SynapseからFabricへのワークロード移行を行っている場合、何が変更され、何が変わらず、既存のSynapseサイズを再利用できるのか疑問に思うかもしれません。 

移行と最適化: 

• ワークロードを移動するには、Azure Synapse to Fabric 마이그레이션ユーティリティを使いましょう。 

• Spark のオートスケール課金を有効化します。 環境とレイクハウスが同じなら、ノートブックやパイプラインを高並行モードで動かしましょう(Synapseにはない機能です)。パフォーマンスを上げるために。 

• ノートブックをネイティブ実行エンジン(NEE)でプロファイリングし、ワークロードに最適化しましょう。 

一般的なコンピューティング構成ガイドライン: 

関連コンテンツ

• Fabric Spark のベスト プラクティスの概要
• Fabric Spark のセキュリティ
• 開発と監視