Ad Exchange Server - nicht wie andere

Published on August 29, 2018

Ad Exchange Server - nicht wie andere

    Ad Exchange für Echtzeit-Gebote (RTB) ist eine der AdTech-Lösungen, die den Online-Werbemarkt verändern. Seine Hauptfunktion ist das Andocken einer großen Anzahl von SSP und DSP, die keine direkte Integration untereinander aufweisen, sowie der Weiterverkauf verschiedener Werbeverkehrsarten zwischen ihnen.

    Dank des Auftrags für den US-Markt haben wir uns intensiv mit den Einzelheiten des Aufbaus der Ad Exchange-Plattform befasst. Und in diesem Artikel präsentieren wir einige Ideen und Ergebnisse.

    Bild

    Problemstellung


    Real-Time-Bidding (RTB) ermöglicht den Verkauf von Werbeflächen auf Websites in Echtzeit, um relevante Anzeigen für die Zielgruppe zu schalten.

    Kurz gesagt, das Prozessdiagramm sieht wie folgt aus:

    Bild

    • Der Endbenutzer fordert eine Webseite oder eine mobile Anwendung an, auf der Platz für das Banner reserviert ist (eingebetteter Code für den Verkauf von Werbeinventar - SSP, Supply Side Platform).
    • Um den maximalen Verkaufspreis für SSP-Inventar über Ad Exchange sicherzustellen, werden Gebote zwischen verschiedenen DSPs (Demand Side Platform) organisiert, deren Ziel es ist, Inventar so billig wie möglich zu kaufen.
    • Nach der Bekanntgabe des Auktionsgewinners sendet der gewinnende DSP den SSP-Code des Banners, der dem Benutzer angezeigt wird.
    • Eine andere Seite des Prozesses ist DMP, ein Drittanbietersystem, das dem DSP detaillierte Informationen über den Endbenutzer liefert (über das hinaus, was als Cookies usw. an den SSP gesendet werden kann), um den Kauf und den vorgeschlagenen Preis zu rechtfertigen.

    Es gibt heute einige Ad Exchange-Börsen. Darüber hinaus implementieren viele SSPs ihre eigenen Trades (tatsächlich wird die Ad Exchange-Funktionalität geschlossen). Unser Kunde war sich jedoch sicher, dass er aufgrund einiger neuer Ideen schnell in den Markt eintreten und dem Wettbewerb standhalten würde.

    Die Börsen funktionieren nach unterschiedlichen Prinzipien: Jemand bietet eine höhere Gewinnspanne, jemand weniger, jemand handelt mit einzigartigem Inventar, andere konzentrieren sich auf bedingte Konsumgüter. Der Markt ist noch recht jung und entwickelt sich aktiv. Daher gibt es im Laufe der Jahre keine bewährten Geschäftsmodelle: Alles basiert auf mutigen Hypothesen und Experimenten. Die meisten Spieler arbeiten auf einfache Weise: Sie erhalten eine Anfrage von einem von mehreren SSPs, mit denen sie eine Einigung erzielen konnten, und senden sie in Erwartung einer besseren Wette an alle integrierten DSPs. Der Ad Exchange-Umsatz ist die Differenz zwischen dem Kaufpreis und dem Verkauf des Werbeinventars von SSP und DSP abzüglich der Betriebskosten.

    Dieses Schema wurde von unserem Kunden vorgeschlagen, um durch korrekte Verteilung der SSP-Anforderungen an den DSP eine Optimierung zu erzielen - um keine offensichtlich "verlierenden" Anforderungen zu senden und damit die Betriebskosten zu senken. Auf diese Weise können Sie die Provision der Börse reduzieren, ohne Einnahmen zu verlieren, und Ihr Angebot vor dem Hintergrund eines Wettbewerbs mit Ad Exchange im Kampf um SSP und DSP attraktiver gestalten. Durch die Vernetzung weiterer Partner werden sowohl Einkommen als auch Stabilität auf dem Markt erzielt.

    Um diese Strategie auf dem US-amerikanischen Markt umzusetzen, mussten wir Ad Exchange mit einer intelligenten Abfrageverteilung ausstatten, die eine gute Einlösungsrate bieten sollte. Theoretisch können Sie für eine solche Verteilung viele Informationen verwenden, die der Anforderung beigefügt sind, auch Daten aus den oben genannten Fremdsystemen (DMP). Komplexe Analysen erfordern jedoch Ressourcen, sodass die Aufgabe darin besteht, ein Gleichgewicht zwischen den Kosten einer intelligenten Verteilung und dem Gewinn (im Vergleich zu anderen Marktteilnehmern) aus ihrer Implementierung zu finden. In einem relativ jungen, noch nicht ausgereiften Markt ist es einfach nicht sinnvoll, sehr komplexe Lösungen zu entwickeln, die ein Zehntel Prozent der Optimierung ausmachen.

    Ein wichtiges Merkmal des Projekts war neben den zu erwartenden hohen Belastungen die Erfüllung der von SSP gestellten nichtfunktionalen Anforderung an die Geschwindigkeit der Auktion. In diesem Marktsegment ist die Wartezeit auf eine Antwort des SSP von 300 ms ausreichend, die erforderlich war, um Anrufe an externe Systeme (DSP) entgegenzunehmen.

    Das Projekt startete im Herbst 2016. Dank der Erfahrung des Teams in diesem Bereich haben wir nach drei Monaten den ersten Prototyp erstellt und nach weiteren drei Monaten war das MVP (Minimum Viable Product) fertig, mit dem wir die ersten Analysen zusammenstellen konnten, um eine intelligente Abfrageverteilung in Ad Exchange zu starten.

    Der Start von MVP hat gezeigt, dass die Hypothese über den kommerziellen Erfolg des Projekts richtig ist - die Ad Exchange begann, das Kundengeld zu verdienen. Die ursprüngliche Entwicklung von Ad Exchange war eine eingehendere Untersuchung von Daten, die mit analytischen Informationen über Endbenutzer aus externen Systemen verknüpft wurden. In der MVP-Phase wurde jedoch beschlossen, nur die Daten zu verwenden, über die der SSP verfügt. Das war genug, um den erwarteten Gewinn zu erzielen.

    Lösungsarchitektur


    Die Lösung basiert auf dem Chain-of-Responsibility-Muster, das es ermöglicht, die Anforderungsroute innerhalb des Systems nicht zu fixieren und einfach Handler und verschiedene Services von der Auktion selbst bis zu Filter-Tools hinzuzufügen.

    Bild

    Der Kunde hat uns nicht auf den Stapel der verwendeten Technologien beschränkt. Aus diesem Grund haben wir für die zukünftige Entwicklung und Unterstützung des Projekts eine horizontal skalierbare Lösung mit Postgres und Hadoop entwickelt.

    Ad Exchange selbst ist in Java geschrieben. Gleichzeitig haben wir keine Frameworks verwendet, um die Last nicht zu beeinträchtigen (wir haben auf einer niedrigen Ebene gearbeitet).
    Um das erwähnte SSP-Timeout einzuhalten, haben wir die Garbage Collector-Parameter (von G1 verwendet) ausgewählt und synchron mit einer großen Anzahl von Anforderungen gearbeitet. Wir haben einen HTTP-Client verwendet, der den Stream nicht blockiert, sowie eine HTTP-Keep-Alive-Protokollerweiterung, mit der Sie mehrere Anforderungen senden können Single-TCP-Verbindung

    Softwarekomponenten werden auf Hardware bereitgestellt, die von einem Hoster geleast wurde Unter den Bedingungen der Aufgabe konnte die Cloud aufgrund der Überschneidung von Ressourcen virtueller Cloud-Maschinen nicht verwendet werden (die Zuweisung der erforderlichen Ressourcen kann einige Zeit in Anspruch nehmen, wir haben sie jedoch nicht). Derzeit verwendet Ad Exchange vier physische Server, von denen einer redundant ist (für nahtlose Updates usw.).

    Der Open-Source-Apache Kafka wird als Nachrichtenvermittler verwendet - er passt perfekt in unser Modell „ein Abonnent - viele Verlage“, obwohl er ein wenig „vermasselt“ werden musste, damit es nicht zu wiederholten Nachrichten kam.

    Jeder der Server bietet im normalen Modus die Verarbeitung von 10 Tausend Anfragen pro Sekunde (diese Parameter wurden während der Entwicklung der Lösung festgelegt). Derzeit beträgt die durchschnittliche Auslastung 15 bis 20.000 Anforderungen pro Sekunde. In der Spitze erreichte der Anforderungsfluss innerhalb weniger Stunden 40.000 Anforderungen pro Sekunde, und Ad Exchange hat dies perfekt bewältigt.

    Die Verteilung der Anfragen auf die Server übernimmt der für unsere Aufgabe konfigurierte Software Load Balancer nginx. Nach unserer Erfahrung kann nginx bis zu 60 bis 70.000 Anforderungen pro Sekunde speichern, ohne einen separaten Hardware-Balancer zuzuweisen. Sollte die Ad Exchange-Auslastung in Zukunft über diesem Schwellenwert liegen, planen wir den Kauf eines Hardware-Balancers, der die Anforderungen auf mehrere Nginx desselben Typs verteilt.

    Überwacht, was passiert, vorbehaltlich eines kontinuierlichen Lastwachstums, das Überwachungssystem, das Teil des erstellten Ad Exchange ist.

    Lagerung


    Angesichts des Analytics-Gebots bei der Verteilung von Abfragen ist die Datenbank ein integraler Bestandteil von Ad Exchange. Das System speichert Informationen zu Geboten, Bietern und Abschlüssen.

    Es ist nicht sinnvoll, diese Datenmenge für den gesamten Zeitraum von Ad Exchange zu erfassen, daher verfügt der Speicher über eine mehrschichtige Architektur. Alle Auktionsdaten werden für eine Woche gespeichert. Auf ihrer Basis werden übergeordnete Zwischenaggregate aufgebaut, die mehrere Monate gelagert werden. Und schon auf der Basis von Zwischenendgeräten werden Baugruppen zusammengesetzt, die in der Langzeitanalyse und für Abstimmungen mit SSP und DSP eingesetzt werden. Neben anderen Informationen in diesen Einheiten gibt es Daten darüber, wie viele Wetten abgeschlossen wurden und wie viel Geld die Börse dem SSP zahlt oder voraussichtlich vom DSP erhält.
    Endgültige Aggregate werden für die Dauer von Ad Exchange gespeichert.

    Das Sammeln von Analysen und das Erstellen von Aggregaten stellen separate Dienste bereit.

    Damit der Speicher der Geschwindigkeit des Systems selbst entsprach, musste es auch damit arbeiten. Insbesondere haben wir einige Zeit mit dem Hoster gestritten, weil Daten über Transaktionen hatten einfach keine Zeit, sich in der Datenbank zu registrieren. Es stellte sich heraus, dass das Hardwareproblem mit dem RAID-Array schuld war. Nach dem Ersetzen konnten wir 90.000 Anfragen pro Sekunde an Postgres senden (beim Einfügen von Daten in die Datenbank).

    Der Rest von Ad Exchange ist statusfrei, was in Zukunft eine einfache horizontale Skalierung ermöglicht. Es werden keine Daten zu Anforderungen gespeichert - das Maximum, die erhaltenen Informationen darüber, welcher DSP ausgewählt werden soll. So können wir neue Server hinzufügen, um Anforderungen nach Bedarf zu verarbeiten.

    Verkehrsfilterung


    Das Schlüsselelement des Systems, mit dem die Last reduziert und die vom Kunden angegebenen Timeouts eingehalten werden können, ist die Verkehrsfilterung.

    Je nach Aufgabe, die von Ad Exchange ausgeführt wird:
    • akzeptiert Anfragen vom SSP;
    • führt eine Auktion durch (sendet Anfragen an mehrere DSP, vergleicht die vorgeschlagenen Preise, identifiziert den Gewinner);
    • einigt sich mit SSP auf einen Sieg (teilt den Preis des Gewinners abzüglich seiner Provision mit, wartet auf eine Antwort mit dem Gesamtpreis der Show);
    • Schließt die Transaktion ab (informiert den erforderlichen DSP über seinen Sieg, führt Benutzerverkehr durch).

    Die clevere Verteilung von Abfragen in unserem Ad Exchange ist zu Beginn der Auktion aktiviert.

    Wenn wir eine Anfrage von einem SSP mit bestimmten Informationen (IP, Benutzeragent) erhalten, führen wir diese anhand der im System gesammelten Informationen auf - bekannte Daten über den Benutzer, eine Liste von DSPs, an die ähnliche Anfragen gesendet wurden, deren Antworten usw. Dies ist erforderlich, um für jede Anforderung die günstigste DSP-Kombination auszuwählen. Dank der Auswahl einer solchen Kombination kann das System keine Anfragen an diejenigen DSPs senden, die nicht wetten oder tun, aber zu niedrig sind. Zu diesem Zweck bildet ein separater Dienst in Echtzeit ab, wie der DSP auf Anforderungen reagiert (diese Karten werden in Redis gespeichert).

    Parallel dazu überprüfen wir den Status des DSP. Wenn der Anteil der Antworten innerhalb des Timeouts sinkt, reduziert das System automatisch die Anzahl der Anforderungen an diesen DSP. Sobald die Belastung des DSP abnimmt (und der Anteil der richtigen Antworten in angemessener Zeit zunimmt), kehrt die Anzahl der Anforderungen allmählich zum vorherigen Niveau zurück.

    Unter den DSPs, die rechtzeitig geantwortet haben, führen wir eine interne Auktion durch - wir markieren das beste Angebot und senden es an SSP. Ab dem Zeitpunkt der Anforderung vom SSP bis zu unserer Antwort dauert es gemäß den Branchenanforderungen nicht länger als 300 ms.

    Da wir die Daten an den SSP weitergeben, bei dem unsere Auktion stattfindet, müssen wir das dortige Höchstgebot berücksichtigen. Ihre Auktion wird im nächsten Schritt auf dem Auktionsserver ausgeführt, wenn der Benutzerverkehr verarbeitet wird. Dank ihm wird die DSP-Antwortkarte mit neuen Daten angereichert (zusammen mit den Informationen, die über den Endbenutzer gesammelt wurden).

    Durch den Vergleich der in der Auktion erhaltenen Daten mit den aus dem Nutzerverkehr bekannten Parametern können Sie Bots filtern (Clicker für Werbung, Suchbots usw.). Dieser Verkehr wird von DSP nicht zurückgenommen und führt mangels eines eigenen Filtersystems zu Kundenverlusten, die mit einer Marge geschlossen werden müssen.

    Es sollte beachtet werden, dass die Filterung des Bots-Verkehrs nicht sofort gestartet wurde. Nach der Einbeziehung einfacher Sperren betrug der Margengewinn jedoch etwa 50%.

    Übrigens: Zusätzlich zu den automatischen Tools zur Verkehrsfilterung in unserem System ist es dem Kunden möglich, die Schwellenwerte einer Reihe von Parametern manuell zu ändern und so die Marge anzupassen.

    Der Benutzerverkehr selbst ist für uns kritisch, aber bei der Verarbeitung müssen keine 300 ms mehr eingepasst werden. Es wird ein separates Verarbeitungssystem verwendet, das den Benutzer ein wenig halten kann, es jedoch nicht zulässt, diese Anforderung zu verlieren.

    Um die Stabilität der Lösung zu gewährleisten, wurde ein Subsystem eingeführt, das unter Berücksichtigung der aktuellen Ad Exchange-Last die Anforderungen für Auktionen "abschneidet", die nicht physisch verarbeitet werden können. So ist das System vor unkontrolliertem Lastwachstum durch den SSP geschützt.

    Perspektiven


    Bis heute funktioniert die von uns erstellte Ad Exchange und bringt einen guten Gewinn. Und wir unterstützen und integrieren bei Bedarf neue Partner (DSP / SSP). Insgesamt wurden bereits mehrere Dutzend Systeme integriert. Jede solche Integration beinhaltet nicht nur eine Softwareverbindung, sondern auch ein umfassendes Testen des Dienstes, da die Probleme des verbundenen Dienstes unter hoher Last andere Partner betreffen können.

    Im Allgemeinen bewegt sich der Markt dahingehend, dass SSP und DSP direkt verbunden werden, was den Austausch unnötig macht. Die Integration beruht jedoch auf den Fähigkeiten von SSP und DSP. Trotz der Existenz einer offen beschriebenen API (OpenRTB-Protokoll) ist diese auf dem Markt noch nicht allgemein anerkannt. Beispielsweise hat ein so großer Player wie Appnexus vor kurzem die Unterstützung für OpenRTB integriert.

    Ein Ad Exchange ist im Wesentlichen ein Liquiditätsanbieter. Es ist daher unwahrscheinlich, dass die Entscheidung in naher Zukunft ihre Relevanz verliert. Darüber hinaus gewinnt der Rest des Aktienmodells des Werbemarktes nur an Beliebtheit.



    Autor des Artikels: Nikolay Eremin

    PS Wir veröffentlichen unsere Artikel auf verschiedenen Seiten des Runet. Abonnieren Sie unseren Seiten in der VK , FB oder Telegramm-Kanal über alle unsere Publikationen und andere Nachrichten Unternehmen Maxilect zu lernen.