Your SlideShare is downloading. ×
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Ad tech 20121030
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ad tech 20121030

3,885

Published on

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

No Downloads
Views
Total Views
3,885
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
33
Comments
0
Likes
26
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
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
  • Transcript

    • 1. ErlangによるSSP側RTB @ajiyoshi from adingo
    • 2. 広告 HERE!
    • 3. RTB• Real Time Bidding• ご存知のとおり、広告の価格をリアル タイムのオークションで決める仕組み
    • 4. 広告リクエスト 媒体側 広告Browser サーバ (SSP)
    • 5. Bid リクエスト 媒体側 広告Browser サーバ 広告主側 (SSP) 広告サーバ (DSP)
    • 6. Bid 10 媒体側 広告 20Browser サーバ 広告主側 (SSP) 30 広告サーバ (DSP) 15
    • 7. オークション 10 媒体側 広告 20 Browser サーバ 広告主側 (SSP) 30 広告サーバ (DSP) 15 ※generally “second price auction”second highest bid price will be the contract price
    • 8. 勝者の広告を表示 10 媒体側 広告 20Browser サーバ 広告主側 (SSP) 30 広告サーバ (DSP) 15
    • 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処理を大量に捌く用途に最適• それでいて堅牢

    ×