フェーズ 1: 移行戦略と計画

この記事は、Azure Synapse Spark から Microsoft Fabric への移行ベストプラクティス シリーズのフェーズ 1/4 です。

ノートブック、Spark ジョブ定義、プール、またはレイク メタデータを移行する前に、ここから始めます。 この記事では、Synapse Spark 資産のスコープを評価し、リスク許容度と配信タイムラインに一致する移行アプローチを選択し、計画に影響するFabricの違いを理解するのに役立ちます。

この手順を完了すると、移行する必要がある内容、使用する移行パターン、主な互換性リスクがある場所、および考慮する必要があるロールバック制約または並列実行制約を把握する必要があります。

この記事では、次の方法について説明します。

• Synapse Spark のフットプリントを評価します。
• リフトアンドシフト、段階的モダン化、並列実行のどちらかを選択します。
• ロールバックと同期の制約を考慮します。
• Synapse Spark と Fabric Spark の主な機能とアーキテクチャの違いを確認します。

Synapse Spark のフットプリントを評価する

Azure Synapse Analyticsには、複数のワークロードの種類が含まれます。 このガイドでは、Spark プール、ノートブック、Spark ジョブ定義、レイク データベース、Hive メタストア メタデータをMicrosoft Fabricに移行することに重点を置いています。 専用 SQL プール、パイプライン、Data Explorer、およびセキュリティ移行のガイダンスについては、コンパニオン ガイドを参照してください。

Fabric評価ツールを実行する

移行を計画する前に、Fabric評価ツールを実行して、Synapse ソース ワークスペースの包括的なレポートを生成します。 このツールはワークスペースをスキャンし、すべてのオブジェクト (Spark プール、ノートブック、Spark ジョブ定義、レイク データベース、リンクされたサービス、およびその構成) の概要を集計して、移行スコープを明確に把握します。

1. ツールをダウンロードします。 Fabric評価ツールは、microsoft/fabric-toolbox のMicrosoft fabric ツールボックス GitHub リポジトリで使用できます。

2. 評価を実行します。 Azure Synapse ワークスペースでツールをポイントします。 Spark 関連のすべてのアイテムをスキャンし、オブジェクト数、構成、依存関係、および潜在的な互換性の問題を含むレポートを生成します。

3. レポートを確認します。 評価の出力を使用して、移行のスコープ (移行する必要があるノートブック、プール、SSD、データベースの数、使用されているリンクされたサービス、潜在的な阻害要因 (GPU プール、サポートされていない機能など) を把握します。

移行パターン

組織の制約、リスク許容度、タイムラインに基づいて移行パターンを選択します。

リフト アンド シフト パターン

最小限の変更でMigration Assistantを使用して、すべての Spark ワークロードを一度に移行します。 Fabric でノートブックとジョブをできるだけ迅速に稼働させることに焦点を当て、破損する要素 (リンクされたサービス、ファイルパス、サポートされていない API) のみをリファクタリングします。 現在のアーキテクチャの as-isを受け入れます。

リフト アンド シフトは、次の場合に使用します。

• Synapse ワークスペースは一定の期限に使用が停止されているため、迅速に移動する必要があります。
• Spark ワークロードは既に適切に設計されています (デルタ優先のクリーン コード、リンクされたサービスの依存関係はほとんどありません)。
• ワークスペースのフットプリントは 1 回の移行で管理でき、チームは 1 回のスプリントでリファクタリング作業を処理できます。
• ダウンストリーム コンシューマー (Power BI API) は、簡単な切り替えウィンドウを許容できます。

段階的な最新化

優先順位に合ったワークロードを段階的に移行し、作業に合った設計を再設計します。 最初に、最も高い値またはリスクの低いワークロードから始めます。 各バッチを移行するときに、Spark プールをより少ない環境に統合し、Lakehouse のベスト プラクティス (Delta-first、V-Order for BI コンシューマー) を採用し、NEE を有効にして、Direct Lake の再設計を行います。

次の場合に段階的モダン化を使用します。

• 複数のチームと多様なワークロードを持つ大規模または複雑な Synapse 環境があり、一度に移行することはできません。
• あなたの現在のアーキテクチャには、対処したい技術的負債があります（非デルタ形式、マウントポイントの依存関係、広がりすぎた Spark プール）。
• タイムラインに柔軟性があり、移行中のパフォーマンスとコスト効率を向上させたいと考えています。
• ワークロードによって所有者が異なり、独立した移行スケジュールが必要です。

並列実行パターン

移行中に両方の環境を同時に実行します。 Synapse でレガシ ワークロードが続行されている間、新しい Spark ワークロードをFabricにルーティングします。 切り替えを行う前に、結果を並べて比較して、移行されたワークロードを検証します。 信頼度が高まるにつれて、Synapse の使用を徐々に停止します。

次の場合に並列実行を使用します。

• ワークロードには、カットオーバーの前に拡張検証を要求する厳格な SLA または規制要件があります。
• 利害関係者が使用停止を承認する前に、Fabricパフォーマンスが Synapse を満たすか、または上回ったことを証明する必要があります。
• ダウンストリーム コンシューマー (ダッシュボード、API、ML モデル) は、移行中の不一致を許容できません。
• 誤った結果がビジネスへの大きな影響を及ぼす可能性のあるプロダクションパイプライン（財務報告、コンプライアンス）を移行しています。

並列実行では、データ同期の問題が発生します。これは、前もって設計する必要があります。 次のいずれかのパターンを選択します。

• 共有ストレージ レイヤー: OneLake ショートカットを使用して、同じ ADLS Gen2 ストレージに対して Synapse とFabricの両方の読み取りと書き込みを行います。 これにより、両方のプラットフォームが同じ Delta ファイルに保持されますが、一度に 1 つのテーブルに対してプラットフォームの書き込みを 1 つだけ行うことで、書き込みの競合を防ぐ必要があります。
• Write-once、read-both: 切り替え時に Synapse をプライマリ ライターとして保持し、Fabric がショートカットを使用して同じデータを読み取るようにします。 Fabricで移行されたノートブックを検証したら、書き込みパスを Fabric に切り替え、使用を停止するまで Synapse を読み取り専用コンシューマーにします。 これは、ほとんどの移行で最も安全なオプションです。
• デュアル書き込み: 比較と調整のツールが既に自動化されている場合を除き、両方の環境で同じ ETL を同時に実行することは避けてください。 デュアル書き込みでは、相違、重複、運用上のオーバーヘッドが発生する傾向があります。

並列実行は、変更管理にも影響します。 Synapse はアクティブな開発環境のままですが、Synapse で行われたノートブック、Spark ジョブ定義、Spark プール構成、またはレイク データベース スキーマの変更は、Fabricに自動的に反映されません。 両方の環境を調整し続けるために、影響を受ける資産を再移行する必要があります。

• Notebook コードの変更: Spark Migration Assistantを再実行するか、更新されたノートブックを手動で再エクスポートして再インポートします。 notebookutils、ファイル パスの更新、Key Vault シークレットなど、Fabric固有のコード リファクタリングを再適用します。
• Spark ジョブ定義の変更: Migration Assistant経由で再移行するか、更新されたSJDをFabricで手動で再作成します。
• Spark プールの構成の変更: 変更されたノード サイズ、自動スケール設定、およびライブラリに合わせて対応する Fabric 環境を更新します。
• Lake データベース スキーマの変更: HMS のエクスポート/インポート ノートブックを再実行するか、影響を受けるテーブルを Fabric lakehouse で手動で作成または変更します。

再移行のオーバーヘッドを減らすために、移行が開始されたら、Synapse 側で変更の凍結を確立します。 変更が避けられない場合は、変更ログを保持して、カットオーバーの前にFabricで再生できるようにします。

ロールバックに関する考慮事項

Synapse から Fabric への移行はコピー操作であり、ソース Synapse ワークスペースは変更または削除されません。 元の Spark プール、ノートブック、データは、プロセス全体を通じてそのまま残ります。 これにより、ロールバックが簡単になります。

• 移行の結果が不十分な場合は、既存の Synapse ワークスペースを引き続き使用してください。 変更を元に戻す必要はありません。
• 移行されたFabric成果物 (ノートブック、環境、Spark ジョブ定義) を削除し、問題に対処した後で再試行します。
• OneLake ショートカットは既存の ADLS Gen2 ストレージを指します。ショートカットを削除しても、基になるデータには影響しません。
• 移行されたすべてのワークロードがFabricで検証され、ダウンストリーム コンシューマーが再ルーティングされるまで、Synapse ワークスペースの使用を停止しないでください。

機能パリティと主な違い

Synapse と Fabric のアーキテクチャの違いを理解することは、計画に不可欠です。 次の表は、コンピューティング アーキテクチャと Spark 機能の主な違いを示しています。

完全な比較については、「Compare Fabric と Azure Synapse Spark: 主な相違点を参照してください。

コンピューティングとアーキテクチャ

Spark: Synapse Spark と Fabric Spark

関連するコンテンツ

• フェーズ 1: 移行戦略と計画
• フェーズ 2: Spark ワークロードの移行
• フェーズ 3: Hive メタストアとデータ移行
• フェーズ 4: セキュリティとガバナンスの移行