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

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

どうも。粟飯原です。

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

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

今回はその座談会録第二回目です!
第一回目はこちら

登場人物

クロ
シニア、アドネットワークシステムなどを担当。

D
シニア、大規模計測システムなどを担当。

YAMA
シニア、大量トラフィックアドサーバーなどを担当。

小林
ミドル、社内サービスAppTizerなどを担当。

若林
ミドル、計測システムやアドネットワークを担当。

【サーバー対策】

―: サーバー強化は有用な対策でしょうか。

クロ: トラフィックが増える予想ができてれば有用でしょうね。マシン導入したりDB強化したり。まぁ明日やりますと言われても困りますけど。

若林: 画像サーバーもそうですよね。

YAMA CDN(コンテンツデリバリーネットワーク)使いたいですね。

クロ: CDNはキャッシュの更新頻度の調整がネックになるみたいですね。

YAMA 常にキャッシュしておくので、配信サーバーに都度アクセスいかなくていいんですよ。なので、高速にいけるというわけです。

小林 DNSのコンテンツ版って感じですね。

クロ: データのアップデートはキャッシュの更新という形で行うのですが、その作業自体がCDNの会社にもよりますが従量課金で、使い方によっては結構お金がかかるようなので、最適解が難しいですね。動画とかやってたら使わざるを得ないですけどね。

YAMA そうですね。動画広告配信システムとかやってそういうのを使ってみたいですね。

クロ: 画像サーバーに関しては、クラウドがあるので、小さなマシンを増やすことでしのぐこともできる…かな!

D クラウドの分散ってどうなの?

クロ: 実際VMでやっているだけなのでイメージしづらいけど、共用回線で占める割合増えるからネットワーク性能も上がるはず。

D パフォーマンスの精度とかイマイチよくわからん。結局裏側がどうなっているかわからないから、インスタンスなんぼ立ち上げてもパフォーマンスが出ないことも結構ある。

クロ: まぁクラウドに台数増やして性能あがるものも上がらないものもあるので、ちゃんと試して計測しないと痛い目に合う。

小林 そういう意味だとクラウド選定の際にも、必ずベンチマークとかしてディスクの早さとか自分が求めている性能のところは最低限調べるようにしますね。ポイントがネットワークなのかディスクなのかメモリの速度なのかetc。

―: だんだんお客さんのサービスが育ってくるとどんどん負荷があがってきて、付け焼き刃的に追加また追加していかなきゃいけないケースも結構多い感じがしますね。

クロ: 自分が見ているサービスでは、集計サーバーがIODriveというディスクIOが早いものを使っていますね。そういう性能のいいマシンに頼ることもあります。

小林 AppTizerもひとつのお客さんが使っているアプリがとてつもなく大きくなったので、仕方なく専用サーバーに逃すということをやりました。
やっぱりそれが共有で入っていたときには全体のトラフィックの50%以上がひとつのアプリで占めてしまい、サーバーの負荷の大半がそいつが握っていて、エラーメールが飛んだり…という状態でした。

若林: 自分がやっているもので、月初にドーンと負荷が上がるものもありました。

クロ: そのときは、ディスクを集中的に強化してもらって、ストライピングで複数台並べてやりましたね。あとはミドルのバージョンを上げて設定チューニングして…それだけでだいぶ良くなりましたよ。

D 大抵ディスク負荷だよね。
CPUがヒーヒー言うことは少なくない?

クロ・小林 いや、ありますよ!

小林 ロードアレベージがかなり高く出てしまうことは多いですね。

D マルチコアだったら、実際それぞれに対してかかる負荷はそう多く無いのでは?

クロ: コア数が複数あれば、コマンドでCPU毎の使用率見られるじゃないですか。
それを見てちゃんと分散されてるなーって確認はしてますね。あまりに偏りが出ていたら、酷いけど、そういう状況はあんまり見たことない。
でも、それでもユーザープロセスが50%超えることがあって…
配信なんですけど、広告データ作って配信しているんですけど、その広告配信データをキャッシュできないですよね。なぜなら開始日終了日とか端末毎に違う画像出したり…とかデータがリアルタイムに変わっていくので、毎回毎回作り直してデータ配信しているのでその分ユーザープロセスの負荷が高くなっているというのはある。システムプロセスは5%くらいなのに、ユーザープロセスは50%くらいいってることありますね。

D 配信サーバーって、比較的、なんかあったときに、増やせばいいって対応できると思うけど、それ以外の集計とかDBってあんまり即座に増やして対応ってできないよね。

一同: できないですね~~

D そのへんをもうちょっと対応しやすい形にしないといけない

小林 1アカウントが巨大になりすぎると対応できないということですね。

D 自分がやっていた計測システムはディスクさえなんとかなればよかった!ディスクさえ…

小林 あれはIOが完全にボトルネックになってましたね。

D サーバースペックがね…。

―: なるほど。サーバー強化は有用な対策ではありますが、それができるお客さんとそうでないお客さんがかなり分かれそうですね。それ以前のシステムの作りをもっと意識する必要がありそうです。

第二回目は以上です!
次回はミドルウェア設定などの話に移ります。

登場人物たちが書いたブログ記事

クロの書いた記事
画像広告と動画広告
ウォール広告効果測定のススメ
全部見えてるわけじゃない
クリエイティブの最適化について

Dの書いた記事
Google Adwords API を利用しての開発

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

小林の書いた記事
iOSアプリ64bit版に対応する
Java8に触れてみた 続・StreamAPI編
Java8に触れてみた –StreamAPI編
Java8に注目してみました
個人情報は自分で守れ!

若林の書いた記事
ADMAGEを振り返って~パート1~
Apache Solrについて ~Second Edition~
Apache Solrについて ValueTrackについて考えてみる
よくわかるインターネット広告の効果測定

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




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

  • このエントリーをはてなブックマークに追加
  • Pocket
  • LINEで送る

コメントを残す

*