Google Cloud Platform 向けリアルタイム ビッダー ソリューション

リアルタイム ビッダー(RTB)は、ネットワーク広告バイヤー向けのサーバー間統合オプションであり、インプレッション ベースで 1 回のインプレッションに対する評価と入札をネットワークで行えるようにします。これにより、統合された購入および測定と、リアルタイム アルゴリズム最適化を透過的で直接アクセス可能なプラットフォームで行えます。2016 年までに、RTB は 70 億ドル、つまり米国でデジタル表示広告に費やされる額の 28% を占めるようになると予測されています。アド エクスチェンジ、デマンドサイド プラットフォーム、サプライサイド プラットフォームによる技術革新により、RTB 採用の急上昇が促進されましたが、同時に、技術的な複雑さによる障害も発生しました。

リアルタイム入札アプリケーション(ビッダー)は、重要なグローバル分散システムであり、高可用性、スケーラブル、予測可能である必要があります。一般に、ビッダーはエクスチェンジ リクエストに 100 ミリ秒以内にレスポンスする必要があり、この 1 つの制約によって、物理的インフラストラクチャから入札ロジックの実装まで、ビッダーの技術スタックに伴うあらゆる分野の主要な決定に影響が及びます。Ad Exchange は複数のリージョンで RTB を提供し、エクスチェンジ サーバーと物理的により近いビッダーは往復のレイテンシがより少なくなり、より高度な入札ロジックを実行するための時間がさらに提供されます。

ここでは、Google Cloud Platform に複数リージョンのリアルタイム ビッダーをビルドおよびデプロイするための参考として使用できるソリューションのペアを示します。次のプロダクトとサービスが使用されます。

  • Google Compute Engine
    • ビッダーは Google Ad Exchange からの入札リクエストへのレスポンスにレイテンシを生じなくなり、レスポンスのコンピュータ処理に 100 ミリ秒をすべて使用できます。
    • ビッダーは標準の Google Cloud Platform が有効なゾーンで実行します。これは、利益を最大化するためのデータ解析の使用など、他の Google サービスの使用をサポートします。
    • ビッダーは高性能仮想マシンとネットワークを活用して、より少ないインスタンスでより多い入札リクエストを処理できます。
  • Google Open Bidder
    • 拡張を簡略化するための API と、ビッダーとロードバランサを構成および管理するためのユーザー インターフェースを提供する、ビッダー実装用フレームワーク。
  • DoubleClick Ad Exchange ホスト型マッチテーブル
    • インフラストラクチャのフットプリントを削減し、リクエスト パイプラインでの追加呼び出しをなくします。
    • テーブルサイズとマッチング レートの正確なレポート作成と、事前にターゲットを設定したフィルタリングを行えます。
  • Google App Engine
    • 操作上のオーバーヘッドを生じずに、他の Google サービスと完全に接続されているホスト管理、キャンペーン管理、顧客直接対応ウェブ アプリケーション。
  • Google Cloud Storage
    • サーバーログと解析成果物を保存します。
    • Google の低レイテンシ、エッジ キャッシング グローバル ネットワークを活用して広告ペイロードを処理します。
    • ゾーンの移行とディザスタ リカバリ用にディスクのスナップショットとデータベースのバックアップを保存します。
  • Google BigQueryPrediction API
    • レポートとダッシュボードを生成し、入札モデルを調整するために、サーバーログとエクスチェンジ レポートを解析します。

以下の代替コンポーネントがあります。

  • Google Cloud DatastoreGoogle Cloud SQL
    • 入札モデル、キャンペーン、ユーザー追跡データを保存します。
  • サードパーティ データベース
    • 既存の実装および専門知識を保存し、MySQL、PostgreSQL、Cassandra、または他のデータベースを Compute Engine で実行します。

このドキュメントは、RTB とその概念にすでに精通しているシステム アーキテクト、デベロッパー、および技術上の意思決定者を対象にしています。

ソリューションの概要

このセクションでは、複数リージョン RTB ビッダー向けの主要な機能コンポーネントを説明し、Google Cloud Platform でビルドおよびデプロイするための 2 つのソリューションを概説します。これらの 2 つの相違点は、データベースの選択にあり、入札サーバーが特定のデータにアクセスする方法と、リージョン間での同期に使用するメカニズムにあります。第 1 のソリューションでは、現在のクラウドベースの入札では一般的な技法が使用されます。第 2 のソリューションは、一般的には不可能であると考えられるが、Google のインフラストラクチャにビルドする場合は実現可能になる対照的なアーキテクチャ セットの選択肢を提供します。

機能コンポーネント

本ドキュメントで提案するソリューションは、すべてではないものの、大部分のビッダーにとって一般的であり、複数の地理的なリージョンの可用性ゾーンにわたってデプロイするように設計された大まかな機能分野のセットを中心にして作成されています。このセクションでは、Google Cloud Platform プロダクトおよびサービスに関するこれらのコンポーネントとそれらの実装の概要を説明します。

図 1: リアルタイム ビッダーの機能コンポーネント

入札コンポーネント

コアビッダー コンポーネントは、入札とピクセル リクエストを処理し、すべてではないものの、それらのハンドラに可能な限りすばやくデータを保存および提供する操作に影響を与えます。これらのコンポーネントには、ロードバランサ、入札、およびピクセル サーバー(通常は配布済みキー値ストア)、さらに場合によってはデータベース自体が含まれています。

エクスチェンジには厳格な期限があり(通常は 100 ミリ秒程度)、その期間内にシステムはレスポンスする必要があります。DoubleClick Ad Exchange (AdX)は 100 ミリ秒の制限を使用しています。レスポンス期限を超過したビッダーはチャンスが減り、レスポンスのための時間が短くなります。また、AdX はエラーレートの高い(15% を超える)ビッダーへのトラフィックを抑制し、オーバーロードしたチャンスを安定させますが、他のエクスチェンジでは実行できません。このため、エクスチェンジ サーバーへの優れたネットワーク接続性、予測可能な実行特性、スケーラブルなアーキテクチャを維持することが重要です。また、パブリッシャーはピクセル処理や広告ペイロードなど、ユーザー ブラウザ リクエストへのレスポンスを低レイテンシで行える、バイヤーのプラットフォームのほうを好むため、ビッダーは高速で信頼性のあるインターネット接続を確保することも重要です。

ビッダーのコア コンポーネントは、DoubleClick Ad Exchange の入札ロジックのホスティングに優れた環境を提供するサービスである Google Compute Engine にデプロイされます(他のエクスチェンジのビッダーもホスティングできます)。Compute Engine を使用して、ビッダーは複数の可用性ゾーンで仮想マシンを実行できます。これによりビッダーは、仮想マシン間、および他の Google Cloud Platform サービスに対して高帯域幅と低レイテンシ接続性を実現する Google のグローバル ネットワークを活用することができます。

フロントエンド

Compute Engine 仮想マシン上で実行している Google の Compute Engine ロード バランシングまたはソフトウェア ロードバランサ(HAProxyNginx など)は、エクスチェンジとユーザーのブラウザからのすべてのリクエスト トラフィックを処理します。ロード バランシングは、ビッダーの集約効率を最大限に高めることに加え、個々の入札サーバーでのエラー率やリクエスト プレッシャーを最低限に抑えるために特に重要です。

バックエンド

フロントエンド ロードバランサは、プラットフォームのカスタム入札ロジックを実行するバックエンド ビッド サーバーにトラフィックをルーティングします。各エクスチェンジ リクエストは、優先入札モデル、アクティブ キャンペーンのセット、ユーザーに関してビッダーが保持している情報、およびその他のデータポイントに対して評価されます。

ピクセル サーバーは、トラッキング、インプレッション、クリックスルー、コンバージョン リクエストをユーザーのブラウザから直接処理し、追加で不正検出を行うこともあります。本ドキュメントでは、「ピクセル サーバー」という用語を使用し、これらのリクエスト(データストア、キャンペーン予算、ユーザー Cookie、トラッキング情報の更新など)から結果として発生する特定の処理を実際に実行する追加ノードについて説明します。

Google Compute Engine で実行すると、アプリケーション デベロッパーは独自のサーバー テクノロジー スタックや、信用できる既存のソリューションを、変更をほとんど施さないか、まったく行わずに自由に選択できます。しかし、新しいビッダーを開発することは簡単な作業ではありません。サーバー インスタンスを構成および管理する簡単な方法と、カスタム ロジックの開発を促進する定形の必須サーバーコードの大部分を提供するフレームワークを活用するほうが都合がよい場合があります。

Open Bidder は RTB フレームワークの一種であり、スケーラブルなカスタム入札アプリケーションの開発をスピードアップできます。Open Bidder は Compute Engine 上で機能し、次の 3 つの構成要素で構成されています。

  • ユーザー インターフェース(Google App Engine アプリケーションとしてデプロイ) – キャンペーンのインポート、操作メトリックの表示、および Compute Engine ネットワークとファイアウォール、サーバー インスタンス、ロードバランサなど、さまざまなシステムコンポーネントを管理するために使用します。
  • Java 用 API – Open Bidder の機能を、入札、インプレッション、クリックスルー ロジックを実装するカスタム インターセプタで拡張するために使用します。また、依存関係を投入することで、クロスエクスチェンジ入札に対するサポートも提供します。
  • サーバー - 入札、インプレッション、クリックスルー リクエストを受け取り、カスタム インターセプタを実行するために使用します。
分散型ストア

多くのビッダーは、MemcachedRedisVoldemort などの分散型キー値ストアを使用して、入札リクエストごとに調べられるマッチング テーブルや Cookie ストアなどのデータに低レイテンシでアクセスするため、入札エンジンに悪影響が及ばないように、可能な限り高速である必要があります。一部のビッダーは、対応するインプレッションの成功に対して後で調整を行えるように、その入札オファーに関連する情報を記録するために、非永続的ストアを使用します。このテクニックは、たとえば、クロスエクスチェンジ キャンペーンの更新や、入札動作をオンザフライで精査するために使用できます。

マッチング テーブルは、購入者のドメイン内でユーザーを識別する、Cookie に対するエクスチェンジ固有のユーザー ID のマッピングを維持するために使用されます。その後、この Cookie はビッダーによって蓄積されたユーザー情報のキーとして使用されます。これは、ユーザーに関する入札決定を行うときに考慮されます。これは、リマーケティング キャンペーンを作成したり、ターゲット設定を詳細に調整したり、リアルタイムで使用可能になったときにインプレッションに対する入札決定を調整したりするときに有用です。ユーザーデータ自体は分散型キー値ストアで完全に一時的なままであることも、データベース内でより永続的に維持される場合もあります。この決定には、主にデータ損失に対するデベロッパーの許容度が反映されます。プラットフォームの中には単純な設計を好み、失われた情報は再作成するものもありますが、永続性を優先するものもあります。Redis などの製品はマスターノードのメモリのみからリクエストを処理し、スレーブノードで永続的に実行できますが、これは混合手法の場合によく選択されます。

Google Compute Engine は、高性能、スケーラブル、効率的なインフラストラクチャを提供します。これを基盤にして、分散型キー値ストアをデプロイできます。また、Google は DoubleClick Ad Exchange 顧客向けのホステッド マッチング テーブルを提供しており、これを使用して次の利益を得ることができます。

  • キー値ストアがテーブルの照合にしか必要ない場合、サポートすべきインフラストラクチャが減少します。
  • テーブルサイズとマッチング率のレポートを改善できます。
  • 入札リクエストでより便利なフォームに Google User ID をマッピングすることで、ルックアップが不要になります。
  • Cookie の存在に基づいて事前ターゲット設定フィルタリングが可能になります。

データ マネジメント

ビッダー データベースには、トレーニング対象の入札モデル、キャンペーン データ(アクティブおよびヒストリカル)、エクスチェンジ固有のデータセット(カテゴリ、ラベル、エージェンシー、ベンダーなど)から、一時的な入札ストアやイベントログまで、あらゆるものが保存されます。ビッダー アーキテクチャが異なれば、データベースを使用する方法も異なります。ここでは、データアクセスとレプリケーション ストラテジーを中心にした、2 種類の手法について説明します。

各リファレンス アーキテクチャは、データベースと他のコンポーネント間でデータイベントをやり取りし、処理するために追加のプロキシノードを使用します。

解析およびモデル化

解析コンポーネントとモデル化コンポーネントによって、プラットフォーム データスタックのその他のセグメントが構成されています。入札プラットフォームは、システムのパフォーマンスや、入札および不正検出アルゴリズムの効率を高めるために不可欠な洞察を提供できる、大容量のログデータを生成します。また、トレーニングとチューニングをモデル化するために重要な入力値も提供します。

Dremel にビルドされた、ログデータを内部で解析するために Google が使用するものと同じテクノロジーである Google BigQuery を使用して、サーバーログとエクスチェンジ レポートを集約、変換、解析できます。これには、対話式にアクセスすることも、プログラムからアクセスすることもできます。また、より高度なインテリジェンス パイプラインでアクション可能な洞察またはステージとして、その出力を即時に使用できます。

Google Compute Engine は、Hadoop を実行できる優れたプラットフォームです。Google の技術パートナーである MapR は、Google の視覚化インフラストラクチャを使用して、TeraSortMinuteSort ベンチマークの両方で新記録を達成しました。特に Google Cloud Storage と Cloud Datastore に加え、サードパーティ データベース クラスタからデータをソーシングする機能とともにこのステージをデータ パイプラインに追加すると、実行できる解析の幅と深さが増します。

そして最後に、高度な入札プラットフォームは、Google のマシン学習アルゴリズムの機能を高める独自のサービス オファリングである Google の Prediction API を活用して、モデルを作成し、改善できました。

キャンペーン管理

Google App Engine プラットフォームは、キャンペーン管理アプリケーションとその他のクライアント向け機能(レポーティングやダッシュボードなど)をホストします。App Engine によってスケーラビリティが高く、安全な環境が提供されるため、デベロッパーはインフラストラクチャの管理ではなく、ドメイン固有ツールの作成に注目することができます。App Engine は Google Cloud Storage、Cloud SQL、および Datastore と直接連動するため、ビッダーのデータとシームレスに統合できます。タスクキュートソケット API を使用して、Compute Engine にホストされているカスタム データベースへの通信を促進できます。

ストレージ

Google Cloud Storage は、BigQuery、MapReduce、Prediction API からのログファイル、中間結果、最終結果を保存およびステージングするために使用されます。その他のソリューションは、グローバル エッジ キャッシングに加え、静的広告コンテンツを提供するために米国またはヨーロッパのいずれかにローカルでデータをホストする機能を活用します。 Nearline および Coldline Storage は、サードパーティ データベースのバックアップおよび災害復旧に最適です。

マネージド データベース ソリューション

このソリューションは、Google によって完全に管理されている高可用性でスケーラブルなデータベース サービスと、それに付随してオペレーションのオーバーヘッドが減少する状況を活用します。Google Cloud Datastore または Cloud SQL のいずれか、または可能であれば両方を使用できます。データスキーマの特徴と、アプリケーション使用体系によって、どちらを決定するかが明らかになります。Cloud Datastore は NoSQL データ ソリューションであり、Google の Megastore 上に構築され、非常にスケーラビリティが高く、高可用性で、強力で一貫性のある書き込みを行えます。これには、その他の多数の Google Cloud Platform サービス(App Engine や Compute Engine など)からアクセスでき、ホスティングされた MapReduce やその他のデータ パイプライン、およびフルテキストでロケーション ベースの検索用の Search API で使用できます。Cloud SQL は、安全なフルマネージドの高可用性 MySQL サービスであり、地理的なリージョンにわたって、内蔵型自動レプリケーションを使用できます。

リファレンス アーキテクチャ

図 2: Google Cloud プラットフォーム上のリアルタイム ビッダー(マネージド データベース)

実装の詳細

通常、ビッダーでは、初期化中に在庫、予算、および設定などのキャンペーン データを、データベースから入札サーバー自体にロードします。このデータをサーバーの処理スペースから直接アクセスできるようにすると、入札リクエストのたびに重要ではないペイロードを転送するために生じる追加のネットワーク呼び出しやオーバーヘッドをなくすことができます。また、ホスティングをサポートしていないエクスチェンジ用の現在の入札データ、ユーザー情報、およびマッチング テーブルの非永続ストレージには、分散型キー値ストアが使用されます。

また、このソリューションでは、分散型メッセージング システムを活用し、複数のリージョンにわたって関連イベントをブロードキャストして、データストアが同期され、入札サーバーが最新状態に保たれるようにします。コア パックエンド コンポーネントとマネージド データベースの間で追加サーバーを使用してデータのプロキシ処理を行います。これらのサーバーにより、必要に応じて App Engine アプリケーションからメッセージング システムに通信をフローバックすることもできます。たとえば、新しいキャンペーンを作成したり、クライアントの再ターゲット指定リクエストを実行したりすることができます。

図 3: マネージド データベース ソリューションの概略

図の概略
ブートストラッピング

A1. 入札サーバーが、入札エンジンのキャンペーンとトレーニング対象モデルデータをロードします。データ プロキシ サーバーが、マネージド データベースからのクエリと結果の照合を管理します。

エクスチェンジ入札リクエスト

B1. ユーザーのブラウザまたは端末が、Google DoubleClick または別の Ad Exchange から広告の配置をリクエストします。

B2. エクスチェンジはビッダーの事前ターゲット指定(該当する場合は、Cookie のマッチングに基づくフィルタリングを含む)をチェックし、ビッダーにリクエストを送信します。次に、リクエストはいずれかのロードバランサにルーティングされます。リクエストには、ホスティングされているマッチング テーブルから取得された、ドメイン固有のユーザー Cookie が含まれる可能性があります。

B3. ロードバランサは、最後の接続、最後のロード、一致したハッシュ、およびラウンドロビンなどの構成済みストラテジーに基づいて、入札サーバーにリクエストをルーティングします。

B4. 入札サーバーは Cookie を使用して Cookie ストアからユーザーに関する情報を取得します。マッチング テーブルをホスティングしているエクスチェンジからリクエストを受け取らなかった場合、ビッダーのマッチング テーブルを使用して、ユーザーのエクスチェンジ ID からドメイン Cookie が取得されます。ビッドエンジンによって、配置の入札が決定されると、元のリクエスト、決定指標、希望価格など、入札に関連する情報をビッドストアに保存した後、エクスチェンジにレスポンスします。

B5. 広告ペイロードは、Google Cloud Storage から直接処理できます。

ユーザー ブラウザのリクエスト

C1. ユーザー アクションによって、ピクセル、インプレッション、クリックスルー、コンバージョンのトラッキングなどのリクエストがユーザーのブラウザからビッダーに直接トリガーされ、ロードバランサによって処理されます。

C2. 該当するピクセル サーバーがロードバランサからリクエストを受け取ります。

C3. ピクセル サーバーは、広告のインプレッションと相関するビッドストアにあるエントリに対してリクエストをマッチングします。

C4. リクエストを処理した後、ピクセル サーバーはメッセージング システムを使用して、ビッド成功に基づく予算、ユーザー情報、キャンペーン データの更新など、さまざまな更新イベントをブロードキャストします。メッセージ システムへの負荷を軽減し、高頻度の割り込みによって受信側が過負荷になることを防止するため、特定のタイプのイベントがバッチ処理されます。

C5. メッセージング システムは、すべてのリージョンにわたってイベントをリレーします。

C6. 入札サーバーは、入札プロセスに関連する予算の更新と、その他のイベントを受け取ります。これにより、ビッダーは完了したキャンペーンをすばやく廃棄し、リアルタイムのデータ フィードバックに適応できるようになります。

C7. データ プロキシ サーバーは、ユーザー情報更新イベントに加え、キャンペーンや予算データに関連するイベントを受け取ります。

C8. データ プロキシ サーバーは、Cookie ストアを更新します。

C9. データ プロキシ サーバーはデータベースを更新します。オプションの通信フローにアクセスして、視覚化用のリアルタイム更新を提供することもできます。オフライン処理でデータストアを定期的に更新するのが最も一般的な手法です。これにより、I/O と全体的なコストを削減できます。

クライアントのワークフロー

D1. プラットフォームのクライアントはキャンペーンの管理ツールにアクセスし、ダッシュボードを表示して、Google App Engine で実行しているウェブ アプリケーションからレポートを取得します。ビッダーは、これらの機能の一部の REST API を公開することもできます。

D2. 新しいキャンペーン クリエイティブと広告が、直接、またはキャンペーン管理アプリケーションから Google Cloud Storage にアップロードされます。

D3. アプリケーションは、データ処理パイプラインによって生成され、Google Cloud Storage に保存されたデータを使用してレポートを構成します。また、必要に応じて、DoubleClick からのパフォーマンスおよびステータス レポートをを取得し、クライアントがダウンロードできるようにすることもできます。

D4. クライアントが新しいキャンペーンを作成したり、リマーケティングやその他の関連するアクティビティを実行したりするときに、ウェブ アプリケーションは App Engine から直接データベースにアクセスします。

D5. 新しい情報をデータベースに保存した後、これらの変更を実行するタスクはデータ プロキシ サーバーに配信されるように、キューに入れられます。Sockets API を介して App Engine からアウトバウンド ソケットを作成することは可能になりましたが、すべてのリージョンにわたってデータ プロキシ サーバーへのポイント ツー ポイント通信を行えるように設計されたソリューションは脆弱です。このソリューションでは、リージョンごとに App Engine タスクキューを使用してこれらのタスクを保持することを推奨します。

D6. 各リージョンのデータ プロキシ サーバーは個別に(他のリージョンに配置されているサーバーから)データ更新タスクをポーリングします。フォールト トレラント手法では、プロキシノードがそのリージョンのキューをクエリする必要があります。複数回タスクが配信されることはありません。また、サーバーがダウンしても、更新はバックエンドにフローし続けます。

D7. 標準的な例として、ユーザー情報や再ターゲット指定への更新は両方とも、Cookie ストアのデータプロキシによって行われます。

D8. 入札プロセスに関連するキャンペーンの更新やその他のタスクは、メッセージング システムに配信されます。これらのイベントは、リージョンをまたいでリレーされないチャネルに従って送信される必要があります。この設計は、以前の制約を緩め、(ステップ D5 で推奨されているリージョンごとではなく)1 つのタスクキューを使用することで簡単に変更できます。

D9. 入札サーバーは新しいキャンペーンと関連メッセージを受け取り、それらの内部データ構造を更新します。

解析ワークフロー

E1. フロントエンドとバックエンドのサーバーログは、オプションの集約サブシステムを介して Google Cloud Storage に直接プッシュされます。

E2. DoubleClick は、Google Cloud Storage にパフォーマンスおよびステータス レポートを毎時保存します。

E3. Google BigQuery と、Compute Engine で実行されている Hadoop のようなデータ処理ソリューションを使用して、サーバーログが集約、変換、および処理されます。

E4. 一部のプラットフォームでは BigQuery API を使用してダッシュボードとレポートが生成されることもあります。

E5. 入札ロジックを最適化したり、不正リクエストを検出したりするためにマシン学習技術を使用するビッダーは、データ処理パイプラインを活用して、Google Prediction API の入力値を生成できます。その結果は、データベースにフィードバックされます。

サードパーティ データベース ソリューション

このソリューションでは、ホスティングされているサービスではなく、自己管理分散型データベースを使用することで、前の手法に対する代替手法が提供されます。この記事では、分散型キー値ストアとメッセージング サブシステムの使用は控え、データベース システムの機能と、Google インフラストラクチャのパフォーマンスを活用して設計をサポートします。

リファレンス アーキテクチャ

図 4: Google Cloud Platform 上のリアルタイム ビッダー(サードパーティ データベース)アーキテクチャ

実装の詳細

前のソリューションでは、データベースから入札サーバーに事前ロードする方法を紹介しました。多くの場合、これは効率的ですが、設計が制限されてしまいます。たとえば、すべての入札サーバーが同じである必要がある場合、考慮事項(キャンペーン数、在庫量、エクスチェンジで提供されるデータセット、ターゲット設定、個人設定など)を考慮して使用可能なデータ総量は、仮想マシンのメモリ容量によって制約を受けます。さらに、容易ではないクエリ処理は、カスタムコードとデータ構造か、組み込みデータベースのいずれかによってサポートされる必要があります。設計によって、多数の各ノードに及ぶ明示的な同期による負荷も発生します。メッセージングおよび非永続的ストレージ サブシステムが追加されることは、ビッダーの設計、開発、管理の全体な複雑さが高まる要因になります。

たとえば、Apache Cassandra などの Google Cloud Platform で実行している最新分散型データベースは、多数のビッダーのパフォーマンス要件を満たすことができます。特に、このようなデータベースは次を行います。

  • 高メモリのマルチコア仮想マシンを活用して、パフォーマンスとリソース使用率を最適化します。
  • データセンターと、それらの間の非同期レプリケーション全体にわたる構成をサポートします。
  • マスターのないアーキテクチャの提供により、単一障害点と書き込みのブロックを排除します。
  • さまざまな読み取り一貫性オプションをサポートし、必要に応じてビッダーをチューニングできます。
  • クラスタの拡張に伴って、ほぼ直線的にスケーリングします。
  • データの整合性を失わずに、シンプルであるが強固なバックアップ スキームを確保できる不変のオンデスク表記を使用します。
  • Hadoop とのネイティブ統合を提供する場合もあります。

Google Cloud Platform によって、次が提供されます。

  • システム要件と合致する多数の仮想マシン構成
  • データを保護するための透過的停止時暗号化機能を持つ、高性能ローカルおよび永続ディスク
  • 同じリージョン内での同期マルチゾーン書き込みをサポートできる、高帯域幅で低レイテンシのネットワーク
  • リージョン間の非同期書き込みが最適にルーティングされるように支援するグローバル ファイバー ネットワーク

このソリューションは 2 つのマルチリージョン クラスタに対して呼び出しを行うアーキテクチャを示しています。1 つは(前のソリューションで事前ロードされた)ビッドデータ用で、もう 1 つは(前のソリューションでキー値ストアに保持された)ユーザーデータです。この手法では、データベース I/O のパーティショニングをより適切に使用状況と相関させることができます。 本ドキュメントは、さまざまなサードパーティ システムのレイテンシおよびスループットのスケーラビリティという特性に関して、ある程度のバックグラウンドを提供するために役立ちます。

図 5: サードパーティ データベース ソリューションの概略

図の概略

この概略では、マネージド ソリューションとの相違点のみが強調されています。

ブートストラッピング

A1. 入札サーバーは、ビッドエンジン用のトレーニング対象モデルデータのみをロードします。

入札リクエスト

B4. 入札サーバーは、ドメイン Cookie によってインデックス付けされたユーザー情報に対してユーザー データベースをクエリし、すべてのマッチング キャンペーンとインベントリに対して入札データベースをクエリします。

ユーザー ブラウザのリクエスト

C5. 前のソリューションでは、メッセージバスを使用してリージョン間のレプリケーションが促進されていました。このソリューションでは、データベースによってそれ自体の非同期レプリケーションがデータセンター全体に実行されます。

図 3 のステップ C6-9 は、このソリューションに適用できません。

クライアントのワークフロー

D7. 標準的な例として、ユーザー情報や再ターゲット指定への更新は、ユーザー データベース上のデータプロキシによって実行されます。

D8. 入札プロセスに関連するキャンペーンの更新やその他のタスクは、入札データベース上のデータプロキシによって実行されます。図 3 のステップ D4 および D9 は、このソリューションに適用できません。

解析ワークフロー

E6. これをサポートするデータベースの場合、アクティブおよびヒストリカル データを直接処理するように、Hadoop クラスタを統合できます。

バックアップおよびディザスタ リカバリ

F1. データベース サーバーに使用される永続ディスクを、Google Cloud Storage に定期的にスナップショットすることができます。また、データベースの増分バックアップとスナップショットのファイルやログを Nearline または Coldline Storage にアーカイブおよび保存することもできます。

まとめ

リアルタイム ビッダーは複合的な分散型システムであり、非常に特殊なパフォーマンスと可用性に関する要件があります。Google Cloud Platform は、デマンドサイド プラットフォームが堅牢な入札ソリューションをビルドする際に重視する可能性のあるパフォーマンス、一貫性、スケーラビリティ、信頼性を、インフラストラクチャおよびプロダクトレベルで提供します。

参照

  1. Navigating The Road To The Consolidated Buying Platform、Forrester Consulting、2013 年 1 月
  2. Real-Time Bidding to Take Ever-Bigger Slice of Display Pie、eMarketer.com、2012 年 11 月 15 日

付録 I - ベスト プラクティス

すべての Google DoubleClick Ad Exchange ビッダーは他のエクスチェンジも同様にうまく適用できる可能性はありますが、以下のベスト プラクティスを考慮する必要があります。詳細および推奨事項については、DoubleClick Ad Exchange RTB のベスト プラクティス ガイドをご覧ください。

エクスチェンジ API の活用

  • 正確な QPS 割り当てを設定して、ビッダーに過負荷が生じたり、過度なエラーに対して速度低下することを防止します(入札リクエストにタイムリーにレスポンスしないとエラーになります)。予期できない急激な増加やビッダーノードの障害を考慮して、ビッダーの容量制限をわずかに下回る QPS 最大値を設定します。
  • 可能な場合は前もってクリエイティブをアップロードし、承認を迅速に処理します。
  • エクスチェンジによって提供されるパフォーマンス データをモニタリングして、解析します。現在および履歴のパフォーマンス データは、パフォーマンス REST API または AdX UI を介してプログラムで入手できます。また、Google Cloud Storage で 1 時間単位で取得できるレポートをダウンロードして解析することもできます。パフォーマンス データには、取引のロケーションごとにグループ化されたさまざまな QPS とレイテンシ メトリクスが含まれ、タイムアウトやエラーのあるレスポンスをログと相関させるために役立ちます。同様に、Google のサーバーがビッダーのラウンド トリップ レイテンシをどのように認識するかを確認するのも重要です。DoubleClick Ad Exchange がどのようにビッダーを測定するかを理解することは、パフォーマンス問題をデバッグし、システム全体の品質を改善するために重要な作業です。また、クリエイティブ REST API とスニペット ステータス レポートを使用して、クリエイティブが承認されたかを判別し、デバッグで問題を解決するのに役立てることができます。オフライン レポートの詳細については、レポートガイドを参照してください。
  • 可能な場合は事前にターゲット設定し、トラフィックや処理による負荷を削減して、アクション可能なコールアウトを最大化します。
  • ホスティングされたマッチング テーブルを使用して、さらに上のレベルのフィルタリングを提供し、不要な入札リクエストを削減して、リクエスト処理で余分なオーバーヘッドが発生しないようにします。

ネットワーク構成

  • DNS - シンプルさを保ち、トリック、非常に短い TTL 設定、または地理やレイテンシに基づく切り替えを使用した「スマート」DNS サービスを使用しないようにします。エクスチェンジ側の DNS キャッシングとポーリングは、膨大な量、スタベーション、およびアンバランスで予測不可能なトラフィック パターンとしてマニフェストする副作用を伴い、これらのオプションと競合する可能性があります。標準の DNS サービスと静的 IP アドレスを使用してください。
  • ロードバランサと入札サーバーでキープアライブと長期有効接続を有効に設定し、不要なオーバーヘッドを回避して、新しい接続の確立に関連するネットワークのラウンドトリップを削減します。アイドル タイムアウトは 2 分間に設定することをお勧めします。「入札なし」のレスポンスを返すときなど、ビッダーが不必要に接続を閉じていないかを確認します。
  • ソース IP をハッシュしないようにします。これは、ビッダーのフロントエンドが少数の IP アドレスからトラフィックを受け取るためです。このため、Cookie や URL パラメータなど、変動性の高い入力値を使用してください。

サーバー構成

  • サーバーをチューニングします。接続あたりのリクエスト数を最大まで増やし、RAN で許容可能な最大値まで接続数の上限を高めます。たとえば、Apache prefork MPM の場合、OS や他の常駐プロセスを考慮した後、RAM に適合できる大まかなプロセス数に MaxClients を設定する必要があります。ビッダーマシンでのメモリからディスクへのスワッピングはオフのままにしておきます。これにより、ビッダー処理がタイムアウトになる可能性があるからです。必ず負荷テストを実行して、プロセスでメモリ不足になり始めたときや、サーバーがキュー リクエストを開始し始めたときのクエリ プレッシャーを確認します。
  • ロードバランサやウェブサーバーの設定の意味を理解します。一般的なウェブサイトやアプリケーションのデフォルト値はほぼ間違いなく RTB サーバーには適していないため、それらを適切に設定します。たとえば、大部分のウェブサーバーは比較的低い(または集中的な)レートで多数のクライアントからリクエストを処理する必要がありますが、RTB ビッダーのフロントエンドは非常に少数のクライアントからの持続する高いレートのリクエスト トラフィックを処理する必要があります。
  • 小さな入札レスポンスを送信します。8KB を超えるとエラーと見なされ、ドロップされます(QPS 割り当てが削減される可能性があります)。
  • GZIP 圧縮を有効に設定して、API に送信されるペイロード量を削減します。
  • 過負荷を適切に処理します。プレッシャーとレイテンシが高まり、サーバーの能力を超えて時間内にレスポンスできなくなった場合、エラーまたは入札なしのレスポンスを返すようにします。最初の方法で、Google はトラフィックをビッダーに応じてスロットル調整できます。これにより、負荷が期待されるレベルまで下がると、即時にリカバリできるようになります。2 つめの方法でも最初の方法と同じ結果が得られますが(処理される入札リクエストの数を削減する)、負荷はビッダーが負担する必要があるという点が異なります。
  • Google が送信する ping リクエストにレスポンスし、ビッダーのステータス、接続を閉じる動作、レイテンシなどを測定します。ping リクエストにレスポンスした後に、接続を閉じないでください。

システム設計

  • リージョン間通信は無料ではないため、このトラフィックを形成するときは慎重に検討して処理します。 メッセージバスやデータベースなど、システムでチャット機能がどのように異なるかを理解し、コスト効率の良いモデルを作成します。
  • 可能な場合は、単一のブロードキャストまたは API 呼び出しにイベントやメッセージをバッチ処理します。 たとえば、キャンペーン予算を、インプレッション イベントごとではなく、1 分ごとに更新することができます。同様に、メッセージ ペイロードの圧縮によってレスポンス時間に影響が及ぼされない状況を特定し、それを使用して処理を迅速に行い、コストを削減します。最後に、通信および呼び出しの失敗に注意を払います(すべてのメッセージが配信され、すべての呼び出しが成功することを前提にしないでください)。ランダムな指数バックオフの再試行動作を使用することで、受信側に大量のトラフィックが流れたり、送信側が過負荷にならないようにします。
このページは役立ちましたか?評価をお願いいたします。

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