Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
SnowflakeとRedshiftの比較検証
Search
Kurochan
July 28, 2020
Technology
1
12k
SnowflakeとRedshiftの比較検証
300コア近くのRedshiftクラスタを運用している広告配信プロダクトでSnowflakeを検証した結果をご紹介します。
Kurochan
July 28, 2020
Tweet
Share
More Decks by Kurochan
See All by Kurochan
入門 電気通信事業者
kurochan
12
5k
AWS x さくらのクラウドのハイブリッドクラウドによる安価なフレッツ閉域網接続の実装
kurochan
9
4.9k
GoでTCP Proxyを実装してみよう
kurochan
1
760
サイバーエージェントの広告配信におけるIPoEトラフィックの概況
kurochan
0
330
スケールするというのはどういうことなのか
kurochan
14
4.4k
サイバーエージェントのGitHub Copilot導入と 開発生産性
kurochan
44
41k
Cloudflare Zero Trustを利用したセキュアな開発環境へのアクセス手法の確立
kurochan
10
2.8k
セキュキャンを卒業してその後
kurochan
0
1.2k
サイバーエージェントの実践×実験Snowflake 導入の経緯から最新機能のトライアルまで / How Snowflake Is Used In CyberAgent - Go To the Future
kurochan
0
960
Other Decks in Technology
See All in Technology
エンジニア視点で見る、 組織で運用されるデザインシステムにするには
shunya078
1
300
eBPFのこれまでとこれから
yutarohayakawa
5
380
「認証認可」という体験をデザインする ~Nekko Cloud認証認可基盤計画
logica0419
2
250
Tricentisにおけるテスト自動化へのAI活用ご紹介/20240910Shunsuke Katakura
shift_evolve
0
180
Monitor GraalVM Native Apps with OpenTelemetry
logico_jp
0
130
LINEヤフーのフロントエンド組織・体制の紹介
lycorp_recruit_jp
0
330
Optuna: a Black-Box Optimization Framework
pfn
PRO
1
110
サーバー管理しないサーバーサービスManaged DevOps Pool
kkamegawa
0
110
ナレッジグラフとLLMの相互利用
koujikozaki
0
340
効果的なオンコール対応と障害対応
ryuichi1208
5
2.7k
Analytics-Backed App Widget Development - Served with Jetpack Glance
miyabigouji
0
340
事前準備が肝!AI活用のための業務改革
layerx
PRO
1
240
Featured
See All Featured
Embracing the Ebb and Flow
colly
83
4.4k
Building Better People: How to give real-time feedback that sticks.
wjessup
359
18k
YesSQL, Process and Tooling at Scale
rocio
167
14k
Designing the Hi-DPI Web
ddemaree
278
34k
A Philosophy of Restraint
colly
202
16k
How to name files
jennybc
75
98k
Scaling GitHub
holman
458
140k
Side Projects
sachag
451
42k
Faster Mobile Websites
deanohume
304
30k
Building a Scalable Design System with Sketch
lauravandoore
458
32k
Pencils Down: Stop Designing & Start Developing
hursman
119
11k
How to Ace a Technical Interview
jacobian
275
23k
Transcript
SnowflakeとRedshiftの⽐較 CA.io # Snowflake 株式会社サイバーエージェント AI事業本部 黒崎 優太 (@kuro_m )
黒崎 優太 • 新卒⼊社6年⽬ • 広告配信プラットフォーム事業の開発責任者 • 業務は Scala +
AWSが中⼼ • イラスト図解でよくわかる ITインフラの基礎知識 •書きました • ⾃宅サーバとかが好きです @kuro_m @kurochan
本⽇お話すること • RedshiftをDWHに採⽤している広告配信事業者が Snowflakeを検証してみてどうだったのかについてお話します • ⼀概にどちらの⽅が優れている、といったような結論は出しません
Contents • (普段業務で開発しているものの紹介) • 現状のDWH周辺の環境紹介 • RedshiftとSnowflakeの違い • 検証でやったこと •
検証してわかったこと • 質疑応答
開発しているシステム • Dynamic Retargeting for Games •スマホ向けリターゲティング広告配信プラットフォーム •トップセールス @⽇本のスマホゲームの中でも⾼いシェア •⽇本、アメリカを中⼼に数カ国に配信
•ユーザごとに最適化した広告を配信 https://www.dynalyst.io
開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 数千億リクエスト/⽉ • ⼊札トラフィック: 約8Gbps
• レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ຊͷೖࡳϦΫΤετඵ ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
もっと知りたい⽅は • ⽉間数千億リクエストをさばく技術 https://logmi.jp/tech/articles/
現状のDWH周辺の環境紹介
Dynalystのデータフロー • アプリケーションサーバで発⽣した広告の⼊札や配信、計測といったログがど のように扱われているかを紹介します
ログ転送フロー • 広告の⼊札や計測のログはすべてKinesis Streamsに流す • 拡張性や耐障害性が向上する MPHBSDIJWFDPOTVNFS BSDIJWF ,JOFTJT4USFBNT QSPEVDFMPHT
BQQTFSWFS 4 1SPEVDFS 4USFBN $POTVNFS
ログのリアルタイム処理 • 何かしらのイベントの発⽣後すぐにDBを更新する⽤途 ECVQEBUFDPOTVNFS BSDIJWF ,JOFTJT4USFBNT QSPEVDFMPHT BQQTFSWFS 1SPEVDFS 4USFBN
$POTVNFS %ZOBNP%#
1つのストリームに複数種類のconsumerも設置可能 %#VQEBUFDPOTVNFS MPHBSDIJWFDPOTVNFS VQEBUF BSDIJWF ,JOFTJT4USFBNT DPOTVNF QSPEVDFMPHT BQQTFSWFS %ZOBNP%#
4 1SPEVDFS 4USFBN $POTVNFS
ログのRedshiftへの取り込み • S にログがアップロードされたのをきっかけにRedshiftに継続取り込み MPHBSDIJWFDPOTVNFS BSDIJWF ,JOFTJT4USFBNT 4 4USFBN $POTVNFS
424 OPUJGZ MPHJNQPSUFS 3FETIJGU $01:UBCMFGSPNT MPBE
ログの集計 • ログの量が数TB/day(圧縮状態) • 広告の集計処理は複雑になりがち • 集計ロジックを⾃前実装したい • テストコードが書きたい •
分散処理がしたい • Apache Spark on Amazon EMR • クラスタコンピューティングフレームワーク • 分散共有メモリモデル • ScalaやPythonで処理が記述できる &.3$MVTUFS .BTUFS 4MBWF 4MBWF 4MBWF 4MBWF
RedshiftとSnowflakeの⽐較
Redshiftとは • AWSのマネージドサービスであり、PostgreSQL互換なDWH • クラスタのノードサイズと台数を選択して利⽤する • 最新世代(RA )からコンピューティングとストレージが分離されたため、 RA の場合はストレージは利⽤した分だけ請求される
DynalystでのRedshiftの活⽤ • アドホックな分析⽤途 • PostgreSQL互換なので利⽤できるツールが幅広い • 機械学習バッチのデータソース • Tableau(BIツール)上での分析や可視化 •
など
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負荷が⼤きく、 クラスタの計算能⼒を使い切れていない
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が発動しっぱなしになってしまいコスト効率がよくなかった
Redshiftの料⾦体系 • 基本的にはクラスタ課⾦が⼤半を占める • クラスタ課⾦ • ノードのサイズ, 台数 x 利⽤時間
• リザーブドインスタンス(前払い)が⼀番安いので1〜3年分コミットすることが多いと思われる • ストレージ課⾦(RA のみ) • スポット課⾦ • Redshift Spectrum • Concurrent Scaling • など
Snowflakeとは • Snowflake社の⽅からご紹介頂いたので概要は割愛 • ポイント • 計算するノードはShared nothing: スケールアウト可能 •
ストレージはShared Disk: 計算するノードはストレージを持たず、外部ストレージを共有 • Virtual Warehouse: 時間課⾦でクエリを実⾏するクラスタはすぐ起動できたり停⽌ができる • 明確に停⽌時間を設定せずとも、クエリが⾛っていない間はVirtual Warehouseの課⾦を0にすることが可能
データ転送料は? • AWSではInboundトラフィックは無料、Outboundトラフィックは有料 • AWS上で⼤量のデータを扱うプロダクトにとって外部のサービスを使う上で データ転送量が問題になりがち • 例: 東京リージョンからインターネットに1⽇5TB転送: 約
$9,000/⽉ • Snowflakeはクラウド事業者とリージョンが選べるので、同⼀リージョン内の 通信にすることができる • AWS TokyoリージョンのS からSnowflakeに転送する料⾦は無料(S のAPI料⾦は発⽣)
RedshiftとSnowflake • Redshift • 顧客がある程度クラスタ管理をする • 細かいワークロード管理ができる • クラスタのリサイズに制約がある •
Resize: 全データのコピーが⾛る, リサイズ完了までRead Onlyになる • Elastic Resize: データのコピーは⾛らないが変更後ノード数は元サイズの2倍〜1/2のサイズのみ, 数分のクエリ停⽌時間あり • Concurrent Scaling: Read系クエリに関してはクラスタの負荷に応じて⼀時的にノードが追加されるような機能 • Snowflake • 顧客はクラスタの数やサイズの設定をするだけ • 細かいワークロード管理はできない(⽤途ごとにVirtual Warehouseを⽴ててしまう) • クラスタ(Warehouse)のリサイズには制約がない • クエリが⾛っていない間⾃動停⽌させたり、サイズ変更を⾏ってもダウンタイムは発⽣しない
最近のニュース
Google、BigQueryをAWSやAzureなどマルチクラウド展開へ、 「BigQuery Omni」発表。 https://www.publickey .jp/blog/ / googlebigqueryawsazurebigquery_omnigoogle_cloud_next_ onair.html
BigQuery Omni • アルファ版のため機能制限など詳細はまだ不明 • BigQueryのマルチクラウド版 • BigQuery • クエリ課⾦なのが特徴
• マルチテナント型なのでクラスタなどリソースはあまり意識しなくてよい • MLやAutoML Tablesといった機械学習系機能も特徴的 • AWS含むマルチクラウドで展開されるということは転送料の問題が解決される
RedshiftとSnowflakeとBigQuery Omni • ※主観でのざっくりとした⽐較です "NB[PO3FETIJGU 4OPXqBLF #JH2VFSZ ՝ۚ 7JSUVBM8BSFIPVTF՝ۚ ىಈ࣌ؒ
εέʔϧ ΫΤϦΛ͛Δ͚࣌ͩසൟʹ ىಈͨ͠Γఀࢭ͢Δ ༻్ඞཁͳੑೳʹԠͯ͡ 8BSFIPVTFΛ࡞ͬͨΓ૿ͨ͠Γ͢Δ ΫϥελͷϊʔυมߋΛ͢Δ͔ $PODVSSFOU4DBMJOH ར༻͢Δؒىಈͨ͠·· Ϋϥελ՝ۚ ΫΤϦ՝ۚ Ϣʔβؔ༩͠ͳ͍ ΫΤϦʹԠͯࣗ͡ಈͰϦιʔεׂ
検証でやったこと
機能検証 • ひととおりの機能を触ってみました
DB作成〜データのimportまで • create database • AWSのIAM Role作成 • S インテグレーション作成
• AWS IAM Roleの信頼関係の更新 • ログフォーマット作成 • External Stageの作成 • テーブル作成 • テーブルへS からデータをinsert
運⽤のしやすさ • クラスタのバージョンアップ作業などが不要(基本的にダウンタイムがなさそう) • 異常に重いクエリを投げてしまってもコストが増⼤しない • Virtual Warehouse課⾦なので起動時間だけ気にしておけばOK • ほぼすべての設定がSQLからも操作できて統⼀感がある
• MySQLやPostgreSQLプロトコルが使えないかわりに • Web UIが充実している • アダプタやインテグレーションが充実している
使い勝⼿ • Redshiftと⽐べたときのSnowflakeのクエリ性能はワークロードの特性によっ て違うと思うので検証してみることをおすすめします • 簡単な集計で使いそうなJOINやGROUP BYなどを⾏った限りは申し分なかった • ある程度まではWarehouseのサイズを上げれば上げるほど実⾏時間が短縮された •
Warehouseが⽤途別に分けられるので、COPYクエリを同時に多数発⾏してもク エリのキューが詰まってクエリが滞留してしまうという事は起きなかった • sort keyやdist keyを明⽰的に指定しなくても⾃動でクラスタリングしてくれる
ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >=
... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、 ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。
Snowpipe • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル タイムに取り込んでくれる仕組み • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない • 別途Snowpipe代が掛かる
• 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない • 体感的にはそんなに⾼くない • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように なるまで数分だった
External Tables • Redshift SpectrumのようにS など直接スキャンできる • S のイベントをきっかけにオブジェクトのインデックス更新ができる •
Amazon Athenaでいうところの「MSCK REPAIR TABLE」のようなクエリが不要
Work Sheets
Work Sheets • 実⾏計画がわかりやすい
Snowsight • 新しいUI(preview) • 簡単なグラフやダッシュボードの作成はUIで完結してしまうので便利
UDF • javascriptでUDFが書ける • RedshiftはPythonでUDFが書ける
External Function • UDFの拡張版 • AWS LambdaとHTTP APIが使える
料⾦の試算 • 課⾦体系の違いから、⼀概にRedshiftと⽐較するのは難しかった • Redshift: どれくらいのリソースが必要か • Snowflake: どれくらいのリソースをどのくらいの時間使うのか •
リソースの使い⽅にメリハリをつければ効率よく使うことができそう • お試しであったり、⼩規模な環境であればそれほど費⽤は⾼くならないはずな のでとりあえず触ってみることをおすすめします • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼
もしもRedshiftから移⾏するとしたら • 互換性のあるDWHではないので移⾏計画を⽴てることが重要 • 移⾏する場合はサポートしてもらえるようです • コストの問題から新旧のDWHを同時並⾏させる期間は短くしたい • 接続するアプリケーションの対応状況の確認 •
アプリケーション(Scala, Java, Python, Rubyなど) • クエリツール(DataGripなど) • BIツール(Tableauなど) • データの移⾏ • S にソースになるデータがある場合はそんなに⼤変ではないかも
まとめ • Redshiftを使っているプロダクトでSnowflakeを検証してみました • 広告配信プラットフォームでのログ分析において欲しい機能は ⼀通り揃っていそうでした • DWHの導⼊や移⾏を考えられている⽅にとって候補になり得るプロダクトでした
質疑応答