Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
DATA CLOUD WORLD TOUR アドテクのビッグデータを 制するSnowflakeの力 株式会社CARTA HOLDINGS 近森 淳平 氏@pei0804
Slide 2
Slide 2 text
アドテクってどんな世界？
Slide 3
Slide 3 text
アドテクの世界は、猛烈な速度で変化を遂げ、 圧倒的なデータ量を生み出します。
Slide 4
Slide 4 text
右肩上がりに増える現場のデータ活用需要。 しかし、我々のデータ基盤はその需要に、 応えられませんでした。
Slide 5
Slide 5 text
気がつけば、データを見るだけで、 日々疲弊をしてしまっていた。
Slide 6
Slide 6 text
そこに現れたSnowflake。
Slide 7
Slide 7 text
Snowflakeを導入したことで、 データ業務を根本から変えてくれました。
Slide 8
Slide 8 text
そして、導入から1年が経ちました。 今日は、絵に描いた餅ではなく、 食べることのできる餅を紹介します。
Slide 9
Slide 9 text
アジェンダ ● 自己紹介 ● アドテクとデータの関係性 ● 現場のデータ課題 ● なぜSnowflakeなのか？ ● 1年間の振り返りと得られた利点
Slide 10
Slide 10 text
アジェンダ ● 自己紹介 ● アドテクとデータの関係性 ● 現場のデータ課題 ● なぜSnowflakeなのか？ ● 1年間の振り返りと得られた利点
Slide 11
Slide 11 text
自己紹介 ぺい @pei0804 近森淳平(チカモリ ジュンペイ) CARTA HOLDINGS （旧VOYAGE GROUP） Zucks システム局 エンジニア
Slide 12
Slide 12 text
techblog.cartaholdings.co.jp, The Zen of Zucks, 2022/06/10, https://techblog.cartaholdings.co.jp/entry/the-zen-of-zucks
Slide 13
Slide 13 text
アジェンダ ● 自己紹介 ● アドテクとデータの関係性 ● 現場のデータ課題 ● なぜSnowflakeなのか？ ● 1年間の振り返りと得られた利点
Slide 14
Slide 14 text
アドテクにおけるデータとは？
Slide 15
Slide 15 text
アドテクは、多くの業務が、 ソフトウェア上で完結するため、 データはその中心的な役割を果たします。
Slide 16
Slide 16 text
業務活動 = データ アドテクにおけるデータは、業務活動のそのものです。 例えば、広告を表示した。広告がクリックされた。 広告からアクションが発生したなど、それら全てがデータです。 そして、実績データから、予算の消化ペースをコントロールしたり、 広告の適正価格を決定したり、意思決定の材料にも使われます。
Slide 17
Slide 17 text
アドテクのデータの特徴 アドテクのデータを一言で表すと、大量の半構造化データです。 まず、量に関しては、1つのログだけで、億record/dailyを超えます。 半構造化データには、色々な種類がありますが、 よく使われるデータの1つに、広告オークションログがあります。 簡単に説明すると、「広告枠のある場所に訪れたユーザー、 こんな人来たけど広告出したい？」的なやり取りをするログです。 中には色々な情報が入ってるのですが、要はでっかいJSONです。
Slide 18
Slide 18 text
でっかいJSONのスクリーンショットです。
Slide 19
Slide 19 text
データが中心なビジネスなので、 データをコントロールすることは、 必然的に重要になります。
Slide 20
Slide 20 text
アジェンダ ● 自己紹介 ● アドテクとデータの関係性 ● 現場のデータ課題 ● なぜSnowflakeなのか？ ● 1年間の振り返りと得られた利点
Slide 21
Slide 21 text
Zucksって、そもそも何やっている？
Slide 22
Slide 22 text
Zucksのアドテク事業 ● アドネットワーク ● デマンドサイドプラットフォーム（以下DSP） ● アフィリエイト 大きく分けて、3つのプロダクトを構築・運用しています。 チームの体制的には、それぞれにプロダクトチームがついて、 日々事業開発をしています。
Slide 23
Slide 23 text
どんなデータ業務があるか？
Slide 24
Slide 24 text
データ業務と使われている技術 ● レポーティング ○ プロダクトごとに、Amazon Redshift, Amazon Auroraを 使った基盤がある。 ● 分析、機械学習 ○ プロダクトを横断して、BigQueryに統合されている。 ● プロダクト ○ Amazon Auroraを使ったトランザクションシステム。 ※他にも色々ありますが、代表的なものだけ。
Slide 25
Slide 25 text
No content
Slide 26
Slide 26 text
この現場で、何が起きていたのか？
Slide 27
Slide 27 text
データ利活用、大変すぎる。
Slide 28
Slide 28 text
データ利活用とは データを利用したサービスという狭義の意味はもちろん、 既存の製品・サービスの付加価値を向上させる、 新たな事業領域を模索したり、新たなイノベーションの創出 新たな市場の創造を進めたりする手段としても 検討・推進されるものである。 経済産業省「データ利活用のポイント集」 10ページ https://www.meti.go.jp/policy/economy/chizai/chiteki/pdf/datapoint.pdf
Slide 29
Slide 29 text
大変の根底にあったのは、 データのサイロ化。
Slide 30
Slide 30 text
データのサイロ化の何が悪いのか？
Slide 31
Slide 31 text
データのサイロ化は、 利活用のオーバーヘッドを高くする。
Slide 32
Slide 32 text
ケーススタディ。 色んなデータにクエリして、金脈探そう！
Slide 33
Slide 33 text
負荷Lv梅 分析基盤にあるデータにクエリする。
Slide 34
Slide 34 text
No content
Slide 35
Slide 35 text
負荷Lv竹 分析基盤にあるデータと、 特定プロダクトのレポーティングデータにクエリする。
Slide 36
Slide 36 text
No content
Slide 37
Slide 37 text
ここで何らかの方法で、手元で突合する。 とても面倒くさい。
Slide 38
Slide 38 text
負荷Lv松 分析基盤にあるデータと、 レポーティングとアプリDBのデータを見る。
Slide 39
Slide 39 text
No content
Slide 40
Slide 40 text
踏み台に入ってクエリする！ 結果のCSVは、なんか頑張って持ってくる！
Slide 41
Slide 41 text
負荷Lv 鬼 プロダクトを横断して、データを見る。
Slide 42
Slide 42 text
No content
Slide 43
Slide 43 text
データを取ってくるだけで大変！
Slide 44
Slide 44 text
しかも、取ってきたデータもカオス！
Slide 45
Slide 45 text
データを揃えるところで9割。 本質的な仕事が1割程度。 そんな経験ありませんか？
Slide 46
Slide 46 text
そもそもデータ利活用は、ほぼうまくいかない データを使って何かしよう！をやったことある人なら、 身をもって理解してると思いますが、データで新たな価値創造するのは、 どれだけ頑張っても、ほとんどうまくいきません。 そういう世界感の仕事で、データにアクセスする部分に、 高いオーバーヘッドが存在すると、げんなりします。人間だもの。 やってみるのハードルを下げなければ、いつしか人々はやらなくなります。
Slide 47
Slide 47 text
データ利活用よりも手前の話 今回紹介した様な大変さがある場合、利活用に限らず、 データに関連する業務の全てが、大変なケースが多いです。 実際、弊社ではレポーティング業務や、 ちょっとした分析ですら大変な状況でした。
Slide 48
Slide 48 text
データのサイロ化は、 利活用業務のオーバーヘッドを高くする。
Slide 49
Slide 49 text
データがサイロ化していると、 構造的に、生産性向上が難しいと判断し、 まずは、データが一箇所にある状態を作る。
Slide 50
Slide 50 text
それをどこで実現するべきか？ それが、今日のメインテーマです。
Slide 51
Slide 51 text
BigQuery？Redshift？ Auroraは行指向で分析用途には、不向きだったので、 選択肢に入れませんでした。
Slide 52
Slide 52 text
No content
Slide 53
Slide 53 text
アジェンダ ● 自己紹介 ● アドテクとデータの関係性 ● 現場のデータ課題 ● なぜSnowflakeなのか？ ● 1年間の振り返りと得られた利点
Slide 54
Slide 54 text
なぜSnowflakeなのか？
Slide 55
Slide 55 text
既存のデータ基盤の改善で、 うまくやれないんだっけ？
Slide 56
Slide 56 text
既存の基盤を置き換えてでも、 Snowflakeのが、優位性があった。
Slide 57
Slide 57 text
vs BigQuery
Slide 58
Slide 58 text
vs BigQuery 転送コスト 弊社のアプリはAWSに存在します。それらのログは、S3にありました。 これらのログをBigQueryで使用する場合、まずGCPにデータを転送する 必要があり、この過程でAWSからGCPへのデータ転送費用と、 コピーされたログのストレージコストが発生します。 これが、開発工数的にも、費用的にも無視できないコストでした。 一方、SnowflakeをAWSで運用すると、転送費用は一切かからない上、 S3にあるログをSnowflakeにロードするのは、非常に簡単です。 独自で新たな仕組みを用意する必要がありません。 結果として、ログを取り込むのにかかるコストを極限まで削減できます。
Slide 59
Slide 59 text
vs BigQuery チューニング余地 結果を高速に返すのを優先したい。コストを下げるのを優先したい。 そういったニーズに細かく応えれるのがSnowflakeです。 BigQueryの場合、どれもそれなりにやってくれます。 一方で、細かくチューニングはできません（≒せずに済むとも言える）。 全く同じワークロードであっても、Snowflakeのが安く実現できます。 なぜなら、コスト優先で速度落とす、テーブルの計算効率を上げるなど、 様々なコスト削減余地があるからです。 ※9割くらいのワークロードは、チューニングなしで十分です。
Slide 60
Slide 60 text
vs Redshift
Slide 61
Slide 61 text
vs Redshift コンピューティング管理 Redshiftはパフォーマンスの上限が、クラスターごとに決まります。 そのため、異なるクエリの性質（アプリ、分析、レポーティング）に 真面目に対応すると、複数のクラスターの運用が必須となります。 しかし、クラスターとデータの強く紐づいていて、手間がかかります。 この性質が、致命的で、全てのワークロードを集約できる イメージが湧きませんでした。 一方でSnowflakeでは、データへアクセスする権限を割り当てて、 用途に応じて、ウェアハウスサイズを調整するだけで対応可能です。
Slide 62
Slide 62 text
どうやって既存のワークロードを Snowflakeへ移行する？ ※Auroraベースのレポーティング基盤は未着手なので割愛
Slide 63
Slide 63 text
一部だけ、Snowflakeとかやると、 新しいサイロができるだけなので、 当然やります。
Slide 64
Slide 64 text
Redshiftレポーティング基盤移行 dbtを使って、レポーティングを実現していたため、 クエリ資産を書き換えずに、Snowflakeに移行できる状態だったので、 Redshiftで提供してる全てを移行する方針で進めた。 切替日を決め、その日からはSnowflake上で作られたレポートを提供し、 過去のレポートに関しては、RedshiftからS3へUnloadし、 新しいレポートとUnionAllで混ぜる戦略で進めた。 既にRedshiftはシャットダウン済みで、Snowflakeのみで提供中。
Slide 65
Slide 65 text
No content
Slide 66
Slide 66 text
BigQuery分析基盤移行 まずは、すべての分析データをSnowflakeにロードし、 新規の分析業務は、Snowflakeで完結できる様になりました。 既存の機械学習ワークロードは、BigQueryで作られたデータに、 強く依存しているため、一切コードは書き換えない方針へ。 その代わり、高コストな訓練データは、Snowflakeで生成し、GCSへUnload。 BigQueryはクエリするだけにすることで、コストをカット。 現在も、事業クリティカルなワークロードから順番に置き換え中。
Slide 67
Slide 67 text
No content
Slide 68
Slide 68 text
あとは、Snowflakeベースで 基盤を作って、終わり。
Slide 69
Slide 69 text
そして、1年が経過した。
Slide 70
Slide 70 text
アジェンダ ● 自己紹介 ● アドテクとデータの関係性 ● データ管理の課題 ● Snowflake導入の決め手 ● 1年の運用を経てのSnowflakeの利点
Slide 71
Slide 71 text
導入してみて1年。 お世辞抜きに最高。
Slide 72
Slide 72 text
良い点はたくさんあるけど、 あえて、1つに絞るとしたら・・・。
Slide 73
Slide 73 text
運用が楽。
Slide 74
Slide 74 text
技術検証では、見えにくい運用体験。 安心してください。楽です。
Slide 75
Slide 75 text
少ない手間で、多くを成し遂げれる。
Slide 76
Slide 76 text
何故、運用が楽なのか？
Slide 77
Slide 77 text
Snowflakeは何故運用が楽なのか ● 高い安定性 ● ウェアハウスが、とにかく便利 ● 質の高いサポート体制 ● 日本のコミュニティが活発
Slide 78
Slide 78 text
Snowflakeは何故運用が楽なのか ● 高い安定性 ● ウェアハウスが、とにかく便利 ● 質の高いサポート体制 ● 日本のコミュニティが活発
Slide 79
Slide 79 text
安定していることは、素晴らしい 1年間の運用で、Snowflakeによる障害が一切ありませんでした。 弊社のチームは、私、新卒1名、業務委託1名（週3日）で、 複数のプロダクトのデータインフラを開発・運用しています。 まだ盤石な体制ではありませんが、高い安定性のおかげで、 Snowflakeベースの基盤構築も、想像よりも早く完了できました。
Slide 80
Slide 80 text
安定していることは、ビジネス価値 データ駆動のビジネスで継続的な価値を提供するには、 データ基盤の安定性が不可欠です。Snowflakeが安定して動くことで、 我々が提供しているビジネス価値の持続性に寄与しています。 仮にSnowflakeが派手に止まってしまうと、 我々のビジネスもそれなりに困ってしまうため、とても助かってます。
Slide 81
Slide 81 text
高い安定性に、驚きはない 実は、大きな障害がないことに、驚きはありません。 導入前に、Snowflakeについて色々調べた時の感想が、 「良い意味で、枯れた技術をうまく使っているので、安定してそう。」だったの で、多少は障害に遭遇することがあったとしても、 そんなに酷いことにはならないだろうと想定していました。 ※もちろん絶対に起きないとは考えていません。
Slide 82
Slide 82 text
Snowflakeは何故運用が楽なのか ● 高い安定性 ● ウェアハウスが、とにかく便利 ● 質の高いサポート体制 ● 日本のコミュニティが活発
Slide 83
Slide 83 text
ワークロードにフィットさせやすい ● レポーティング：定期的にクエリ実行。 ● 分析：アドホックなクエリの実行。 ● 機械学習：大量のコンピューティングリソース要求。 これらの異なる要件に、適切なウェアハウスを割り当てることで、 最適な性能を簡単に提供できます。 その操作性と効率性は、思っていた以上に便利で楽です。
Slide 84
Slide 84 text
けど、適切なサイズの割当大変でしょう？
Slide 85
Slide 85 text
簡単です。
Slide 86
Slide 86 text
ウェアハウスサイズの選択とその柔軟性 ● Large：10秒でのレスポンス。1日1万円。 ● Medium：30秒でのレスポンス。1日5千円。 適切なサイズ選びはワークロード次第ですが、 このようなシンプルな選択肢でコストをコントロールできます。 特筆すべきは、ダウンタイムなくサイズを変更できる点です。 これにより、非常に柔軟に運用が可能となります。
Slide 87
Slide 87 text
Snowflakeは何故運用が楽なのか ● 高い安定性 ● ウェアハウスが、とにかく便利 ● 質の高いサポート体制 ● 日本のコミュニティが活発
Slide 88
Slide 88 text
びっくりするくらい ほしい答えが返ってくる。
Slide 89
Slide 89 text
私が気に入ってる点のひとつを紹介すると、 使わせたいものを提案してくるんじゃなくて、 使ったほうがいいものを提案してくれる。
Slide 90
Slide 90 text
本質的な答えを返してくれる。
Slide 91
Slide 91 text
パートナーに近い存在。
Slide 92
Slide 92 text
そして、びっくりするくらい、 ドキュメントが分かりやすい。
Slide 93
Slide 93 text
読んでみてください。 ちゃんと読めるので驚きます。
Slide 94
Slide 94 text
Snowflakeは何故運用が楽なのか ● 高い安定性 ● ウェアハウスが、とにかく便利 ● 質の高いサポート体制 ● 日本のコミュニティが活発
Slide 95
Slide 95 text
日本コミュニティが活発 今日のイベントを含めて、日本コミュニティが活発です。 ユーザーグループ主導で、イベントや講座が作られたりしてます。 内容は初学者から上級者まで、みんな楽しめる工夫がされています。 興味があれば、是非ユーザーコミュニティに顔を出してみてください。 Snowflake User Groups Japan https://usergroups.snowflake.com/japan/
Slide 96
Slide 96 text
運用とコミュニティ関係ある？
Slide 97
Slide 97 text
活発なコミュニティ、多面的な価値 活発なコミュニティは、様々な価値をもたらします。 日本語で読める情報が増加し、新規ユーザーが参入しやすくなります。 多様な人々が増えると、多様な知見がコミュニティに共有されます。 ここからビジネスシナジーを生まれることもあるでしょう。 このような流れの結果として、日本がSnowflakeにとって、 重要な投資対象となり、ビジネス加速の源泉となる（はず）。 上記に書いた様々な利点が、日々の運用効率に、多面的に効いてきます。
Slide 98
Slide 98 text
まとめ
Slide 99
Slide 99 text
運用が楽なのは、本当にいいぞ
Slide 100
Slide 100 text
DATA CLOUD WORLD TOUR