Upgrade to Pro — share decks privately, control downloads, hide ads and more …

SnowflakeとRedshiftの比較検証

 SnowflakeとRedshiftの比較検証

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

Kurochan

July 28, 2020
Tweet

More Decks by Kurochan

Other Decks in Technology

Transcript

  1. SnowflakeとRedshiftの⽐較
    CA.io # Snowflake
    株式会社サイバーエージェント AI事業本部

    黒崎 優太 (@kuro_m )

    View Slide

  2. 黒崎 優太
    • 新卒⼊社6年⽬
    • 広告配信プラットフォーム事業の開発責任者
    • 業務は Scala + AWSが中⼼
    • イラスト図解でよくわかる ITインフラの基礎知識
    •書きました
    • ⾃宅サーバとかが好きです
    @kuro_m @kurochan

    View Slide

  3. 本⽇お話すること
    • RedshiftをDWHに採⽤している広告配信事業者が

    Snowflakeを検証してみてどうだったのかについてお話します
    • ⼀概にどちらの⽅が優れている、といったような結論は出しません

    View Slide

  4. Contents
    • (普段業務で開発しているものの紹介)
    • 現状のDWH周辺の環境紹介
    • RedshiftとSnowflakeの違い
    • 検証でやったこと
    • 検証してわかったこと
    • 質疑応答

    View Slide

  5. 開発しているシステム
    • Dynamic Retargeting for Games
    •スマホ向けリターゲティング広告配信プラットフォーム
    •トップセールス @⽇本のスマホゲームの中でも⾼いシェア
    •⽇本、アメリカを中⼼に数カ国に配信
    •ユーザごとに最適化した広告を配信
    https://www.dynalyst.io

    View Slide

  6. 開発しているシステム概況
    • ⼊札リクエスト量: 数⼗万リクエスト / 秒
    数千億リクエスト/⽉
    • ⼊札トラフィック: 約8Gbps
    • レスポンスタイム: 100ms以内
    • ログの量: 数TB / Day(圧縮状態)
    • ALL AWS
    ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD

    View Slide

  7. もっと知りたい⽅は
    • ⽉間数千億リクエストをさばく技術
    https://logmi.jp/tech/articles/

    View Slide

  8. 現状のDWH周辺の環境紹介

    View Slide

  9. Dynalystのデータフロー
    • アプリケーションサーバで発⽣した広告の⼊札や配信、計測といったログがど
    のように扱われているかを紹介します

    View Slide

  10. ログ転送フロー
    • 広告の⼊札や計測のログはすべてKinesis Streamsに流す
    • 拡張性や耐障害性が向上する
    MPHBSDIJWFDPOTVNFS
    BSDIJWF
    ,JOFTJT4USFBNT
    QSPEVDFMPHT
    BQQTFSWFS
    4
    1SPEVDFS 4USFBN $POTVNFS

    View Slide

  11. ログのリアルタイム処理
    • 何かしらのイベントの発⽣後すぐにDBを更新する⽤途
    ECVQEBUFDPOTVNFS
    BSDIJWF
    ,JOFTJT4USFBNT
    QSPEVDFMPHT
    BQQTFSWFS
    1SPEVDFS 4USFBN $POTVNFS
    %ZOBNP%#

    View Slide

  12. 1つのストリームに複数種類のconsumerも設置可能
    %#VQEBUFDPOTVNFS
    MPHBSDIJWFDPOTVNFS
    VQEBUF
    BSDIJWF
    ,JOFTJT4USFBNT
    DPOTVNF
    QSPEVDFMPHT
    BQQTFSWFS
    %ZOBNP%#
    4
    1SPEVDFS 4USFBN $POTVNFS

    View Slide

  13. ログのRedshiftへの取り込み
    • S にログがアップロードされたのをきっかけにRedshiftに継続取り込み
    MPHBSDIJWFDPOTVNFS
    BSDIJWF
    ,JOFTJT4USFBNT
    4
    4USFBN $POTVNFS
    424
    OPUJGZ
    MPHJNQPSUFS
    3FETIJGU
    $01:UBCMFGSPNT
    MPBE

    View Slide

  14. ログの集計
    • ログの量が数TB/day(圧縮状態)
    • 広告の集計処理は複雑になりがち
    • 集計ロジックを⾃前実装したい
    • テストコードが書きたい
    • 分散処理がしたい
    • Apache Spark on Amazon EMR
    • クラスタコンピューティングフレームワーク
    • 分散共有メモリモデル
    • ScalaやPythonで処理が記述できる
    &.3$MVTUFS
    .BTUFS
    4MBWF
    4MBWF
    4MBWF
    4MBWF

    View Slide

  15. RedshiftとSnowflakeの⽐較

    View Slide

  16. Redshiftとは
    • AWSのマネージドサービスであり、PostgreSQL互換なDWH
    • クラスタのノードサイズと台数を選択して利⽤する
    • 最新世代(RA )からコンピューティングとストレージが分離されたため、

    RA の場合はストレージは利⽤した分だけ請求される

    View Slide

  17. DynalystでのRedshiftの活⽤
    • アドホックな分析⽤途
    • PostgreSQL互換なので利⽤できるツールが幅広い
    • 機械学習バッチのデータソース
    • Tableau(BIツール)上での分析や可視化
    • など

    View Slide

  18. 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負荷が⼤きく、

    クラスタの計算能⼒を使い切れていない

    View Slide

  19. 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が発動しっぱなしになってしまいコスト効率がよくなかった

    View Slide

  20. Redshiftの料⾦体系
    • 基本的にはクラスタ課⾦が⼤半を占める
    • クラスタ課⾦
    • ノードのサイズ, 台数 x 利⽤時間
    • リザーブドインスタンス(前払い)が⼀番安いので1〜3年分コミットすることが多いと思われる
    • ストレージ課⾦(RA のみ)
    • スポット課⾦
    • Redshift Spectrum
    • Concurrent Scaling
    • など

    View Slide

  21. Snowflakeとは
    • Snowflake社の⽅からご紹介頂いたので概要は割愛
    • ポイント
    • 計算するノードはShared nothing: スケールアウト可能
    • ストレージはShared Disk: 計算するノードはストレージを持たず、外部ストレージを共有
    • Virtual Warehouse: 時間課⾦でクエリを実⾏するクラスタはすぐ起動できたり停⽌ができる
    • 明確に停⽌時間を設定せずとも、クエリが⾛っていない間はVirtual Warehouseの課⾦を0にすることが可能

    View Slide

  22. データ転送料は?
    • AWSではInboundトラフィックは無料、Outboundトラフィックは有料
    • AWS上で⼤量のデータを扱うプロダクトにとって外部のサービスを使う上で
    データ転送量が問題になりがち
    • 例: 東京リージョンからインターネットに1⽇5TB転送: 約 $9,000/⽉
    • Snowflakeはクラウド事業者とリージョンが選べるので、同⼀リージョン内の
    通信にすることができる
    • AWS TokyoリージョンのS からSnowflakeに転送する料⾦は無料(S のAPI料⾦は発⽣)

    View Slide

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

    View Slide

  24. 最近のニュース

    View Slide

  25. Google、BigQueryをAWSやAzureなどマルチクラウド展開へ、
    「BigQuery Omni」発表。
    https://www.publickey .jp/blog/ /
    googlebigqueryawsazurebigquery_omnigoogle_cloud_next_ onair.html

    View Slide

  26. BigQuery Omni
    • アルファ版のため機能制限など詳細はまだ不明
    • BigQueryのマルチクラウド版
    • BigQuery
    • クエリ課⾦なのが特徴
    • マルチテナント型なのでクラスタなどリソースはあまり意識しなくてよい
    • MLやAutoML Tablesといった機械学習系機能も特徴的
    • AWS含むマルチクラウドで展開されるということは転送料の問題が解決される

    View Slide

  27. RedshiftとSnowflakeとBigQuery Omni
    • ※主観でのざっくりとした⽐較です
    "NB[PO3FETIJGU 4OPXqBLF #JH2VFSZ
    ՝ۚ 7JSUVBM8BSFIPVTF՝ۚ
    ىಈ࣌ؒ
    εέʔϧ
    ΫΤϦΛ౤͛Δ͚࣌ͩසൟʹ
    ىಈͨ͠Γఀࢭ͢Δ
    ༻్΍ඞཁͳੑೳʹԠͯ͡
    8BSFIPVTFΛ࡞ͬͨΓ૿΍ͨ͠Γ͢Δ
    Ϋϥελͷϊʔυ਺มߋΛ͢Δ͔
    $PODVSSFOU4DBMJOH
    ར༻͢Δؒ͸ىಈͨ͠··
    Ϋϥελ՝ۚ ΫΤϦ՝ۚ
    Ϣʔβ͸ؔ༩͠ͳ͍
    ΫΤϦʹԠͯࣗ͡ಈͰϦιʔεׂ౰

    View Slide

  28. 検証でやったこと

    View Slide

  29. 機能検証
    • ひととおりの機能を触ってみました

    View Slide

  30. DB作成〜データのimportまで
    • create database
    • AWSのIAM Role作成
    • S インテグレーション作成
    • AWS IAM Roleの信頼関係の更新
    • ログフォーマット作成
    • External Stageの作成
    • テーブル作成
    • テーブルへS からデータをinsert

    View Slide

  31. 運⽤のしやすさ
    • クラスタのバージョンアップ作業などが不要(基本的にダウンタイムがなさそう)
    • 異常に重いクエリを投げてしまってもコストが増⼤しない
    • Virtual Warehouse課⾦なので起動時間だけ気にしておけばOK
    • ほぼすべての設定がSQLからも操作できて統⼀感がある
    • MySQLやPostgreSQLプロトコルが使えないかわりに
    • Web UIが充実している
    • アダプタやインテグレーションが充実している

    View Slide

  32. 使い勝⼿
    • Redshiftと⽐べたときのSnowflakeのクエリ性能はワークロードの特性によっ
    て違うと思うので検証してみることをおすすめします
    • 簡単な集計で使いそうなJOINやGROUP BYなどを⾏った限りは申し分なかった
    • ある程度まではWarehouseのサイズを上げれば上げるほど実⾏時間が短縮された
    • Warehouseが⽤途別に分けられるので、COPYクエリを同時に多数発⾏してもク
    エリのキューが詰まってクエリが滞留してしまうという事は起きなかった
    • sort keyやdist keyを明⽰的に指定しなくても⾃動でクラスタリングしてくれる

    View Slide

  33. ログのローテーションのしやすさ
    • TBくらいのテーブルに対して2TB分くらいの削除をした
    • DELETE FROM table WHARE logged_at >= ...
    • 数秒でクエリが終了した
    • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、

    ⼤量のデータの削除が楽
    • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。

    View Slide

  34. Snowpipe
    • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル
    タイムに取り込んでくれる仕組み
    • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない
    • 別途Snowpipe代が掛かる
    • 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない
    • 体感的にはそんなに⾼くない
    • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように
    なるまで数分だった

    View Slide

  35. External Tables
    • Redshift SpectrumのようにS など直接スキャンできる
    • S のイベントをきっかけにオブジェクトのインデックス更新ができる
    • Amazon Athenaでいうところの「MSCK REPAIR TABLE」のようなクエリが不要

    View Slide

  36. Work Sheets

    View Slide

  37. Work Sheets
    • 実⾏計画がわかりやすい

    View Slide

  38. Snowsight
    • 新しいUI(preview)
    • 簡単なグラフやダッシュボードの作成はUIで完結してしまうので便利

    View Slide

  39. UDF
    • javascriptでUDFが書ける
    • RedshiftはPythonでUDFが書ける

    View Slide

  40. External Function
    • UDFの拡張版
    • AWS LambdaとHTTP APIが使える

    View Slide

  41. 料⾦の試算
    • 課⾦体系の違いから、⼀概にRedshiftと⽐較するのは難しかった
    • Redshift: どれくらいのリソースが必要か
    • Snowflake: どれくらいのリソースをどのくらいの時間使うのか
    • リソースの使い⽅にメリハリをつければ効率よく使うことができそう
    • お試しであったり、⼩規模な環境であればそれほど費⽤は⾼くならないはずな
    のでとりあえず触ってみることをおすすめします
    • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼

    View Slide

  42. もしもRedshiftから移⾏するとしたら
    • 互換性のあるDWHではないので移⾏計画を⽴てることが重要
    • 移⾏する場合はサポートしてもらえるようです
    • コストの問題から新旧のDWHを同時並⾏させる期間は短くしたい
    • 接続するアプリケーションの対応状況の確認
    • アプリケーション(Scala, Java, Python, Rubyなど)
    • クエリツール(DataGripなど)
    • BIツール(Tableauなど)
    • データの移⾏
    • S にソースになるデータがある場合はそんなに⼤変ではないかも

    View Slide

  43. まとめ
    • Redshiftを使っているプロダクトでSnowflakeを検証してみました
    • 広告配信プラットフォームでのログ分析において欲しい機能は

    ⼀通り揃っていそうでした
    • DWHの導⼊や移⾏を考えられている⽅にとって候補になり得るプロダクトでした

    View Slide

  44. 質疑応答

    View Slide