Snowflake と Airbyte ではじめるモダンデータスタックへの道
概要
- Awarefy はデータ分析基板として Snowflake を採用した
- 構築にあたる行程のなかで最も課題になっていたデータインジェスチョンについて、Airbyte（OSS版）を採用することで大幅にショートカットすることができた
- Snowsight で簡易的にダッシュボードを構築することができるが、BI ツールほどの機能はないため、この点について課題がある
本記事でお伝えしている要旨は上記のとおりですが、読み進めることで以下についての知見を得られます。
- なぜ Snowflake を選定したのか
- Airbyte の何が嬉しいのか
データスタック・システム構成図
今回のプロジェクトにより構築したデータスタックのクラウドインフラ・アーキテクチャ図は次の通りです。
※ 記載している会社名、製品名、ロゴなどは各社の商標または登録商標です。
Snowflake 検証までの経緯
昨年（2023年）、Awarefy はデータ分析基板として「Snowflake」を採用しました。
株式会社Awarefy
Awarefy がこれまで利用していたデータ分析基板として、Google の BigQuery とAWS の Redshift を利用していました。
BigQuery の使い勝手についてはよく知られているとおりで大きな不満はありませんでした。しかし、アプリケーションのデータが AWS の Aurora 側にあることから、アプリケーション側のデータを元にしたデータ分析については BigQuery では行えない、という課題がありました。BigQuery は Google Analytics と連携しているため、Google Analytics から取得できる行動ログベースでデータを分析していたのですが、Aurora 由来のデータで分析対象としたいデータが増えてきたこともあり、BigQuery だけでは限界を迎えていました。
Aurora から BigQuery にデータを転送して運用を回しているチームもあると思います。Awarefy においてもその選択肢もあるにはあったのですが、AWS のネットワークの外に出てしまうのであれば、BigQuery 以外も検討にいれていいのではないか、ということを考えました。
Redshift については元々 DWH 的な使い方ではなく、Federated Query という機能を使用して Redshift 越しに Aurora のデータに対して分析をかける、という使い方をしていました。
Federated Query については、単に遅い（データサイズが大きくなくても、遅い）という問題があり、若干の工夫を試みたものの、使い勝手の面やデータ可視化ツールとの連携の面で課題があるなと考え、Redshift 以外の選択も検討することになりました。
（前提として総合的な判断を行ったということであり、Redshift や BigQuery、その他選ばなかったサービスが良くない、という主張ではありません、念のため）
なお 2024年1月時点では、Redshift と Aurora の zero-ETL インテグレーションサービスが有力候補としてあげられるのではないかなと思っています（今回はこれ以上は取り扱いません）。
モダンデータスタックへの旅、あるいは沼
そんなこんなで BigQuery でも Redshift でもないデータ・ウェア・ハウス（DWH）を探す旅が始まったわけですが、技術スタックの様変わりのしように当初は大変面食らって、どこから手をつけるのがよいかと右往左往していました。
そんな中、控えめにいって神、順当にいっても神な資料と出会いまして、これを読んで自分の知識が一気にアンラーニング&ラーニングされてその後も大変助かりました。
僕自身は一応その昔、データエンジニア業、ないしクラウドインフラエンジニアを生業としていたつもりだったのですが、その頃とは概念がアップデートされていたり（ETL じゃなくて ELT とか。Every Little Thing ではない）、同じ、または似た領域でもプレイヤーがまったく入れ替わっていたりと、テクノロジー業界の趨勢を感ずにはいられませんでした。
そんな浦島太郎状態の僕でしたが、Snowflake についてはかねてより存じ上げており簡単な検証もしたことがあったことから、"シン・データ分析基盤" を支えるデータベース候補の1つを Snowflake にすると仮定し、Snowflake を中心にどのようにデータ分析環境を整えるか、といったことを設計しました。
今回紙面の都合で割愛するのですが、他に Microsoft Azure Synapse Analytics や Databricks なども検討していました。導入コストや運用コストを含めて、選択肢が多すぎで決められない、という沼に陥っておりなかなか大変でしたが、上述の素晴らしい資料にも助けられ、なんとか収束しました。
最大の課題はデータの連携、Airbyte によりすべてが解決する
データ分析基盤の構築にあたり、課題となるのはデータをどのように転送・連携するか、ということがあります。多くの場合、アプリケーションのデータはアプリケーションに適したデータストア（例えば MySQL や PostgreSQL などの RDB）を利用しており、データ分析や DWH の用途には最適化されていないため、分析用のデータストアは別途用意する必要があります。ひとたびデータ連係が行えても、アプリケーションの実装変更によりデータベーススキーマが変更されたり、連携頻度が変わったり、データソースが増えたりなど、運用の課題は少なくないでしょう。
さて、データベースを Snowflake に定めた場合、Aurora のデータをどのように連携するかが課題になります。この課題が残っているということは、BigQuery を選んだ場合の課題が解決していないのではないかと思われるかも知れません。確かにその指摘は一部正しいのですが、Snowflake はシステムのデプロイ先を Azure/AWS/GCP の中から選ぶことができるため、純粋な "AWS の外の" サービスを利用する場合とやや事情がことなります。
結論からいうと、Airbyte の OSS 版を AWS の EC2 上に展開して運用することで、すべてが解決しました。Every issue has been resolved!!
Airbyte は、Data Ingestion、ELT、Data Integration 領域のプロダクトです。競合、類似のプロダクトとして、Fivetrain や 国内で言うと trocco があります。（各種、色々特徴があるので完全に同じレイヤーのプロダクトに括ることはできないかも知れません）
Fivetrain は Snowflake のテクノロジーパートナーであるらしく良さそうだったのですが、従量課金となると料金面が気になり、高いとか安いという以前に運用体制が固まっていない以上試算が事実上できなさそうという問題を解決できず二の足を踏んでいました。じつは Airbyte もその点については同様なのですが、Airbyte の場合プロダクトが OSS で公開されており（！）、セルフホスティングで運用することが可能です。
Awarefy では Airbyte OSS版（以下、たんに Airbyte）を AWS EC2 上にデプロイし、運用することで費用の不透明さを回避しました。
Airbyte OSS版 の License は MIT および ELv2 です。
airbytehq
Airbyte に辿り着く前、例によっていくつかのツールを選定し簡単な検証を行っていたのですが、スキーマを都度定義したり、連携のための多段階の準備をする必要があったりと導入コストが高く感じられました（AWS Database Migration Service や、Snowpipe 、ないしそれらを含めたいくつかのサービスの連携方法を模索していました）。
前述のスライドで土地勘を付けていたこともあり、運良く Airbyte に辿り着くことができ、検証の結果以下のことがすべてできることが分かりました。
- Aurora PostgreSQL to Snowflake のデータ連携
- データ連携のスケジューリング
- データ連係対象テーブルの選択、データ連係カラムの選定
- dbt との連携
- Amazon S3 to Snowflake のデータ連係
ざっくりいうと、Airbyte を適切に運用することで、Aurora のデータ構造の複製を Snowflake 上につくることができます。分析に必要ないデータや機密性の高いデータは連携しない、という選択もとることができます。テーブルの中のカラムを取捨選択することもできます。
お気づきのとおり、Private VPC 内の EC2 に展開しているので Aurora へのアクセスを問題なく行うことができます。SaaS 版のツールを使う場合、Aurora へのアクセス経路を開放しないといけない点が少し懸念ですよね、そうしたことを考えなくて良い点でもセルフホスティングはお勧めです。Airbyte は Web GUI で操作するのですが、そこまでの経路は Cloudflare Tunnel を使い確保しています。
ダッシュボード構築には Snowsight が使えるが、かなり簡易的
Airbyte を介した Aurora と Snowflake の連携により素材は揃い、あとはデータを分析するのみとなりました。今回、Snowsight（Snowflake の Web GUI 機能全体を指す名称のようです）の中の Data Visualization の機能を利用し、簡易ダッシュボードを構築しました。
Snowsight は、GCP でいうところの Data Portal （現 Looker Studio？）のようなものです。しかし、BI ツールのようなリッチな機能をイメージしてしまうと、その期待値には及ばないでしょう。Snowsight は現時点では、かなり簡易的な機能にとどまっています。それでも、時系列の単純集計といったレベルであれば簡単に可視化とちょっとしたパラメータ指定までできるので、お手軽感はあります。
Snowflake では SQL に加えて Python、Steamlit を Web インターフェース上で動かすことができます。しかしそれらのスキルをまだ身につけていないメンバーもデータ分析を行いたい、というニーズもあると思います。コーディングなしでより高度な分析を行いたければ、Tableau などの BI ツールと連携する必要がありそうです。多くの BI ツールが Snowflake をサポートしています。
もう触れないといいつつ言及してしまうのですが、いまなら Aurora + zero-ETL Integration + Redshift+ Amazon QuickSight のスタックも検討できるのではないかと思います。AI/LLM の統合進化の著しい Microsoft Azure のスタックも気になりますよね。
Snowflake を導入してから数ヶ月が経ちました。プロダクトチームが毎日モニタリングするダッシュボードもでき、施策の善し悪しを判断するために Snowflake を見に行ったりと、しっかり運用に乗っているかなと感じています。セルフホスティングをしている Airbyte も、大きなトラブルなく安定的に稼働しており、ひとまずは OSS版の導入で正解だったなとふり返っているところです。
今回のプロジェクトをつうじて、事業的には使い勝手のよい分析基盤ができたことが何よりのメリットといえ、個人的にはデータスタックについての再学習ができたことが一番大きかったといえます。今後の課題としては BI の環境をどうしていくかということと、dbt を Snowflake と合わせ活用していくかの知見を深めることがあげられます。
2024年はさらなる AI の進化により、データ分析の工程が今よりもさらに自動化・簡略化されることが期待されます。そのときに今回紹介したデータ分析基盤がどのように活用されているのか、楽しみです。