Migration von Ubers Ledger-Daten von DynamoDB zu LedgerStore

• Letzte Woche wurde LedgerStore (LSG) untersucht, Ubers zusätzlicher dedizierter Ledger-Datenbank im Ledger-Stil.
• Diese Woche geht es darum, wie Uber geschäftskritische Ledger-Daten zu LSG migriert hat.
• Es wird besprochen, wie mehr als 1 Billion Einträge (mehrere Petabyte an Daten) transparent und ohne Unterbrechung verschoben wurden und was dabei gelernt wurde.

Historie

• Gulfstream ist Ubers Zahlungsplattform und wurde 2017 mit DynamoDB eingeführt.
• In Ubers Größenordnung wurde DynamoDB teuer, daher wurden nur 12 Wochen an Daten (Hot Data) in DynamoDB gespeichert und ältere Daten (Cold Data) in Ubers Blobstore TerraBlob abgelegt.
• Als langfristige Lösung war LSG vorgesehen. LSG wurde speziell für die Speicherung von zahlungsähnlichen Daten entwickelt.
• Wichtige Funktionen von LSG:
  • Verifizierbare Unveränderlichkeit (mithilfe kryptografischer Signaturen kann geprüft werden, dass Datensätze nicht verändert wurden)
  • Tiered Storage zur Kostenkontrolle (Hot Data an einem Ort, der gut für die Verarbeitung von Anfragen geeignet ist, Cold Data an einem Ort, der für Speicherung optimiert ist)
  • Verbesserte Latenz bei letztlich konsistenten Sekundärindizes
• Bis 2021 nutzte Gulfstream eine Kombination aus DynamoDB, TerraBlob und LSG zur Datenspeicherung.
  • DynamoDB: Daten der letzten 12 Wochen
  • TerraBlob: Cold Data
  • LSG: Zielsystem, in das Daten geschrieben wurden und in das migriert werden sollte

Warum musste migriert werden?

• LSG eignet sich wegen seiner Unveränderlichkeit besser zur Speicherung von Ledger-Daten.
• Der Umzug zu LSG brachte erhebliche wiederkehrende Kosteneinsparungen.
• Der Wechsel von drei Speichersystemen zu einem einzigen vereinfachte Code und Architektur des Gulfstream-Services.
• LSG versprach kürzere Indexierungsverzögerungen und bot dank On-Premises-Betrieb in Ubers Rechenzentren geringere Netzwerklatenzen.

Risiken im Zusammenhang mit den Eigenschaften der Daten

• Die zu migrierenden Daten umfassen alle geschäftlichen Ledger-Daten von Uber seit 2017:
  • Unveränderliche Datensätze: 1,2 PB komprimiert
  • Sekundärindizes: 0,5 PB unkomprimiert
• Die unveränderlichen Datensätze können nicht geändert werden, während bei den Sekundärindexdaten die Flexibilität besteht, Korrekturen vorzunehmen.

Validierung

• Um sicherzustellen, dass das Backfill in jeder Hinsicht korrekt und akzeptabel ist, musste geprüft werden, ob aktueller Traffic verarbeitet werden kann und ob derzeit nicht abgerufene Daten korrekt sind.
• Validierungskriterien:
  • Vollständigkeit: Wurden alle Datensätze per Backfill übertragen?
  • Korrektheit: Sind alle Datensätze korrekt?
  • Last: Kann LSG die aktuelle Last verarbeiten?
  • Latenz: Liegt die P99-Latenz von LSG im akzeptablen Bereich?
  • Verzögerung: Liegt die Erzeugungsverzögerung der Sekundärindizes im akzeptablen Bereich?

Shadow Validation

• Durch den Vergleich der Antworten vor und nach der Migration wurde sichergestellt, dass aktueller Traffic nicht durch Probleme bei der Datenmigration oder Bugs im Code beeinträchtigt wurde.
• Mit Shadow Validation wurde bestätigt, dass das Backfill mindestens zu 99,99 % vollständig und korrekt war; die Obergrenze wurde auf 99,9999 % gesetzt.
• Shadow Validation bestätigte, dass LSG produktiven Traffic verarbeiten kann, und stärkte das Vertrauen in den Datenzugriffscode.
• Shadow Validation lieferte Vertrauen in die Vollständigkeit und Korrektheit der aktuell genutzten Daten.

Offline-Validierung und inkrementelles Backfill

• Die gesamten Daten in LSG wurden mit einem Daten-Dump aus DynamoDB verglichen.
• Die Offline-Validierung überprüfte, ob das Daten-Backfill korrekt durchgeführt wurde, und deckte den gesamten Datenbestand ab.
• Die Offline-Validierung sollte zusammen mit der Shadow Validation durchgeführt werden.

Backfill-Probleme

• Jedes Backfill ist riskant. Für das Backfill wurde Ubers Apache Spark verwendet.
• Ansätze zur Problemlösung:
  • Skalierbarkeit: Im kleinen Maßstab beginnen und schrittweise ausweiten.
  • Inkrementelles Backfill: Daten in kleine Batches aufteilen und schrittweise übertragen.
  • Geschwindigkeitssteuerung: Die Rate der Backfill-Jobs regulieren.
  • Dynamische Geschwindigkeitssteuerung: Die Rate anhand des aktuellen Systemzustands anpassen.
  • Not-Aus: Eine Funktion bereitstellen, mit der das Backfill bei Verdacht auf Überlast schnell gestoppt werden kann.
  • Größe der Datendateien: Die Größe der Daten-Dump-Dateien angemessen halten.
  • Fehlertoleranz: Probleme bei Datenqualität oder -beschädigung behandeln.
  • Logging: Logs begrenzen, damit die Logging-Infrastruktur nicht überlastet wird.

Risikominderung

• Verschiedene Validierungs- und Backfill-Statistiken wurden analysiert, und das Rollout von LSG wurde konservativ vorangetrieben.
• Anfangs wurde ein Fallback genutzt, der Daten aus DynamoDB holte, falls das Backfill fehlschlug.
• Durch Prüfung der Fallback-Logs wurde sichergestellt, dass in LSG tatsächlich keine Daten fehlten.

Fazit

• Dieser Artikel behandelt den Prozess der Migration großvolumiger geschäftskritischer Ledger-Daten von einem Datenspeicher in einen anderen.
• Behandelt wurden verschiedene Aspekte wie Migrationskriterien, Validierung, Backfill-Probleme und Sicherheit.
• Die Migration wurde über zwei Jahre hinweg ohne Unterbrechungen oder Ausfälle abgeschlossen.

Meinung von GN⁺

• Bedeutung der Datenmigration: Große Datenmigrationen sind komplex und riskant, bieten aber langfristig erhebliche Vorteile durch Kostensenkung und Vereinfachung des Systems.
• Nutzen von Shadow Validation: Shadow Validation ist ein leistungsfähiges Werkzeug, um Vollständigkeit und Korrektheit von Daten zu prüfen, ohne den realen Traffic zu beeinflussen.
• Notwendigkeit der Offline-Validierung: Offline-Validierung ist ebenfalls unverzichtbar, da sie Probleme aufdecken kann, die allein durch Shadow Validation nicht sichtbar werden.
• Schrittweiser Ansatz beim Backfill: Backfill-Arbeiten in kleine Batches aufzuteilen und schrittweise auszuführen, ist wirksam, um eine Überlastung des Systems zu vermeiden.
• Not-Aus-Funktion: Eine Funktion, mit der Backfill-Arbeiten bei Problemen schnell gestoppt werden können, ist wichtig, um die Systemstabilität zu erhalten.

[GN⁺]

Hacker-News-Meinung

Zusammenfassung der Hacker-News-Kommentare

• 2 Milliarden Fahrten pro Quartal

  • Uber verarbeitet pro Quartal 2 Milliarden Fahrten. Das entspricht umgerechnet etwa 1000 Transaktionen pro Sekunde. Es ist schwer nachzuvollziehen, warum man sich so stark auf die Skalierung der Infrastruktur konzentriert.

• DynamoDB schlecht genutzt

  • Uber hat DynamoDB schlecht genutzt. Für bestimmte kritische User Journeys (CUJ) ist starke Konsistenz erforderlich, und für historische Transaktionen wird Data Warehousing benötigt. Es ist seltsam, dass man nicht auf eine DynamoDB-und-Redshift-Architektur umgestellt hat.

• Google lehnt ab

  • Es wirkt, als hätte Uber ein bei Google gescheitertes Projekt übernommen. Solche Projekte zielen oft auf eine große Beförderung ab. Nach dem Muster: „$Xm durch Entwurf und Bau eines eigenen Systems eingespart! Bitte befördert mich!“ Aber die Baukosten sind höher, und in ein paar Jahren wird es wahrscheinlich wieder eingestellt.

• SQLite auf einem einzelnen Server

  • Jemand fragt sich, ob sich 1,7 Petabyte an Daten (1 Billion indexierte Datensätze) mit SQLite auf einem einzigen leistungsstarken Bare-Metal-Server speichern ließen. Ein Beispiellink wird genannt.

• LedgerStore ist nicht Open Source

  • LedgerStore ist nicht Open Source. Um Informationen dazu zu finden, muss man den Verweisen in Uber-Blogposts folgen. Ein Link zu einem Beitrag von 2021 wird genannt.

• Ära der maßgeschneiderten Infrastruktur

  • Um 2015 herum haben viele Technologieunternehmen wie Netflix, Spotify, SoundCloud und Uber zahlreiche Infrastruktur- und Datenbanktools selbst gebaut. Heute sprechen viele Engineers eher in AWS-/Cloud-Begriffen. Es ist trotzdem erfrischend, noch Organisationen zu sehen, die eigene Tools bauen.

• Teure proprietäre Cloud

  • Das ist ein gutes Beispiel dafür, wie teuer proprietäre cloudbasierte Datenspeicher sein können. Eine Migration auf etwas anderes ist möglich.

• TigerBeetle in Betracht gezogen?

  • Es wird gefragt, ob TigerBeetle in Betracht gezogen wurde.

• DynamoDB ist teuer

  • Auch wenn unklar ist, ob sich dieses Projekt wirtschaftlich lohnt, ist DynamoDB wirklich teuer. Man dachte vielleicht, andere würden es nur falsch einsetzen, aber selbst bei der Nutzung als verteilte Hash-Tabelle entstehen weiterhin hohe Kosten.

• Kosten für den Betrieb des Teams

  • Die Kosten für den Betrieb des Projektteams dürften sich kaum von den Einsparungen (6 Millionen Dollar) unterscheiden. Hinzu kommen Wartungskosten. Ein Zahlungssystem ist möglicherweise keine langfristige Wette. Es ist interessant, warum man ein solches Projekt überhaupt startet. Vielleicht hängt es mit versunkenen Kosten rund um ein bereits bestehendes Engineering-Team zusammen.