SnowflakeとRedshiftの比較検証

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

Transcript

1. SnowflakeとRedshiftの⽐較 CA.io # Snowflake 株式会社サイバーエージェント AI事業本部
 黒崎 優太 (@kuro_m )
2. 黒崎 優太 • 新卒⼊社6年⽬ • 広告配信プラットフォーム事業の開発責任者 • 業務は Scala + AWSが中⼼ • イラスト図解でよくわかる ITインフラの基礎知識 •書きました • ⾃宅サーバとかが好きです @kuro_m @kurochan
3. 本⽇お話すること • RedshiftをDWHに採⽤している広告配信事業者が
 Snowflakeを検証してみてどうだったのかについてお話します • ⼀概にどちらの⽅が優れている、といったような結論は出しません
4. Contents • (普段業務で開発しているものの紹介) • 現状のDWH周辺の環境紹介 • RedshiftとSnowflakeの違い • 検証でやったこと • 検証してわかったこと • 質疑応答
5. 開発しているシステム • Dynamic Retargeting for Games •スマホ向けリターゲティング広告配信プラットフォーム •トップセールス @⽇本のスマホゲームの中でも⾼いシェア •⽇本、アメリカを中⼼に数カ国に配信 •ユーザごとに最適化した広告を配信 https://www.dynalyst.io
6. 開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 数千億リクエスト/⽉ • ⼊札トラフィック: 約8Gbps • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
7. もっと知りたい⽅は • ⽉間数千億リクエストをさばく技術 https://logmi.jp/tech/articles/
8. 現状のDWH周辺の環境紹介
9. Dynalystのデータフロー • アプリケーションサーバで発⽣した広告の⼊札や配信、計測といったログがど のように扱われているかを紹介します
10. ログ転送フロー • 広告の⼊札や計測のログはすべてKinesis Streamsに流す • 拡張性や耐障害性が向上する MPH
    BSDIJWF
    DPOTVNFS BSDIJWF ,JOFTJT
    4USFBNT QSPEVDF
    MPHT BQQ
    TFSWFS 4 1SPEVDFS 4USFBN $POTVNFS
11. ログのリアルタイム処理 • 何かしらのイベントの発⽣後すぐにDBを更新する⽤途 EC
    VQEBUF
    DPOTVNFS BSDIJWF ,JOFTJT
    4USFBNT QSPEVDF
    MPHT BQQ
    TFSWFS 1SPEVDFS 4USFBN $POTVNFS %ZOBNP%#
12. 1つのストリームに複数種類のconsumerも設置可能 %#
    VQEBUF
    DPOTVNFS MPH
    BSDIJWF
    DPOTVNFS VQEBUF BSDIJWF ,JOFTJT
    4USFBNT DPOTVNF QSPEVDF
    MPHT BQQ
    TFSWFS %ZOBNP%# 4 1SPEVDFS 4USFBN $POTVNFS
13. ログのRedshiftへの取り込み • S にログがアップロードされたのをきっかけにRedshiftに継続取り込み MPH
    BSDIJWF
    DPOTVNFS BSDIJWF ,JOFTJT
    4USFBNT 4 4USFBN $POTVNFS 424 OPUJGZ MPH
    JNQPSUFS 3FETIJGU $01:
    UBCMF
    GSPN
    T MPBE
14. ログの集計 • ログの量が数TB/day(圧縮状態) • 広告の集計処理は複雑になりがち • 集計ロジックを⾃前実装したい • テストコードが書きたい • 分散処理がしたい • Apache Spark on Amazon EMR • クラスタコンピューティングフレームワーク • 分散共有メモリモデル • ScalaやPythonで処理が記述できる &.3
    $MVTUFS .BTUFS 4MBWF 4MBWF 4MBWF 4MBWF
15. RedshiftとSnowflakeの⽐較
16. Redshiftとは • AWSのマネージドサービスであり、PostgreSQL互換なDWH • クラスタのノードサイズと台数を選択して利⽤する • 最新世代(RA )からコンピューティングとストレージが分離されたため、
 RA の場合はストレージは利⽤した分だけ請求される
17. DynalystでのRedshiftの活⽤ • アドホックな分析⽤途 • PostgreSQL互換なので利⽤できるツールが幅広い • 機械学習バッチのデータソース • Tableau(BIツール)上での分析や可視化 • など
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負荷が⼤きく、
 クラスタの計算能⼒を使い切れていない
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が発動しっぱなしになってしまいコスト効率がよくなかった
20. Redshiftの料⾦体系 • 基本的にはクラスタ課⾦が⼤半を占める • クラスタ課⾦ • ノードのサイズ, 台数 x 利⽤時間 • リザーブドインスタンス(前払い)が⼀番安いので1〜3年分コミットすることが多いと思われる • ストレージ課⾦(RA のみ) • スポット課⾦ • Redshift Spectrum • Concurrent Scaling • など
21. Snowflakeとは • Snowflake社の⽅からご紹介頂いたので概要は割愛 • ポイント • 計算するノードはShared nothing: スケールアウト可能 • ストレージはShared Disk: 計算するノードはストレージを持たず、外部ストレージを共有 • Virtual Warehouse: 時間課⾦でクエリを実⾏するクラスタはすぐ起動できたり停⽌ができる • 明確に停⽌時間を設定せずとも、クエリが⾛っていない間はVirtual Warehouseの課⾦を0にすることが可能
22. データ転送料は？ • AWSではInboundトラフィックは無料、Outboundトラフィックは有料 • AWS上で⼤量のデータを扱うプロダクトにとって外部のサービスを使う上で データ転送量が問題になりがち • 例: 東京リージョンからインターネットに1⽇5TB転送: 約 $9,000/⽉ • Snowflakeはクラウド事業者とリージョンが選べるので、同⼀リージョン内の 通信にすることができる • AWS TokyoリージョンのS からSnowflakeに転送する料⾦は無料(S のAPI料⾦は発⽣)
23. RedshiftとSnowflake • Redshift • 顧客がある程度クラスタ管理をする • 細かいワークロード管理ができる • クラスタのリサイズに制約がある • Resize: 全データのコピーが⾛る, リサイズ完了までRead Onlyになる • Elastic Resize: データのコピーは⾛らないが変更後ノード数は元サイズの2倍〜1/2のサイズのみ, 数分のクエリ停⽌時間あり • Concurrent Scaling: Read系クエリに関してはクラスタの負荷に応じて⼀時的にノードが追加されるような機能 • Snowflake • 顧客はクラスタの数やサイズの設定をするだけ • 細かいワークロード管理はできない(⽤途ごとにVirtual Warehouseを⽴ててしまう) • クラスタ(Warehouse)のリサイズには制約がない • クエリが⾛っていない間⾃動停⽌させたり、サイズ変更を⾏ってもダウンタイムは発⽣しない
24. 最近のニュース
25. Google、BigQueryをAWSやAzureなどマルチクラウド展開へ、 「BigQuery Omni」発表。 https://www.publickey .jp/blog/ / googlebigqueryawsazurebigquery_omnigoogle_cloud_next_ onair.html
26. BigQuery Omni • アルファ版のため機能制限など詳細はまだ不明 • BigQueryのマルチクラウド版 • BigQuery • クエリ課⾦なのが特徴 • マルチテナント型なのでクラスタなどリソースはあまり意識しなくてよい • MLやAutoML Tablesといった機械学習系機能も特徴的 • AWS含むマルチクラウドで展開されるということは転送料の問題が解決される
27. RedshiftとSnowflakeとBigQuery Omni • ※主観でのざっくりとした⽐較です "NB[PO
    3FETIJGU 4OPXqBLF #JH2VFSZ ՝ۚ 7JSUVBM
    8BSFIPVTF՝ۚ ىಈ࣌ؒ εέʔϧ ΫΤϦΛ౤͛Δ͚࣌ͩසൟʹ
    ىಈͨ͠Γఀࢭ͢Δ ༻్΍ඞཁͳੑೳʹԠͯ͡
    8BSFIPVTFΛ࡞ͬͨΓ૿΍ͨ͠Γ͢Δ Ϋϥελͷϊʔυ਺มߋΛ͢Δ͔
    $PODVSSFOU
    4DBMJOH ར༻͢Δؒ͸ىಈͨ͠·· Ϋϥελ՝ۚ ΫΤϦ՝ۚ Ϣʔβ͸ؔ༩͠ͳ͍ ΫΤϦʹԠͯࣗ͡ಈͰϦιʔεׂ౰
28. 検証でやったこと
29. 機能検証 • ひととおりの機能を触ってみました
30. DB作成〜データのimportまで • create database • AWSのIAM Role作成 • S インテグレーション作成 • AWS IAM Roleの信頼関係の更新 • ログフォーマット作成 • External Stageの作成 • テーブル作成 • テーブルへS からデータをinsert
31. 運⽤のしやすさ • クラスタのバージョンアップ作業などが不要(基本的にダウンタイムがなさそう) • 異常に重いクエリを投げてしまってもコストが増⼤しない • Virtual Warehouse課⾦なので起動時間だけ気にしておけばOK • ほぼすべての設定がSQLからも操作できて統⼀感がある • MySQLやPostgreSQLプロトコルが使えないかわりに • Web UIが充実している • アダプタやインテグレーションが充実している
32. 使い勝⼿ • Redshiftと⽐べたときのSnowflakeのクエリ性能はワークロードの特性によっ て違うと思うので検証してみることをおすすめします • 簡単な集計で使いそうなJOINやGROUP BYなどを⾏った限りは申し分なかった • ある程度まではWarehouseのサイズを上げれば上げるほど実⾏時間が短縮された • Warehouseが⽤途別に分けられるので、COPYクエリを同時に多数発⾏してもク エリのキューが詰まってクエリが滞留してしまうという事は起きなかった • sort keyやdist keyを明⽰的に指定しなくても⾃動でクラスタリングしてくれる
33. ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >= ... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、
 ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。
34. Snowpipe • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル タイムに取り込んでくれる仕組み • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない • 別途Snowpipe代が掛かる • 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない • 体感的にはそんなに⾼くない • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように なるまで数分だった
35. External Tables • Redshift SpectrumのようにS など直接スキャンできる • S のイベントをきっかけにオブジェクトのインデックス更新ができる • Amazon Athenaでいうところの「MSCK REPAIR TABLE」のようなクエリが不要
36. Work Sheets
37. Work Sheets • 実⾏計画がわかりやすい
38. Snowsight • 新しいUI(preview) • 簡単なグラフやダッシュボードの作成はUIで完結してしまうので便利
39. UDF • javascriptでUDFが書ける • RedshiftはPythonでUDFが書ける
40. External Function • UDFの拡張版 • AWS LambdaとHTTP APIが使える
41. 料⾦の試算 • 課⾦体系の違いから、⼀概にRedshiftと⽐較するのは難しかった • Redshift: どれくらいのリソースが必要か • Snowflake: どれくらいのリソースをどのくらいの時間使うのか • リソースの使い⽅にメリハリをつければ効率よく使うことができそう • お試しであったり、⼩規模な環境であればそれほど費⽤は⾼くならないはずな のでとりあえず触ってみることをおすすめします • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼
42. もしもRedshiftから移⾏するとしたら • 互換性のあるDWHではないので移⾏計画を⽴てることが重要 • 移⾏する場合はサポートしてもらえるようです • コストの問題から新旧のDWHを同時並⾏させる期間は短くしたい • 接続するアプリケーションの対応状況の確認 • アプリケーション(Scala, Java, Python, Rubyなど) • クエリツール(DataGripなど) • BIツール(Tableauなど) • データの移⾏ • S にソースになるデータがある場合はそんなに⼤変ではないかも
43. まとめ • Redshiftを使っているプロダクトでSnowflakeを検証してみました • 広告配信プラットフォームでのログ分析において欲しい機能は
 ⼀通り揃っていそうでした • DWHの導⼊や移⾏を考えられている⽅にとって候補になり得るプロダクトでした
44. 質疑応答