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
Redshift から Snowflake に移行した話
Search
DragonTaro1031
November 26, 2021
Programming
2
2.1k
Redshift から Snowflake に移行した話
Snowflake 社主催の社内勉強会で発表した内容です。
DragonTaro1031
November 26, 2021
Tweet
Share
More Decks by DragonTaro1031
See All by DragonTaro1031
大規模データを扱うクラウドセキュリティプラットフォームのアーキテクチャ変遷
dragontaro
1
4.4k
CDK で未対応のパラメータを付与する方法
dragontaro
0
210
CloudbaseでのAWS CDKとAWS Step Functionsを用いたバッチ処理基盤の爆速構築
dragontaro
0
540
DMS を使って MySQL のデータを Snowflake に同期する
dragontaro
0
1.9k
Other Decks in Programming
See All in Programming
型で語るカタ
irof
0
760
リバースエンジニアリング新時代へ! GhidraとClaude DesktopをMCPで繋ぐ/findy202507
tkmru
4
1.2k
Goで作る、開発・CI環境
sin392
0
270
はじめてのWeb API体験 ー 飲食店検索アプリを作ろうー
akinko_0915
0
160
PHPUnitの限界をPlaywrightで補完するテストアプローチ
yuzneri
0
250
AI時代のソフトウェア開発を考える(2025/07版) / Agentic Software Engineering Findy 2025-07 Edition
twada
PRO
101
38k
スタートアップの急成長を支えるプラットフォームエンジニアリングと組織戦略
sutochin26
1
7.6k
React は次の10年を生き残れるか:3つのトレンドから考える
oukayuka
39
14k
Startups on Rails in Past, Present and Future–Irina Nazarova, RailsConf 2025
irinanazarova
0
280
初学者でも今すぐできる、Claude Codeの生産性を10倍上げるTips
s4yuba
16
13k
Python型ヒント完全ガイド 初心者でも分かる、現代的で実践的な使い方
mickey_kubo
1
250
PHPカンファレンス関西2025 基調講演
sugimotokei
5
850
Featured
See All Featured
The Art of Delivering Value - GDevCon NA Keynote
reverentgeek
15
1.6k
Facilitating Awesome Meetings
lara
54
6.5k
Imperfection Machines: The Place of Print at Facebook
scottboms
267
13k
Testing 201, or: Great Expectations
jmmastey
43
7.6k
Reflections from 52 weeks, 52 projects
jeffersonlam
351
21k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
8
360
The Invisible Side of Design
smashingmag
301
51k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
248
1.3M
Understanding Cognitive Biases in Performance Measurement
bluesmoon
29
1.8k
VelocityConf: Rendering Performance Case Studies
addyosmani
332
24k
Designing Dashboards & Data Visualisations in Web Apps
destraynor
231
53k
KATA
mclloyd
30
14k
Transcript
Redshift から Snowflake に 移行した話 AI 事業本部 AirTrack 宮川竜太朗
今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3.
移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3.
移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
AirTrack について - 位置情報データを用いて広告配信・計測を行う DSP/DMP - 来店を最大化するような配信メニュー - 来店予測モデルによるオフライン推論 -
伝統的なジオターゲティング - 特定の場所に滞在した人をターゲティング
AirTrack での DWH の使い方 保持しているデータ - 数万 qps のトラフィックのサンプリングされたログ -
広告の配信実績 - 数千億行の位置情報データ 実行されているクエリ - 1日数千クエリ - 位置情報データをフルスキャンするような高負荷な処理も - ↑のような処理がビジネス起因で不定期に実行される
今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3.
移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
AirTrack の抱えていた問題 - Redshift のコスト最適化が難しかった - 並列数の制限でビジネス用途の処理が詰まっていた - リソースが足りずに外部リソース(EMR)に分散させていた
Redshift のコスト最適化が難しかった - ds2 ファミリーを使用 - RI を1年で購入していた - データ量が多い(常にストレージ90%ぐらい)
- たまに激重クエリが走るから耐えうるスペック - つまり不均一なワークロードに最適化するのが難しかった - これによりコストがかかってしまう - ra3 ファミリーでも課題感はあまり変わらない - RI を3年で購入すればかなりお得だが覚悟が持てなかった
Redshift のコスト最適化が難しかった - ds2 ファミリーを使用 - RI を1年で購入していた - データ量が多い(常にストレージ90%ぐらい)
- たまに激重クエリが走るから耐えうるスペック - つまり不均一なワークロードに最適化するのが難しかった - これによりコストがかかってしまう - ra3 ファミリーでも課題感はあまり変わらない - RI を3年で購入すればかなりお得だが覚悟が持てなかった 低コストでスケーリングできたらそれだけで解決するなぁ
並列数の制限 - Redshift はもちろん並列処理可能 - 負荷の高い処理ではスケーリングしないと詰まる(当たり前) - そしてスケーリングでコストがかかる - スケーリング分は
RI 当たらない(多少クレジットはあるが)
並列数の制限 - Redshift はもちろん並列処理可能 - 負荷の高い処理ではスケーリングしないと詰まる(当たり前) - そしてスケーリングでコストがかかる - スケーリング分は
RI 当たらない(多少クレジットはあるが) 低コストでスケーリングできたらそれだけで解決するなぁ
リソースが足りず外部リソースを使っていた - 定常的に走る比較的重めな集計処理を EMR に切り出していた - ただの join 程度の集計に EMR
を使うのはコスパが悪かった - 金銭的なコスト - 保守・運用コスト
リソースが足りず外部リソースを使っていた - 定常的に走る比較的重めな集計処理を EMR に切り出していた - ただの join 程度の集計に EMR
を使うのはコスパが悪かった - 金銭的なコスト - 保守・運用コスト 低コストでスケーリングできたらそれだけで解決するなぁ
そこで検証をしました
Snowflake の検証 - スケールアウトとコストの最適化は可能なのか - クエリのパフォーマンスは遜色ないのか - 無駄な EMR は廃止できるのか
スケールアウトとコストの最適化は可能なのか Dynalyst での事例を聞いていけそうな気はしてたが。。 結果 - 十分にスケールしてくれた - ウェアハウス(計算ノード)がよい - コストが最適化できた
- クエリのパフォーマンス - 従量課金の恩恵
クエリのパフォーマンスは遜色ないのか - 軽量なクエリはむしろパフォーマンスがよい - マイクロパーティションが優秀 - 位置情報の重いクエリはパフォーマンスが劣化したものもある - 影響が限定的でスケールアップで耐え凌げる -
そもそもチューニングの余地がある
無駄な EMR を廃止できるのか - DWH でできることは DWH に集約したかった - クラスタの管理
- 学習コスト(運用できる人が抜けた) - スケールアウトが容易なのでなんら問題なかった
他の DWH の検討 - Big Query - データ転送量がかかる - Big
Query Omni - AWS 上で Big Query を使えるサービス - 検討当時は利用できなかった - 2021/10 公開
検討の結果 Snowflake に決定 🎉
今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3.
移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
移行にあたって苦労した点 - 最難関は「ほとんど保守されていない Java のバッチ」 - 移行完了の定義 - 過去データの移植
ほとんど保守されていない Java のバッチ - 組織のメンバーが入れ替わったタイミングでの移行だった - ちょっと触ったことのあるメンバーが3人だけ。。 - 大量の temp
table と unload 祭り。。 - 一時データは削除されるので削除しないようにするところから - 謎の union all(csv のヘッダー付与してるだけ) - 条件分岐を含めて動的に生成される100行ぐらいのクエリ
どんなプロダクトでも負債はありますよね
恐怖の Java バッチとの戦い - とはいえ移行するしかない - 慣れない Java を読み解くところからスタート -
Redshift 経由の処理と Snowflake 経由の処理を同時に実行 - 成果物を逐一蓄積するようにして比較 - Redshift の処理を消して Snowflake の処理で本番書き込み - ORM がぱっと動かなくて JDBC 直書き - 新たな負債を生み出したかも。。
- 億オーダーのテーブルで完全一致は無理ゲー - 日付や計算の精度が前よりよくなって純増 - 検索の境界条件の微妙な違い 移行完了の定義
移行完了の定義 - 既存のデータと join して一致度の調査 - お金が絡むところは完全一致 - それ以外は数%程度までズレを許容
過去データの移植 - Redshift からのアンロードで1日かかることも - 失敗するとビジネスに影響するので工数よりも精神的負担が。。
今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3.
移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
移行後のパフォーマンス・コスト面について - コスト面 - パフォーマンス面
コスト面 - 移行前の検証通りコストの最適化はできた
パフォーマンス面 - 後述の位置情報の重いクエリ以外は体感早くなった - すべてのクエリが問題なく動いている
パフォーマンス面 - 位置情報の重いクエリでのパフォーマンス劣化 - ストレージと計算ノードのネットワーク部分がネックに - Redshift と Snowflake 両方で緯度経度に最適化なし
※ちなみに過去1年間でスクランブル交差点に 2分以上滞在したことのあるユーザーを抽出するクエリを走らせました。
まとめ - Redshift から Snowflake に移行してコストの最適化ができた - 移行は大変だったが約3ヶ月で終わったのでよかった - ほとんどのクエリは満足に動いている
おまけ (当日話してない内容です)
Snowflake のサポートは神 - いつも大変お世話になっております - サポートあってこその移行成功でした - 迅速かつ丁寧な対応でだいたいのことがすぐに解決する
サポートしていただいた事例
1. 遅いクエリのチューニング - Redshift に比べて圧倒的にパフォーマンスが悪いクエリ - ただの join だったはずがパフォーマンスが悪かった -
Double(浮動小数点)⇔ Number(固定小数点)の join が原因 - Double を Number にキャストすると約 1000 倍早くなったw
2. クラスタリングキー - 位置情報の検索が遅かった - 丸めた緯度経度にクラスタリングキーの付与をおすすめされた - あまりのデータ量に再クラスタリング(alter table)で 💸
- insert into target select * from origin; で全部入れ直す方が安い - 問題箇所は圧倒的にクエリが早くなった - ただ致命的に他のクエリが遅くなった - もっと入念に相談すべきだった。。
3. Snowflake 関係なく window 関数で苦労した話 - 毎回結果が変わるクエリを生み出してしまった - 原因 -
毎回レコードの順序が変わる with 句 - レコードの順序に依存する不完全な lead 関数 - 詳しくは ADC と Snowflake のアドベントカレンダーで - 結果として Snowflake が悪くない部分の調査をさせてしまう形に - ちなみに解決までほぼ1営業日
None