2015.01.20広告システムと負荷分散【ADMAGE座談会vol.1】(1)TweetPocketどうも。先日、ADMAGEユニットのメンバーで座談会を行いました。テーマはズバリ「広告システムと負荷分散」です。これから数回に分けて、その座談会の様子をアップしていきたいと思います。お読み下さい!!登場人物クロシニア、アドネットワークシステムなどを担当。画像広告と動画広告ウォール広告効果測定のススメ全部見えてるわけじゃないクリエイティブの最適化についてDシニア、大規模計測システムなどを担当。利用しての開発YAMAシニア、大量トラフィックアドサーバーなどを担当。SDKを使ってAndroid端末の広告ID(Advertising-ID)を取得するUnity任せの機種固有ID取得は危険!-Unityアプリで効果計測を行う際の注意点-MySQLTunerを使ってMySQLを診断しよう!iOS7標準搭載『iBeacon』についてWEB広告システムとの親和性について考えてみた。ADMAGEとアプリSDKの今後はどうなる?小林ミドル、社内サービスAppTizerなどを担当。–StreamAPI編Java8に注目してみました個人情報は自分で守れ!若林ミドル、計測システムやアドネットワークを担当。広告システムと負荷というのは、システムが大きくなればなるほど向き合っていく必要のあるテーマです。今回の座談会では、広告システムと、その負荷をいかに分散させるかの対策・悩みポイント等お話できればと思います。負荷がかかるのはどういうポイントでしょうか。配信か、集計か、DBかなどあると思いますが。お客さんの規模や考え方によります。いいかな?でもそんなに対策せず、案外小規模で回っているお客さんもいるという話もあるだろうし。2台構成で動いているシステムがある一方、画像サーバーだけで十数台あるようなお客さんもいます。一般的に「負荷対策」と言ってイメージするのは後者がメインですかね。どのくらいの規模だったら負荷対策せずに回るなどの目安はありますか?トラフィック数など。それはシステムの中身によるので、一概に基準は設けられない。マシンの性能だけ上げれば大丈夫な場合、ミドルをチューニングしないといけない場合など。DBへのアクセスを頻繁に行う場合は、DBも所詮ファイルなので、ファイルへのアクセス性能が高くなるように考慮されていないといけない。SSDとか使えばかなり高速な転送ができるから、さほど気にしなくてもDBは回る場合もある。DBがスカスカで負荷かかってなくても、ネットワークでダメになってしまう場合や、ミドルでコネクション制限しないといけない場合もある。負荷のかかる側面は様々ですね。負荷のかかるタイミングもまちまちでしょうか。負荷がかかるタイミングはある程度決まっているでしょうね。自分が担当しているシステムでは、ブースト広告が走るタイミングが一番ですね。一気にダウンロード数を稼ぐために、リワードサービスでユーザーにポイントを付与してダウンロードしてもらうための広告なので、成果も多く、キックバックもしなくてはいけませんね。時間としては夕方が多いでしょうか。実際、ブースト広告が打たれたタイミングでも、困る点は、配信かDBかバッチ処理(集計・キックバック)かに分けられると思います。社内で運用しているサービスのAppTizerやRewardShareの場合、配信サーバーの問題は少ないです。逆にディスクIOが問題ですね。自分がやっているシステムでは、ブースト広告が走ったときに、キックバックが大量に溜まってしまうケースがありました。キックバックが溜まるのは、こちらの性能のせいもあるし、相手の性能のせいもある。こちらの性能が良いからといってキックバックしまくると相手が落ちてしまうし、こっちの性能落としてばかりにしてしまうと、相手的にはログが遅れたりして...。相手先との調整ですね、この辺は。自分が見ていたシステムの場合は、深夜帯がピークタイムでしたね。大きい画像を大量に配信しているシステムがあって、その場合は深夜帯とかにアクセスが多くなるのだが、画像を配信するのだけど回線の容量が決まっているので、それを超えると画像配信が遅延しちゃうということがありました。画像サーバー20台でそれぞれ1/20で分散して、ピークタイム乗り切ったりしています。1台あたりの回線使用量を40Mbps以下にするためには20台って感じですね。自分がやっていた計測システムは、配信とかせず集計計測ばっかりだったけど、集計系のネックは、やはりディスク。