Ruby World Conference 2019 rubyによる超大量データ配信

Ruby World Conference 2019 rubyによる超大量データ配信

1. 1. Rubyによる超大量データ配信 Ruby World Conference 2019 Supership CTO Daisuke Yamazaki
2. 2. 2 About me Supership CTO Daisuke Yamazaki Supership 取締役 CTO 2006年 スケールアウトを創業 2013年 買収されKDDIグループ入り 2015年 会社が合併し、Supershipとして再出発
3. 3. 3 今日話す順番 ● 弊社の紹介 ● Rubyでいかに大量配信システムを構築したか ● Rubyでいかにビジネスニーズと相対してきたか 今日のアジェンダは以下の通りです （所要時間：３０分）
4. 4. 4Confidential 会社概要 グループ会社 エージェンシー不正広告対策 KDDIから出資を受けるSupershipホールディングスの子会社として、 2015年11月設立。 KDDIの戦略子会社として、インターネット分野で幅広く事業を推進。 AI・データ分析
5. 5. 5 サービス概要 国内最大級広告配信プラットフォーム「Scaleout Ad Platform」の提供 Ad Platform上の主なプロダクト ▼Ad Generation インプレッション数：約450億／月 登録メディア数：約6,000apps・sites 主要メディア：ジモティー、グノシー、ニコニコ動画、有名メディア多数 ▼ScaleOut DSP リクエスト数：約5,000億/月
6. 6. 6 About ScaleoutAdPlatformについて カジュアル（＝安価）にあらゆる広告配信ニーズを満 たすべく開発された純国産広告配信管理システム （弊社メインプロダクト） 1. 現在総アクセスは月間一兆ほど 2. SSP/DSP/屋外広告/OEMなど、その他デジタル広 告配信に関することなら何でも対応可能
7. 7. 7 Rubyと配信システムについて
8. 8. 8 全体概要 Logs 広告案件データ(PostgreSQL) 配信管理 システム 集計管理 システム 配信部分 C++, ruby, swig 独自DB 管理システム ほとんどRails 配信サーバ C++サーバ
9. 9. 9 配信部分 Logs 広告案件データ(PostgreSQL) 配信管理 システム 集計管理 システム 配信部分 C++, ruby, swig 独自DB 管理システム ほとんどRails 配信サーバ C++サーバ
10. 10. 10 配信部分 • 複数プロセスがSharedMemoryを介してデー タをやりとり 広告案件データ(SharedMemory) C++サーバ User Access 管理プログラム群 管理DB
11. 11. 11 データの管理はruby+swigで 管理DBからＤＢアップデート用DSLを作成し、各ADSVRで実 行することにより、Sharedメモリを書き換える ADServer DB C++API,SwigなRuby スクリプトを生成 ADServer ADServer 各ADServer loader = SoAdsScheduleLoader.new loader.start_create_adsshm loader.add_constraint(:constraintid => "0", :expression => "true;") loader.add_constraint(:constraintid => "true_func", :expression => "true;") loader.add_constraint(:constraintid => "rtb-common-template", :expression => <<-EOT) (function() { var result = candidate_context_get("rtb_result"); set_adrequest_cache("user-common-html", result.template_callback()); return true; })(); EOT
12. 12. 12 データ反映用DSL（抜粋） loader = SoAdsScheduleLoader.new loader.start_create_adsshm loader.add_constraint(:constraintid => "0", :expression => "true;”) loader.add_constraint(:constraintid => "true_func", :expression => "true;”) loader.add_constraint(:constraintid => "rtb-common-template", :expression => <<-EOT) (function() { var result = candidate_context_get("rtb_result"); set_adrequest_cache("user-common-html", result.template_callback()); return true; })(); EOT # DSL(Ruby Ofcource)
13. 13. 13 DSLがrubyでうれしいこと(その１) tl = SoAdsTreeLoader.new tl.add("2075500479","784200084") tl.add("2075500768","2075500767") tl.add("2075500505","2075500503") SharedMemoryのデータレイアウトが変わってもDSLは一緒な ので、バージョンアップ時のデータ移行が簡単 データの互換性をrubyレベルで担保できる
14. 14. 14 DSLがrubyでうれしいこと(その2) has_var_loader_class = SoAdsVarLoader rescue false vl = SoAdsVarLoader.new if has_var_loader_class Rubyなので、メタプログラミングと組み合わせてやりたい放題 新機能をクラス化して、クラスが存在するときだけ 新機能を実行させるなど自由自在。
15. 15. 15 集計部分 • 配信サーバ側で一次処理、集計サーバでマージ集計 • 一次集計はログ形式を工夫することで速度を稼ぐ • 分散処理な為、基本集計に関しては全部rubyでも間に合ってる
16. 16. 16 集計システム概要 広告案件データ(PostgreSQL) マージ＆ロード 集計システム (Rails) Logs 一次集計 (Ruby&C++Extention) 配信サーバ processedLog
17. 17. 17 一次集計 配信サーバ側で一次処理を行い、データを圧縮 (数１００MB→数100KBに) またログ形式を工夫することで速度を稼ぐ 色々間に合わなかったので、ここはC++Extention Logs 一次集計 (Ruby&C++Extention) 配信サーバ processedLog
18. 18. 18 マージ集計 広告案件データ (PostgreSQL) マージ&ロード（ruby) 各ADSVRで一次集計されたデータをマージ集計し、 DBに流し込み(Rubyでもなんとかなってる)。 processedLog
19. 19. 19 スケーラビリティについてのまとめ • だいたいrubyでなんとかなってる • 速度がどうしても稼げないところはC++など • 上手に役割分担させることで一兆アクセスでもいけてる
20. 20. 20 Rubyとビジネスについて
21. 21. 21 About Scaleout AdPlatform ScaleOut Ad Platform Supership Inc. TagManagement DMP DSP SSP 3rdParty AdServer Video Reward Video Ads PMPOEM
22. 22. 22 デジタル広告業界を取り巻く状況
23. 23. 23 大企業とベンチャーの相性について 理想 ベンチャーの機動力と大企業のリソースを合わせてうまいことやる 現実 • 大企業そんなにスピード早くない • 突然大企業側が本気出したときに案件のデカさに ベンチャー側が耐えられない（こっちが非常に多い！）
24. 24. 24 ベンチャーとして戦い続けるにはどうすればいいか？ 起業前に1ヶ月ほど考えた
25. 25. 25 大企業と協業するにあたって出した結論 • 超スケーラビリティがあって • 超柔軟性があって • 超落ちない 超すごいシステムがあれば大企業の要望に答えられる
26. 26. 26 実装について考えたこと
27. 27. 27 超すごいシステムを作るにあたって考えたこと 普通にプログラムを書いただけだと、普通のプロダクトに なってしまうだろう →成功しているOSSやシステムを参考にすれば 何かしら知見が得られるはずと考えた
28. 28. 28 参考にしたポイント 1. 古くからあるOSS →どうやって長い間成長できたのかを分析 →思想にたどり着けるはず 2. 新しく出たOSS →既存の問題を解くべく現れたはず →差分を見れば思想にたどり着けるはず
29. 29. 29 設計にあたって参考にしたOSSなど • RAID • qmail • Emacs, Lisp • (もちろん）Ruby, Rails
30. 30. 30 RAID 構成するコンポーネントが不安定だからとい って全体の安定性を諦める必要はない
31. 31. 31 qmail • Sendmailの対抗（今はPostfix？） 複数のプログラムがお互いを過度に信用 せず、協調してシステムを構築する
32. 32. 32 Emacs(Lisp), Firefox(JS) 描画エンジン＋ EmacsLisp 描画エンジン＋ JavaScript 言語を内蔵していて、機能をあとからじゃんじゃん足せる
33. 33. 33 Emacs(Lisp), Firefox(JS) 今時のユーザからのソフトウェアへの要求は余りに多く， プログラマ にはほとんど予想しきれない． （略）ユーザの望みを完璧に叶えるソ フトウェアをプログラマが供給できなくとも， プログラマには拡張で きるソフトウェアを供給することはできる (ポール・グラハム On Lispより)
34. 34. 34 なぜRuby及びRailsを選んだか？ 会社立ち上げ当時(2006年)、開発機のOSはFreeBSD で、言語はさておき、よいORMを探していた。 Catalystだ！→ CPAN地獄にはまり挫折 PHPだ！ → ORMがほぼなかった(当時) Javaだ！ → PHPと同様 Rails? → インストール一発！AR最高！ ということでRails(当時1.1)になりました ぶっちゃけたまたまですが、人にも異様に恵まれて とてもよい選択だったと思います。
35. 35. 35 実際の実装について
36. 36. 36 広告システムの正体 「広告システムとは」 その瞬間の状況に応じた最適なコンテンツ (＝ Markup Languageで記述された小さなテキスト片)を 超柔軟かつ超高速に選択し、配信し、集計できる仕組み
37. 37. 37 小さなHTML片？ 広告クリエイティブの正体はテキストと素材データ - Banner(gif,jpg,flash,text) - TextMail - 3rdParty Tag - Video Ads - InGame Ads - Etc.. Text(Metadata) ＋ Raw Material (gif,jpg,swf,flv) 正体は?
38. 38. 38 ScaleoutAdPlatformの構成 コンテンツ配信管理システム(socdm.com) （配信及びログ集計） 広告配信システム 広告アプリA 広告アプリB 広告アプリC まず汎用の配信システムを作り、 その上に汎用の広告配信システムを作り、 更にその上に広告アプリとしてSSP/DSPを構築
39. 39. 39 なぜ別々に作らなかったか？ すでに数千億アクセスをさばいており新規のアプリも 頑強なシステムの上でアプリを作るため、安定性が高い 長い時間かけて練られて 実績もあるシステムが土台としてある 安定性が高いものが最初から作れる コンテンツ配信管理システム(socdm.com) （配信及びログ集計） 広告配信システム 広告アプリ１ 広告アプリ２ NewApp
40. 40. 40 広告システムに求められる要件（再掲） • 超スケーラビリティがあって • 超柔軟性があって • 超落ちない 配信サーバは当時Cで書かれてたので、 頻繁にアップデートしたくなかった。 →配信サーバに手を入れることなく任意の機能追加ができればいいと 考えた。
41. 41. 41 ビジネスロジックをシステムから分離させた 管理DBにビジネスロジックを登録するとADSVRに 自動でロードされる (＝新ロジックの実装にADSVRのVerUp必要なし) ADServer DB （IncludingBusinessLogic） BusinessLogic Description Language ADServer ADServer 各ADServer loader = SoAdsScheduleLoader.new loader.start_create_adsshm loader.add_constraint(:constraintid => "0", :expression => "true;") loader.add_constraint(:constraintid => "true_func", :expression => "true;") loader.add_constraint(:constraintid => "rtb-common-template", :expression => <<-EOT) (function() { var result = candidate_context_get("rtb_result"); set_adrequest_cache("user-common-html", result.template_callback()); return true; })(); EOT
42. 42. 42 ビジネスロジック記述言語？ loader.add_constraint(:constraintid => "rtb-common-template", :expression => <<-EOT) (function() { var result = candidate_context_get("rtb_result"); set_adrequest_cache("user-common-html", result.template_callback()); return true; })(); EOT ぶっちゃけJavaScriptです。 というかADSVRにJSエンジン積んでます(SpiderMonkey)
43. 43. 43 JavaScriptの嬉しさ • JavaScriptなので、やりたい放題 • 設定するお客さんもまぁ許容してくれる(最初はSchemeとか検討し ました) • Google(v8)とかMozillaが勝手にエンジンを早くしてくれるかも？ →ビジネスロジックであるJSの生成はrubyで行ったわけですが、 実際それは非常にうまく機能し、大企業の要望を満たすことができま した。
44. 44. 44 Yconbinator ポール・グラハムの言葉（その２） Beating The Averages（普通のやつらの上を行け 2001年） http://pactical-scheme.net/trans/beating-the-averages-j.html 私達のソフトウェアがユニークだったのは、それが主にLispと呼ばれ る プログラミング言語で書かれていたからだ。 (略）そして、パワー において劣る他の言語を使っている競争相手に対して、 Lispは強力な アドバンテージとなった。
45. 45. 45 当時（2006年）私が思ったこと あれ？ポール・グラハムはLispでライバルを蹴散らしたけど、 それって当時Ruby/Rails相当をもってたってことじゃない？ →もう確かめる方法はないのですが、私にとってのLispはRubyで、 実際戦い抜くことができてます。たぶんrubyでなかったら途中でビジ ネスが頓挫していた可能性は高かったと思います。
46. 46. 46 まとめ • Rubyで超大規模システムを構築することはもはや当たり前 • 起業は海の向こうだけの話ではなく、我々でも十分可能 （でも結構大変） • プログラミングはエンジニアにパワーを与えてくれて、世界を変え ることができる
47. 47. 47 ご清聴ありがとうございました