Adevinta - Cloud-Migration revolutioniert Datenlösung

Wie Adevinta seine Datenlösung mit einer Cloud-Migration revolutioniert hat

Viele Unternehmen haben Schwierigkeiten, in die Cloud zu migrieren. Dies ist oft ein komplexes und invasives Projekt. Adevinta entschied sich, von seiner gut funktionierenden On-Premise-Umgebung zu einer Cloud-Umgebung zu wechseln. Es hat sich gezeigt, dass sich ein solcher Wechsel fast immer lohnt, insbesondere für Unternehmen, die ein hohes Datenaufkommen haben.

Für Anwendungen, die jederzeit verfügbar sein müssen, ist jede Migration eine große Herausforderung. Oft handelt es sich um ein komplexes und spezifisches Projekt. Umgebungen, die im Laufe der Jahre entwickelt und verändert wurden. Backends, APIs, Datenbanken, was auch immer, es wurde hinzugefügt oder aktualisiert. Alles muss perfekt ausgeführt werden, und jeder Fehler kann die Zugänglichkeit gefährden. Das Risiko und die Investition können große Hindernisse darstellen.

Aber die Migration von einer lokalen Umgebung in die Cloud ist in vielerlei Hinsicht sehr vorteilhaft, auch wenn dies nicht immer sofort ersichtlich ist. Selbst wenn die lokale Umgebung weitgehend ausreichend ist. Plötzlich wird es möglich, Dinge hinzuzufügen, die vorher zu teuer und zu komplex waren. Außerdem bietet es mehr Flexibilität und ermöglicht den Zugriff auf Daten auf neue Weise. Vorteile, die erst nach einer Migration wirklich sichtbar werden, aber für jedes zukunftsorientierte Unternehmen von entscheidender Bedeutung sind.

Adevinta, die Muttergesellschaft, zu der Marktplaats.nl und eBay gehören, ist ein gutes Beispiel. Die firmeneigene Hadoop-Umgebung Odin 2 verarbeitet 13.000 Datenereignisse pro Sekunde, was mehr als 1 Milliarde pro Tag entspricht. Das entspricht 2,5 TB zusätzlicher Daten in Google BigQuery pro Tag. Dazu gehören Beiträge und Suchergebnisse von Nutzern über mehrere Plattformen und Marken hinweg. Im Backend werden die Daten vom Produzenten an Apache Kafka gesendet und gehen durch eine von Kafka gesteuerte Apache Flink-Pipeline zum Konsumenten. Und das hat ziemlich gut funktioniert, wie Charlie Evans, Senior Software Engineer bei Adevinta, auf der Club Cloud 2021 im vergangenen November erklärte. "Die Pipeline war in einem guten Zustand", sagt Evans. Das Endprodukt war einfach zu warten und extrem stabil.

Eine gute Umgebung, aber nicht zukunftssicher

Wenn es funktioniert, warum sollte man es ändern? So einfach ist das nicht. Eine der großen Herausforderungen bei On-Premises-Umgebungen besteht darin, dass sie sehr wartungsintensiv sind, während es viel Arbeit macht, sie auf dem neuesten Stand zu halten und neue Funktionen hinzuzufügen. Das Ersetzen von Hardware ist eine große Investition, die auch einmal zu Buche schlägt. Und Adevinta hatte viele Gründe für ein Upgrade.

"Der Datenverbrauch, die Daten aus HDFS und Kafka, stellte uns vor eine Menge Herausforderungen", erklärt Evans. "Was Kafka betrifft, so konnten nur die zentralen Datenteams der verschiedenen Organisationen die Daten nutzen. Auf der HDFS-Seite verwendeten wir außerdem eine etwas veraltete Version von Hadoop, was uns daran hinderte, die neuesten Tools und APIs einzusetzen."

Die Odin 2-Lösung steckte in ihrer lokalen Umgebung fest. Adevinta hatte viele Herausforderungen, wenn es um Verbesserungen und die Implementierung von Erweiterungen ging. Daher wurde die Entscheidung getroffen, die gesamte Umgebung auf die Google Cloud Platform zu migrieren. Dadurch erhält Adevinta mehr Flexibilität und Zugang zu den Tools, die die Cloud-Plattform bieten kann. Auch der Zugriff auf die Daten wird dadurch einfacher.

3 Schritte für eine Cloud-Migration

Schritt 1: Stellen Sie eine geeignete Architektur bereit

Eine der ersten Chancen, die eine Migration bietet, ist die Möglichkeit, die gesamte Architektur unter die Lupe zu nehmen. Jetzt gab es die Möglichkeit, die Architektur einheitlicher zu gestalten. Evans sagt, die Produzenten könnten an den Proxy publizieren, aber auch direkt an Kafka.

"Wenn Sie diese beiden Endpunktschnittstellen in der Pipeline haben, kommt es zu Reibungsverlusten, weil Sie dann zwei Möglichkeiten zur Authentifizierung haben. Das bietet auch die Möglichkeit, die Apache Flink-Pipeline zu vereinfachen."

Eine solche Vereinfachung ist bei der Migration in die Cloud von entscheidender Bedeutung, da das Kostenmodell anders ist. Da die Nutzung bezahlt wird, können doppelte Operationen zusätzliche Kosten verursachen, erklärt Diederik Greveling, CTO bei GoDataDriven Solutions. Ein CAPEX-Modell wird gegen ein OPEX-Modell ausgetauscht, so dass das Unternehmen die tatsächliche Nutzung kennen muss. "Die Flink-Pipeline enthält zum Beispiel eine Bot-Erkennung", sagt er.

"Für On-Premises macht die Bot-Erkennung in Flink sehr viel Sinn. Aber wir haben das in die BigQuery-Schreiblogik verlagert. Und warum? Weil wir dann nur einmal aus dem Abonnement lesen müssen, und das ist natürlich billiger.

Bei der Migration in die Cloud müssen Sie an die Kosten denken." Bei der Größenordnung, in der Adevinta arbeitet, spart das schnell Zehntausende von Euro.

Schritt 2: Implementierung und Optimierung der Cloud-Infrastruktur

Die Daten wurden von On-Prem gespiegelt, um die Cloud-Implementierung mit dem vollen Datenvolumen zu testen. Die Cloud-Implementierung in DataFlow erwies sich jedoch als suboptimal, u.a. weil sie zwei Dinge gleichzeitig tat: Sie schrieb die Daten von Pub/Sub in BigQuery, führte aber auch die Bot-Erkennung durch. "Das hat andere Teile der Pipeline beeinträchtigt", sagt Evans. "Die Bot-Erkennung ist wichtig, aber sie ist eher ein Best Effort.

Aber das Hauptziel ist es, die Daten in BigQuery zu erhalten. Das sollte nicht durch etwas weniger Wichtiges beeinträchtigt werden. Die Trennung der beiden hat zu einer großen Verbesserung geführt."

Da die Architektur verbessert wird, kann eine Migration länger dauern als ursprünglich angenommen. Aber in den meisten Fällen ist es das wert.

Schritt 3: Suchen Sie nach den kleinen Vorteilen

Greveling zufolge ist das alles ähnlich wie bei der Entwicklung vor Ort. Aber wenn es erst einmal funktioniert, merkt er an, dass man viel Zeit spart, weil die Cloud-Umgebung teilweise oder sogar vollständig verwaltet wird. Darüber hinaus gibt es viele kleine Vorteile, die in der Summe einen großen Unterschied ausmachen können. "Der Odin-Kollektor zum Beispiel, über den die Mieter ihre Nachrichten senden, scheint bei Cloud Run gut zu funktionieren", erwähnt Greveling. "Und ich sollte hinzufügen, dass er sogar noch vorteilhafter geworden ist. Seit kurzem muss man nicht mehr pro Anfrage, sondern pro CPU-Zuweisung bezahlen. Dadurch konnten diese Kosten auf ein Zehntel reduziert werden."

Eine Erweiterung oder sogar Duplizierung der Umgebung ist von da an ebenfalls sehr einfach, erklärt Greveling. "Wir hatten einen Mieter in Australien, während sich unsere Infrastruktur in Westeuropa befindet", sagt er. "Es kam die Anfrage, ob wir nicht auch etwas in Australien zur Verfügung stellen könnten, um zum Beispiel die Latenzzeit und die Transferkosten zu reduzieren. Dafür haben wir vielleicht ein paar Stunden gebraucht. Wenn man es einmal geschafft hat, kann man viel einfacher skalieren."