100K QPSに対応するRTB基盤のエンジニアリング

アドエクスチェンジから入札リクエストが届きます。入札インフラは10ms以内にそのインプレッションを評価し、稼働中のキャンペーンと照合してスコアリングし、入札価格を算出してレスポンスを返さなければなりません。

期限を逃せばインプレッションは失われ、再試行はできません。100,000+ QPSでは、1%のタイムアウト率でも毎秒1,000件の機会損失になります。

ビッダーをアドエクスチェンジとコロケーションし、評価時間を取り戻す

ビッダーとアドエクスチェンジ間のネットワークレイテンシは、入札評価に使える時間をそのまま削ります。エクスチェンジから50msの距離にあるビッダーは、コードが動き出す前にすでに負けています。

主要なアドエクスチェンジとビッダーインスタンスをコロケーションするDSP開発チームは、決定的なミリ秒を取り戻せます：

• 世界6〜8拠点のデータセンターに配置すると、集中配置と比べてリクエストあたり5〜15msの評価時間を取り戻せます
• 各リージョンのオートスケーリンググループがトラフィックの波に追随します。米国東部が業務時間帯にピークを迎える間、アジア太平洋は縮退します
• リージョンごとの入札インスタンスはキャンペーンのターゲティングデータをローカルに保持し、中央ストアから5-10秒ごとに同期します
• データセンター間の光ファイバは同期トラフィックを運びますが、入札評価の経路がリージョンをまたぐことはありません

入札評価のホットパスからメモリ確保を排除する

10万QPSでは、メモリ確保のパターンがレイテンシ予算を満たせるかどうかを決めます。100QPSでは見えないガベージコレクションの停止が、この規模では致命的になります。

入札評価の経路では、次の手法を使います：

• キャンペーンのターゲティング条件、フリークエンシーキャップ、予算制約は事前計算済みのルックアップテーブルで保持し、メインのキャンペーンストアから5-10秒ごとに非同期で更新します
• オブジェクトプールとアリーナアロケーションにより、リクエストごとのヒープ確保を完全に排除
• 共有状態にはロックフリーのデータ構造を使います：フリークエンシーキャップにはブルームフィルター、予算ペーシングにはアトミックカウンターを用います
• ターゲティング評価用の事前構築済み決定木：木の構築には数秒かかりますが、評価はマイクロ秒で完了します

ホットパスでのゼロアロケーションは最適化ではありません。100K QPSでは必須要件です。

MLモデルの推論を1入札あたり3ms未満で実行する

クリック率予測とコンバージョン確率のモデルは、入札評価パイプライン全体の一部として2〜3ms以内に推論を完了する必要があります。推論に使った1msは、他の入札ロジックには使えません。

INT8量子化モデルを使うONNX Runtimeが、レイテンシと精度の最良のバランスをもたらします：

• ユーザーとコンテキストのシグナルを事前計算した特徴量ストアを使い、ビッドリクエストからの特徴量抽出を0.5ms未満で行います
• スレッド固定実行でONNXをバッチ評価し、モデル推論を1〜2msで完了——スコアリング中のコンテキストスイッチはありません
• キャンペーン階層ごとの事前計算済み価格カーブを用いて、スコア補正と入札価格の算出を0.5ms未満で行います
• モデル更新はブルーグリーン方式で反映します——新モデルをシャドーモードで読み込み、本番の予測と突き合わせて検証したうえで、アトミックに切り替えます

入札経路にオーバーヘッドを加えずに大規模に監視する

100K QPSでは、従来型のロギングが入札ロジック本体より大きな負荷を生みます。監視スタックはアプリケーションと同じく性能を意識して作る必要があります。

• サンプリングによる指標収集：1,000件に1件のリクエストを詳細に記録し、残りはアトミックに更新されるカウンターとヒストグラムに集約します
• リージョン別、アドエクスチェンジ別、キャンペーン階層別に、p50、p95、p99をリアルタイムで追跡します
• p99レスポンスタイムがエクスチェンジのタイムアウトを超えたビッダーインスタンスを、サーキットブレーカーが自動でローテーションから外します
• 入札率の低下、落札率の変化、消化ペースのずれを異常検知。エラー率の監視より早く、陳腐化したモデルやネットワークの劣化を捉えます

オークションのSSP側を担う

サプライサイドプラットフォームは、その鏡像の課題を抱えます。数十のビッダーに入札リクエストを配信し、レスポンスを集め、フロアプライスを評価し、オークションを実行して落札者を返す。これらすべてを自らの厳しいタイムアウト内で行います。

SSP開発チームには、さらに複雑な要件が加わります：

• ヘッダービディングは複数のオークションを並列で実行することを意味します：各入札者のタイムアウトがSSPのレイテンシ予算になります
• MLモデルによるフロアプライス最適化は、レイテンシを増やさず同じオークションの時間枠内で実行される必要があります
• 高性能なオークションロジックが1インプレッションあたり20〜50件の入札レスポンスを評価し、1ms未満で落札者を決定します

大規模なプログラマティック広告では、オークションの双方が低レイテンシを徹底して追求する必要があります。

入札インフラをモバイルアプリとアプリ内在庫に対応させる

アプリ内の入札リクエストは、Webのリクエストとは異なるシグナルを持ちます。クッキーベースのシグナルの代わりに、デバイス単位の識別子（利用できる場合）、アプリのコンテキスト、SDKが報告するビューアビリティが使われます。

ウェブ在庫で学習したクリック率モデルは、操作パターンが大きく異なるアプリ内環境向けに再学習が必要です。

• モバイルのアトリビューションモデリングには、MMPとのサーバー間ポストバック連携が必要です
• 複数のアトリビューションウィンドウをまたいだ重複排除により、コンバージョンの二重計上を防ぎます
• 確率的マッチングと決定的マッチングの突合は非同期で実行し、結果は24時間以内に入札モデルへ反映されます