ユーザがWebサイトにアクセスした瞬間にリアルタイムにオークションを行い，配信する広告を決定するしくみが「RTB」です。このRTBによる広告配信サービスを提供するマイクロアドに，システムのインフラやアプリケーションの部分などについてお話を伺いました。

わずか5ミリ秒で広告を選定し入札

インターネットにおける広告配信システムのいとつとして，大きな注目を集めているのが「RTB」（⁠Real Time Bidding）というしくみです。これは，広告枠を持つWebサイトにユーザがアクセスした際，そこに表示する広告をリアルタイムにオークション形式で選定するというもの。媒体社が広告収益の最大化を目的に利用する「SSP」（⁠Supply Side Platform⁠）⁠，広告主が広告効果の最大化を目的に利用する「DSP」（⁠Demand Side Platform）という2つのプラットフォームの間で，1回の広告表示ごとにオークションが開催されます。

それでは，具体的にどのような流れで広告が表示されるのかを見ていきましょう。まず，ユーザがWebサイトにアクセスすると，そのWebサイトからSSPに対して広告のリクエストが送信されます。リクエストを受け取ったSSPは，複数のDSPに対して広告枠の仕様やユーザの属性といった条件を提示します。一方，DSPは提示された条件をチェックし，自身が管理する広告の中でマッチするものがあれば金額を提示します。SSPは複数のDSPが提示した金額を比較し，最も金額の高い広告を表示するという流れです。

このように文章で説明すると長くなりますが，ユーザがWebサイトにアクセスしてから広告が表示されるまでの時間はおおむね0.1秒以内です。このように極めて高速にオークションを実施することにより，広告枠を持つ媒体社と，広告を配信したい広告主の双方のメリットを最大化しているのがRTBというわけです。

DSPの「MicroAd BLADE⁠」⁠，そしてSSPである「MicroAd AdFunnel」をそれぞれ運営するマイクロアドによれば，0.1秒（100ミリ秒）のうち，ユーザがWebサイトへアクセスしSSPへリクエストが到達するのに10～20ミリ秒程度，SSPからDSPへのオークション処理時間は80ミリ秒以内（各オークション主催者がそれぞれ定義）となっているそうです（図1⁠）⁠。また，80ミリ秒の中身としては，ネットワーク通信とDSP内の入札広告選定処理に分かれますが，ネットワーク通信は一事業者が完全にはコントロールできない部分であるため，DSP内での入札広告選定をどれだけ高速にできるかがRTBの鍵になるとのことです。

MicroAd BLADE（図2）では「誰がどの広告主サイトにどのくらい興味があるか」「⁠誰がどの広告を何回見たか」「⁠各広告と各Webページの相性⁠」⁠，そして性別や居住地域，年代といった「デモグラフィック情報」などを総合的に判断し，入札する広告とその金額を決定したうえでSSPに通知します。MicroAd BLADEの技術的な特長として，この入札広告の選定処理が極めて迅速に行われることが挙げられ，1日25億件という膨大な数の入札処理の99％を，わずか5ミリ秒（1000分の5秒！）で完了しています。

サービスのインフラを設計から運用まで3人で実施

このように高速な処理を行うインフラはどうなっているのでしょうか。マイクロアドのインフラエンジニアの元井正明氏は，特にデータベースがボトルネックになるとして次のように説明します。

「マイクロアドのインフラは，いわゆる3階層システムです。遅延が発生すると大きな問題につながるため，それぞれの領域において遅延をサンプリングし，数値に落とし込んでチェックするといった形で品質を管理しています。ボトルネックとなりやすいのは，やはりデータベース部分ですね。MySQLを使っていますが，数年前からは一部をKVS（Key-Value Store）にリプレースし，当初はTokyo Tyrant，現在はKyoto Tycoonを利用しています。ただRTBの場合，膨大なリクエストが発生し，またデータ量も増大しているため，KVSを使っただけでは徐々に耐えられなくなってきています。そこでストレージをSSDに変更したり，あるいはKVSを運用しているサーバの数を増やして負荷分散したりすることで対応しました。しかしながら，この構成では今後のリクエスト増加に対して十分なパフォーマンスを得られないことがわかっていたため，次の策としてFusion-ioがリリースしているioDriveを導入しました。これを導入しただけで今までのKVSサーバを減らすことができ，なおかつリクエストが倍に増えても対応できるようになりました。ioDriveは甘えと言われることもありますが，運用コストやシステムの成長スピードを考えると，OSSだけでなく商用製品のキャッチアップも大事ですね」（⁠元井氏）

なお，マイクロアドで現在運用しているサーバは約700台。3人のインフラエンジニアで機器選定から構築運用までのすべてを行っています。ちなみに現状で利用されているのはすべて物理サーバで，IaaS（Infrastructure as a Service）などは利用していないとのこと。IaaSではパフォーマンスの問題が考えられるうえ，ネットワークの遅延も発生してしまうため，現状では物理サーバの性能をフルに使い切る方向でシステム構築を進めているということです。

自前でキャッシュのしくみを開発

広告の選定や入札のロジックが組み込まれたアプリケーションは，マイクロアドではJavaで開発しています。特にWebの領域では，PerlやPython，Rubyといった言語が広まっていますが，パフォーマンスの点ではJavaのほうが優れていること，そしてスレッドを扱いやすいといったところが選定のポイントだったようです。

このJavaで開発したアプリケーション部分において，高速化のポイントになっているのはキャッシュのしくみであると同社のアプリケーションエンジニアの池田貴紀氏は説明します。

「Webアプリケーションの場合，やはりデータベースアクセスがボトルネックになりがちです。そこを解消するためにKVSを使い始め，現在ではKyoto Tycoonを利用しているわけです。ただ，現状ではKyoto TycoonのJava用ライブラリが公式にはないんですね。そのため，自前でライブラリを開発しているほか，コネクションプーリングのしくみやデータを複数のサーバに分散して管理するためのしくみなども作っています。また，高速化のためにデータのキャッシュも行っています。キャッシュと言えばmemcachedがよく使われていると思いますが，そうするとmemcachedとの通信やオブジェクトへデシリアライズする処理が必要になります。そのコストを改善したいということで，Javaのメモリ内にできるだけデータを保持するような構成にしています。もちろん元データはデータベースやKVSにあるわけですが，キャッシュできるデータはすべてJava側で持ってしまうという考え方です」（⁠池田氏）

また，ひとくちにキャッシュと言っても，データの内容によって具体的な処理は変わると言います。

「キャッシュするデータにもいくつかの種類があり，整合性を担保する必要があるデータもあれば，そうでないものもあります。そのあたりを見極めて，適切にキャッシュしていくことが大切ですね。たとえばマイクロアドでは数万件もの広告データがあり，そのマスタはMySQLに格納されています。毎回MySQLに問い合わせると遅いので，アプリケーション側でキャッシュしていますが，広告データは随時変わるので，その変更を反映しなければなりません。そのため，現在では2分間に1回はキャッシュを全更新しています。このように定期的にキャッシュの更新を行い，その間のマスタのデータ更新は無視するという方針です。一方で，より重要な配信期間などの情報は，入札する前にMySQL内の情報をチェックしています。このように，キャッシュするデータの内容に応じてきめ細かな制御を行っています」（⁠池田氏）