So konnte das ilert-Team eine nahtlose Migration von Community MySQL zu AWS RDS Aurora mit minimalen Auswirkungen auf die Kunden erreichen
Mit dem exponentiellen Wachstum unserer Kundenbasis und den gestiegenen Datenanforderungen wurde es unerlässlich, unsere Datenbankinfrastruktur zu skalieren. Unsere Vision war es, eine aktive-aktive Datenbankarchitektur aufzubauen, die regionale Unabhängigkeit und erstklassige Servicequalität weltweit gewährleistet.
In diesem Artikel geben wir einen detaillierten Überblick darüber, wie unser Team unsere Produktionsdaten mit modernsten Strategien zu AWS RDS Aurora migriert hat, um die Auswirkungen während der Übergangsphase auf ein Minimum zu reduzieren.
Die Herausforderung
Da wir mit unserem bestehenden Community-MySQL-Setup an unsere Grenzen stießen, benötigten wir eine skalierbare Lösung mit hoher Verfügbarkeit, die unsere steigende Datenlast bewältigen und den globalen Datenzugriff verbessern konnte. Unser Ziel war es, eine Aktiv-Aktiv-Konfiguration mit AWS RDS Aurora zu implementieren, um die regionale Unabhängigkeit zu fördern und die globale Servicebereitstellung zu verbessern.
Schritt 1: Strategische Planung vor der Migration
Die Vorbereitung war der erste wichtige Schritt. Unser Team untersuchte das bestehende Datenbanksystem akribisch und zeichnete alle Abhängigkeiten und Spezifikationen auf. Wir erfassten alle Infrastrukturkomponenten mit Terraform, was nicht nur eine leichtere Einrichtung in AWS ermöglichte, sondern auch die Konsistenz in unseren Umgebungen sicherstellte – ein entscheidender Faktor für die Reduzierung potenzieller Fehler während der Migration.
Unser Team führte einen umfassenden Planungsprozess durch, bei dem jeder Aspekt unserer bestehenden Datenbankkonfigurationen und Abfrageanforderungen bewertet wurde. Diese Analyse half uns, die Rechen- und Speicherspezifikationen für unser Aurora-Setup zu definieren.
Schritt 2: Konfiguration von AWS RDS Aurora und Read-Only-Diensten
Wir richteten das AWS RDS Aurora-Cluster ein und stellten sicher, dass es alle unsere Anforderungen an hohe Performance und Zuverlässigkeit erfüllte. Um einen reibungslosen Übergang zu gewährleisten, richteten wir Read-Only-Dienste ein, die mit einer Aurora-Read-Replica verbunden waren. Dieser Schritt war entscheidend, da es unseren Diensten ermöglichte, ohne Unterbrechung im Read-Only-Modus weiterzuarbeiten, während die Hauptdatenbank vorübergehend nicht verfügbar war.
Parallel dazu konfigurierten wir NGINX Ingress in unseren Kubernetes-Clustern, was eine zentrale Rolle bei der Verwaltung des Traffics während der Migration spielte. Durch die Definition spezifischer Regeln im NGINX Ingress leiteten wir den Traffic zwischen unseren normalen und Read-Only-Dienstinstanzen um und stellten die Verfügbarkeit des Services sicher, selbst wenn die Hauptdatenbank in einem kritischen Zustand war.
Hier ist ein Beispiel für die service-a Ingress-Regel:
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
labels:
app: service-a
ingress-class: nginx
name: service-a
namespace: default
spec:
ingressClassName: nginx
rules:
- host: '*.ilert.com'
http:
paths:
- backend:
service:
name: service-a
port:
number: 9999
path: /
pathType: Prefix
tls:
- hosts:
- '*.ilert.com'
Und hier ist ein Beispielskript, um den Traffic zwischen Read-Only- und normalen Instanzen zu verwalten:
# Move traffic to readonly instances
kubectl patch service service-a -p '{"spec":{"selector": {"app": "service-a-readonly"}}}'
# Move traffic to back to write instances
kubectl patch service service-a -p '{"spec":{"selector": {"app": "service-a"}}}'Schritt 3: Zeitliche Planung und Durchführung der Migration
Um die Auswirkungen auf die Kunden zu minimieren, planten wir die Migration zu der Zeit mit dem geringsten Traffic. Der Wechsel in den „Read-Only“-Modus für die Hauptdatenbank dauerte nur 4 Minuten. Während dieses Zeitfensters interagierten unsere Anwendungen nahtlos mit den Read-Only-Diensten, die mit der Aurora-Replica verbunden waren, was die kontinuierliche Verfügbarkeit der Daten für Lesezwecke sicherstellte.
Gleichzeitig haben wir die endgültige Synchronisierung der letzten Datencharge von der MySQL-Datenbank zur Aurora-Datenbank eingeleitet. Am Ende dieses Prozesses wurde das Aurora-Cluster hochgesetzt, um sowohl Lese- als auch Schreiboperationen zu übernehmen.
Schritt 4: Umswitchen mit minimaler Unterbrechung
Nach der erfolgreichen Synchronisierung und Promotion des Aurora-Clusters haben wir den Live-Traffic von den Read-Only-Instanzen zurück zu den normalen Service-Instanzen umgeleitet, die nun auf das neu hochgestufte Aurora-Cluster zeigten. Dieser Wechsel wurde sorgfältig über aktualisierte NGINX Ingress-Regeln abgewickelt, die den gesamten Traffic auf das neue Aurora-Setup umleiteten, das nun in der Lage war, sowohl Lese- als auch Schreiboperationen auszuführen.
Schritt 5: Überwachung und Optimierung nach der Migration
Nach der Migration überwachte unser Team sorgfältig das System, um sicherzustellen, dass es wie erwartet funktionierte. Wir legten besonderes Augenmerk auf Leistungsmetriken wie Abfrageeffizienz, CPU-Auslastung und Speichernutzung. Stetige Optimierungen wurden vorgenommen, um sicherzustellen, dass unsere Abfragen die fortschrittlichen Funktionen von Aurora voll ausschöpfen.
Fazit
Die Migration zu AWS RDS Aurora mit nur einem 4-minütigen Read-Only-Fenster ist ein Beispiel für das Engagement unseres Teams für einen exzellenten IT-Betrieb und minimale Beeinträchtigungen für unsere Kunden. Unsere sorgfältige Vorbereitung, der Einsatz fortschrittlicher Tools wie Terraform und die strategische Durchführung ermöglichten es uns nicht nur, unsere Datenbankleistung zu verbessern, sondern auch unsere globale Infrastruktur so zu gestalten, dass sie unsere Kunden durch eine innovative aktive-aktive Konfiguration besser bedient.
Heute läuft unser Aurora-Datenbank-Cluster erfolgreich in einer active-active Konfiguration über zwei unabhängige Regionen, die sechs Verfügbarkeitszonen umfassen. Diese Konfiguration verbessert nicht nur die Leistung und gewährleistet eine höhere Verfügbarkeit, sondern reduziert auch die Verzögerung für unsere weltweite Kundenbasis.
Mit Blick auf die Zukunft planen wir, unsere Operationen noch weiter zu skalieren und die Widerstandsfähigkeit und Effizienz unserer Infrastruktur zu verbessern. Unser Weg mit AWS Aurora ist ein Beweis für unser fortwährendes Engagement, modernste Technologien zu nutzen, um unseren Kunden den bestmöglichen Service zu bieten.
ilert ist offizieller Partner von AWS und hat die Amazon RDS Ready und Qualified Software Auszeichnung erhalten. ilert bietet direkt einsatzbereite Integrationen mit verschiedenen Amazon-Diensten, die darauf abzielen, Ihre Systeme zu überwachen und Ihr Team zu alarmieren, wenn Anomalien erkannt werden. Arbeiten Sie jetzt mit der Cloud für einen IT-Betrieb auf Top-Niveau mit ilert und AWS.
