Amazon Redshift から Snowflake へのデータ基盤移行

移行前の状態

シンプルフォームでは、主に金融機関のお客様における法人審査業務を効率化・高度化するための SaaS ソリューションを提供しており、そのために全国 500 万法人に関する様々な定性情報を独自に収集・データベース化しています。これらの法人定性情報やユーザー行動を分析できるよう、Redash をインターフェースとする以下のようなデータ分析基盤を2023年1~2月頃に構築し、2年弱ほど運用してきました。（新基盤への移行をまだ完了できていないため、2025年1月現在も運用中）

• Redshift Serverless を構築し、Redash データソースとして接続
• データ実体は S3 に置いたまま、Glue データカタログ化したものを Redshift Spectrum の機能を利用して参照
• データレイヤー間の変換処理は Glue ETL ジョブで実装し、日次の全件洗い替え方式で定期実行

課題

データ分析が社内的にそれほど普及していなかった構築当時、上記アーキテクチャは分析系リソースを（プロダクトと同じ）AWS 環境内で完結させることができ、分析クエリが実行されなければ ETL 以外にほぼコストのかからないという意味で始めやすいものでした。また、データ量も現在ほど大きくなく、全件洗い替えによる処理の非効率性よりも運用の簡便さのメリットが大きい状況でした。

しかし、事業成長に伴うデータ量の増加や分析ユースケースの多様化、データ分析者の増加などに伴い、以下のような問題に直面するようになりました。

【課題1】 日次 ETL 実行の長期化

全件洗い替え方式で ETL パイプラインを日次実行しているため、時間の経過とともに ETL 実行にかかる時間が長期化し、金銭的コストも日に日に重くなってきていました。ETL 実行が長期化すると、途中のジョブが何らかの原因で失敗した際に復旧までに時間を要してしまい、分析基盤におけるデータの可用性を大きく損ねてしまいます。

現在はテーブル逐次処理を並列化したり、 Glue ジョブのワーカータイプやワーカー台数を調整することによって何とか運用できていますが、いずれ処理しきれなくなるタイミングが訪れる可能性が高いため、早めに増分更新方式に切り替える必要がありました。

【課題2】 分析にかかるコストの増加

ETL 実行にかかるコストだけでなく、データ分析者が発行するクエリの実行にかかるコストも増加していました。分析ユースケースの多様化・データ分析者の増加に伴って Redshift Serverless の基本容量 (Bese Capacity) を徐々に上げている現状があったため、よりクエリ単価の安い DWH 製品への移行のモチベーションが高くなっていました。

【課題3】 コンピュートリソースの競合

単一の Redshift Serverless を全 Redash ユーザーが共有するアーキテクチャとしていたため、大きめのクエリが発行されて Redshift 側が逼迫した際に、パフォーマンス悪化の影響が他の全 Redash ユーザーに波及しやすい状態でした。（弊社の場合、Redshift Spectrum を利用しているので複数の Redshift Serverless に分けることも考えられましたが、それはそれで今後 Redshift マネージドストレージを利用しづらくなるといった制約を抱えることになると考えました）

【課題4】 セキュリティポリシー実装の柔軟性

データ分析基盤上で提供するデータには、アクセス制御を設けるべき機微な情報を含むテーブル・カラムも存在しています。このようなデータは Redshift 上でスキーマを分けた上で、それを含めて参照可能な上位の Redshift ユーザーを作成し、Redash データソースとマッピングするような形で RBAC を実現していましたが、ポリシー変更に柔軟に対応しやすい運用ではありませんでした。

【課題5】 メタデータの管理・提供

データ分析者が Redash 上で参照可能なテーブル・カラムについて、その説明 (description) を知る手段が限定されており、分析に必要な知識が属人化しやすい状況でした。また、各種ソーステーブルから Glue ETL ジョブによって生成された加工済みテーブルについて、その生成過程を分析者側で把握する手段がありませんでした。

他にもいくつか理由はありますが、概ね上記のような課題意識を持って Snowflake × dbt (dbt core) の導入を検討しました。

Snowflake × dbt 以外に検討した選択肢として、以下のようなものがあります。

（※いずれも筆者が検討当時、調査・検証した限りの情報です。内容が最新ではない場合はご容赦ください）

Redshift（継続利用）

まず検討したのは、アーキテクチャを一部変更した上で Redshift を継続利用することです。

• ETL/ELT 部分に Redshift Zero-ETL 機能を利用
• データ変換ツールとして Glue ジョブではなく dbt を利用
• データアクセス制御のため Lake Formation の権限管理機構を利用

もともと Redshift を利用していたこともあり、ある意味で最も無難な選択肢ではありましたが、以下の理由から採用は難しいと判断しました。

• Redash データソースの Redshift (with IAM User/Role) が Redshift Serverless に対応していなかったこと
• Lake Formation 権限の Terraform リソースが上手く動作しなかったこと（Apply した直後に何故か plan 差分が出る）
• dbt を利用しようとすると変換結果を Redshift マネージドストレージに書き込むことになるはずだが、この場合に【課題3】を解消できないこと

データレイクハウスの自前構築・運用

増分更新 (≒ UPSERT) 可能なデータ基盤という観点で、データレイクハウスを自前で構築・運用することも検討してみました。オープンテーブル形式の主要な選択肢としては Hudi, Iceberg, Delta がありましたが、検討の末 AWS Glue × Apache Iceberg の組み合わせで検証を実施しました。

• AWS Glue × Apache Iceberg で構築する更新可能なデータレイクテーブル - Zenn

重要な要件であった「UPSERT が可能であること」についてはクリアできそうな見通しがある程度ついたものの、以下の理由から最終的には見送りました。

• Iceberg の技術自体が黎明期にあり、少人数チームで運用していくには不安が残ること
• Iceberg のメリットの一つとして挙げられる「相互運用性」を意識しなければならないほどの組織規模ではないこと

ただし、上記の検証・検討を行ったのが2024年4月のことでしたが、その後6月に開催された Snowflake Data Cloud Summit や Databricks DATA + AI Summit などを皮切りに急速にベンダー側のサポートが進んでいるように思います。同じ検討を行っても、タイミングによっては違った判断になったかもしれません。

• 上記の【課題1】~【課題5】すべてにおいて改善が見込まれること
• 「コンピュート層」と「ストレージ層」が完全に分離されており、dbt との相性が良いこと
• Snowflake の「サービス層」にあたる各種機能の使い勝手が良く、少人数チームでも運用がしやすいこと
• Terraform Provider が公式にサポートされることが決定していたこと

改善したかった課題はどれくらい解決されたか

【課題1】 日次 ETL 実行の長期化

データ連携方式を「増分更新方式」に変更したことで、時間・コストそれぞれ以下のような効果が得られました。（コストに関しては ETL/ELT に関連する Glue ジョブ、ECS タスク、Snowpipe、仮想ウェアハウス を対象に算出）

• （時間）5~6 時間 → 30 分弱
• （コスト）$31~34 /日 → 約 $3.2 /日

【課題2】 分析にかかるコストの増加

移行過渡期であり、現時点で実績ベースでの比較ができないため割愛します。

【課題3】 コンピュートリソースの競合

こちらも実績に基づく評価は難しいですが、Redash ユーザーグループ毎に利用可能な仮想ウェアハウスを分けており、マルチクラスターウェアハウスによるスケーリングも設定しているため、リソース競合による可用性の低下はかなりの程度抑えられているのではないかと考えています。

【課題4】 セキュリティポリシー実装の柔軟性

Snowflake のデータアクセス制御機構を利用して柔軟性の高い RBAC 実装が可能になりました。また、動的データマスキングの機能を利用することで「値の区別はできるようにしつつ、生の値は参照させたくない」といった細かな要求にも応えられる基盤になりました。

【課題5】 メタデータの管理・提供

dbt のデータカタログ機能である dbt Docs を SAML 認証付きの CloudFront + S3 にホスティングし、データカタログとして社内展開しました。GitHub 管理された dbt プロジェクト内でテーブルメタ情報を付与し、GitHub をソースとする CodePipeline として CI/CD を構築しました。

• dbt Docs をホスティングする AWS インフラ構成 - Zenn

どのような成果が得られたか

その他、以下のような効果を実感しています。

• データ変換に dbt を使用することでエンジニアリング工数が大幅に下がり、高速にデリバリーできるようになった
• アドホックな分析において Snowflake Notebook という選択肢が加わり、Python 利用のハードルが下がった

検討当時、自分も含めて Snowflake, dbt とも利用経験のあるメンバーが社内におらず、導入を滞りなく進められるかどうかは懸念点でしたが、以下のような点を考慮して何とかなりそうな感触を得られたため、導入に踏み切る決断をしました。

• Snowflake サポートがキャパシティ契約に含まれており、追加費用なく利用できること
• 公式ドキュメントの品質が高いこと
• 担当 Account Executive, Sales Engineer からの支援が手厚かったこと
• Snowflake コミュニティが成熟しており、参考にできそうな発信が多数存在していたこと

• 旧データ基盤からの完全移行、Snowflake データ基盤運用の安定化
• 運用の高度化（監視・通知の実装、CI/CD 実装、パフォーマンスチューニング など）
• AI/ML, LLM などの機能を活用した分析の高度化
• Streamlit アプリケーションなどのデータ活用パターンの拡充