Slide 1

Slide 1 text

サイバーエージェントの実践×実験Snowflake 導⼊の経緯から最新機能のトライアルまで How Snowflake Is Used In CyberAgent - Go To the Future 株式会社サイバーエージェント AI事業本部 黒崎 優太 (@kuro_m ) @Snowflake Build.local Japan

Slide 2

Slide 2 text

ࠇ࡚ ༏ଠ 2015೥౓ ৽ଔೖࣾ AIࣄۀຊ෦ DXຊ෦ ΞϓϦӡ༻ηϯλʔ @kurochan @kuro_m88 ج൫ٕज़੹೚ऀ αΠόʔΤʔδΣϯτ CTO౷ׅࣨ

Slide 3

Slide 3 text

Contents • サイバーエージェントグループでのSnowflakeの活⽤状況 • Snowflake導⼊のきっかけ • Snowflake導⼊のTips • Snowflake活⽤のこれから

Slide 4

Slide 4 text

サイバーエージェントグループでの Snowflakeの活⽤状況

Slide 5

Slide 5 text

サイバーエージェントグループについて

Slide 6

Slide 6 text

インターネット広告事業 • 成⻑しつづける市場で国内トップシェア • 運⽤x技術で広告効果を最⼤化するのが強み

Slide 7

Slide 7 text

メディア事業 • ABEMA、Ameba、タップルなど多くのユーザに使われるメディアを 開発し運⽤してきた実績

Slide 8

Slide 8 text

ゲーム事業 • ⼈気タイトルを数多く排出

Slide 9

Slide 9 text

サイバーエージェントグループでのSnowflakeの利⽤状況 • アカウント数 •約20アカウント •データ量 •数百TB •売上規模 •????

Slide 10

Slide 10 text

Snowflakeを利⽤している事業の例 •広告配信プラットフォーム •マーケティング⽀援プラットフォーム •デジタルサイネージ •IoTログ基盤 •⼩売企業のデータ分析基盤 •ソーシャルゲーム •社内情報システム管理基盤 •などなど、10以上のプロダクトで採⽤

Slide 11

Slide 11 text

広告配信プラットフォーム •広告をオークション形式で取引するプラットフォーム •⽉間数千億のリクエスト量になることも •導⼊プロダクト例 •Dynalyst •AirTrack

Slide 12

Slide 12 text

IoTログ基盤 •CAスマートPOP •Bluetoothビーコンの計測ログなど

Slide 13

Slide 13 text

社内情報システム管理基盤 •1万台以上あるPCの新管理台帳構築プロジェクト •スプレッドシートとSnowflakeの同期による運⽤作業の⾃動化 •時系列データの活⽤による管理状況の可視化

Slide 14

Slide 14 text

Snowflake導⼊のきっかけ

Slide 15

Slide 15 text

Snowflake導⼊のきっかけ •サイバーエージェントグループの中では早くから検討していた Dynalystというプロダクトの例を紹介します •時を同じくして、またはDynalystの事例をうけて社内で複数のプロダクトが Snowflake導⼊の検討をはじめました •きっかけは社内での「SnowflakeというDWHがいいらしい」という噂です •軽い気持ちで実験するくらいの気持ちで試しているうちに 採⽤を決めました

Slide 16

Slide 16 text

Dynalyst • Dynamic Retargeting for Games •スマホ向けリターゲティング広告配信プラットフォーム •トップセールス @⽇本のスマホゲームの中でも⾼いシェア •ユーザごとに最適化した広告を配信 https://www.dynalyst.io

Slide 17

Slide 17 text

開発しているシステム概況 • ⼊札リクエスト量: 数⼗万リクエスト / 秒 数千億リクエスト/⽉ • ⼊札トラフィック: 約8Gbps • レスポンスタイム: 100ms以内 • ログの量: 数TB / Day(圧縮状態) • ALL AWS ೔ຊͷೖࡳϦΫΤετඵ ೔ຊΞϝϦΧͷϨεϙϯελΠϜ NTFD

Slide 18

Slide 18 text

もっと知りたい⽅は • ⽉間数千億リクエストをさばく技術 https://logmi.jp/tech/articles/

Slide 19

Slide 19 text

Dynalystでの悩み • ログの転送量がとにかく多い(数TB/day) • 事業の特性上仕⽅がない • データウェアハウスのコスト • ⾦銭的コストが課題だった • データウェアハウスのパフォーマンスが引き出せない • ログの転送量が多いことに起因して、読み込み性能が引き出せていなかった • データウェアハウスの運⽤負荷 • テーブルのローテーションやDWHの空き容量の整理といったメンテナンス作業

Slide 20

Slide 20 text

費⽤の試算 • 何はともあれ、費⽤が現実的でなければ選択肢に⼊らない • Snowflakeはどれくらいのリソースをどのくらいの時間使うのかがキモ • 厳密な費⽤を⾒積もるのは無理だった • コンピュートリソースをどれくらい利⽤するかが読めなかった • ⼩規模な環境を⽤意して実際に動かすことで費⽤感を把握した • ある程度使⽤量を予測して事前にコミットしなくて良いのは安⼼ • 以前の環境よりは⾼くならなさそう、という感覚はつかめた

Slide 21

Slide 21 text

使い勝⼿ • 簡単な集計で使いそうなJOINやGROUP BYなどを⾏った限りは申し分なかった • ある程度まではWarehouseのサイズを上げるほど実⾏時間が短縮された • Warehouseが⽤途別に分けられるので、COPYクエリを同時に多数発⾏してもク エリのキューが詰まってクエリが滞留してしまうという事は起きなかった • sort keyやdist keyを明⽰的に指定しなくても⾃動でクラスタリングしてくれる

Slide 22

Slide 22 text

運⽤のしやすさ • クラスタのバージョンアップ作業などが不要(基本的にダウンタイムがなさそう) • 異常に重いクエリを投げてしまってもコストが増⼤しない • Virtual Warehouse課⾦なので起動時間だけ気にしておけばOK • ほぼすべての設定がSQLからも操作できて統⼀感がある • MySQLやPostgreSQLプロトコルが使えないかわりに • Web UIが充実している • アダプタやインテグレーションが充実している

Slide 23

Slide 23 text

セキュリティ⾯ • おもにSnowflakeへの各種アプリケーションからのアクセス⽅法 • Snowflakeはインターネットに公開される前提で認証/認可や通信が暗号化され ているため、どこからでもアクセスができ楽になった • 以前はVPN経由でしかDWHにアクセスできなかった • IPアドレス制限やAWS Private Linkによるインターネットを経由しない通信も可能 • PostgreSQLプロトコルなどオープンなプロトコルが利⽤できない代わりに ネットワーク的なアクセス制限が不要になった

Slide 24

Slide 24 text

DWHの安定性 • クエリが集中したり、重いクエリが⾛っているときにクエリ時間が極端に遅く なる状況は利⽤者にとってストレスなので避けたい • Snowflakeは⽤途ごとにVirtual Warehouseが作成でき、それぞれの Warehouseは独⽴しているため、負荷の影響を受けない

Slide 25

Slide 25 text

クエリ性能 • 普段分析で使うようなクエリが許容範囲の性能かどうか • ⽇常的に使う重めのクエリで1-2分以内に応答してほしい • 1ヶ⽉分のデータをインポートして性能を計測後3ヶ⽉分, 半年分とデータ量を 増やしていき、性能が⼤幅に悪化しないことを確認 • ウェアハウスのサイズを2倍にすると、多くのケースでクエリ時間もおおむね半 分になることを確認 • 普段はM〜L, 重いクエリはXLで運⽤することに

Slide 26

Slide 26 text

ログのローテーションのしやすさ • TBくらいのテーブルに対して2TB分くらいの削除をした • DELETE FROM table WHARE logged_at >= ... • 数秒でクエリが終了した • メタデータ更新のみか、バックグラウンドで削除が⾏われるようで、 ⼤量のデータの削除が楽 • ⼀定期間経過するとexpireするような機能もあるとさらに嬉しいところ。。

Slide 27

Slide 27 text

Snowpipe • S 等へのファイルのPUTイベントをフックしてSnowflakeにファイルをリアル タイムに取り込んでくれる仕組み • Virtual Warehouseのリソースは使⽤しないのでパフォーマンス影響がない • 別途Snowpipe代が掛かる • 費⽤の計算⽅法がないため、実験してみないと費⽤はわからない • 体感的にはそんなに⾼くない • TB/⽇くらいの勢いでデータを投⼊してもS へのPUTからクエリできるように なるまで数分だった

Slide 28

Slide 28 text

• S などにデータをアップロードすると⾃動でSnowflakeに取り込んでくれる • ETL処理を時前実装しなくて良い • 取り込み遅延は1〜2分くらい Snowpipe アップロード S イベント通知 subscribe SQS SNS S ⾃分のAWSアカウント SnowflakeのAWSアカウント 取り込み

Slide 29

Slide 29 text

Snowflake導⼊の決定 •様々な⽐較検討をした結果、導⼊を決定 •スモールスタートができるため、旧環境と並⾏稼動ができ、 有事の際にSnowflakeの導⼊とりやめという選択肢が残せた安⼼感 •旧環境と細かい部分での互換性の維持などの調整を除いて スムーズに移⾏ができた •互換性のチェックは効率化できず、エンジニアで⼿分けして⼿動で チェックを⾏いました

Slide 30

Slide 30 text

Snowflake導⼊のTips

Slide 31

Slide 31 text

運⽤開始後の事故 • 運⽤開始から1年、おおよそ問題なく運⽤ができています • ただし、⼀度だけ盛⼤な事故が発⽣しました

Slide 32

Slide 32 text

💥突然のDROP TABLE💥

Slide 33

Slide 33 text

💥突然のDROP TABLE💥 • 正直勘弁してほしい • こんなときどうしますか…? • データの再import • S にすべてのログが保管されているので最悪やれなくはない • 数年分のデータを⼊れ直すのは時間的にきつい & やりたくない…

Slide 34

Slide 34 text

👼 UNDROP TABLE 👼 • Snowflakeはテーブルは時系列で保存されているので Fail Safe期間中の任意の地点に復元することができる

Slide 35

Slide 35 text

💥突然のDROP TABLE💥 • Snowflakeは標準で1⽇〜テーブルの履歴が時系列で維持されている • 削除も例外ではなく、削除という⾏為も戻すことが可能 • さらに履歴を維持する期間を超えたデータも7⽇間は「Fail Safe」という特別 な領域に保管され、ユーザは操作することができない • サポートにお願いするとそこから復元できたりするはず…? • サポートが介在しない限りユーザは触れないので混乱して危険な操作をすることがなさそう • バックアップの上に最終⼿段が⽤意されてるのはありがたい

Slide 36

Slide 36 text

コスト効率の向上 • Snowflakeは従量課⾦の要素が強い • ウェアハウスが従量課⾦でコストの⼤半を占める • クエリを投げるタイミングを集中させてウェアハウスの利⽤効率を 上げたり、クエリの頻度を⾒直したりする必要がある • 普通は分散させるところを集中させるのがポイント • 結果的にコストは下がった

Slide 37

Slide 37 text

データ保存料⾦は? • Snowflakeは「圧縮後」のデータに対して保存料⾦が計算される • 実はかなりお得 • Snowflakeに保存するだけで⾃動で圧縮される • 場合によってはcsv等をgzipするより圧縮効率が⾼くなる

Slide 38

Slide 38 text

データの移⾏ • S にあるファイルをSnowflakeに移⾏しました • ⼤きめのWarehouseを複数使い並列に取り込むことで数時間で移⾏が完了 • 総容量60TBくらい(Snowflakeで圧縮後) • computeとstorageが分離されている恩恵を受けました

Slide 39

Slide 39 text

ALTER TABLE 〜 SWAP WITH • 初めて知ったときは感動しました • alter table系のクエリはトランザクションが効かない • テーブル洗い替え系の操作をしている瞬間にクエリが来るとタイミングが悪い とテーブルが存在しない • alter table 〜 swap with 〜をつかうとテーブルの⼊れ替えがatomicに • トランザクションができなくともテーブルのスワップが安全に!

Slide 40

Slide 40 text

Task • 定期実⾏したいようなクエリ(定時集計やテーブルのメンテナンスなど)が Snowflakeで完結する, deleteクエリを毎⽇流すことで定期削除

Slide 41

Slide 41 text

Snowflake活⽤のこれから

Slide 42

Slide 42 text

⼩売のDX • 詳しくはこれを⾒てください • 140兆円の巨⼤市場、⼩売業界の再発明に挑む開発プロジェクト • https://speakerdeck.com/kurochan/retail-dx-project

Slide 43

Slide 43 text

⼩売のDXとは

Slide 44

Slide 44 text

⼩売のDXとは

Slide 45

Slide 45 text

⼩売のDXとは

Slide 46

Slide 46 text

⼩売のDXとは

Slide 47

Slide 47 text

⼩売のDXとは

Slide 48

Slide 48 text

⼩売のDXとは

Slide 49

Slide 49 text

⼩売のDXとは

Slide 50

Slide 50 text

PoC案件におけるデータ収集

Slide 51

Slide 51 text

Data Marketplace • ⼩売企業のデータを分析する上で外部データをかけ合わせて分析したい需要 • SnowflakeのMarketplace機能でデータが売買されている

Slide 52

Slide 52 text

Secure Data Sharing • ウェザーニューズ様との連携の例 • サイバーエージェントのSnowflakeアカウント内から気象情報にアクセス •気象情報と掛け合わせたデータ分析が簡単に •気象情報のテーブルはウェザーニューズ様が継続してメンテナンスしてくれる

Slide 53

Slide 53 text

ログの集計(現状) • ログの量が数TB/day(圧縮状態) • 広告の集計処理は複雑になりがち • 集計ロジックを⾃前実装したい • テストコードが書きたい • 分散処理がしたい • Apache Spark on Amazon EMR • クラスタコンピューティングフレームワーク • 分散共有メモリモデル • ScalaやPythonで処理が記述できる &.3$MVTUFS .BTUFS 4MBWF 4MBWF 4MBWF 4MBWF

Slide 54

Slide 54 text

Apache SparkのSnowflake Driver • Apache Spark: クラスタコンピューティングフレームワーク • 集計はApache Sparkを使って256コア, 512GB程度のクラスタで実⾏ • データソースとしてSnowflakeを使うことで集計対象のデータ抽出や簡単な 前処理をSnowflakeに寄せることができる https://docs.snowflake.com/ja/user-guide/spark-connector-overview.html

Slide 55

Slide 55 text

Snowpark • Sparkっぽいインターフェイスでアプリケーションコードから Snowflakeが操作できる仕組み

Slide 56

Slide 56 text

Snowpark • Scalaでデータ集計のコードを書くと

Slide 57

Slide 57 text

Snowpark • 裏側ではSQLが⽣成されてSnowflake上で実⾏される • カスタムで定義したコードはUDFとして実⾏される

Slide 58

Slide 58 text

Snowpark • 詳しくはブログを書きました! https://developers.cyberagent.co.jp/blog/archives/ /

Slide 59

Slide 59 text

No content