この記事は NewsPicks Advent Calendar 2024 の6日目の記事です。

ソーシャル経済メディア「NewsPicks」の中村です。最近はデータ基盤の開発運用、データアナリストのサポート、LLM活用等をやっています。

現在、NewsPicksではデータウェアハウスとして長年利用してきたAmazon RedshiftからSnowflakeへの移行を進めています。まだ移行作業の途上ではありますが、完了の目処が立ったので、なぜデータ基盤の移行を行なっているのか、どのように移行計画を立てたか、実際に移行作業を進めてみてどうだったか等を紹介したいと思います。データ基盤を運用している方、データウェアハウスの比較検討をされている方などの参考になれば幸いです。

なぜデータウェアハウスを移行するのか

Redshiftのパフォーマンスとコストの問題

まず、NewsPicksの従来のデータ基盤は下図のような構成になっています（省略している部分もあります）。利用している具体的なツールやサービスはともかく、概念的には生データ（Raw data bucket） → 共通前処理済データ（Normalized data bucket） → ユースケース別のデータ（Redshift, Data mart bucket）というデータの流れになっており、よくある構成かと思います。

このうち、Redshiftが関わる処理は以下の通りです。

Digdagによる定期バッチ処理
- データロード
- データ加工処理
- データアンロード
BIツールからのアドホッククエリ（Metabase、Tableau等）
その他のシステムからのアクセス（図では省略）

おおむね安定稼働しているシステムですが、長年の利用によりバッチ処理の数もBIツールからのクエリの量も増大し、Redshiftの負荷が常時高くなっていました。そのため以下のような課題を抱えていました。

BIツールのクエリが遅く、分析者体験が悪い：BIもバッチも同一のRedshiftクラスター上でクエリが実行されるため、重いバッチが実行されている時間帯はなかなかBIツール上でチャートが表示されず、ストレスとなっていました。多数のKPIのチャートを表示するダッシュボード等では、すべてのチャートが表示されるまで数分待ちということもありました。
クリティカルな処理に影響する可能性があるため、うかつに処理を追加できない：データ基盤の主な用途は社内のデータ分析であり、可用性等のサービスレベルについて厳格な目標は定めていません。しかしバッチ処理基盤としての使いやすさから、加工したデータをNewsPicksの本番アプリケーション用DBに書き戻すようなユースケースが徐々に増えていました。また、社内向けのユースケースであってもリアルタイムに近いデータ更新が要求されるものもあります。たとえばプッシュ通知すべきニュースを決める業務判断に利用されるダッシュボード等です。このように、NewsPicksのサービス提供にとってクリティカルな処理とそうでもない処理が同一のRedshiftクラスター上で動いているため、うかつに重いクエリを実行するとクリティカルな処理に影響が出てしまい、障害につながりかねない状態となっていました。

Redshiftにも、クエリの優先順位を調整したりパフォーマンスを改善したりするためにワークロード管理の設定や推奨設定のレコメンド機能等が備わってはいます。しかし残念ながら多少設定を調整しても上記の問題を解消することはできませんでした。

クエリのパフォーマンスを向上させる他のアプローチとして、SQLのコード自体を改善したり、共通データマートを整備したりして、重いクエリが実行される頻度を減らすといったことも考えられます。しかしバッチにせよBIにせよ、これまでに積み重ねられてきたクエリの資産（あるいは負債）は大量であり、どこが本当にボトルネックになっているのか特定するのも困難です。どれくらいの工数をかければどの程度のパフォーマンス改善が得られるのか見積もることも難しいので、このアプローチはあきらめることにしました。

ではあとは何ができるのかと言えば、お金を積むしかありません。つまりRedshiftのクラスターのスペックを上げたり、クリティカルな処理を別のクラスターで動かしたりすればいいのです。しかしここでRedshiftの課金モデルが問題になります。NewsPicksでは1年契約のリザーブドインスタンスを利用しているため、スペックを試しに少し上げてみてパフォーマンスが改善するか見るといったことができません。最低でもクラスターのスペックを一段階上げて1年間コミットする必要があるためかなりのコスト増になります。ここは、計算時間や処理データ量に応じた従量課金であるSnowflakeやBigQueryといった他のデータウェアハウスと比べると見劣りするところです。実際にはRedshiftにもServerlessという従量課金のプランがあるのですが、Redshift Serverlessから既存のRedshiftクラスターのデータを直接クエリすることはできないため*1、Redshift Serverlessを導入するのも別のデータウェアハウス製品に移行するのもかかる労力はあまり変わらないのではないかと思われました。

結局、データ基盤を改善するために何をするにせよコストの増加は避けられないし労力も変わらなそうなので、だったらこの際どのデータウェアハウスが良いのかゼロから考え直してもいいのではないか、というわけです。

生成AIと分析者体験

もうひとつデータウェアハウス移行のきっかけとなった出来事として、生成AI、特にLLMの流行があります。移行を検討し始めた当時、SnowflakeやBigQuery (GCP) では、データ分析や機械学習に関わるサービスと生成AIの統合について次々と新機能が発表されていました。データ分析の生産性向上という点では、LLMが適切な分析クエリを生成してくれるようなサービスは特に魅力的です。一方、Redshift (AWS) はそうした面においてやや出遅れているように感じられました*2。

また、生成AIを抜きにしてもSnowflakeやBigQueryの方が分析者や開発者にとって使いやすい高レイヤーのサービスが充実しているようにも思われました。たとえばSnowflakeであれば分析や可視化のためにNotebookやStreamlitのような便利なツールを手軽に使えます。GoogleもColaboratoryで無料のNotebookが使えますし、Looker Studioという無料のBIツールもあります。BigQueryであればGoogleスプレッドシートとの連携等も容易です。もちろんAWSにもSageMakerがあり、その中にNotebook等々もあり、我々も活用はしていたのですが、データ分析に関わるメンバーが誰でも簡単に使えるという状態にはなっていませんでした。

総じて、データウェアハウスの主要ベンダーに対して以下のような印象を持っていました。

AWSにも分析に便利なパーツは揃っているが、本当に誰でも使えるようにするにはそれなりに自前で繋ぎ込みをする必要がある
Snowflakeはデータウェアハウスを中心にして分析や機械学習に必要なサービスが統合されており、使いやすそう
Googleエコシステムにどっぷり浸かれるならBigQuery最強

NewsPicksにはデータエンジニアリングやデータ分析専任のメンバーというのはあまりおらず、データパイプラインの開発やデータ分析は、様々なチームの分析をしたい人とエンジニアが協力して分散的に行われることが普通でした。そのため、少ない労力で生産性の高いデータ基盤を提供し、改善していけることが重要です。

もともとそのような状況だったところに、生成AI等によってデータ分析や機械学習システム開発の生産性を高められそうな時代がやってきたわけなので、データウェアハウスの移行を考えることは自然な選択肢となりました。

Snowflake vs BigQuery

さて、Redshiftから移行することは決めたので、次はどこに移行するかを決める必要がありました。といってもすでにここまでの話で分かる通り、SnowflakeとBigQueryを比較検討してSnowflakeに決めたというのが結論です。

SnowflakeとBigQueryはクラウドデータウェアハウスのトップシェアサービスであり、公開されている事例や技術情報も多いので、この2つに移行先候補を絞ることに特に迷いはありませんでした。したがって、あとはどちらが我々が抱えている課題をよりよく解決できるかが焦点となります。

まずパフォーマンスとコストについてです。すでに少し触れましたが、SnowflakeもBigQueryもコンピュートとストレージが分離されたアーキテクチャとなっており、課金モデルも基本的には計算時間または処理データ量に対する従量課金なので、十分なコストをかけてコンピュートを増やせば必要なパフォーマンスが得られることは特に心配していませんでした。実際、我々のバッチのなかでも特に複雑なもの、重いものをいくつか動かして検証してみましたが、どちらでも十分なパフォーマンスが得られました。

すると大事になってくるのはコストの方です。課金モデルが異なるため、Redshiftで実行しているすべての処理を移行したときにどのくらいコストがかかるのか精緻に見積もるのは難しいのですが、大雑把な見積もりではSnowflakeもBigQueryでもそれほど料金は変わらなそうだという結論になりました。そのため、移行した後にコスト最適化を行いやすそうのはどちらかという観点で比較を行いました。Snowflakeのコンピュートはウェアハウスという単位で提供されており、スペックが倍のウェアハウスを使うと料金も倍という、極めてシンプルな課金モデルになっています。BigQueryはかつては処理データ量に応じた従量課金でしたが、現在は計算時間（スロット時間）に応じた課金モデルが主流になっています（二つの課金モデルを組み合わせて使うこともできます）。結局どちらでもコンピュートのスペックと計算時間に応じた従量課金が選べるので差はないといえばないのですが、Snowflakeの方が完全にシンプルな課金モデルに振り切っているので、少人数で運用していく上ではこちらの方が良いように思われました。ウェアハウスのスペックと数を調整してコストを下げられなければもう他に調整できる余地がないので、効果の出ないコスト最適化に工数をかけてしまうようなことが防げると考えたのです。

次に生成AIと分析者体験です。SnowflakeとBigQueryのどちらもサービスと生成AIの統合を進めているとはいえ、それらのベースとなるAIの基盤モデル開発力でいえばGoogleの方に軍配が上がるのは明らかです。とはいえ、移行検討当時もすでにMetaのLlamaのようなオープンで高性能なモデルは存在していましたし、モデルベンダーと様々なサービスとの提携が進んでいくであろうことも予想がつきました*3。また、データ分析クエリ生成のような用途では、テーブルのスキーマ情報やメタデータを用いたRAG (Retrieval Augmented Generation）的な技術が基盤モデルの性能以上に重要であろうことも想像できました。メタデータの整備などは結局自分たちでやる必要があるでしょうから、その意味ではどちらのデータウェアハウスを選んでもあまり差はないように思われました。

まとめると、

パフォーマンスとコスト管理の点では、Snowflakeがやや有利
生成AIと分析者体験の点では、BigQueryがやや有利

ということで、我々の抱えている課題の解決という点ではどちらかに決めがたい状況となってしまいました。

そこで他にもいくつかの観点から比較を行ったのですが、結局ひとつの決め手となったのはSnowflakeがマルチクラウド対応なのでAWS上で運用できるという点です。NewsPicksのアプリケーションのほとんどはAWS上で構築・運用されており、ノウハウが蓄積されています。ここでもやはり、少人数でデータ基盤を運用していくことを考えると、慣れ親しんでいるインフラに寄せた方が良いと判断しました。

こうしてSnowflakeへの移行を決めたのですが、すでにだいぶ話が長くなってしまいました。具体的な移行計画や、移行作業の実際については続編で紹介できればと思います。

*1:Redshift Serverlessと既存のクラスターでデータを共有する仕組みも存在しますが、色々と制限があります。

*2:現在ではAWSもAmazon Qというブランドで様々なサービスとLLMが統合されてきており、つい先日にはAmazon Novaという最高クラスの性能を持つLLMの開発力があることも示されたので、差はあまりなくなっているかもしれません。

*3:実際、最近になってSnowflakeとAnthropicの提携が発表されました。