![ビジネス指標重要
• 障害の重要度判断はこちらの指標に与え
る影響度合いで考えるべき
• その障害が[有|無]害なのかの判断材料
• 例: 配信停止 >> 入札停止 >> その他
• 「ただちにサービス/売上に影響はない
のかそうでないのか」](https://image.slidesharecdn.com/yapc201209forupload-120929002432-phpapp02/75/50msperl-66-2048.jpg?cb=1666782485)
平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用
•32 likes•11,686 views
Download to read offline
Report
Recommended
More Related Content
Viewers also liked
Viewers also liked(20)
Similar to 平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用
Similar to 平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用(20)
More from Tatsuro Hisamori
More from Tatsuro Hisamori(8)
平均レスポンスタイム50msをPerlで捌く中規模サービスの実装/運用
- 1. 平均レスポンスタイム50msをPerlでry Tatsuro Hisamori
- 2. 改め
- 3. アドテク業界って 最近こうなってます Tatsuro Hisamori
- 4. アドテク? • 広告技術(Ad Tech) • 狭義にはネット広告関連技術
- 5. 広告の目的? • 広告が成立する条件 • “出す”場所がある • “見る”人がいる • ”出稿”したい誰かがいる • 広告枠 : オーディエンス : 広告主
- 6. 広告の目的? • 広告主にとって • お金を使って宣伝したいものがある • 広告枠(を持つ人)にとって • その枠から収益を得たい
- 7. ネット広告の簡単な歴史
- 8. ネット広告の始まり • 期間保証型広告 • 例: 1ヶ月掲載あたりxxx円 • 表示回数保証型広告 • 例: 100万回表示あたりxxx円 • 90年代∼2001年頃
- 10. 昭和な感じ
- 11. Web 1.0(beta)
- 12. その後
- 13. 検索連動型の台頭 • Google AdWords • 検索ワードに連動する広告を出す • 例: 1クリックあたりxx円 • 2002年∼いまもある
- 15. 平成な感じ
- 16. Web 2.0(死語)っぽい
- 17. Web 2.0といえば • CGMの時代 • Blog, SNS, Wiki, etc • (Web広告的な意味で)起こったこと • 広告”枠”の爆発的増加 • ビューの増加に売上が追いつかない
- 18. つまり • メディアの大小問わず • 枠があるのにマネタイズできてない • 人気なのにサービス続けるの難しい
- 19. せっかく • 下記のような多様なメディアがあるのに • 規模は大小あれど • カテゴリ分けが割とはっきり • 対象者もある程度明確
- 20. アドネットワーク登場 • カテゴリや対象ユーザでまとめた • マネタイズ出来ていない”枠”を • 広告主に販売する
- 21. 例えば • Google AdSense • Yahoo!インタレストマッチ • みたいなの
- 23. そこから更に
- 26. SSP? • 伺かのベースウェア -> ☓ • Supply Side Platform -> ○
- 27. SSP? • Supply Side Platform • メディアの都合で最も最適な広告を複 数アドネットワークから選択して配 信する事業者 • yield optimizerとかいう言い方も
- 28. これでメディア かる (∩´∀｀)∩ﾜｰｲ
- 29. めでたしめでたし
- 31. ちょっと待った
- 32. これではまだ ”広告主” を置いて行ってる状況
- 34. “枠”を買ってるのは (当然ながら) 広告主...
- 35. 広告主のニーズ • 費用対効果を最適化したい • 買う枠をちゃんと選びたい • そのために1リクエスト単位で買うか決 めたい
- 36. DSPの登場 • Digital Signal Processor -> ☓ • デジタル信号処理集積回路 • Demand Side Platform -> ○ • 広告主の都合で広告枠を買うための プラットフォーム
- 38. オークション
- 41. 内容 • システムで使ってる技術とポイント • 実装で注意している点 • テスト/CI/レビュー • インフラ
- 42. RTBのサービス概要
- 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. どこで割り切るか が重要
- 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はビジネス指標の可視化
- 64. GrowthForecast • ビジネス指標の取得 • 入札量の推移 • 配信量の推移 • 入札/配信結果の評価指標推移
- 65. GrowthForecast
- 66. ビジネス指標重要 • 障害の重要度判断はこちらの指標に与え る影響度合いで考えるべき • その障害が[有|無]害なのかの判断材料 • 例: 配信停止 >> 入札停止 >> その他 • 「ただちにサービス/売上に影響はない のかそうでないのか」
- 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.インフラ
- 79. なんでこうしているか • サービスの性質上費用固定しやすいほうがいい • 日によって大きく変動することが少ない • 「使った分支払い」だと高く付く
- 80. どこで割り切るか が重要
- 82. 古典的でも 地道にやる
- 83. まとめ
- 84. 事実を積み上げて 判断する
- 85. • パフォーマンス • I/Oさせない、計測する • テスト/リリース • 他の人がメンテを引き受けられるように • インフラ • 規模や予算、要件に見合った事をする
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