Successfully reported this slideshow.

平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用

32

Share

1 of 86
1 of 86

More Related Content

Related Audiobooks

Free with a 14 day trial from Scribd

See all

平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用

  1. 1. 平均レスポンスタイム50msをPerlでry Tatsuro Hisamori
  2. 2. 改め
  3. 3. アドテク業界って 最近こうなってます Tatsuro Hisamori
  4. 4. アドテク? • 広告技術(Ad Tech) • 狭義にはネット広告関連技術
  5. 5. 広告の目的? • 広告が成立する条件 • “出す”場所がある • “見る”人がいる • ”出稿”したい誰かがいる • 広告枠 : オーディエンス : 広告主
  6. 6. 広告の目的? • 広告主にとって • お金を使って宣伝したいものがある • 広告枠(を持つ人)にとって • その枠から収益を得たい
  7. 7. ネット広告の簡単な歴史
  8. 8. ネット広告の始まり • 期間保証型広告 • 例: 1ヶ月掲載あたりxxx円 • 表示回数保証型広告 • 例: 100万回表示あたりxxx円 • 90年代∼2001年頃
  9. 9. 誰かれ構わず 配信している状況
  10. 10. 昭和な感じ
  11. 11. Web 1.0(beta)
  12. 12. その後
  13. 13. 検索連動型の台頭 • Google AdWords • 検索ワードに連動する広告を出す • 例: 1クリックあたりxx円 • 2002年∼いまもある
  14. 14. 検索ワードに関連する 広告を出している
  15. 15. 平成な感じ
  16. 16. Web 2.0(死語)っぽい
  17. 17. Web 2.0といえば • CGMの時代 • Blog, SNS, Wiki, etc • (Web広告的な意味で)起こったこと • 広告”枠”の爆発的増加 • ビューの増加に売上が追いつかない
  18. 18. つまり • メディアの大小問わず • 枠があるのにマネタイズできてない • 人気なのにサービス続けるの難しい
  19. 19. せっかく • 下記のような多様なメディアがあるのに • 規模は大小あれど • カテゴリ分けが割とはっきり • 対象者もある程度明確
  20. 20. アドネットワーク登場 • カテゴリや対象ユーザでまとめた • マネタイズ出来ていない”枠”を • 広告主に販売する
  21. 21. 例えば • Google AdSense • Yahoo!インタレストマッチ • みたいなの
  22. 22. これで 小規模メディアも マネタイズできた
  23. 23. そこから更に
  24. 24. 「アドネットワーク いくつもあるけど いつでも 最適な配信したい」
  25. 25. というニーズに 応えるべく SSPが登場
  26. 26. SSP? • 伺かのベースウェア -> ☓ • Supply Side Platform -> ○
  27. 27. SSP? • Supply Side Platform • メディアの都合で最も最適な広告を複 数アドネットワークから選択して配 信する事業者 • yield optimizerとかいう言い方も
  28. 28. これでメディア かる (∩´∀`)∩ワーイ
  29. 29. めでたしめでたし
  30. 30. ちょっと待った
  31. 31. これではまだ ”広告主” を置いて行ってる状況
  32. 32. ここまでの仕組みは メディアの都合で 作られた商品
  33. 33. “枠”を買ってるのは (当然ながら) 広告主...
  34. 34. 広告主のニーズ • 費用対効果を最適化したい • 買う枠をちゃんと選びたい • そのために1リクエスト単位で買うか決 めたい
  35. 35. DSPの登場 • Digital Signal Processor -> ☓ • デジタル信号処理集積回路 • Demand Side Platform -> ○ • 広告主の都合で広告枠を買うための プラットフォーム
  36. 36. どうやって? • SSPとDSPを接続 • 1リクエスト単位でオークションをする
  37. 37. オークション
  38. 38. 大きな変化 • 「先物取引」だったWeb広告が • 「現物取引」に変わる
  39. 39. RealTimeBidding • 広告枠の「現物取引」を実現する枠組 • リクエストした瞬間に競争入札をする
  40. 40. 内容 • システムで使ってる技術とポイント • 実装で注意している点 • テスト/CI/レビュー • インフラ
  41. 41. RTBのサービス概要
  42. 42. この間100msくらい (SSP/DSP間のRTT含む)
  43. 43. FreakOut!の構成概要
  44. 44. 一般的なLAMP構成
  45. 45. ソフトウェア • nginx + starman + 素のpsgiアプリ • Tokyo|Kyoto Product, memcached • MySQL
  46. 46. 1.実装で注意している点
  47. 47. 気をつけている点 • /etc/hosts • 特にKVS/memcached引くのが多い • 出来るだけ外部と通信させたくない • KVS • TC/KTのファイルをサーバに配布 • 出来るだけ外部と通信させたくない
  48. 48. その他のポイント
  49. 49. インスタンス内キャッシュ • 一度取得したキーの値はリクエスト中 でキャッシュして使いまわす • コード例: InstanceCache.pm
  50. 50. DBへ同期的書き込みをしない • 一旦ログに落としておく • -> サーバ自身に集計させる • -> 回収して集計する • シリアライズしてKVSに入れる • -> 他のサーバに引き渡す際に利用
  51. 51. どこで割り切るか が重要
  52. 52. 高速化への回答 I/Oに注意すれば PerlでもRTT含めて 50msで応答出来る
  53. 53. 古典的でも 地道にやる
  54. 54. DSPの特徴 • 入札(bid)サーバが一番多くなる • 接続SSPのimp合計 = 入札リクエスト • 入札に勝たないと配信出来ない • かと言ってサーバは有限 参考: http://www.slideshare.net/kurodaeiji/adserver-12948257
  55. 55. 推測より計測 • HTTPDでの計測 • Devel::NYTProf • 局所的に取るケース • 寝てる間も指標を取る
  56. 56. HTTPDでの計測 • nginx.conf に設定 • "$upstream_response_time" • "$request_time"
  57. 57. 補足 • FreakOut! での例 • nginx.conf.example • ログを愚直に吐くとdiskがあふれるの で標準では絞っている • fluentdとか検討中
  58. 58. Devel::NYTProf • starman + daemontools の場合 • run_example • バッチプログラムとかの場合 • shebangに -d:NYTProf 追加するだけ
  59. 59. 局所的に取るケース •例 • KVSのデータ取得に掛かっている時間 の取得 • PerformanceTimeout.pm
  60. 60. 寝てる間も指標を取る • CloudForecast++ GrowthForecast++ • CloudForecastはメトリクス収集可視化 • GrowthForecastはビジネス指標の可視化
  61. 61. CloudForecast • いわずもがな • とってないとイスが飛びます
  62. 62. GrowthForecast • ビジネス指標の取得 • 入札量の推移 • 配信量の推移 • 入札/配信結果の評価指標推移
  63. 63. GrowthForecast
  64. 64. ビジネス指標重要 • 障害の重要度判断はこちらの指標に与え る影響度合いで考えるべき • その障害が[有|無]害なのかの判断材料 • 例: 配信停止 >> 入札停止 >> その他 • 「ただちにサービス/売上に影響はない のかそうでないのか」
  65. 65. 見えるようにしとけば 説得力が違う
  66. 66. 古典的でも 地道にやる
  67. 67. 2. テスト/CI/レビュー
  68. 68. テスト • 実際に開発した機能での例 • admute(http://fout.jp/ad-mute/) • 特定広告主の広告を停止する機能 • Facebookとかでも実装されてるアレ
  69. 69. コンポーネント • Plack::Request, Plack::Response • を継承してるモジュール • ↑を受け取って処理するモジュール • App::AdMute::Register みたいな • ごくごくありふれたWebアプリ
  70. 70. どうやってるか • Mockオブジェクト • Mock::App::Request とか作る • t::Utils でいろいろ置き換える • memcached, KVS, MySQLの設定をlocal に書き換え
  71. 71. CI • Ukigumo::Server + 自前script • テストさえある程度まとまっていれば どうにかなる • 見えるようにしとくのは重要 • tokuhirom++
  72. 72. 古典的でも 地道にやる
  73. 73. 3.インフラ
  74. 74. 最近クラウド全盛ですが 自作サーバメインです
  75. 75. なんでこうしているか • サービスの性質上費用固定しやすいほうがいい • 日によって大きく変動することが少ない • 「使った分支払い」だと高く付く
  76. 76. どこで割り切るか が重要
  77. 77. 費用対効果とリスクを 勘案してやるべき
  78. 78. 古典的でも 地道にやる
  79. 79. まとめ
  80. 80. 事実を積み上げて 判断する
  81. 81. • パフォーマンス • I/Oさせない、計測する • テスト/リリース • 他の人がメンテを引き受けられるように • インフラ • 規模や予算、要件に見合った事をする
  82. 82. 古典的でも地道にやれば 50msでresponseを返せる

Editor's Notes

  • \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
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • InstanceCache.pm を vim で開いて適当に解説\n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • nginx.conf.example を開いて適当に解説\n
  • run_example を開いて適当に解説\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
  • ×