第5回 開発目線からのRTB【連載】これで分かる! アドテクノロジー入門(1/2 ページ)

RTBの応答を少しでも早めるには、あらゆる面でRTBの処理時間の最小化を目指さなければならない。しかし、RTBの構造上の複雑さが事態を複雑にしている。

» 2013年02月19日 08時53分 公開
[落合省治,ユナイテッド]

はじめに

 今回は「Trading Deskの基礎――成立の背景からビジネスモデル、今後の展開予想まで」よりもさらにRTBの技術的な面に突っ込んだ解説をしていきます。RTBの特性について理解することで、より効果的にRTBを利用できる一助になると思います。技術的な用語が多くなりますが、ご了承ください。

RTB開発の難しさ

 前回記しましたが、RTBは仕組み的に従来のアドネットワークに比べて難しい部分があります。よく言われるのは「全てのアクセスをリアルタイムで高速に処理しなくてはならない」ということです。しかし、これは広告配信の技術には常について回る問題です。気を使う部分ではありますが、一般的な広告配信レベルの高速化であれば、Web配信でよく使われる技術を組み合わせることで、十分なレベルでの高速化が実現可能です。

 問題は、RTBという仕組みが構造的に複雑であるということです。

 広告を配信するためのシステム全体でみれば、RTBは中間的な位置にあるために、通信を行う対象と、データの通信量が多くなります。通常のアドネットワークであれば、内部の通信を除けば、外部とは広告を配信する対象(アプリまたはWebブラウザ)と通信するだけで済みます。データ転送量も広告を配信するのみです。

 それに対して、RTBは広告の配信先に加えて、各DSPとのデータのやりとりも発生します。接続しているDSPが3つあったとしたら、単純にデータのBid情報のやりとりは、1DSPとのやりとりと比べて3倍になります。当然データ送受信の処理もその分複雑になりますし、データ転送量が積算で増えていくので、帯域使用量も増え、結果的にインフラコストが跳ね上がっていきます。

 またRTBは連携している全てのDSPの応答を100ms前後(弊社では120ms)まで待ちます。120msというのは、アドネットワークの応答速度から考えれば気の遠くなるほどの時間です。というのも、サーバー間のコネクションやデータ通信速度などのネットワーク通信速度を除けば、実際サーバー上だけでの処理時間など、数ms、速ければ1ms以下というのが普通です。これにネットワーク通信の時間が加わって(これがほとんどなのですが)、十数msから数十msというのが最終的にWebブラウザなどに広告が届くレスポンス時間になります。RTBは仕組み上、サーバー上だけで最大120msという待ちをしなければなりません。もちろん、全てのDSPから応答があれば、その時点で待ちは終わるのですが、それでも平均40ms前後はDSPの応答を待たなければなりません。RTBがどれだけ速く処理を行おうが、です。

 だからこそRTBの応答を少しでも早めるために、RTBの処理時間はあらゆる面で最小を目指さなければなりません。

 もちろん、さまざまなコスト(開発コスト、インフラコスト、運用コスト、メンテナンスコスト)との両立も大事です。RTBはリクエストに対する結果をキャッシュできない、時間単位のコネクション数が膨大になるという特性上、インフラを一定以上スケールダウンすることができないので、下手な設計をすればたちまちインフラコストが跳ね上がります。

       1|2 次のページへ

Copyright © ITmedia, Inc. All Rights Reserved.