Lock in $30 Savings on PRO—Offer Ends Soon! ⏳

SnowflakeとRedshiftの比較検証

 SnowflakeとRedshiftの比較検証

300コア近くのRedshiftクラスタを運用している広告配信プロダクトでSnowflakeを検証した結果をご紹介します。

Kurochan

July 28, 2020
Tweet

More Decks by Kurochan

Other Decks in Technology

Transcript

  1. 黒崎 優太 • 新卒⼊社6年⽬ • 広告配信プラットフォーム事業の開発責任者 • 業務は Scala +

    AWSが中⼼ • イラスト図解でよくわかる ITインフラの基礎知識 •書きました • ⾃宅サーバとかが好きです @kuro_m @kurochan
  2. 開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 数千億リクエスト/⽉ • ⼊札トラフィック: 約8Gbps

    • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
  3. ログの集計 • ログの量が数TB/day(圧縮状態) • 広告の集計処理は複雑になりがち • 集計ロジックを⾃前実装したい • テストコードが書きたい •

    分散処理がしたい • Apache Spark on Amazon EMR • クラスタコンピューティングフレームワーク • 分散共有メモリモデル • ScalaやPythonで処理が記述できる &.3$MVTUFS .BTUFS 4MBWF 4MBWF 4MBWF 4MBWF
  4. DynalystのRedshift(今の構成) • ds . xlarge x nodes • vCPU, GB

    RAM, TB HDD x => vCPU, GB RAM, TB HDD • TBくらいのストレージが欲しかったためこの構成を選択(約3年前) • 3年のReserved Instance • コンピューティング資源としてはいくらか余剰が出ている • 1⽇数TB(圧縮状態)くらい取り込んでいるテーブルへのinsert負荷が⼤きく、
 クラスタの計算能⼒を使い切れていない
  5. DynalystのRedshift(更新する場合) • ra . xlarge x nodes • vCPU, GB

    RAM, TB RMS x => vCPU, GB RAM, TB RMS • ds の世代に⽐べて⼤幅にダウンサイジングしてリソースを効率化したい • 従量課⾦のRMS(外部ストレージ): 実際に使った分だけストレージ費⽤が課⾦される • Redshift Spectrum: S 上のCSVやParquetのファイルに対して直接クエリできる • ログの取り込み負荷がないため⼤規模なテーブルのみSpectrumに移⾏する • Concurrent Scaling: 負荷状況に応じて⼀時的にクラスタにノードが追加される • ds 世代でも使えたが、Dynalystの環境ではログの取り込み負荷でキューが詰まった時に
 Concurrent Scalingが発動しっぱなしになってしまいコスト効率がよくなかった
  6. Redshiftの料⾦体系 • 基本的にはクラスタ課⾦が⼤半を占める • クラスタ課⾦ • ノードのサイズ, 台数 x 利⽤時間

    • リザーブドインスタンス(前払い)が⼀番安いので1〜3年分コミットすることが多いと思われる • ストレージ課⾦(RA のみ) • スポット課⾦ • Redshift Spectrum • Concurrent Scaling • など
  7. Snowflakeとは • Snowflake社の⽅からご紹介頂いたので概要は割愛 • ポイント • 計算するノードはShared nothing: スケールアウト可能 •

    ストレージはShared Disk: 計算するノードはストレージを持たず、外部ストレージを共有 • Virtual Warehouse: 時間課⾦でクエリを実⾏するクラスタはすぐ起動できたり停⽌ができる • 明確に停⽌時間を設定せずとも、クエリが⾛っていない間はVirtual Warehouseの課⾦を0にすることが可能
  8. データ転送料は? • AWSではInboundトラフィックは無料、Outboundトラフィックは有料 • AWS上で⼤量のデータを扱うプロダクトにとって外部のサービスを使う上で データ転送量が問題になりがち • 例: 東京リージョンからインターネットに1⽇5TB転送: 約

    $9,000/⽉ • Snowflakeはクラウド事業者とリージョンが選べるので、同⼀リージョン内の 通信にすることができる • AWS TokyoリージョンのS からSnowflakeに転送する料⾦は無料(S のAPI料⾦は発⽣)
  9. RedshiftとSnowflake • Redshift • 顧客がある程度クラスタ管理をする • 細かいワークロード管理ができる • クラスタのリサイズに制約がある •

    Resize: 全データのコピーが⾛る, リサイズ完了までRead Onlyになる • Elastic Resize: データのコピーは⾛らないが変更後ノード数は元サイズの2倍〜1/2のサイズのみ, 数分のクエリ停⽌時間あり • Concurrent Scaling: Read系クエリに関してはクラスタの負荷に応じて⼀時的にノードが追加されるような機能 • Snowflake • 顧客はクラスタの数やサイズの設定をするだけ • 細かいワークロード管理はできない(⽤途ごとにVirtual Warehouseを⽴ててしまう) • クラスタ(Warehouse)のリサイズには制約がない • クエリが⾛っていない間⾃動停⽌させたり、サイズ変更を⾏ってもダウンタイムは発⽣しない
  10. BigQuery Omni • アルファ版のため機能制限など詳細はまだ不明 • BigQueryのマルチクラウド版 • BigQuery • クエリ課⾦なのが特徴

    • マルチテナント型なのでクラスタなどリソースはあまり意識しなくてよい • MLやAutoML Tablesといった機械学習系機能も特徴的 • AWS含むマルチクラウドで展開されるということは転送料の問題が解決される
  11. RedshiftとSnowflakeとBigQuery Omni • ※主観でのざっくりとした⽐較です "NB[PO3FETIJGU 4OPXqBLF #JH2VFSZ ՝ۚ 7JSUVBM8BSFIPVTF՝ۚ ىಈ࣌ؒ

    εέʔϧ ΫΤϦΛ౤͛Δ͚࣌ͩසൟʹ ىಈͨ͠Γఀࢭ͢Δ ༻్΍ඞཁͳੑೳʹԠͯ͡ 8BSFIPVTFΛ࡞ͬͨΓ૿΍ͨ͠Γ͢Δ Ϋϥελͷϊʔυ਺มߋΛ͢Δ͔ $PODVSSFOU4DBMJOH ར༻͢Δؒ͸ىಈͨ͠·· Ϋϥελ՝ۚ ΫΤϦ՝ۚ Ϣʔβ͸ؔ༩͠ͳ͍ ΫΤϦʹԠͯࣗ͡ಈͰϦιʔεׂ౰
  12. DB作成〜データのimportまで • create database • AWSのIAM Role作成 • S インテグレーション作成

    • AWS IAM Roleの信頼関係の更新 • ログフォーマット作成 • External Stageの作成 • テーブル作成 • テーブルへS からデータをinsert
  13. 使い勝⼿ • Redshiftと⽐べたときのSnowflakeのクエリ性能はワークロードの特性によっ て違うと思うので検証してみることをおすすめします • 簡単な集計で使いそうなJOINやGROUP BYなどを⾏った限りは申し分なかった • ある程度まではWarehouseのサイズを上げれば上げるほど実⾏時間が短縮された •

    Warehouseが⽤途別に分けられるので、COPYクエリを同時に多数発⾏してもク エリのキューが詰まってクエリが滞留してしまうという事は起きなかった • sort keyやdist keyを明⽰的に指定しなくても⾃動でクラスタリングしてくれる
  14. ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >=

    ... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、
 ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。
  15. Snowpipe • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル タイムに取り込んでくれる仕組み • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない • 別途Snowpipe代が掛かる

    • 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない • 体感的にはそんなに⾼くない • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように なるまで数分だった
  16. 料⾦の試算 • 課⾦体系の違いから、⼀概にRedshiftと⽐較するのは難しかった • Redshift: どれくらいのリソースが必要か • Snowflake: どれくらいのリソースをどのくらいの時間使うのか •

    リソースの使い⽅にメリハリをつければ効率よく使うことができそう • お試しであったり、⼩規模な環境であればそれほど費⽤は⾼くならないはずな のでとりあえず触ってみることをおすすめします • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼
  17. もしもRedshiftから移⾏するとしたら • 互換性のあるDWHではないので移⾏計画を⽴てることが重要 • 移⾏する場合はサポートしてもらえるようです • コストの問題から新旧のDWHを同時並⾏させる期間は短くしたい • 接続するアプリケーションの対応状況の確認 •

    アプリケーション(Scala, Java, Python, Rubyなど) • クエリツール(DataGripなど) • BIツール(Tableauなど) • データの移⾏ • S にソースになるデータがある場合はそんなに⼤変ではないかも