Home
Portfolio
AWS-zu-AWS-Migration für einen Verkehrsintelligenz-Anbieter

AWS-zu-AWS-Migration für einen Verkehrsintelligenz-Anbieter

Der Kunde benötigte eine schnelle Migration seines Produkt-Ökosystems in eine neue AWS-Organisation. Itransition migrierte die komplexe Infrastruktur des Kunden und stellte dabei Geschäftskontinuität sowie Datenkonsistenz sicher.

Keine

Ausfallzeiten

100 %

Datenkonsistenz

50 TB

migrierte Daten

AWS-zu-AWS-Migration für einen Verkehrsintelligenz-Anbieter

Alle eingesetzten Technologien

AWS

Terraform

Amazon Athena

Amazon S3

Amazon SQS

RabbitMQ

Amazon API Gateway

Engagement-Modell

Vollständiges Projekt-Outsourcing

Über den Kunden

Der Kunde ist ein in der EMEA-Region ansässiger Daten- und Analyseanbieter und spezialisiert sich auf betriebliche und marktbezogene Einblicke für die globale Logistik und den Transport. Seine Lösungen unterstützen die betriebliche Transparenz, optimieren Logistikabläufe und liefern Analysen der Transportaktivitäten in der Branche.

Unternehmensform

Privat

Branche

Informationsdienste, Daten & Analytics

Geografie

EMEA

Spezialisierung

Logistik- und Transportintelligenz

Die Herausforderung

Im Rahmen einer Unternehmensumstrukturierung musste der Kunde seine Produkte in eine neue AWS-Organisation migrieren. Die Herausforderung bestand darin, einen reibungslosen und zugleich schnellen Übergang zur neuen Infrastruktur bei minimalen Ausfallzeiten zu ermöglichen und so die Betriebsfähigkeit der Lösung sowie die Geschäftskontinuität sicherzustellen.

Die Lösung

Auf einen Blick

Itransition analysierte die AWS-Infrastruktur des Kunden, wählte den optimalen Migrationsansatz aus und migrierte die Lösung schrittweise, um deren Verfügbarkeit zu gewährleisten und Ausfallzeiten auf ein Minimum zu beschränken.

Vorbereitung

Die bestehende AWS-Infrastruktur des Kunden war komplex und umfasste zahlreiche Produkte – sowohl neue als auch seit Langem betriebene –, die eine große Zahl von Endkunden bedienten. Das gesamte Datenvolumen belief sich auf 50 TB; täglich wurden 1 TB Echtzeitdaten verarbeitet.

Die Hauptmigrationsstrategie war Lift and Shift – die Migration der bestehenden Infrastruktur im Ist-Zustand auf ein anderes AWS-Konto mithilfe der AWS-Tools und ohne nennenswerten Neuentwicklungsaufwand. Auf den Big-Bang-Migrationsansatz – eine einstufige Migration, bei der alle Ressourcen gleichzeitig innerhalb eines bestimmten Zeitfensters umgestellt werden – verzichteten wir, um Risiken durch Dienstunterbrechungen und Dateninkonsistenzen zu verringern, umfangreiche Tests zu vermeiden und Kosten zu senken. Stattdessen entschieden wir uns für eine schrittweise Migration des Produkts. Um Verfügbarkeit und minimale Ausfallzeiten zu gewährleisten, planten wir einen gemischten Betrieb, bei dem Quell- und Zielkonto während der Übergangsphase parallel liefen.

Unser Team unterteilte den gesamten Migrationsumfang in mehrere Stränge. Deren Reihenfolge richtete sich nach dem Datenfluss, da zwischen Teilen der Infrastruktur Abhängigkeiten bestanden. So ließ sich die Infrastruktur in kleineren Schritten migrieren. Neben den Hauptsträngen definierten wir sekundäre Stränge ohne oder mit nur indirekten Abhängigkeiten zur Kernanwendung; ihre Migrationsreihenfolge war nicht kritisch.

Migration

Die Migrationsstränge liefen schrittweise entsprechend den Abhängigkeiten im Datenfluss. Dieser Ansatz war für den parallelen Betrieb zweier Konten (Cross-Account-Modus) am einfachsten und logischsten und erlaubte eine einfachere Wartung der Anwendungen ohne gravierende Änderungen. Einige Dienste blieben auf Quell- und Zielkonto aktiv, bis die Abhängigkeiten zu noch nicht migrierten Komponenten entfielen – auch weil nicht alle Legacy-Anwendungen den Cross-Account-Modus unterstützten.

Die Migration nutzte weitgehend das AWS-Toolset und die AWS-Datenmigrationsdienste. Infrastrukturteile, die bereits über automatisierte Terraform-Skripte abgebildet waren, wurden im neuen AWS-Konto neu erstellt. Für den Großteil der Legacy-Anwendungen erstellten wir Maschinen-Snapshots, übertrugen sie ins Zielkonto und stellten sie betriebsbereit wieder her.

Zu einigen Altsystemen und ihrer Konfiguration lagen keine Informationen vor; eine Migration als Snapshot war daher nicht möglich. Unser Team musste diese Legacy-Anwendungen per Reverse Engineering nachvollziehen und von Grund auf neu konfigurieren. Das Kundenteam lieferte dabei Anleitung, nötige Details und Überprüfungen. Außerdem arbeiteten wir mit weiteren Anbietern zusammen, die Drittanbieterprodukte und zugehörige Lösungen im Ökosystem des Kunden betreuten, und bereiteten die Plattform für deren Deployment vor.

Hauptstränge

Strang 1
Migration der Datenerfassungspipeline. Das SNS-Topic im Zielkonto sendete weiterhin Daten an die SQS-Warteschlangen im Quellkonto, bis diese vollständig migriert waren.
Strang 2
Neuerstellung und Inbetriebnahme einer Datenarchivierungsanwendung sowie der zugehörigen Objektspeicher (Athena, S3) im Zielkonto.
Strang 3
Migration von Legacy-Anwendungen einschließlich zugehöriger SQS-Warteschlangen und der dedizierten Datenbank sowie Anbindung der Anwendungen an die entsprechenden SQS-Warteschlangen im Zielkonto.
Strang 4
Neuerstellung und Start der Knoten für Datenerfassung und Jobplanung (5 EC2-Autoscaling-Gruppen), SQS- und RabbitMQ-Warteschlangen sowie Wiederherstellung des Elasticsearch-Cluster-Backups im Zielkonto.
Strang 5
Erstellung von Snapshots der Aurora- und RDS-Datenbanken und Wiederherstellung dieser Snapshots im Zielkonto.
Strang 6
Neuerstellung der API im Zielkonto. API-Aufrufe liefen über API Gateway; einige Anfragen erfolgten über statische IP-Adressen, weil Endkunden dies aus Sicherheitsgründen wünschten. Für diesen Multi-Region-Fall kombinierten wir Custom DNS mit verschiedenen API-Gateway-Konfigurationen.
Strang 7
Bereitstellung der Weboberfläche im Zielkonto und DNS-Umstellung zum geplanten Termin als abschließender wichtiger Schritt.

Sekundäre Stränge

Strang 1
Erstellung einer Kopie der CI/CD-Pipeline im Zielkonto und schrittweise Umstellung darauf parallel zur Migration der App-Komponenten, die mit den CI/CD-Jobs zusammenhängen.
Strang 2
Migration der Microsites einschließlich der zugehörigen Datenbank.
Strang 3
Migration der Redshift-Datenbank und Wiederherstellung im Zielkonto. Wir wählten den leistungsstärksten Redshift-Cluster-Typ und stellten ihn bereit; die Zielkapazität wurde vorübergehend erhöht, damit die vollständige Datenmigration und -wiederherstellung in wenigen Stunden statt in Tagen erfolgen konnte.
Strang 4
Neuerstellung und Start des Tools zur statischen Datenerfassung im Zielkonto sowie Neukonfiguration für die Arbeit mit der dedizierten Datenbank.
Strang 5
Aufbau der Infrastruktur für eine Predictive-Analytics-Anwendung eines Drittanbieters sowie Erstkonfiguration der Datenbank und der anwendungsbezogenen Infrastrukturteile.

Suchen Sie einen erfahrenen Anbieter für Cloud-Migrationen?

Wir können Ihnen helfen

Das Ergebnis

Itransition migrierte die Infrastruktur des Kunden in die neue AWS-Organisation und stellte während der Übergangsphase eine nahtlose Datensynchronisation zwischen beiden AWS-Konten sicher. So konnte der Kunde den Geschäftsbetrieb ohne Unterbrechung fortführen und die Datenkonsistenz bewahren.