普段何気なく見ているWeb広告ですが、その裏側では極めて高度な処理が行われているのをご存じでしょうか。ここでは、最新の広告枠の販売形態である「RTB」を支えるインフラについて解説します。

広告主と媒体社の双方のニーズに応えるRTB

近年、市場が急成長しているWeb広告は、広告表示回数やクリック数など効果測定が定量的に行えるという、これまでの広告とは大きく異なる特徴を持ちます。広告の出稿目的はさまざまで、たとえばブランドの認知度を上げることであったり、Webサイトに来て商品を購入してもらうことであったりと多岐にわたります。それらのニーズに応えるため、Web広告技術はこれまで日進月歩で進化してきました。

当初は、広告を出す企業がWebサイト上の広告枠を事前（数週間から数ヵ月前）に購入し、同じ広告を一定期間配信し続けるという形でしたが、その後、より効果的な広告配信を実現するためにさまざまな配信手法が確立されてきました。主なものとしては、検索キーワードに連動して広告を表示する「検索連動型広告」や、広告枠を保有する媒体社と広告主とを束ねてさまざまなWebサイトにさまざまな広告を配信する「アドネットワーク⁠」⁠、さらにインターネット上の行動からユーザの興味・関心を推定してアドネットワーク上でユーザに応じた広告を配信する「行動ターゲティング広告」などがあります。

このように進化し続けるWeb広告において大きな変革をもたらし注目を集めているのが「RTB（Real Time Bidding⁠）⁠」という広告の取引形態です。RTBとは、ユーザがWebサイトにアクセスすることによって生まれる「広告枠」をリアルタイムに売買する手法です。ユーザがWebサイトにアクセスすると、Webサイトを運営する媒体社と広告を出稿する複数の広告主との間でオークションが開かれ、最も高い値を付けた広告主の広告が表示されるという取引がつど発生します。

この取引形態が広まった背景には、広告効果を最大化したい広告主と、広告収益を最大化したい媒体社の意向がマッチしたことが挙げられます。同じ広告枠であっても、誰が見ているのかによって広告主にとっての価値は変動するため、そうした情報もつど考慮に入れて入札額を決定できれば、より効率的な広告配信が実現でき、より大きな効果を得られます。また媒体社にとっても、その広告枠に最も高値を付けている広告主に広告枠を売ることができれば、広告収益を増やせるというわけです。このような背景により、RTBは広がりを見せています。

なお、RTBオークションの出品者である媒体社が広告収益を最大化させるために利用するサービスを「SSP（Supply Side Platform⁠）⁠」と言い、オークションの参加者である広告主が広告効果を最大化させるために利用するサービスを「DSP（Demand Side Platform⁠）⁠」と言います（図1⁠）⁠。

1日に25億件ものリクエストを5ミリ秒で処理するシステムとは

SSPとDSPの間で行われるRTBは、広告枠が発生してから実際に広告が表示されるまでのわずかな時間で行われます。ユーザがWebサイトにアクセスして広告が表示されるまでの時間はおおむね0.1秒以内であり、その間にオークションを実施して表示する広告を決定し、ユーザのWebブラウザに広告を表示するという処理を行っています。

この0.1秒の中にはSSP側での処理やネットワークの通信時間なども含まれるため、DSPが使える時間はわずか数十ミリ秒しかありません。この極めて短い時間の中で、発生した広告枠に表示する広告を選定し、入札する金額を決定します。

また、SSPを導入しているWebサイトにユーザが訪れ、広告枠のリクエストが発生するたびにオークションが行われるため、DSPによっては1日あたりに数十億件もの処理に対応する必要があります。またひとつひとつの取引が売上につながっていることを考えると、システムのトラブルなどによる停止は大きな損害に直接つながってしまいます。このため、単に高速に処理できるというだけでなく、高い信頼性も求められます。

このような要求を満たしたDSPサービスとして「MicroAd BLADE」を提供しているのがマイクロアドです。RTBを通じて1広告表示ごとに適正価格で広告枠を買い付けることによるCPA（Cost Per Action）の最適化や、細やかな広告配信設定、そしてユーザの行動履歴や属性データをもとに広告配信できるターゲティング機能などにより、高い広告効果を実現できるDSPとして多くの企業が広告配信に活用しています。

MicroAd BLADEでは1日に25億件もの膨大な数の入札処理を行っており、そのうちの99％がわずか5ミリ秒で処理を完了しているとのこと。このような高速処理を実現するため、インフラではさまざまな工夫が積み重ねられています。そうした工夫の1つに挙げられるのが、データストアとしてRDBMSのMySQLに加え、KVSであるKyoto Tycoonも利用している点です。

同社ではもともとデータストアとしてMySQLを使っていましたが、それが処理上のボトルネックになることが少なくなかったと言います。そこで導入されたのがKVSで、現在はMySQLとKVSであるKyoto Tycoonが使い分けられています。マイクロアドのインフラエンジニアである元井正明氏は、2つのデータストアの使い分けについて次のように説明します。

「リレーショナルである必要のないもので、かつ高速に参照したいものをKyoto Tycoonに入れています。具体的には、Webサイトを閲覧するユーザの属性情報などですね。一方MySQLは、MicroAd BLADEを使って広告配信を行っている企業が設定した情報などの記録に利用しています（元井氏⁠）⁠」

つまり、パフォーマンスが求められるデータはKyoto Tycoon、信頼性が重要であるものはMySQLと、両者の特性に合わせて使い分けているわけです。

KVSの導入により、データストアがボトルネックになることは少なくなりましたが、リクエスト数やデータ量の増大によって、あらためてパフォーマンス不足が課題となりました。当初はSSDの導入によって問題の解決が試みられましたが、それでも耐えられないほどのリクエスト量になったことから、Fusion-ioが提供している「ioDrive」の導入に踏み切ったと元井氏は話します。

「SSDやメモリの増設などでも耐え切れないリクエスト量になることが予想できていたため、サーバ増設やさまざまな分散方法を検討しました。運用コストやアプリ改修の必要性を考慮した結果、導入したのがioDriveでした。結局、ioDriveを導入したことによってKVSを分散する必要がない状態になり、なおかつリクエストが倍に増えてもとくに問題なく処理できるようになりました。運用コストやシステムの成長スピードなどまで考えると、高価に見えて導入をためらうハードウェアも、実際にはコストパフォーマンスが良いこともあるので、新しい技術や製品の情報収集は重要です（元井氏⁠）⁠」

もう1つ、MicroAd BLADEのインフラで注目したいのが、実際に入札処理を行うフロントサーバ上でMySQLやKyoto Tycoonが動作している点でしょう。マスター自体はフロントサーバの背後にあるサーバで管理されており、フロントサーバ上のMySQLやKyoto Tycoonはそのスレーブとして動作し、マスターとの間でデータのレプリケーションが逐次行われています（図2⁠）⁠。このようにフロントサーバ側でデータを持つことにより、サーバ間の通信で発生する遅延を解消することが可能になり、高速な処理が実現できるというわけです。

スケールアウトが容易な構成で運用負荷を軽減

フロントサーバでデータを持つメリットとして、参照用DBの負荷軽減になる点も見逃せないでしょう。いわゆる3層構造でシステムを構築し、Webサーバとアプリケーションサーバ、データベースサーバを分けた場合、Webサーバやアプリケーションサーバの数を増やしても、データベースを実行するサーバがボトルネックとなってパフォーマンスが伸びないというケースは少なくありません。しかしフロントサーバ側で必要なデータを持ち、リクエストに対する処理を1台で完結できるMicroAd BLADEの構成であれば、データベースサーバがボトルネックになることなく、フロントサーバを増やすだけで処理能力を高めることができます。

ただし、レプリケーションできないデータ量を扱うものは、フロントサーバからリクエストを受ける必要があります。これを実現するために導入されたのがKVSであるKyoto TycoonやFusion-ioのioDriveだったというわけです。とくにioDriveは「更新しながらの参照もすごく高速（元井氏⁠）⁠」ということで、MicroAd BLADEのシステムに欠かせない存在となっています。

こうしたシステム構成は、システムの運用負担の軽減にもつながっていると元井氏は説明します。

「フロントサーバの中の1台が停止しても全体の処理には影響しないうえ、実際のリクエスト量よりも少し余裕を持ってフロントサーバを構築しています。このため、フロントサーバのいずれかに障害が発生しても、基本的には定期メンテナンスのついでに対応すればよいという形になっています。マスターを持つデータベースサーバの障害など、緊急で対応する必要があるトラブルも時にはありますが、フロントサーバのトラブルであれば即時対応の必要があるケースはほとんどないですね（元井氏⁠）⁠」

またリクエストが突発的に増大した場合には、スタンバイ状態のフロントサーバを動かすだけで対応できるとのこと。たとえば受け付けるRTBリクエスト量を10億から15億へと拡大したいというビジネス要望が発生した際も、たった1名のインフラエンジニアが1週間ですべての準備を整え、無事15億のリクエストを受けて正常な入札ができたと言います。このように少ない労力で効率的に運用できることも、MicroAd BLADEのインフラの大きな特長だと言えるでしょう。

既存のシステムに満足せず、常に新しい挑戦を模索

MicroAd BLADEでは、ネットユーザの性別や居住地域、年代といったデモグラフィック情報や、広告主サイトへの興味の度合い、あるいは広告と各Webページの相性などの情報を利用し、RTBの入札内容を決定しています。その膨大な情報の集計に使われているのがHadoopで、そこで解析した結果をKyoto Tycoonに取り込み、配信プログラムから参照しています。その具体例の1つにリターゲティング広告と呼ばれるものがあります。マイクロアドのシステム開発部を統括する佐藤由紀氏は、リターゲティング広告について次のように説明します。

「リターゲティング広告とは、広告主企業のWebサイトにアクセスしたことがある人に対し、再訪を促すための広告配信手法です。企業のWebサイトにマイクロアドのビーコンを設置してもらい、収集したログをHadoopで1～2時間ごとに解析しています。ユーザの行動ごとに配信方法を選べ、たとえばWebサイトのトップページにアクセスした人全員に広告を配信、あるいは詳細ページに3回以上アクセスしたが商品購入はしていない人に広告を配信するといった、広告主の希望に応じたリターゲティング広告を実現しています（佐藤氏⁠）⁠」

また、リターゲティング広告に関する現在の課題と今後の取り組みについて佐藤氏が話します。

「現在のシステム構成では、リターゲティング広告を利用する広告主の数が増えて収集・解析するログ量が増加しても、Hadoopのノードサーバを増やして対応できる構成になっています。運用しやすい構成ではありますが、すでにノードサーバは50台を超えており、このままビジネスが拡大していくとノードサーバの数が膨大になり、運用負担の増大につながると考えています。一方で、広告主に提供するサービスという観点では、現在の機能よりも、もっとリアルタイム性があり柔軟な設定ができるリターゲティング機能を提供していきたいと考えています。この2つの課題を解決するため、全面的な見直しの検討を始めているところです（佐藤氏⁠）⁠」

解析処理のリアルタイム化については、Twitterが公開したStormなどのストリーミング技術も視野に入れて検討を進めているとのこと。現状に甘んじることなく、常に未来を見据え、マイクロアドのシステム開発部は挑戦を続けています。

答えは現場に溢れている─⁠─エンジニアが力を発揮できる環境

マイクロアドのシステム開発部は少数精鋭の方針が貫かれています。そのシステム開発部を統括する立場である佐藤氏は、マネジメントするうえで“⁠エンジニアを信じ、いい意味で頼る⁠”ことを大切にしていると話します。

「新卒の頃より、エンジニアリングだけでなくプロジェクトマネジメントの仕事も行ってきたため、自分よりも能力のあるエンジニアをマネジメントする機会が多かったのです。その中で培った独自のマネジメント手法の根底には、“⁠マネジメントとエンジニアリングはどちらが上でも下でもなく、お互いに必要不可欠な存在である⁠”という考え方があります。その考えに基づき、マネジメントの立場としては、エンジニアを信じ、いい意味で頼るということを意識しています。マネジメントの立場の人間よりも、現場で日々システムと向き合っているエンジニアのほうがシステムに対する良い考えや想いを持っていることは容易に想像できると思います。それでも、“⁠エンジニアを信じて頼るというのは不安ではないですか？⁠”という質問を頂戴することがよくありますが、そのように思ってしまう方はマネジメントの仕事に向いていないと思います。日ごろから傾聴の姿勢でエンジニアの考えや想いを引き出そうとすることができ、物事を俯瞰し論理的に考え、不確定要素があっても決断できる力があれば、不安になることなく、エンジニアを信じて頼ることができると思います。“⁠答えは現場に、そしてエンジニアの中に溢れている⁠”のですから（佐藤氏⁠）⁠」

マイクロアドのシステム開発部において少数精鋭主義が実現できる理由の1つに、この佐藤氏の考え方の下で“⁠個々のエンジニアが自分の力量を最大限に発揮できる⁠”環境が整えられたことが挙げられるのは間違いないでしょう。