JMDC TECH BLOG

JMDCのエンジニアブログです

トップ > 年間数千万円のコスト削減が見えた。RedshiftからSnowflakeへの移行PoCをやってみた話

年間数千万円のコスト削減が見えた。RedshiftからSnowflakeへの移行PoCをやってみた話

こんにちは。株式会社JMDC プロダクト開発部の三井です。

今年、JMDCではアドベントカレンダーに参加しています。 qiita.com

本記事は、JMDC Advent Calendar 2025 15日目の記事です。

はじめに

私が関わっているプロダクトでは現在、DWH基盤をRedshiftからSnowflakeへ移行する検討をしております。

上期にPoCを実施してみたのでその活動を振り返ってみようと思います。

ざっくりまとめ

  • 「Redshiftのコストが高い」という課題を解決するため、Snowflake移行のPoCを実施してみた
  • 検証の結果、データロード速度は最大67%向上。性能面でも十分な手応えあり
  • 従量課金モデルへの移行で年間約2,800万円のコスト削減が見込めることが分かった

Snowflakeとは

Snowflakeとは、クラウド上で提供されるデータプラットフォームです。一般的に「クラウドデータウェアハウス（DWH）」として知られていますが、 単なるDWHにとどまらず、データレイク、データエンジニアリング、データサイエンス、データ共有など、データ活用に必要な機能を包括的に提供するSaaSです。

特徴としては「ストレージ」と「コンピュート」を完全に分離したアーキテクチャを採用している点です。

Snowflake key concepts and architecture | Snowflake Documentation

従来のデータウェアハウス（DWH）では、ストレージとコンピュートが密結合していることが多く、以下のような問題がありました。

  • 大量のデータを読み込む処理（ETL）と、分析クエリが同時に実行されると、お互いがリソースを奪い合い、処理速度が低下する（リソースの競合）
  • どちらか一方の性能だけを上げることが難しく、コスト効率が悪かった

Snowflakeではストレージ層でデータはすべてクラウドストレージ（Amazon S3やAzure Blob Storageなど）に一元的に保存されます。

コンピュート層では「仮想ウェアハウス」と呼ばれる独立したコンピュート・クラスター（CPUやメモリ）が、ストレージ層のデータにアクセスして処理を実行します。

この分離により、以下のような大きなメリットを得ることが可能となりました。

  • リソースの競合がない：例えば、「データ分析チーム用」「データサイエンスチーム用」「ETL処理用」と、目的ごとに別々の仮想ウェアハウス（コンピュート）を割り当てることができます。それぞれが独立しているため、あるチームが重い処理を実行しても、他のチームのクエリ速度に影響を与えません。
  • 高いスケーラビリティ：処理が重くなった時だけ、仮想ウェアハウスのサイズを瞬時に大きく（スケールアップ）したり、数を増やしたり（スケールアウト）できます。処理が終わればすぐに縮小・停止できるため、無駄なコストがかかりません。
  • コスト効率：ストレージは安価なままデータを無制限に保存でき、コンピュートは使った分だけ（秒単位）の従量課金となります。

その他の主な特徴として、マルチクラウド対応やゼロコピークローン、セキュアなデータ共有や運用負荷の軽減といったものもあり、多くの企業でデータ基盤の中核として採用されています。

現状の課題

私が現在関わっているプロダクトではDWHとしてAWSのRedshiftを採用しており、以下の課題があります。

  • 高価なインフラコスト
    • リクエストに応じてクラスタが即座に起動しないため未使用時もクラスタの常時起動が必要
    • クラスタが柔軟にスケールせず常に高価なインスタンスサイズでの処理が必要

クラスタの常時起動が必要なため、インフラコストが高くなり、コスト効率が悪い形になっています。

Snowflakeであればストレージは安価なままデータを無制限に保存でき、コンピュートは使った分だけの従量課金にできるので、コスト効率を大幅に向上できると考え、白羽の矢が立ちました。

PoCを実際にやってみた

PoCを実施するにあたって、以下を検証項目として置きました。

  • クラスタを自動起動・停止するSnowflakeによってコスト削減が可能かを検証
    • クラスタサイズを複数検証し、性能基準を達成する適切なサイズを選定
    • Redshiftの実稼働時間を計算し、選択したサイズで稼働した場合の年間コストを算出

まずは現行のRedshiftで実行されているSQLの処理時間をクエリタイプ毎に計測し、

1ヵ月あたり約257.21時間、1日あたり約9.2時間の稼働を確認しました。

また、本番・開発環境のRedshiftが1日24時間稼働し続けた場合、システムコストは年間約4,500万円掛かると試算しました。

次にアプリケーションの各機能やデータロードで実行されているSQLを、RedshiftとSnowflakeで実行し比較を行いました。

Snowflakeではクエリ処理を行うコンピュート層の仮想ウェアハウスの性能をSmall, Medium, Largeといった形でサイズを指定することができます。

PoCではRedshiftをra3.16xlarge、SnowflakeをMedium、Large、X-Largeで設定し比較を行いました。

実際の比較表

比較表より、下記の結果を得ることができました。

  • RedshiftとMediumの速度比較
    • データロード(COPY)：35%改善
    • アプリケーション機能：8%悪化
  • RedshiftとLargeの速度比較
    • データロード(COPY)：67%改善
    • アプリケーション機能：30%改善

上記より、SnowflakeのウェアハウスサイズとしてはLargeを採用する方向となりました。

X-Largeについてはデータロードの性能改善はかなりあったものの、アプリケーション機能においてはLargeと同程度だったため、コストパフォーマンス的にはベストではないという結論でした。

しかし、例えばデータロードはX-Large、アプリケーション機能はLargeで実施する、インシデント発生時のリカバリ対応でX-Largeを一時的に利用するなど使い分けが可能ですので、運用しつつコストと性能を見て検討していきたいと考えています。

SnowflakeでウェアハウスサイズをLargeにした場合、SQLの処理時間をクエリタイプ毎に試算した結果、1日あたりの稼働時間は約5.9時間となりました。 これにより、仮にSnowflakeで1日5.9時間稼働した場合、年間約1,646万円のシステムコストになるという試算を得ることができました。

想定される定量・定性効果

PoCの結果より、以下の定量・定性的な効果が見込めることがわかりました。

  • 定量的には

    • トータルコストの改善 - 合計削減金額：年間約3,520万円相当
      • 年間使用料：年間約2,800万円削減
      • 保守運用コスト：約36%の工数削減、年間約720万円相当

  • 定性的には

    • 将来のリスク・コスト回避
      • データロード時間の超過：データロード時間が始業時間に食い込むリスクのあるデータがあるが、Snowflakeの採用で遅延によるユーザー利用への悪影響を回避可能
      • パフォーマンスの悪化：Snowflakeの採用により、今後のさらなる同時利用ユーザー数の増加や、突発的な負荷増大が発生しても効率的に対応可能
      • システム拡張時の工数・コスト：今後システムを拡張する際に、Redshiftでは必要なプロビジョニングや、各種チューニング作業が大幅に効率化

実際にやってみて

実際にPoCをやってみて、下記の知見を得ることができました。

  • 従量課金制によるコスト最適化

    • サービスの利用状況(平日の日中帯に利用が集中し、夜間や休日は利用が少ない)を考慮すると、従量課金制は大きなメリットであった
    • クエリ実行時間に対してのみ費用が発生するため、利用が少ない時間帯の不要なコストをほぼゼロにできる。この仕組みにより、全体的な運用コストの大幅な削減が期待できる

  • ウェアハウスのスケーリングによるパフォーマンスとコスト削減の両立

    • ワークロードの変動に応じて、ウェアハウスのサイズ(コンピュートリソース)を柔軟にスケールアップ・ダウンできるのは、非常に優れた機能だと感じた
    • 例えば、データの大量ロードや複雑なクエリ実行時のみリソースを拡張し、それ以外の時間帯は縮小するといった運用が可能になる
    • これにより、必要な時に必要な分だけリソースを利用し、パフォーマンスを維持しながら最適なコストパフォーマンスでの運用を実現できる

  • リソースの分離によるユーザー体験の向上

    • Redshiftではクラスター単位でのリソース共有が一般的だったが、Snowflakeではウェアハウスごとにリソースを完全に分離できる
    • これにより、特定のユーザーが高負荷なクエリを伴う機能を実行したとしても、他のユーザーが実行する機能のパフォーマンスに影響を与えることがなく、常にスムーズな環境が提供されることで、ユーザーの生産性向上に大きく貢献すると考えられる

今後について

PoCで得られた知見を活かして、本格的に移行を進めていく予定です。

まだまだ道のりは長いですが、移行が完了したらまた記事を書いてみたいと思います。

ここまで読んでいただき、ありがとうございました。

導入を考えている方や興味がある方に少しでも参考になったら嬉しいです。

明日16日目は、金さんによる「Glueジョブ開発の実践：PySpark + Jupyterによる大量データ変換と単体テスト」です。お楽しみに！

JMDCでは、ヘルスケア領域の課題解決に一緒に取り組んでいただける方を積極採用中です！フロントエンド /バックエンド/ データベースエンジニア等、様々なポジションで募集をしています。詳細は下記の募集一覧からご確認ください。 hrmos.co まずはカジュアルにJMDCメンバーと話してみたい／経験が活かせそうなポジションの話を聞いてみたい等ございましたら、下記よりエントリーいただけますと幸いです。 hrmos.co ★最新記事のお知らせはぜひ X（Twitter）、またはBlueskyをご覧ください！ twitter.com bsky.app