ユーザが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内の情報をチェックしています。このように、キャッシュするデータの内容に応じてきめ細かな制御を行っています」（⁠池田氏）

ボトルネックを見極め改善を繰り返す

Javaにはメモリ内の不要な領域を解放する「ガベージコレクション」という処理があります。このガベージコレクションが実行されるとパフォーマンスが大幅に低下してしまうため、特にリアルタイム性の強いアプリケーションでは、このガベージコレクションが大きな問題になるケースがあります。ただ池田氏によれば、これまで問題となるような事態は発生していないと言います。

「まず前提として、不要なオブジェクトの生成を極力しないよう注意して開発しています。たとえば、アプリケーション内で1つしか必要のないインスタンスは起動時に生成し、DI（Dependency Injection）でインスタンスを注入して1つのインスタンスを使い回すようにしています。そのようなクラスはもちろんスレッドセーフにする必要があります。それでもオブジェクトの生成と破棄はかなり発生しているはずなのですが、メモリリークが発生しないように注意してコーディングをしたり、またサーバにできるだけ多くのメモリを載せていることもあり、ガベージコレクションが問題となったことはないですね。また、ヒープをダンプして、どのオブジェクトがどの程度の容量を使っているのかといったチェックも行っています」（⁠池田氏）

さて、5ミリ秒という驚異的なスピードを実現するため、マイクロアドではシステムのボトルネックを特定して改善するという作業を繰り返し行っています。その際に注意していることとして、池田氏はボトルネックを見誤らないことを挙げます。

「ボトルネックになっているところを正しく見極められず、見当違いな場所を修正しても効果はありません。そのため、本当にボトルネックになっている個所を正しく判断することがまず重要になります。ボトルネックを発見できれば次は改善ということになり、問題に応じて適切に対処することになります。たとえばデータベースが遅いという話であれば、キャッシュすることはできないか、サーバの台数を増やしてパフォーマンスを改善できないか、あるいはFusion-ioを使えないかなど、具体的な対応を検討していくわけです。データベースとのセッション部分が問題ではなく、アプリケーション側で対応しなければならない場合には、アルゴリズムやデータ構造を見直していくという流れですね」（⁠池田氏）

少人数の精鋭エンジニアでシステムを開発

このようにさまざまな工夫を積み重ねてRTBを実現しているマイクロアドのシステムですが、同社には20名弱のエンジニアしか在籍していません。その背景について、同社のシステム開発部を統括している佐藤由紀氏は次のように話します。

「Web業界は変化のスピードが速いと言われていますが、そのような状況下では単に頭数をそろえるよりも、一人一人が自律的に考え、行動し、エッジの効いた価値を創出できることが重要と考えています。そのため、マイクロアドのシステム開発部では、少数精鋭、鋭利、先鋭的といった意味で『鋭』というテーマを掲げています。少人数であることの利点を活かし、自分の担当範囲に縛られることなく、インフラでもミドルでもアプリでも、自由に首を突っ込んでいくことで、総合力でより良いシステムを作り上げています。

もう1つ、『⁠Velocity』というテーマもあります。Velocityとは速度のことであり、速さ（スピード）と方向を持ったベクトル量のことを指します。仕事のスピードが必要とされる業界ではありますが、スピードを追い求めるだけでは不十分です。どちらを向いてスピードを出しているのか、方向という要素が欠かせないと考えています。全員で同じ方向を向いて走ることが必要なときもあれば、可能性を広げるためにあえて異なる方向を向いて走るべきときもあります。方向を意識することで、一人一人の仕事のクオリティも、私たちの提供するプラットフォームシステムのクオリティも向上していくと考えています。こうした考え方に基づき、ピラミッド型の組織形態ではなく、全員が何らかの決定権を持ち、責任を持って自由にそしてストイックに仕事をするというのがマイクロアドのシステム開発部のスタンスです」（⁠佐藤氏）

マイクロアドで働くエンジニアに求められるスキルを佐藤氏に伺ったところ、次のような答えが返ってきました。

「エンジニアが主体的に動くことを重視しているので、その意味で『ゼロベースで物事を考えられるかどうか』はとても大事だと考えています。あとは、技術自体を目的にしないことですね。まず実現したいこと、あるいは改善したいことがあり、それに使える技術かどうかという視点で考えられることが大切だと思います。最新の技術にアンテナを張ることはもちろん重要ですが、『⁠新しいのか古いのか』『⁠流行っているのかいないのか』ということ自体は技術の本質ではないと冷静に考えられるエンジニアが良いですね」（⁠佐藤氏）

インフラエンジニアとして求められるポイントについて説明するのは元井氏です。

「佐藤が話したことに加えて、システム全体のしくみ、技術を把握することですね。ミドルウェアやOSの動きを知るうえで、ハードウェアの知識は必要ですし、ネットワークではパケットの動きなどについても理解しておく必要があります。当然ながらアプリケーションの動作も把握しておく必要があります。このようにさまざまな領域について知識があれば、トラブルが発生したときに障害のポイントをすばやく切り分けられますよね。あるレイヤしか調べられないということになると、トラブルの原因がそれ以外のレイヤだったときに複数のエンジニアで対応する必要が生じます。特に緊急時にはシステム全体を見ることができれば1人で原因を特定でき、場合によっては解決までできます。もちろん、すべてのレイヤを完璧にというのは無理ですが、複数の領域にまたがって知識を持つということは大切だと思います」（⁠元井氏）

このようにマイクロアドでは、職人気質のエンジニアが高い意識を持ってシステムの構築や運用に携わっています。同社が広告プラットフォームの世界をリードし続けられる理由として、それぞれのエンジニアが決定権を持ち、自由な環境の中で新たな価値の創造に向けて伸び伸びと働ける環境があることは間違いなさそうです。