Migration einer hochbelasteten Suchinfrastruktur von Elastic Cloud zu OpenSearch Serverless
(Wenn Sie Videoinhalte bevorzugen, sehen Sie sich bitte die kurze Videozusammenfassung dieses Artikels unten an.)
Key Takeaways
- Mehr als 100 Millionen Produktionsdatensätze erfolgreich von Elastic Cloud zu AWS OpenSearch Serverless migriert – ohne Unterbrechung des laufenden Betriebs.
- Eine Dual-Write-Architektur implementiert, die es der Anwendung ermöglichte, jederzeit zwischen den Suchmaschinen zu wechseln, ohne das Risiko eines Datenverlusts.
- Ein eigenes Migrationstool mit automatischen Wiederholungsversuchen und kontrollierter Batch-Verarbeitung entwickelt, um die Auswirkungen auf die Produktion zu minimieren.
- Mehrere Einschränkungen von OpenSearch Serverless gelöst, darunter die fehlende Unterstützung von Aliases sowie Performance-Engpässe aufgrund einer ungleichmäßigen Verteilung der Indizes.
Die Migration einer unternehmenskritischen Live-Suchplattform besteht nie nur darin, Daten von einem System in ein anderes zu kopieren. Es bedeutet, den Produktionsbetrieb vollständig aufrechtzuerhalten, während sich täglich Millionen von Datensätzen weiter verändern.
Genau vor dieser Herausforderung stand unser Kunde, als er sich dafür entschied, Elastic Cloud durch AWS OpenSearch Serverless zu ersetzen.
Der Wechsel bedeutete eine grundlegende Umstellung von einem knotenbasierten, lizenzbeschränkten Ökosystem auf eine vollständig serverlose Open-Source-Architektur. Das Projekt erforderte die Migration eines umfangreichen Produktionsdatensatzes, die Anpassung der Anwendung an eine andere Suchmaschinenarchitektur und die Sicherstellung, dass die Nutzer während der gesamten Migration keinerlei Ausfallzeiten bemerkten.
Diese Fallstudie zeigt, wie die Ingenieure von SaM Solutions eine Zero-Downtime-Migrationsstrategie für ein stark frequentiertes Kundensupport-Ticketing-System umgesetzt und mehrere technische Herausforderungen bewältigt haben, die speziell bei OpenSearch Serverless auftreten.
Die geschäftlichen Anforderungen
Unser Kunde bietet eine umfassende Ticketing-Plattform an, die Unternehmen zur Verwaltung von Kundensupport-Anfragen, Wissensdatenbanken und internen Wikis nutzen.
Die Suchfunktion der Plattform basierte auf der Suchmaschine Elastic Cloud. Die bestehende Konfiguration sah wie folgt aus:
- Mehr als 10 logische Indizes für mehrere unterstützte Sprachen, was zu mehr als 25 physischen Indizes führte.
- Im Laufe der Zeit wuchsen diese Indizes in der Produktion auf etwa 100 Millionen Datensätze an.
- Strenge Anforderungen an die Mandantenfähigkeit: Um Datenlecks zwischen verschiedenen Enterprise-Konten zu verhindern, setzte die Architektur eine komplexe Datenfilterung über Elastic-Index-Aliases durch, sodass Nutzer nur die Datensätze sehen konnten, für die ihre jeweilige Organisation autorisiert war.
Um die Betriebsausgaben und Infrastrukturkosten zu optimieren, entschied sich der Kunde für die Migration zu AWS OpenSearch Serverless. Als aktive B2B-SaaS-Plattform kam ein Ausfall jedoch nicht infrage. Da kontinuierlich neue Tickets und Wissensdatenbank-Einträge erstellt, aktualisiert und gelöscht wurden, benötigte der Kunde eine Lösung, die beide Suchplattformen bis zum finalen Cutover synchron halten würde.
Projektumsetzung
Die zentrale Vorgabe für die Experten von SaM Solutions war klar: Live-Produktionsdaten zu migrieren und gleichzeitig die Möglichkeit zu gewährleisten, jederzeit zwischen den beiden Systemen wechseln zu können – ohne Datenverlust oder Unterbrechung für die Nutzer.
Aufbau einer Zero-Downtime-Migrationsstrategie
Eine Live-Migration in einem System mit aktiven Nutzern bedeutet, dass sich das Datenziel ständig verändert. Die Umstellung musste daher nahtlose Rollback-Möglichkeiten in jeder Phase unterstützen, ohne während des Migrationszeitraums erstellte Datensätze zu verlieren.
Um dies zu erreichen, setzten die Ingenieure von SaM Solutions auf Dual-Writing über AWS Lambda. Die Plattform des Kunden verfügte bereits über AWS-Lambda-Funktionen zur Indexierung von Daten. Allerdings gab es eine eigens entwickelte interne Bibliothek, die das Schreiben ausschließlich in Elastic Cloud unterstützte. Unsere Experten passten diese Bibliothek so an, dass sie parallele Dual-Writes ausführen konnte und eingehende Live-Daten abhängig von der Konfiguration gleichzeitig direkt an Elastic Cloud und AWS OpenSearch Serverless weiterleitete.
Dadurch war jedes neu erstellte oder aktualisierte Dokument sofort in beiden Systemen verfügbar. Somit enthielten beide Suchmaschinen stets die aktuellste Version jedes Dokuments. Selbst wenn ein Datensatz bereits migriert und anschließend aktualisiert wurde, wurde die Änderung sofort in beide Systeme repliziert. Dadurch wurde das Risiko von Dateninkonsistenzen während des gesamten Migrationsprozesses ausgeschlossen.
Dieser Dual-Write-Ansatz ermöglichte es den Ingenieuren, bei Bedarf jederzeit zwischen den Suchmaschinen zu wechseln oder bei unerwarteten Problemen sogar ein Rollback durchzuführen, ohne dabei neu erzeugte Daten zu verlieren.
Migration historischer Daten
Nachdem die Live-Änderungen abgedeckt waren, musste unser Team die umfangreichen historischen Daten übertragen (mehr als 100 Millionen Produktionsdatensätze).
Dafür entwickelten unsere Experten ein eigenes Migrationstool auf Basis von Hangfire, das die Dokumente in Batches von jeweils 2.500 Datensätzen verarbeitete. Größere Batches führten zu einer Drosselung durch OpenSearch Serverless, sodass kleinere, kontrollierte Batches das optimale Gleichgewicht zwischen Durchsatz und Stabilität darstellten.
Die Migration wurde an Wochenenden durchgeführt, um die Belastung der Produktion zu minimieren. Unser Team erstellte für jeden Index einen eigenen Migrationsjob, sodass mehrere Indizes parallel migriert werden konnten. Dadurch ließ sich die Gesamtdauer der Migration deutlich reduzieren. Automatische Retry-Mechanismen fingen temporäre Fehler ab und stellten sicher, dass vorübergehende Infrastrukturprobleme den Migrationsprozess nicht unterbrachen.
Überprüfung der Datenintegrität
Der Abschluss der Migration war nur ein Teil der Aufgabe. Das Team musste außerdem sicherstellen, dass jedes Dokument korrekt übertragen worden war.
Dazu wurden zufällig ausgewählte Produktionsdatensätze, die in der vorherigen Woche erstellt worden waren, stichprobenartig überprüft und zwischen Elastic Cloud und OpenSearch Serverless verglichen. Zusätzlich entwickelte das Team eine Reihe von Integrationstests, die identische Suchanfragen gegen beide Plattformen ausführten und die zurückgegebenen Ergebnisse automatisch miteinander verglichen.
Die Validierung erfolgte in zwei Modi. Im ersten wurden die Ergebnisse anhand ihrer Position verglichen, um zu überprüfen, ob beide Suchmaschinen die Dokumente exakt in derselben Reihenfolge zurückgaben. Wenn Elastic Cloud beispielsweise die Datensätze James, Jannet und Jordan zurückgab, während OpenSearch Serverless Jannet, Jordan und James lieferte, wurde der Test als nicht bestanden gewertet, obwohl dieselben Dokumente vorhanden waren.
Im zweiten Modus wurde die Reihenfolge der Ergebnisse ignoriert und ausschließlich die zurückgegebenen Datensätze verglichen. In diesem Fall war der Test erfolgreich, solange beide Systeme dieselben Dokumente zurückgaben – unabhängig von deren Ranking.
Durch die Kombination dieser Prüfungen konnte das Team tatsächliche Datenabweichungen von erwarteten Unterschieden im Suchranking unterscheiden und bestätigen, dass die migrierten Daten vor dem finalen Cutover vollständig und konsistent waren.
Um die Migrationsrisiken weiter zu reduzieren, wurden zwei dedizierte Testumgebungen eingerichtet. QA-Ingenieure konnten identische Suchszenarien gegen beide Suchmaschinen ausführen und die Ergebnisse direkt nebeneinander vergleichen.
Technische Herausforderungen bewältigen
Obwohl OpenSearch Serverless erhebliche Vorteile im Betrieb bietet, unterscheidet sich seine Architektur deutlich von Elastic Cloud. Mehrere Herausforderungen bei der Implementierung erforderten individuelle technische Lösungen.
In Elastic Cloud wurde die Mandantenisolation über Index-Aliases mit integrierten Filtern umgesetzt. Dadurch wurde automatisch verhindert, dass mehrere Konten auf die vertraulichen Datensätze der jeweils anderen zugreifen konnten.
AWS OpenSearch Serverless unterstützt diese Funktion nicht. Wäre dieses Problem nicht gelöst worden, hätte das Risiko bestanden, mandantenübergreifende Daten offenzulegen.
Unsere Entwickler gestalteten daher die Schicht zur Generierung von Suchanfragen neu, sodass für jede Anfrage dynamisch entsprechende Filterbedingungen erstellt werden. Auf diese Weise konnten sie das Sicherheitsverhalten herkömmlicher Aliases nachbilden, ohne die Suchperformance zu beeinträchtigen.
Eine weitere Herausforderung trat nach der ersten Migration auf. Ein Produktionsindex enthielt rund 60 Millionen Dokumente, während sich die übrigen Indizes insgesamt auf nur 20–40 Millionen Datensätze verteilten. Diese ungleichmäßige Verteilung führte trotz zusätzlicher, von AWS zugewiesener OpenSearch Compute Units (OCUs) zu Performance-Engpässen. Gleichzeitig war das Anfragevolumen für den größten Index nicht hoch genug, um die automatische Skalierung von AWS auszulösen.
Gemeinsam mit AWS-Ingenieuren prüfte unser Team verschiedene Ansätze zur Optimierung der Performance.
Letztendlich entschied sich das Team dafür, die Sucharchitektur neu zu organisieren und den größten Index in eine separate OpenSearch Collection zu verschieben. Dadurch ergaben sich größere Flexibilität bei der Ressourcenzuweisung und bessere Möglichkeiten zur Skalierung.
Die Änderung erforderte eine weitere kontrollierte Migration, gefolgt von einer erneuten Validierungsrunde und einer manuellen Anpassung der OCUs. Nach diesen Optimierungen erreichte die Suchperformance das erforderliche Produktionsniveau.
Die Migration brachte auch Unterschiede im Verhalten von Elastic Cloud und OpenSearch Serverless zutage. Ein Beispiel dafür waren besonders lange Suchanfragen.
Im Gegensatz zu Elastic Cloud setzt OpenSearch Serverless strengere Grenzen für die Größe von Suchanfragen, sodass bestimmte komplexe Anfragen die unterstützten Grenzwerte überschreiten konnten. Um diese Einschränkungen zu bewältigen, waren zusätzliche Optimierungen der Suchanfragen erforderlich. Weitere Verbesserungen sind geplant, während sich die Plattform kontinuierlich weiterentwickelt.
Ergebnisse
Die Migration wurde erfolgreich abgeschlossen – ohne Ausfallzeiten in der Produktion und ohne Datenverlust.
Im Verlauf des Projekts:
- Mehr als 100 Millionen Produktionsdatensätze wurden sicher migriert.
- Die Indexierung in der Produktion lief dank des Dual-Write-Synchronisierungsmechanismus ohne Unterbrechung weiter.
- Historische Daten wurden übertragen, ohne die Verfügbarkeit des Systems zu beeinträchtigen.
- Eine umfassende Validierung bestätigte die Datenkonsistenz vor dem finalen Cutover.
- Die Suchfunktion wurde trotz der architektonischen Unterschiede vollständig an AWS OpenSearch Serverless angepasst.
Der Kunde war mit den erzielten Ergebnissen rundum zufrieden.
Zusammenfassung
Migrationen von Suchmaschinen in großem Maßstab sind selten unkompliziert, insbesondere wenn Produktionssysteme rund um die Uhr neue Daten verarbeiten.
Dieses Projekt zeigt, dass eine sorgfältige Planung, eine schrittweise Synchronisierung und eine gründliche Validierung die Risiken, die traditionell mit Live-Infrastrukturmigrationen verbunden sind, eliminieren können. Das Team von SaM Solutions migrierte erfolgreich eine geschäftskritische Suchplattform von Elastic Search zu AWS OpenSearch Serverless, ohne den Geschäftsbetrieb zu unterbrechen.
Für die Endnutzer war der Übergang praktisch unsichtbar. Die Plattform blieb während des gesamten Migrationsprozesses vollständig betriebsfähig.
