#gunosybeer

1. HTTPプロキシによるゼロダウン
タイムなアドサーバー移行
Ryo Aita

2. 自己紹介
会田 遼
Gunosy 広告技術部所属
2014年12月入社
ダイエット中

3. Overview
• Go言語製のHTTPプロキシを実装して、広告
配信サーバーを（おおむね）ゼロダウンタイム
で移行した話（※タイトルには誇張がありま
す)
• 踏んだ地雷の話

4. Gunosyのアドサーバー移行の課題
• 収益の拡大
• 施策の高速化
• 保守・追加開発の効率化

5. システム移行の悩み
• 新旧システムの並行運用は避けたい
– 収益の集計系の多重管理とか恐怖
– そもそも運用コストを避けるのが目的
• 停止時間は最低限にしたい
– 停止中に広告が出ないと収益が減る
• テストが難しい
– シナリオテストは重要だが、本番で起きている全ての
ケースを網羅するのは困難
– 本番からのリクエストで予期せぬエラーが出ないか
– リリースしてからクライアントのクラッシュ率がらない
か

6. １％限定公開
• DNSの設定で1%だけ、新サーバーを公開
• テスト時間帯の収益の1%は目をつぶる（短時
間でかつピーク帯を避ければ後から取り返せ
る)
• クライアントのクラッシュ率が上がらないか監
視

7. 問題
新サーバーが本番のリクエストに耐えれるか、
1%限定公開じゃわからないよね!？

8. 回答
リリース前に本番へのリクエストをまるごと新
サーバーに流せばよくね？

9. 解決策
• シャドウプロキシーで本番のリクエストを段階
的に新サーバーに流して負荷に耐えれるか
試験

10. シャドウプロキシーって？
• 本番のリクエストを、稼働中のシステムとは別
の環境に送るツール（or 仕組み）
• 本番のリクエストを使うので、負荷テストやシ
ナリオテストでのテスト漏れを防げる

11. Gunosy Ad プロキシ
• Go言語で実装
• リバースプロキシ
– リクエストを稼働中のシステムに送信
– プロキシ先のレスポンスをクライアントに返信
• シャドウプロキシ
– Goルーチンでバックグラウンドで送信
– レスポンスは捨てる
• URL単位でプロキシ先を設定可能

12. システム構成

13. 結果
• 事前に、本番のリクエストを新サーバーに
100%流すことによってリスクを減らせた。
• 本番リリース時に配信サーバーの作業はプ
ロキシの設定を変えるだけで済んだ。
• 大きな障害を起こすことなく、新サーバーへ
の移行が出来た。

14. 続くよ
踏んだ地雷の話もするよ

15. 地雷1
• Goルーチンが溢れた
– リクエストを受け取ったらGoルーチンを作成して、
シャドウプロキシーの対象にリクエストを送信する
ようにしてた
– ピークにリクエスト数が増えて、Goルーチンが溢
れた
• シャドウ用のGoルーチンのプールを作成して
解決

16. 地雷2
• シャドウ用のプールの数が足りなかった

17. 地雷2
• シャドウプロキシーからのリクエストが遅延
• シャドウ先へのリクエストが角刈りに・・・・

18. 地雷3
• DNSループ・・・・

19. 地雷3
• プロキシー先のホスト名をELBのホスト名では
なく、公開用のホスト名を指定してた
• リクエストの100%をプロキシーを経由するよう
にした瞬間、リクエストが完全にループして広
告が出せなくなった