アドテクのビッグデータを制するSnowflakeの力 / data-cloud-world-tour-tokyo-2023

イベントページ
https://www.snowflake.com/events/data-cloud-world-tour-tokyo/

セッション説明
このセッションでは、Snowflakeがどのようにして、アドテクで発生する多種多様なビッグデータの一元管理を可能にし、データの真の価値を引き出す方法について詳しく説明します。データサイロの解消から多様なワークロードへの対応、Snowflakeがどのように運用上の課題を解決可能にし、ビジネス価値を引き立てるのかを、具体的な事例と共に解説します。
このセッションを通じて、Snowflakeの優れた特性を理解し、ビッグデータをより効果的に活用するための新たな視野を開くことを目指します。

Transcript

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