株式会社estieでのSnowflake活用事例

ツール導入前の課題

estieは、商業用不動産事業向けに国内最大級の網羅的な不動産データベースを構築し、そのデータを元にした複数のWebプロダクトを不動産事業者のみなさんに提供しています。 創業直後から提供データ及びユーザ行動の分析基盤としてRedash(on EC2)を活用しており、Amazon Aurora MySQLのリードレプリカ接続とS3に蓄積されたログへのAmazon Athena経由のクエリを組み合わせて必要十分な分析環境を構築していました。(当時の基盤の参考記事はこちら)

創業から3年ほど経過したタイミングで、事業伸張に応じて以下のような課題を感じ始めるようになりました

• クエリ記載の複雑性・難易度の高さ
  • 当時の分析環境はソースデータからクエリすることしか出来なかったため、ログをパースする処理など複雑な処理を毎回（コピー&ペーストを繰り返しながら）書いていた
  • 「特定のユーザが閲覧した建物の詳細情報」など、MySQLの情報とS3にあるログの情報を組み合わせたクエリを書く場合には、RedashのQuery Result Data Source(QRDS)という機能を使って実現しており見通しが悪く、複数のクエリエンジンの記法を覚える必要があった
• クエリ実行時間の長期化
  • 蓄積されたデータが増えるとともに、上記のQRDSを用いる関係もあり実行時間が長期化していた
• データ閲覧権限の管理 　- プロダクトが増加するタイミングであり、特に顧客データを扱うプロダクトのデータについては社内でも担当プロダクトに関連するメンバーだけに閲覧権限を付与したいという要求を見通し良く実現したいと考えていた

• Amazon Redshift(Serverless)
• BigQuery
• Amazon Athena

• 専門知識に基づいた管理のコストが低いこと
  • 特段扱うデータ量が多いわけではない弊社にとって、「深く考えなくても結構なパフォーマンスが出て、コストもそこそこで抑えられる」というのが専門家が掛かりきりでみなくても実現出来ると良いなと考えていました
• 段階的なデータ基盤の改善が実現しやすいこと
  • スタートアップである弊社が3年後の事業状態やその時点の社員数・データ量を完全に予測することはほとんど不可能です
  • 導入時点での決定事項が少なく、様々な決断を後に遅延してもあとからdbtや各種BI、ReverseETLツールとの組み合わせを改善しやすいことを重視していました
• 見通し良く権限管理が可能なこと
  • プロダクト担当のメンバーだけが閲覧可能な情報や、特定メンバーだけが閲覧可能な情報が多くなることが見込まれるため、これらの設定を見通し良くIaCでコードとして管理出来ることを期待していました
• プロダクトとして力を入れて改善され続けそうなこと
  • （評価は難しいのですが…）データ移行は大きなコストを伴います。「移行したけど、またすぐに移行」とならないと良いなと考えていました

トライアルとして、RedashのQRDSを用いたクエリをSnowflakeに移管してみて、パフォーマンスとして問題なかったことからSnowflakeへの移行を決めました。

ComputingとWarehouseがアーキテクチャのベースレベルで分離されており課金形態が実行時間ベースで分かりやすいという点、FivetranなどのData Ingestionツールと統合しやすくdbtを用いてデータパイプラインをインクリメンタルに改善しやすそうな点を元に導入を決定しました。

弊社のデータ分析の元となるデータのほとんどがAWS環境にあることもAWS上に構築出来るSnowflakeの導入を後押ししました。

なくてはならないデータ分析基盤になったと感じています

• 100名程度の社員ほぼ全員がチームの分析のためにクエリを書いてダッシュボードを構築したり、ダッシュボードを閲覧したりといった用途で活用する基盤となっています
• Snowflake導入後に、dbtも導入して分析用に事前集計されたテーブル/ビューの構築も進みました。これにより分析時に書くクエリ量はかなり減少し、より速い実行時間で分析結果を得ることが出来るようになりました
• Streamlit in Snowflakeを用いた簡易WebアプリもSnowflakeの権限を引き継ぎながら構築可能なため、運用用途のデータアプリをSnowflake上に構築しているチームもあります

さらに、導入初期には考慮していなかった展望として、社内向けのデータ分析基盤としての役割だけではなく、顧客に不動産データを提供するためのデータ加工基盤としての役割も担うようになりました。

データ加工基盤としても、

• Pythonで書かれていた処理をdbt(SQL, Python)で実現し、見通し良く高速にデータを複数チームに提供しやすくなった
• 加工した提供データの分析自体をSnowflakeのダッシュボード機能やStreamlit in Snowflakeを用いて行い、品質の高いデータを早く提供しやすい

といったメリットを享受することが出来ています。

QRDSを用いて運用に用いられているダッシュボードのクエリの移行は、やるだけではありつつ分量も多く想像していたよりも複雑なクエリも多かったこともあり苦労しました。 ※苦労するような複雑なクエリが生み出されてしまっていたからこそ移行したメリットは大きいとも言えます

また移行のタイミング(2022年前半)時点では、Snowflake導入経験がある方が市場に多くなかったことから一定調べながら移行を進めるという点が多かったかなと思います。 （副業としてSnowflakeのコミュニティで活躍されていた導入・運用経験が豊富な方に参画して頂き相談しながら進められたので助かりました）

多くの場合、有力な候補になるData Warehouse製品かなと思います。 まずはコミュニティイベントなどに参加したり、記事を読んだりして事例収集などして見るのがオススメです。