広告ワークロードを処理するためのインフラストラクチャ オプション(パート 1)

この記事では、広告サーバーや入札者など、さまざまな広告技術プラットフォームで共有されるコンポーネントについて説明します。また、この記事では、こうしたコンポーネントを実装するためのオプションについても説明します。

広告サーバーと入札者が、技術が重複している補完的なプラットフォームとなることもあります。コンテンツの重複を避けるために、この記事とパート 2 では、このシリーズに必要なコンテキストを示します。

シリーズ全体の概要と用語については、広告プラットフォームの構築(概要)をご覧ください。

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

購入者サイドまたは販売サイドのプラットフォームを操作する場合は、次の点を考慮してください。

  • コンピューティング プラットフォーム: プログラマティック広告プラットフォームは、各サービスが 1 つ以上の機能を提供する複数のサービスから構成されます。これらの関数の一部またはすべてをコンテナ化できるかどうか、またはサービスを仮想マシン(VM)インスタンスで直接実行する必要があるかどうかを早期に決定してください。
  • 地理的な位置: インフラストラクチャを顧客やプロバイダの近くにデプロイすると、ネットワークのレイテンシが短縮されます。
  • 再現性: 世界中のさまざまな地域のシステムを複製する場合、同じインフラストラクチャを一貫してデプロイできるため、プラットフォーム全体で整合性が確保されます。
  • 負荷分散: 単一のマシンでは、広告技術の負荷を処理できません。内部リクエストと外部リクエストの両方を複数のサーバーに分散します。
  • 自動スケーリング: 広告リクエストの負荷は、1 日の中で変動します。システムの規模を自動的に増減することで、コストを削減し、可用性を向上できます。
  • ネットワーク通信: 分散型システムには、通信に関する問題があります。たとえば、オレゴン州で入札しているものの、キャンペーン管理データベースがヨーロッパにあるとします。通信がオフライン同期で構成されている場合でも、公共のインターネットを介して通信することは望ましくありません。

プラットフォームを計算する

GCP には、計算の負荷に対応するためのいくつかのオプションがあります。次のオプションを検討してください。

  • App Engine ウェブ ユーザー インターフェース(UI)を実行すると、運用上のオーバーヘッドのほとんどがなくなる。
  • Compute Engine App Engine でサポートされていないリレーショナル データベースやカスタムコードをインストールして管理する。
  • Google Kubernetes Engine(GKE) ステートレス フロントエンドを設定したり、コンテナ化されたアプリケーションを実行したりする。

こうしたオプションは推奨事項であり、大抵の場合、互換性があります。コスト、運用上のオーバーヘッド、パフォーマンスのいずれであっても、お客様の要件が最終的な決定要因になります。

Compute Engine と GKE の両方で、コストを節約するためにアドテックのワークロードでよく使用されるプリエンプティブ VM がサポートされています。ただし、プリエンプティブ VM はわずか 1 分の警告でプリエンプトされる可能性があります。したがって、次のことが推奨されています。

  • Compute Engine を使用する場合、2 種類のマネージド インスタンス グループ(プリエンプティブ VM があるグループと標準 VM があるグループ)を同じロードバランサの背後に存在させることが可能です。1 つのグループが標準 VM で構成されていることを確認して、フロントエンドが常に受信リクエストを処理できるようにします。次の図は、このアプローチを示しています。

    同じロードバランサ内の 2 種類のマネージド インスタンス グループ

  • GKE を使用している場合は、GKE クラスタにプリエンプティブ以外のノードプールとプリエンプティブ ノードプールの両方を作成することで、可用性を実現しながらコストを軽減できます。

地理的なロケーション

広告主が世界中のあらゆる地域の顧客をターゲットにしたいと望むことがあります。プラットフォームの UI フロントエンドのいずれかに数ミリ秒が追加されても、たとえば、パフォーマンス データを可視化する場合に、広告主のエクスペリエンスが低下することはありません。ただし、ネットワーク距離の追加によって入札レスポンスに数ミリ秒が追加される場合には注意が必要です。この数ミリ秒が、広告主の入札が承認されるかどうか、広告が顧客に配信されるかどうかに影響する可能性があります。

GCP は、us-east、us-west、europe-west、asia-southeast、asia-east を含めて、いくつかのリージョンに存在しています。各リージョンには、高可用性とスケーリングの両方を提供する複数のゾーンが含まれています。

レイテンシが重要な場合は、異なるリージョンのゾーン間でサービスの一部を提供できます。必要に応じて、設定をカスタマイズできます。たとえば、一部のフロントエンド サーバーを us-east4 と us-west1 に配置し、データは us-central のデータベースに格納できます。場合によっては、一部のデータベース データをローカルでフロントエンド サーバーに複製できます。あるいは、複数リージョンの Cloud Spanner インスタンスを検討してください。

再現性

再現性によって保守とデプロイがシンプルになります。関連するすべての地理的なロケーションでプラットフォームを動作させることは、重要な期限より前に入札を行うための鍵を握ります。再現性を確保するために、すべてのリージョンで同様の作業を行う必要があります。主な違いは、リージョンの需要を満たすために必要なワークロード、マシンとゾーンの数です。

Compute Engine では、インスタンス テンプレートが、同様のリージョンのマネージド インスタンス グループを設定するための基盤となります。こうしたグループは、高可用性を実現するために、SSP に近接する複数のリージョンに配置し、複数のゾーンにまたがることが可能です。次の図は、このプロセスを示しています。

インスタンス テンプレートを使用してリージョン マネージド インスタンス グループを設定する

コンテナによって、マシンの仮想化よりも高レベルの抽象化が実現します。Kubernetes は、複数のクラスタ間で整合性のあるポッドサービスデプロイメントを定義できる YAML 構成ファイルによって、アプリケーションの再現性をネイティブに実現します。

負荷分散

次の 2 つの主なシナリオでは負荷分散が必須です。

  • 広告リクエストや入札リクエストなどの外部トラフィックの場合は、HTTP(S) 機能とネットワーク負荷分散機能を提供する Cloud Load Balancing を使用できます。事前警告とグローバルな負荷分散と単一のエニーキャスト IP を使用しないため、システムが世界のあらゆる場所から毎秒何百万ものリクエストを受信する可能性があります。
  • サービス間の内部トラフィックの場合、GCP は内部負荷分散を行います。

インフラストラクチャの一部で Kubernetes を使用する場合は、GKE を使用することをおすすめします。Kubernetes の機能の一部は、プロバイダでそれらがネイティブにサポートされていない場合、なんらかの追加の実装を必要とする場合があります。GKE を使用すると、Kubernetes でネイティブ GCP 機能を使用できます。

また、GKE ではネットワーキング時間と余分なネットワーキング ホップの可能性を最小限に抑えるために、コンテナ ネイティブの負荷分散がサポートされています。大まかには、ロードバランサは、リクエストされたサービスのポッドをホストしていないインスタンスにリクエストがルーティングされることを防ぎます。

スケーリング

プラットフォームでは 1 日に何十億もの広告リクエストを解析して計算する必要があるため、負荷分散は必須です。そのうえ、単一マシンではその作業に対応できません。ただし、リクエストの数は 1 日の間に変化する傾向があるため、需要に基づいてインフラストラクチャのスケールアップとダウンを行える必要があります。

Compute Engine を使用する場合、インスタンス テンプレートから自動スケーリングされるマネージド インスタンス グループを作成できます。こうしたグループは、HTTP 負荷、CPU などのさまざまな指標や、アプリケーションのレイテンシなどの Stackdriver のカスタム指標でスケーリングできます。また、これらの指標を組み合わせて、こうしたグループをスケーリングすることもできます。

自動スケーリングの決定は過去 10 分間の指標の平均に基づき、スライディング ウィンドウを使用して毎分行われます。すべてのインスタンス グループに独自のスケーリング ルールのセットを指定できます。

GKE を使用する場合、Kubernetes のクラスタ オートスケーラーは GKE のクラスタ オートスケーラーを使用してネイティブに実装できます。GKE のクラスタ オートスケーラーの動作は Compute Engine のオートスケーラーとは異なり、基盤となるノードでの CPU やメモリの不足により既存のノードで新しいポッドをスケジュールできなくなったときに、新しいノードを起動します。CPU またはメモリが再び解放されると、スケーリングが自動的に機能します。

ネットワーク通信

Virtual Private Cloud(VPC)は、複数のリージョンにまたがることができます。言い換えれば、us-east のデータベース リード レプリカと asia-southeast のマスター データベースが同じ VPC 内にある場合、Google ネットワークを離れずにプライベート IP またはホスト名を使用して安全に通信できます。

次の図では、すべてのインスタンスが同じ VPC 内にあり、異なるリージョンにある場合でも、VPN を必要とせずに直接通信できます。

すべてのインスタンスが同じ VPC、異なるリージョンにある

GKE クラスタは、作成時に VPC に割り当てられ、既存のネットワーク機能の多くを使用できます。

Google では、次の 2 種類のネットワーク インフラストラクチャも提供しています。

  • プレミアム: Google のグローバル プライベート ネットワークを使用します。クロスリージョン データベース レプリケーションなどの重要なワークロードの場合は、このオプションを優先します。
  • スタンダード: 価格に敏感で、公共のインターネットを使用できる場合は、このオプションを優先します。

Cloud Bigtable、Cloud Storage、BigQuery などのマネージド サービスを使用する場合、GCP は VPC を介してこうしたサービスへのプライベート アクセスを提供します。

ユーザー フロントエンド

ユーザー フロントエンドは重要ですが、ワークロードが非常に少ないため、技術的なオーバーヘッドはほとんど必要ありません。ユーザー フロントエンドでは、プラットフォームのユーザーに、キャンペーン、クリエイティブ、請求、入札などの広告リソースを管理する機能が提供されます。また、フロントエンドでは、たとえば、キャンペーンや広告の掲載結果をモニタリングするためのレポートツールを操作する機能も提供されます。

これらの両方の機能に、プラットフォームのユーザーに UI を提供するためのウェブサービスと、トランザクション データや分析データを格納するためのデータストアが必要です。

ウェブサービス

広告フロントエンドでは、以下のことが必要とされます。

  • 高可用性を提供する。
  • 毎秒何百ものリクエストを処理する。
  • 優れたユーザー エクスペリエンスを提供するために、許容範囲のレイテンシでグローバルに利用できるようにする。
  • UI を提供する。

インターフェースには、広告主、キャンペーン、関連するコンポーネントを設定するためのダッシュボードやページなどの機能が含まれています。UI デザイン自体は独立した規範であり、この記事の範囲外です。

技術的なオーバーヘッドを最小限に抑えるため、App Engine をフロントエンド プラットフォームとして使用することをおすすめします。これを選択すると、ウェブサイト インフラストラクチャの管理に費やす時間を最小限に抑えるために役立ちます。カスタム ランタイムが必要な場合は、カスタム ランタイムを検討してください。また、優先されるアプリケーション スタックに他の要件がある場合、GKE または Compute Engine を使用できます。

データストア

ユーザー フロントエンドには 2 種類のデータストアがあります。

  • オンライン トランザクション処理(OLTP)データベースを必要とする管理データストア。オプションの詳細については、メタデータ管理ストア セクションをご覧ください。
  • オンライン分析処理(OLAP)データベースを必要とするレポート データストア。オプションの詳細については、レポート / ダッシュボード ストア セクションをご覧ください。

リクエストの処理

フロントエンド

リクエストは、プラットフォームで提供される HTTP(S) エンドポイントに送信され、処理されます。主要コンポーネントは次のとおりです。

  • 数十万の QPS を処理できるロードバランサ
  • さまざまな KPI に基づいて、迅速なスケールアップとダウンが可能なインスタンスのプール。
  • エンドポイントに対して調整や認証を行うことが可能な API。

Compute Engine と GKE のいずれも、コンピューティング プラットフォームに適した選択肢です。

  • Compute Engine では、Cloud Load Balancing と、スケーリング セクションで説明しているマネージド インスタンス グループを使用します。
  • GKE では、Cloud Load Balancing と Ingress(または Istio Ingress Gateway)、水平ポッド オートスケーラー、クラスタ オートスケーラーを使用します。

ポッド スケーリングはノード スケーリングより高速なため、GKE はサービスレベルごとに迅速な自動スケーリングを提供します。また、GKE では、関連するサービスのポッドをホストするインスタンスに直接ルーティングするリクエストを最適化するために、コンテナ ネイティブの負荷分散もサポートされています。

調整や認証は、ApigeeService Infrastructure などのテクノロジーで管理できます。

解析

広告リクエストは一般的に、IP アドレス、ユーザー エージェント、サイトカテゴリなどの情報とともに JSON 形式や protobuf 形式でフォーマットされます。(固有の)ユーザーの詳細が含まれているこのデータを抽出し、広告を選択してフィルタリングするためのセグメントを取得することが重要です。

静的フィルタリング

一般的に購入者サイドで受信される一部のリクエストは、静的ルールを使用して破棄できます。このような早期フィルタリングでは、データ量やダウンストリームで必要とされる複雑な処理を軽減できます。

ルールはサイト運営者のブラックリストまたはコンテンツ タイプの除外です。初期化中に、ワーカーは Cloud Storage 上でホストされているファイルからこれらのルールを取得して読み込むことが可能です。

広告の選択

広告の選択は、サイト運営者の広告サーバー、広告主の広告サーバー、DSP を含めてさまざまなサービスやプラットフォームで行えます。広告を選択する際には、さまざまなレベルの複雑さが発生します。

  • サイト運営者のウェブサイトやページにおいて特定のカテゴリの広告を選択する場合のように、簡単に行える選択もあります。この場合、価格は広告ごとに異なるわけではありません。
  • 高度な選択には、ユーザー属性とセグメントが組み込まれており、潜在的に機械学習ベースの広告レコメンデーション システムが含まれています。
  • RTB システムは通常、最も複雑な決定を行います。広告は、(一意の)ユーザー セグメントや以前の入札価格などの属性に基づいて選択されます。この選択には、(リクエストごとに)入札価格を最適化するための入札計算も含まれています。

関連する広告を選択することは、システムの中心的な機能です。高度なルールベースのアルゴリズムや ML 選択アルゴリズムを含めて、考慮すべき要素が多数あります。ただし、この記事では引き続き、高レベルのプロセスと、さまざまなデータストアの操作に焦点を当てます。

広告の選択プロセスは、次の手順で構成されます。

  1. ターゲット ユーザーに関連付けられたセグメントを(一意の)ユーザー プロフィール ストアから取得します。
  2. ユーザーのセグメントに最適なキャンペーンまたは広告を選択します。この選択では、メタデータ管理ストアからメタデータを読み取る必要があります。そのため、このストアでは大量読み込みの保存パターンのいずれかを実装する必要があります。
  3. 選択したキャンペーンや広告を、コンテキスト ストアのいずれかに保存されている残りの予算などの指標に合わせてフィルタリングします。
  4. 広告を選択します。

入札者には入札とオークションに関連するその他の手順と、レイテンシに関する厳しい要件が課せられます。広告の選択時における入札者の要件の詳細については、RTB 入札者のインフラストラクチャ オプション(パート 4)をご覧ください。

大量読み込みの保存パターン

広告を選択する際に行う決定の大部分には、次のようなインテリジェントなデータが必要です。

  • ミリ秒単位、場合によってはサブミリ秒単位で読み込まれる。
  • 特に時間的制約のあるカウンタの場合、できるだけ早く書き込まれる。
  • バックグラウンドでの分析タスクや機械学習タスクを使用するオフライン プロセスの一部として書き込まれることもある。

データストアの選択方法は、次の要件の優先順位付けの方法によって異なります。

  • 読み取りまたは書き込みのレイテンシの最小化: レイテンシが重要な場合は、サーバーに近い、大量の読み書きを高速に処理できるストアが必要です。
  • 運用上のオーバーヘッドの最小化: エンジニアリング チームが小規模な場合は、フルマネージド データベースが必要になる場合があります。
  • スケーリング: 1 日あたり数百万人のターゲット ユーザーや数十億のイベントをサポートするには、データストアの水平スケーリングを行う必要があります。
  • クエリスタイルの適応: 一部のクエリでは特定のキーを使用できますが、その他のクエリでは異なる条件セットを満たすレコードを取得する必要があります。場合によっては、データのクエリをキーにエンコードできます。それ以外の場合、クエリに SQL のような機能が必要です。
  • データの更新頻度の最大化: カウンタの一部(予算など)は、できるだけ迅速に更新する必要があります。オーディエンス セグメントやカウンタ(たとえば、1 日の上限)などの他のデータは、後で更新できます。
  • コストの最小化: DevOps を最小限に抑えるために、1 日に数十億回の読み書きを、グローバルに強整合性を維持しながら単一のデータベースで処理することは、必ずしも経済的、実用的であるとは限りません。

大量読み込みの要件に対応するためのさまざまなオプションがあります。つまり、リードレプリカ、キャッシュ システム、メモリ内 NoSQL データベース、マネージド ワイドカラム型 NoSQL データベースなどです。

RDBMS リードレプリカ

Cloud SQL(または Compute Engine にインストールされて管理される同等の RDBMS)を使用する場合は、マスター インスタンスから読み込みをオフロードできます。多くのデータベースで、この機能がネイティブにサポートされます。ワーカーは以下の方法によって必要な情報のクエリを実行できます。

  • ワーカーの数と一致するリードレプリカを使用する。
  • プーリング プロキシを使用する。

次の図は、このプロセスを示しています。

読み取りがマスター インスタンスからオフロードされるデータベース

リードレプリカは大量読み込みトラフィックを処理するように設計されていますが、スケーラビリティは線形ではなく、多数のレプリカによってパフォーマンスが低下する可能性があります。グローバルな整合性と最小限の運用オーバーヘッドを実現しながら、スケーリング可能な読み書きが必要な場合は、Cloud Spanner の使用を検討してください。

ローカル キャッシュ レイヤ

Compute Engine の Redis などのキャッシュ レイヤを、ワーカーのオプションのローカル レプリカとともに使用できます。このレイヤでは、読み取りとネットワーキングの両方で可能な限りレイテンシを最小限に抑えることが可能です。次の図は、このレイヤを示しています。

キャッシュ レイヤを利用してレイテンシを最小化する

この場合に Kubernetes を使用するには、以下を行って DaemonSet とそのアフィニティを確認してください。

  • レプリケートされたデータの量を制限する。
  • データをサービング ポッドの近くで維持する。

メモリ内 Key-Value NoSQL

Aerospike や Redis などのメモリ内データベースをデプロイすると、大規模な高速読み取りが実現します。このソリューションは、リージョンのデータやカウンタに役立ちます。格納されているデータ構造のサイズが心配な場合は、SSD ディスクへの書き込みが可能なメモリ内データベースを活用することもできます。次の図は、このソリューションを示しています。

SSD ディスクに書き込み可能なメモリ内データベース

マネージド ワイドカラム型 NoSQL

ワイドカラム型データストアは、高速での読み書きを可能にする Key-Value ストアです。Cassandra や HBase などの一般的なオープンソース データベースをインストールできます。

このようなストアを使用する場合は、Cloud Bigtable を使用して運用上のオーバーヘッドを最小限に抑えることをおすすめします。こうしたストアを使用すると、ノードの数に比例して入出力オペレーション数(IOP)を増減できます。適切なキー設計では、広告セレクタで読み取りが可能で、データ パイプラインで 1 桁のミリ秒の速度で 1 ペタバイトのデータの最初のバイトに書き込むことが可能です。次の図は、このプロセスを示しています。

ワイドカラム型データストア

静的オブジェクト ストレージ

protobuf、AVRO、JSON 形式で保存できる静的データの場合、ワーカーで初期化中に Cloud Storage から読み込み、コンテンツを RAM に保存できます。次の図は、このプロセスを示しています。

Cloud Storage からデータを読み込む

画一的なアプローチは存在しません。優先順位に基づいてソリューションを選択し、レイテンシ、コスト、オペレーション、読み書きのパフォーマンス、データサイズを調整します。

解決方法 レイテンシ コスト 運用上のオーバーヘッド 読み書きのパフォーマンス データサイズ
RDBMS リードレプリカ ミリ秒 サービスベースまたはコンピューティング ベース 制限付き 制限付き
Cloud Spanner ミリ秒 サービスベース ノード数による均等スケール ペタバイト
メモリ内ストア サブミリ秒 コンピューティング ベース ノード数に応じて可変 ノード数に応じて可変
Cloud Bigtable 1 桁のミリ秒 サービスベース ノード数による均等スケール ペタバイト

広告データストア

このセクションでは、次の 3 つのシナリオのいずれかに対応するデータ ストレージ オプションについて説明します。

  • 広告配信ストアは、広告の選択に関連するサービスで使用されます。ワークロードに対処するには、低レイテンシ、1 日に数十億回の読み取りを処理する能力が必要です。データサイズはデータの種類によって異なります。
  • 分析ストアは、アドホック クエリまたはバッチデータ パイプラインを介してオフラインで使用されます。1 日あたり数百テラバイトのデータを保存できます。
  • レポート / ダッシュボード ストアは、あらかじめ用意されているダッシュボード、時系列、カスタム レポートに使用できます。これらのオプションはフロントエンドを差別化し、プラットフォーム ユーザーがビジネス パフォーマンスの現状を適時に把握して可視化できます。

広告配信ストアは、次のようにさらに細分化できます。

  • メタデータ管理ストアは、関連するキャンペーンと広告を選択するときに使用されます。ユーザー フロントエンドでは、データを作成して更新します。このデータには永続性が必要です。
  • (一意の)ユーザー プロフィール ストアは、(一意の)ユーザーをプロファイリングしてユーザーと広告を照合するときに使用されます。データは主にイベントを使用して更新されます(パート 2)。このデータには永続性が必要です。
  • 配信コンテキスト ストアは、予算やフリークエンシー キャップなどの複数のカウンタに基づいて広告とキャンペーンをフィルタリングするために使用されます。データはイベントを使用して更新されます。このデータは頻繁に上書きされます。

メタデータ管理ストア

メタデータ管理ストアには、広告の選択時にルールを適用する参照データが含まれています。ここに格納されているリソースの中には、プラットフォームに固有のものもあれば、以下と重複するものもあります。

  • 販売サイドの広告サーバーの場合、サイト運営者がキャンペーン、クリエイティブ、広告主、広告スロット、価格に関するデータを管理します。フロントエンドの一部は、購入者にアクセス権を付与します。
  • 購入者サイドの広告サーバーの場合、購入者がキャンペーン、クリエイティブ、広告主、価格に関するデータを管理します。広告主は UI を使用してこのデータ自体を更新できます。
  • DSP の場合、購入者がキャンペーン、クリエイティブ、広告主、入札価格に関するデータを管理します。広告主 は UI を使用してデータを更新できます。

メタデータ ストアには、リレーショナル データまたは階層型の半静的データが含まれています。

  • 書き込みは、プラットフォーム ユーザーがフロントエンドで編集を行った結果であり、めったに発生しません。
  • データは、広告の選択サーバーによって 1 日につき何十億回も読み取られます。

キャンペーン メタデータ データベースでは、ユーザーのフロントエンドに焦点を当て、リソースの関係と階層を管理し、メガバイト単位から数ギガバイトのデータに格納できるようにする必要があります。また、データベースでは数百の QPS の範囲内で読み取りと書き込みを行う必要もあります。こうした要件に対応するために、GCP ではマネージドと非マネージドの両方で複数のデータベース オプションを用意しています。

  • Cloud SQL: MySQL または PostgreSQL を実行できるフルマネージド データベース サービス。
  • Cloud Datastore: 高度にスケーラブルなマネージド分散型 NoSQL データベース サービス。ACID トランザクションをサポートし、SQL に似たクエリ言語を提供し、強力な結果整合性レベルがあります。
  • Cloud Spanner: 強力で整合性のある読み取り、グローバル トランザクション、クロスリージョン レプリケーションを提供する、水平スケーリング可能なリレーショナル データベース。大量データの読み書きを処理できます。
  • カスタム: Compute Engine または GKE で、オープンソースまたは専用のデータベース(MySQL、PostgreSQL、MongoDB、Couchbase など)の多くをインストールして管理することもできます。

要件によってオプションを絞り込めますが、大まかには、リレーショナル データのサポートのために Cloud SQL を使用できます。Cloud SQL も管理され、リードレプリカ オプションが提供されます。

前述のとおり、メタデータ ストアは、レポートや管理のためにプラットフォーム ユーザーが使用するだけではなく、広告を選択するサーバーでも使用されます。こうした読み取りは 1 日に何十億回も発生します。大量読み込みの要件に対応するには、主に次の 2 つの方法があります。

  • 整合性のある書き込みをグローバルに処理できるデータベースを使用して、Cloud Spanner と同様に 1 日に数十億回の読み取りを行います。
  • 読み取りと書き込みを切り離します。このアプローチは、メタデータが頻繁に変更されないために利用できます。このアプローチの詳細については、エクスポート(パート 2)をご覧ください。

(一意の)ユーザー プロフィール ストア

このストアには、(一意の)ユーザーと、必要に応じてキャンペーンや広告を選択するための重要な情報を提供する関連情報が含まれています。情報には、(一意の)ユーザーの属性、独自のセグメント、サードパーティからインポートされたセグメントが含まれている可能性があります。RTB では、インポートされたセグメントに入札価格の推奨が含まれることがあります。

このデータストアには、数百ギガバイトや数テラバイトのデータを格納できる必要があります。また、データストアでは、最大でも 1 桁のミリ秒の速度で単一のレコードを取得できる必要もあります。保存するデータの量は、(固有の)ユーザー情報の詳細度によって異なります。少なくとも、ターゲット ユーザーのセグメントのリストを取得できる必要があります。

ストアは、(一意の)ユーザーによる広告の操作、アクセスしたサイト、行ったアクションに基づいて頻繁に更新されます。情報が豊富なほど、ターゲット設定が向上します。また、サードパーティのデータ管理プラットフォーム(DMP)を使用して、自社データを充実させることもできます。

Cloud Bigtable や Cloud Datastore は、(一意の)ユーザーデータに使用する一般的なデータベースです。両方のデータベースが、単一のレコードのランダムな読み書きに適しています。少なくとも数百ギガバイトのデータがある場合にのみ、Cloud Bigtable の使用を検討してください。

MongoDB、Couchbase、Cassandra、Aerospike などの他の一般的なデータベースも、Compute Engine や GKE にインストールできます。これらのデータベースではより多くの管理作業が必要となることがありますが、その一部では柔軟性や低レイテンシが実現し、場合によってはクロス リージョン レプリケーションが実現します。

詳細については、ユーザー マッチング(パート 4)をご覧ください。

コンテキスト ストア

コンテキスト ストアはカウンタ(フリークエンシー キャップや予算の残高など)を保存するために使用されることがあります。コンテキスト ストアでデータが更新される頻度はさまざまです。たとえば、1 日の上限は毎日伝播できますが、キャンペーンの残りの予算はできるだけ早く再計算して伝播する必要があります。

選択したストレージ パターン、更新するカウンタ、選択したデータベースの機能に応じて、データベースに直接書き込むことが可能です。または、Cloud Pub/Sub などのメッセージング システムで publish-subscribe パターンを使用して実装を切り離し、計算後にストアを更新することもできます。

以下はコンテキスト ストアの良い例です。

  • Cloud Bigtable
  • リージョン メモリ内 Key-Value NoSQL パターン
  • リージョン キャッシュ パターン

こうしたストアでは、水平スケーリングを使用することで、大規模な読み書きを処理できます。 広告サーバーのインフラストラクチャ オプション(パート 3)RTB 入札者のインフラストラクチャ オプション(パート 4)では、これらのオプションの一部について詳しく説明しています。

分散環境での予算カウンタの管理方法の例

キャンペーン管理ツールで予算を設定します。ほとんどの場合、広告主は余分なインプレッションに対して支払うことがないため、キャンペーンの予算超過を望んでいません。しかし、分散環境では特にシステムで 1 秒間に何十万件もの広告リクエストを受信できるような場合、残りの予算などのカウンタの集計が困難になる可能性があります。グローバルな残りの予算が迅速に統合されない場合、キャンペーンはわずか数秒で予算超過になる可能性があります。

デフォルトでは、ワーカーは兄弟ワーカーが使った金額を知ることなく、予算の一部を使用します。コミュニケーションの欠如によって、ワーカーが利用可能ではなくなった金額を使用してしまう状況が発生する可能性があります。

この問題に処理するには、さまざまな方法があります。以下のオプションの両方でグローバル予算マネージャーを実装しますが、これらの動作は異なります。

  1. 予算の枯渇についてワーカーに通知する: 予算マネージャーは、キャンペーンの予算が枯渇したときに、支出を追跡し、各ワーカーに通知をプッシュします。高レベルの QPS が発生する可能性があるため、予算超過を速やかに制限するために、1 秒以内に通知を行う必要があります。次の図は、このプロセスの動作を示しています。

    予算の枯渇の通知

  2. 各ワーカーに予算のスライスを繰り返し割り当てる: 予算マネージャーは、残りの予算全体を、各ワーカーに個別に割り当てるように小額に分割します。ワーカーは各自のローカル予算を使い、枯渇したときには、増額をリクエストできます。このオプションには 2 つの利点があります。

    1. 再び使用できるようになる前に、ワーカーは予算マネージャーが新しい金額を割り当てるまで待つ必要があります。このアプローチは、一部のワーカーがしばらくの間アイドル状態のままであっても、過剰な支出を防ぎます。
    2. 予算マネージャーは、各サイクルでのワーカーの支出行動に基づいて、各ワーカーに送信された割り当て金額を調整できます。次の図は、このプロセスを示しています。

      予算マネージャーが各ノードに予算を割り当てる

いずれのオプションを選択する場合でも、予算カウンタはサイト運営者と広告主が合意した価格設定モデルに基づいて計算されます。たとえば、モデルは次のようになります。

  • インプレッション単価ベースの場合、請求可能なインプレッションが発生すると、1,000 インプレッションあたりの価格設定に基づいて残りの予算を減らすイベントがシステムに送信されます。
  • クリック単価ベースの場合、ユーザーがクリックすると、1 回のクリックに対して設定された価格に基づいて残りの予算を減らすイベントがシステムに送信されます。
  • コンバージョン単価ベースの場合、広告主のプロパティに配置されたトラッキング ピクセルにより、1 回のアクションに対して設定された価格に基づいて残りの予算を減らすイベントがシステムに送信されます。

インプレッション数がクリック数よりも数桁多くなる場合があります。クリック数がコンバージョン数よりも数桁多くなる場合もあります。これらのイベントを取り込むには、スケーラブルなイベント処理インフラストラクチャが必要です。このアプローチの詳細については、データ パイプラインの記事をご覧ください。

分析ストア

分析ストアは、毎日のテラバイト単位の取り込んだデータをオフラインで保存して処理するために使用されるデータベースです。つまり、リアルタイムでの処理ではありません。例:

  • (一意の)ユーザーデータはオフラインで処理され、関連付けられたセグメントが決定され、ユーザー プロフィール データベースなどの高速なデータベースにコピーされて配信されます。このプロセスについては、エクスポートで説明しています。
  • コンテキスト ストアで使用されているオフライン カウンタを集計するために、リクエストをインプレッションと(一意の)ユーザー アクションに結合します。

レポート / ダッシュボード ストア

レポート / ダッシュボード ストアはユーザーのフロントエンドで使用され、キャンペーンや在庫の状況を把握するのに役立ちます。これにはさまざまなレポートタイプがあります。数秒ごと、またはリアルタイムで更新されるカスタム分析機能や半静的ダッシュボードなど、一部のみを提供することも、すべてを提供することもできます。

分析機能に BigQuery を使用できます。ビューを利用してデータアクセスを制限し、それに従って顧客と共有する場合、独自の UI または独自の可視化ツールを使用して、プラットフォーム ユーザーにアドホック分析機能を提供できます。すべての企業がこのオプションを提供しているわけではありませんが、お客様に提供できるということは大きな利点です。このユースケースに対して定額料金を使用することを検討してください。

ミリ秒単位から秒単位のレイテンシでお客様に OLAP 機能を提供する場合は、BigQuery の前面でデータベースを使用することを検討してください。レポートのためにデータを集約し、BigQuery から選択したデータベースにエクスポートできます。Cloud SQL でサポートされているリレーショナル データベースがこの目的でよく使用されます。

サービス アカウントを使用してユーザーの代理として役割を果たす App Engine や他のフロントエンドのために、BigQuery ではクエリが単一のユーザーによるものだと認識されます。その結果、BigQuery が一部のクエリをキャッシュに保存し、以前に計算した結果を迅速に返すことが可能になります。

半静的ダッシュボードも一般的に使用されています。こうしたダッシュボードは、データ パイプライン プロセスによって作成され、事前に集計された KPI を使用します。ほとんどのストアは、リアルタイム更新を容易にするための Firestore や、Cloud Memorystore などのキャッシュ レイヤなど、NoSQL ベースです。データの鮮度は一般的に、更新頻度とデータの集計に使用されるウィンドウの期間に依存します。

次のステップ

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

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