広告システムと負荷分散【ADMAGE座談会vol.1】(1)

どうも。粟飯原です。

先日、ADMAGEユニットのメンバーで座談会を行いました。
テーマはズバリ
「広告システムと負荷分散」
です。

広告システムと負荷分散【ADMAGE座談会vol.1】

これから数回に分けて、その座談会の様子をアップしていきたいと思います。
ぜひ順次お読み下さい!!

登場人物

クロ
シニア、アドネットワークシステムなどを担当。
クロの書いた記事
画像広告と動画広告
ウォール広告効果測定のススメ
全部見えてるわけじゃない
クリエイティブの最適化について

D
シニア、大規模計測システムなどを担当。
Dの書いた記事
Google Adwords API を利用しての開発

YAMA
シニア、大量トラフィックアドサーバーなどを担当。
YAMAの書いた記事
Google Play Servece SDKを使ってAndroid端末の広告ID(Advertising-ID)を取得する
Unity任せの機種固有ID取得は危険!-Unityアプリで効果計測を行う際の注意点-
MySQLTunerを使ってMySQLを診断しよう!
iOS7標準搭載『iBeacon』についてWEB広告システムとの親和性について考えてみた。
ADMAGEとアプリSDKの今後はどうなる?

小林
ミドル、社内サービスAppTizerなどを担当。
小林の書いた記事
iOSアプリ64bit版に対応する
Java8に触れてみた 続・StreamAPI編
Java8に触れてみた –StreamAPI編
Java8に注目してみました
個人情報は自分で守れ!

若林
ミドル、計測システムやアドネットワークを担当。
若林の書いた記事
ADMAGEを振り返って~パート1~
Apache Solrについて ~Second Edition~
Apache Solrについて ValueTrackについて考えてみる
よくわかるインターネット広告の効果測定

はじめに

―: 広告システムと負荷というのは、システムが大きくなればなるほど向き合っていく必要のあるテーマです。今回の座談会では、広告システムと、その負荷をいかに分散させるかの対策・悩みポイント等お話できればと思います。
一同: よろしくお願いします。

負荷のかかるポイントやタイミング

―: まず、負荷がかかるのはどういうポイントでしょうか。配信か、集計か、DBかなどあると思いますが。

クロ: まちまちですね。お客さんの規模や考え方によります。

D: 今回は大きいクライアントの話に絞って良いのでは?

クロ: いいかな?
でもそんなに対策せず、案外小規模で回っているお客さんもいるという話もあるだろうし。2台構成で動いているシステムがある一方、画像サーバーだけで十数台あるようなお客さんもいます。一般的に「負荷対策」と言ってイメージするのは後者がメインですかね。

―: 例えば、どのくらいの規模だったら負荷対策せずに回るなどの目安はありますか?トラフィック数など。

小林: それはシステムの中身によるので、一概に基準は設けられない。
例えば、マシンの性能だけ上げれば大丈夫な場合、ミドルをチューニングしないといけない場合など。DBへのアクセスを頻繁に行う場合は、DBも所詮ファイルなので、ファイルへのアクセス性能が高くなるように考慮されていないといけない。SSDとか使えばかなり高速な転送ができるから、さほど気にしなくてもDBは回る場合もある。
DBがスカスカで負荷かかってなくても、ネットワークでダメになってしまう場合や、ミドルでコネクション制限しないといけない場合もある。

―: なるほど。負荷のかかる側面は様々ですね。
では、負荷のかかるタイミングもまちまちでしょうか。

小林: 負荷がかかるタイミングはある程度決まっているでしょうね。
自分が担当しているシステムでは、ブースト広告が走るタイミングが一番ですね。

―: リワード広告ですね。一気にダウンロード数を稼ぐために、リワードサービスでユーザーにポイントを付与してダウンロードしてもらうための広告なので、成果も多く、キックバックもしなくてはいけませんね。
時間としては夕方が多いでしょうか。

小林: 実際、ブースト広告が打たれたタイミングでも、困る点は、配信かDBかバッチ処理(集計・キックバック)かに分けられると思います。
社内で運用しているサービスのAppTizerやRewardShareの場合、配信サーバーの問題は少ないです。逆にディスクIOが問題ですね。

D: ディスクがネックなんだよね!

クロ: 自分がやっているシステムでは、ブースト広告が走ったときに、キックバックが大量に溜まってしまうケースがありました。キックバックが溜まるのは、こちらの性能のせいもあるし、相手の性能のせいもある。こちらの性能が良いからといってキックバックしまくると相手が落ちてしまうし、こっちの性能落としてばかりにしてしまうと、相手的にはログが遅れたりして…。相手先との調整ですね、この辺は。

若林: 自分が見ていたシステムの場合は、深夜帯がピークタイムでしたね。
大きい画像を大量に配信しているシステムがあって、その場合は深夜帯とかにアクセスが多くなるのだが、画像を配信するのだけど回線の容量が決まっているので、それを超えると画像配信が遅延しちゃうということがありました。
だから、画像サーバー20台でそれぞれ1/20で分散して、ピークタイム乗り切ったりしています。

D: その20台って、どう計算して20台って算出したの?

若林: 1台あたりの回線使用量を40Mbps以下にするためには20台って感じですね。

D: なるほど。自分がやっていた計測システムは、配信とかせず集計計測ばっかりだったけど、集計系のネックは、やはりディスク。ログが多すぎた。

小林: そうなりますよね。

D: あと1回落ちたのはtwitterだね!twitterに計測タグ貼られたとき!そのときは秒間アクセスがApacheやTomcatをオーバーして、計測サーバーが落ちたってことはあった。まぁそれは想定してないトラフィックだったから落ちたってだけ当たり前だけど…。

クロ: 広告主側のシステムだと、思わぬところにタグを貼られてトラフィックが増えるということはありますね。
アプリのインストールと更新でも問題が起きたことがありました。大きいアプリだと、更新だけでも再起動がどんどんかかってしまうのですが、最初の頃はそれらを区別してなかったので、アプリの更新をどんどん計測してしまっていました。なので、同タイミングで一気にトラフィックがきてしまって、パンクするということがありました。
事前に大物アプリがくる、大きなメディアとつなげるってわかっていたら対策しようがあるけれど…わからないままやらなきゃいけないこともあるのが辛いとこですね!

―: なるほど。
ではタイミングとしてはアクセス集中するときや、集計のときですね。

第一回目は以上です!
次回はサーバー設定など具体的な話に移ります。

広告システムの負荷分散対策に興味ある方やお悩みの方はお気軽にご相談ください!




広告システムについてのお問い合わせやご相談、パッケージ製品の詳細はこちらからどうぞ。
http://admage.jp/
アプリ計測SDK admage for Appのお問い合わせ・詳細はこちら。
http://apptizer.jp/

コメントを残す