Wie wir einen 12-stöckigen Technologie-Stack zusammenstellen und nicht verrückt waren

Appodeal ist ein Unternehmen von rund 100 Mitarbeitern, die in Moskau, San Francisco, Barnaul, Luzk, Kirow, Barcelona und seit Juni 2018 auch in Minsk arbeiten.

Wir beschäftigen uns mit der Monetarisierung mobiler Anwendungen durch Werbung für Benutzer. Wir haben mit der Werbevermittlung begonnen, aber der Technologiestack wächst ständig. Daher wurden andere Produkte aus der Ad-Tech-Branche in die Mediation aufgenommen.

Bild

Für diejenigen, die noch nicht mit Ad Tech vertraut sind - das ist das Arbeitsgebiet von Technologieunternehmen, die im Werbebereich arbeiten. Wenn Sie jemandem sagen, dass Sie im Bereich der mobilen Werbung arbeiten, reagieren die Leute oft skeptisch - anscheinend kommen Ihnen nervige Anzeigen wie „Azino Three Axes“ in den Sinn. Tatsächlich ist dies nur die Spitze des Eisbergs, und all diese "wilde" Werbung hat nichts mit diesem Werbegeschäft zu tun. Und das mobile Segment, in dem wir tätig sind, ist dem Segment der Werbung im Web längst entwachsen:

Bild

Warum muss ich Werbung in Anwendungen integrieren?


Natürlich werden viele Ressourcen für die Erstellung von Anwendungen verwendet - und die Ersteller / Besitzer wünschen sich die Zeit und Mühe, die sich auszahlen. Besitzer von mobilen Anwendungen, die ihre Anwendung im App Store / Google Play verbreiten, werden als Publisher oder Publisher bezeichnet. Publisher verwenden verschiedene Monetisierungsmodelle, von In-App-Käufen bis zur Monetarisierung durch Werbung. Von all diesen Methoden erlaubt es jedoch nur der letztere, dem Benutzer nicht für die Nutzung der Anwendung zu zahlen - und dies gibt der größten Zielgruppe eine Reichweite.

Ja, wenn zu viele Anzeigen vorhanden sind, wird dies alle nerven und die Aufbewahrung des Benutzers beeinträchtigen. Was natürlich keiner braucht. Daher versucht die Werbung immer, sich sinnvoll zu integrieren, um mit ihrer Anwendung ein Maximum an Geld zu verdienen und gleichzeitig den Nutzern keinen Cent zu nehmen.

Wie funktioniert das?


Sobald der Verlag mit Hilfe der Werbung Geld verdienen möchte, kommt er zu dem Unternehmen, das ihm diese Aufgabe so leicht wie möglich machen kann. Wie geht das mit Appodeal? Nach der Registrierung auf der Website integrieren wir die Anwendung in unseren Service. Dies geschieht über das Client-SDK, das die Anwendung mit dem Server-Teil verbindet und über die API mit dem Server-Teil kommuniziert.

Wenn wir die Details auf ein Minimum reduzieren, wird das Ziel der Interaktion auf zwei Stufen reduziert:

a. Bestimmen Sie, welche Art von Werbung Sie jetzt anzeigen müssen.
b. Senden Sie Informationen darüber, welche Anzeige geschaltet wurde und welche nicht, und zeigen Sie sie in der Statistik an.

Gegenwärtig stellt Appodeal mehrere tausend aktive Anwendungen bereit, die täglich etwa 400 bis 450 Millionen Anzeigenimpressionen liefern, die als Antwort auf etwa 1 Milliarde Anfragen an Werbenetzwerke (Werbeanbieter) eingehen. Damit all dies funktioniert, bedienen unsere Server insgesamt etwa 125.000 Anfragen pro Sekunde, d. H. rund 10,8 Milliarden Anfragen pro Tag.

Bild

Worauf ist das alles aufgebaut?


Wir verwenden verschiedene Technologien, um Geschwindigkeit, Zuverlässigkeit und gleichzeitig Flexibilität bei der Entwicklung und Unterstützung zu bieten. Momentan schreiben wir Code in den folgenden Sprachen:

  • / Ruby / Ruby on Rails + React.JS (Frontend) /: Immer noch ein großer Teil der API und des gesamten Webparts, das Benutzer und unsere Mitarbeiter sehen
  • / GoLang /: Verarbeitung großer Datenmengen nach Statistiken und nicht nur
  • / Scala /: Echtzeitverarbeitung von Anfragen zur Arbeit mit Börsen des Verkehrshandels über das RTB-Protokoll (mehr dazu am Ende des Artikels)
  • / Elixier / Phoenix /: Vielmehr der experimentelle Teil. Aufbau einiger Mikrodienste zur Verarbeitung eines Teils der Statistiken und der API.

Bild

Warum zunächst Ruby und Ruby on Rails?


Appodeal konkurriert in seinem Segment mit sehr großen Marktteilnehmern, so dass eine rasche Anpassung an Marktveränderungen erforderlich ist. Oft fühlt es sich an, als würde sich das Rad eines Autos bei einer Geschwindigkeit von 100 km / h ändern. Ruby on Rails ermöglichte es uns, das Rennen aufrechtzuerhalten und im Markt Fuß zu fassen, um in seinem Segment führend zu sein. Die wichtigsten Vorteile von Rails aus unserer Sicht:

  • Eine große Anzahl von erfahrenen Entwicklern
  • Großartige Gemeinschaft. Eine Vielzahl von fertigen Lösungen und Bibliotheken
  • Die Geschwindigkeit der Einführung neuer Funktionen und Ändern / Löschen alter

Bild

Der offensichtliche Nachteil:

  • Die Gesamtleistung lässt zu wünschen übrig. Dies wirkt sich auch auf das Fehlen von JIT (im Moment) und die Unfähigkeit aus, den Code zu parallelisieren (wenn Sie JRuby nicht berücksichtigen). Bis zu einem gewissen Grad bleibt dies tolerierbar, da Datenbank und Cache in der Regel zum Engpass werden. Was wir auf dem Bild von NewRelic sehen:

Bild

  • Der Schienenmonolith wird von Mikrodienstleistungen nicht allzu gut gesägt - ein hoher Grad an Kohärenz von Geschäftslogik und Datenzugriffslogik (ActiveRecord) ist davon betroffen.

Wie werden die Daten gespeichert?


Wir haben viele Daten. Sehr Dies sind Milliarden / Dutzende / Hunderte Milliarden Datensätze. Da die Daten völlig unterschiedlich sind, speichern wir sie auf unterschiedliche Weise. Sie sollten sich in der Architektur niemals auf eine Lösung beschränken, die angeblich universell ist. Die Praxis zeigt, dass es in Highload praktisch keine universellen Lösungen gibt. Vielseitigkeit bedeutet, dass durchschnittliche (oder deutlich unterdurchschnittliche) Daten zu Zugriff, Lesegeschwindigkeit und Speichergröße für diese Vielseitigkeit zahlbar sind. Zweitens müssen Sie ständig Neues ausprobieren, experimentieren und nach nicht trivialen Lösungen für die gestellten Aufgaben suchen. Gesamt:

  • / PostgreSQL /: Wir lieben Postgre. Wir halten es derzeit für die beste OLTP-Speicherlösung. Dort werden Daten zu Benutzern, Anwendungen, Werbekampagnen usw. gespeichert. Wir verwenden die Replikation der Primärreplik. Backups werden nur während der Weihnachtsferien durchgeführt, da dies für Wimps (nur ein Scherz) ist.
  • / VerticaDB /: Spaltenorientierte Datenbank. Wir verwenden zum Speichern von Milliarden Datensätzen in Statistiken. Kurz gesagt, Vertik galt lange Zeit als die beste OLAP-Lösung für Analytics-Speicher. Der Hauptnachteil ist der riesige (individuelle) Lizenzpreis.
  • / ClickHouse /: Auch spaltenorientierte Datenbank. Bewegen Sie sich mit VerticaDB nach und nach darauf. Wir betrachten derzeit die beste OLAP-Lösung. Nicht einen Cent wert. Es funktioniert sehr schnell und zuverlässig. Der Hauptnachteil besteht darin, dass Daten nicht gelöscht und aktualisiert werden können (wir werden in einem separaten Artikel darüber informieren, wenn jemand interessiert ist).

Bild

Nichosi! Wie können diese Daten nicht gelöscht und geändert werden?!

  • / Aerospike /: Der schnellste NoSQL-Schlüsselspeicher nach unserer Meinung. Es gibt eine Reihe von Nachteilen, aber im Allgemeinen sind wir zufrieden. Für Aerospike gibt es auf ihrer Website sogar eine Vergleichstabelle für die Leistung mit anderen Lösungen: [Wann ist die Aerospike NoSQL-Datenbank Redis] (https://www.aerospike.com/when-to-use-aerospike-vs-redis/)
  • / Redis /: Über "Radishes" denke ich, es macht keinen Sinn, es getrennt zu erzählen. Paradoxerweise besteht der Hauptvorteil in der einfachen Bedienung und dem Single-Streaming, wodurch beispielsweise Rennbedingungen vermieden werden können, wenn mit banalen Schaltern gearbeitet wird.
  • / Druid /: Wir verwenden große Datenfelder bei der Arbeit mit RTB-Börsen. Tatsächlich spielt es größtenteils auf demselben Feld wie ClickHouse, aber historisch gesehen stellte sich heraus, dass wir noch nicht zu einem Instrument wechseln konnten.

Bild

Ein solches Set mag überladen erscheinen, aber erstens besteht Appodeal aus einem großen Konglomerat aus mehreren Entwicklungsteams und mehreren Projekten in einem. Und zweitens sind dies die harten Realitäten der Werbetechnologie - wir sind weit davon entfernt, dass wir einen mehrstöckigen Stack in einem Unternehmen einsetzen.

Wie folgst du dem?



Da die Datenströme groß sind, müssen sie zur Verarbeitung der Warteschlange hinzugefügt werden, um sie verarbeiten zu können. Als Warteschlange benutzen wir Kafka. Dies ist eine großartige, zuverlässige Lösung, geschrieben in Scala, die uns nie im Stich gelassen hat.

Bild


Die einzige Anforderung für den Benutzer in diesem Fall ist, dass er Zeit hat, die ständig wachsende Warteschlange schneller zu rechen, als sie wächst. Einfache und offensichtliche Regel. Zu diesem Zweck verwenden wir hauptsächlich GoLang. Dies schließt jedoch nicht die Tatsache aus, dass der Arbeitsspeicher auf diesem Server ausreichend sein sollte.

Um den Überblick über die gesamte Wirtschaft zu behalten, müssen Sie buchstäblich alles überwachen und delegieren. Dafür verwenden wir:

  • / NewRelic /: Eine bewährte Lösung, die sich perfekt in Ruby on Rails und Mikrodienste von GoLang integriert. Der einzige Nachteil von NewRelic ist der Preis. Daher ist NewRelic nicht überall bei uns. In den meisten Fällen versuchen wir, sie durch von Hand gesammelte Metriken zu ersetzen - wir fügen sie zu Grafana hinzu.
  • / Statsd + Grafana /: Gute Informationen zum Sammeln von Metriken. Der einzige Nachteil besteht darin, dass Sie alles selbst anpassen und die NewRelic-Funktionalität "out of the box" wiederholen müssen.
  • / ElasticSearch + Fluentd + Kibana /: In den Protokollen fügen wir alles hinzu. Von langsamen PostgreSQL-Abfragen zu einigen Rails-Systemnachrichten. Tatsächlich können Sie mit einer auf ElasticSearch basierenden Lösung wie Kibana alle Protokolle bequem an einem Ort sammeln und dann nach den erforderlichen Nachrichten suchen.
  • / Airbrake /: Das Sammeln von Fehlern zusammen mit Stacktrace-Meldungen ist in allen Fällen obligatorisch. Im Moment ziehen wir mit Airbrake aus einer der kostenlosen Lösungen. Aus dem Grund wieder die Preise.

Bild

Sie müssen verstehen, dass richtig konstruierte Überwachung Ihre Augen und Ohren sind. Blinde Arbeit unmöglich. Sie müssen sehen, was auf Ihren Servern zu einem bestimmten Zeitpunkt passiert. Die Stabilität und Zuverlässigkeit Ihres Produkts hängt wesentlich davon ab, wie gut Sie ein System zum Erfassen und Anzeigen von Metriken erstellen.

Apropos Zuverlässigkeit: Wir halten mehrere Staging-Server für das Pre-Roll-Out und die Überprüfung von Releases bereit, die wir ständig unter Last halten und einen Teil des realen Datenverkehrs dort duplizieren. Jede Woche synchronisieren wir die Datenbanken zwischen Produktion und Styling. Dies gibt uns eine Art "Spiegel", mit dem wir Dinge testen können, die nicht vor Ort getestet werden können, sowie Probleme auf der Ebene des Lasttests ermitteln.

Ist das alles so schwer?


Es stellt sich so heraus. Wie Ilon Musk in seinem Buch schrieb: "Die besten Köpfe meiner Generation beschäftigen sich damit, wie man Menschen dazu bringt, auf Werbung zu klicken", erzählte mir Jeff Hammerbacher, ein früherer Facebook-Ingenieur. - Der Horror ... ". Eine kurze Liste der Funktionen von Appodeal:

  • Wir sind in zwei Dutzend Ad Networks und Agenturen integriert. Im automatischen Modus registrieren wir Anwendungen in diesen Netzwerken und richten verschiedene Parameter ein, damit diese Netzwerke mit maximaler Leistung arbeiten. Nicht jedes Netzwerk hat entsprechende APIs, irgendwo muss man es mit "Robotern" tun.
  • Jedes Netzwerk zahlt dem Benutzer Einnahmen für Impressionen, die nach unterschiedlichen Parametern abgerufen und verarbeitet werden müssen. Dies geschieht im Non-Stop-Modus. Wieder irgendwo von Robotern.
  • Um dem Nutzer maximale Einnahmen zu bieten, „zwingen“ wir die Netze, miteinander zu konkurrieren, und bauen den sogenannten „Wasserfall“ von Werbeangeboten auf. Der Wasserfall basiert auf verschiedenen Indikatoren, zum Beispiel dem eCPM (durchschnittlicher Preis pro 1000 Impressionen), den wir auf verschiedene Weise vorhersagen. Je höher das Aktionsangebot in einem Wasserfall ist, desto höher prognostizieren wir den Preis. Auf dem Gerät wird beliebig oft ein Wasserfall angeboten. Wie Sie vielleicht erraten haben, ist eine Werbung, die niemand schiebt und die nur jeden nervt, für niemanden von Interesse. Die einzige Ausnahme ist das sogenannte. Branded-Bannerwerbung von Coca-Cola, Pepsi und anderen Unternehmensgiganten, die immer und überall über sich selbst gesprochen haben.
  • Einige dieser Interaktionen basieren auf dem sogenannten RTB-Protokoll (Real-Time Bidding):

Bild


In diesem Fall werden die sogenannten Bieter online bei der Auktion miteinander gehandelt, um ihre Anzeigen auf dem ausgewählten Gerät zu schalten. Sehr interessanter Moment, der einen separaten Artikel verdient. Bei vielen Börsen wie Google AdExchange wird ein starrer Rahmen für die Antwortzeit des Servers festgelegt (z. B. 50 ms), was die Frage der Leistung aufwirft. Im Falle von Ungehorsam - eine Geldstrafe von Tausenden Dollar. Genau das macht den Kernel, der zusammen mit Druid auf Scala geschrieben wurde.

Jeder Jäger möchte wissen, wo der Fasan sitzt, und unsere Kunden (wie wir) möchten wissen, wer wann wann die Anzeigen erhalten hat. Daher müssen wir den gesamten Datenbestand, den wir haben, in eine Warteschlange stellen (Kafka), schrittweise verarbeiten und zur OLAP-Datenbank (ClickHouse) hinzufügen. Viele Leute denken, dass PostgreSQL diese Aufgabe genauso gut bewältigen kann wie jede andere Hipster-Lösung. Dies ist jedoch nicht der Fall. PostgreSQL ist gut, aber die klassische Lösung zum Erstellen von Indizes für die Datenzugriffsgeschwindigkeit funktioniert nicht mehr, wenn die Anzahl der zu filternden und sortierenden Felder mehr als 10 beträgt und die Menge der gespeicherten Daten etwa 1 Milliarde Datensätze beträgt. Sie haben einfach nicht genügend Speicherplatz, um alle diese Indizes zu speichern, oder es gibt Probleme beim Aktualisieren dieser Indizes. In jedem Fall, um die gleiche Leistung wie eine spaltenorientierte Lösung zu erzielen,

Fazit


In diesem Artikel habe ich versucht, zumindest kurz zu sagen, was wir tun, wie wir Daten speichern und verarbeiten. Teilen Sie uns in den Kommentaren mit, welchen Stack Sie verwenden, stellen Sie Fragen und fordern Sie neue Artikel an - wir teilen Ihnen gerne unsere Erfahrungen.

Jetzt auch beliebt: