Redshift から Snowflake に移行した話

Snowflake 社主催の社内勉強会で発表した内容です。

Transcript

1. Redshift から Snowflake に 移行した話 AI 事業本部 AirTrack 宮川竜太朗
2. 今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3. 移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
3. 今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3. 移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
4. AirTrack について - 位置情報データを用いて広告配信・計測を行う DSP/DMP - 来店を最大化するような配信メニュー - 来店予測モデルによるオフライン推論 - 伝統的なジオターゲティング - 特定の場所に滞在した人をターゲティング
5. AirTrack での DWH の使い方 保持しているデータ - 数万 qps のトラフィックのサンプリングされたログ - 広告の配信実績 - 数千億行の位置情報データ 実行されているクエリ - 1日数千クエリ - 位置情報データをフルスキャンするような高負荷な処理も - ↑のような処理がビジネス起因で不定期に実行される
6. 今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3. 移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
7. AirTrack の抱えていた問題 - Redshift のコスト最適化が難しかった - 並列数の制限でビジネス用途の処理が詰まっていた - リソースが足りずに外部リソース（EMR）に分散させていた
8. Redshift のコスト最適化が難しかった - ds2 ファミリーを使用 - RI を1年で購入していた - データ量が多い（常にストレージ90％ぐらい） - たまに激重クエリが走るから耐えうるスペック - つまり不均一なワークロードに最適化するのが難しかった - これによりコストがかかってしまう - ra3 ファミリーでも課題感はあまり変わらない - RI を3年で購入すればかなりお得だが覚悟が持てなかった
9. Redshift のコスト最適化が難しかった - ds2 ファミリーを使用 - RI を1年で購入していた - データ量が多い（常にストレージ90％ぐらい） - たまに激重クエリが走るから耐えうるスペック - つまり不均一なワークロードに最適化するのが難しかった - これによりコストがかかってしまう - ra3 ファミリーでも課題感はあまり変わらない - RI を3年で購入すればかなりお得だが覚悟が持てなかった 低コストでスケーリングできたらそれだけで解決するなぁ
10. 並列数の制限 - Redshift はもちろん並列処理可能 - 負荷の高い処理ではスケーリングしないと詰まる（当たり前） - そしてスケーリングでコストがかかる - スケーリング分は RI 当たらない（多少クレジットはあるが）
11. 並列数の制限 - Redshift はもちろん並列処理可能 - 負荷の高い処理ではスケーリングしないと詰まる（当たり前） - そしてスケーリングでコストがかかる - スケーリング分は RI 当たらない（多少クレジットはあるが） 低コストでスケーリングできたらそれだけで解決するなぁ
12. リソースが足りず外部リソースを使っていた - 定常的に走る比較的重めな集計処理を EMR に切り出していた - ただの join 程度の集計に EMR を使うのはコスパが悪かった - 金銭的なコスト - 保守・運用コスト
13. リソースが足りず外部リソースを使っていた - 定常的に走る比較的重めな集計処理を EMR に切り出していた - ただの join 程度の集計に EMR を使うのはコスパが悪かった - 金銭的なコスト - 保守・運用コスト 低コストでスケーリングできたらそれだけで解決するなぁ
14. そこで検証をしました
15. Snowflake の検証 - スケールアウトとコストの最適化は可能なのか - クエリのパフォーマンスは遜色ないのか - 無駄な EMR は廃止できるのか
16. スケールアウトとコストの最適化は可能なのか Dynalyst での事例を聞いていけそうな気はしてたが。。 結果 - 十分にスケールしてくれた - ウェアハウス（計算ノード）がよい - コストが最適化できた - クエリのパフォーマンス󰢏 - 従量課金の恩恵
17. クエリのパフォーマンスは遜色ないのか - 軽量なクエリはむしろパフォーマンスがよい - マイクロパーティションが優秀 - 位置情報の重いクエリはパフォーマンスが劣化したものもある - 影響が限定的でスケールアップで耐え凌げる - そもそもチューニングの余地がある
18. 無駄な EMR を廃止できるのか - DWH でできることは DWH に集約したかった - クラスタの管理 - 学習コスト（運用できる人が抜けた） - スケールアウトが容易なのでなんら問題なかった
19. 他の DWH の検討 - Big Query - データ転送量がかかる - Big Query Omni - AWS 上で Big Query を使えるサービス - 検討当時は利用できなかった - 2021/10 公開
20. 検討の結果 Snowflake に決定 🎉
21. 今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3. 移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
22. 移行にあたって苦労した点 - 最難関は「ほとんど保守されていない Java のバッチ」 - 移行完了の定義 - 過去データの移植
23. ほとんど保守されていない Java のバッチ
 - 組織のメンバーが入れ替わったタイミングでの移行だった
 - ちょっと触ったことのあるメンバーが3人だけ。。
 - 大量の temp table と unload 祭り。。
 - 一時データは削除されるので削除しないようにするところから
 - 謎の union all（csv のヘッダー付与してるだけ）
 - 条件分岐を含めて動的に生成される100行ぐらいのクエリ
 

24. どんなプロダクトでも負債はありますよね
25. 恐怖の Java バッチとの戦い - とはいえ移行するしかない - 慣れない Java を読み解くところからスタート - Redshift 経由の処理と Snowflake 経由の処理を同時に実行 - 成果物を逐一蓄積するようにして比較 - Redshift の処理を消して Snowflake の処理で本番書き込み - ORM がぱっと動かなくて JDBC 直書き - 新たな負債を生み出したかも。。
26. - 億オーダーのテーブルで完全一致は無理ゲー - 日付や計算の精度が前よりよくなって純増 - 検索の境界条件の微妙な違い 移行完了の定義
27. 移行完了の定義 - 既存のデータと join して一致度の調査 - お金が絡むところは完全一致 - それ以外は数％程度までズレを許容
28. 過去データの移植 - Redshift からのアンロードで1日かかることも - 失敗するとビジネスに影響するので工数よりも精神的負担が。。
29. 今日お話する内容 1. AirTrack について 2. Redshift から Snowflake に移行を決意した理由 3. 移行にあたって苦労した点 4. 移行後のパフォーマンス・コスト面について
30. 移行後のパフォーマンス・コスト面について - コスト面 - パフォーマンス面
31. コスト面 - 移行前の検証通りコストの最適化はできた
32. パフォーマンス面 - 後述の位置情報の重いクエリ以外は体感早くなった - すべてのクエリが問題なく動いている
33. パフォーマンス面 - 位置情報の重いクエリでのパフォーマンス劣化 - ストレージと計算ノードのネットワーク部分がネックに - Redshift と Snowflake 両方で緯度経度に最適化なし
34. ※ちなみに過去1年間でスクランブル交差点に 2分以上滞在したことのあるユーザーを抽出するクエリを走らせました。
35. まとめ - Redshift から Snowflake に移行してコストの最適化ができた - 移行は大変だったが約3ヶ月で終わったのでよかった - ほとんどのクエリは満足に動いている
36. おまけ （当日話してない内容です）
37. Snowflake のサポートは神 - いつも大変お世話になっております󰢛 - サポートあってこその移行成功でした - 迅速かつ丁寧な対応でだいたいのことがすぐに解決する
38. サポートしていただいた事例
39. 1. 遅いクエリのチューニング - Redshift に比べて圧倒的にパフォーマンスが悪いクエリ - ただの join だったはずがパフォーマンスが悪かった - Double（浮動小数点）⇔ Number（固定小数点）の join が原因 - Double を Number にキャストすると約 1000 倍早くなったw
40. 2. クラスタリングキー - 位置情報の検索が遅かった - 丸めた緯度経度にクラスタリングキーの付与をおすすめされた - あまりのデータ量に再クラスタリング（alter table）で 💸 - insert into target select * from origin; で全部入れ直す方が安い - 問題箇所は圧倒的にクエリが早くなった - ただ致命的に他のクエリが遅くなった - もっと入念に相談すべきだった。。
41. 3. Snowflake 関係なく window 関数で苦労した話 - 毎回結果が変わるクエリを生み出してしまった - 原因 - 毎回レコードの順序が変わる with 句 - レコードの順序に依存する不完全な lead 関数 - 詳しくは ADC と Snowflake のアドベントカレンダーで - 結果として Snowflake が悪くない部分の調査をさせてしまう形に - ちなみに解決までほぼ1営業日