Im programmatischen Audiobereich bedeuten 101 ms null Umsatz. Das ist kein Performance-Problem, sondern ein Existenzproblem.  Wir betreiben eine digitale Signalverarbeitungsplattform (DSP) für Audiowerbung, die   Jede einzelne Anfrage muss innerhalb von   Wird dieses Zeitfenster verpasst, verfällt das Gebot. Bei 101 ms sind wir praktisch nicht existent. täglich rund 350 Millionen Anfragen verarbeitet – etwa 2 Milliarden pro Woche. 100 Millisekunden empfangen, ausgewertet und beantwortet werden.  Wir realisieren dies mit einem dreiköpfigen Entwicklerteam und Cloud-Kosten von unter 10.000 US-Dollar pro Monat. Dasselbe Team ist für alles verantwortlich – die Infrastruktur für Bieter, die Anwendungsschicht, die Datenbanken und den Betrieb.   Das RTB-Ökosystem  Falls Sie sich nicht so intensiv mit Werbetechnologie auskennen, hier die Kurzfassung: Programmatische Werbung basiert auf Real-Time Bidding (RTB).  Auf der Angebotsseite befinden sich   . Dies sind Plattformen wie AdsWizz oder Triton, die Werbeinventar aus Tausenden von Apps und Publishern aggregieren – Podcast-Player, Streaming-Apps und andere Audio-Plattformen. SSPs (Supply-Side-Plattformen)  Auf der Nachfrageseite gibt es   – Systeme wie unseres, die die Werbetreibenden vertreten und in Echtzeit entscheiden, ob sie auf eine bestimmte Impression bieten. DSPs (Demand-Side-Plattformen)  Wenn ein Hörer eine Podcast-App öffnet und ein Werbeplatz verfügbar wird, kommuniziert die App mit ihrer SSP (Software-Service-Plattform). Die SSP sendet daraufhin Gebotsanfragen an mehrere DSPs (Demand-Side-Plattformen). Unser System empfängt diese Anfrage, analysiert den Nutzer und die aktiven Kampagnen, berechnet einen Gebotspreis und sendet eine Antwort zurück. Dieser gesamte Prozess muss in weniger als 100 ms ablaufen.  Latenz ist hier nicht nur eine Messgröße. Sie ist das Produkt.  Nachdem wir das akzeptiert hatten, war klar, dass herkömmliche Webanwendungsmuster nicht funktionieren würden. Wir konnten uns keine Netzwerkverbindungen zwischen den Microservices leisten und erst recht nicht die hohen Cloud-Kosten einer ausufernden Kubernetes-Umgebung. Um zu überleben, mussten wir die Einschränkungen von Anfang an in unsere Planung einbeziehen.  Diese Einschränkung war nicht theoretischer Natur. Anfangs, als wir noch Cloud-Guthaben hatten, kümmerten wir uns wenig um Effizienz. Sobald dieses Guthaben aufgebraucht war, hatte jede Architekturentscheidung plötzlich einen realen Preis. Da mussten wir einen Schritt zurücktreten und das System im Hinblick auf Latenz, Kosten und einfache Bedienung neu konzipieren.  Im Folgenden wird die Architektur vorgestellt, die es einem dreiköpfigen Team ermöglicht, ein globales RTB-System in großem Umfang zu betreiben – ohne dabei Geld zu verbrennen oder schlaflose Nächte zu haben.  1. Geographie als erster Filter: Gestaltung der Netzwerkphysik  Die wichtigsten Audio-SSPs, mit denen wir integrieren –   – sind in den USA, Europa und Südostasien ansässig. Unsere Anwendungsschicht, die die Kampagnenlogik für Werbetreibende in Indien enthält, befindet sich in Indien. Triton, AdsWizz, Magnite (ehemals Rubicon) und MCTV  Die reine Netzwerklaufzeit zwischen diesen Regionen beträgt allein schon rund   , noch bevor die Anwendungslogik ausgeführt wird. Damit überschreiten wir das zulässige Budget bereits um mehr als das Doppelte. 240 Millisekunden  Die Lösung war unkompliziert, aber unabdingbar. Wir haben unsere Gebotscluster in   eingesetzt: US-West (Oregon), EU-Zentral (Frankfurt) und Asien-Pazifik (Singapur und Hongkong). vier strategischen AWS-Regionen  Dadurch wird sichergestellt, dass bei einer Gebotsanfrage eines SSP unsere Entfernung zum Hardware-Server vernachlässigbar gering ist – typischerweise im einstelligen Millisekundenbereich –, sodass der größte Teil des 100-ms-Budgets für die eigentliche Berechnung zur Verfügung steht.  2. Das Monolith-Mikroservice-Hybridmodell   Wir haben eine Architektur entwickelt, die zwischen einem traditionellen Monolithen und einem Microservices-Setup liegt. Anstatt die Dienste über das Netzwerk zu verteilen, platzieren wir einen   und skalieren diese VMs dann horizontal hinter einem globalen Load Balancer. kleinen Cluster eng gekoppelter Dienste auf einer einzigen virtuellen Maschine  Innerhalb jeder VM – die als einzelner Knoten behandelt wird – sieht es aus wie ein verteiltes Miniatursystem:    : Ein einzelner Ingress-Container, der als interner Traffic-Cop fungiert. Nginx    : 3–5 Replikate des Node.js-Bietdienstes, die auf demselben Rechner laufen, um die CPU optimal auszunutzen. Bieter    : Eine lokale Redis-Instanz, die direkt neben dem Code läuft. Redis  Der Vorteil liegt in der standardmäßigen Datenlokalität. Der Bieter muss die Daten nicht über das Netzwerk abrufen, sondern liest sie direkt vom lokalen Rechner. Dadurch können wir   deutlich erhöhen. Durch den Einsatz größerer VMs (z. B. c6i.xlarge) und die gemeinsame Nutzung eines einzelnen In-Memory-Datensatzes durch mehrere Worker erzielen wir ein wesentlich besseres RAM-zu-CPU-Verhältnis – wir minimieren Ressourcenverschwendung und maximieren gleichzeitig den Durchsatz. die Ressourcendichte  3. Die Logik: Schnelles Scheitern  Um eine Frist von 100 ms einzuhalten, reicht schneller Code allein nicht aus. Das System muss schnell entscheiden, wann es keine Arbeit ausführen soll.  Die meisten eingehenden Gebotsanfragen führen nie zum Erfolg. Der schnellste Weg, das Latenzbudget zu sprengen, wenn diese Anfragen auf Zustände, Datenbanken oder Schreibpfade zugreifen. Wir strukturieren den Bieter als Entscheidungsbaum, geordnet nach der „Fehlerwahrscheinlichkeit“, wobei die kostengünstigsten Prüfungen zuerst ausgeführt werden.  Die Prüfungen laufen in etwa in dieser Reihenfolge ab:    : Ein Großteil der Gebote scheitert hier. Dies ist ein einfacher Vergleich, der fast sofort ein Ergebnis liefert. Geografische Prüfung    : Wenn die geografische Prüfung erfolgreich ist, überprüfen wir die Plattform- und Gerätebeschränkungen. Betriebssystem- und Geräteprüfung    : Überprüfung, ob die App mit unserem zulässigen Inventar übereinstimmt. Publisher-/App-Targeting    : Nur wenn eine Anfrage diese Filter übersteht, greifen wir auf komplexere Pfade zu – Benutzerdaten, Budget- und Pacing-Logik oder alles, was eine Koordination erfordert. Zustandsbehaftete Logik  Durch schnelles Scheitern weisen wir 90 % des Datenverkehrs innerhalb von Mikrosekunden zurück und reservieren so CPU-Zyklen für die Gebote, die tatsächlich zu Konversionen führen.  4. Die Datenarchitektur: Redis für Regeln, Aerospike für Profile  Wir haben unsere Datenarchitektur anhand der Zugriffsmuster und der Kosten von „veralteten“ Daten in zwei Ebenen unterteilt.  Die Regeln: Lokales Redis  Jeder Knoten speichert aktuelle Metadaten (aktive Kampagnen und Budgetobergrenzen) in seinem lokalen Redis-Speicher. Ein Cron-Worker verwendet ein   und ruft alle 60 Sekunden die neuesten Daten von unserer zentralen API ab. Pull-Prinzip  In unserem Umfang birgt diese 60-sekündige Datenverfügbarkeit ein Risiko:   . Wenn mehrere Knoten gleichzeitig auf dieselben veralteten Budgetdaten zugreifen, könnten sie mehr ausgeben, als dem Kunden zugewiesen wurde. Mehrausgaben  Wir lösen dies mit einem   : Die Flottengröße dient als Eingangsgröße für die Budgetkontrolle. Mit zunehmender Anzahl aktiver Bieterknoten reduziert jeder Knoten dynamisch seinen Budgetanteil. Selbst wenn ein Knoten mit veralteten Daten arbeitet, sind seine lokalen Limits bereits durch die aktuelle Flottengröße begrenzt. Die Ausgaben sinken sanft statt sprunghaft, und das System stabilisiert sich im nächsten Aktualisierungszyklus. Bremsmechanismus  Die Profile: Aerospike (Der SSD-Vorteil)  Benutzerprofilabfragen, Frequenzbegrenzungen und Retargeting erfordern einen Zugriff auf massive, veränderliche Datensätze im Submillisekundenbereich. Ein herkömmliches RDBMS kann diese Last zu unserem Preis nicht bewältigen.  Wir verwenden   für diese Schicht, da es für die Nutzung von SSDs als primären Speicher optimiert ist, anstatt den gesamten Arbeitsspeicher im RAM zu halten. Dies ermöglicht uns eine vorhersehbare Latenz bei gleichzeitig deutlich geringeren Hardwarekosten als reine RAM-Lösungen wie ElastiCache. Aerospike  Um diese Ebene kostengünstig zu halten, achten wir rigoros auf Datenhygiene:  Die 10-Tage-Regel: Wir speichern nur Daten von Nutzern, die in den letzten 10 Tagen aktiv waren.  Die 10-Millionen-Grenze: Wir beschränken den Datensatz aktiv auf die wenigen Millionen aktivsten Nutzer.  Wenn ein Nutzer nicht mehr aktiv ist, werden seine Daten gelöscht. Diese Vorgehensweise gewährleistet, dass die Speicherkosten konstant bleiben, während sich der Bieter nur auf die relevanten Nutzer konzentriert.  5. Das Geheimnis der „asynchronen“ Arbeitsweise: Entlastung der Last  Unsere erste Version war technisch gesehen asynchron. Wir sendeten die Gebotsantwort sofort und ließen die Node.js-Funktion im Hintergrund weiterlaufen, um das Protokoll in MongoDB zu schreiben.    : Der Datenverkehr ist nicht gleichmäßig, sondern tritt sprunghaft auf. Während der Spitzenzeiten, obwohl keine Anfragen mehr beantwortet wurden, blieben unsere Node.js-Container in einer Art „Schwebezustand“ gefangen – sie hielten offene Verbindungen und verbrauchten CPU-Zyklen, um Datenbankzugriffe abzuschließen. Dies veranlasste unseren Autoscaler, zusätzliche VMs zu starten, nur um den   zu bewältigen, was schließlich zu einer Überlastung unserer Datenbank durch zu viele Verbindungen führte. Die Falle Schreibstau    : Wir haben von „asynchronem Code“ zu „   “ gewechselt.   dient als Puffer zwischen Bieter und Schreibvorgang. Der Bieter sendet nun eine Nachricht an Kafka und gibt seine Ressourcen sofort frei. Der Schreibvorgang wird von einer separaten Consumer-Flotte kontrolliert abgewickelt. Die Lösung asynchroner Architektur Kafka  6. Benchmarking: Messen statt raten  Bei diesem Umfang ist das Erraten von Instanztypen aufwändig. Anstatt uns also auf die Theorie zu verlassen, haben wir Benchmarks durchgeführt.  Wir hatten Hypothesen aufgestellt – ob der Bieter rechen- oder speichergebunden war, wie viele Worker-Prozesse pro Knoten sinnvoll waren und wie sich die Instanzgröße auf die Latenz auswirkte. Wir testeten verschiedene AWS-Instanzfamilien und -größen und variierten die Anzahl der auf einem einzelnen Knoten ausgeführten Bietdienste.  Wir haben den gleichen Ansatz für die Datenschicht gewählt und verschiedene Maschinentypen ausprobiert, um herauszufinden, welche für MongoDB unter realer Last am besten geeignet sind, wobei wir der stabilen Latenz Vorrang vor dem Spitzendurchsatz eingeräumt haben.  All dies wurde durch Lasttests validiert, die produktionsnahe QPS-Werte durch das System jagten und Reaktionszeiten sowie Latenzzeiten maßen. Einige Annahmen trafen zu. Viele jedoch nicht.  Die wichtigste Erkenntnis war einfach:   . Bei einem Budget von 100 ms schlagen Benchmarks die Theorie jedes Mal  7. Finanzoperationen: Wie wir die Kosten bei 10.000 US-Dollar halten  Startups gehen nicht unter, wenn der Datenverkehr zunimmt. Sie gehen unter, wenn das Cloud-Guthaben aufgebraucht ist. Für uns ist Kostenkontrolle kein nachträglicher Gedanke – sie ist integraler Bestandteil des Systemdesigns.  Ein Teil der Einsparungen resultierte aus Verhandlungen. Wir haben die Abrechnung über einen Reseller abgewickelt und dafür einen Mengenrabatt erhalten. Beim Bandbreitenvolumen haben wir uns auf   festgelegt, wodurch wir die CDN-Preise im Vergleich zu On-Demand-Tarifen um mehr als 60 % senken konnten. Bei unserem Datenverkehr hat diese einzelne Vereinbarung einen deutlichen Unterschied gemacht. etwa 1 PB monatliches Transfervolumen  Wir unterscheiden auch die verschiedenen Aspekte: Stateless-Bidding-Server arbeiten mit stark vergünstigter Spot-Kapazität, während Stateful-Datenbanken vorhersehbare, langlebige Instanzen nutzen.  Bei unserer Größenordnung ist die Speicherung von Hunderten Millionen Datensätzen pro Tag eine tickende Zeitbombe. Detaillierte Gebotsprotokolle werden nur kurz aufbewahrt – in der Größenordnung von Tagen, nicht Monaten. Daten, die wir behalten möchten, werden stündlich anstatt ereignisbezogen aggregiert und in kostengünstigere, abfragefreundliche Speicher ausgelagert. Alles, was nur für Compliance-Zwecke oder historische Prüfungen benötigt wird, wird in Cold Storage verschoben, wo die Kosten im Vergleich zu Standardtarifen um 80–90 % sinken.  Die größte Ersparnis erzielt man jedoch nicht durch Rabatte, sondern durch eine   . bessere Nutzung  Die meisten Systeme betreiben ihre CPUs aus Sicherheitsgründen nur mit 20–30 % Auslastung. Bei uns ist das nicht nötig. Da die Architektur fehlertolerant ist und Lasten sanft reduziert, können wir die CPUs bedenkenlos mit   betreiben. Wir zahlen nicht für Leerlaufzyklen. Jeder Kern, für den wir bezahlen, ist aktiv im Einsatz. 80 % Auslastung  Diese Denkweise – Effizienz als vorrangige Einschränkung zu behandeln – sorgt dafür, dass die Kosten auch bei zunehmendem Verkehrsaufkommen konstant bleiben.  8. Betrieb mit drei Personen: Die Philosophie der „Studiengebühren“  Globale Skalierung mit einem dreiköpfigen Team funktioniert nur, wenn Systeme – und nicht Personen – die Last tragen. Wir gestalten unsere Abläufe so, dass menschliche Eingriffe im kritischen Pfad vermieden und Single Points of Failure nach Möglichkeit beseitigt werden. Zudem vermeiden wir Rollensilos – jeder Entwickler beherrscht den gesamten Stack – sodass operatives Wissen niemals einen Single Point of Failure darstellt.  Infrastruktur ist standardmäßig austauschbar. Sollte ein Knoten Fehlfunktionen aufweisen, wird er nicht direkt debuggt, sondern beendet und vom Autoscaler ersetzt. Die Wiederherstellung ist schneller als die Fehlersuche, und jede Instanz befindet sich in einem bekannten, sauberen Zustand.  Observability ist wichtig, aber Dashboards allein helfen einem kleinen Team nicht weiter. Wir verlassen uns auf handlungsrelevante Warnmeldungen (über Datadog), die nur dann ausgelöst werden, wenn menschliches Eingreifen erforderlich ist. Wenn ein regionaler Cluster langsamer wird oder ein Client nicht mehr reagiert, werden wir benachrichtigt. Alles andere läuft automatisiert ab.  Automatisierung ist jedoch keine Zauberei. Wir müssen immer noch ab und zu Studiengebühren zahlen.  In einem frühen Fall schlug ein Hintergrundprozess, der für die Aktualisierung des Budgetstatus zuständig war, unbemerkt fehl. Der Bieter arbeitete weiterhin mit veralteten Daten und gab Geld für eine Kampagne aus, die eigentlich beendet sein sollte – ein klassisches „Zombie-Bieter“-Szenario. Wir erstatteten dem Kunden das Geld zurück, schlossen die Lücke und verstärkten das System durch regelmäßige, von Datadog überwachte Prüfungen. Die Budgetaktualität wird nun transparent dargestellt, und selbst wenn keine Aktualisierung erfolgt, wird ein Alarm ausgelöst. Erhält der Bieter keine gültige Aktualisierung, wird die Kampagne als beendet markiert.  In einem kleinen Team sind Fehler unvermeidlich.  Sie zu wiederholen ist optional.  Schlussgedanken  Keine der Entscheidungen in diesem System ist für sich genommen ungewöhnlich. Was es aber so effektiv macht, ist das Zusammenspiel dieser Entscheidungen.  Netzwerkphysik setzt die Grenzen. Lokalität und Ausfallsicherheitslogik schützen den 100-ms-Pfad. Asynchrone Grenzen absorbieren Lastspitzen. Messung ersetzt Intuition. Kostendisziplin und hohe Auslastung gewährleisten Wirtschaftlichkeit. Der Betrieb ist so konzipiert, dass menschliche Eingriffe nur dann erforderlich sind, wenn das System sich nicht selbst wiederherstellen kann.  Dies ist keine Geschichte über Werbetechnologie oder einen bestimmten Technologie-Stack. Sie soll daran erinnern, dass   . Wenn man Latenz, Kosten und Personalbedarf als zentrale Anforderungen behandelt, ist die resultierende Architektur tendenziell einfacher, nicht komplexer. Einschränkungen im großen Maßstab keine Hindernisse, sondern wichtige Designvorgaben darstellen  Das Ziel war nicht, etwas Beeindruckendes zu bauen. Es ging darum, etwas zu bauen, das Bestand hat.

This story contains new, firsthand information uncovered by the writer.

This story contains AI-generated text. The author has used AI either for research, to generate outlines, or write the text itself. 

Read My Stories

Dieses Audio ist in der Originalsprache der Geschichte produziert!

2 Milliarden Anfragen, 100 ms Fristen, 10.000 US-Dollar pro Monat: Entwicklung eines schlanken globalen RTB-Systems

About Author

KOMMENTARE

Hängeetiketten

DIESER ARTIKEL WURDE VORGESTELLT IN

Related Stories

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

HackerNoon Decoded 2024: Celebrating Our AI Community!

HackerNoon Decoded 2024: Celebrating Our Cybersecurity Community!

HackerNoon Decoded 2024: Celebrating Our Startups Community!

HackerNoon Decoded 2024: Wir feiern unsere Gaming-Community!

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps