Infrastrukturoptionen für die Bereitstellung von Werbearbeitslasten (Teil 1)

In diesem Artikel werden die Komponenten erläutert, die auf verschiedenen Werbetechnologieplattformen, einschließlich Ad-Servern und Gebotsfunktionen, gemeinsam genutzt werden. Der Artikel bietet Ihnen Optionen zum Implementieren dieser Komponenten.

Ad-Server und Gebotsfunktionen sind oft komplementäre Plattformen mit überlappender Technologie. Dieser Artikel und Teil 2 bieten den nötigen Kontext für die Reihe, um doppelte Inhalte zu vermeiden:

Eine allgemeine Übersicht über die gesamte Reihe und die darin verwendete Terminologie finden Sie unter Werbeplattformen erstellen (Übersicht).

Hinweise zu Plattformen

Berücksichtigen Sie bei der Kauf- oder Verkaufsseite der Plattformen Folgendes:

  • Rechenplattform: Plattformen für programmatische Werbung umfassen mehrere Dienste, die jeweils eine oder mehrere Funktionen bieten. Entscheiden Sie sich frühzeitig, ob einige oder alle dieser Funktionen in einem Container zur Verfügung gestellt werden können, oder ob der Dienst direkt auf VM-Instanzen ausgeführt werden muss.
  • Geografische Standorte: Durch die Bereitstellung Ihrer Infrastruktur in der Nähe Ihrer Kunden und Anbieter können Sie die Netzwerklatenz reduzieren.
  • Reproduzierbarkeit: Wenn Sie ein System in verschiedenen Regionen der Welt replizieren, können Sie die gleiche Infrastruktur konsistent auf der gesamten Plattform bereitstellen.
  • Load-Balancing: Eine einzelne Maschine reicht nicht aus, um Arbeitslasten im Bereich der Anzeigentechnologie zu verarbeiten. Verteilen Sie interne und externe Anfragen auf mehrere Server.
  • Autoscaling: Die Anzahl der Anzeigenanfragen schwankt im Verlauf eines Tages. Durch die automatische Skalierung Ihres Systems können Sie Kosten senken und die Verfügbarkeit erhöhen.
  • Netzwerkkommunikation: Mit einem verteilten System sind immer Kommunikationsfragen verbunden. Angenommen, Sie geben in Oregon Gebote ab, aber Ihre Kampagnenverwaltungsdatenbank befindet sich in Europa. Selbst wenn die Kommunikation über Offline-Synchronisierung erfolgt, möchten Sie vermutlich nicht über das öffentliche Internet kommunizieren.

Rechenplattform

Die Google Cloud Platform (GCP) bietet zum Ausführen Ihrer Rechenarbeitslasten verschiedene Optionen:

  • App Engine zum Ausführen einer Web-UI ohne den Großteil des operativen Aufwands
  • Compute Engine zum Installieren und Verwalten einiger relationaler Datenbanken (oder benutzerdefiniertem Code), die nicht von App Engine unterstützt werden
  • Google Kubernetes Engine (GKE) zum Einrichten zustandsloser Front-Ends oder zum Ausführen von containerisierten Anwendungen

Diese Optionen sind Empfehlungen und oft untereinander austauschbar. Ihre Anforderungen an Kosten, Betriebsaufwand und Leistung sind letztendlich der entscheidende Faktor.

Compute Engine und GKE unterstützen beide VMs auf Abruf. Diese werden häufig in Arbeitslasten für Anzeigentechnologie verwendet, um Kosten zu sparen. VMs auf Abruf können allerdings mit einer Vorwarnung von nur einer Minute vorzeitig beendet werden. Daher bietet sich Folgendes an:

  • Wenn Sie Compute Engine verwenden, können sich zwei verschiedene verwaltete Instanzgruppen (eine auf Abruf und eine mit Standard-VMs) hinter demselben Load-Balancer befinden. Mit einer Gruppe aus Standard-VMs gewährleisten Sie, dass Ihr Front-End immer in der Lage ist, eingehende Anfragen zu bearbeiten. Das folgende Diagramm veranschaulicht diesen Ansatz.

    Zwei verschiedene verwaltete Instanzgruppen im selben Load-Balancer

  • Wenn Sie GKE verwenden, erstellen Sie in Ihrem GKE-Cluster sowohl Knotenpools auf Abruf als auch solche, die nicht auf Abruf verfügbar sind, um die Kosten zu reduzieren und gleichzeitig eine hohe Verfügbarkeit beizubehalten.

Standorte

Manche Werbetreibende möchten Kunden in allen Regionen der Welt ansprechen. Ein paar Millisekunden mehr in der Ausführung des UI-Front-Ends der Plattform beeinträchtigen Ihre Kunden nicht, wenn sie beispielsweise Leistungsdaten visualisieren. Aber seien Sie vorsichtig, wenn durch die zusätzliche Netzwerkentfernung die Gebotsantwort ein paar Millisekunden länger dauert. Diese wenigen Millisekunden könnten sich darauf auswirken, ob das Gebot des Werbetreibenden angenommen und seine Anzeige an die Kunden ausgeliefert wird.

Die GCP ist in mehreren Regionen vertreten, darunter us-east, us-west, europe-west, asia-southeast und asia-east. Jede Region umfasst mehrere Zonen, um sowohl eine hohe Verfügbarkeit als auch Skalierung zu bieten.

Wenn die Latenzzeit von entscheidender Bedeutung ist, möchten Sie möglicherweise einige Ihrer Dienste auf diese Zonen in verschiedenen Regionen verteilen. Sie können Ihre Einrichtung an Ihre Bedürfnisse anpassen. Beispielsweise könnten Sie sich für einige Front-End-Server in us-east4 und us-west1 entscheiden, die Daten jedoch in einer Datenbank in us-central speichern. In einigen Fällen könnten Sie einige Datenbankdaten lokal auf die Front-End-Server replizieren. Alternativ können Sie auch eine multiregionale Cloud Spanner-Instanz in Betracht ziehen.

Reproduzierbarkeit

Die Reproduzierbarkeit ermöglicht eine einfachere Wartung und Bereitstellung. Die Plattform an allen relevanten geografischen Standorten auszuführen kann außerdem entscheidend dafür sein, dass Angebote vor der kritischen Abgabefrist geliefert werden. Damit die Reproduzierbarkeit gewährleistet werden kann, muss jede Region ähnliche Arbeiten ausführen. Der Hauptunterschied besteht in der Arbeitslast und wie viele Maschinen und Zonen für die Skalierung erforderlich sind, um den regionalen Bedarf zu decken.

Bei Compute Engine sind Instanzvorlagen die Basis zum Einrichten ähnlicher regionaler verwalteter Instanzgruppen. Diese Gruppen können sich in verschiedenen Regionen befinden, um sich in der Nähe der SSPs zu befinden. Außerdem können sie sich über mehrere Zonen erstrecken, um eine hohe Verfügbarkeit zu gewährleisten. Das folgende Diagramm zeigt, wie dieser Prozess aussieht.

Mit Instanzvorlagen regional verwaltete Instanzgruppen einrichten

Container bieten eine höhere Abstraktion als die Maschinenvirtualisierung. Kubernetes ermöglicht die native Reproduzierbarkeit von Anwendungen durch YAML-Konfigurationsdateien, mit denen Pods, Services und Deployments mit Konsistenz zwischen den verschiedenen Clustern definiert werden können.

Lastenausgleich

Zwei Hauptszenarien erfordern Load-Balancing:

Wenn Sie Kubernetes für einige Teile der Infrastruktur verwenden möchten, empfehlen wir die Verwendung von GKE. Einige Kubernetes-Funktionen erfordern zusätzliche Implementierungsvorgänge, falls sie von Ihrem Anbieter nicht nativ unterstützt werden. Mit GKE kann Kubernetes native GCP-Funktionen verwenden:

GKE unterstützt auch container-natives Load-Balancing, um die Netzwerkzeit und mögliche zusätzliche Netzwerksprünge zu minimieren. Auf übergeordneter Ebene verhindert das Lastenausgleichsmodul, dass eine Anfrage an eine Instanz weitergeleitet wird, die keinen Pod des angeforderten Diensts hostet.

Autoscaling

Da Ihre Plattform Milliarden von Anzeigenanfragen pro Tag analysieren und berechnen muss, ist Load-Balancing unverzichtbar. Außerdem wäre eine einzelne Maschine für diese Aufgabe ungeeignet. Die Anzahl der Anfragen ändert sich jedoch im Laufe des Tages. Dies bedeutet, dass Ihre Infrastruktur je nach Bedarf skaliert werden muss.

Wenn Sie Compute Engine verwenden, können Sie verwaltete Autoscaling-Instanzgruppen aus Instanzvorlagen erstellen. Sie können diese Gruppen dann für verschiedene Messwerte skalieren, wie z. B. die HTTP-Last, für die CPU und für benutzerdefinierte Stackdriver-Messwerte, wie z. B. die Anwendungslatenz. Sie können diese Gruppen auch für eine Kombination dieser Messwerte skalieren.

Autoscaling-Entscheidungen beruhen auf dem Messwertdurchschnitt der letzten zehn Minuten und werden jede Minute über ein gleitendes Fenster getroffen. Jede Instanzgruppe kann eigene Skalierungsregeln haben.

Wenn Sie GKE, den Cluster Autoscaler von Kubernetes, verwenden, können Sie das Autoscaling mithilfe des GKE Cluster Autoscaler nativ implementieren. Der GKE Cluster Autoscaler verhält sich anders als der Compute Engine Autoscaler. Er generiert neue Knoten, wenn neue Pods nicht mehr auf den vorhandenen Knoten geplant werden können, da CPU oder Speicher auf den darunter liegenden Knoten fehlen. Wenn CPU oder Speicher wieder freigegeben werden, wird automatisch herunterskaliert.

Netzwerkkommunikation

Virtual Private Clouds (VPCs) können sich über mehrere Regionen erstrecken. Mit anderen Worten: Wenn Sie Datenbank-Lesereplikate in us-east und eine Master-Datenbank in asia-southeast innerhalb derselben VPC haben, können diese sicher über ihre privaten IP-Adressen oder Hostnamen kommunizieren, ohne das Google-Netzwerk zu verlassen.

Im folgenden Diagramm befinden sich alle Instanzen in derselben VPC und können ohne VPN direkt kommunizieren, auch wenn sie sich in verschiedenen Regionen befinden.

Alle Instanzen befinden sich in derselben VPC und in verschiedenen Regionen

GKE-Cluster werden bei ihrer Erstellung einer VPC zugewiesen und können viele dieser vorhandenen Netzwerkfunktionen verwenden.

Google bietet außerdem zwei Typen der Netzwerkinfrastruktur an:

  • Premium: Verwendet das globale private Netzwerk von Google. Wählen Sie diese Option für kritische Arbeitslasten wie die regionsübergreifende Datenbankreplikation.
  • Standard: Wählen Sie diese Option, wenn Sie aus Kostengründen lieber das öffentliche Internet verwenden möchten.

Wenn Sie verwaltete Produkte wie Cloud Bigtable, Cloud Storage oder BigQuery verwenden, bietet die GCP über die VPC privaten Zugriff auf diese Produkte.

Nutzer-Front-End

Ihr Nutzer-Front-End ist wichtig, erfordert jedoch den geringsten technischen Aufwand, da es wesentlich weniger Arbeitslasten bewältigt. Das Nutzer-Front-End bietet Plattformnutzern die Möglichkeit, Werbemittel wie Kampagnen, Creatives, Abrechnungen oder Gebote zu verwalten. Das Front-End bietet auch die Möglichkeit, mit Tools zur Berichterstellung zu interagieren. Sie können z. B. Kampagnen oder die Anzeigenleistung überwachen.

Beide Funktionen benötigen einerseits Web-Server, um dem Plattformnutzer eine UI zu bieten, und andererseits Datenspeicher zum Speichern von Transaktions- und Analysedaten.

Web-Serving

Ihr Werbe-Front-End muss wahrscheinlich:

  • hohe Verfügbarkeit bieten
  • hunderte Anfragen pro Sekunde verarbeiten
  • weltweit mit einer akzeptablen Latenzzeit verfügbar sein, um ein komfortables Nutzererlebnis zu bieten
  • eine UI bereitstellen

Ihre Benutzeroberfläche umfasst wahrscheinlich Funktionen wie ein Dashboard und Seiten, um Werbetreibende, Kampagnen und zugehörige Komponenten einzurichten. Das UI-Design ist eine separate Fertigkeit und geht über den Rahmen dieses Artikels hinaus.

Wir empfehlen die Verwendung von App Engine als Front-End-Plattform, um den technischen Aufwand zu minimieren. Das reduziert die Zeit, die Sie für die Verwaltung Ihrer Website-Infrastruktur benötigen. Wenn Sie eine benutzerdefinierte Laufzeit benötigen, sollten Sie benutzerdefinierte Laufzeiten in Betracht ziehen. Alternativ können Sie GKE oder Compute Engine verwenden, wenn Ihr bevorzugtes Anwendungspaket andere Anforderungen hat.

Datenspeicher

Es gibt zwei Datenspeichertypen in den Nutzer-Front-Ends:

Anfragen verarbeiten

Front-Ends

Anforderungen werden gesendet, um an einem von Ihrer Plattform bereitgestellten HTTP(S)-Endpunkt verarbeitet zu werden. Das sind die wichtigsten Komponenten:

  • Ein Load-Balancer, der mehrere hunderttausend Abfragen pro Sekunde verarbeiten kann
  • Ein Pool von Instanzen, die auf Basis verschiedener KPIs schnell skaliert werden können
  • Eventuell eine API, die den Endpunkt drosselt und/oder authentifiziert

Sowohl Compute Engine als auch GKE eignen sich gut als Rechenplattformen:

  • Compute Engine verwendet Cloud Load Balancing und verwaltete Instanzgruppen, die im Abschnitt Autoscaling behandelt werden.
  • GKE verwendet Cloud Load Balancing und Ingress (oder Istio Ingress Gateway), Horizontal Pod Autoscaler und Cluster Autoscaler.

Da die Pod-Skalierung schneller als die Knotenskalierung ist, bietet GKE möglicherweise schnelleres Autoscaling für einzelne Dienste. GKE unterstützt auch den Container-nativen Lastenausgleich. Damit wird das Weiterleiten von Anfragen direkt an Instanzen optimiert, die einen Pod des entsprechenden Diensts hosten.

Drosselung und Authentifizierung können mit Technologien wie Apigee oder Service Infrastructure verwaltet werden.

Parsen

Anzeigenanfragen sind im Allgemeinen im JSON- oder protobuf-Format und enthalten Informationen wie IP-Adresse, User-Agent oder Websitekategorie. Es ist wichtig, diese Daten zu extrahieren, die möglicherweise auch Informationen zum (einzelnen) Nutzer enthalten. Sie können dann damit Segmente abrufen, um Anzeigen auszuwählen und zu filtern.

Statische Filterung

Einige Anfragen, die normalerweise auf der Käuferseite eingehen, können unter Verwendung statischer Regeln verworfen werden. Eine solche frühzeitige Filterung kann die Datenmenge und die komplexe Verarbeitung reduzieren, die später erforderlich sind.

Regeln können schwarze Listen von Publishern oder der Ausschluss von Inhaltstypen sein. Während der Initialisierung können die Worker diese Regeln aus einer auf Cloud Storage gehosteten Datei abrufen und laden.

Anzeigenauswahl

Die Anzeigenauswahl kann in den verschiedenen Diensten oder Plattformen durchgeführt werden. Dazu gehören der Publisher-Ad-Server, der Advertiser-Ad-Server und der DSP. Bei der Anzeigenauswahl gibt es unterschiedliche Komplexitätsgrade:

  • Manche Auswahlmöglichkeiten sind einfach, z. B. das Auswählen von Anzeigen für bestimmte Kategorien der Website oder Seite des Publishers. In diesem Fall unterscheiden sich die Preise pro Anzeige nicht.
  • Erweiterte Auswahlmöglichkeiten umfassen Nutzerattribute und -segmente sowie möglicherweise ein auf maschinellem Lernen basierendes Anzeigenempfehlungssystem.
  • RTB-Systeme treffen in der Regel besonders komplexe Entscheidungen. Anzeigen werden basierend auf Attributen wie eindeutigen Nutzersegmenten und vorherigen Gebotspreisen ausgewählt. Die Auswahl umfasst außerdem eine Gebotsberechnung, um den Gebotspreis pro Anfrage zu optimieren.

Das Auswählen der jeweils relevanten Anzeige ist die Kernfunktion Ihres Systems. Sie müssen viele Faktoren berücksichtigen, darunter erweiterte regelbasierte Algorithmen oder ML-Auswahlalgorithmen. Dieser Artikel konzentriert sich jedoch weiterhin auf den übergeordneten Prozess und die Interaktionen mit den verschiedenen Datenspeichern.

Der Prozess für die Anzeigenauswahl besteht aus den folgenden Schritten:

  1. Die mit dem Zielnutzer verknüpften Segmente aus dem Profilspeicher für einzelne Nutzer abrufen.
  2. Die Kampagnen oder Anzeigen auswählen, die zu den Segmenten des Nutzers passen. Dazu müssen Metadaten aus dem Speicher für Metadatenverwaltung ausgelesen werden. Zu diesem Zweck muss ein Speicherungsmuster für hohe Lesegeschwindigkeit implementiert werden.
  3. Die ausgewählten Kampagnen oder Anzeigen entsprechend den Messwerten filtern (z. B. nach dem verbleibenden Budget), die in einem der Kontextspeicher gespeichert sind.
  4. Die Anzeige auswählen.

Bei Gebotsfunktionen gibt es mehr Schritte in Bezug auf Gebote und Auktionen sowie höhere Latenzanforderungen. Weitere Informationen zu den Anforderungen an Gebotsfunktionen bei der Anzeigenauswahl finden Sie unter Infrastrukturoptionen für RTB-Gebotsfunktionen (Teil 4).

Speicherungsmuster für hohe Lesegeschwindigkeit

Die meisten Entscheidungen, die bei der Auswahl einer Anzeige getroffen werden, erfordern intelligente Daten, die:

  • in Millisekunden, manchmal noch schneller, gelesen werden
  • so schnell wie möglich geschrieben werden, insbesondere für zeitkritische Zähler
  • oft als Teil eines Offline-Prozesses geschrieben werden, der Hintergrundanalysen oder maschinelle Lernaufgaben verwendet

Wie Sie Ihren Datenspeicher auswählen, hängt von Ihrer Gewichtung (Priorisierung) der folgenden Anforderungen ab:

  • Lese- oder Schreiblatenzzeiten minimieren: Wenn die Latenzzeit von entscheidender Bedeutung ist, benötigen Sie einen Speicher, der sich in der Nähe Ihrer Server befindet und auch schnelle Lese- und Schreibvorgänge skaliert ausführen kann.
  • Betriebsaufwand minimieren: Wenn Sie ein kleines Engineering-Team haben, benötigen Sie möglicherweise eine vollständig verwaltete Datenbank.
  • Skalierung: Der Datenspeicher muss horizontal skaliert werden, um entweder Millionen von Zielnutzern oder Milliarden von Ereignissen pro Tag zu unterstützen.
  • Abfragestil anpassen: Einige Abfragen können einen bestimmten Schlüssel verwenden, während andere Datensätze abrufen müssen, die andere Bedingungen erfüllen. In einigen Fällen können Abfragedaten im Schlüssel codiert werden. In anderen Fällen benötigen die Abfragen SQL-ähnliche Funktionen.
  • Aktualität der Daten maximieren: Einige Leistungsindikatoren wie das Budget müssen so schnell wie möglich aktualisiert werden. Andere Daten wie das Zielgruppensegment oder Zähler (z. B. Tagesobergrenzen) können später aktualisiert werden.
  • Kosten minimieren: Es ist möglicherweise nicht immer wirtschaftlich oder praktisch, jeden Tag Milliarden von Lese- und Schreibvorgängen mit hoher Konsistenz global in einer einzigen Datenbank zu verarbeiten, um das DevOps-Volumen zu minimieren.

Es gibt verschiedene Optionen, um hohe Anforderungen an die Lesegeschwindigkeit zu erfüllen. Dazu gehören Lesereplikate, Caching-Systeme, NoSQL-Datenbanken im Arbeitsspeicher und verwaltete spaltenorientierte NoSQL-Datenbanken.

RDBMS-Lesereplikate

Wenn Sie Cloud SQL verwenden (oder ein gleichwertiges auf der Compute Engine installiertes und verwaltetes RDBMS), können Sie die Lesevorgänge der Master-Instanz umverteilen. Viele Datenbanken unterstützen diese Funktion bereits. Worker können die benötigten Informationen abfragen, indem sie:

  • Lesereplikate verwenden, die der Anzahl der Worker entsprechen
  • Pooling-Proxys verwenden

Das folgende Diagramm zeigt, wie dieser Vorgang aussieht.

Datenbank, in der die Lesevorgänge von der Masterinstanz übertragen werden

Lesereplikate sind für starken Leseverkehr ausgelegt, die Skalierbarkeit ist jedoch nicht linear und die Leistung kann bei einer größeren Anzahl von Replikaten leiden. Wenn Sie Lese- oder Schreibvorgänge benötigen, die mit globaler Konsistenz und minimalem betrieblichen Aufwand skalierbar sind, sollten Sie Cloud Spanner in Betracht ziehen.

Lokale Caching-Ebene

Sie können eine Caching-Ebene wie Redis auf der Compute Engine mit optionalen lokalen Replikaten für die Worker verwenden. Diese Ebene kann die Latenz sowohl beim Lesen als auch beim Netzwerk stark reduzieren. Das folgende Diagramm zeigt, wie diese Ebene aussieht.

Latenz minimieren durch Verwendung einer Caching-Ebene

Wenn Sie in diesem Fall Kubernetes verwenden, sehen Sie sich DaemonSet und die Affinität an, um zu gewährleisten, dass:

  • Sie die Menge der replizierten Daten begrenzen
  • die Daten in der Nähe eines Bereitstellungs-Pods bleiben

Schlüssel/Wert-NoSQL im Arbeitsspeicher

Stellen Sie eine Datenbank im Arbeitsspeicher bereit, wie Aerospike oder Redis, um schnelle, maßgeschneiderte Lesevorgänge in großem Umfang zu ermöglichen. Diese Lösung kann für regionale Daten und Zähler hilfreich sein. Wenn Sie Vorbehalte wegen der Größe der gespeicherten Datenstrukturen haben, können Sie auch Datenbanken im Arbeitsspeicher nutzen, die auf SSD-Laufwerke schreiben können. Das folgende Diagramm zeigt, wie diese Lösung aussieht.

Speicherinterne Datenbank, die auf SSD-Laufwerke schreiben kann

Verwaltetes spaltenorientiertes NoSQL

Spaltenorientierte Datenspeicher sind Speicher für Schlüssel/Wert-Paare, die schnelles Lesen und Schreiben in großem Umfang ermöglichen. Sie können eine gemeinsame Open-Source-Datenbank wie Cassandra oder HBase installieren.

Wenn Sie sich für einen solchen Speicher entscheiden, empfehlen wir die Verwendung von Cloud Bigtable, um den betrieblichen Aufwand zu minimieren. Mit diesen Speichern können Sie Ihre Ein-/Ausgabeoperationen (IOPs) linear mit der Anzahl der Knoten skalieren. Mit einem geeigneten Schlüsseldesign können Anzeigenselektoren mit Geschwindigkeiten im einstelligen Millisekundenbereich das erste Byte in Petabyte von Daten lesen und Datenpipelines können ebenso schnell schreiben. Das folgende Diagramm zeigt, wie dieser Vorgang aussieht.

Spaltenorientierter Datenspeicher

Statischer Objektspeicher

Statische Daten, die im Protobuf-, AVRO- oder JSON-Format gespeichert werden können, lassen sich von Workern während der Initialisierung aus dem Cloud-Speicher laden und ihr Inhalt kann im RAM beibehalten werden. Das folgende Diagramm zeigt, wie dieser Vorgang aussieht.

Daten aus Cloud Storage laden

Es gibt keine einheitliche Lösung. Wählen Sie zwischen Lösungen, die auf Ihren Prioritäten basieren. Berücksichtigen Sie dabei Latenzzeit, Kosten, Vorgänge, Lese-/Schreibleistung und Datengröße.

Lösung Latenz Kosten Operativer Aufwand Lese-/Schreibleistung Datengröße
RDBMS-Lesereplikate Millisekunden Dienst- oder Compute-basiert Hoch Begrenzt Begrenzt
Cloud Spanner Millisekunden Dienstbasiert Niedrig Lineare Skalierung mit der Knotenanzahl Petabyte
In-Memory-Speicher Sub-Millisekunde Compute-basiert Hoch Skaliert mit der Knotenanzahl Skaliert mit der Knotenanzahl
Cloud Bigtable Einstelliger Millisekundenbereich Dienstbasiert Niedrig Lineare Skalierung mit der Knotenanzahl Petabyte

Werbedatenspeicher

In diesem Abschnitt werden Datenspeicheroptionen beschrieben, die sich jeweils für eines der drei folgenden Szenarien eignen:

  • Ad Serving-Speicher werden von Diensten für die Anzeigenauswahl verwendet. Für die Bereitstellung von Arbeitslasten sind geringe Latenzzeiten erforderlich und die Fähigkeit, Milliarden Lesevorgänge pro Tag abzuwickeln. Die Datengröße hängt von der Art der Daten ab.
  • Analytische Speicher werden offline über Ad-hoc-Abfragen oder Batch-Daten-Pipelines verwendet. Sie unterstützen Hunderte von Terabyte an Daten, die täglich gespeichert werden.
  • Berichterstellungs- oder Dashboardspeicher können für vordefinierte Dashboards, Zeitreihen oder für die Erstellung angepasster Berichte verwendet werden. Diese Optionen teilen Ihr Front-End auf und ermöglichen es Ihren Plattformnutzern, schnell Erkenntnisse zu gewinnen und die Leistung ihres Unternehmens zu visualisieren.

Ad-Serving-Speicher können so unterteilt werden:

  • Der Speicher für Metadatenverwaltung wird zum Auswählen relevanter Kampagnen und Anzeigen verwendet. Das Nutzer-Front-End erstellt und aktualisiert Daten. Für diese Daten ist Persistenz erforderlich.
  • Der Speicher für (einzelne) Nutzerprofile wird verwendet, wenn für den (einzelnen) Nutzer ein Profil erstellt wird, um eine passende Anzeige für den Nutzer zu finden. Die Daten werden hauptsächlich anhand von Ereignissen (in Teil 2) aktualisiert. Für diese Daten ist Persistenz erforderlich.
  • Der Speicher für Kontextbereitstellung wird zum Filtern von Anzeigen und Kampagnen nach mehreren Indikatoren wie Budget oder Häufigkeitsbegrenzung verwendet. Daten werden anhand von Ereignissen aktualisiert. Diese Daten werden häufig überschrieben.

Speicher für Metadatenverwaltung

Der Metadatenverwaltungsspeicher enthält die Referenzdaten, auf die Sie bei der Anzeigenauswahl Regeln anwenden. Einige hier gespeicherte Ressourcen gelten für eine bestimmte Plattform, andere können plattformübergreifend genutzt werden:

  • Bei einem Ad-Server auf der Verkaufsseite verwalten die Publisher Daten zu Kampagnen, Creatives, Werbetreibenden, Anzeigenflächen und Preisen. Einige Front-Ends gewähren möglicherweise auch den Käufern Zugriff.
  • Bei einem Ad-Server auf der Kaufseite verwalten die Käufer Daten zu Kampagnen, Creatives, Werbetreibenden und Preisen. Werbetreibende können diese Daten häufig selbst über eine UI aktualisieren.
  • Bei einer DSP verwalten Käufer Daten zu Kampagnen, Creatives, Werbetreibenden und Gebotspreisen. Werbetreibende können die Daten häufig selbst über eine UI aktualisieren.

Der Metadatenspeicher enthält relationale oder hierarchische semistatische Daten:

  • Schreibvorgänge sind das Ergebnis von Änderungen, die von Plattformnutzern über das Front-End vorgenommen werden und nicht häufig vorkommen.
  • Die Daten werden von den Servern für die Anzeigenauswahl täglich milliardenfach gelesen.

Die Metadaten-Datenbank für Kampagnen konzentriert sich auf das Nutzer-Front-End und muss Ressourcenbeziehungen und -hierarchien verwalten und von einigen Megabyte bis einigen Gigabyte an Daten speichern können. Die Datenbank muss außerdem Lese- und Schreibvorgänge im Bereich von Hunderten von Anfragen pro Sekunde bereitstellen. Die GCP bietet verschiedene verwaltete und nicht verwaltete Datenbankoptionen, um diese Anforderungen zu erfüllen:

  • Cloud SQL: Ein vollständig verwalteter Datenbankdienst, der MySQL oder PostgreSQL ausführen kann.
  • Cloud Datastore: Ein hoch skalierbarer, verwalteter und verteilter NoSQL-Datenbankdienst. Er unterstützt ACID-Transaktionen, bietet eine SQL-ähnliche Abfragesprache und verfügt über Strong Consistency- und Eventual Consistency-Ebenen.
  • Cloud Spanner: Eine horizontal skalierbare, relationale Datenbank, die starke, konsistente Lesevorgänge, globale Transaktionen und die Replikation zwischen Regionen ermöglicht. Sie kann hohe Arbeitslasten für Lese- und Schreibvorgänge verarbeiten.
  • Benutzerdefiniert: Sie können auch viele der Open-Source- oder proprietären Datenbanken (wie MySQL, PostgreSQL, MongoDB oder Couchbase) unter Compute Engine oder GKE installieren und verwalten.

Ihre Anforderungen können dazu beitragen, die Optionen einzugrenzen. Auf übergeordneter Ebene können Sie jedoch Cloud SQL verwenden, da es relationale Daten unterstützt. Cloud SQL ist auch verwaltet und bietet Optionen für Lesereplikate.

Wie bereits erwähnt, wird der Metadatenspeicher nicht nur von Plattformnutzern für die Berichterstellung oder Verwaltung verwendet, sondern auch von den Servern, die Anzeigen auswählen. Diese Lesevorgänge finden Milliarden Male am Tag statt. Es gibt zwei Hauptansätze, um diese hohen Leseanforderungen zu erfüllen:

  • Die Verwendung einer Datenbank wie Cloud Spanner, die konsistente Schreibvorgänge und milliardenfache Lesevorgänge pro Tag verarbeiten kann.
  • Die Entkoppelung von Lese- und Schreibvorgängen. Dieser Ansatz ist möglich, da Metadaten nicht häufig geändert werden. Weitere Informationen zu diesem Ansatz finden Sie unter Exporte (in Teil 2).

Speicher für einzelne Nutzerprofile

Dieser Speicher enthält (einzelne) Nutzer und die zugehörigen Informationen, die wichtige Entscheidungshilfen zur Auswahl einer Kampagne oder Anzeige auf Anfrage bieten. Zu den Informationen können die Attribute (einzelner) Nutzer, Ihre eigenen Segmente oder von Drittanbietern importierte Segmente gehören. In RTB enthalten importierte Segmente häufig Gebotspreisempfehlungen.

Dieser Datenspeicher muss Hunderte von Gigabyte, möglicherweise Terabyte, Daten speichern können. Der Datenspeicher muss außerdem in der Lage sein, einzelne Datensätze mit höchstens einstelligen Millisekunden-Geschwindigkeiten abzurufen. Wie viele Daten Sie speichern, hängt davon ab, wie detailliert Ihre Informationen zu (einzelnen) Nutzern sind. Sie sollten zumindest in der Lage sein, eine Liste von Segmenten für den Zielnutzer abzurufen.

Der Speicher wird häufig mit Daten aus der Interaktion von (einzelnen) Nutzern mit Anzeigen, von besuchten Websites oder über durchgeführte Aktionen aktualisiert. Je mehr Informationen vorhanden sind, desto besser ist das Targeting. Sie können auch Datenverwaltungsplattformen (DMPs) von Drittanbietern verwenden, um Ihre selbst erhobenen Daten anzureichern.

Cloud Bigtable oder Cloud Datastore sind gängige Datenbanken, die für Daten von (einzelnen) Nutzern verwendet werden. Beide Datenbanken eignen sich gut für das zufällige Lesen und Schreiben einzelner Datensätze. Sie sollten Cloud Bigtable nur dann in Betracht ziehen, wenn Sie mehrere Hundert Gigabyte Daten haben.

Andere gängige Datenbanken wie MongoDB, Couchbase, Cassandra oder Aerospike können ebenfalls unter Compute Engine oder GKE installiert werden. Obwohl diese Datenbanken häufig mehr Verwaltungsaufwand benötigen, bieten manche möglicherweise größere Flexibilität, eine geringere Latenzzeit und in manchen Fällen auch regionsübergreifende Replikation.

Weitere Informationen finden Sie unter Nutzerzuordnung (in Teil 4).

Kontextspeicher

Der Kontextspeicher wird häufig zum Speichern von Zählern verwendet, z. B. Frequency Capping und Restbudget. Wie oft die Daten im Kontextspeicher aktualisiert werden, ist unterschiedlich. Eine tägliche Obergrenze kann beispielsweise täglich verbreitet werden, während das verbleibende Kampagnenbudget so bald wie möglich neu berechnet und weitergeleitet werden muss.

Abhängig von dem von Ihnen ausgewählten Speichermuster, den von Ihnen aktualisierten Leistungsindikatoren und den Funktionen Ihrer ausgewählten Datenbank können Sie direkt in die Datenbank schreiben. Oder Sie möchten die Implementierung entkoppeln, indem Sie ein Publish-Subscribe-Muster mit einem Nachrichtensystem wie Cloud Pub/Sub verwenden, um den Speicher nach der Berechnung zu aktualisieren.

Gute Kandidaten für Kontextspeicher sind:

  • Cloud Bigtable
  • Das regionale Schlüssel/Wert-NoSQL-Muster im Arbeitsspeicher
  • Das regionale Caching-Muster

Bei Verwendung einer horizontalen Skalierung können diese Speicher Schreib- und Lesevorgänge skaliert verarbeiten. Unter Infrastrukturoptionen für Ad-Server (Teil 3) und Infrastrukturoptionen für RTB-Gebotsfunktionen (Teil 4) werden einige dieser Optionen ausführlicher erörtert.

Beispiel für die Verwaltung eines Budgetzählers in einer verteilten Umgebung

Sie legen Budgets im Kampagnenverwaltungstool fest. Sie möchten nicht, dass Ihre Kampagnen zu viel Geld ausgeben, da die meisten Werbekunden diese zusätzlichen Impressionen nicht bezahlen. In einer verteilten Umgebung kann es jedoch schwierig sein, Zähler wie das verbleibende Budget zusammenzufassen, insbesondere wenn das System Hunderttausende von Anzeigenanfragen pro Sekunde empfangen kann. Kampagnen können in wenigen Sekunden schnell überlastet werden, wenn das verbleibende globale Budget nicht schnell konsolidiert wird.

Standardmäßig gibt ein Worker einen Teil des Budgets aus, ohne zu wissen, wie viel gleichrangige Worker ausgegeben haben. Diese mangelnde Kommunikation kann dazu führen, dass der Worker nicht mehr vorhandenes Geld ausgibt.

Es gibt verschiedene Möglichkeiten, mit diesem Problem umzugehen. In den beiden folgenden Optionen wird ein globaler Budgetmanager implementiert; das Verhalten dieser Optionen variiert jedoch.

  1. Worker über ausgeschöpftes Budget benachrichtigen: Der Budgetmanager verfolgt die Ausgaben und benachrichtigt alle Worker, wenn das Budget der Kampagne ausgeschöpft ist. Aufgrund der Wahrscheinlichkeit eines hohen QPS-Volumens sollten Benachrichtigungen innerhalb einer Sekunde erfolgen, um Budgetüberschreitungen schnell einzudämmen. Das folgende Diagramm zeigt, wie dieser Prozess funktioniert.

    Benachrichtigung über die Erschöpfung des Budgets

  2. Wiederholt zugewiesene Budgetanteile für jeden Worker: Der Budgetmanager teilt das verbleibende Gesamtbudget in kleinere Beträge auf, die jedem Worker einzeln zugewiesen werden. Worker geben ihr eigenes, lokales Budget aus und können weitere Mittel anfordern, wenn das Budget ausgeschöpft ist. Diese Option bietet zwei Vorteile:

    1. Worker können weitere Ausgaben erst vornehmen, nachdem ihnen vom Budgetmanager ein neuer Betrag zugewiesen wurde. Dieser Ansatz verhindert Budgetüberschreitungen, allerdings kann es passieren, dass einige Worker zeitweise nicht aktiv sind.
    2. Der Budgetmanager kann den zugewiesenen Betrag, der an jeden Worker gesendet wird, in jedem Zyklus an das Ausgabeverhalten des Workers anpassen. Das folgende Diagramm zeigt diesen Vorgang.

      Der Budgetmanager weist jedem Knoten ein Budget zu

Unabhängig davon, welche Option Sie auswählen, werden die Budgetzähler auf der Basis des zwischen Publisher und Werbetreibendem vereinbarten Preismodells berechnet. Angenommen, das folgende Modell wurde vereinbart:

  • Auf CPM-Basis sendet eine abrechnungsfähige Impression ein Ereignis an das System, und das verbleibende Budget wird gemäß dem Preis pro tausend Impressionen verringert.
  • Auf CPC-Basis sendet die Klickaktion eines Nutzers ein Ereignis an das System, und das verbleibende Budget wird gemäß dem festgelegten Preis pro Klickaktion verringert.
  • Auf CPA-Basis sendet ein im Attribut des Werbetreibenden platziertes Tracking-Pixel ein Ereignis an das System, und das Budget wird gemäß dem Preis pro Aktion verringert.

Die Anzahl der Impressionen ist oft um einige Größenordnungen höher als die Anzahl der Klicks. Und die Anzahl der Klicks ist oft um einige Größenordnungen höher als die Anzahl der Conversions. Die Datenaufnahme dieser Ereignisse erfordert eine skalierbare Infrastruktur für die Ereignisverarbeitung. Dieser Ansatz wird im Artikel zur Datenpipeline ausführlicher beschrieben.

Analysespeicher

Der Analysespeicher ist eine Datenbank, in der Terabytes täglich aufgenommener Daten offline gespeichert und verarbeitet werden. Es findet somit keine Echtzeitverarbeitung statt. Beispiel:

  • Daten von (einzelnen) Nutzern werden offline verarbeitet, um die zugehörigen Segmente zu ermitteln. Diese werden für die Bereitstellung in schnellere Datenbanken kopiert, z. B. in die Nutzerprofildatenbank. Dieser Vorgang wird im Abschnitt Export erläutert.
  • Anfragen werden mit Impressionen und (einzelnen) Nutzeraktionen verknüpft, um die in einem Kontextspeicher verwendeten Offlinezähler zusammenzufassen.

Speicher für Berichterstellung/Dashboarding

Der Berichterstellungs-/Dashboarding-Speicher wird im Nutzer-Front-End verwendet und bietet Einblick in die Leistung von Kampagnen oder Inventaren. Es gibt verschiedene Berichterstellungstypen. Es könnte für Sie sinnvoll sein, einige oder alle davon anzubieten, darunter auch benutzerdefinierte Analysefunktionen und semistatische Dashboards, die jeweils im Abstand weniger Sekunden oder in Echtzeit aktualisiert werden.

Sie können BigQuery für seine Analysefunktionen verwenden. Wenn Sie Ansichten nutzen, um den Datenzugriff zu beschränken und sie entsprechend für Ihre Kunden freizugeben, können Sie Ihren Plattformnutzern Ad-hoc-Analysefunktionen über Ihre eigene UI oder ihre eigenen Visualisierungstools zur Verfügung stellen. Nicht jedes Unternehmen bietet diese Option an. Es ist aber eine gute Ergänzung, wenn Sie sie Ihren Kunden anbieten können. Verwenden Sie für diesen Anwendungsfall eine Pauschalpreisberechnung.

Wenn Sie Ihren Kunden OLAP-Funktionen mit einer Millisekunden-zu-Sekunden-Latenzzeit anbieten möchten, sollten Sie eine vor BigQuery gestellte Datenbank in Betracht ziehen. Sie können Daten für die Berichterstellung zusammenfassen und aus BigQuery in die gewünschte Datenbank exportieren. Zu diesem Zweck werden häufig relationale Datenbanken verwendet, wie sie von Cloud SQL unterstützt werden.

Da App Engine oder ein anderes Front-End, das stellvertretend für einen Nutzer handelt, ein Dienstkonto verwendet, behandelt BigQuery Suchanfragen, als ob sie von einem einzelnen Nutzer stammen. Dadurch kann BigQuery einige Suchanfragen im Cache speichern und zuvor berechnete Ergebnisse schneller zurückgeben kann.

Semistatische Dashboards werden ebenfalls häufig verwendet. Diese Dashboards verwenden vorab aggregierte KPIs, die von einem Datenpipeline-Prozess geschrieben werden. Speicher basieren höchstwahrscheinlich auf NoSQL, wie Firestore für leichtere Echtzeitaktualisierungen, oder es sind Caching-Ebenen wie Cloud Memorystore. Die Aktualität der Daten hängt in der Regel von der Häufigkeit der Aktualisierungen und der Dauer des Zeitfensters ab, in dem Ihre Daten zusammengefasst werden.

Weitere Informationen

Hat Ihnen diese Seite weitergeholfen? Teilen Sie uns Ihr Feedback mit:

Feedback geben zu...