SnowflakeとRedshiftの比較検証

by Kurochan

Slide 1

Slide 1 text

SnowﬂakeとRedshiftの⽐較 CA.io # Snowﬂake 株式会社サイバーエージェント AI事業本部  黒崎優太 (@kuro_m )

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

本⽇お話すること • RedshiftをDWHに採⽤している広告配信事業者が  Snowﬂakeを検証してみてどうだったのかについてお話します • ⼀概にどちらの⽅が優れている、といったような結論は出しません

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

現状のDWH周辺の環境紹介

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

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

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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

Slide 15

Slide 15 text

RedshiftとSnowﬂakeの⽐較

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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負荷が⼤きく、  クラスタの計算能⼒を使い切れていない

Slide 19

Slide 19 text

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

Slide 20

Slide 20 text

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

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

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

Slide 23

Slide 23 text

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

Slide 24

Slide 24 text

Slide 25

Slide 25 text

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

Slide 26

Slide 26 text

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

Slide 27

Slide 27 text

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

Slide 28

Slide 28 text

検証でやったこと

Slide 29

Slide 29 text

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

Slide 30

Slide 30 text

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

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >= ... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、  ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

Work Sheets

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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

Slide 40

Slide 40 text

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

Slide 41

Slide 41 text

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

Slide 42

Slide 42 text

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

Slide 43

Slide 43 text

まとめ • Redshiftを使っているプロダクトでSnowﬂakeを検証してみました • 広告配信プラットフォームでのログ分析において欲しい機能は  ⼀通り揃っていそうでした • DWHの導⼊や移⾏を考えられている⽅にとって候補になり得るプロダクトでした

Slide 44

Slide 44 text

質疑応答