OpenAI skaliert Habitat-Speicher für über eine Milliarde Nutzer
OpenAIs Technikbeitrag vom 23. Oktober beschreibt Habitat und Azure Cosmos DB für mehr als eine Milliarde Nutzer in 40 Regionen sowie über 500 Petabyte auf der gesamten Plattform. Nach dedizierten Containern wurde gemeinsame Nutzung wieder zum Standard, nachdem die Behandlung heißer Schlüssel und die Skalierung verbessert wurden.
Habitat-Speicher im ChatGPT-Maßstab
OpenAI's Engineering Post vom 23. Oktober beschreibt Teil II seiner Online-Speichergeschichte Habitat. Das Unternehmen sagt, die Plattform bedient mehr als eine Milliarde Nutzer in 40 geografischen Regionen und verwaltet mehr als 500 Petabyte Daten. Diese Zahlen beschreiben das eigene System und sind kein unabhängiger Benchmark. Teil I umfasste den Übergang von der Python-Clientbibliothek zum Speicherdienst; Teil II konzentriert sich auf Azure Cosmos DB als zugrunde liegende Speicherkomponente und die operativen Entscheidungen, die im großen Maßstab erforderlich sind.
Die zentrale Lektion ist eine Umkehrung, nicht ein Slogan für universelle Multi-Tenancy. Habitat nutzte zunächst einen gemeinsamen Cosmos DB-Container, stellte dann dedizierte Container für Arbeitsbelastungen bereit, die Isolation benötigten, und kehrte schließlich nach gemeinsamer Entwicklungsarbeit mit Azure als Standard zur gemeinsamen Nutzung zurück. Dedizierte Container verringerten die gegenseitige Störung, machten aber jedes Team für die Kapazitätsplanung verantwortlich. Ein neuer Service könnte von einem Testverkehr auf eine Million Anfragen pro Sekunde springen, was eine vorzeitige Bereitstellung erfordert, die Teams manchmal vergessen. Der Artikel beschreibt Vorfälle und den Druck, der durch diese organisatorische Belastung am Starttag verursacht wird.
Warum das gemeinsame Design zurückkehrte
OpenAI sagt, dass das überarbeitete Design zuerst die heißesten Partitionsschlüssel einschränkt, so dass eine laute Arbeitslast weniger wahrscheinlich den Durchsatz einer ganzen physischen Partition verbraucht. Ein verbesserter Azure Cosmos DB Serverless-Modus unterstützt bis zu 10.000 Anforderungseinheiten pro Sekunde pro physische Partition und zusätzliche Spliting basierend auf Nutzung von Anforderungseinheiten sowie Speicherung. Diese Zahl ist eine für die Vereinbarung von OpenAI gemeldete Service-Design-Grenze und nicht ein Versprechen zur Latenzzeit der Anwendung. Der Ansatz reduziert die manuelle Vorskalierung, beseitigt jedoch nicht die Notwendigkeit, Hot Keys und Mandantengrenzen zu testen.
Der Beitrag berichtet, dass OpenAIs größtes Cosmos-DB-Konto Dutzende Petabyte speichert und mehr als 20 Millionen Abfragen pro Sekunde bedient. Ein regionaler Stromausfall Ende 2024 zeigte außerdem, dass der Failover der größten Konten in eine sekundäre Region mehrere Stunden dauern würde; die Dauer des Stromausfalls wird damit nicht beziffert. Die technische Lehre ist, dass auch ein verwalteter Speicherdienst bei außergewöhnlicher Größe gemeinsame Tests mit dem Anbieter braucht. Allgemeine Failover-Dokumentation ersetzt keine vollständige Probe mit dem tatsächlichen Datenvolumen und Verkehrsprofil des Kunden.
OpenAI berichtet von Verbesserungen der Leseleistung, einschließlich 12-mal schnellerer Leseanforderungen in seiner Speicherarbeit, aber die Leser sollten jeden Anspruch im speziellen Arbeitslast- und Messkontext des Unternehmens finden. In diesem Artikel werden diese Verhältnisse nicht auf einen anderen Einsatz extrapoliert. Der ursprüngliche Beitrag enthält mehr Details über Caching, Container und die Partnerschaft mit dem Anbieter; ein Team, das seine eigene Architektur plant, sollte seine eigene Leseverteilung, Schreibdruck und Fehlverhalten messen, bevor es eine Komponente kopiert.
Praktische Lehren für andere Teams
Für einen kleineren Service ist die nützliche Wahl weder „immer teilen“ noch „immer isolieren“. Ordnen Sie Mandanten nach Durchsatz, Partitionsschlüsselverteilung, Speicherwachstum und Ausfallstoleranz. Wiederholen Sie einen Startspike und einen regionalen Ausfall, einschließlich der Zeit, um nützliche Lesungen wiederherzustellen. Verfolgen Sie, wer die Kapazitätsänderungen besitzt und wer einen heißen Mandanten verlangsamen kann. Die Erfahrungen von OpenAI zeigen, dass operatives Eigentum einem sauberen theoretischen Isolierungsmodell überwiegen kann.
Die Quelle ist der Artikel Habitat Teil II vom 23. Oktober. Dieser Artikel vom 26. Oktober berichtet über seine Architektur und Grenzen. Es verlangt keinen Zugang zu OpenAI-Telemetrie, zu Azure-Dienstverträgen oder zur unabhängigen Reproduktion der Leistungsnummern.
Sources
FAQ
Warum kehrte Habitat zu gemeinsam genutzten Containern zurück?
OpenAI zufolge minderten dedizierte Cosmos-DB-Container Störungen durch andere Lasten, machten aber jedes Produktteam für die Kapazität zum Start verantwortlich. Verbesserungen mit Azure bei heißen Schlüsseln und Partitionen ermöglichten die gemeinsame Nutzung als Standard. Das ist keine allgemeingültige Datenbankregel.
Welche Größenordnung nennt OpenAI für Habitat?
Das Unternehmen nennt über eine Milliarde Nutzer in 40 Regionen und mehr als 500 Petabyte für die Plattform. Das größte Cosmos-DB-Konto enthalte Dutzende Petabyte und bearbeite über 20 Millionen Abfragen pro Sekunde. Diese Zahlen stammen von OpenAI, nicht aus einer unabhängigen Messung.
Was sollte ein anderes Team vor einer Übernahme testen?
Es sollte eigene heiße Partitionsschlüssel, gegenseitige Störungen, Lastspitzen beim Start und regionales Failover mit realistischen Daten prüfen. OpenAI berichtet, ein Ausfall 2024 habe bei den größten Konten eine Umschaltung über mehrere Stunden offengelegt.