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

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

どうも。粟飯原です。

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

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

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

登場人物

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

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

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

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

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

分散を意識した設計

―: 負荷試験はどのようにやっているでしょうか。

D: jmeterつかってリクエストを投げる。

クロ: クライアントっていくつも並べないと負荷かけられないですよね。

D そうですね。相手の規模によって、必要になる負荷は変わるんですが、すごく大きいシステムに対してはそこまでの負荷はかけられないですね。
もともとの負荷試験って、1アカウントがでかいのがいたときみたいなのでやっていたけど、nアカウントという観点ではなかった。

―: Hadoopを使ったシステムにも携わっていましたが、Hadoopはどうでした?

D: 配信サーバーがあって、ログを全部Hadoopにぶち込みます。で、Hadoop上でいくつかファイルを作って、集計サーバーでHadoop側からファイルをとって集計するという構成になってましいた。しかし、詳細は言えませんけど、プログラムの造り方含めて、かなり悩ましいところもありました…。

―: なるほど。プログラム自体の設計とか、そういった点は社内共有がもっとできそうですね。

クロ: 実際にやってみないと、ここが重要・この観点が抜けてるっていうのは気付きづらいから、1つのモデルをブラシュアップしていくのがいいんですかね。

D 知見が他からありゃ持ってきたいのはヤマヤマなんですけどね。Hadoopとか使ってもどれだけやりゃ効果出るのかピンとこないですね。

クロ: そうですね。
ADMAGEは広告システムに必要なものをまとめたパッケージシステムなので、メディアと広告主とASPのどちらに向けても使うことができます。
ただ、メディア側に経つと配信に負荷かかるし、広告主側に立つと自然流入とか第三者配信とかしたいからその他のトラッキングデータも集めて持っておいていつでも見られるようにしてほしいとかいう要求が入ってくる。
計測するモノが全然違ってくる、なので溜めるデータも違ってくるという難しさがありますね。
たとえば、ページ内解析とかアプリ内解析的な用途で使おうとしたらトラフィックは厳しくなりますね。

D: もともとそういう用途で作っていないしね。

若林: GoogleのSDKとかは毎回毎回送っていないですよね。

小林: 溜め込んで送って…って感じですね。
リアルタイムに近くなるようにはしていますが、何秒か毎にまとめて送っているので、サーバー側の負荷はそう重くないみたいです。

―: 分散を意識するだけでなく、サーバー側の負荷を低減して、ある程度クライアント側にやってもらう設計も必要ですね。

D: 広告主向けだと、やっぱり大きいところはトラッキングデータとっておけって話になるんだよね。
それでそのトラッキングデータをどうやって扱うかって話になるわけで…

クロ: で、大きくなってくる。
アカウントが最初から大きいパターンと、入れてくれたクライアントがどんどん成長して大きくなっていくパターンと2つあって、どっちにも対応したいですね

D: 自分がやっていた計測システムでは、ほとんどサイト解析のデータで問題になってた。
データ溜めて全部残しておかなきゃいけないし、行動履歴も残しておかなきゃいけないから持たなきゃいけない情報多くなりすぎちゃった。かつPV数が多い…

クロ: 若林さんがやってた計測システムはどんな感じでした?自然流入とかアトリビューション計測とか。

若林: KVS使って、KVSに訪問タグの履歴とかを書いて…ってやってたくらいですね。

クロ: データ捨てていく前提でやるならいいけど、永続的に溜めて使うことを考えていると結構難しい。実際広告データなんて1か月前の行動履歴なんて残していてもしょうがないから消していけばいいと思うけど。

D: 1年くらい普通に使ってるところもありますよ。全部とっておいてありますもん。

クロ: メディア側なら配信システムなので、配信サーバー並べることである程度はできる。まぁその場合それだけ並ぶとログ書き込みにすごく時間がかかるので、それで止まっちゃった経験はあります。
それはIODriveの中に直接書き込むって方法にしました。

D: 結局のところ、ログをどう処理するか、というのがポイントだよね。

―: HadoopやKVSなど技術をうまく取り入れつつ、分散を意識した設計にしていきたいですね!

ミドルウェア

―: ミドルウェアの設定では何かポイントがありますか?

D: MySQLのパーティションは切る!!

クロ: ずっと取っておくデータもパーティションで分けられると良いですよね。年とか月とか。

YAMA 自分のところのシステムも月で一番大きいので、毎月1億くらい溜まるので、そこはもうパーティションにしています。

D: パーティションしてても1億はきつくね?

―: MySQLパーティションはMySQL5.1以降に実装された機能ですね。

D: 新しいミドルはどんどん使った方が良いでしょう。

クロ: 集計する前のログをためるDBと集計に使うDBとマスタに使うDBってそれぞれ向き不向きがある気がしますね。
ログ溜めるのはそれでやって、集計結果では別にやって、とか必要ですよね。
そういうのを最初から見きれないからね。何が起きるかは後から出てくる。

小林: 負荷分散するときにまず一番簡単にできるのはミドルのチューニングですね。
チューニング間違っていたり設定怠っている…という失敗談は結構多いと思う。Connectionとかメモリ量とか、単純なところですけど。

―: ミドルバージョンを上げるのも手ですかね。

クロ: そうですね。ただ、しっかり検証した前提。

小林: うちで言うとApache、php、MySQL、tomcat、javaなど、最低限の組み合わせで検証が必要ですね。

―: パッケージとしては安定的に動くバージョンで出す必要があるので、すぐ変えられるものではないですが、対策としては有用って感じですね。

小林: DB回りとかミドルウェアとかは、性能の劣化の中にメモリリークとか製品の問題があるのでそれが1コ解決されるだけで大きく変わるとかは当然ありますね。
あとは、実際に性能上がらなくても、調査がしやすくなるんだったら、例えばjava8に上げたらいいって観点もあると思う。できることも増えますから。
もちろんできなくなることも多いんだけど、それが今の製品にあってるかどうかのトレードオフで新しいものを取り入れていったらよい。

―: 実際にミドルのバージョンを変えてすごく性能が上がった例はありますか?

小林: やはりMySQLは顕著ですね。

クロ: innoDBの性能がすごくあがってて、5.6とかパフォーマンスに注力してやっているので、性能上がるって効果ありますよね。あとはパーティションは使って当たり前の時代に入ってますね。

第三回目は以上です!!
次回は最終回!ADMAGEの今後について語ります!!

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

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

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で送る

コメントを残す

*