1. 10000req/secを50msecで返す
サーバーインフラをAWSで作る
- RTB広告配信システムの開発・運用 -
2013/3/15
山田 直行 （株式会社AMoAd（サイバーエージェント））

2. 発表者について
• 山田直行（やまだ なおゆき）
インフラ寄りのソフトウェアエンジニア
（インフラ設計、サーバー運用、負荷対策、運用自動化）
• ソーシャルゲームのインフラエンジニア→広告配信の世界へ
• 好きな言語はPHP 好きなデータベースはMySQL
• 好きなエディタはvimとIntelliJ
• 好きなAWSサービスはRoute53
• https://www.facebook.com/yamadanaoyuki
https://twitter.com/satully

3. 株式会社AMoAd
• :DeNAとサイバーエージェントの共同出資の子会社
Ameba + Mobage + Advertisement = AMoAd
• スマホ向け広告配信（アドネットワーク）事業
• 海外向けに広告配信を今年始めから運用開始
→今日はこの中の、RTB広告の配信システムの話をします

4. SSP = Supply Side Platform(メディア側)
RTB広告配信？ DSP = Demand Side Platform(広告主側)
RTB = Real Time Bidding(リアルタイム広告入札)
ここの話

5. インフラ設計時の要件
• 「ネットワークレイテンシの都合上、サーバーは北米東海岸に置く」
• 「規模は拡大し続けるので、どこまでもスケーラブルに」
• 「世界の他の地域でも立ち上げていくので、多展開しやすいように考慮して」
• 「フルスクラッチで作るけど、3ヶ月後にリリースできるように」
• 「 配信サーバーは10000req/secを50msec以内で安定して返し続けられるように」
• 「 計測サーバーは特にクリック・コンバージョンなどの計測データは絶対にロス
トしないよう、全てのリクエストを漏らさず受けきる」

6. 設計方針と課題
• どう見てもAWS一択
（S3の存在、マルチリージョン、CloudFrontなど考慮して総合的に）
• リアルタイム入札で他社に勝っていくため、とにかく配信サーバー
（bidサーバー）が重要
• 50msecというレスポンスタイム要件が厳しい。
ネットワークが安定しないといわれるクラウドでやれるか？
→レイテンシを短くする工夫が必要

7. 設計上で工夫しているところ
1)フロントのロードバランサにELBを使わず、Apache+mod_proxyを使う
2)配信データのあるMySQLサーバーやKVSは各アプリケーションサーバーに
レプリケーションする
3)必要最小限のデータを配信サーバーにレプリケーションするため、
MySQLを多段レプリケーションする
4)配信サーバーはAZ間で冗長化しない。そのかわり障害時には
短時間で全てのサーバー群を自動でたちあげて復旧できるようにする

8. 1)ELBを使わず、Apache+mod_proxyを使う

9. 2)各アプリケーションサーバーにDBをレプリする

10. 3)MySQLを多段レプリケーションする

11. 4)AZ間で冗長化しない。復旧を高速・自動化する
レイテンシを短くするため、配信系
サーバーは一つのAZに集中させる
実際には、片方のAZが落ちると
いうことはほとんどない
DSPというサービスだから
取れる手段という話も・・・

12. 今後やりたいこと
•OpsWorks?
現状はfabricとchef-soloでCUIベースで独自システムを
開発・運用中だが
•RedShift？
EMRを使っているところを部分的に置き換えられる
かも！