Amazon RedshiftからSnowflakeへの移行ガイド¶

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

この初期段階は、移行を成功させる基盤を確立するために非常に重要です。このステップを急ぐと、スコープクリープ、予算超過、納期遅れにつながることが多いです。綿密な計画によって、すべての利害関係者の足並みが揃い、プロジェクトの目標が明確に定義されます。

行動可能なステップ：

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

  • インベントリと分析： Redshiftクラスタ内のすべてのデータベース、スキーマ、テーブル、ビュー、ストアドプロシージャ、ユーザー定義関数（UDFs）をカタログ化します。Redshiftのシステムテーブル（SVV_TABLE_INFO、PG_PROCなど）を使ってメタデータを収集します

  • ワークロードの分析： Redshift のSTL_QUERYとSVL_QUERY_SUMMARYビューを使⽤して、クエリパターン、ユーザー同時処理、パフォーマンスのボトルネックを特定します。このデータは、Snowflakeウェアハウス戦略を設計する上で極めて重要です

  • 依存関係の特定： 全てのアップストリームデータソース（ETL/ELTジョブ）とダウンストリームコンシューマー（BIツール、アプリケーション、データサイエンスノートブック）をマップします

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

  • ワークロードの優先順位付け： ビジネスへの影響と技術的な複雑さによってワークロードを分類します。手っ取り早く成果を上げ、勢いをつけるために、インパクトが大きく、複雑度の低い仕事から始めましょう

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

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

  • チームの確立： 明確な役割と責任を持った移行チームを作ります（プロジェクトマネージャー、データエンジニア、DBA、セキュリティ管理者、ビジネスアナリストなど）

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

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

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

しっかりとした計画を立てた上で、次のステップはSnowflake環境を準備し、セキュリティ体制を再現することです。Redshiftからの移行の主な利点は、両プラットフォームが通常同じクラウドプロバイダー（AWS）上で稼働するため、データ転送が簡素化されることです。

行動可能なステップ：

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

  • エディションとクラウドプロバイダーの選択: ニーズを満たすSnowflakeのエディション（Standard、Enterprise、Business Criticalなど）を選択します。クラウドプロバイダーとしてAWSを選び、現在のS3バケットと同じリージョンを選択し、データ転送コストとレイテンシーを最小限に抑えます

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

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

  • Redshiftのユーザー/グループをSnowflakeのロールにマッピングする： Redshiftのユーザーとグループの権限をSnowflakeのロールベースのアクセスコントロール（RBAC）モデルに変換します。機能ロール（例：SYSADMIN、SECURITYADMIN）とアクセスロール（例：BI_READ_ONLY、ETL_READ_WRITE）の階層を作成します

  • ネットワークポリシーと認証の構成: ネットワークポリシーを設定し、信頼できるIPアドレスへのアクセスを制限します。OktaやAzure ADのようなIDプロバイダーを使用してフェデレーション認証（SSO）などの認証方法を構成します

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

このフェーズでは、RedshiftのDDL、DML、手続きコードをSnowflakeと互換性があるように変換します。自動化ツールはこのプロセスを加速させますが、SQL方言やプラットフォームアーキテクチャの違いにより、手作業によるレビューと調整が不可欠です。

行動可能なステップ：

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

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

  • Redshift固有の句を削除する： DISTSTYLE、DISTKEY、SORTKEYのようなRedshift固有の物理設計句を削除します。Snowflakeのアーキテクチャは、データの分散とクラスタリングを自動的に、または非常に大きなテーブルの論理クラスタリングキーによって処理します

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

  • ストアドプロシージャの書き換え： Redshift はストアドプロシージャにPL/pgSQLを使用します。これらは、Snowflakeスクリプト（SQL）、JavaScript、Python、Javaなど、Snowflakeがサポートする言語に手動で書き換える必要があります。これはコード変換プロセスの中で最も時間のかかる部分であることが多いです

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

  • メンテナンスコマンドの置き換え： VACUUM、ANALYZE、REINDEXのようなRedshift固有のコマンドを含むスクリプトは、Snowflakeがこれらのメンテナンスタスクを自動的に処理するため、削除する必要があります。

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

このフェーズでは、RedshiftクラスターからSnowflakeテーブルへの履歴データの物理的な移動に焦点を当てます。最も効率的な方法は、中間ステージング領域としてAmazon S3を活用することです。

行動可能なステップ：

• RedshiftからS3にデータをアンロードする：

  • Redshift UNLOADコマンドを使用して、指定したS3バケットにテーブルからデータをエクスポートします。これは高度に並列化されており、クライアントツールを介したSELECTクエリよりも大幅に高速です

  • Snowflakeへの読み込みパフォーマンスを最適化するために、データをParquetまたは圧縮されたCSVとしてフォーマットします。複数のファイルを書き込むには、PARALLEL ONオプションを使用します

• S3からSnowflakeにデータをロードする：

  • 外部ステージの作成： Snowflakeで、ロードされていないデータを含むS3バケットを指す外部ステージオブジェクトを作成します

  • COPY INTOコマンドを使用する： SnowflakeのCOPY INTO <table> コマンドを使用して、S3ステージから対象のSnowflakeテーブルにデータをロードします。このコマンドはパフォーマンスとスケーラビリティに優れています

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

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

履歴データの移行が完了したら、Redshiftの代わりにデータを直接Snowflakeにフィードするために、進行中のデータ取り込みパイプラインを再設計する必要があります。

行動可能なステップ：

• バッチETL/ELTジョブを移行する：

  • 既存のETLジョブ（AWS Glue、Talend、Informaticaなどのツールで）を更新して、Snowflakeをデスティネーションとしてターゲットにします。これには通常、接続の詳細の変更と、Snowflakeの方言を使用するためのSQLオーバーライドの更新が含まれます

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

  • 連続的なデータストリーム（KinesisやS3にあるアプリケーションログなど）の場合は、Snowpipeを設定します。Snowpipeは、S3から新しいデータファイルが到着すると自動的かつ効率的にSnowflakeテーブルにロードし、ほぼリアルタイムの取り込みソリューションを提供します

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

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

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

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

行動可能なステップ：

• 接続ドライバを更新する: BIツールをホストするサーバー（Tableau Server、PowerBI Gateway、など）にSnowflakeのODBC/JDBCドライバーをインストールし、構成します

• レポートとダッシュボードをリダイレクトする：

  • BIツールで、データソース接続をRedshiftからSnowflakeに変更します。

  • すべての重要なレポートとダッシュボードをテストし、正しく機能することを確認します

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

  • 一部のダッシュボードには、カスタムSQLまたはデータベース固有の関数が含まれている場合があります。これらのクエリを見直し、SnowflakeのSQL方言を使ってパフォーマンス機能を活用できるようにリファクタリングします。Snowflakeのクエリプロファイルツールを使用して、実行速度の遅いレポートを分析し、最適化します

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

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

行動可能なステップ：

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

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

  • セルレベル検証: 重要なテーブルについては、集約された値（SUM()、AVG()、MIN()、MAX()など）を比較するか、キー列のチェックサムを使用することで、より深い検証を行います

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

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

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

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

  • ビジネスユーザーに参加してもらい、新しいSnowflake環境を使用してレポートを検証し、日々のタスクを実行してもらいます。フィードバックを集め、問題があれば対処します

フェーズ8：デプロイ¶

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

行動可能なステップ：

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

  • 週末または夕方のカットオーバーイベントの順序を決めます。これには、RedshiftをポイントするETLジョブの停止、最終的なデータ同期の実行、すべての接続のリダイレクト、システムの健全性の検証などが含まれます

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

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

• 実稼働環境への移行：

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

  • Redshift環境を廃止する前の予備措置として、短期間読み取り専用状態にしておきます

• Redshiftを廃止する：

  • Snowflake環境が安定し、本番環境で検証されたら、Redshiftクラスターを廃止し、コストの発生を止めることができます

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

この最終段階は、新しいSnowflake環境のパフォーマンス、コスト、ガバナンスを管理する継続的なプロセスです。目標は、継続的にセットアップを改良し、価値を最大化することです。

行動可能なステップ：

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

  • ウェアハウスのサイズ適切化: ワークロードのパフォーマンスを継続的に監視し、ウェアハウスのサイズの増減を調整することで、可能な限り低いコストでSLAsを満たすことができます

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

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

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

  • コスト監視: SnowflakeのACCOUNT_USAGEスキーマとリソースモニターを使用し、クレジットの消費を追跡し、予算超過を防ぎます

  • セキュリティの改善: 最小権限の原則が維持されるように、役割と権限を定期的に監査します。機密データに対する動的データマスキングや行アクセスポリシーのような高度なセキュリティ機能を実装します

付録1：SnowflakeとRedshiftアーキテクチャの比較¶

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

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