1. ErlangによるSSP側RTB
@ajiyoshi from adingo

2. 広告
HERE!

3. RTB
• Real Time Bidding
• ご存知のとおり、広告の価格をリアル
タイムのオークションで決める仕組み

4. 広告リクエスト
媒体側
広告
Browser
サーバ
（SSP）

5. Bid リクエスト
媒体側
広告
Browser
サーバ 広告主側
（SSP） 広告サーバ
（DSP)

6. Bid
１０
媒体側
広告 ２０
Browser
サーバ 広告主側
（SSP） ３０
広告サーバ
（DSP)
１５

7. オークション
１０
媒体側
広告 ２０
Browser
サーバ 広告主側
（SSP） ３０
広告サーバ
（DSP)
１５
※generally “second price auction”
second highest bid price will be the contract price

8. 勝者の広告を表示
１０
媒体側
広告 ２０
Browser
サーバ 広告主側
（SSP） ３０
広告サーバ
（DSP)
１５

9. 問題
• これを作るとして、どう設計するか

10. cf. DSP
• http://d.hatena.ne.jp/yamaz/20111026
• RTB用のADサーバこそ最強である必
要がある件

11. cf. DSP
• 全SSP分のbidリクエストを受けきるパ
ワーが必要
• 普通のadサーバとして非常に強力であ
る必要がある

12. SSP
• 100億RTB imp x DSP10社 → 1000億bid
• 外部ネットワークアクセス
• ラック内ではない
• 同じL2にぶら下がるわけでもない
• 普通のadサーバならやりたくない

13. 要件
• 堅牢であること
• 高速であること
• < 100msec （可能なら）
• ネットワークIOでブロックしないこと
• 適切なタイムアウト処理（超重要）

14. IOでブロックしない
• マルチスレッド、マルチプロセス
• IO多重化
• select epoll libeioなど
• IO多重化＋イベントドリブン
• libevなど

15. タイムアウトはお ですか

16. タイムアウト(curl)
• CURLOPT_CONNECTTIMEOUT
• CURLOPT_CONNECTTIMEOUT_MS
• CURLOPT_TIMEOUT
• CURLOPT_TIMEOUT_MS

17. なにそれ怖い

18. タイムアウト
• CURLOPT_TIMEOUT_MS
• cURL 関数の実行にかけられる最大のミ
リ秒数。 システムの標準の名前解決を
使うように libcurl をビルドしている場合
は、 接続のタイムアウトは秒単位の精
度となり、最小のタイムアウトは 1 秒と
なります。

19. なにそれも怖い

20. タイムアウト処理
• 個別の接続
• socket APIはコネクションと転送のタイムアウ
トが別…
• 処理全体
• 処理全体でのタイムアウトを記述するのはよ
くある言語だと結構ツラい
• リクエスト毎に監視用のスレッドを立て
る？
• signalを飛ばす？

21. 選択肢
• libev や libeio などを使ってCで書く
• node.js (内部でlibev libeio を使用）
• 軽量プロセスを持つ言語（Erlangなど）

22. Cで書く
• pros
• 動作が早い

23. Cで書く
• cons
• メモリリークが怖い
• マルチスレッドは地獄（特に保守）
• タイムアウト処理の記述が地獄

24. node.jsを使う
• pros
• イベントループやIO多重化を自分で書
かなくていい
• メモリ解放を自分で書かなくていい

25. node.jsを使う
• cons
• コールバック地獄
• シングルスレッド
• タイムアウトは結局地獄
• 枯れていない
• 頻繁なバージョンアップ

26. Erlang
• pros
• 軽量プロセス
• 枯れている＆安定している
• 記述が超楽
• まさにこのためにあるような言語

27. Erlang
• cons
• Erlangを使える技術者が少ない

28. Erlang

29. Erlang
• エリクソンの研究所で開発された言語
• 1998年にオープンソース化
• 軽量プロセスを持つ関数型言語
• TwitterやHerokuなどが使用してたり
• もちろんエリクソンも使用

30. Erlangの利点(1)
• 軽量プロセス
• ユーザプロセス
• コンテキストスイッチが高速
• 1プロセスに最低309ワードのメモリ
• プロセス毎のGC
• アクター同士のメッセージパッシング

31. Erlangの利点(2)
• 再代入がない
• 副作用＋マルチスレッド＝地獄
• 各プロセスは資源を共有しない

32. Erlangの利点(3)
• タイムアウトの実装が超楽
• プロセスが軽量なので監視プロセス
をリクエスト毎に作っても楽勝
• 単にメッセージ受信にタイムアウトを
設定するだけでもよい

33. Erlangの性能
http://dsas.blog.klab.org/archives/51993306.html
TCP echo サーバの秒間処理数

34. klabの人の考察
しかし、CPU負荷をモニタリングしていると、thread版はほんの少し速いだ
けなのにCPUを200% 使いきっており、CPU負荷のうちでも sys が多い状況
になっていました。これは、ネイティブスレッドの コンテキストスイッチ
の負荷だと思います。
なので、最速TCPサーバーの条件とは、基本的にネイティブスレッドではな
く軽量なユーザーランド スレッドかイベント駆動方式で接続の多重化を行
いつつ、なおかつ複数コアを利用するために コア数程度のネイティブス
レッドかプロセスを利用するという物になると思います。

35. やってみた
• RTB処理専用のdaemonをErlangで実装
• 既存システムはErlangでないので
• 既存システムからリクエストを受けて
オークション結果を返す
• 処理全体で120msecタイムアウト

36. 性能
• 約30億 bid/月
• 約1.1億 bid/日（8月の実績）
• ピーク時 約5000 bid/秒
• ※サンプリングによる概算

37. タイムアウト
フロントエンドの応答時間分布（両対数）

38. 堅牢性
• メモリリークは特に観測されていない
• ボトルネックも特になし
• VMを含むクラッシュも今の所なし
• ソースコードわずか2400行
• Cだったら何万行になるか…

39. 要件（再掲）
• 堅牢であること→OK
• 高速であること→OK
• ネットワークIOでブロックしないこと
→OK（軽量プロセスで解決）
• 適切なタイムアウト処理（超重要）
→OK（軽量プロセスで解決）

40. ロバートと私はともによくLispを知っていて、私達の直観を覆すようないかなる 理由も見当た
らなかった。他の誰もがC++やPerlを使っていることは知っていた。 でもそれは私達には何の
意味もないことだった。もし、他の誰もが使っているからと いう理由で技術を選ぶなら、
Windowsを走らせておけばいいのさ。 技術を選択する時は、他の人がどうやっているかなんて
無視して、 何が最適かを見極めることだけを考えるべきだ。
特にベンチャー企業ではそうだ。大企業では、他の大企業がやっているのと 同じようなこと
をしていても良い。ベンチャーは他のベンチャーと同じことを やっていてはいけない。このこ
とに、ベンチャー企業の中に居てさえ 気付いていない人が多いんじゃないかと思う。
平均的な大企業は年に10%成長する。だから、あなたが大企業を経営していて、 他の大企業が
やっているのと全く同じようにやっていれば、 やはり年に10%くらいの成長が期待できるだろ
う。
もちろん、同じ論理はベンチャー企業にも成り立つ。 もしあなたが平均的なベンチャー企業
と同じことをやっていれば、 平均的な成長率が期待できる。問題は、だ。ベンチャー企業の
平均的な成長とは、 すなわち、潰れてしまうということだ。ベンチャー企業の生存率は50%よ
りはるかに 小さい。したがって、ベンチャーをやるなら何か変わったことをしなければなら
ない。 そうでなければ、困ったことになる。

41. 普通の奴らの上をいけ
http://practical-scheme.net/trans/beating-the-averages-j.html

42. cf. adgear trader
• http://ferd.ca/rtb-where-erlang-blooms.html

43. まとめ
• Erlangかわいい
• 細かいIO処理を大量に捌く用途に最適
• それでいて堅牢