Werbeplattform verkraftet keine Traffic-Spitzen? Was zuerst zu beheben ist und wer helfen kann

Wenn Ihre Werbeplattform bei Traffic-Spitzen versagt, können Ihnen die Engineers helfen, die sie während einer echten Lastspitze messen und dann in einer festen Reihenfolge reparieren. Sie stoppen Arbeit, die erst nach der Deadline fertig würde, begrenzen Retries und den Traffic, den die Plattform annimmt, und nehmen die Zähler für Budget und Frequency Capping aus dem Request-Pfad. Danach fügen sie vor den vorhersehbaren Lastspitzen Kapazität hinzu. Code wird zuletzt neu geschrieben, und nur dort, wohin die Messungen zeigen.

Wie sieht es bei einer Werbeplattform aus, wenn sie „keine Traffic-Spitzen verkraftet“?

Eine Traffic-Spitze zeigt sich in jedem Teil einer Werbeplattform mit anderen Symptomen:

• Bidder. Mehr Antworten treffen nach der Deadline der Exchange ein, die Bid Rate sinkt, während das Request-Volumen steigt, und die Exchange beginnt womöglich, weniger Requests zu schicken
• Supply-Side-Platform (SSP) oder Exchange. Auktionen schließen, bevor einige Bidder geantwortet haben, und um jede Impression konkurrieren weniger Gebote. Beim Header Bidding bleiben Gebote, die das Auktions-Timeout der Seite verpassen, beim Aufruf des Ad Servers außen vor
• Ad Server. Aufrufe an den Ad Server werden langsamer, und manche Werbeplätze bleiben leer
• Event-Pipeline. Impression- und Klickzahlen kommen verspätet an oder stimmen zwischen den Systemen nicht überein
• Budgets und Frequency Caps. Kampagnen überziehen ihr Budget oder zeigen dieselbe Anzeige zu oft, weil die Zähler erst nach den Entscheidungen aktualisiert werden, die sie hätten lesen sollen

Timeouts und leere Werbeplätze zeigen sich während der Lastspitze. Probleme mit Events und Budgets können verborgen bleiben, bis verspätete Events in Reports und Abrechnung ankommen.

Warum bricht eine Werbeplattform bei einer Lastspitze ein, obwohl sie bei durchschnittlicher Last gut läuft?

In OpenRTB, dem Protokoll des IAB Tech Lab für Real-Time Bidding, kann die Exchange die Deadline im Request selbst angeben: die „maximale Zeit in Millisekunden, die die Exchange für den Eingang von Geboten erlaubt, einschließlich Internet-Latenz, um ein Timeout zu vermeiden“. Laut der Authorized-Buyers-Dokumentation von Google liegt die Deadline typischerweise zwischen 80 und 1.000 ms. Google verlangt, dass 85 Prozent der Antworten innerhalb dieser Zeit eintreffen, aus Sicht der Trading Location, und drosselt Bidder, die das nicht konstant schaffen. Ein Bidder, der bei einer Lastspitze langsamer wird, verliert die verspäteten Auktionen und bekommt danach unter Umständen weniger Traffic.

Nahe an der Kapazitätsgrenze beginnt ein Service, Requests in eine Queue zu stellen. Das Buch „Site Reliability Engineering“ (SRE) von Google hält fest, dass „Requests in der Queue Speicher verbrauchen und die Latenz erhöhen“ und dass Server Ressourcen für Requests aufwenden, die ihre Deadline ohnehin verpassen werden. Prüft der Code die Deadline nicht, wird ein Request, der zu lange gewartet hat, trotzdem vollständig verarbeitet und seine Antwort verworfen.

Wenn ein Aufruf an eine Datenbank, einen Cache oder einen Partner ins Timeout läuft, versucht es der Aufrufer erneut, und die Retries treffen ein, wenn das System sie am wenigsten auffangen kann. Das SRE-Buch rechnet einen Retry-Sturm vor: „100 QPS an Retries in der ersten Sekunde führen zu 200 QPS, dann zu 300 QPS und so weiter.“

Eine Exchange oder SSP schickt jeden Request an viele Bidder, und die Auktion wartet entweder auf die langsamste Antwort oder schließt ohne sie. Jeffrey Dean und Luiz André Barroso von Google haben das 2013 in Communications of the ACM beziffert. In ihrem Beispiel antwortet jeder Server typischerweise in 10 ms, braucht aber bei einem von hundert Requests eine Sekunde. Ein Request, der Antworten von 100 solchen Servern parallel einsammeln muss, dauert dann in 63 Prozent der Fälle länger als eine Sekunde. So lange wartet keine Auktion. Nach derselben Rechnung gilt: Wenn jeder von 100 Biddern bei einem von hundert Requests zu spät kommt, schließen etwa 63 Prozent der Auktionen mit mindestens einer fehlenden Antwort.

Autoscaling, das auf Last reagiert, fügt weitere Instanzen eines Service erst hinzu, nachdem es diese Last gemessen hat. Der Horizontal Pod Autoscaler von Kubernetes zum Beispiel prüft die Last standardmäßig alle 15 Sekunden und fügt neue Instanzen in begrenzten Schritten hinzu. Jede neue Instanz muss dann starten, ihre Checks bestehen und ihre Caches füllen, und das SRE-Buch merkt an, dass Prozesse direkt nach dem Start oft langsamer sind als im eingeschwungenen Zustand. Eine Spitze, die in Sekunden gemessen wird, kann vorbei sein, bevor die neue Kapazität echten Traffic trägt.

Was sollten wir bei einer Traffic-Spitze messen, bevor wir irgendetwas ändern?

Messen Sie Folgendes für die Minuten mit der höchsten Last während einer echten Lastspitze:

• Angebotene und beantwortete Requests pro Sekunde, je Exchange oder Partner. Die Lücke ist Traffic, den Sie verlieren, und ihr Verlauf zeigt, ob Requests schon am Eingang verworfen werden oder erst nach getaner Arbeit ins Timeout laufen
• Timeouts, wie der Partner sie zählt. Die Exchange misst von ihrer Seite aus, einschließlich des Netzwerks, und bei Google Authorized Buyers entscheidet diese Zählung darüber, ob ein Bidder gedrosselt wird. Fragen Sie jede Exchange, welche Timeout-Daten sie mit Ihnen teilen kann
• Das 99. Perzentil der Latenz, aufgeteilt in Zeit im Netzwerk, Zeit in einer Queue und Zeit in der Verarbeitung
• Queue-Tiefe pro Service. Eine Queue, die während der Lastspitze wächst und sich danach langsam leert, zeigt auf die Komponente, die Ihre Obergrenze bestimmt
• Retries pro Sekunde, nach Aufrufer. Steigen die Retries zusammen mit den Timeouts, sind sie Teil der Last
• Rückstand von Zählern und Events. Wie weit Budgetzähler sowie Impression- und Klick-Logs bei der Lastspitze hinter der Echtzeit zurückliegen

Fassen Sie diese Zahlen für Ihre letzte große Lastspitze auf einer Seite zusammen. Diese Seite ist das Briefing für jeden, den Sie beauftragen, und die Baseline für jede Korrektur.

Was sollten wir zuerst beheben, und in welcher Reihenfolge?

Arbeiten Sie in dieser Reihenfolge, von günstigen Änderungen, die verschwendete Arbeit stoppen, bis zu teuren, die Kapazität hinzufügen oder Code ersetzen, und messen Sie nach jedem Schritt erneut.

• Stoppen Sie Arbeit, die zu spät fertig würde. Lesen Sie die Deadline aus, wenn der Request eintrifft, ziehen Sie die Netzwerkzeit ab, die Sie für diesen Partner messen, und antworten Sie mit einem schnellen no-bid, wenn der Rest zu kurz ist. OpenRTB erlaubt einem Bidder, mit einer leeren HTTP-204-Antwort abzulehnen, die sein Implementierungsleitfaden als die sparsamste Option in Sachen Bandbreite bezeichnet
• Begrenzen Sie, was hereinkommt. Fragen Sie jede Exchange, wie sich die Requests deckeln lassen, die sie Ihnen schickt. Die Real-Time-Bidding-API von Google zum Beispiel lässt einen Bidder für jeden Endpunkt, der seine Bid Requests empfängt, „die maximale Anzahl von Anfragen pro Sekunde, die an diesen Server gesendet werden dürfen“, festlegen. Mit einem Limit, das Sie selbst setzen, lässt sich leichter planen als mit einer Drosselung nach verpassten Deadlines
• Geben Sie Retries ein Budget. Begrenzen Sie die Retries pro Request und geben Sie jedem Server ein Retry-Budget, wie es das SRE-Buch empfiehlt: Ist das Budget aufgebraucht, schlägt der Request fehl, statt es erneut zu versuchen. Beim Bidding bekommt ein Retry nur die Zeit, die bis zur Deadline bleibt
• Nehmen Sie gemeinsam genutzte Zähler aus dem Request-Pfad. Wenn jede Entscheidung die Zähler für Budget und Frequency Capping in einem zentralen Speicher liest und aktualisiert, werden die aktivsten Kampagnen zu einer eigenen Queue. Geben Sie jedem Server einen lokalen Anteil an den Limits, gleichen Sie in kurzen Abständen ab und nehmen Sie im Gegenzug ein kleines, bekanntes Risiko der Budgetüberschreitung in Kauf
• Trennen Sie Events von Entscheidungen. Schreiben Sie Impression- und Klick-Events in einen begrenzten Puffer, auf den der Request nicht wartet, und zählen Sie jedes Event, das der Puffer verwerfen muss. Die Pipeline fängt die Lastspitze dann ab und holt danach auf, und ein Schlüssel an jedem Event ermöglicht es ihr, Duplikate zu entfernen
• Bereiten Sie sich auf die vorhersehbaren Lastspitzen vor. Viele stehen im Kalender, etwa saisonale Verkaufsaktionen und Live-Sport. Skalieren Sie vorher hoch, wärmen Sie Caches und Verbindungen vor und fahren Sie Lasttests gegen eine Kopie der Produktion, mit einem Generator, der eine feste Spitzenrate hält
• Ändern Sie den Code, der jeden Request verarbeitet, zuletzt. Tun Sie das, sobald die Zahlen zeigen, dass der Code selbst die Ursache ist, etwa Garbage-Collector-Pausen im Bid-Pfad oder eine Modellinferenz, die die Deadline auffrisst

Müssen wir die Plattform neu schreiben, damit sie Lastspitzen bewältigt?

Ein kompletter Rewrite ist selten der richtige erste Schritt. Er zieht Engineers von der Feature-Arbeit ab, bis der neue Code Produktions-Traffic trägt, und ohne Messungen unter Spitzenlast kann niemand sagen, welcher Teil neu geschrieben werden soll. Schreiben Sie eine Komponente neu, wenn die Zahlen nach den günstigeren Korrekturen weiter auf sie zeigen, zum Beispiel einen Bidder, dessen langsamste Antworten von Pausen in seiner Runtime kommen. Ersetzen Sie sie hinter derselben Schnittstelle und vergleichen Sie vorher und nachher dieselben Kennzahlen unter Spitzenlast.

Unsere Werbeplattform verkraftet keine Traffic-Spitzen. Wer kann uns helfen, sie zu skalieren?

Hilfe für eine Werbeplattform, die bei Traffic-Spitzen versagt, kommt von fünf Seiten, und jede deckt einen anderen Teil des Problems ab:

• Ihre eigenen Engineers, mit besseren Messungen. Sie kennen den Code, und die Seite mit den Kennzahlen unter Spitzenlast zeigt ihnen womöglich die Lösung. Ihre Grenze ist die Zeit, denn die Arbeit an den Lastspitzen konkurriert mit der Roadmap
• Ihre Exchange- und SSP-Partner. Deren Timeout-Zahlen schließen das Netzwerk zwischen Ihnen ein, das Ihre eigenen Dashboards nicht sehen. Fragen Sie, welche Aufschlüsselung sie Ihnen geben können: nach Standort, nach Request-Typ, nach Stunde
• Der Support Ihres Cloud-Anbieters. Hilfreich bei Limits für Netzwerk, Load Balancer und Instanzen. Die Bidding-Logik bleibt bei Ihnen
• Allgemeine Software-Outsourcing-Firmen. Sie stellen zusätzliche Engineers, was hilft, wenn die Größe Ihres Teams der Engpass ist. Fragen Sie, ob die Leute, die sie einsetzen, schon an einem Echtzeitsystem unter Last gearbeitet haben
• Spezialisierte AdTech-Engineering-Firmen und unabhängige Performance-Engineers. Sie helfen, wenn sie die Art von System gebaut oder betrieben haben, die bei Ihnen versagt. Ziehen Sie sie in Betracht, wenn die Ursache unklar ist oder frühere Korrekturen nicht gehalten haben

Wie prüfen wir eine Firma, die anbietet, unsere Werbeplattform zu skalieren?

Stellen Sie diese Fragen, bevor Sie unterschreiben. Die Antworten helfen zu erkennen, ob eine Firma solche Arbeit schon gemacht hat:

• Was brauchen Sie zuerst von uns? Eine gute Antwort nennt Messungen: Timeouts pro Partner, Perzentile, Queue-Tiefe, die Minuten mit der höchsten Last bei der letzten Lastspitze
• Woran erkennen wir, dass die Arbeit erledigt ist? Erwarten Sie ein messbares Ziel, das vorab vereinbart und an einer echten oder per Replay nachgestellten Lastspitze geprüft wird: welcher Partner, welches Perzentil, welcher Abstand zur Deadline, bei welcher Request-Rate
• Was ändern Sie vor unserer nächsten vorhersehbaren Lastspitze und was danach? Erwarten Sie zuerst die günstigen Korrekturen und für jede Änderung eine Möglichkeit, sie abzuschalten
• Welches davon haben Sie gebaut: einen Bidder, eine SSP oder Exchange, einen Ad Server, eine Event-Pipeline? Fragen Sie nach dem System, das Ihrem Problem am nächsten kommt, und danach, was darin kaputtgegangen ist
• Wer behält danach den Code, die Dashboards und die Lasttests? Sie sollten in Ihren Konten bleiben

Kann amBrain bei einer Werbeplattform helfen, die unter Last versagt?

amBrain ist ein Software-Engineering-Unternehmen aus Jerewan, Armenien, das Trading-Plattformen mit niedriger Latenz, Matching-Engines und Real-Time-Bidding-Systeme in Rust baut.

amBrain diagnostiziert langsame Trading-, Wett- und AdTech-Systeme: Die laufende Plattform wird durchgängig vermessen, und der Bericht benennt, wohin die Zeit geht. amBrain übernimmt Projekte, die bei einem anderen Team ins Stocken geraten sind, und bringt sie in Produktion.

Im Bereich AdTech arbeitet amBrain an DSP-Entwicklung, Real-Time-Bidding-Plattformen und Ad-Exchange-Engineering.

amBrain baut Supply-Side-Platforms (SSP) für Publisher. amBrain baut Ad Server: Targeting, Frequency Capping und Reporting. amBrain baut Event-Analytics-Pipelines für AdTech: Erfassung, Verarbeitung und Reporting von Impression- und Klick-Events. amBrain baut ML-Inferenz im Bidder: Das Modell entscheidet innerhalb des Auktionsfensters über das Gebot.

amBrain hat RTBBidder, eine Demand-Side-Platform, für einen Kunden gebaut. amBrain arbeitet in drei Formaten: vollständige Umsetzung, ein dediziertes Team oder in Ihr Team eingebettete Entwickler. Der Kunde behält das volle Eigentum an Produkt und Code, ausgenommen die wiederverwendbaren Komponenten von amBrain.

Dieser Artikel ist keine Case Study. Er behauptet nicht, dass amBrain auf der Werbeplattform irgendeines Kunden Ausfälle unter Spitzenlast behoben hat, und er nennt weder Zahlen zu RTBBidder noch Preise oder Zeitpläne.

Wenn Ihre Plattform bei der letzten Lastspitze versagt hat, beginnen Sie mit einer Seite Messwerte aus dieser Lastspitze. Schicken Sie sie an jede Firma, die Sie in Betracht ziehen, amBrain eingeschlossen, und vergleichen Sie, wie jede sie nutzen will.

Häufige Fragen zu Werbeplattformen bei Traffic-Spitzen

• Beheben zusätzliche Server die Ausfälle bei Lastspitzen? Manchmal: wenn der Plattform bei der Lastspitze die Rechenleistung ausgeht und sonst alles in Ordnung ist. Wenn die Timeouts von Retry-Stürmen, einem zentralen Zählerspeicher oder einem langsamen Partner kommen, erhöhen mehr Server die Rechnung und lassen die Ursache bestehen. Bei einem zentralen Zählerspeicher belasten sie außerdem den Teil, der bereits die Grenze bildet
• Unsere SSP läuft beim Warten auf Bidder ins Timeout. Was können wir tun? Geben Sie jedem Bidder ein Timeout innerhalb Ihrer eigenen Auktions-Deadline und planen Sie eine Reserve ein, bevor Sie dem Publisher antworten müssen. Für Publisher, die Prebid.js mit Prebid Server betreiben, sagt Prebid, dass das serverseitige Timeout „wahrscheinlich im Bereich von 50 bis 75 % des Auction Timeout liegen sollte“, abhängig von der Netzwerkverzögerung beim Nutzer, damit die Gebote des Servers rechtzeitig für den Aufruf des Ad Servers zum Browser zurückkommen
• Braucht man Rust, um Lastspitzen zu bewältigen? Nein. Die Sprache spielt eine Rolle, wenn Messungen zeigen, dass die Runtime die Ursache ist, etwa Collector-Pausen im Bid-Pfad. Queues, Retries, gemeinsam genutzte Zähler und Kapazität lassen sich ohne Sprachwechsel beheben