10000req/secを50msecで返すサーバーインフラをAWSで作る- RTB広告配信システムの開発・運用 -

2013/3/15山田 直行 （株式会社AMoAd（サイバーエージェント））

発表者について

• 山田直行（やまだ なおゆき）インフラ寄りのソフトウェアエンジニア（インフラ設計、サーバー運用、負荷対策、運用自動化）

• ソーシャルゲームのインフラエンジニア→広告配信の世界へ

• 好きな言語はPHP　好きなデータベースはMySQL

• 好きなエディタはvimとIntelliJ

• 好きなAWSサービスはRoute53

• https://www.facebook.com/yamadanaoyukihttps://twitter.com/satully

株式会社AMoAd

• :DeNAとサイバーエージェントの共同出資の子会社Ameba + Mobage + Advertisement = AMoAd

• スマホ向け広告配信（アドネットワーク）事業

• 海外向けに広告配信を今年始めから運用開始→今日はこの中の、RTB広告の配信システムの話をします

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

ここの話

インフラ設計時の要件

• 「ネットワークレイテンシの都合上、サーバーは北米東海岸に置く」

• 「規模は拡大し続けるので、どこまでもスケーラブルに」

• 「世界の他の地域でも立ち上げていくので、多展開しやすいように考慮して」

• 「フルスクラッチで作るけど、3ヶ月後にリリースできるように」

• 「 配信サーバーは10000req/secを50msec以内で安定して返し続けられるように」

• 「 計測サーバーは特にクリック・コンバージョンなどの計測データは絶対にロストしないよう、全てのリクエストを漏らさず受けきる」

設計方針と課題

•どう見てもAWS一択（S3の存在、マルチリージョン、CloudFrontなど考慮して総合的に）

• リアルタイム入札で他社に勝っていくため、とにかく配信サーバー（bidサーバー）が重要

• 50msecというレスポンスタイム要件が厳しい。ネットワークが安定しないといわれるクラウドでやれるか？

→レイテンシを短くする工夫が必要

設計上で工夫しているところ

1)フロントのロードバランサにELBを使わず、Apache+mod_proxyを使う

2)配信データのあるMySQLサーバーやKVSは各アプリケーションサーバーにレプリケーションする

3)必要最小限のデータを配信サーバーにレプリケーションするため、 MySQLを多段レプリケーションする

4)配信サーバーはAZ間で冗長化しない。そのかわり障害時には短時間で全てのサーバー群を自動でたちあげて復旧できるようにする

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

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

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

4)AZ間で冗長化しない。復旧を高速・自動化する

実際には、片方のAZが落ちるということはほとんどない

DSPというサービスだから取れる手段という話も・・・

レイテンシを短くするため、配信系サーバーは一つのAZに集中させる

今後やりたいこと

•OpsWorks?

現状はfabricとchef-soloでCUIベースで独自システムを開発・運用中だが

•RedShift？EMRを使っているところを部分的に置き換えられるかも！