サイバーエージェントの実践×実験Snowflake 導入の経緯から最新機能のトライアルまで / How Snowflake Is Used In CyberAgent - Go To the Future

BUILD.localイベントはコミュニティメンバーによってリードされており、「BUILD」の名の通り、データアプリケーション、データサイエンス、データエンジニアリング、そしてデータシェアリングの領域でイノベーションを作り上げている人たちのためのイベントです。
https://usergroups.snowflake.com/events/details/snowflake-japan-presents-buildlocal-japan-snowparkdexi-ufei-gou-zao-deta-playing-with-unstructured-data-using-snowpark/

Transcript

1. サイバーエージェントの実践×実験Snowflake 導⼊の経緯から最新機能のトライアルまで How Snowflake Is Used In CyberAgent - Go To the Future 株式会社サイバーエージェント AI事業本部 黒崎 優太 (@kuro_m ) @Snowflake Build.local Japan
2. ࠇ࡚ ༏ଠ 2015೥౓ ৽ଔೖࣾ AIࣄۀຊ෦ DXຊ෦ ΞϓϦӡ༻ηϯλʔ @kurochan @kuro_m88 ج൫ٕज़੹೚ऀ αΠόʔΤʔδΣϯτ CTO౷ׅࣨ
3. Contents • サイバーエージェントグループでのSnowflakeの活⽤状況 • Snowflake導⼊のきっかけ • Snowflake導⼊のTips • Snowflake活⽤のこれから
4. サイバーエージェントグループでの Snowflakeの活⽤状況
5. サイバーエージェントグループについて
6. インターネット広告事業 • 成⻑しつづける市場で国内トップシェア • 運⽤x技術で広告効果を最⼤化するのが強み
7. メディア事業 • ABEMA、Ameba、タップルなど多くのユーザに使われるメディアを 開発し運⽤してきた実績
8. ゲーム事業 • ⼈気タイトルを数多く排出
9. サイバーエージェントグループでのSnowflakeの利⽤状況 • アカウント数 •約20アカウント •データ量 •数百TB •売上規模 •????
10. Snowflakeを利⽤している事業の例 •広告配信プラットフォーム •マーケティング⽀援プラットフォーム •デジタルサイネージ •IoTログ基盤 •⼩売企業のデータ分析基盤 •ソーシャルゲーム •社内情報システム管理基盤 •などなど、10以上のプロダクトで採⽤
11. 広告配信プラットフォーム •広告をオークション形式で取引するプラットフォーム •⽉間数千億のリクエスト量になることも •導⼊プロダクト例 •Dynalyst •AirTrack
12. IoTログ基盤 •CAスマートPOP •Bluetoothビーコンの計測ログなど
13. 社内情報システム管理基盤 •1万台以上あるPCの新管理台帳構築プロジェクト •スプレッドシートとSnowflakeの同期による運⽤作業の⾃動化 •時系列データの活⽤による管理状況の可視化
14. Snowflake導⼊のきっかけ
15. Snowflake導⼊のきっかけ •サイバーエージェントグループの中では早くから検討していた Dynalystというプロダクトの例を紹介します •時を同じくして、またはDynalystの事例をうけて社内で複数のプロダクトが Snowflake導⼊の検討をはじめました •きっかけは社内での「SnowflakeというDWHがいいらしい」という噂です •軽い気持ちで実験するくらいの気持ちで試しているうちに 採⽤を決めました
16. Dynalyst • Dynamic Retargeting for Games •スマホ向けリターゲティング広告配信プラットフォーム •トップセールス @⽇本のスマホゲームの中でも⾼いシェア •ユーザごとに最適化した広告を配信 https://www.dynalyst.io
17. 開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 数千億リクエスト/⽉ • ⼊札トラフィック: 約8Gbps • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD
18. もっと知りたい⽅は • ⽉間数千億リクエストをさばく技術 https://logmi.jp/tech/articles/
19. Dynalystでの悩み • ログの転送量がとにかく多い(数TB/day) • 事業の特性上仕⽅がない • データウェアハウスのコスト • ⾦銭的コストが課題だった • データウェアハウスのパフォーマンスが引き出せない • ログの転送量が多いことに起因して、読み込み性能が引き出せていなかった • データウェアハウスの運⽤負荷 • テーブルのローテーションやDWHの空き容量の整理といったメンテナンス作業
20. 費⽤の試算 • 何はともあれ、費⽤が現実的でなければ選択肢に⼊らない • Snowflakeはどれくらいのリソースをどのくらいの時間使うのかがキモ • 厳密な費⽤を⾒積もるのは無理だった • コンピュートリソースをどれくらい利⽤するかが読めなかった • ⼩規模な環境を⽤意して実際に動かすことで費⽤感を把握した • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼ • 以前の環境よりは⾼くならなさそう、という感覚はつかめた
21. 使い勝⼿ • 簡単な集計で使いそうなJOINやGROUP BYなどを⾏った限りは申し分なかった • ある程度まではWarehouseのサイズを上げるほど実⾏時間が短縮された • Warehouseが⽤途別に分けられるので、COPYクエリを同時に多数発⾏してもク エリのキューが詰まってクエリが滞留してしまうという事は起きなかった • sort keyやdist keyを明⽰的に指定しなくても⾃動でクラスタリングしてくれる
22. 運⽤のしやすさ • クラスタのバージョンアップ作業などが不要(基本的にダウンタイムがなさそう) • 異常に重いクエリを投げてしまってもコストが増⼤しない • Virtual Warehouse課⾦なので起動時間だけ気にしておけばOK • ほぼすべての設定がSQLからも操作できて統⼀感がある • MySQLやPostgreSQLプロトコルが使えないかわりに • Web UIが充実している • アダプタやインテグレーションが充実している
23. セキュリティ⾯ • おもにSnowflakeへの各種アプリケーションからのアクセス⽅法 • Snowflakeはインターネットに公開される前提で認証/認可や通信が暗号化され ているため、どこからでもアクセスができ楽になった • 以前はVPN経由でしかDWHにアクセスできなかった • IPアドレス制限やAWS Private Linkによるインターネットを経由しない通信も可能 • PostgreSQLプロトコルなどオープンなプロトコルが利⽤できない代わりに ネットワーク的なアクセス制限が不要になった
24. DWHの安定性 • クエリが集中したり、重いクエリが⾛っているときにクエリ時間が極端に遅く なる状況は利⽤者にとってストレスなので避けたい • Snowflakeは⽤途ごとにVirtual Warehouseが作成でき、それぞれの Warehouseは独⽴しているため、負荷の影響を受けない
25. クエリ性能 • 普段分析で使うようなクエリが許容範囲の性能かどうか • ⽇常的に使う重めのクエリで1-2分以内に応答してほしい • 1ヶ⽉分のデータをインポートして性能を計測後3ヶ⽉分, 半年分とデータ量を 増やしていき、性能が⼤幅に悪化しないことを確認 • ウェアハウスのサイズを2倍にすると、多くのケースでクエリ時間もおおむね半 分になることを確認 • 普段はM〜L, 重いクエリはXLで運⽤することに
26. ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >= ... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、 ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。
27. Snowpipe • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル タイムに取り込んでくれる仕組み • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない • 別途Snowpipe代が掛かる • 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない • 体感的にはそんなに⾼くない • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように なるまで数分だった
28. • S などにデータをアップロードすると⾃動でSnowflakeに取り込んでくれる • ETL処理を時前実装しなくて良い • 取り込み遅延は1〜2分くらい Snowpipe アップロード S イベント通知 subscribe SQS SNS S ⾃分のAWSアカウント SnowflakeのAWSアカウント 取り込み
29. Snowflake導⼊の決定 •様々な⽐較検討をした結果、導⼊を決定 •スモールスタートができるため、旧環境と並⾏稼動ができ、 有事の際にSnowflakeの導⼊とりやめという選択肢が残せた安⼼感 •旧環境と細かい部分での互換性の維持などの調整を除いて スムーズに移⾏ができた •互換性のチェックは効率化できず、エンジニアで⼿分けして⼿動で チェックを⾏いました
30. Snowflake導⼊のTips
31. 運⽤開始後の事故 • 運⽤開始から1年、おおよそ問題なく運⽤ができています • ただし、⼀度だけ盛⼤な事故が発⽣しました
32. 💥突然のDROP TABLE💥
33. 💥突然のDROP TABLE💥 • 正直勘弁してほしい • こんなときどうしますか…？ • データの再import • S にすべてのログが保管されているので最悪やれなくはない • 数年分のデータを⼊れ直すのは時間的にきつい & やりたくない…
34. 👼 UNDROP TABLE 👼 • Snowflakeはテーブルは時系列で保存されているので Fail Safe期間中の任意の地点に復元することができる
35. 💥突然のDROP TABLE💥 • Snowflakeは標準で1⽇〜テーブルの履歴が時系列で維持されている • 削除も例外ではなく、削除という⾏為も戻すことが可能 • さらに履歴を維持する期間を超えたデータも7⽇間は「Fail Safe」という特別 な領域に保管され、ユーザは操作することができない • サポートにお願いするとそこから復元できたりするはず…？ • サポートが介在しない限りユーザは触れないので混乱して危険な操作をすることがなさそう • バックアップの上に最終⼿段が⽤意されてるのはありがたい
36. コスト効率の向上 • Snowflakeは従量課⾦の要素が強い • ウェアハウスが従量課⾦でコストの⼤半を占める • クエリを投げるタイミングを集中させてウェアハウスの利⽤効率を 上げたり、クエリの頻度を⾒直したりする必要がある • 普通は分散させるところを集中させるのがポイント • 結果的にコストは下がった
37. データ保存料⾦は？ • Snowflakeは「圧縮後」のデータに対して保存料⾦が計算される • 実はかなりお得 • Snowflakeに保存するだけで⾃動で圧縮される • 場合によってはcsv等をgzipするより圧縮効率が⾼くなる
38. データの移⾏ • S にあるファイルをSnowflakeに移⾏しました • ⼤きめのWarehouseを複数使い並列に取り込むことで数時間で移⾏が完了 • 総容量60TBくらい(Snowflakeで圧縮後) • computeとstorageが分離されている恩恵を受けました
39. ALTER TABLE 〜 SWAP WITH • 初めて知ったときは感動しました • alter table系のクエリはトランザクションが効かない • テーブル洗い替え系の操作をしている瞬間にクエリが来るとタイミングが悪い とテーブルが存在しない • alter table 〜 swap with 〜をつかうとテーブルの⼊れ替えがatomicに • トランザクションができなくともテーブルのスワップが安全に！
40. Task • 定期実⾏したいようなクエリ(定時集計やテーブルのメンテナンスなど)が Snowflakeで完結する, deleteクエリを毎⽇流すことで定期削除
41. Snowflake活⽤のこれから
42. ⼩売のDX • 詳しくはこれを⾒てください • 140兆円の巨⼤市場、⼩売業界の再発明に挑む開発プロジェクト • https://speakerdeck.com/kurochan/retail-dx-project
43. ⼩売のDXとは
44. ⼩売のDXとは
45. ⼩売のDXとは
46. ⼩売のDXとは
47. ⼩売のDXとは
48. ⼩売のDXとは
49. ⼩売のDXとは
50. PoC案件におけるデータ収集
51. Data Marketplace • ⼩売企業のデータを分析する上で外部データをかけ合わせて分析したい需要 • SnowflakeのMarketplace機能でデータが売買されている
52. Secure Data Sharing • ウェザーニューズ様との連携の例 • サイバーエージェントのSnowflakeアカウント内から気象情報にアクセス •気象情報と掛け合わせたデータ分析が簡単に •気象情報のテーブルはウェザーニューズ様が継続してメンテナンスしてくれる
53. ログの集計(現状) • ログの量が数TB/day(圧縮状態) • 広告の集計処理は複雑になりがち • 集計ロジックを⾃前実装したい • テストコードが書きたい • 分散処理がしたい • Apache Spark on Amazon EMR • クラスタコンピューティングフレームワーク • 分散共有メモリモデル • ScalaやPythonで処理が記述できる &.3
    $MVTUFS .BTUFS 4MBWF 4MBWF 4MBWF 4MBWF
54. Apache SparkのSnowflake Driver • Apache Spark: クラスタコンピューティングフレームワーク • 集計はApache Sparkを使って256コア, 512GB程度のクラスタで実⾏ • データソースとしてSnowflakeを使うことで集計対象のデータ抽出や簡単な 前処理をSnowflakeに寄せることができる https://docs.snowflake.com/ja/user-guide/spark-connector-overview.html
55. Snowpark • Sparkっぽいインターフェイスでアプリケーションコードから Snowflakeが操作できる仕組み
56. Snowpark • Scalaでデータ集計のコードを書くと
57. Snowpark • 裏側ではSQLが⽣成されてSnowflake上で実⾏される • カスタムで定義したコードはUDFとして実⾏される
58. Snowpark • 詳しくはブログを書きました！ https://developers.cyberagent.co.jp/blog/archives/ /