Snowflakeへのデータ移行/データ基盤マイグレーションの勘所

NUP WHITE Tech Blog

Snowflakeへのデータ移行データ基盤マイグレーションの勘所データは現代ビジネスの血液であり、その流れを滞りなく、かつ効率的に管理するデータ基盤は企業の成長戦略において不可欠です。NUP WHITEのエンジニアチームは、これまで複数社で様々なデータ基盤の構築とマイグレーションを経験してきました。その中で、ビジネス要件の変化やデータ量の増大、既存システムの限界といった課題に直面し、新たなデータ基盤への移行を成功させてきました。

本稿では、数あるデータウェアハウスの中でも特に高い注目を集めるSnowflakeへのデータ移行について、私たちが直面した課題（いわゆる“ハマりポイント”）とその解決策を、具体的な機能に触れながらご紹介します。データ基盤の移行を検討されている方、特にSnowflakeへの移行を計画中の方にとって、本記事が少しでもお役に立てば幸いです。

なぜSnowflakeへのデータ基盤マイグレーションが必要だったのか

これまでのプロジェクトで共通して見られたのは、既存のデータ基盤が抱える以下のような課題でした。

スケーラビリティの限界: 事業成長に伴うデータ量の爆発的な増加や、複雑化する分析要件に対し、既存のデータストアが追従できなくなっていました。特にピーク時のクエリパフォーマンスの低下は、ビジネス上の意思決定に遅延をもたらしていました。
運用コストの増大と複雑性: オンプレミスや特定のクラウドサービスに最適化された従来のデータ基盤では、ハードウェアの選定、構築、運用、そしてパッチ適用といったインフラ管理の負担が大きく、エンジニアのリソースが分析業務ではなく運用に割かれていました。
データ活用の障壁: 複数のデータソースからのデータ統合が困難であったり、異なるデータ形式への対応が限定的であったりするため、データアナリストやビジネスユーザーがリアルタイムに近い形でデータを活用することが難しい状況でした。
技術的負債: 長年の運用で蓄積された複雑なETLロジックや、属人化した運用プロセスが、新たな機能開発や改善の足かせとなっていました。

これらの課題を解決し、柔軟なスケーラビリティ、高いパフォーマンス、運用負荷の軽減、そして多様なデータソースへの対応能力を持つSnowflakeは、私たちのチームにとって最も魅力的な選択肢となりました。コンピュートとストレージの分離、マルチクラウド対応、従量課金モデル、そしてSQLベースのシンプルな操作性は、データ活用を加速させる上で非常に強力な武器となると判断したのです。

Snowflake移行におけるハマりポイントと解決策

ここからは、実際に私たちが経験した具体的なハマりポイントと、それらをどのように解決していったかをご紹介します。

1. 既存のNoSQLデータベースからのデータ移行と複雑な構造への対応

ハマりポイント

従来のデータストア、特に柔軟なスキーマを持つNoSQLデータベースからSnowflakeへのデータ移行は、最も労力を要する部分の一つでした。NoSQLではJSON形式などの半構造化データがそのまま格納されていることが多く、これをリレーショナルな構造を持つSnowflakeに適合させるには、スキーマの設計変更と複雑なデータ変換が必要でした。また、膨大な量の初期データロードと、継続的な増分データの連携も課題でした。

解決策:

初期データロード

大量のデータ移行には、S3などのクラウドストレージを経由した一括ロードが最も効率的です。既存のNoSQLからデータを抽出し、JSON Lines形式やParquet形式などでクラウドストレージに配置します。SnowflakeのCOPY INTOコマンドは、これらの半構造化データをVARIANT型カラムとして取り込むことができ、さらにFROM句内でparse_jsonやflatten関数を組み合わせることで、ロード時に必要な要素を抽出し、リレーショナルなテーブル構造に整形しながら取り込むことが可能です。これにより、初期のETLプロセスを大幅に簡素化できました。

COPY INTO target_table (id, name, value)

FROM (

    SELECT

        $1:id::VARCHAR,

        $1:name::VARCHAR,

        $1:data.value::INTEGER

    FROM @my_stage/data/path/

)

FILE_FORMAT = (TYPE = JSON STRIP_OUTER_ARRAY = TRUE)

ON_ERROR = 'CONTINUE';増分データ連携

リアルタイムに近い増分データ連携には、SnowflakeのSTREAMとTASK、そしてPIPEを組み合わせるのが効果的です。

既存のシステムから変更データキャプチャ（CDC）の仕組みを導入し、S3などのクラウドストレージに差分データを継続的に出力します。

PIPEは、外部ステージ（S3など）にファイルが置かれると自動的にデータをSnowflakeテーブルにロードする機能です。これにより、データ取り込みのプロセスをフルマネージドで自動化できます。

さらに、対象テーブルにSTREAMを定義することで、そのテーブルに加えられた変更（INSERT/UPDATE/DELETE）を履歴として追跡できます。このSTREAMをソースとして、TASKで定義したSQLプロシージャやマージ文を実行することで、リアルタイム性の高いDWHへの反映を実現しました。

`-- STREAMの作成例

CREATE STREAM my_table_stream ON TABLE my_source_table;

-- TASKの作成例

CREATE OR REPLACE TASK my_merge_task

  WAREHOUSE = my_warehouse

  SCHEDULE = '5 minute' -- 5分ごとに実行

  WHEN SYSTEM$STREAM_HAS_DATA('my_table_stream') -- ストリームにデータがある場合のみ実行

AS

  MERGE INTO my_target_table T

  USING my_table_stream S

  ON T.id = S.id

  WHEN MATCHED AND S.METADATA$ACTION = 'DELETE' THEN DELETE

  WHEN MATCHED THEN UPDATE SET T.col = S.col, T.updated_at = S.updated_at

  WHEN NOT MATCHED THEN INSERT (id, col, created_at, updated_at) VALUES (S.id, S.col, S.created_at, S.updated_at);

ALTER TASK my_merge_task RESUME;データ変換ロジックの一元化

複雑なデータ変換ロジックは、オープンソースのデータ変換ツールであるdbt (data build tool) を活用して一元的に管理しました。dbtを用いることで、SQLを使ってデータ変換モデルを定義し、依存関係を明確にした上で、テスト、ドキュメント生成、バージョン管理を行うことができます。これにより、開発者が分散していた変換ロジックを共通のSQLモデルとして再構築し、保守性と信頼性を大幅に向上させることができました。特に、半構造化データから必要な情報を抽出・整形する際には、dbtの柔軟なモデル定義が大いに役立ちました。

2. データモデル設計とパフォーマンスの最適化

ハマりポイント:

NoSQLの世界からリレーショナルなDWHへ移行する際、既存のアプリケーションのデータアクセスパターンに囚われすぎると、DWHとして最適なデータモデルを設計できません。特に、JOINの多用や大量データのスキャンが必要なクエリでパフォーマンスが出ない、という課題に直面しました。また、VARIANT型の多用によるクエリパフォーマンスの低下も懸念されました。

解決策:

適切なデータモデルの設計

データウェアハウスのベストプラクティスであるスタースキーマやスノーフレークスキーマを採用し、ファクトテーブルとディメンションテーブルに再設計しました。これにより、クエリの可読性とパフォーマンスを向上させ、ビジネスユーザーが理解しやすいデータ構造を提供しました。

VARIANT型の賢い利用

すべての半構造化データをフラット化するのではなく、利用頻度の低い情報やスキーマが頻繁に変わる可能性のあるデータはVARIANT型として保持し、必要に応じてparse_jsonやjson_extract_path_text関数で抽出するようにしました。ただし、頻繁にクエリされるキーは、別途カラムとして抽出し、クエリパフォーマンスを確保しました。

マイクロパーティショニングとクラスタリング

Snowflakeのアーキテクチャは自動的なマイクロパーティショニングによってある程度のパフォーマンスを保証しますが、非常に大規模なテーブルや特定のフィルター条件でのクエリが多い場合は、CLUSTER KEYを設定することでパフォーマンスをさらに向上させることができました。例えば、タイムスタンプや頻繁にフィルタリングされるID列をクラスタリングキーに設定することで、データのプルーニング効率を高めました。

マテリアライズドビュー (Materialized View) の活用*:

集計クエリや頻繁に実行される複雑なJOINを含むクエリに対しては、Materialized Viewを導入しました。これにより、クエリ実行時に毎回計算することなく、最新の集計結果を高速に取得できるようになり、分析レポートの表示速度が大幅に改善されました。Snowflakeが自動でビューをメンテナンスしてくれるため、運用負荷も小さい点が利点です。

仮想ウェアハウスの最適化

ワークロードに応じて仮想ウェアハウスのサイズ（X-Small, Small, Mediumなど）を適切に調整し、複数のウェアハウスを使い分けることで、分析クエリとETLジョブのパフォーマンスを両立させました。また、自動サスペンドと自動リジュームを設定することで、コスト効率も最大化しました。

3. 既存データパイプラインの移行とオーケストレーション

ハマりポイント:

既存のデータパイプラインは、様々なスクリプトやバッチ処理が混在しており、それらの依存関係も複雑でした。これをSnowflake上で効率的に再構築し、監視・運用可能な形にする必要がありました。

解決策:

Snowflake TASKによるオーケストレーション*:

定時実行されるデータ変換処理や集計処理は、SnowflakeのTASK機能を用いて定義しました。複数のTASKを依存関係に基づいてチェーン化することで、複雑なワークフローをSnowflake内部で構築できます。これにより、外部のワークフロー管理ツールの導入コストを抑えつつ、堅牢なパイプラインを構築しました。

-- 依存関係を持つTASKの作成例

CREATE OR REPLACE TASK my_task_b

  WAREHOUSE = my_warehouse

  AFTER my_task_a -- my_task_aの完了後に実行

AS

  INSERT INTO final_table SELECT * FROM intermediate_table;

PROCEDUREの活用*:

より複雑なロジックや条件分岐が必要な処理は、Snowflake Procedure（JavaScriptやPythonなどで記述可能）を活用しました。これにより、SQLだけでは表現が難しい処理もSnowflake内で実行でき、データパイプラインの一貫性を保つことができました。

セキュリティ考慮事項

データ基盤の移行において、セキュリティは最優先事項です。私たちは以下の点を特に重視しました。

ロールベースアクセス制御 (RBAC) の徹底:

Snowflakeの強力なRBACモデルを活用し、最小権限の原則に基づいてアクセス権限を付与しました。ユーザーやアプリケーションの役割ごとにカスタムロールを定義し、各ロールに特定のデータベース、スキーマ、テーブル、ビュー、仮想ウェアハウスへのアクセス権限をGRANTしました。例えば、データアナリストには特定の分析用ビューへの読み取り権限のみを付与し、生データへの直接アクセスは制限しました。

データ暗号化:

Snowflakeは保存データ（データストレージに格納されるデータ）と転送データ（ネットワークを介して転送されるデータ）の両方を、デフォルトで業界標準の暗号化技術を用いて保護します。この自動暗号化により、データ保護の基礎が確立されていることを確認しました。より高度な要件がある場合は、顧客管理キー（CMK）を利用することも検討しました。

動的データマスキングポリシー (Masking Policy):

個人情報や機密性の高い情報が含まれるカラムに対しては、Masking Policyを適用しました。これにより、アクセスするロールに応じてデータをマスキング（例: メールアドレスの一部を*で隠す、ハッシュ化するなど）し、機密情報の漏洩リスクを最小限に抑えました。特定の権限を持つユーザーのみが完全なデータを見られるように設定し、それ以外のユーザーにはマスキングされたデータのみを提供しました。

-- マスキングポリシーの作成例

CREATE OR REPLACE MASKING POLICY email_masking_policy AS (val VARCHAR) RETURNS VARCHAR ->

    CASE

        WHEN CURRENT_ROLE() IN ('SECURITY_ADMIN', 'DATA_GOVERNANCE') THEN val

        ELSE REGEXP_REPLACE(val, '(^[^@]{1,3}|(?!^).?)(?=@)', '**')

    END;

-- カラムへのポリシー適用

ALTER TABLE users MODIFY COLUMN email SET MASKING POLICY email_masking_policy;

4. ネットワークセキュリティ:

外部からの不正アクセスを防ぐため、IPアドレスの許可リストを設定し、許可されたIPアドレスからのアクセスのみをSnowflakeアカウントに許可しました。さらに、特定のクラウドプロバイダを利用している場合は、AWS PrivateLinkやAzure Private Link、Google Cloud Private Service Connectといったプライベート接続オプションを利用し、インターネットを介さないセキュアなネットワークパスを確立しました。

監査とロギング:

Snowflakeの強力な監査機能（Query History, Access Historyなど）を活用し、誰が、いつ、どのようなデータにアクセスし、どのような操作を行ったかを常に監視しました。これらのログは必要に応じてSIEM（Security Information and Event Management）ツールと連携させ、異常なアクティビティを早期に検知できる体制を構築しました。

運用と継続的な改善

データ基盤の移行は一度行えば終わりではありません。移行後も、コストの最適化、パフォーマンスの監視、そして新たなビジネス要件への対応といった継続的な運用が求められます。

SnowflakeのResource Monitor機能は、仮想ウェアハウスの利用状況やクレジット消費を監視し、予算超過のリスクを管理する上で非常に有用でした。また、dbt Cloudのような外部ツールと連携することで、データパイプラインの実行状況の可視化、エラー通知、そしてデプロイメントの自動化を実現し、運用負荷の軽減に努めました。

まとめ

Snowflakeへのデータ基盤マイグレーションは、既存システムの課題を解決し、データ活用の可能性を大きく広げるための重要なステップです。私たちのチームは、複数社での経験を通じて、移行には多くの困難が伴うことを学びましたが、適切な計画、Snowflakeの機能を最大限に活用する戦略、そしてdbtのような強力なデータ変換ツールとの連携によって、これらの課題を乗り越え、成功に導くことができました。

特に、従来のNoSQLデータベースからのデータ移行における複雑なデータ構造への対応、データモデルの再設計、そしてセキュリティの確保は、移行プロジェクトの成否を分ける重要なポイントとなります。本稿でご紹介したハマりポイントと解決策が、これからSnowflakeへの移行に挑戦される皆様の道標となれば幸いです。

データ基盤は、構築して終わりではなく、常に変化するビジネス要件と技術の進化に合わせて継続的に改善していくものです。NUP WHITEのエンジニアチームは、これからも最先端の技術を取り入れながら、お客様のデータ活用を強力に推進していきます

Snowflakeへのデータ移行/データ基盤マイグレーションの勘所

なぜSnowflakeへのデータ基盤マイグレーションが必要だったのか

Snowflake移行におけるハマりポイントと解決策

1. 既存のNoSQLデータベースからのデータ移行と複雑な構造への対応

2. データモデル設計とパフォーマンスの最適化

3. 既存データパイプラインの移行とオーケストレーション

セキュリティ考慮事項

運用と継続的な改善

まとめ

関連記事

Bigquery料金抑制のアラート作成方法

チャットボットはWeb接客の要になる！メリットやデメリットとは

広告出稿にも最適な「Instagram」の運用について