Amazon Redshiftからの移行で積年の課題を解決

ツール導入前の課題

従来、NewsPicksではAmazon Redshift（以下、Redshift）をデータウェアハウスとして使用していましたが、長年の利用によりバッチジョブやBIツールからクエリの数が増大し、常時負荷が高い状態となっていました。このため、BIツールでのダッシュボード閲覧時や、アドホックな分析等を行う際の体感のレイテンシーが大きくなっており、分析者体験を損なっていました。短期間でクエリやRedshift自体のパフォーマンスチューニングを行うことは難しく、Redshiftのスペックアップも検討しましたが、利用していたRedshiftはサーバーレス版ではなかったため、一段階スペックアップするだけでも大きなコスト増となってしまう見込みでした。

また、当時の世間的なトレンドとして、データ分析や機械学習系のサービスへの生成AIの統合が進んでいました。Redshift及びAWSのサービス全般の特徴として、生成AIを活用するためのパーツは揃っているが、使いやすいツールを作るにはある程度内製でインテグレーションをする必要があるという印象を持っており、より手間をかけずに生成AIと統合されたデータ分析ツールを社内に提供できないだろうかと考えていました。

どのような状態を目指していたか

上記の課題感から、クエリの性能や使いやすい分析ツールといった観点で快適な分析者体験を提供しつつ、柔軟にコストコントロールができるデータウェアハウスの運用体制を作りたいと考えていました。

• BigQuery
• Amazon Redshift Serverless

データウェアハウスの性能を上げつつ大幅なコスト上昇は避けたいという背景から、スケールアップとコスト管理の柔軟性を重視しました。また、生成AI等を活用した分析者体験の向上に寄与する便利な機能が簡単に導入できるか、さらに今後もそうした新機能が迅速に追加されていきそうかどうかも検討のポイントでした。

重要視していた点についてはBigQueryとSnowflakeの両方とも我々の要求を満たせると思われました。しかし、Snowflakeの方が課金モデルが若干わかりやすくコスト管理がしやすそうなこと、またNewsPicksではアプリケーションのインフラとして基本的にAWSを利用しており、マルチクラウド対応でAWS上で運用できるSnowflakeの方がデータ連携の容易さ等の点でメリットがあることから、Snowflakeを導入することに決定しました。

改善したかった課題はどれくらい解決されたか

Snowflakeではクエリごとに使用する計算リソース（ウェアハウス）を分離できるため、要件に応じたスケールアップやスケールダウンは非常に容易になりました。

生成AIについてはLLM関連関数やベクトル検索、Snowflake Copilot（LLMによるクエリ生成）等の機能が頻繁にアップデートされており、今後、これらを活用して分析者体験を向上させていけると考えています。

ただし、コストについては必ずしもRedshiftよりも安価になったわけではありません。Redshiftで稼働していたワークロードをほぼそのままSnowflakeに移行したままの状態では、Redshiftと同程度かそれ以上のコストがかかる想定です。しかし、ワークロードをSnowflakeの課金モデルに適した形に変更していくことで、かなりのコスト削減ができるのではないかと見込んでいます。

Snowflakeはウェアハウスの稼働時間に比例してコストがかかるため、コスト節約のためにはクエリをなるべく低頻度、短時間で実行する必要があります。一方、Redshiftはリザーブドインスタンスを購入して利用していたため、一旦購入してしまえばコスト面でクエリを効率化する動機はあまりありませんでした。どちらかといえばRedshift時代に重視していたのは運用の容易さであり、そのためにテーブルを定期的に洗い替えるバッチ処理が多くなっていました。しかしSnowflakeではテーブルを洗い替えるよりも差分更新にした方が、また、定期バッチによるテーブル更新よりもソースデータの更新に応じたイベント駆動のテーブル更新（Snowpipe等）の方が、コスト的には有利になる可能性が高いです。そのため、今後はこのようなワークロードの変更を行なってコストを削減していこうと考えています。

どのような成果が得られたか

上記のもともと想定していた課題の解決に加えて大きなメリットを感じているのが、SnowflakeがTerraformに対応していることです。

NewsPicksではAWSのインフラ管理にAWS Cloud Development Kit（以下、CDK）を活用しているのですが、CDKはRedshiftのほとんどのリソースに対応していません。特にユーザーやグループ、権限については、最新の状態が容易に把握できるようにコードや設定ファイルで宣言的に管理できることが望ましいのですが、そうした仕組みがないため、内製の権限管理ツールを利用していました。一方、Snowflakeではほとんどのリソースを公式のTerraform providerによって扱えるため、リソースの管理と把握が大変容易になりました。先述の通りAWSのインフラ管理にはもともとCDKを用いていたため、CDK for Terraformを用いてSnowflakeのリソースを管理しています。

導入当時はRedshiftからSnowflakeへのクエリ変換ツールが公式には提供されていなかったため、クエリの書き換えとテストには多くの工数を要しました。Snowflakeは型名や関数名に互換性のためのエイリアスが数多く用意されており、全く書き換えなくても動作するクエリは多いです。しかし名前やシグネチャがRedshiftと同じでも仕様が微妙に異なる場合も多く、クエリ結果のデータチェックは欠かせません。結局、クエリの半自動変換ツールやデータ比較ツール、Redshiftとの違いに関するFAQ等を作成しつつデータウェアハウスの移行作業を行うこととなりました。

現在はSnowConvertという公式のクエリ変換ツールがRedshiftにも対応しているようなので、もっと楽に移行作業ができるかもしれません。

すでにGoogle Cloudを中心としたインフラを構築しているのでない限り、クラウドデータウェアハウスの導入を検討しているのであれば第一に検討すべき選択肢だと思います。

導入時には重視していませんでしたが、Snowpark Container Services等、単なるデータウェアハウスに留まらずSnowflake上でアプリケーション全般を開発、運用できるような機能が揃ってきています。データを活用した社内ツール等を開発する際には汎用のパブリッククラウドよりもSnowflakeを使う方が有利な場面もあると思われるので、今後はこうした機能の利用も検討していきたいです。