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

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

[落合省治，ユナイテッド]

はじめに

　今回は「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はリクエストに対する結果をキャッシュできない、時間単位のコネクション数が膨大になるという特性上、インフラを一定以上スケールダウンすることができないので、下手な設計をすればたちまちインフラコストが跳ね上がります。