高速な広告配信サーバの作り方のコツ

高速な配信サーバをつくるためのコツを紹介しています。

Transcript

1. 高速な広告配信サーバの作り方 のコツ GUNOSY  inc.   印南 聡志
2. 自己紹介 •  印南聡志（いんなみ さとし）   •  Gunosyのアドエンジニア  (3年目)   –  Gunosyのアド配信サーバ周り全般担当   •  言語   –  Go   –  Python   •  マイブーム   –  AJINOMOTOの冷凍餃子   –  大食い(視るだけ)   •  参照   –  Blog：NO  AD  NO  LIFE(hBp://inchom.hatenadiary.jp/)   –  Github：hBps://github.com/satoshi03  
3. 広告配信サーバって？
4. 配信サーバ   (API) バッチサーバ 広告情報   （キャッシュ） とても簡単な仕組み 広告情報   （元データ） ELB 広告   リクエスト
5.     広告配信による収益の最大化 目的
6. 収益   広告選択   応答性能 可用性
7. 高速な広告配信サーバって？
8. 50ms  or  die 某社
9. リプレース時の要求性能     １リクエストの応答時間：  50ms  以内   リクエスト数：                                            10,000req/sec  
10. リプレース後のサーバ性能は？
11. 5ms
12.     １リクエストの応答時間：  5ms   リクエスト数：                                            10,000req/sec  以上  
13. （あたり前だけど忘れがちな）   広告配信サーバを高速化するコツ
14. 1. ボトルネックをつくらない
15. 配信サーバ Redis これまでの問題 リクエスト増
16. 中央の共有DBを作らない
17. 配信サーバ LevelDB S3 バッチサーバ ダウンロード アップロード
18. 共有DBが必要な場合は   Writeを集約
19. 配信サーバ Redis  Master Redis  Slave Redis  Slave READ WRITE Sync バッチサーバ (ログ集約)
20. プロセスキャッシュを導入
21. 配信サーバ Redis  Master Redis  Slave Redis  Slave READ WRITE Sync 取得したデータを 一定期間保持
22. 2.  APIサーバは薄く
23. これまでの問題 •  APIサーバ側で複雑な入札ロジックを実装   – 複数の入札ロジック   – 逐次スコアを計算   – 複雑なバリデーション   •  Python  (tornado)  製  
24. 対応 •  API側   – Golangで実装   – やることを極限まで削減   •  広告候補の取得   •  簡単なバリデーション   •  バッチ側で複雑な処理を一括で計算   – Python  
25. 3. 応答性能を常時計測
26. 問題   •  様々な性能劣化の原因   – 機能追加/改修   – データの増加   – アクセス傾向の変化  
27. 負荷試験をかけて性能劣化を防止

28. LOCUST •  Python製の分散負荷計測ツール   – テストのシナリオをPythonで記述   – Web  UI  の管理画面   – 管理が容易  
29. LOCUST  構成 ・・・ Locust  slave Locust  master 広告配信 サーバ ・・・ シナリオに応じてリクエストを 生成 Slaveを管理
31. 4. コードのチューニング
32. 問題       実際に実行すると処理速度が遅い…    
33. pprof •  Goのプロファイラ   – 関数ごとのCPU処理時間を計測   – グラフ描画   •  重い処理を視覚的に発見しやすい  
34. 見つかった問題 •  様々な原因   – ライブラリ内の実装   – 入札時の広告の探索範囲が広い   – バリデーションのコスト   – データキャストのコスト   – オブジェクト生成のコスト   – DB接続時のコスト   – ログ出力コスト  
35. 対策を全部うってもダメな場合…
36. 5.  金で解決
37. 金で解決の例 •  Redis  をやめる   – DynamoDB   – AeroSpike   •  スケールアップで対応   – 4xlargeインスタンス…  
38. まとめ •  広告配信サーバの高速化のコツ   1. ボトルネックをつくらない   2.  APIサーバを薄く   3. 応答性能を計測   4. コードのチューニング   5. 金で解決