視聴動向データの分析基盤を Redshift から Snowflake に乗り換えた話
参考になった
5
株式会社PLAY / maruyama
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名
| ツールの利用開始時期 | 事業形態 |
|---|---|
| 2022年6月 | B to B |
アーキテクチャ
アーキテクチャの意図・工夫
プレイヤーから送信された視聴動向データは、最初に Fargate 上で稼働するアプリケーションによって形が整えられてから、Kinesis Data Streams に取り込まれます。ここでデータは 2 本のストリームに分けられ、一方はそのまま生データとして S3 に保存され、他方は Kinesis Data Analytics（現在は Managed Service for Apache Flink に名称変更）に流すことでリアルタイム分析を行っています。リアルタイム分析用のデータと、バッチ分析用のデータを分けて扱う考え方は「ラムダアーキテクチャ」と呼ばれ、ビッグデータの分野ではよく用いられます。S3 に保存されたデータは Snowpipe により自動的に Snowflake に取り込まれます。お客様が視聴動向レポートの出力を要求したタイミングで、バックエンドである API サーバが Snowflake に対してクエリを実行し、その結果をもとにレポートを表示しています。
導入の背景・解決したかった問題
導入背景
弊社では、2022 年に視聴動向データの分析基盤のリニューアルを実施しました。視聴動向データとは、誰が、いつ、どこで、どの動画を、どんなデバイスで、どのシーンまで見たか、といったようなデータを指します。ユーザーが動画を視聴している間、プレイヤーから定期的に送信されてくるデータを収集、蓄積しておき、事業者がそのデータを集計、分析できるといったサービスを弊社では SaaS として提供しています。
従来の分析基盤は、収集されたデータを蓄積し分析するためのデータウェアハウスに Amazon Redshift を使用していました。しかしながら、長期間の運用によりデータの蓄積量が増加してきたことで Redshift のクエリ応答時間が長くなってきており、今後のスケーラビリティに不安が残る構成となっていました。そのため、Redshift からの乗り換えの検討を始めました。
比較検討したサービス
- Snowflake
- Amazon Redshift
- Amazon Redshift Serverless
- Google BigQuery
比較した軸
- 少ない開発工数で既存システムから移行できること
- 単位コストあたりのクエリ処理性能が優れていること
- 月間あたりのコストが予測可能であること
選定理由
Snowflake は、もともと Oracle 出身者らを中心に創業した Snowflake 社が提供しているデータウェアハウス製品で、2019 年には日本法人も設立されており日本語でのサポートが受けられます。昨今、データウェアハウスの新たな選択肢として注目されており、DevelopersIO にも 2024 年 5 月時点で 800 件を超える記事 が投稿されています。
私たちが新しいデータウェアハウスとして Snowflake を選択した理由は主に以下の 3 つです。
1. S3 からのデータロードが簡単
Snowflake はマルチクラウドで展開されているサービスであり、ユーザーは AWS 上の Snowflake、GCP 上の Snowflake、Azure 上の Snowflake から自分が使いたい環境を選択することができます。弊社のサービスは基本的に AWS 上に構築されているため、AWS 上の Snowflake を選択しました。これにより、データのやりとりが AWS のネットワーク内で完結するため、データの高速なロード＆アンロードが可能になります。
さらに、Snowflake には Snowpipe と呼ばれる強力なデータ取り込み機能があります。これは S3 バケットにファイルを置くことで、ほぼリアルタイムで Snowflake に取り込んでくれるというものです。現在は、Redshift にも auto-copy from Amazon S3 と呼ばれる機能が実装されているため、Redshift でも同じことができるのですが、検討当時はまだこの機能は存在していなかったため、これは Snowflake にしか存在しない画期的な機能でした。この機能のおかげで、データ取り込みの仕組みを既存システムよりも大幅に簡略化することができました。
2. 優れたコストパフォーマンス
今回検証した 4 つのデータウェアハウス製品について、同じクエリを投げたときの処理時間を比較したところ、Redshift よりも Snowflake や BigQuery のほうが費用対効果が高いという結果が得られました。
さらに、Snowflake には 一定時間クエリがないと自動的にリソース（仮想ウェアハウス）が停止される というサーバーレス的な要素もあります。停止している仮想ウェアハウスに対しては課金されませんし、停止中にクエリを投げても 1 秒〜数秒程度で素早く起動して処理されます。この仕組みがあるため、BigQuery を「定額料金」プランで契約するよりも、Snowflake のほうがよりコストを抑えられる可能性が高くなります。
3. 柔軟なキャパシティ管理が可能
Snowflake は Redshift RA3 ノードタイプや Amazon Aurora などと同様に、コンピューティング層とストレージ層が分離されたアーキテクチャとなっています。今回検討しているプロジェクトは、マルチテナント型の SaaS アプリケーションであるため、複数のお客様がひとつのデータベースを共有しています。そのため、一部のお客様が負荷の高い分析クエリを実行している間、その他のお客様が影響を受けてしまう可能性があります。Snowflake では、仮想ウェアハウス（コンピューティング層）を複数用意することで、別の仮想ウェアハウスには影響が及ばないようにできるため、高負荷の分析を行うお客様には個別の仮想ウェアハウスを割り当てることで、それ以外のお客様への影響を抑えることができます。
導入の成果
Snowflake に乗り換えたことで、これまで時間がかかっていたクエリが短時間で終わるようになり、課題となっていたパフォーマンスやスケーラビリティの問題を解決することができました。また、これまでパフォーマンスチューニングなどに割かれていた時間が、新機能の開発に充てられるようになり、エンジニアがより生産的な活動に専念できるようになったことも重要な成果だと考えています。
導入に向けた社内への説明
上長・チームへの説明
当時のプロダクトが抱えていた課題点と、それを解決するためのデータウェアハウス製品として Snowflake が適当であると判断した 3 つの理由（上述した通り）を提案資料にまとめ、開発グループの定例会議で上長を含むメンバーに対して説明しました。今回のリニューアルでは、実施前に比べてコストはやや増える見込みだったのですが、そのデメリットを上回るほどの性能改善が見込めたことから、特に異議はなく全会一致での導入が決まりました。
活用方法
よく使う機能
- 仮想ウェアハウスによる視聴動向データへのクエリ
- Snowpipe を利用した Amazon S3 からの自動ロード
- タスク機能によるストアドプロシージャの定期実行
ツールの良い点
Snowflake の本番運用を開始してから 2 年ほど経ちますが、特にトラブルもなく安定稼働しています。また、Snowflake では毎週のようにアップデートが行われていますが、その中には性能改善のアップデートも含まれており、何もしなくても勝手にクエリが高速化していることもあり、これが地味に嬉しいポイントだったりします。
ツールの課題点
2024 年 5 月現在、日本国内の Google Cloud リージョンでは Snowflake がホストされていないため、Google Cloud の東京リージョンで動作するシステムと連携する場合はレイテンシについて検討する必要があるかもしれません。AWS であれば東京リージョンで Snowflake が利用可能です。
株式会社PLAY / maruyama
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名
よく見られているレビュー
株式会社PLAY / maruyama
テックリード / テックリード / 従業員規模: 101名〜300名 / エンジニア組織: 101名〜300名
レビューしているツール
目次
- アーキテクチャ
- 導入の背景・解決したかった問題
- 活用方法