1. 平均レスポンスタイム50msをPerlでry
Tatsuro Hisamori

2. 改め

3. アドテク業界って
最近こうなってます
Tatsuro Hisamori

4. アドテク?
• 広告技術(Ad Tech)
• 狭義にはネット広告関連技術

5. 広告の目的?
• 広告が成立する条件
• “出す”場所がある
• “見る”人がいる
• ”出稿”したい誰かがいる
• 広告枠 : オーディエンス : 広告主

6. 広告の目的?
• 広告主にとって
• お金を使って宣伝したいものがある
• 広告枠(を持つ人)にとって
• その枠から収益を得たい

7. ネット広告の簡単な歴史

8. ネット広告の始まり
• 期間保証型広告
• 例: 1ヶ月掲載あたりxxx円
• 表示回数保証型広告
• 例: 100万回表示あたりxxx円
• 90年代∼2001年頃

9. 誰かれ構わず
配信している状況

10. 昭和な感じ

11. Web 1.0(beta)

12. その後

13. 検索連動型の台頭
• Google AdWords
• 検索ワードに連動する広告を出す
• 例: 1クリックあたりxx円
• 2002年∼いまもある

14. 検索ワードに関連する
広告を出している

15. 平成な感じ

16. Web 2.0(死語)っぽい

17. Web 2.0といえば
• CGMの時代
• Blog, SNS, Wiki, etc
• (Web広告的な意味で)起こったこと
• 広告”枠”の爆発的増加
• ビューの増加に売上が追いつかない

18. つまり
• メディアの大小問わず
• 枠があるのにマネタイズできてない
• 人気なのにサービス続けるの難しい

19. せっかく
• 下記のような多様なメディアがあるのに
• 規模は大小あれど
• カテゴリ分けが割とはっきり
• 対象者もある程度明確

20. アドネットワーク登場
• カテゴリや対象ユーザでまとめた
• マネタイズ出来ていない”枠”を
• 広告主に販売する

21. 例えば
• Google AdSense
• Yahoo!インタレストマッチ
• みたいなの

22. これで
小規模メディアも
マネタイズできた

23. そこから更に

24. 「アドネットワーク
いくつもあるけど
いつでも
最適な配信したい」

25. というニーズに
応えるべく
SSPが登場

26. SSP?
• 伺かのベースウェア -> ☓
• Supply Side Platform -> ○

27. SSP?
• Supply Side Platform
• メディアの都合で最も最適な広告を複
数アドネットワークから選択して配
信する事業者
• yield optimizerとかいう言い方も

28. これでメディア かる
(∩´∀｀)∩ﾜｰｲ

29. めでたしめでたし

31. ちょっと待った

32. これではまだ
”広告主”
を置いて行ってる状況

33. ここまでの仕組みは
メディアの都合で
作られた商品

34. “枠”を買ってるのは
(当然ながら) 広告主...

35. 広告主のニーズ
• 費用対効果を最適化したい
• 買う枠をちゃんと選びたい
• そのために1リクエスト単位で買うか決
めたい

36. DSPの登場
• Digital Signal Processor -> ☓
• デジタル信号処理集積回路
• Demand Side Platform -> ○
• 広告主の都合で広告枠を買うための
プラットフォーム

37. どうやって?
• SSPとDSPを接続
• 1リクエスト単位でオークションをする

38. オークション

39. 大きな変化
• 「先物取引」だったWeb広告が
• 「現物取引」に変わる

40. RealTimeBidding
• 広告枠の「現物取引」を実現する枠組
• リクエストした瞬間に競争入札をする

41. 内容
• システムで使ってる技術とポイント
• 実装で注意している点
• テスト/CI/レビュー
• インフラ

42. RTBのサービス概要

43. この間100msくらい
(SSP/DSP間のRTT含む)

44. FreakOut!の構成概要

45. 一般的なLAMP構成

46. ソフトウェア
• nginx + starman + 素のpsgiアプリ
• Tokyo|Kyoto Product, memcached
• MySQL

47. 1.実装で注意している点

48. 気をつけている点
• /etc/hosts
• 特にKVS/memcached引くのが多い
• 出来るだけ外部と通信させたくない
• KVS
• TC/KTのファイルをサーバに配布
• 出来るだけ外部と通信させたくない

49. その他のポイント

50. インスタンス内キャッシュ
• 一度取得したキーの値はリクエスト中
でキャッシュして使いまわす
• コード例: InstanceCache.pm

51. DBへ同期的書き込みをしない
• 一旦ログに落としておく
• -> サーバ自身に集計させる
• -> 回収して集計する
• シリアライズしてKVSに入れる
• -> 他のサーバに引き渡す際に利用

52. どこで割り切るか
が重要

53. 高速化への回答
I/Oに注意すれば
PerlでもRTT含めて
50msで応答出来る

54. 古典的でも
地道にやる

56. DSPの特徴
• 入札(bid)サーバが一番多くなる
• 接続SSPのimp合計 = 入札リクエスト
• 入札に勝たないと配信出来ない
• かと言ってサーバは有限
参考: http://www.slideshare.net/kurodaeiji/adserver-12948257

57. 推測より計測
• HTTPDでの計測
• Devel::NYTProf
• 局所的に取るケース
• 寝てる間も指標を取る

58. HTTPDでの計測
• nginx.conf に設定
• "$upstream_response_time"
• "$request_time"

59. 補足
• FreakOut! での例
• nginx.conf.example
• ログを愚直に吐くとdiskがあふれるの
で標準では絞っている
• fluentdとか検討中

60. Devel::NYTProf
• starman + daemontools の場合
• run_example
• バッチプログラムとかの場合
• shebangに -d:NYTProf 追加するだけ

61. 局所的に取るケース
•例
• KVSのデータ取得に掛かっている時間
の取得
• PerformanceTimeout.pm

62. 寝てる間も指標を取る
• CloudForecast++ GrowthForecast++
• CloudForecastはメトリクス収集可視化
• GrowthForecastはビジネス指標の可視化

63. CloudForecast
• いわずもがな
• とってないとイスが飛びます

64. GrowthForecast
• ビジネス指標の取得
• 入札量の推移
• 配信量の推移
• 入札/配信結果の評価指標推移

65. GrowthForecast

66. ビジネス指標重要
• 障害の重要度判断はこちらの指標に与え
る影響度合いで考えるべき
• その障害が[有|無]害なのかの判断材料
• 例: 配信停止 >> 入札停止 >> その他
• 「ただちにサービス/売上に影響はない
のかそうでないのか」

67. 見えるようにしとけば
説得力が違う

68. 古典的でも
地道にやる

69. 2. テスト/CI/レビュー

70. テスト
• 実際に開発した機能での例
• admute(http://fout.jp/ad-mute/)
• 特定広告主の広告を停止する機能
• Facebookとかでも実装されてるアレ

71. コンポーネント
• Plack::Request, Plack::Response
• を継承してるモジュール
• ↑を受け取って処理するモジュール
• App::AdMute::Register みたいな
• ごくごくありふれたWebアプリ

72. どうやってるか
• Mockオブジェクト
• Mock::App::Request とか作る
• t::Utils でいろいろ置き換える
• memcached, KVS, MySQLの設定をlocal
に書き換え

73. CI
• Ukigumo::Server + 自前script
• テストさえある程度まとまっていれば
どうにかなる
• 見えるようにしとくのは重要
• tokuhirom++

74. 古典的でも
地道にやる

76. 3.インフラ

77. 最近クラウド全盛ですが
自作サーバメインです

79. なんでこうしているか
• サービスの性質上費用固定しやすいほうがいい
• 日によって大きく変動することが少ない
• 「使った分支払い」だと高く付く

80. どこで割り切るか
が重要

81. 費用対効果とリスクを
勘案してやるべき

82. 古典的でも
地道にやる

83. まとめ

84. 事実を積み上げて
判断する

85. • パフォーマンス
• I/Oさせない、計測する
• テスト/リリース
• 他の人がメンテを引き受けられるように
• インフラ
• 規模や予算、要件に見合った事をする

86. 古典的でも地道にやれば
50msでresponseを返せる