Azure SynapseからSnowflakeへの移行ガイド¶

フェーズ1：計画と設計¶

この初期段階は、移行を成功させる基盤を確立するために非常に重要です。Azure Synapseからの移行には、統合されたコンポーネントを明確に理解し、利害関係者の調整、スコープの定義、予算超過を防ぐための綿密な計画が必要です。

行動可能なステップ：

• Synapse環境の徹底的なアセスメントを実施する：

  • インベントリと分析： 専用の SQL プールテーブル、サーバーレス SQL プールビュー、スキーマ、T-SQL ストアドプロシージャ、関数、ビューなど、Synapseワークスペース内のすべてのオブジェクトをカタログ化します。Synapseのシステムビュー（sys.tables、sys.proceduresなど）を使用してメタデータを収集します。

  • ワークロードの分析： Azure MonitorとSynapseの動的管理ビュー（ DMVs ）を使用して、クエリパターン、ユーザーの同時実行性、リソース使用率（ DWUs ）、パフォーマンスのボトルネックを特定します。このデータは、Snowflakeウェアハウス戦略を設計する上で極めて重要です。

  • 依存関係の特定： すべてのアップストリームデータソース、特にAzure Data Factory（ ADF ）パイプラインと、Power BI レポート、Azure機械学習モデル、その他のアプリケーションなどのダウンストリームコンシューマーをマップします。

• マイグレーションの範囲と戦略を定義する：

  • **ワークロードの優先順位付け：**ビジネスへの影響と技術的な複雑さによってワークロードを分類します。インパクトが大きく、複雑度の低いワークロード（特定のデータマートなど）から始めて、価値を示し、軌道に乗せます。

  • 移行アプローチの選択： より迅速な移行を目指す「リフト&シフト」か、データモデルとパイプラインを最新化するリアーキテクチャアプローチかを決定します。

• プロジェクト計画を策定する：

  • チームの確立： 明確な役割（プロジェクトマネージャー、データエンジニア、Synapse/SQL 、Snowflakeアーキテクト、セキュリティ管理者、ビジネスアナリスト）を持つ移行チームを作ります。

  • タイムラインの作成： 9つの各フェーズについて、現実的なタイムラインとマイルストーンを定義します。

  • 成功メトリックの定義： コスト削減、クエリパフォーマンスの改善、ユーザー満足度など、成功を測るための明確な KPIs を確立します。

フェーズ2：環境とセキュリティ¶

しっかりとした計画を立てた上で、次のステップはSnowflake環境を準備し、Azureのセキュリティモデルを変換することです。データ転送とネットワーク統合を簡素化するために、Azure上でSnowflakeをホストすることを強くお勧めします。

行動可能なステップ：

• Snowflakeアカウントをセットアップする：

  • エディションとクラウドプロバイダーの選択： ニーズを満たすSnowflakeエディション（例：Standard、Enterprise、Business Critical）を選択します。クラウドプロバイダーとしてAzureを選択し、データ転送コストと遅延を最小限に抑えるために、Azureデータレイクストレージ（ ADLS Gen2）と同じリージョンを選択します。

  • **ウェアハウス戦略の設計：**フェーズ1のワークロード分析に基づき、ウェアハウスの初期セットを作成します。リソースの競合を防ぐために、異なるワークロード（WH_LOADING、WH_TRANSFORM、WH_BI_ANALYTICS）を分離します。Tシャツのサイズ（X-Small、Smallなど）から始め、パフォーマンステストに基づいてサイズ変更を計画します。

• セキュリティモデルを導入する：

  • **Azure AD プリンシパルをSnowflakeロールにマップします：**Azure Active Directory（ AAD ）のユーザーとグループをSnowflakeの階層型ロールベースのアクセス制御（ RBAC ）モデルに変換します。機能ロール（SYSADMIN、SECURITYADMIN）とアクセスロール（BI_READ_ONLY、ETL_READ_WRITE）の階層を作成します。

  • ネットワークポリシーと認証の構成： 安全な接続のために、Azure Private Link 経由の信頼された IP アドレスへのアクセスを制限するネットワークポリシーを設定します。Azure AD で Snowflakeをエンタープライズアプリケーションとして設定して、 SSO を構成します。

フェーズ3：データベースコード変換¶

このフェーズでは、SynapseのT- SQL ベースの DDL 、 DML 、手続き型コードをSnowflakeと互換性のあるものに変換します。自動化ツールはこのプロセスを加速させますが、手作業によるレビューは不可欠です。

行動可能なステップ：

• DDL（データ定義言語）を変換する：

  • テーブルとビュー： Synapseから CREATE TABLE、CREATE VIEW ステートメントを抽出します。Synapse固有のデータ型をSnowflakeに相当するデータ型に変換します（付録2を参照）。

  • Synapse特有の句の削除： DISTRIBUTION のようなシナプス特有の物理的分配句（例： ROUND _ROBIN 、 HASH ）や、 CLUSTERED COLUMNSTORE INDEX のようなインデックス戦略を削除します。Snowflakeはデータの配布と保存を自動的に管理します。

  • 制約の再実装： Snowflakeは NOT NULL 制約のみを強制します。PRIMARY KEY およびUNIQUE 制約は情報提供です。他のすべてのデータ整合性ロジックは、 ETL/ELT プロセスに移動する必要があります。。

• DML （データ操作言語）と手続きコードの変換：

  • T-SQL ストアドプロシージャの書き換え： Synapse のT-SQL ストアドプロシージャはSnowflakeスクリプト（ SQL ）、 JavaScript 、Pythonなど、Snowflakeでサポートされている言語に書き換える必要があります。

  • SQL 関数の変換： Synapse/T-SQL 固有の関数を、対応するSnowflake関数にマップします（例： GETDATE() は CURRENT_TIMESTAMP()、 ISNULL() は IFNULL() になります)。一般的なマッピングについては付録3を参照してください。

フェーズ4：データ移行¶

このフェーズでは、Synapse SQL データベースからSnowflakeテーブルへの履歴データの物理的な移動に焦点を当てます。最も効率的な方法は、中間ステージング領域として Azureデータレイクストレージ（ ADLS Gen2）を活用することです。

行動可能なステップ：

• Synapse から ADLS Gen2にデータをアンロードします：

  • Synapseで CREATE EXTERNAL TABLE AS SELECT （ CETAS ）コマンドを使用して、テーブルから ADLS Gen2アカウント内の指定されたコンテナにデータをエクスポートします。

  • Snowflakeへの読み込みパフォーマンスを最適化するために、データをParquetまたは圧縮された CSV としてフォーマットします。

• ** ADLS Gen2からSnowflakeにデータをロードします。

  • 外部ステージの作成： Snowflakeで、 ADLS Gen2に安全に接続するためのストレージ統合オブジェクトを作成し、アンロードされたデータを含むコンテナーを指す外部ステージを作成します。

  • COPY INTO コマンドの使用： Snowflake のCOPY INTO <table> コマンドを使用して、 ADLS ステージから対象のSnowflakeテーブルにデータをロードします。

  • サイズアップしたウェアハウスの活用： 最初のデータロードには専用の大規模な仮想ウェアハウスを使用してプロセスを高速化し、その後はスケールダウンまたは一時停止します。

フェーズ5：データの取り込み¶

履歴データの移行が完了したら、進行中のデータ取り込みパイプライン（最も一般的にはAzure Data Factory）を再設計して、Snowflakeにデータをフィードする必要があります。

行動可能なステップ：

• Azure Data Factory（ ADF ）パイプライン：

  • ADF パイプラインで、SynapseデータセットとアクティビティをSnowflakeの同等のものに置き換えます。ソースアクティビティとシンクアクティビティの両方に、 ADF でSnowflakeのネイティブコネクタを使用します。

  • すべてのLookupアクティビティやScriptアクティビティを、Snowflakeの SQL 方言を使用するように更新します。

• Snowpipe を使用した継続的取り込みの実施：

  • ADLS Gen2に到達する継続的なデータストリームの場合は、Snowpipeを構成します。Snowpipeは、新しいデータファイルが到着すると自動的かつ効率的にSnowflakeテーブルにロードし、ほぼリアルタイムの取り込みソリューションを提供します。これはAzure Event Grid通知によってトリガーされます。

• Snowflakeエコシステムを活用する：

  • KafkaやSparkなどのプラットフォーム向けのSnowflakeのネイティブコネクタを検討して、直接データストリーミングを簡素化します。

フェーズ6：レポートと分析¶

このフェーズでは、すべてのダウンストリームアプリケーション、特にPower BI を、Snowflakeのデータをクエリするようにリダイレクトします。

行動可能なステップ：

• 接続ドライバーの更新： Power BI Desktopとオンプレミス データゲートウェイに最新のSnowflakeドライバーがインストールされていることを確認します。

• Power BI レポートのリダイレクト：

  • Power BI で各レポートのデータソースを編集し、接続先をAzure SynapseからSnowflakeに切り替えます。SnowflakeのネイティブPowerBI コネクタは認定済みで、強く推奨されます。

  • すべての重要なレポートとダッシュボードをテストします。DirectQuery を使用するレポートでは、パフォーマンス特性が変化するため、細心の注意を払ってください。

• クエリを精査および最適化する：

  • 一部のレポートにはネイティブの T-SQL クエリが含まれる場合があります。これらはSnowflakeの SQL 方言を使うようにリファクタリングする必要があります。Snowflake のクエリプロファイルツールとPower BI のパフォーマンスアナライザーを使用して、実行速度が遅いレポートを最適化します。

フェーズ7：データ検証とテスト¶

新しいプラットフォームに対するビジネスの信頼を築き、データの完全性とパフォーマンスが期待に応えることを確認するためには、厳格なテストが不可欠です。

行動可能なステップ：

• データ検証を実行する：

  • **行カウント：**SynapseのソーステーブルとSnowflakeのターゲットテーブル間の行数を比較します。

  • セルレベル検証： 重要なテーブルについては、集約された値（SUM、AVG、MIN、MAX）を比較することで、より深い検証を行います。

• クエリとパフォーマンステストを実施する：

  • **ベンチマーククエリ：**SynapseとSnowflakeの両方に対して代表的なクエリセットを実行し、結果とパフォーマンスを比較します。

  • BIツールのパフォーマンス： Snowflakeに接続された主要なPowerダッシュボードのロード時間と対話性をテストします。

• ユーザー受け入れテスト（UAT）：

  • ビジネスユーザーに参加してもらい、新しいSnowflake環境を使用してレポートを検証し、日々のタスクを実行してもらいます。

フェーズ8：デプロイ¶

デプロイは、Azure SynapseからSnowflakeへの最終的なカットオーバーです。このプロセスは、業務への支障を最小限に抑えるため、慎重に管理する必要があります。

行動可能なステップ：

• カットオーバー計画を策定する：

  • カットオーバーの一連の流れを定義します。これには、Synapseを指す ADF パイプラインの一時停止、最終的なデータ同期の実行、すべての接続のリダイレクト、システムの健全性の検証が含まれます。

• 最終データ同期を実行する：

  • 最後のインクリメンタルデータロードを実行し、テスト段階で発生したデータ変更を把握します。

• 実稼働環境への移行：

  • すべての実稼働データパイプラインとユーザー接続をSynapseからSnowflakeに切り替えます。

  • Synapse環境は、デコミッショニング前のフォールバックとして、短期間利用可能な状態（可能であれば一時停止状態）にしておきます。

• Synapseのデコミッション：

  • Snowflake環境が安定し、本番環境で検証されたら、Synapse SQL プールを廃止し、コストの発生を止めることができます。

フェーズ9：最適化と実行¶

この最終段階は、新しいSnowflake環境のパフォーマンス、コスト、ガバナンスを管理する継続的なプロセスです。

行動可能なステップ：

• パフォーマンスとコストを最適化する：

  • 適切なサイズのウェアハウス： ワークロードのパフォーマンスを継続的に監視し、仮想ウェアハウスのサイズを調整します。これは、シナプス DWUs のスケーリングの概念に代わるものです。

  • **積極的な自動一時停止ポリシーの設定：**すべてのウェアハウスの自動一時停止タイムアウトを60秒に設定し、アイドル状態の計算時間に対する支払いを回避します。

  • クラスタリングキーの使用： 非常に大きなテーブル（数テラバイト）の場合、高度にフィルタリングされたクエリのパフォーマンスを向上させるためにクラスタリングキーを定義します。

• 長期的な FinOps とガバナンスを確立する：

  • コスト監視： Snowflakeの ACCOUNT_USAGE スキーマとリソースモニターを使用し、クレジットの消費を追跡します。

  • セキュリティを強化する： 役割と権限を定期的に監査します。機密データに対する動的データマスキングや行アクセスポリシーのような高度なセキュリティ機能を実装します。

付録1：SnowflakeとAzure Synapseアーキテクチャ¶

付録2：データ型マッピング¶

付録3： SQLと関数の違い¶