Ad tech 20121030
- 1. 贰谤濒补苍驳による厂厂笔侧搁罢叠 @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) １５
- 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 ? 贰谤濒补苍驳を使える技术者が少ない
- 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/秒 ? ※サンプリングによる概算
- 38. 堅牢性 ? メモリリークは特に観測されていない ? ボトルネックも特になし ? VMを含むクラッシュも今の所なし ? ソースコードわずか2400行 ? Cだったら何万行になるか…
- 39. 要件（再掲） ? 堅牢であること→OK ? 高速であること→OK ? ネットワークIOでブロックしないこと →OK（軽量プロセスで解決） ? 適切なタイムアウト処理（超重要） →OK（軽量プロセスで解決）
- 40. ロバートと私はともによくLispを知っていて、私達の直観を覆すようないかなる 理由も見当た らなかった。他の誰もがC++やPerlを使っていることは知っていた。 でもそれは私達には何の 意味もないことだった。もし、他の誰もが使っているからと いう理由で技術を選ぶなら、 Windowsを走らせておけばいいのさ。 技術を選択する時は、他の人がどうやっているかなんて 無視して、 何が最適かを見極めることだけを考えるべきだ。 特にベンチャー企業ではそうだ。大企業では、他の大企業がやっているのと 同じようなこと をしていても良い。ベンチャーは他のベンチャーと同じことを やっていてはいけない。このこ とに、ベンチャー企業の中に居てさえ 気付いていない人が多いんじゃないかと思う。 平均的な大企業は年に10%成長する。だから、あなたが大企業を経営していて、 他の大企業が やっているのと全く同じようにやっていれば、 やはり年に10%くらいの成長が期待できるだろ う。 もちろん、同じ論理はベンチャー企業にも成り立つ。 もしあなたが平均的なベンチャー企業 と同じことをやっていれば、 平均的な成長率が期待できる。問題は、だ。ベンチャー企業の 平均的な成長とは、 すなわち、潰れてしまうということだ。ベンチャー企業の生存率は50%よ りはるかに 小さい。したがって、ベンチャーをやるなら何か変わったことをしなければなら ない。 そうでなければ、困ったことになる。
- 42. cf. adgear trader ? http://ferd.ca/rtb-where-erlang-blooms.html
- 43. まとめ ? Erlangかわいい ? 細かいIO処理を大量に捌く用途に最適 ? それでいて坚牢