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

13,292 views

Published on

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

No Downloads
Views
Total views
13,292
On SlideShare
0
From Embeds
0
Number of Embeds
3,444
Actions
Shares
0
Downloads
53
Comments
0
Likes
32
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
  • \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
  • 平均レスポンスタイム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を返せる

    ×