(画像は Snowflake 公式 Web サイトのものを流用)
本記事について
昨年の4月に前職をレイオフされ、同6月にシンガポールのFinTechスタートアップ（デジタル専門の保険会社）にData Engineerとして転職した旨は以前紹介しました。
また、データウェアハウスとしてSnowflake、またそのリソースのデプロイにTerraformを使っている旨も昨年の記事に書きました。
一方で、データウェアハウスとしてSnowflakeを選んだ理由を書いていたなかったので、今回は選定の経緯や理由を紹介します。
データウェアハウス選定前に行っていた活動（入社後半年くらい）
私が現在在籍している企業は、入社当時設立約 3 年目のスタートアップであり、モバイルアプリで金融商品を販売しています。
私が入社する以前に、初期段階のモバイルアプリと Web アプリはリリースされ、継続的に加入者が増え、商品カテゴリの種類もカテゴリ別の売り上げも着実に増えてきているところでした。そこで中期経営目標達成に向け、より効果的にマーケティング施作を実施して、更なる新規顧客の獲得や既存顧客からの売り上げを拡大するべくデータ分析を強化しようとなり、主にマーケティング部門がリードする形でデータサイエンティストとデータエンジニア（私です）をそれぞれ1名を雇用することになりました。
データエンジニア（私）より数ヶ月先に入社したデータサイエンティストが入った時点では、まだ全データを集約した BI ダッシュボードが存在せず、マーケティング担当者は各種 SaaS に附属のダッシュボードを見たりしている状態でした。これは開発が不要ですが、断片的な情報しか見えず、社内のデータを統合した高度な分析ができません。そこで最初に彼がやったのは以下でした。まだまだデータ系の人材が不足しているため、データサイエンティストと言うよりはデータアナリストよりの仕事かなと思います。
- 社内外のデータの整理および理解。社内の OLTP 系の DB の他、Firebase、Insider、Salesforce Marketing Cloud、Branch.io など各種マーケティング用の SaaS を利用していました。
- マーケティング部門からの依頼に対するアドホックデータ分析
この段階では、もちろんデータエンジニアもいませんので、データの収集はデータサイエンティストが手動もしくは簡単なスクリプトを書いて実施していました。
私が入った後は、まずは Airflow を使って利用可能な全データソースのデータを定期的に集めてきて、データマート（ PostgreSQL のデータベース）にデータをロードするデータパイプラインを構築してデータの収集を自動化しました。私が入社した事前でモバイルアプリとWebアプリは AWS のみを使って運用されてたため、Airflow は ECS Farget に、PostgreSQL データベースは RDS Aurora を使いました。
これでデータの収集が自動化されたので、データサイエンティストに余裕が出たので、彼は以下のような取り組みを実施しました。
- Tabeau Online（SaaS）を導入し、データマートに接続し、主要なKPIを表示するBIダッシュボードを構築。
- 大学生インターン 2 名をデータアナリストとして採用し、コンシューマビジネス部門の依頼に応じて、随時、ダッシュボードを追加。
- 顧客のクラスタ分析など、マーケティング部門のお題に応じて小規模に機械学習および統計解析モデルを構築。この時点では ML パイプラインを自動化する必要性はなかったので、AWS SageMaker などは導入せず。
これでビジネス部門主導で BI を使ったデータ分析が周り始め、ビジネス部門からはお褒めの言葉をいただくようになり、一段落したなという感触はありました。しかし、M&A などをビジネスを急拡大させる方向性が経営層から見える中、顧客数およびデータ量の増大に対してアーキテクチャ上の課題が見えてきました。
例えば、VPC 内にある RDS のデータを抽出し、 Tableu Online にロードするジョブを実行する方法として Tableau Briddge を使っていましたが、その際のデータ抽出・変換用SQLで重たい処理が走っており、RDS や Tableau Briddge の動作が不安定になる現象が起きていました。対症療法として、リソース使用料を監視し、RDS と Tableau Briddge のリソースを追加してパフォーマンスを安定化させることもやっていましたが、これは本質的な解決策ではないと感じました。
そこで 重たいデータ分析ワークロードはデータウェアハウスに委譲し、BI はサマリデータを落として表示するだけの軽い処理に専念することにしました。 RDS AuroraもRDBとしては十分スケーラブルですが、 データ基盤を運用する人が私一人しかいないので RDB のパフォーマンスチューニングするより、前職でも使っていた BigQuery のようなフルマネージドのクラウドデータウェアハウスで分析ワークロードを走らせる方が楽だろうと考え、データウェアハウスを導入することになりました。
データウェアハウス選定の前提条件
と言うことで、CTO および Head of Engineering よりデータウェアハウス選定のミッションを仰せつかったわけですが、重視する条件としては以下が挙がりました。
(1) AWS上で完結する
前職・前々職では、BigQuery を使っていたので、データウェアハウスと言えば、BigQuery 一択でしょう！と思っていましたが、以下の理由により社内的に AWS を優先するという話になっており、BigQuery は真っ先に選定候補から外れました。
- 私が入社した時点で AWS を使ってモバイルアプリと Web アプリが使われていたので、AWS を優先する。
- 経営層がマルチクラウドに対して否定的。
- スタートアップとはいえ保険会社と言うことで、顧客データの扱いには比較的保守的な業界。
- よほどの合理的な理由がない限り、クラウドサービスを跨いてデータを移動させることはやりたくない。
- 経営層は技術屋さんではないので、BigQuery を使いたいのでGCPにしましょうと言う話だけでは通じない。
この時点で AWS で利用できる範囲のサービスにしましょうと言うことになり、以下を候補に絞りました。
- Snowflake
- AWS Redshift
- AWS Athena
- AWS EMR（でHiveなどHadoop系でクラスタ構築）
(2) フルマネージドであり、管理運用コストが低い
データウェアハウスを含め、データ基盤を構築したとして現状でメンテするのは、私一人です。クラスタ管理はビジネス価値に一才貢献しないので、クラスタの管理運用に労力をかける必要があるサービスは NG です。
4つの候補のうち、フルマネージドで管理運用コストが低いのは、Snowflake と AWS Athena です。両方ともコンピューティングリソースはサービス側で管理されており、ジョブを投げれば自動的に実行してくれるため、クラスタを管理する必要がありません。
AWS Redshift は、シンガポールに引っ越しする前（約 2 年前）の会社で別プロジェクトの担当者が利用していましたが、オンプレのデータウェアハウスよりはましでしょうが、BigQuery 以後の時代の人間としては非常に労力がかかる印象を受けました。
（注）ここ数年のアップデートで解決している可能性はあります。根本解決していた場合は訂正いたします。
- クラスタ保守に伴う再起動でサービス停止が発生する（ EC2 と同じでインスタンスを保持する必要があるため）。
- アーキテクチャ上の制限により、並列クエリの処理が不得意。並列性が上がりすぎるとキューが詰まり、処理が遅延する。
- 並列性問題を回避しようとするとデータパイプラインが極端に複雑化する。上記プロジェクトでは Redshift と RDS を併用し、処理結果をやりとりすると言う代替策を取っていたようですが、結果として本質的ではない処理の方が膨れ上がっているようでした。
自分で詳しい技術調査をしたわけではありませんが、その当時の会社の CTO からは「 Redshift にはアーキテクチャ上の欠陥があり、それが直らない限りは並列クエリ問題は解決しないが、アーキテクチャが根本的に変わる可能性は低いのでは？」と伺ってたので、今回も Redshift は避けることにしました。
AWS EMR で Hive や Spark などのクラスタを構築する方法については、オンプレで自前でクラスタを構築・管理することに比べたらましでしょうが、小規模なクラスタでも少なくとも一人は専任でクラスタ管理者が必要になるため、クラウドデータウェアハウスが全盛の時代には割りに合わない選択肢だと思いました。
(3) リソースが自動的にスケールし、パフォーマンスチューニングの労力がかからない
ここで残った選択肢 Snowflake および AWS Athena のうち、どちらがパフォーマンス面で良いか検討することになりました。
ここで、AWS のドキュメンテーションでは Athena （実態は AWS Managed な EMR 上の Presto1）は厳密にはデータウェアハウスではなく、性能を取るなら Redshift を使えとの指摘があり、ここで Athena が脱落しました。
一方で、Snowflake の方は、Virtual Warehouse のインスタンスタイプの変更（スケールアップ）とクラスタサイズの変更（スケールアウト）で性能を拡張できます。また、目的別に Virtual Warehouse を瞬時に作成できるので、負荷分散も簡単です。
(4) 顧客データを扱うため、セキュリティ対策が万全
この時点は選択肢は Snowflake しか残っていませんが、ここで顧客データをどうやって保護するか確認する必要がありました。
プライベートなネットワーク経由のアクセスだけに制限できる
お高めのプランではありますが、Business Critical と言うプランを使うと、自社の AWS アカウントの VPC と Snowflake の AWS アカウントの VPC の間で Private Link を貼ることができます。さらにネットワークポリシーで接続元の IP アドレスの CIDR ブロックを自社の AWS アカウントの VPC のものを設定しておけば、インターネット越しのアクセスをブロックし、VPC 経由でのアクセスのみ受け付けるように制限できます。
さらに自社のネットワークと AWS VPC の間を AWS Direct Connect でつないでおけば、自社のネットワークから AWS VPC を経由して Snowflake にアクセスできるようになります。
（注）Edition ごとの違いはこちらを参照。https://www.snowflake.com/pricing/
End to End の暗号化
こちらも Business Critical で利用できる機能ですが、自動で End to End での経路上の暗号化、ストレージ上での暗号化などをサポートしています。暗号化や鍵の管理の詳細は以下を参照。
動的なデータマスキング
社内で好評だったのが、Enterprise Edition以上で利用できる 動的データマスキングです。
データウェアハウスにデータを投入する際によく困るのが、個人識別情報（Personal Identity Information、略してPII。氏名、市民ID、メールアドレスなど個人を直接的にあるいは間接的に特定できる情報）が含まれている場合の取り扱いです。以前の会社では、PII が含まれている場合はデータウェアハウスに入れる前にデータソース側でマスキングすると言う方針になっていました。
この場合、様々なシステムでマスキングが行われるため、データマスキングを簡単に導入できるようなライブラリやデータ移動時に自動的にマスキングを入れるような共通レイヤーを開発していました。これはこれでかなりの開発ボリュームがあります。また、仮にデータ分析の際にマスキングされる前の情報が必要になった場合でも元のデータが失われているため、データウェアハウスだけでは対処できなくなります。
一方で、Snowflakeの場合、オリジナルのデータをテーブルに保存させておきながら、クエリ時に動的にデータをマスキングすることができます。利用者側が指定するのはマスキングする条件とマスキングする方法です。柔軟な仕組みのため、もしマスキングに漏れがあった場合でも後から追加することもできます。これを自前で作るとなるとかなりの労力は必要になるので、詳しくはこちらを参照ください。https://docs.snowflake.com/en/user-guide/security-column-ddm-intro.html
選定した後に実施したこと（直近3ヶ月ほど）
と言うわけで、2020年の年末ごろに Snowflake の導入が決まり、直近3ヶ月ほどで以下のようなことをしていました。
- 自社の AWS と Snowflake の間で Private Link を接続。プライベートネットワーク接続のみアクセス可にした。
- BIの分析用データベース（RDS Aurora PostgreSQL）に入れていたテーブルを一通り Snowflake 上に作成。
- テーブルなど Snowflake のリソースの作成には、Terraform Provider for Snowflake を使い、Infra as Code およびデプロイ自動化を実現。
- 上記テーブルにデータを投入するジョブの作成。Airflow から SQL を実行してロードするパターン、Snowpipe で S3 上のファイルをイベント駆動で取り込むパターンをそれぞれ実装した。
- 現在は SSO を設定中。
なお、現在、RDS を利用して稼働中のワークロードはそのままにして、新規ものから Snowflake を利用する予定でいます。よってまだプロダクションで稼働しているワークロードは今のところありません。
使ってみての所感
最後に3ヶ月ほど使ってみて感じたことをいくつか述べたいと思います。
良いと感じた点は以下です。総じて良いサービスだと思います。
- フルマネージドと言うことで、クラスタの管理や運用の業務が一切不要なので、非常に楽。
- Virtual Warehouse をプロジェクトごとに作成できるので、負荷分散やプロジェクトごとの予算管理が簡単に行える点がありがたい。
- データをセキュアに扱うための機能が豊富にあるので、安心感がある（Private Link、end to end暗号化、データマスキング、多様な認証方式）。
一方で BigQuery と比較して気になる点は以下です。
- マルチクラウド対応のサービスであるためか、BigQuery のようにクラウドサービスに組み込まれたサービスと比較すると、自社の AWS との連携部分が非常に複雑に感じる。Stage、Pipe など内部詳細を意識せずに使えるようにしてほしい。
- パフォーマンスが十分出て、コスト管理が簡単であれば、 Virtual Warehouse を管理する必要性を全く感じないので、管理不要にしてほしい。中身を完全にブラックボックスしてジョブを投げればリソースを自動スケールして結果を出せ、プロジェクト単位でコスト管理できれば OK。
以上です。データウェアハウスを選定している方、これから使い始める方にとって参考になれば幸いです。
Discussion