Es scheint, dass der Bereich der Online-Werbung so technologisch fortschrittlich und automatisiert wie möglich sein sollte. Natürlich, denn dort arbeiten Giganten und Experten ihres Fachs wie Yandex, Mail.Ru, Google und Facebook. Aber wie sich herausstellte, gibt es der Perfektion keine Grenzen und es gibt immer etwas zu automatisieren.
Kommunikationsgruppe Dentsu Aegis Network Russland ist der größte Player auf dem Markt für digitale Werbung und investiert aktiv in Technologie, um seine Geschäftsprozesse zu optimieren und zu automatisieren. Eines der ungelösten Probleme des Online-Werbemarktes ist die Erhebung von Statistiken über Werbekampagnen verschiedener Internetplattformen. Die Lösung dieses Problems führte letztendlich zur Schaffung eines Produkts D1.Digital (gelesen als DiVan), über dessen Entwicklung wir sprechen wollen.
Warum?
1. Zum Zeitpunkt des Projektstarts gab es kein einziges fertiges Produkt auf dem Markt, das das Problem der Automatisierung der Erhebung von Statistiken zu Werbekampagnen löste. Das bedeutet, dass niemand außer uns selbst unsere Bedürfnisse befriedigen kann.
Dienste wie Improvado, Roistat, Supermetrics und SegmentStream bieten die Integration mit Plattformen, sozialen Netzwerken und Google Analytics und ermöglichen außerdem den Aufbau analytischer Dashboards zur bequemen Analyse und Steuerung von Werbekampagnen. Bevor wir mit der Entwicklung unseres Produkts begannen, haben wir versucht, einige dieser Systeme zum Sammeln von Daten von Websites zu verwenden, aber leider konnten sie unsere Probleme nicht lösen.
Das Hauptproblem bestand darin, dass die getesteten Produkte auf Datenquellen basierten, Platzierungsstatistiken pro Website anzeigten und keine Möglichkeit boten, Statistiken zu Werbekampagnen zu aggregieren. Dieser Ansatz ermöglichte es uns nicht, Statistiken verschiedener Websites an einem Ort anzuzeigen und den Status der Kampagne als Ganzes zu analysieren.
Ein weiterer Faktor war, dass die Produkte in der Anfangsphase auf den westlichen Markt ausgerichtet waren und die Integration mit russischen Standorten nicht unterstützten. Und bei den Websites, mit denen die Integration implementiert wurde, wurden nicht immer alle erforderlichen Metriken mit ausreichender Detailgenauigkeit heruntergeladen, und die Integration war nicht immer bequem und transparent, insbesondere wenn es darum ging, etwas zu erhalten, das nicht in der Systemschnittstelle enthalten ist.
Generell haben wir uns entschieden, nicht auf Produkte von Drittanbietern umzusteigen, sondern mit der Entwicklung eigener Produkte zu beginnen...
2. Der Online-Werbemarkt wächst von Jahr zu Jahr und hat 2018 gemessen an den Werbebudgets den traditionell größten TV-Werbemarkt überholt. Es gibt also eine Skala.
3. Im Gegensatz zum TV-Werbemarkt, wo der Verkauf kommerzieller Werbung monopolisiert ist, gibt es im Internet viele einzelne Eigentümer von Werbeinventar unterschiedlicher Größe mit eigenen Werbekonten. Da eine Werbekampagne in der Regel auf mehreren Websites gleichzeitig läuft, ist es zum Verständnis des Status der Werbekampagne erforderlich, Berichte von allen Websites zu sammeln und sie in einem großen Bericht zusammenzufassen, der das Gesamtbild zeigt. Es besteht also Optimierungspotenzial.
4. Es schien uns, dass die Eigentümer von Werbeinventar im Internet bereits über die Infrastruktur zum Sammeln von Statistiken und deren Anzeige in Werbekonten verfügen und in der Lage sein werden, eine API für diese Daten bereitzustellen. Das bedeutet, dass die Umsetzung technisch möglich ist. Sagen wir gleich, dass es nicht so einfach war.
Generell waren für uns alle Voraussetzungen für die Umsetzung des Projekts klar und wir rannten los, um das Projekt zum Leben zu erwecken...
Großer Plan
Zunächst entwickelten wir eine Vision eines idealen Systems:
- Darin sollen Werbekampagnen aus dem 1C-Unternehmenssystem automatisch mit ihren Namen, Zeiträumen, Budgets und Platzierungen auf verschiedenen Plattformen geladen werden.
- Für jede Platzierung innerhalb einer Werbekampagne sollten alle möglichen Statistiken automatisch von den Websites heruntergeladen werden, auf denen die Platzierung erfolgt, wie z. B. die Anzahl der Impressionen, Klicks, Aufrufe usw.
- Einige Werbekampagnen werden mithilfe der Überwachung durch Dritte durch sogenannte Adserving-Systeme wie Adriver, Weborama, DCM usw. verfolgt. In Russland gibt es auch einen industriellen Internetzähler – die Firma Mediascope. Nach unserem Plan sollen auch Daten aus unabhängiger und industrieller Überwachung automatisch in die entsprechenden Werbekampagnen geladen werden.
- Die meisten Werbekampagnen im Internet zielen auf bestimmte Zielaktionen (Kauf, Anruf, Anmeldung zur Probefahrt usw.) ab, die mithilfe von Google Analytics getrackt werden und deren Statistiken auch für das Verständnis des Kampagnenstatus wichtig sind sollte in unser Tool geladen werden.
Der erste Pfannkuchen ist klumpig
Angesichts unseres Engagements für flexible Prinzipien der Softwareentwicklung (agil, alles) haben wir beschlossen, zunächst ein MVP zu entwickeln und uns dann iterativ dem angestrebten Ziel zu nähern.
Wir haben uns entschieden, MVP basierend auf unserem Produkt zu entwickeln DANBo (Dentsu Aegis Network Board), eine Webanwendung mit allgemeinen Informationen zu den Werbekampagnen unserer Kunden.
Für MVP wurde das Projekt hinsichtlich der Umsetzung so weit wie möglich vereinfacht. Wir haben eine begrenzte Liste von Plattformen für die Integration ausgewählt. Dies waren die wichtigsten Plattformen wie Yandex.Direct, Yandex.Display, RB.Mail, MyTarget, Adwords, DBM, VK, FB und die wichtigsten Anzeigensysteme Adriver und Weborama.
Um über die API auf Statistiken zu Websites zuzugreifen, haben wir ein einziges Konto verwendet. Ein Kundengruppenmanager, der die automatische Erfassung von Statistiken zu einer Werbekampagne nutzen wollte, musste zunächst den Zugriff auf die erforderlichen Werbekampagnen auf Websites an das Plattformkonto delegieren.
Als nächstes kommt der Systembenutzer DANBo musste eine Datei eines bestimmten Formats in das Excel-System hochladen, die alle Informationen zur Platzierung (Werbekampagne, Plattform, Format, Platzierungszeitraum, geplante Indikatoren, Budget usw.) und Kennungen der entsprechenden Werbekampagnen auf der enthielt Websites und Zähler in Werbesystemen.
Es sah ehrlich gesagt erschreckend aus:
Die heruntergeladenen Daten wurden in einer Datenbank gespeichert, und dann sammelten separate Dienste Kampagnenkennungen auf Websites von ihnen und luden Statistiken darüber herunter.
Für jede Site wurde ein separater Windows-Dienst geschrieben, der einmal täglich unter einem Dienstkonto in der API der Site ging und Statistiken für bestimmte Kampagnen-IDs herunterlud. Das Gleiche geschah mit Werbesystemen.
Die heruntergeladenen Daten wurden auf der Oberfläche in Form eines kleinen benutzerdefinierten Dashboards angezeigt:
Unerwartet für uns begann MVP zu arbeiten und begann, aktuelle Statistiken zu Werbekampagnen im Internet herunterzuladen. Wir haben das System auf mehreren Kunden implementiert, aber beim Versuch, es zu skalieren, stießen wir auf schwerwiegende Probleme:
- Das Hauptproblem war die Komplexität der Vorbereitung der Daten zum Laden in das System. Außerdem mussten die Platzierungsdaten vor dem Laden in ein streng festgelegtes Format konvertiert werden. Es war notwendig, Entitätskennungen von verschiedenen Websites in die Download-Datei aufzunehmen. Wir sind mit der Tatsache konfrontiert, dass es für technisch ungeübte Benutzer sehr schwierig ist, zu erklären, wo diese Identifikatoren auf der Website zu finden sind und wo in der Datei sie eingegeben werden müssen. Angesichts der Anzahl der Mitarbeiter in den Abteilungen, die Kampagnen auf den Websites durchführen, und des Umsatzes führte dies zu einer enormen Unterstützung auf unserer Seite, mit der wir absolut nicht zufrieden waren.
- Ein weiteres Problem bestand darin, dass nicht alle Werbeplattformen über Mechanismen verfügten, den Zugriff auf Werbekampagnen an andere Konten zu delegieren. Aber selbst wenn ein Delegationsmechanismus verfügbar wäre, wären nicht alle Werbetreibenden bereit, Drittkonten Zugriff auf ihre Kampagnen zu gewähren.
- Ein wichtiger Faktor war die Empörung, die bei den Nutzern darüber ausgelöst wurde, dass sie alle geplanten Indikatoren und Platzierungsdetails, die sie bereits in unser 1C-Buchhaltungssystem eingeben, erneut eingeben müssen DANBo.
Dies brachte uns auf die Idee, dass die primäre Informationsquelle über die Platzierung unser 1C-System sein sollte, in das alle Daten genau und pünktlich eingegeben werden (hier geht es darum, dass Rechnungen auf der Grundlage von 1C-Daten erstellt werden, also korrekte Eingabe der Daten in 1C). ist eine Priorität für jeden KPI). So entstand ein neues Konzept des Systems...
Konzept
Als erstes haben wir uns entschieden, das System zur Erhebung von Statistiken zu Werbekampagnen im Internet in ein separates Produkt aufzuteilen – D1.Digital.
Im neuen Konzept haben wir uns für das Laden entschieden D1.Digital Informationen zu Werbekampagnen und darin enthaltenen Platzierungen von 1C und rufen dann Statistiken von Websites und AdServing-Systemen zu diesen Platzierungen ab. Dies sollte den Nutzern das Leben deutlich erleichtern (und den Entwicklern wie üblich mehr Arbeit bescheren) und den Supportaufwand reduzieren.
Das erste Problem, auf das wir stießen, war organisatorischer Natur und hing damit zusammen, dass wir keinen Schlüssel oder kein Zeichen finden konnten, anhand dessen wir Entitäten aus verschiedenen Systemen mit Kampagnen und Platzierungen von 1C vergleichen könnten. Tatsache ist, dass der Prozess in unserem Unternehmen so gestaltet ist, dass Werbekampagnen von verschiedenen Personen (Mediaplaner, Einkauf usw.) in verschiedene Systeme eingegeben werden.
Um dieses Problem zu lösen, mussten wir einen eindeutigen Hash-Schlüssel, DANBoID, erfinden, der Entitäten in verschiedenen Systemen miteinander verknüpft und der in heruntergeladenen Datensätzen relativ einfach und eindeutig identifiziert werden kann. Diese Kennung wird im internen 1C-System für jede einzelne Platzierung generiert und an Kampagnen, Platzierungen und Zähler auf allen Websites und in allen AdServing-Systemen übertragen. Die Implementierung der Praxis, DANBoID in allen Platzierungen einzusetzen, hat einige Zeit gedauert, aber wir haben es geschafft :)
Dann haben wir herausgefunden, dass nicht alle Websites über eine API zum automatischen Sammeln von Statistiken verfügen, und selbst diejenigen, die über eine API verfügen, geben nicht alle erforderlichen Daten zurück.
Zu diesem Zeitpunkt haben wir beschlossen, die Liste der zu integrierenden Plattformen erheblich zu reduzieren und uns auf die Hauptplattformen zu konzentrieren, die an der überwiegenden Mehrheit der Werbekampagnen beteiligt sind. Diese Liste umfasst alle größten Player auf dem Werbemarkt (Google, Yandex, Mail.ru), sozialen Netzwerken (VK, Facebook, Twitter), wichtigen AdServing- und Analysesystemen (DCM, Adriver, Weborama, Google Analytics) und anderen Plattformen.
Die meisten der von uns ausgewählten Websites verfügten über eine API, die die von uns benötigten Metriken bereitstellte. In Fällen, in denen es keine API gab oder diese nicht die erforderlichen Daten enthielt, verwendeten wir Berichte, die täglich an unsere Büro-E-Mail-Adresse gesendet wurden, um Daten zu laden (in einigen Systemen ist es möglich, solche Berichte zu konfigurieren, in anderen haben wir uns auf die Entwicklung solcher Berichte geeinigt für uns).
Bei der Analyse von Daten verschiedener Standorte haben wir festgestellt, dass die Hierarchie der Entitäten in verschiedenen Systemen nicht gleich ist. Darüber hinaus müssen Informationen unterschiedlich detailliert aus verschiedenen Systemen heruntergeladen werden.
Um dieses Problem zu lösen, wurde das SubDANBoID-Konzept entwickelt. Die Idee von SubDANBoID ist ganz einfach: Wir markieren die Hauptentität der Kampagne auf der Site mit der generierten DANBoID, laden alle verschachtelten Entitäten mit eindeutigen Site-Identifikatoren hoch und bilden SubDANBoID nach dem DANBoID-Prinzip + Identifikator der ersten Ebene verschachtelte Entität + Kennung der verschachtelten Entität der zweiten Ebene +... Dieser Ansatz ermöglichte es uns, Werbekampagnen in verschiedenen Systemen zu verbinden und detaillierte Statistiken darüber herunterzuladen.
Wir mussten auch das Problem des Zugriffs auf Kampagnen auf verschiedenen Plattformen lösen. Wie wir oben geschrieben haben, ist der Mechanismus, den Zugriff auf eine Kampagne an ein separates technisches Konto zu delegieren, nicht immer anwendbar. Daher mussten wir eine Infrastruktur für die automatische Autorisierung über OAuth mithilfe von Token und Mechanismen zur Aktualisierung dieser Token entwickeln.
Später in diesem Artikel werden wir versuchen, die Architektur der Lösung und die technischen Details der Implementierung detaillierter zu beschreiben.
Lösungsarchitektur 1.0
Als wir mit der Implementierung eines neuen Produkts begannen, wurde uns klar, dass wir sofort die Möglichkeit zur Anbindung neuer Standorte vorsehen mussten, und entschieden uns daher für den Weg der Microservice-Architektur.
Bei der Gestaltung der Architektur haben wir die Konnektoren zu allen externen Systemen – 1C, Werbeplattformen und Adserving-Systemen – in separate Dienste aufgeteilt.
Die Grundidee besteht darin, dass alle Konnektoren zu Sites dieselbe API haben und Adapter sind, die die Site-API auf eine für uns bequeme Schnittstelle bringen.
Im Zentrum unseres Produkts steht eine Webanwendung, also ein Monolith, der so konzipiert ist, dass er sich leicht in Dienste zerlegen lässt. Diese Anwendung ist für die Verarbeitung der heruntergeladenen Daten, die Zusammenstellung von Statistiken aus verschiedenen Systemen und deren Präsentation für Systembenutzer verantwortlich.
Um zwischen den Konnektoren und der Webanwendung zu kommunizieren, mussten wir einen zusätzlichen Dienst erstellen, den wir Connector Proxy nannten. Es führt die Funktionen der Serviceerkennung und des Taskplaners aus. Dieser Dienst führt jede Nacht Datenerfassungsaufgaben für jeden Connector aus. Das Schreiben einer Serviceschicht war einfacher als das Anschließen eines Nachrichtenbrokers, und für uns war es wichtig, das Ergebnis so schnell wie möglich zu erhalten.
Aus Gründen der Einfachheit und Geschwindigkeit der Entwicklung haben wir außerdem beschlossen, dass alle Dienste Web-APIs sein werden. Dadurch war es möglich, schnell einen Proof-of-Concept zu erstellen und zu überprüfen, ob das gesamte Design funktioniert.
Eine separate, recht komplexe Aufgabe bestand darin, den Zugang zum Sammeln von Daten aus verschiedenen Konten einzurichten, was, wie wir entschieden haben, von den Benutzern über die Weboberfläche durchgeführt werden sollte. Es besteht aus zwei separaten Schritten: Zuerst fügt der Benutzer ein Token hinzu, um über OAuth auf das Konto zuzugreifen, und konfiguriert dann die Datenerfassung für den Client von einem bestimmten Konto. Der Erhalt eines Tokens über OAuth ist notwendig, da es, wie wir bereits geschrieben haben, nicht immer möglich ist, den Zugriff auf das gewünschte Konto auf der Website zu delegieren.
Um einen universellen Mechanismus zum Auswählen eines Kontos aus Websites zu erstellen, mussten wir der Connectors-API eine Methode hinzufügen, die ein JSON-Schema zurückgibt, das mithilfe einer modifizierten JSONEditor-Komponente in ein Formular gerendert wird. Auf diese Weise konnten Benutzer die Konten auswählen, von denen sie Daten herunterladen wollten.
Um die auf Websites geltenden Anforderungslimits einzuhalten, fassen wir Einstellungsanfragen innerhalb eines Tokens zusammen, können jedoch verschiedene Token parallel verarbeiten.
Wir haben MongoDB als Speicher für geladene Daten sowohl für die Webanwendung als auch für die Konnektoren ausgewählt, sodass wir uns in der Anfangsphase der Entwicklung, wenn sich das Objektmodell der Anwendung jeden zweiten Tag ändert, nicht zu viele Gedanken über die Datenstruktur machen mussten.
Wir stellten schnell fest, dass nicht alle Daten gut in MongoDB passen und es beispielsweise bequemer ist, tägliche Statistiken in einer relationalen Datenbank zu speichern. Daher haben wir für Konnektoren, deren Datenstruktur besser für eine relationale Datenbank geeignet ist, begonnen, PostgreSQL oder MS SQL Server als Speicher zu verwenden.
Die gewählte Architektur und Technologie ermöglichte es uns, das Produkt D1.Digital relativ schnell zu entwickeln und auf den Markt zu bringen. Im Laufe von zwei Jahren Produktentwicklung haben wir 23 Konnektoren zu Websites entwickelt, unschätzbare Erfahrungen bei der Arbeit mit APIs von Drittanbietern gesammelt, gelernt, die Fallstricke verschiedener Websites zu vermeiden, von denen jede ihre eigenen hatte, und zur Entwicklung der API von mindestens 3 beigetragen Websites, automatisch Informationen zu fast 15 Kampagnen und für mehr als 000 Platzierungen heruntergeladen, zahlreiche Rückmeldungen von Benutzern zur Funktionsweise des Produkts gesammelt und es auf der Grundlage dieser Rückmeldungen geschafft, den Hauptprozess des Produkts mehrmals zu ändern.
Lösungsarchitektur 2.0
Seit Beginn der Entwicklung sind zwei Jahre vergangen D1.Digital. Die stetig steigende Systemlast und das Aufkommen immer neuer Datenquellen offenbarten nach und nach Probleme in der bestehenden Lösungsarchitektur.
Das erste Problem hängt mit der Menge der von den Websites heruntergeladenen Daten zusammen. Wir waren mit der Tatsache konfrontiert, dass das Sammeln und Aktualisieren aller erforderlichen Daten auf den größten Websites zu viel Zeit in Anspruch nahm. Das Sammeln von Daten aus dem Adserving-System AdRiver, mit dem wir Statistiken für die meisten Platzierungen erfassen, dauert beispielsweise etwa 12 Stunden.
Um dieses Problem zu lösen, haben wir begonnen, alle Arten von Berichten zum Herunterladen von Daten von Websites zu verwenden. Wir versuchen, deren API zusammen mit den Websites zu entwickeln, damit die Betriebsgeschwindigkeit unseren Anforderungen entspricht, und den Datendownload so weit wie möglich zu parallelisieren.
Ein weiteres Problem betrifft die Verarbeitung heruntergeladener Daten. Wenn nun neue Platzierungsstatistiken eintreffen, wird ein mehrstufiger Prozess zur Neuberechnung der Metriken gestartet, der das Laden von Rohdaten, die Berechnung aggregierter Metriken für jede Website, den Vergleich von Daten aus verschiedenen Quellen miteinander und die Berechnung zusammenfassender Metriken für die Kampagne umfasst. Dies führt zu einer hohen Belastung der Webanwendung, die alle Berechnungen durchführt. Während des Neuberechnungsprozesses verbrauchte die Anwendung mehrmals den gesamten Speicher auf dem Server, etwa 10–15 GB, was sich äußerst nachteilig auf die Arbeit der Benutzer mit dem System auswirkte.
Die identifizierten Probleme und ehrgeizigen Pläne für die Weiterentwicklung des Produkts führten uns zu der Notwendigkeit, die Anwendungsarchitektur zu überdenken.
Wir haben mit Steckverbindern begonnen.
Uns ist aufgefallen, dass alle Konnektoren nach dem gleichen Modell funktionieren. Deshalb haben wir ein Pipeline-Framework erstellt, bei dem man zum Erstellen eines Konnektors nur die Logik der Schritte programmieren musste, der Rest war universell. Wenn ein Konnektor verbessert werden muss, übertragen wir ihn sofort in ein neues Framework, während der Konnektor verbessert wird.
Gleichzeitig haben wir mit der Bereitstellung von Konnektoren für Docker und Kubernetes begonnen.
Wir haben die Umstellung auf Kubernetes schon lange geplant, mit CI/CD-Einstellungen experimentiert, aber erst mit der Umstellung begonnen, als ein Connector aufgrund eines Fehlers anfing, mehr als 20 GB Speicher auf dem Server zu verbrauchen, was andere Prozesse praktisch zum Erliegen brachte . Im Zuge der Untersuchung wurde der Connector in einen Kubernetes-Cluster verschoben, wo er letztlich auch nach Behebung des Fehlers verblieb.
Wir stellten schnell fest, dass Kubernetes praktisch ist, und übertrugen innerhalb von sechs Monaten sieben Connectors und Connectors Proxy, die die meisten Ressourcen verbrauchen, in den Produktionscluster.
Im Anschluss an die Konnektoren haben wir beschlossen, die Architektur der restlichen Anwendung zu ändern.
Das Hauptproblem bestand darin, dass Daten in großen Mengen von Konnektoren zu Proxys gelangen, dann auf die DANBoID treffen und zur Verarbeitung an die zentrale Webanwendung gesendet werden. Aufgrund der großen Anzahl von Metrik-Neuberechnungen entsteht eine große Belastung für die Anwendung.
Es erwies sich auch als recht schwierig, den Status einzelner Datenerfassungsjobs zu überwachen und innerhalb von Connectors auftretende Fehler an eine zentrale Webanwendung zu melden, damit Benutzer sehen konnten, was passierte und warum keine Daten erfasst wurden.
Um diese Probleme zu lösen, haben wir die Architektur 2.0 entwickelt.
Der Hauptunterschied zwischen der neuen Version der Architektur besteht darin, dass wir anstelle der Web-API RabbitMQ und die MassTransit-Bibliothek verwenden, um Nachrichten zwischen Diensten auszutauschen. Dazu mussten wir Connectors Proxy fast vollständig neu schreiben und daraus Connectors Hub machen. Der Name wurde geändert, da die Hauptaufgabe des Dienstes nicht mehr darin besteht, Anfragen an Connectors und zurück weiterzuleiten, sondern darin, die Sammlung von Metriken von Connectors zu verwalten.
Von der zentralen Webanwendung aus haben wir Informationen zu Platzierungen und Statistiken von Websites in separate Dienste getrennt, was es ermöglichte, unnötige Neuberechnungen zu vermeiden und nur bereits berechnete und aggregierte Statistiken auf Platzierungsebene zu speichern. Außerdem haben wir die Logik zur Berechnung grundlegender Statistiken auf Basis von Rohdaten neu geschrieben und optimiert.
Gleichzeitig migrieren wir alle Dienste und Anwendungen auf Docker und Kubernetes, um die Lösung einfacher skalierbar und komfortabler zu verwalten.
Wo sind wir jetzt
Proof-of-Concept-Architektur 2.0-Produkt D1.Digital Bereit und funktionsfähig in einer Testumgebung mit einer begrenzten Anzahl von Konnektoren. Jetzt müssen Sie nur noch weitere 20 Konnektoren für eine neue Plattform umschreiben, testen, ob die Daten korrekt geladen und alle Metriken korrekt berechnet wurden, und das gesamte Design in die Produktion einführen.
Tatsächlich wird dieser Prozess schrittweise erfolgen und wir müssen die Abwärtskompatibilität mit alten APIs verlassen, damit alles funktioniert.
Zu unseren unmittelbaren Plänen gehören die Entwicklung neuer Konnektoren, die Integration mit neuen Systemen und das Hinzufügen zusätzlicher Metriken zu den von verbundenen Websites und Anzeigensystemen heruntergeladenen Daten.
Wir planen außerdem, alle Anwendungen, einschließlich der zentralen Webanwendung, auf Docker und Kubernetes zu übertragen. In Kombination mit der neuen Architektur wird dies die Bereitstellung, Überwachung und Kontrolle der verbrauchten Ressourcen erheblich vereinfachen.
Eine andere Idee besteht darin, mit der Wahl der Datenbank zum Speichern von Statistiken zu experimentieren, die derzeit in MongoDB gespeichert ist. Wir haben bereits mehrere neue Konnektoren auf SQL-Datenbanken übertragen, dort ist der Unterschied jedoch kaum spürbar, und bei aggregierten Statistiken pro Tag, die für einen beliebigen Zeitraum angefordert werden können, kann der Gewinn durchaus gravierend sein.
Im Allgemeinen sind die Pläne grandios, lasst uns weitermachen :)
Autoren des Artikels R&D Dentsu Aegis Network Russia: Georgy Ostapenko (), Michail Kotsik ()
Source: habr.com