ErlangによるSSP側RTB    @ajiyoshi from adingo
広告 HERE!
RTB• Real Time Bidding• ご存知のとおり、広告の価格をリアル タイムのオークションで決める仕組み
広告リクエスト          媒体側           広告Browser          サーバ          (SSP)
Bid リクエスト          媒体側           広告Browser          サーバ     広告主側          (SSP)   広告サーバ                  (DSP)
Bid                  10          媒体側           広告     20Browser          サーバ               広告主側          (SSP)    30      ...
オークション                             10                      媒体側                      広告      20       Browser              ...
勝者の広告を表示                  10          媒体側           広告     20Browser          サーバ               広告主側          (SSP)    30 ...
問題• これを作るとして、どう設計するか
cf. DSP• http://d.hatena.ne.jp/yamaz/20111026 • RTB用のADサーバこそ最強である必   要がある件
cf. DSP• 全SSP分のbidリクエストを受けきるパ ワーが必要• 普通のadサーバとして非常に強力であ る必要がある
SSP• 100億RTB imp x DSP10社 → 1000億bid• 外部ネットワークアクセス • ラック内ではない • 同じL2にぶら下がるわけでもない • 普通のadサーバならやりたくない
要件• 堅牢であること• 高速であること • < 100msec (可能なら)• ネットワークIOでブロックしないこと• 適切なタイムアウト処理(超重要)
IOでブロックしない• マルチスレッド、マルチプロセス• IO多重化 • select epoll libeioなど• IO多重化+イベントドリブン • libevなど
タイムアウトはお ですか
タイムアウト(curl)• CURLOPT_CONNECTTIMEOUT• CURLOPT_CONNECTTIMEOUT_MS• CURLOPT_TIMEOUT• CURLOPT_TIMEOUT_MS
なにそれ怖い
タイムアウト•   CURLOPT_TIMEOUT_MS    •   cURL 関数の実行にかけられる最大のミ        リ秒数。 システムの標準の名前解決を        使うように libcurl をビルドしている場合        ...
なにそれも怖い
タイムアウト処理•   個別の接続    •   socket APIはコネクションと転送のタイムアウ        トが別…•   処理全体    •   処理全体でのタイムアウトを記述するのはよ        くある言語だと結構ツラい   ...
選択肢• libev や libeio などを使ってCで書く• node.js (内部でlibev libeio を使用)• 軽量プロセスを持つ言語(Erlangなど)
Cで書く• pros • 動作が早い
Cで書く• cons • メモリリークが怖い • マルチスレッドは地獄(特に保守) • タイムアウト処理の記述が地獄
node.jsを使う• pros • イベントループやIO多重化を自分で書  かなくていい• メモリ解放を自分で書かなくていい
node.jsを使う•   cons    •   コールバック地獄    •   シングルスレッド    •   タイムアウトは結局地獄    •   枯れていない        •   頻繁なバージョンアップ
Erlang• pros • 軽量プロセス • 枯れている&安定している • 記述が超楽 • まさにこのためにあるような言語
Erlang• cons • Erlangを使える技術者が少ない
Erlang
Erlang• エリクソンの研究所で開発された言語• 1998年にオープンソース化• 軽量プロセスを持つ関数型言語• TwitterやHerokuなどが使用してたり • もちろんエリクソンも使用
Erlangの利点(1)• 軽量プロセス • ユーザプロセス • コンテキストスイッチが高速 • 1プロセスに最低309ワードのメモリ • プロセス毎のGC • アクター同士のメッセージパッシング
Erlangの利点(2)• 再代入がない • 副作用+マルチスレッド=地獄 • 各プロセスは資源を共有しない
Erlangの利点(3)• タイムアウトの実装が超楽 • プロセスが軽量なので監視プロセス  をリクエスト毎に作っても楽勝• 単にメッセージ受信にタイムアウトを  設定するだけでもよい
Erlangの性能http://dsas.blog.klab.org/archives/51993306.html       TCP echo サーバの秒間処理数
klabの人の考察しかし、CPU負荷をモニタリングしていると、thread版はほんの少し速いだけなのにCPUを200% 使いきっており、CPU負荷のうちでも sys が多い状況になっていました。これは、ネイティブスレッドの コンテキストスイッチ...
やってみた• RTB処理専用のdaemonをErlangで実装 • 既存システムはErlangでないので • 既存システムからリクエストを受けて  オークション結果を返す• 処理全体で120msecタイムアウト
性能• 約30億 bid/月• 約1.1億 bid/日(8月の実績)• ピーク時 約5000 bid/秒 • ※サンプリングによる概算
タイムアウトフロントエンドの応答時間分布(両対数)
堅牢性• メモリリークは特に観測されていない• ボトルネックも特になし• VMを含むクラッシュも今の所なし• ソースコードわずか2400行 • Cだったら何万行になるか…
要件(再掲)•   堅牢であること→OK•   高速であること→OK•   ネットワークIOでブロックしないこと    →OK(軽量プロセスで解決)•   適切なタイムアウト処理(超重要)    →OK(軽量プロセスで解決)
ロバートと私はともによくLispを知っていて、私達の直観を覆すようないかなる 理由も見当たらなかった。他の誰もがC++やPerlを使っていることは知っていた。 でもそれは私達には何の意味もないことだった。もし、他の誰もが使っているからと いう理...
普通の奴らの上をいけhttp://practical-scheme.net/trans/beating-the-averages-j.html
cf. adgear trader• http://ferd.ca/rtb-where-erlang-blooms.html
まとめ• Erlangかわいい• 細かいIO処理を大量に捌く用途に最適• それでいて堅牢
Upcoming SlideShare
Loading in...5
×

Ad tech 20121030

4,023

Published on

0 Comments
26 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
4,023
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
34
Comments
0
Likes
26
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Ad tech 20121030

    1. 1. ErlangによるSSP側RTB @ajiyoshi from adingo
    2. 2. 広告 HERE!
    3. 3. RTB• Real Time Bidding• ご存知のとおり、広告の価格をリアル タイムのオークションで決める仕組み
    4. 4. 広告リクエスト 媒体側 広告Browser サーバ (SSP)
    5. 5. Bid リクエスト 媒体側 広告Browser サーバ 広告主側 (SSP) 広告サーバ (DSP)
    6. 6. Bid 10 媒体側 広告 20Browser サーバ 広告主側 (SSP) 30 広告サーバ (DSP) 15
    7. 7. オークション 10 媒体側 広告 20 Browser サーバ 広告主側 (SSP) 30 広告サーバ (DSP) 15 ※generally “second price auction”second highest bid price will be the contract price
    8. 8. 勝者の広告を表示 10 媒体側 広告 20Browser サーバ 広告主側 (SSP) 30 広告サーバ (DSP) 15
    9. 9. 問題• これを作るとして、どう設計するか
    10. 10. cf. DSP• http://d.hatena.ne.jp/yamaz/20111026 • RTB用のADサーバこそ最強である必 要がある件
    11. 11. cf. DSP• 全SSP分のbidリクエストを受けきるパ ワーが必要• 普通のadサーバとして非常に強力であ る必要がある
    12. 12. SSP• 100億RTB imp x DSP10社 → 1000億bid• 外部ネットワークアクセス • ラック内ではない • 同じL2にぶら下がるわけでもない • 普通のadサーバならやりたくない
    13. 13. 要件• 堅牢であること• 高速であること • < 100msec (可能なら)• ネットワークIOでブロックしないこと• 適切なタイムアウト処理(超重要)
    14. 14. IOでブロックしない• マルチスレッド、マルチプロセス• IO多重化 • select epoll libeioなど• IO多重化+イベントドリブン • libevなど
    15. 15. タイムアウトはお ですか
    16. 16. タイムアウト(curl)• CURLOPT_CONNECTTIMEOUT• CURLOPT_CONNECTTIMEOUT_MS• CURLOPT_TIMEOUT• CURLOPT_TIMEOUT_MS
    17. 17. なにそれ怖い
    18. 18. タイムアウト• CURLOPT_TIMEOUT_MS • cURL 関数の実行にかけられる最大のミ リ秒数。 システムの標準の名前解決を 使うように libcurl をビルドしている場合 は、 接続のタイムアウトは秒単位の精 度となり、最小のタイムアウトは 1 秒と なります。
    19. 19. なにそれも怖い
    20. 20. タイムアウト処理• 個別の接続 • socket APIはコネクションと転送のタイムアウ トが別…• 処理全体 • 処理全体でのタイムアウトを記述するのはよ くある言語だと結構ツラい • リクエスト毎に監視用のスレッドを立て る? • signalを飛ばす?
    21. 21. 選択肢• libev や libeio などを使ってCで書く• node.js (内部でlibev libeio を使用)• 軽量プロセスを持つ言語(Erlangなど)
    22. 22. Cで書く• pros • 動作が早い
    23. 23. Cで書く• cons • メモリリークが怖い • マルチスレッドは地獄(特に保守) • タイムアウト処理の記述が地獄
    24. 24. node.jsを使う• pros • イベントループやIO多重化を自分で書 かなくていい• メモリ解放を自分で書かなくていい
    25. 25. node.jsを使う• cons • コールバック地獄 • シングルスレッド • タイムアウトは結局地獄 • 枯れていない • 頻繁なバージョンアップ
    26. 26. Erlang• pros • 軽量プロセス • 枯れている&安定している • 記述が超楽 • まさにこのためにあるような言語
    27. 27. Erlang• cons • Erlangを使える技術者が少ない
    28. 28. Erlang
    29. 29. Erlang• エリクソンの研究所で開発された言語• 1998年にオープンソース化• 軽量プロセスを持つ関数型言語• TwitterやHerokuなどが使用してたり • もちろんエリクソンも使用
    30. 30. Erlangの利点(1)• 軽量プロセス • ユーザプロセス • コンテキストスイッチが高速 • 1プロセスに最低309ワードのメモリ • プロセス毎のGC • アクター同士のメッセージパッシング
    31. 31. Erlangの利点(2)• 再代入がない • 副作用+マルチスレッド=地獄 • 各プロセスは資源を共有しない
    32. 32. Erlangの利点(3)• タイムアウトの実装が超楽 • プロセスが軽量なので監視プロセス をリクエスト毎に作っても楽勝• 単にメッセージ受信にタイムアウトを 設定するだけでもよい
    33. 33. Erlangの性能http://dsas.blog.klab.org/archives/51993306.html TCP echo サーバの秒間処理数
    34. 34. klabの人の考察しかし、CPU負荷をモニタリングしていると、thread版はほんの少し速いだけなのにCPUを200% 使いきっており、CPU負荷のうちでも sys が多い状況になっていました。これは、ネイティブスレッドの コンテキストスイッチの負荷だと思います。なので、最速TCPサーバーの条件とは、基本的にネイティブスレッドではなく軽量なユーザーランド スレッドかイベント駆動方式で接続の多重化を行いつつ、なおかつ複数コアを利用するために コア数程度のネイティブスレッドかプロセスを利用するという物になると思います。
    35. 35. やってみた• RTB処理専用のdaemonをErlangで実装 • 既存システムはErlangでないので • 既存システムからリクエストを受けて オークション結果を返す• 処理全体で120msecタイムアウト
    36. 36. 性能• 約30億 bid/月• 約1.1億 bid/日(8月の実績)• ピーク時 約5000 bid/秒 • ※サンプリングによる概算
    37. 37. タイムアウトフロントエンドの応答時間分布(両対数)
    38. 38. 堅牢性• メモリリークは特に観測されていない• ボトルネックも特になし• VMを含むクラッシュも今の所なし• ソースコードわずか2400行 • Cだったら何万行になるか…
    39. 39. 要件(再掲)• 堅牢であること→OK• 高速であること→OK• ネットワークIOでブロックしないこと →OK(軽量プロセスで解決)• 適切なタイムアウト処理(超重要) →OK(軽量プロセスで解決)
    40. 40. ロバートと私はともによくLispを知っていて、私達の直観を覆すようないかなる 理由も見当たらなかった。他の誰もがC++やPerlを使っていることは知っていた。 でもそれは私達には何の意味もないことだった。もし、他の誰もが使っているからと いう理由で技術を選ぶなら、Windowsを走らせておけばいいのさ。 技術を選択する時は、他の人がどうやっているかなんて無視して、 何が最適かを見極めることだけを考えるべきだ。特にベンチャー企業ではそうだ。大企業では、他の大企業がやっているのと 同じようなことをしていても良い。ベンチャーは他のベンチャーと同じことを やっていてはいけない。このことに、ベンチャー企業の中に居てさえ 気付いていない人が多いんじゃないかと思う。平均的な大企業は年に10%成長する。だから、あなたが大企業を経営していて、 他の大企業がやっているのと全く同じようにやっていれば、 やはり年に10%くらいの成長が期待できるだろう。もちろん、同じ論理はベンチャー企業にも成り立つ。 もしあなたが平均的なベンチャー企業と同じことをやっていれば、 平均的な成長率が期待できる。問題は、だ。ベンチャー企業の平均的な成長とは、 すなわち、潰れてしまうということだ。ベンチャー企業の生存率は50%よりはるかに 小さい。したがって、ベンチャーをやるなら何か変わったことをしなければならない。 そうでなければ、困ったことになる。
    41. 41. 普通の奴らの上をいけhttp://practical-scheme.net/trans/beating-the-averages-j.html
    42. 42. cf. adgear trader• http://ferd.ca/rtb-where-erlang-blooms.html
    43. 43. まとめ• Erlangかわいい• 細かいIO処理を大量に捌く用途に最適• それでいて堅牢
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×