OpenAI legt uit hoe ChatGPT 1 miljard gebruikers bedient zonder dat de opslag vastloopt

OpenAI heeft in een technische blog uitgelegd hoe het de opslag achter ChatGPT en andere producten heeft opgebouwd en bijgesteld. Het systeem heet Habitat. Volgens OpenAI moet het binnen milliseconden antwoorden aan meer dan 1 miljard gebruikers, verspreid over 40 geografische regio’s, en beheert het meer dan 500 petabyte aan data. Dit is het tweede deel van een reeks. Het gaat over de database eronder: Azure Cosmos DB van Microsoft.

Wat ging er mis bij de eerste opzet?

In het begin gebruikte OpenAI één gedeelde opslagruimte (een zogeheten container) voor alles, en dat leidde tot drie problemen, volgens het bedrijf zelf.

Het eerste probleem: verschillende producten gebruikten dezelfde sleutels om gegevens te vinden, zoals een gebruikers-ID. Daardoor deelden ze dezelfde limieten en beperkte het ene product de snelheid van het andere voor dezelfde gebruiker.

Het tweede probleem is het bekende naburige-lawaai-effect. Gegevens van verschillende gebruikers liggen fysiek op dezelfde plek. Een functie die veel vraagt kon daardoor onverwacht andere onderdelen vertragen. OpenAI noemt als voorbeeld dat een weinig gebruikte productfunctie de kernfuncties inloggen en aanmelden kon verstoren.

Het derde probleem: zwakke partities. Naarmate er meer data bij komt, wordt de opslag in stukken gesplitst, terwijl de totale capaciteit gelijk blijft. Elk stuk krijgt dan minder ruimte. Alleen al door groei van de opgeslagen data daalde dus de snelheid voor actieve gebruikers, ook als het aantal verzoeken gelijk bleef.

Waarom koos OpenAI eerst voor aparte opslag?

OpenAI gaf kritieke nieuwe diensten een eigen opslagruimte, zodat storingen beperkt bleven. Volgens het bedrijf voorkwam dat meerdere storingen van de hele site. Het bleef bij uitval van één dienst of functie.

De keerzijde was organisatorisch. Elk team moest zelf vooraf berekenen hoeveel capaciteit nodig was voor een lancering. Teams vergaten dat, waarna OpenAI op de lanceerdag in nood moest opschalen. In een gedeelde ruimte valt een nieuwe functie nauwelijks op in het totaal. In een eigen, kleine ruimte kan een lancering de belasting met een factor 1.000 of meer doen stijgen. Het bijhouden van die capaciteit vroeg ook kennis van elk product, waardoor bijna elk team zich met capaciteitsplanning moest bezighouden. Dat schaalde volgens OpenAI niet mee met de organisatie.

Waarom stapt OpenAI weer over naar gedeelde opslag?

OpenAI koos opnieuw voor gedeelde opslag als standaard, maar nu met extra verkeersregels. Het werkte daarvoor nauw samen met het Azure-team van Microsoft.

Twee maatregelen worden genoemd. De eerste is het afremmen van de drukste sleutels, zodat één overbelaste gebruiker of organisatie niet de hele fysieke opslag opslokt. De tweede is een prioriteitssysteem: zware achtergrondtaken, zoals massaal invoeren of exporteren van data, krijgen lagere voorrang dan verzoeken van gebruikers die live wachten. Bij drukte worden die bulktaken dus eerst afgeremd. Een derde optie, de serverloze modus van Cosmos DB, zou het probleem met zwakke partities oplossen, maar de bron breekt af bij de nadelen ervan. Die kunnen we dus niet beoordelen.

Opvallend is dat OpenAI zegt nog vroeg te zijn in dit verhaal. Het bedrijf heeft investeringen in eigen voorzieningen kunnen uitstellen door waar mogelijk de ingebouwde functies van Cosmos DB te gebruiken.

Wat staat er niet in de bron?

Het is een verslag van OpenAI over zijn eigen systeem. Er zijn geen onafhankelijke metingen, geen kosten, geen prijzen en geen beschikbaarheidscijfers. Er staat ook niets over waar gegevens van Europese gebruikers worden opgeslagen. In een schema noemt OpenAI wel een onderdeel voor plaatsing en gegevensverblijf (data residency), maar uitleg of toezeggingen ontbreken. Ook is het stuk in de beschikbare tekst afgebroken, waardoor de conclusies ontbreken.