RTB ビッダーのインフラストラクチャ オプション(パート 4)

この記事では、デマンドサイド プラットフォーム(DSP)で実行される主なタスクについて説明します。これらのタスクには、広告リクエストの処理、インテリジェント データの使用、入札、イベントの処理などが含まれます。一般に、これらのタスクはすべて迅速に(約 100 ミリ秒以内に)実行される必要があります。レイテンシの期限は、販売サイド プラットフォーム(SSP)または Ad Exchange によって設定されます。このドキュメントの残りの部分では、標準の期限として 120 ミリ秒(Google の最も一般的な SLA)を使用します。

この記事は、次のシリーズの一部です。

このシリーズ全体で使用される広告技術用語の概要をご覧ください。

概要

広告主への直接販売のほかに、サイト運営者はリアルタイム入札(RTB)システムでインプレッションを購入するプログラマティック購入者に在庫を公開することもできます。サイト運営者は、残りの在庫を売却するか、管理のオーバーヘッドを削減するためにこれを行うことがあります。RTB では、広告のインプレッションに入札した購入者に対して、サイト運営者の在庫のオークションが行われます。

オークションを行うには、サイト運営者は Ad Exchange や DSP で動作する SSP を使用して、オークションで獲得した広告を自動的に返却します。詳細については、概要の入札者セクションをお読みください。

次の図は、統合された広告配信がない DSP システムで利用できるアーキテクチャを示しています。

統合された広告配信がない DSP システムで利用できるアーキテクチャ

キャンペーンや入札の管理者などの管理フロントエンドの詳細については、ユーザー フロントエンド(パート 1)をご覧ください。

このアーキテクチャとパート 3 で説明した広告サーバー用のアーキテクチャの違いは次のとおりです。

  • 機械学習の予測がオフラインで行われる。これらの予測を、局所性鋭敏型ハッシュを使用してインメモリ ストアにコピーし、固有の特徴の組み合わせに基づいてキーを作成します。広告配信の記事(パート 3)で説明されている高速な機械学習配信のその他のオプションをご覧ください。
  • 入札者が読み取るデータは、高速読み取り用としてインメモリのクラスタ化された NoSQL データベースに格納されます。

プラットフォームに関する考慮事項

必要なほとんどの情報は、プラットフォームに関する考慮事項のセクション(パート 1)で提供されています。ただし、このセクションで説明しているように、入札者はいくつかの要件を満たす必要があります。

地理的なロケーション

ネットワーク レイテンシを最小限に抑えるには、主要な Ad Exchange の近くに入札者を配置します。近接性により、入札者と Ad Exchange との間の通信中に生じるラウンドトリップ時間が最小限に抑えられます。Ad Exchange は、入札リクエストが送信されてから約 120 ミリ秒以内にレスポンスを要求することがよくあります。タイムアウトが頻繁に発生すると、DSP の入札機能に影響を与える可能性があります。

  • 短期的には、入札者が特定のオークションを逃してしまいます。
  • 中長期的には、SSP が DSP のスロットリングを開始し、送信する入札リクエストが少なくなる可能性があります。

負荷分散

Cloud Load Balancing では、80 を超えるグローバル ロケーションで、低レイテンシで 1 秒につき 100 万件以上のクエリがサポートされます。フロントエンドは単一のグローバル IP アドレスで利用でき、DNS 設定が容易になります。また、Cloud Load Balancing は Cloud CDN と統合されています。

Kubernetes を使用すると、ロードバランサはトラフィックを VM インスタンスに配信し、kube-proxy は iptables をプログラミングしてトラフィックをエンドポイントに配信します。この方法では、ネットワークのパフォーマンスに影響する可能性があります。たとえば、適切なポッドが含まれていないノードにトラフィックが到着すると、余分なホップが追加される可能性があります。Google Kubernetes Engine(GKE)は、エイリアス IP を使用する VPC ネイティブ クラスタコンテナ ネイティブの負荷分散を使用して余分なホップを削減できます。

Cloud Load Balancing は推奨されるアプローチですが、Compute Engine または GKE での独自の負荷分散の設定を検討することもできます。

  • DSP フロントエンド ワーカーが広告リクエストを処理します。
  • リクエストが既知の(一意の)ユーザーに対するものである場合、広告またはキャンペーンがそのユーザーに配信された頻度に関する頻度カウンタが増分されます。
  • ユーザーがキャップによって指定された最大しきい値に達すると、その(一意の)ユーザーに対して一定期間、入札が行われません。

RTB 入札者は 1 日に何十億ものリクエストを処理しているため、(一意の)ユーザーの入札リクエストと、それらのリクエストを処理する DSP フロントエンド ワーカーの間にアフィニティを確立していない場合、リージョンごとに受信イベントを一元管理し、(一意の)ユーザーごとにカウンタを集計する必要があります。概要ですでに示したアーキテクチャでは、コレクタがイベントを取り込み、Cloud Dataflow が処理した後、最終的にカウンタなどの値がマスター Redis ノードによって増分される、一元管理されたアプローチを示しています。

アフィニティ化アプローチを使用すると、同じフロントエンド ワーカーで、同じ(一意の)ユーザーに関連するすべての広告リクエストを処理できます。フロントエンドでは、カウンタのローカル キャッシュを保持できます。これにより、一元管理処理の依存関係(このユースケースの場合)が削除されます。その結果、オーバーヘッドが少なくなり、レイテンシが減少します。

リクエスタとプロセッサの間のアフィニティは通常、受信リクエストのヘッダーを解析することによってロードバランサ内で確立されます。ただし、Ad Exchange では通常、このユーザー情報からヘッダーが除去されるため、リクエストのペイロードを処理する必要があります。これは Cloud Load Balancing ではサポートされていないため、独自のロードバランサの設定を検討している場合は、HAProxy などのソフトウェアを検討することをおすすめします。

最終的に、グローバル インフラストラクチャを提供するマネージド サービスを選択するか、特定のユースケースに採用できるカスタムビルドを選択するかを決定する必要があります。

プロバイダへの接続

Ad Exchange と SSP の関係や近接性に応じて、次の接続オプションを検討してください。

  • いずれかのパートナーで相互接続をセットアップした後、すべてのパートナーに関して Ad Exchange または SSP に依頼して同様の相互接続をセットアップします。このオプションを使用すると、稼働時間、スループットの予約、および下りコストの削減に関して SLA が提供されます。
  • Ad Exchange または SSP が GCP のお客様でもある場合は、ネットワークのコストを削減できるので、VPC ネットワーク ピアリングのセットアップを検討してください。このオプションはセキュリティに影響するので注意してください。

レイテンシをさらに短縮するには、次のオプションを検討してください。

  • サポートされている場合、UNIX ドメイン ソケットを使用してローカル データストアと通信する。
  • 可能な場合、QUICUDP などのプロトコルを使用する。
  • プロトコル バッファを使用して、データ ストリーム間での構造化データのシリアル化およびシリアル化解除を高速化する。

入札リクエストの処理

入札リクエストは、フロントエンド セクションで概要を説明しているのと同じスケーリング要件があるフロントエンドが受け取ります。

入札リクエストは一般的に JSON 形式や protobuf 形式でシリアル化され、IP アドレス、広告ユニット ID、広告サイズ、ユーザーの詳細、ユーザー エージェント、オークションのタイプ、最大オークション時間が含まれます。多くの DSP と SSP は、OpenRTB 標準とともに動作します。ただし、使用されている標準やシリアル化に関係なく、フロントエンド コードでペイロードを解析し、必要なフィールドとプロパティを抽出する必要があります。

フロントエンドは、HTTP ステータス コード 204 などの非入札レスポンスで返して入札リクエストを破棄するか、次のステップに進みます。

入札単価

入札者は次のタスクを実行します。

  • ユーザー マッチング: (一意の)ユーザーを特定する。
  • セグメントの選択: (一意の)ユーザーのセグメントとその価格を取得して選択する。
  • 入札するかどうかを決める: 入札単価が高すぎる場合や、広告リクエストが既存のキャンペーンと一致しない場合があります。入札者は入札を拒否できる必要があります。この拒否により、処理時間とリソースを節約します。
  • 関連する広告の選択:** **入札者が入札を決定した場合、入札者は広告も選択する必要があります。適切な広告を選択することで、ユーザーがクリックしてコンバージョンが生成される可能性を高めることができます。
  • 入札の最適化: 入札者は常にオークションに勝つ最小入札価格を模索します。
  • 入札レスポンスの作成: OpenRTB またはカスタム アプリケーションを使用して、protobuf または JSON 形式でシリアル化された入札レスポンスを作成して返します。レスポンスには広告 URL、入札単価、獲得 URL エンドポイントなどの情報が含まれています。

機械学習でこれらの入札タスクが容易になることがあります。たとえば、ML を使用して最適な価格を予測し、入札決定を行う前に入札で勝てるかどうかを判断できます。ただし、この記事ではインフラストラクチャの決定に焦点を当てています。ML モデルのトレーニングと配信の詳細については、以下をご覧ください。

  • 機械学習においてモデルを構築しホストするために必要なこと(パート 2)
  • 機械学習の配信において予測を配信する際のレイテンシに関する考慮事項(パート 2)

ユーザー マッチング

(一意の)ユーザーを識別するには、一般的に使用される以下の 2 つの方法があります。

  • モバイル広告の場合、リセット可能なデバイス識別子を使用できます。Android または iOS プラットフォーム上に構築されたネイティブ アプリは、リセット可能なデバイス識別子にアクセスできます。
  • ウェブ上での広告の場合、広告プラットフォームは、リセット可能なユーザー識別子を格納するために Cookie を使用できます。ただし、Cookie は作成元のドメインでしか読み取ることができないため、プラットフォーム間で識別子を共有するのは簡単でありません。広告技術の利用者は個々の Cookie に合わせてテーブルを作成し、お客様を幅広い視野から把握できます。

マッチテーブルは、SSP、DSP、DMP、広告サーバーの間で使用できます。これらのプロセスのすべてが非常に似ていても、パートナーシップごとに異なるプロセスを実装します。

リアルタイム入札では、DSP が入札リクエストを受信する前に Cookie マッチング プロセスが行われることがあります。DSP が他の広告インプレッションから SSP との Cookie マッチング リクエストを開始するか、SSP が無関係の広告インプレッションで DSP との Cookie マッチング(「ピクセル プッシュ」)を開始します。多くの場合、DSP は、発行者のプロパティではなく、広告主のプロパティで発生する同期を開始します。リアルタイム入札での Cookie マッチングの仕組みについては、Google アド マネージャーのウェブサイトで説明されています。ウェブ上で非常に幅広く使用されています。

SSP と DSP でマッチテーブルのホストについて合意する必要があります。この記事では、DSP がユーザー マッチング データストアをホストしていることを前提としています。このデータストアは、以下の条件を満たしている必要があります。

  • 最大で数ミリ秒以内に特定のキーのペイロードを取得する。
  • リージョン内で高可用性を維持する。
  • ネットワーク処理のレイテンシを最小限に抑えるために、すべてのターゲット地域に存在する。
  • 1 日に何十億もの読み込みを処理する。
  • 現在のカウンタの更新時に高速書き込みを処理する。

NoSQL データベースは負荷の大きい作業を処理するために水平スケーリングが可能で、行を非常に高速で取得できるため、こうしたワークロードに適しています。

1 桁のミリ秒単位で特定のキーを使用して値を取得できるフルマネージド サービスが必要な場合は、Cloud Bigtable を検討してください。高可用性が実現し、その QPS とスループットはノード数に比例します。コンセプト レベルでは、データが Cloud Bigtable に次に類似の形式で保存されます。

キー 内部 ID 作成
ssp_id#source_id dsp_id 123456789

セグメントの選択

入札プロセスのこの時点までに、このシステムでは広告リクエストを受け取り、解析して SSP のユーザー ID を抽出し、内部 DSP のユーザー ID と照合しました。

別の照合を使用すると、システムで(一意の)ユーザー プロフィール ストアからユーザー セグメントを抽出し、価格ごとにセグメントの順序を指定し、最適なセグメントをフィルタできます。次の例は、照合の結果を示しています(わかりやすくするために簡略化)。

キー セグメント 更新
dsp_id [ {‘dmp1':{‘segment':'a',‘type':‘cpm',‘price': 1}} {‘dmp1':{‘segment':'b',‘type':‘cpm',‘price': 2}} {‘dmp2':{‘segment':'c',‘type':‘cpm',‘price': 1.5}} ] 1530000000

順序指定とフィルタリングのロジックによっては、データ プロバイダ名などの個別のフィールドをキーに昇格させたい場合があります。効果的なキー設計は、クエリの時間を短縮するとともに、スケーリングにも役立ちます。キー設計にアプローチする方法については、Cloud Bigtable スキーマの設計に関するドキュメントの行キーの選択をご覧ください。

この記事では Cloud Bigtable をセグメントの読み取りとユーザー ID の照合を行うためのサンプル サービスとして使用していますが、Redis や Aerospike などのインメモリ ストアでは、運用上のオーバーヘッドが増加するものの、パフォーマンスが向上します。詳細については、大量読み込みの保存パターン(パート 1)をご覧ください。

追加の外部ユーザーデータにアクセスするために、DSP では SSP で使用されるのと同様のユーザー マッチング技術を実装するデータ管理プラットフォーム(DMP)を使用することがよくあります。

DSP では、ユーザーのプロフィールを作成するために次の 2 つのプライマリ データソースを使用します。

  • ファースト パーティのユーザー情報: DSP は、広告主のプロパティよりも前にユーザーを認識することがあります。DSP は、ユーザーのプロフィールを作成するために使用できるユーザーに関する情報(Cookie やデバイス ID)を収集します。
  • サードパーティのユーザー情報: 多くの広告主に対応していない DSP は、インターネットまたはアプリケーションを介して多くのプロパティに対応する DMP のデータを使用して(一意の)ユーザーを識別することがあります。ユーザーのマッチングは、サイト運営者が提供するユーザー ID に基づいて行われるか、DSP と DMP の共有によって行われるか、DMP と DSP の間で直接行われます。3 番目の方法の場合、DSP は、DSP もマッチテーブルを保持している DMP からデータをオフラインで繰り返し読み込みます。

サードパーティのデータは、外部の場所から Cloud Storage に繰り返し読み込んでから、BigQuery に読み込むことが可能です。また、メッセージング システムに面しているエクスポーズされたエンドポイントにリアルタイムでデータを読み込むこともできます。

イベントの処理

イベントの取り込みと保存の方法については、イベント管理で説明しています。RTB では、以下の追加イベントも収集されます。

  • 入札リクエスト: 広告リクエストと同様に、SSP または Ad Exchange に提供したエンドポイントに送信されます。
  • オークションでの勝利: オークションで勝利すると、SSP または Ad Exchange は、DSP によって初期段階で定義された獲得エンドポイントにその入札レスポンス内で通知を返します。
  • オークションでの敗北: SSP または Ad Exchange は、入札で勝利しなかった場合、すべての DSP に通知しますが、他の情報を提供することはほとんどありません。Google のエクスチェンジなど、特定の SSP は、その後の入札リクエストでこのフィードバックを連絡します。

こうしたイベントはプラットフォーム上のさまざまなサービスで使用され、以下を行います。

  • カウンタを更新する: 広告の選択プロセスと同様に、予算の上限や残高などのカウンタによって、関連性の低いキャンペーンや広告を除外できます。
  • 入札関連の意思決定を行う: 過去の入札結果データと価格を使用することにより、入札するかどうかの意思決定が向上し、入札価格が最適化されます。
  • レポート用のデータを提供する: 広告配信と同様に、ユーザーは入札と広告の実施方法を知りたいと望んでいます。

オークションへの参加と勝利後のデータ

入札者は、入札リクエストごとに意思決定を行う必要があります。これは、広告のバッチごとに価格が計算される広告配信とは異なります。このため、できるだけ早くデータを結合することで、入札の意思決定を向上できます。

入札リクエストとオークションのイベントを処理するときは、次の点に注意してください。

  • 広告配信では、インプレッション数、クリック数、コンバージョン数の間に数桁の差があります。RTB では、入札リクエストは広告リクエストとは異なり、インプレッションを保証するものではありません(入札者が入札し、勝利する必要がある)。
  • 入札リクエストを獲得してインプレッションが生成されるまでの時間はミリ秒単位です。
  • インプレッションからクリックまでの時間は最大でも数秒です。
  • コンバージョンが生成されるまでの時間は、数分、数日、数週間の可能性もあります。

これらのパターンによって、(インプレッション後のクリックなど)何かが発生するのをシステムが待機しなくてはならない場合があるため、データを結合するときになんらかの問題が発生する可能性があります。クリック後のコンバージョンや、クリックにリンクされていないコンバージョン(ビュースルー コンバージョンと呼ばれる)などのイベントが発生するまで、システムが 1 日や 1 週間待機する必要があることもあります。最後に、入札に勝利しても、レンダリングされた請求可能なインプレッションが発生しないことがあります。

システムを構築するときに、次のことを想定してください。

  • データが Cloud Pub/Sub などのメッセージング システムを介してリアルタイムで取り込まれる。
  • Cloud Dataflow などのデータ処理ツールは、入札リクエスト獲得後のインプレッションやクリックを数ミリ秒または数秒待機して管理できる。
  • システムはすべての入札リクエスト、入札レスポンス、勝利した入札、インプレッション、クリック、コンバージョンを結合できる必要がある。
  • オークション ID はすべてのイベントに共通。
  • 所定の期間が経過した後に発生するクリックやコンバージョンを破棄できる。たとえば、時間が経過しすぎて、クリックまたはコンバージョンが特定のオークションによるものであることを確認できない場合。

データ パイプライン中またはデータが格納された後に、どこで結合を行うかは、データをすぐに結合するかどうかや、結合プロセスで待機できるかどうかによって決まります。データをすぐに結合する場合は、次のようなプロセスを実装します。

  1. Cloud Pub/Sub または Apache Kafka からイベントを読み込みます。
  2. オークション ID を含めて、情報を解析して抽出します。
  3. Cloud Bigtable でキーのルックアップを実行して、オークション ID のイベントがすでに存在しているかどうかを確認します。
  4. 既存のイベントがない場合、Cloud Bigtable にイベントを書き込みます。
  5. 既存のイベントがある場合は、イベントを既存のデータと結合します。
  6. 履歴の分析のために BigQuery にイベントを書き込みます。
  7. シンクが存在する場合は、イベントを高速データストアに直接書き込みます。あるいは、イベントをメッセージング システムに書き込んで、コレクタのグループが高速データストアとの間で読み書きできるようにします。

次の図は、こうした手順を示しています。

イベントと入札リクエストを処理する分散アーキテクチャ

このソリューションを実装するときは、次の点に注意してください。

  • Cloud Dataflow と Cloud Pub/Sub の分散性のために、データの順序が指定されない可能性があります。ただし、できるだけ早く完全な結合を行うことが目標であるため、これは重要ではありません。
  • BigQuery で独自のガベージ コレクションを行うには、delete ステートメントを使用する必要があります(図では簡略化)。これをスケジュールするには、Cloud Composer を利用するか、cron ジョブを使用します。
  • Cloud Bigtable の有効期限機能を使用して、所定の時間が経過した後に発生するクリックやコンバージョンを破棄します。

また、Apache Beam で提供されるタイムリーでステートフルな処理機能を使用して、ワークフローを改善することもできます。イベントの順序を指定できます。Cloud Bigtable では使用できません。

遅延を許容できるため、オフライン結合を使用することを決定する場合、プロセスは次のようになります。

  1. Cloud Pub/Sub または Apache Kafka からイベントを読み込みます。
  2. オークション ID を含めて、情報を解析して抽出します。
  3. 処理されたレコードを BigQuery などのデータ ウェアハウスに追加します。
  4. オークション ID と最新のタイムスタンプを N 間隔ごとに使用してデータを結合します。ここで、N は事前定義された秒数、分数、時間数または日数です。このタスクには、Cloud Composer または cron ジョブを使用できます。
  5. Cloud Composer または cron ジョブを使用して、N 間隔ごとに無効なデータ(オークション ID やイベントタイプごとに最も古いタイムスタンプのデータ)を削除します。

入札者に近いデータをエクスポートする

データの提供に関するインフラストラクチャ オプションについては、大量読み込みの保存パターンをご覧ください。

データのエクスポートのコンセプトは広告配信と同様ですが、入札者は事前定義された期限内に入札レスポンスを返す必要があります。このため、入札者の一部は、操作上のオーバーヘッドが増えるとしても、サブミリ秒の読み書きを処理できるストアを使用することを望みます。入札者は通常、ローカル スレーブまたは地域の Aerospike とともに Redis を使用します。詳細については、リアルタイム集計またはオフライン分析によるデータをエクスポートするインフラストラクチャ オプションをご覧ください。

次のステップ

このページは役立ちましたか?評価をお願いいたします。

フィードバックを送信...