- Stripe hielt 2023 eine Verfügbarkeit von 99,999 % aufrecht und verarbeitete dabei ein gesamtes Zahlungsvolumen von 1 Billion US-Dollar
- Das Datenbank-Infrastrukturteam von Stripe stellt mit DocDB eine Database as a Service (DBaaS) als Basisschicht der API bereit
- DocDB ist eine erweiterte Variante von MongoDB Community und besteht aus mehreren intern bei Stripe entwickelten Services
- Es verarbeitet mehr als 5 Millionen Abfragen pro Sekunde und speichert geschäftskritische Finanzdaten im Petabyte-Bereich verteilt über mehr als 2.000 Datenbank-Shards in über 5.000 Collections
- Für MongoDB Community entschied man sich wegen der Flexibilität des Dokumentenmodells und der Fähigkeit zur Echtzeit-Datenverarbeitung im großen Maßstab
- 2011 gab es MongoDB Atlas noch nicht, daher baute Stripe einen selbstverwalteten Cluster von MongoDB-Instanzen auf, der in der Cloud lief
- Das Herzstück von DocDB ist die Data Movement Platform
- Ursprünglich wurde sie als horizontale Skalierungslösung entwickelt, um die Grenzen der vertikalen Skalierung von MongoDB zu überwinden, später aber für verschiedene Zwecke angepasst
- Etwa zum Zusammenlegen wenig genutzter Datenbank-Shards zur besseren Auslastung und Effizienz, für große Upgrades der Datenbank-Engine zur Erhöhung der Zuverlässigkeit oder für den Wechsel großer Nutzer von Multi-Tenant auf Single-Tenant
- Die Data Movement Platform ermöglicht den Übergang von wenigen großen Datenbank-Shards zu vielen kleinen Datenbank-Shards
- Sie bietet zudem für Clients transparente Migrationen und Zero Downtime und ermöglicht damit ein hoch elastisches DBaaS
- DocDB kann bei Verkehrsspitzen Datenbank-Shards aufteilen und bei geringem Traffic per Bin-Packing Tausende Datenbanken konsolidieren
Aufbau der Datenbank-Infrastruktur
- Beim Start im Jahr 2011 wählte Stripe MongoDB als Online-Datenbank, weil es eine höhere Entwicklerproduktivität als Standard-Relationaldatenbanken bot
- Stripe wollte auf MongoDB eine robuste Datenbank-Infrastruktur betreiben, bei der die Stabilität der API Vorrang hat, konnte aber kein bestehendes DBaaS finden, das die Anforderungen erfüllte
- Erfüllung höchster Anforderungen an Verfügbarkeit, Haltbarkeit und Performance
- Nur minimale Datenbankfunktionen nach außen freigeben, um Probleme durch nicht optimierte Abfragen von Client-Anwendungen zu vermeiden
- Unterstützung horizontaler Skalierung durch Sharding
- Erstklassige Unterstützung für Multi-Tenancy mit erzwungenen Quotas
- Starke Sicherheit durch Durchsetzung von Autorisierungsrichtlinien
- Die Lösung war der Aufbau von DocDB auf Basis von MongoDB als Storage Engine – ein wirklich elastisches und skalierbares DBaaS, bei dem Online-Datenmigrationen im Zentrum stehen
- Stripes Produktanwendungen greifen über eine intern in Go entwickelte Flotte von Datenbank-Proxy-Servern auf die Daten in der Datenbank zu, um Fragen der Zuverlässigkeit, Skalierbarkeit, Freigabekontrolle und Zugriffskontrolle durchzusetzen
- Dabei fiel die zentrale Architekturentscheidung, Sharding als Mechanismus für horizontale Skalierung zu verwenden
- Tausende Datenbank-Shards, die jeweils kleine Chunks der kumulierten Daten speichern, bilden heute die Grundlage aller Stripe-Produkte
- Wenn eine Anwendung eine Abfrage an einen Datenbank-Proxy-Server sendet, wird die Abfrage geparst, an einen oder mehrere Shards geroutet und das Ergebnis aus den Shards zusammengeführt und an die Anwendung zurückgegeben
- Die Datenbank-Proxy-Server nutzen einen Chunk-Metadaten-Service, der Chunks auf Datenbank-Shards abbildet, um die für eine gegebene Abfrage relevanten Shards leicht nachzuschlagen
- Änderungsereignisse durch Schreibvorgänge in die Datenbank werden an ein Streaming-Softwaresystem gesendet und schließlich über eine Change-Data-Capture-(CDC)-Pipeline im Objektspeicher abgelegt
- Auf Ebene der Produktanwendungen provisioniert Stripes Team mithilfe einer internen Dokumentdatenbank-Control-Plane logische Container für Daten, sogenannte logische Datenbanken, die eine oder mehrere DocDB-Collections mit Dokumenten für zusammengehörige Zwecke enthalten
- Die Daten dieser DocDB-Collections sind auf mehrere Datenbanken verteilt, also physische Datenbanken, die kleine Chunks der Collection speichern
- Die physischen Datenbanken von DocDB befinden sich auf Shards, die als Replica Sets mit einem Primärknoten sowie mehreren Sekundärknoten inklusive Replikation und automatischem Failover bereitgestellt werden
Entwurf der Data Movement Platform
- Um ein horizontal skalierbares und hoch elastisches DBaaS-Produkt zu bauen, das sich je nach Anforderungen der Produktanwendungen hoch- und herunterskalieren lässt, war eine Funktion nötig, die Daten zwischen Datenbank-Shards transparent für Clients und ohne Downtime migrieren kann
- Das ist ein komplexes Problem verteilter Systeme, das durch die besonderen Anforderungen kritischer Finanzdaten noch schwieriger wird
- Datenkonsistenz und -vollständigkeit: Es muss sichergestellt werden, dass die migrierten Daten sowohl auf dem Quell-Shard als auch auf dem Ziel-Shard konsistent und vollständig bleiben
- Verfügbarkeit: Längere Downtime während der Datenmigration ist nicht akzeptabel, weil Millionen Unternehmen rund um die Uhr auf Stripe angewiesen sind, um Kundenzahlungen entgegenzunehmen
- Ziel ist es, die Kernschritte des Migrationsprozesses kürzer zu halten als die geplante Failover-Zeit des primären Datenbankknotens, die normalerweise nur wenige Sekunden beträgt, und innerhalb des Retry-Budgets der Produktanwendungen zu bleiben
- Granularität und Anpassungsfähigkeit: In Stripes Größenordnung muss es möglich sein, eine beliebige Anzahl von Daten-Chunks aus einer beliebigen Anzahl von Quellen auf Ziel-Shards zu migrieren
- Es darf weder eine Begrenzung für die Anzahl gleichzeitig laufender Migrationen von Datenbank-Chunks in der Flotte geben noch eine Begrenzung dafür, an wie vielen Migrationen ein bestimmter Shard zu einem bestimmten Zeitpunkt teilnehmen kann
- Da zudem ein erheblicher Teil der Datenbank-Shards Daten im Terabyte-Bereich enthält, müssen Chunks verschiedener Größen mit hohem Durchsatz migriert werden können
- Keine Performance-Auswirkungen auf Quell-Shards: Bei der Migration von Datenbank-Chunks zwischen Shards soll die Performance und der verfügbare Durchsatz der Quell-Shards erhalten bleiben, damit Nutzerabfragen nicht negativ beeinflusst werden
- Um diese Anforderungen zu erfüllen, baute Stripe eine Data Movement Platform, die mit speziell entwickelten Services Online-Datenmigrationen zwischen Datenbank-Shards verwaltet
- Die Coordinator-Komponente der Data Movement Platform ist für die Orchestrierung der verschiedenen Schritte einer Online-Datenmigration zuständig und ruft die entsprechenden Services auf, um die unten beschriebenen Konfigurationsschritte auszuführen
Schritt 1: Chunk-Migration registrieren
- Zunächst wird im Chunk-Metadaten-Service die Absicht registriert, einen Datenbank-Chunk von einem Quell-Shard auf einen beliebigen Ziel-Shard zu migrieren
- Danach werden auf dem Ziel-Shard Indizes für den migrierten Chunk aufgebaut
Schritt 2: Daten im Bulk importieren
- Als Nächstes werden Daten anhand eines Chunk-Snapshots des Quell-Shards zum Zeitpunkt T auf einen oder mehrere Datenbank-Shards geladen
- Der Service für den Bulk-Import kann verschiedene Datenfilter verarbeiten und importiert nur Daten-Chunks, die die Filterkriterien erfüllen
- Das sah zunächst einfach aus, doch beim Laden großer Datenmengen in DocDB-Shards stieß Stripe auf Durchsatzgrenzen
- Man versuchte, Writes zu bündeln und die Engine-Parameter von DocDB für optimalen Bulk-Ingest anzupassen, hatte damit aber nur begrenzten Erfolg
- Einen bedeutenden Durchbruch erreichte das Team erst, als es ausnutzte, dass DocDB die Daten mit einer B-Tree-Datenstruktur sortiert, und deshalb nach Wegen suchte, die Einfügereihenfolge zu optimieren
- Indem Daten nach den häufigsten Indexattributen einer Collection sortiert und in sortierter Reihenfolge eingefügt wurden, verbesserte sich die Schreib-Lokalität erheblich, wodurch sich der Schreibdurchsatz verzehnfachte
Schritt 3: Asynchrone Replikation
- Nachdem die Daten auf den Ziel-Shard importiert wurden, startet für die migrierten Datenbank-Chunks die Replikation von Schreibvorgängen vom Quell- zum Ziel-Shard ab Zeitpunkt T
- Das asynchrone Replikationssystem liest Änderungen aus Schreibvorgängen auf dem Quell-Shard aus dem CDC-System und führt die Writes auf dem Ziel-Shard aus
- Das Operation Log oder
oplog ist eine spezielle Collection jedes DocDB-Shards, in der alle Operationen protokolliert werden, die Daten in den Datenbanken dieses Shards verändern
- Die
oplog-Einträge aller DocDB-Shards werden an Kafka als Event-Streaming-Plattform gesendet und anschließend in Cloud-Objektspeichern wie Amazon S3 abgelegt
- Mit
oplog-Events aus Kafka und Amazon S3 baute Stripe einen Service, der Änderungen von einem oder mehreren Quell-DocDB-Shards auf einen oder mehrere Ziel-DocDB-Shards repliziert
- Da der Service auf
oplog-Events des CDC-Systems setzt, verbraucht er keinen Lesedurchsatz der Quell-Shards, der für Nutzerabfragen benötigt wird, und verlangsamt Nutzerabfragen daher nicht; außerdem ist er nicht durch die Größe des oplog des Quell-Shards eingeschränkt
- Der Service ist so ausgelegt, dass er auch dann elastisch bleibt, wenn Ziel-Shards nicht verfügbar sind, und dass die Synchronisierung jederzeit an einem Checkpoint gestartet, pausiert und fortgesetzt werden kann
- Der Replikationsservice bietet außerdem die Möglichkeit, die Replikationsverzögerung abzurufen
- Änderungen an Chunks in Migration werden bidirektional vom Quell- zum Ziel-Shard und umgekehrt repliziert, wobei der Replikationsservice die von ihm erzeugten Writes markiert, um zirkuläre asynchrone Replikation zu verhindern
- Das war eine bewusste Designentscheidung, um die Flexibilität zu haben, Traffic bei Problemen nach der Umschaltung auf den Ziel-Shard wieder zurück auf den Quell-Shard zu leiten
Schritt 4: Korrektheit prüfen
- Sobald die Replikation zwischen Quell- und Ziel-Shard synchron ist, wird die Datenvollständigkeit und -korrektheit umfassend überprüft, indem Point-in-Time-Snapshots verglichen werden
- Auch das war eine bewusste Designentscheidung, damit der Durchsatz der Shards nicht beeinträchtigt wird
Schritt 5: Traffic umschalten
- Sobald die Daten eines Chunks vom Quell- auf den Ziel-Shard importiert wurden und Änderungen aktiv repliziert werden, orchestriert der Coordinator die Umschaltung des Traffics
- Um die Lese- und Schreibpfade für den migrierten Daten-Chunk umzulenken, muss zunächst der Traffic auf dem Quell-Shard kurz angehalten, dann der Pfad im Chunk-Metadaten-Service aktualisiert und schließlich müssen die Proxy-Server Reads und Writes auf den Ziel-Shard umleiten
- Das Protokoll für die Traffic-Umschaltung basiert auf der Idee des Version Gating
- Im stabilen Zustand fügt jeder Proxy-Server Anfragen an DocDB-Shards eine Versions-Token-Nummer hinzu
- Durch einen benutzerdefinierten Patch in MongoDB können Shards prüfen, ob die Versions-Token-Nummer einer Anfrage vom Proxy-Server neuer ist als die ihnen bekannte Versions-Token-Nummer, und nur Anfragen verarbeiten, die dieses Kriterium erfüllen
- Um das Chunk-Routing zu aktualisieren, führt Stripe mit dem Coordinator die folgenden Schritte aus:
- Zuerst wird die Versions-Token-Nummer des Quell-DocDB-Shards erhöht. Die Versions-Token-Nummer ist in einem Dokument einer speziellen Collection von DocDB gespeichert, und ab diesem Zeitpunkt werden alle Reads und Writes für den Chunk auf dem Quell-Shard abgewiesen
- Danach wartet man, bis der Replikationsservice ausstehende Writes vom Quell-Shard repliziert hat
- Abschließend wird im Chunk-Metadaten-Service das Chunk-Routing so aktualisiert, dass es auf den Ziel-Shard und die Versions-Token-Nummer zeigt
- Danach holen die Proxy-Server aus dem Chunk-Metadaten-Service das aktualisierte Routing für den Chunk und die neueste Versions-Token-Nummer ab
- Die Proxy-Server nutzen das aktualisierte Routing, um Reads und Writes für den Chunk auf den Ziel-Shard zu leiten
- Das gesamte Protokoll zur Traffic-Umschaltung dauert weniger als 2 Sekunden, und alle fehlgeschlagenen Reads und Writes, die an den Quell-Shard gesendet wurden, sind bei einem Retry erfolgreich
Schritt 6: Registrierung der Chunk-Migration aufheben
- Abschließend markiert Stripe die Migration im Chunk-Metadaten-Service als abgeschlossen und löscht die Chunk-Daten vom Quell-Shard, womit der Migrationsprozess beendet ist
Einsatz der Data Movement Platform
- Die Fähigkeit, Daten-Chunks online zwischen DocDB-Shards zu migrieren, hilft Stripe dabei, die Datenbank-Infrastruktur horizontal im Tempo des Unternehmenswachstums zu skalieren
- Ingenieure des Datenbank-Infrastrukturteams können DocDB-Shards je nach Größe und Durchsatz per Knopfdruck aufteilen und so Speicher- und Durchsatzreserven für Produktteams schaffen
- 2023 verbesserte Stripe mithilfe der Data Movement Platform die Auslastung der Datenbank-Infrastruktur
- Konkret migrierte das Unternehmen 1,5 Petabyte an Daten transparent für Produktanwendungen, um Tausende schwach ausgelastete Datenbanken per Bin-Packing zusammenzulegen, und reduzierte so die Gesamtzahl der zugrunde liegenden DocDB-Shards auf etwa drei Viertel des ursprünglichen Bestands
- Außerdem nutzte Stripe die Data Movement Platform, um die Datenbank-Infrastruktur-Flotte zu aktualisieren, indem Daten in einem einzigen Schritt per Forklift-Migration auf neuere MongoDB-Versionen gebracht wurden, ohne Zwischenstufen über wichtige oder kleinere Versionen hinweg
- Das Datenbank-Infrastrukturteam von Stripe konzentriert sich darauf, eine robuste und zuverlässige Grundlage zu schaffen, die mit dem Wachstum der Internetwirtschaft skaliert
- Aktuell wird ein Heat-Management-System als Prototyp entwickelt, das Daten auf Basis von Größe und Durchsatz proaktiv zwischen Shards ausbalanciert, außerdem investiert Stripe in Auto-Scaling für Shards, das dynamisch auf Veränderungen im Traffic-Muster reagiert
Noch keine Kommentare.