Wie OpenAI den Habitat-Speicher auf Azure Cosmos DB für 1 Milliarde Nutzer skaliert hat

Habitat im Maßstab von OpenAI

Laut OpenAI hängen alle Produkte des Unternehmens von schnellem, zuverlässigem Datenzugriff ab, den Habitat, die Online-Speicherplattform, bereitstellt. Habitat müsse in Millisekunden auf Anfragen von über 1 Milliarde Nutzern in 40 geografischen Regionen reagieren und sei von einer einfachen Client-Bibliothek samt Datenbank zu einer global verteilten Plattform mit über 500 Petabyte an Daten gewachsen.

Teil I der Serie behandelte die Entwicklung von Habitat von einem Python-Client zu einem Service. Teil II konzentriert sich auf die zugrunde liegende Speicherkomponente Azure Cosmos DB. Durch die enge Zusammenarbeit mit dem Azure-Team sei OpenAI zu einem tragfähigen Multi-Tenancy-Ansatz aus gemeinsam verwalteten Containern gelangt, der bei massiver, globaler Skalierung eine ausgezeichnete Leseleistung biete, so das Unternehmen.

OpenAI beschreibt seine Prioritäten als Abfolge: Zuerst zuverlässig genug für geschäftskritischen Produktverkehr werden, dann schnell genug für globale Nutzer und schließlich im massiven Maßstab betreibbar sein.

Phase I: Ein gemeinsamer Container und seine Grenzen

OpenAI erläutert, dass Single-Tenancy, bei der jedes Produktteam sein eigenes System betreibt, den Wirkungsradius von Ausfällen begrenzt und klare Zuständigkeiten schafft, aber teuer wird und häufig zu erheblicher Überprovisionierung führt. Bei Multi-Tenancy hat ein zentrales Datenbankteam die Kontrolle, doch es entstehen Noisy-Neighbor-Probleme, bei denen ein Mandant einen ungewöhnlich großen Teil der Ressourcen beansprucht.

Zunächst nutzte Habitat in jedem Konto einen einzigen Standard-Container von Azure Cosmos DB und ließ jede Client-Last durch. Als Gegendruck diente das angegebene Limit von 10K RU/s pro logischem Partitionsschlüssel. OpenAI nennt drei Probleme dieses Aufbaus:

• Limits der logischen Partitionsschlüssel: Weil frühe API-Entscheidungen die Wahl des Partitionsschlüssels den Clients überließen, kollidierten verschiedene Produktanwendungsfälle häufig bei gängigen Schlüsseln wie user_id oder workspace_id. Sie teilten sich dann die Limits und begrenzten den Durchsatz für einen bestimmten Nutzer.
• Noisy Neighbors: Die Limits werden tatsächlich auf der physischen Partition durchgesetzt, sodass logische Partitionen in der Praxis keine 10.000 RU/s erreichen und sich die Kapazität mit gemeinsam platzierten Schlüsseln teilen. Laut OpenAI störten Workloads für Nischenfunktionen zentrale Login- und Anmeldeabläufe.
• Schwache Partitionen: Der bereitgestellte Durchsatz eines Containers verteilt sich in etwa gleichmäßig auf seine physischen Partitionen. Wenn Partitionen mit wachsendem Datenbestand geteilt werden, bleibt der Gesamtdurchsatz gleich, das Limit pro Partition sinkt also. Bei speicherintensiven, Blob-artigen Anwendungsfällen verringerte allein das Speicherwachstum den Durchsatz für aktive Workloads.

Das Unternehmen weist zudem darauf hin, dass beim Skalieren von Postgres vor dem Wechsel zu Habitat und Azure Cosmos DB heiße Organisationen oder Schlüssel die gesamte Datenbank lahmlegen konnten. Das habe erheblichen Aufwand für Caching und Leases bei Cache-Misses erfordert.

Phase II: Isolierte Container und ihre Kosten

Um diese Probleme zu beheben, begann OpenAI, für die kritischsten neuen Anwendungsfälle separate Container zu nutzen. Jeder Container erhält eigene physische Partitionen, sodass nur Workloads desselben Containers als Noisy Neighbors auftreten können. In Kombination mit einem Skript, das den bereitgestellten Durchsatz jedes Containers mit der Zahl seiner physischen Partitionen synchronisiert, wurden die genannten Probleme laut Unternehmen weitgehend vermieden.

Viele kritische Altanwendungen blieben jedoch ohne Datenmigration im Standard-Container hängen. Als Druck und Produktionsvorfälle auf diesem Container zunahmen, begann OpenAI, für jeden neuen Service und jede große Produktfunktion Container bereitzustellen. Das habe das Unternehmen vor vielen plattformweiten Ausfällen bewahrt und den Wirkungsradius auf Beeinträchtigungen einzelner Funktionen oder Services begrenzt.

Der Mehraufwand holte das Unternehmen schließlich ein. Jeder Container braucht eine eigene Kapazitätsplanung. Im gemeinsamen Container veränderte ein neuer Anwendungsfall, der von 0 auf 1 Million QPS sprang, die Gesamtauslastung wahrscheinlich kaum. In einem isolierten Container konnte derselbe Sprung 1.000-mal mehr Last bedeuten als die Basislast aus dem internen Dogfooding. Teams mussten für Launches vorab provisionieren, vergaßen es aber oft, und OpenAI sagt, man habe am Launch-Tag in SEV-Räumen gesessen und versucht, Container in letzter Minute zu skalieren.

Was das bedeutet

Laut OpenAI ist Habitat heute eine mandantenfähige Datenbankschicht für viele seiner Produkte und wurde standardmäßig wieder auf einen Multi-Tenant-Container umgestellt. Das Unternehmen fügt hinzu, man stehe bei Multi-Tenancy noch ganz am Anfang und habe Investitionen in diesem Bereich aufgeschoben, indem man wo immer möglich die integrierten Primitive von Azure Cosmos DB nutze.

Für Teams, die große gemeinsam genutzte Datenplattformen aufbauen, verdeutlicht der Bericht den Zielkonflikt zwischen Isolation und effizienter Kapazitätsplanung. Der Quelltext bricht ab, bevor die finalen Designdetails des Ansatzes mit gemeinsam verwalteten Containern beschrieben werden.