データ基盤移行を振り返る

はじめに

こんにちは！シンプルフォームの山岸です。

弊社では社内向けのデータ分析基盤としてこれまで Amazon Redshift を利用してきましたが、昨年6月に Snowflake の導入を決定し、移行に向けた検証・構築を進めてきました。当時の技術選定については、以下の Findy Tools レビュー記事でもご紹介しています。

https://findy-tools.io/products/snowflake/10/360

昨年末に Snowflake 基盤の提供を開始してからは、旧 Redshift 基盤の運用を停止すべく既存クエリ資産の移行に奔走していましたが、先日ようやくの終わりを迎えました。

上記のレビュー記事では技術選定をメインに扱いましたが、本記事では弊社データ基盤の歴史と、データ基盤移行のプロセスについて振り返ってみたいと思います。

SimpleForm データ分析基盤の歴史

① データ分析基盤がなかった時期【- 2022.12】

弊社は主に金融機関のお客様を対象に、法人調査・審査業務を効率化・高度化するためのソリューション「SimpleCheck」を提供しています。2022年6月に正式リリースを開始し、現在は有難いことに多くのお客様にご利用頂いております。

サービス提供開始当時、データ分析用の OLAP データベースなどはなく、どうしても分析の必要がある時はプロダクト用の OLTP データベースに直接クエリが発行されていました。DB の CPU 使用率が 99% に貼り付くといったことも度々起きており、当時はまだご導入頂いているお客様も少なく影響が小さかったとは言え、今から考えるとかなり怖い状況です。

ちょうどこの頃、カスタマーサクセス部門が発足したこともあり、より精緻な分析を安心して（=プロダクトに影響を与えることなく）行いたい需要が高まっていたため、データ分析基盤の構築に着手しました。

② Redshift 基盤の初期構築・リリース【2023.1 - 2023.2】

初期のデータ分析基盤として、以下のようなアーキテクチャで構築しました。

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

構築の際に特に意識したことは、「従量課金のコスト体系であること」「なるべく早くリリースできること」「なるべく運用が簡単であること」の３点です。

• 「従量課金のコスト体系であること」 ... データ分析がほとんど普及していなかった当時、どれほどの価値をもたらせるか見通せない状況で、大きな固定費がかかる構成を採るのは避けたいと考えていました。その意味で、Redshift Serverless はクエリが発行されなければコストが全くかからないので、相性が良いと考えました。
• 「なるべく早くリリースできること」 ... 一部では既に分析需要が大きかったので、なるべく早くリリースできるよう、比較的慣れ親しんでいた AWS サービスで技術スタックを固めました。（困ったら AWS サポートに聞けば何とかなるだろうという安心感もありました）
• 「なるべく運用が簡単であること」 ... データ連携方式として、「全件洗い替え」「増分更新」「変更データキャプチャ (CDC)」などの選択肢がありましたが、当時はインフラエンジニアが自分一人だったこともあり、最も運用が簡単な「全件洗い替え」で実装しました。

③ 普及展開【2023.3 -】

データ分析基盤を初期リリースしてからは、かなり速いペースで普及が進んだと思います。最初こそカスタマーサクセス部門での利用がメインでしたが、すぐに他部門での調査・分析業務でも利用されるようになりました。

というのも、Biz チーム側で主体的に SQL 勉強会を定期開催してくれるメンバーがおり、特に基盤側から何かアクションを起こさなくても勝手に普及が進んでいくような状況がありました。基盤を構築してもそれが業務で活用されるまでには大きなハードルがあるだろうと思っていたので、この点は良い意味で誤算であり、かなり環境に恵まれていたと思います。

④ データ基盤改善【2023.3 -】

データ分析基盤の提供を開始してからも、必要な改善施策を適宜実行してきました。

• DB 以外のデータソースや分析用データマートテーブルの拡充
• ETL パイプラインの改善（リトライ機能の実装、テーブル逐次処理の並列化 など）
• Redash のアーキテクチャ改善（Redis のコンテナ化 など）
• Aurora MySQL バージョンアップ対応に伴う一時テーブル対応 ... etc.

Snowflake へのデータ基盤移行

発端【2024.2】

データ基盤移行を真剣に考え始める契機となったのが、法人ナレッジグラフ機能 (CKG: Company Knowledge Graph) の内部向け提供開始 ^[1] でした。この機能は、RDB のような構造化テーブルからは探索するのが難しい法人間のつながりを、グラフ機能を用いて可視化するというもので、裏側では Amazon Neptune というグラフ DB サービスを利用しています。

グラフ機能の提供開始から間もなくして、それまで 2~3 時間ほどで完了していた日次バッチが急にタイムアウトや Out-of-Memory で失敗するようになりました。機能提供開始に伴うデータ量増加が原因であることは分かったので、その時は Glue ジョブのワーカータイプや台数を調整することで何とかなりましたが、全件洗い替え方式がいずれ限界を迎えることを悟った出来事でした。

① 技術選定【2024.4 - 2024.6】

移行先データ基盤の技術選定に関しては、冒頭にもご紹介した こちらの記事 をご覧頂けると嬉しいです。検討当初、Snowflake はそこまで選択肢として考えておらず（というより存在を知っている程度で何がすごいのかあまり分かっておらず）、データ連携方式だけ変更して Redshift を採用し続けるか、あるいは流行り始めていた Apache Iceberg を導入してみるかで悩んでいました。（Apache Iceberg × AWS Glue の検証内容については こちらの記事 でも扱っています）

いずれにしてもデータモデリング部分に dbt を導入したいとは考えており、そのキャッチアップのために以下の Udemy 講座を受講してみたのですが、その過程で Snowflake トライアルアカウントを開設してみたのが Snowflake との出会いでした。

• The Complete dbt (Data Build Tool) Bootcamp: Zero to Hero - Udemy

その後 Snowflake の営業担当の方からご連絡を頂き、最初は情報収集（いつか導入するかも）のつもりでお話しを伺っていましたが、話を聞くほど「今まさに導入するべきなのでは」という気持ちが強くなり、最終的には CTO を説き伏せにかかりました。

② 検証・構築【2024.7 - 2024.12】

Snowflake の導入を決めてから約半年ほどかけて、重要な機能・非機能要件の検証、および構築に取り組みました。Snowflake・dbt ともほぼ未経験で右も左も分からない状況でしたが、SnowVillage コミュニティからの発信（特に Kevin さんの「Snowflake × dbt × Terraform」軸の発信 ^{[2] [3]}）には大いに助けられました。

主に以下のような取り組みを行いました。

• Terraform+Terragrunt による Snowflake インフラリソース管理の検討 ^[4]
• ソース DB からの増分更新 ELT アーキテクチャの検証・構築 ^{[5] [6] [7]}
• セキュリティ等の非機能検証（SnowSight への SAML 認証ログイン ^[8]、RBAC のためのロール設計、動的データマスキング ^[9] 等）
• データカタログ提供のためのホスティング・CI/CD 基盤実装 ^[10]

技術的な課題にぶつかりつつも、Snowflake 社員やコミュニティの助けも借りながら何とか乗り越えることができ、年を越す前には社内向けの提供開始をアナウンスすることができました。

③ 移行期【2025.1 - 2025.3】

Snowflake 基盤の提供を開始して終わりではなく、これまで利用してきた Redshift 基盤の運用を停止可能な状態にし、実際に停止できて初めて移行完了になります。具体的に行ったことは次節で詳しく述べますが、以下のようなスケジュール感で旧基盤からの段階的な移行を進めました。

移行期にやったこと

① 社内情報発信

まず行ったのは社内情報発信です。データ基盤移行に伴って利用者側にも少なからず負担を強いることになるので、「なぜ移行する必要があるのか」「具体的にどのように移行を進めていく想定なのか」に対する説明を、週次の全社会や Slack 周知などを通じて行いました。

また、Snowflake 自体についても知ってもらう機会があった方が良いかと考え、Snowflake 社員（担当 AE・SE）をオフィスにお招きして勉強会を開催したりもしました。

② ドキュメント整備

ドキュメント整備の一環として、『Redashクエリ移行ガイド』なる Notion ページを作成しました。これは、Redshift 向けに書かれたクエリを Snowflake 向けに書き直すにあたって、具体的にどのように修正すべきかを示す位置付けのものです。データ基盤アーキテクチャやデータモデルの新旧対応表、Redshift・Snowflake 間のクエリ記述の違いなどを、具体的なサンプルクエリ実装も交えながら内容として盛り込みました。

③ クエリ移行代行

基本的には前述の『Redashクエリ移行ガイド』に沿って、移行が必要な既存クエリ・ダッシュボードについて現場側での修正をお願いする形を取っていましたが、所定の Notion ページに起票してもらったものに関しては、移行対応をデータ基盤チーム側で代行することにしました。

データモデルにほとんど変更がなく（せいぜいテーブル名変更程度で）クエリ修正が比較的容易であれば、現場側に全てお願いすることも出来たかもしれませんが、それまで負債だと感じていたデータモデリングをデータ基盤移行を機に大きく変更したため、既存クエリの移行までを現場（特に Biz チーム）にお願いするのは難しいだろうと判断し、このような対応にしました。

結果的には 86 個のクエリと 27 個のダッシュボードを起票頂き、数の多さに若干面食らいましたが、データ基盤チーム以外にも Biz 新規参画メンバー2名が手伝ってくれたこともあり、無事スケジュール通りに移行を終えることができました。

移行を振り返って

他部門への依頼やコミュニケーションが多くなるという意味で、技術的な検証・構築の時期よりも移行期の方がやはり大変だった（コントロールが難しかった）なと改めて思います。

ただ、今回現場のクエリ移行を担ってみたことで、それまであまり見えていなかった現場の分析ニーズに対する解像度を上げることができ、ポジティブな側面も非常に大きかったと感じます。移行の過程で従来の非効率な運用を見直したり、非正規化テーブルの整備・汎用な変換処理の UDF 化を行ったりと、基盤側の改善をかなり進めることができました。

また、クエリ移行を手伝ってくれた Biz メンバーにとっても SQL や社内データ構造について理解を深める機会として上手く活用してもらえたようで、その点でも非常に良かったと思います。

最後に

SimpleForm におけるデータ分析基盤の歴史と、Snowflake へのデータ基盤移行について振り返ってみました。いかがだったでしょうか。

データ基盤に関する事情は百社百様だと思いますので、そのまま他社で適用できるものは多くないかもしれませんが、少しでも参考になる情報があったなら幸いです。それでも共通して言えることは、自社のデータ利活用の成熟度や投じられるリソース（コスト・人員）を勘案しながら、技術選定・取り組み優先度・実行プロセス 等を都度適切に意思決定していくことが大事、ということではないかなと思います。

最後まで読んで頂き、ありがとうございました。

脚注

1. 本機能は、2024年12月に正式提供が開始しています。 - 目に見えない法人間のつながりを30秒で可視化する新機能を提供開始～人手では難しかった関連事業者の特定・分析・リストアップを瞬時に実現し、最新の法人間ネットワークが把握可能に。リスク・実体性の評価業務の判断精度向上に寄与～

2. Snowflake×dbt×Terraformでモダンなデータ基盤開発してみた - Medium

3. Snowflake x dbt x Terraform マルチデータプロダクト基盤 [DataOps Night #4] - SpeakerDeck

4. 【個別検証】Terragrunt で始めるマルチアカウント Snowflake 環境構築 - Zenn

5. 【個別検証】Snowpipe によるファイル取り込みを AWS Lambda から動かしてみる - Zenn

6. 【個別検証】Snowflake × dbt で構築する ELT アーキテクチャ - Zenn

7. 【個別検証】Snowflake への ELT ワークフローを AWS Step Functions で実装してみた - Zenn

8. 【個別検証】Snowflake の SAML 認証を AWS IAM Identity Center で構築する - Zenn

9. 【個別検証】Snowflake Secret を用いたソルト付きハッシュ化 UDF - Zenn

10. 【個別検証】dbt Docs をホスティングする AWS インフラ構成 - Zenn