Snabb skalning av onlinelagring för över 1 miljard ChatGPT‑användare (del II)

Alla OpenAI-produkter behöver snabb och tillförlitlig åtkomst till data. Det tillhandahåller vår lagringsplattform Habitat. Den måste svara på millisekunder för över 1 miljard användare i 40 geografiska regioner. Vår infrastruktur stod inför en enorm utmaning: att klara explosiv tillväxt och nya användningsfall och samtidigt fortsätta förbättra tillförlitlighet, prestanda och produktutvecklarnas arbetstakt. För att lösa den utmaningen behövde vi tänka om kring hur vår onlinelagringsplattform utformades och drevs. Vi utvärderade ständigt olika avvägningar enligt följande ordning: först tillräckligt tillförlitlig för verksamhetskritisk produkttrafik, sedan tillräckligt snabb för användare världen över och slutligen smidig att driva i enorm skala.

Den här serien i två delar beskriver hur vi utvecklade Habitat från ett enkelt klientbibliotek och en databas till en globalt distribuerad lagringsplattform som tillhandahåller över 500 petabyte data. Del I handlade om Habitats utveckling från en Python-klient till en tjänst. Den tog också upp teknikerna som lät oss pressa en Python-baserad tjänst långt bortom vad många skulle anse vara praktiskt möjligt.

I det här inlägget, del II, går vi igenom hur vi skalade den underliggande lagringskomponenten: Azure Cosmos DB. Genom ett nära samarbete med Azure-teamet hittade vi en fungerande flerklientslösning med gemensamt förvaltade containrar och utmärkt läsprestanda i mycket stor, global skala.

När företag växer går infrastrukturteam ofta från att driva enkelklientsystem till flerklientsystem. I enkelklientsystem underhåller varje produktområdes team sitt eget system. Det begränsar spridningen av fel och ger tydliga ansvarsgränser och isolerade arbetsbelastningar. När teamen och produktområdena växer blir detta dyrt att driva. Enkelklientsystem gör varje produktteam ansvarigt för kapacitetsplanering och leder ofta till betydande överallokering.

I flerklientsystem ligger kontrollen däremot hos ett centralt databasteam med bättre kunskap och erfarenhet av resursallokering. Men flerklientsystem skapar egna problem, som störande grannar: en klient förbrukar en ovanligt stor andel av resurserna på de andra klienternas bekostnad.

I Habitat behövde vi väga alla dessa för- och nackdelar mot varandra för att utforma ett tillförlitligt och effektivt lagringssystem i stor skala. I dag är Habitat ett databaslager för flera klienter som används av många OpenAI-produkter. Men vi har gått varvet runt: från en gemensam Azure Cosmos DB-container för flera klienter, via separata underliggande containrar för enskilda klienter, tillbaka till en flerklientscontainer som standard. Vi är fortfarande i början av arbetet med flerklientsstöd i Habitat. Vi stöder många användningsfall, men har kunnat skjuta upp investeringar på området genom att använda Azure Cosmos DB:s inbyggda grundfunktioner där det går.

Innan vi går igenom vår resa med Azure Cosmos DB behövs lite bakgrund:

• Ett Azure Cosmos DB-konto definierar en uppsättning containrar och en replikeringspolicy

• Varje container tilldelas en viss kapacitet i begärandeenheter per sekund (RU/s)

• Data i varje container delas som vanligt upp i shardar utifrån en angiven logisk partitionsnyckel, med dokumenterade gränser för lagring och kapacitet per logisk partitionsnyckel

• Azure Cosmos DB fördelar logiska partitionsnycklar över ett mindre antal underliggande fysiska partitioner. Dessa delas i fler fysiska partitioner när lagringen passerar en tröskel eller när containern behöver fler fysiska partitioner för att upprätthålla den allokerade kapaciteten

Från början släppte vi igenom all klientbelastning och förlitade oss på den angivna gränsen på 10 000 RU/s per logisk partitionsnyckel för att ge mottryck. När vi började använde vi också bara en standardcontainer i Azure Cosmos DB per konto. Det fungerade tillräckligt bra, men visade sig vara problematiskt av flera skäl:

Tidiga API-beslut gjorde att vi lät klienterna välja logisk partitionsnyckel direkt. Därför får vi ofta kollisioner mellan olika produktanvändningsfall för vanliga partitionsnycklar som user_id och workspace_id. Eftersom dessa användningsfall delade Azure Cosmos DB:s gränser för samma logiska partitionsnycklar begränsade utformningen den totala kapaciteten för en viss användare.

Ett vanligt problem när vi skalade Postgres, innan vi gick över till Habitat och Azure Cosmos DB, var att många anrop från en mycket hårt belastad organisation eller nyckel – en klient som genererade oproportionerligt hög belastning – kunde slå ut hela databasen. Vi lade mycket gemensamt arbete på att cachelagra dessa nycklar och införa tidsbegränsade lås vid cachemissar, så att belastningen från missarna inte överbelastade den underliggande databasen.

De dokumenterade gränserna för datastorlek och kapacitet gäller logiska partitionsnycklar, men det är på den fysiska partitionen som gränserna faktiskt upprätthålls. I praktiken innebär det att logiska partitioner inte kan nå 10 000 RU/s. I stället delar de den fysiska partitionens gränser med alla andra logiska partitionsnycklar som finns på samma fysiska partition.

Det gjorde att störande grannar kunde påverka många orelaterade logiska partitionsnycklar. Arbetsbelastningar som hanterade data för nischade produktfunktioner störde grundläggande inloggnings- och registreringsflöden.

Kapacitetsgränsen för en viss fysisk partition varierar också beroende på den totala kapacitet som tilldelats Azure Cosmos DB-containern. Containerns allokerade kapacitet fördelas ungefär jämnt över dess fysiska partitioner.

När datavolymen växer delas de fysiska partitionerna. Det totala antalet partitioner ökar, medan den totala allokerade kapaciteten förblir oförändrad. Resultatet är att den faktiska kapacitetsgränsen per partition sjunker när datamängden växer.

För våra mest lagringskrävande, blobliknande användningsfall skapar detta ett felläge där enbart ökad lagringsvolym minskar kapaciteten för aktiva arbetsbelastningar, trots att anropsfrekvens och användning är stabila.

Separata containrar hjälper delvis mot dessa partitionsnyckelgränser och störande grannar. Varje separat container kan tilldelas egna, oberoende fysiska partitioner. Då är det bara arbetsbelastningarna i samma container som kan störa varandra eller ha överlappande partitionsnycklar. Nackdelen är att nya containrar medför extra arbete: varje container kräver egen kapacitetsplanering. Därför vill vi bara skapa containrar vid rimliga gränser mellan tjänster eller användningsfall.

Vi började använda separata Azure Cosmos DB-containrar för de mest kritiska nya användningsfallen som krävde stark isolering. Tillsammans med ett skript som hanterade svaga partitioner genom att anpassa varje containers totala allokerade kapacitet efter antalet fysiska partitioner kunde vi i stort sett undvika alla problem vi hade stött på.

Eftersom vi hade börjat med en standardcontainer var många äldre, kritiska användningsfall tyvärr fast där om vi inte migrerade data. För att skydda kritiska tjänster som fortfarande använde data i den delade standardcontainern rekommenderade vi ofta teamen att skapa separata containrar för nya tjänster eller större produktfunktioner. När vi växte ökade belastningen på standardcontainern, liksom antalet incidenter i produktion. Vi började skapa containrar för varje ny tjänst eller större produktfunktion, enbart för att skydda standardcontainern från mer belastning.

Det besparade oss många avbrott som annars skulle ha drabbat hela sajten och begränsade påverkan till störningar i enskilda funktioner eller tjänster. Till slut hann dock merarbetet med att skapa nya containrar ikapp oss:

I den gamla delade standardcontainern var det osannolikt att ett enskilt nytt användningsfall som gick från 0 till 1 miljon QPS skulle påverka den totala användningen nämnvärt. I en isolerad container kunde däremot ett nytt användningsfall som gick från 0 till 1 miljon QPS innebära 1 000 gånger högre belastning än basnivån från enbart intern testanvändning.

Med dedikerade containrar behövde teamen nu komma ihåg att allokera förväntad kapacitet i förväg inför lanseringar. Produktteamen driftsatte ofta sina funktioner utan att skala upp i förväg. Då fick vi sitta i incidentmöten på lanseringsdagen och försöka skala upp containrar i sista minuten.

Att blanda arbetsbelastningar är en central fördel med flerklientsystem, som vi med denna containerstrategi förlorar i utbyte mot bättre isolering.

Med tiden krävde även övervakningen av dedikerade containrars användning ingående produktkunskap om när trafiken skulle förändras eller växa.

Vi kan tillhandahålla ett enkelt kontrollplansskript som skalar upp varje containers allokerade kapacitet utifrån tillväxttrender. Men utan stabil samlad tillväxt krävde korrekt skalning att i princip varje produktteam på OpenAI deltog i kapacitetsplaneringen.

Det gick inte att skala organisatoriskt. Det varierade stort hur noggrant teamen som ansvarade för respektive tjänst skötte kapacitetstilldelningen i Azure Cosmos DB.

När organisationen växte blev dessa driftproblem svåra att hantera i större skala. Utan ett enda centralt team som skötte planeringen blev resultatet att många team planerade dåligt. Därför återgick vi till en flerklientslösning och arbetade nära Azure-teamet för att lösa våra ursprungliga problem med en konstruktion för delade resurser:

Genom att strypa de hårdast belastade nycklarna först hindrar vi störande grannar från att förbruka all tillgänglig kapacitet i en viss fysisk partition. Det minskar effekten av störande grannar, där en enda hårt belastad nyckel kan påverka hela sajten.

QoS med prioritetsnivåer för anrop hindrar på motsvarande sätt offline-arbetsbelastningar, som massinfogningar eller datauttag, från att använda all kapacitet i en viss fysisk partition. Genom att ge dessa anrop lägre prioritet stryps de först. Då slipper interaktiva anrop med högre prioritet, som betjänar slutanvändare, strypas.

Azure Cosmos DB hade redan ett serverlöst läge som skulle ha löst problemet med svaga partitioner i läget med förallokerad kapacitet. Men det hade en stor nackdel: det skalade enbart efter lagringsanvändning och begränsade RU-användningen till 5 000 RU/s per fysisk partition. Det skulle lösa problemet med svaga partitioner, men hindra oss från att skala upp RU-krävande användningsfall.

Azure Cosmos DB-teamet byggde ett förbättrat serverlöst läge åt oss där varje fysisk partition kunde skala upp till 10 000 RU/s. Det införde också partitionsdelning baserad på RU-användning, utöver lagringsanvändning, så att vi slapp övervaka och skala upp containrar manuellt.

Med dessa ändringar har vi kunnat återgå till en enda delad container. Det har avsevärt förenklat kapacitetsplaneringen för produktteamen, både inför lansering och löpande, samtidigt som arbetsbelastningarna förblir isolerade. Under månaderna sedan dess har vi inte haft några incidenter kopplade till kapacitetstilldelning eller störande grannar, trots att produktutvecklingen accelererat.

När företag når OpenAI:s storlek blir hanterade tjänster mindre ”hanterade”. Många arbetsbelastningar avviker från det normala i molnleverantörens infrastruktur. När OpenAI blev en av de största användarna av Azure Cosmos DB krävdes ett annat arbetssätt för att driva det framgångsrikt: gemensamma tester och instrumentpaneler, direkta kanaler mellan utvecklarna och delat ansvar för fellägen som bara uppstår i vår skala. I dag lagrar vårt största Azure Cosmos DB-konto tiotals petabyte data och hanterar över 20 miljoner QPS. Såvitt vi vet är vi det enda företaget som har driftsatt Azure Cosmos DB i denna skala.

I slutet av 2024 visade ett regionalt avbrott tydligt varför detta samarbete var nödvändigt. Då drabbades den primära Azure-regionen för ett av våra största Azure Cosmos DB-konton av ett strömavbrott. Vid den efterföljande redundansväxlingen insåg vi att våra största konton skulle ta flera timmar att växla över till en sekundär region. Det hade varken vårt team eller Azure Cosmos DB-teamet testat i vår skala.

Ungefär en månad senare, när vi växlade tillbaka kontona till den ursprungliga regionen, utlöste vi ännu ett allvarligt avbrott. En anstormning av anslutningar till den ursprungliga regionen överbelastade dess Azure Cosmos DB-gateway. En egenhet i hur Azure Cosmos DB-klienten i gatewayläge hanterade redundansväxling fick alla klienter att omedelbart upprätta anslutningar och skicka anrop till den ursprungliga regionen, trots att bara en del av de fysiska partitionerna hade flyttats tillbaka dit.

Vid varje avbrott följde både OpenAI och Azure sina incidenthanteringsprocesser, identifierade flera grundorsaker och införde korrigeringar. Men avbrotten var symptom på ett större systemproblem i hur vårt team och Azure Cosmos DB-teamet arbetade och testade. Till en början lät hanterade tjänster oss arbeta snabbt och fokusera på verksamhetens mål. I stor skala blir hanterade tjänster mindre hanterade och kräver djup integration med tjänsteleverantören på alla nivåer, från utformning till drift.

I dag övervakar Habitats och Azures utvecklingsteam tillsammans varje lager i Habitat, från våra tjänstelager ända ner till Azure Cosmos DB:s fysiska lagringslager. Vi kör och testar ändringar mot ett Azure Cosmos DB-konto som är lika stort som produktionsmiljön men inte används i produktion. Vi testar och vidareutvecklar SDK:er tillsammans och tar fram bästa praxis för hur vi skalar och dimensionerar våra Azure Cosmos DB-konton. Vi har direktkontakt mellan utvecklingsteamen via Teams och har till och med gjort det möjligt att larma varandra direkt utan att gå via supportnivåer.

Under det senaste året har vi tillsammans gjort ett omfattande arbete för att förbättra skalbarheten i Azure Cosmos DB:s kontrollplan och gateway. Vi har infört överbelastningsskydd och cachelagring av olika Azure Cosmos DB-metadata i deras gateway för att skydda metadatapartitionen, minskat belastningen från våra Python-processer för habitat-service genom anslutningspoolning och ökad återanvändning av anslutningar, samlokaliserat arbetsbelastningar där det går och isolerat kritiska arbetsbelastningar från offline-arbetsbelastningar med separata VPC:er.

Detta nära utvecklingssamarbete har varit avgörande för stabiliteten i vår Azure Cosmos DB-miljö under det senaste året. Alla tillräckligt stora eller kritiska system kräver den här typen av samarbete: att bryta ner revirgränser och arbeta över organisationsgränser.

Som vi nämnde i del I är vår grundfilosofi: få det att fungera, gör det snabbt, gör det billigt. Först tillförlitlighet, sedan prestanda, därefter effektivitet. Habitat hade blivit kritisk infrastruktur för OpenAI, så högsta prioritet var att göra det tillförlitligt. När systemet stabiliserades under 2025 och OpenAI expanderade globalt blev latensen nästa begränsning för användare och produktteam.

Beräknings- och lagringskapacitet låg ofta i olika regioner, vilket gjorde anrop mellan regioner oundvikliga.

Latensen varierade kraftigt beroende på var data lagrades och var anropet hanterades. För att få snabba Habitat-anrop använde produktutvecklarna extra cachelagring på klientsidan, grupperade anrop, minimerade databasläsningar och -skrivningar och flyttade bort arbete från den kritiska vägen där det gick. Det gav visserligen upphov till intressanta produktlösningar som bättre tålde databasproblem, men det gjorde också produkterna mer komplexa och bromsade produktutvecklingen. Därmed uppfyllde vi inte Habitats mål: snabb produktutveckling utan att behöva förstå databasen.

Detta har varit ett stort fokus för oss under 2026. Vi har utvecklat en strategi i flera lager för att optimera läsprestandan, eftersom läsningar står för över 90 % av Habitats anrop:

Vi har flera Azure Cosmos DB-konton i olika Azure-regioner runt om i världen för användare med krav på datahemvist. Även för användare utan strikta krav på datahemvist ger lagring nära användarna en bättre upplevelse genom lägre latens.

I praktiken kan vi inte göra detta i någon större utsträckning utöver fall med krav på datahemvist, eftersom placeringen begränsas av den fysiska molnkapaciteten. Våra datamängder är så stora att många regioner inte kan rymma den enorma lagringsvolym som krävs för deras andel av användartrafiken.

I regioner med begränsad datacenterkapacitet, elförsörjning eller kylning står vi ibland inför ett direkt vägval: reservera kapacitet för samlokaliserad lagring och lägre Habitat-latens, eller använda kapaciteten för mer beräkningskraft för anropshantering och skicka lagringsanrop längre bort.

Placeringsbeslut blir därför ofta en produktavvägning mellan A) optimerad latens för olika produkter och användargrupper och B) ren lagrings- och beräkningskapacitet.

För de mest latenskritiska arbetsbelastningarna, som autentiseringsmetadata som behövs vid varje anrop, minskar vi tur- och returtiden (RTT) mellan beräkningsresurserna och Habitat med Azure Cosmos DB-konton som replikeras till många sekundära regioner. Vissa konton replikeras till alla 40 Azure-regioner där vi hanterar trafik, andra till minst en region per kontinent.

Vi har behövt bygga in ett transparent lager för dataflytt och routning i Habitat tidigare än planerat, så att vi kan flytta datamängder mellan konton med olika replikeringstopologier.

Även denna metod begränsas dock i slutändan av kapaciteten och används därför bara för ett fåtal utvalda datamängder.

Habitats arbetsbelastningar domineras av läsningar. Applikationer hämtar ständigt inställningar, tillstånd och andra egenskaper. En oproportionerligt stor del av trafiken gäller en relativt liten aktiv datamängd av typer som används ofta. Det gör systemet särskilt väl lämpat för distribuerad cachelagring. Cachelagring förbättrar prestandan i infrastruktur med en enda region, men vinsterna blir ännu större över flera regioner, där den kan ”dölja” latensen mellan regioner.

Vi har integrerat ett distribuerat lookaside-cachelager i Habitat. Det lagrar en kopia av nyligen använda objekt och kanter på Valkey-servrar i vår infrastruktur, nära där användaranrop behandlas. Vanligtvis använder sådana cachar en livslängd (TTL) som balanserar träffgrad mot inaktuella data. Korta TTL:er minskar risken för inaktuella data men begränsar nyttan med cachelagring, eftersom poster snabbt försvinner ur cachen och måste hämtas oftare. Längre TTL:er ger högre träffgrad, men levererar inaktuella data under längre perioder. Det försämrar användarupplevelsen och gör produkternas beteende oförutsägbart.

Ett annat sätt är att uttryckligen invalidera cacheposter när applikationen skriver till samma underliggande data. Det håller cachade data betydligt mer aktuella, men kan vara svårt att implementera korrekt. Metoden är också känslig för specialfall, som partiella fel, som lämnar cachen inaktuell. Drift i flera regioner förvärrar problemen: nätverken mellan regioner är mindre tillförlitliga, och kapplöpning kan uppstå mellan cachen och replikeringen av den underliggande lagringen. Kompletterar man med TTL:er begränsas hur länge data kan vara inaktuella, men samma grundläggande TTL-avvägning som ovan kvarstår.

Vi har valt en mer avancerad metod för invalidering, inspirerad av system som Metas TAO. Habitats integrerade cache använder ändringsdatainsamling (CDC) via Azure Cosmos DB:s ändringsflöde för att sprida invalideringar globalt inom några sekunder. Det ger hög träffgrad med låg grad av inaktuella data. En tjänst i vår infrastruktur läser ändringsflödet och invaliderar poster i de lokala cacharna när underliggande data uppdateras. Nästa läsning ger då en cachemiss, och cachen fylls med den senaste versionen av data.

Vi har också sänkt latensen avsevärt genom att minska omkostnaderna i själva Habitat-tjänsten. Vi skrev om koden i Rust, som ger bättre prestanda än den ursprungliga Python-koden.

Tillsammans har dessa ändringar sänkt vår totala globala läslatens vid p50 från cirka 120 ms till cirka 10 ms – en förbättring med en faktor på 12 sedan vi började fokusera på prestanda tidigare i år.

Cachelagring har sänkt medianlatensen dramatiskt, men de långsammaste anropen kräver fortfarande att inte cachade data hämtas från underliggande lagring, ofta i avlägsna regioner. När mer kapacitet tas i drift och vi gör lagringen effektivare planerar vi att ta itu med en mer grundläggande utmaning: att redan från början placera data närmare den plats där de ska användas.

Tillförlitlig och skalbar CDC – att sprida databasändringar till nedströms system – är en viktig komponent i mer än bara Habitats cachestrategi. Miljontals insamlade ändringar per sekund från tusentals containrar och miljontals containerpartitioner flödar genom över hundra Kafka-topics. De driver även sekundära index med eventualkonsistens, pipelines för dataflytt, offlineanalys och andra produktfunktioner i realtid. När vår underliggande infrastruktur har vuxit globalt har det blivit allt mer komplext att bevaka radändringar. Om en klient vill registrera en återanropsfunktion som körs när rader av dess typ ändras måste den bland annat först fastställa vilka Cosmos-konton och containrar som innehåller dess data och vilken CDC-tjänstinstans som bevakar dem i respektive region. Dessutom måste klienten skala CDC-tjänstens arbetsprocesser, Kafka och sin konsument korrekt. Vår CDC-plattform ska dölja allt detta för produktutvecklarna och i stället ge ett enkelt gränssnitt där klienter registrerar en funktion som ska anropas för ändrade rader. Vi sköter all bakomliggande infrastruktur och skalning.

Ett internt kontrollplan säkerställer löpande att ändringar samlas in från alla nödvändiga containrar, väljer vilka Cosmos-regioner som ska läsas och fördelar arbetet effektivt mellan tusentals arbetsprocesser i flera geografiska regioner. Genom att använda replikregioner och ge flödesläsningar lägre prioritet skyddar vi latenskänslig Habitat-trafik från insamlingsarbete i bakgrunden. I en så stor miljö uppstår ständigt kraschade arbetsprocesser, containerproblem, fel i lagringen av tidsbegränsade lås, ogiltig konfiguration och fel hos mottagare. Vi gjorde CDC-arbetsprocessernas livscykel och hanteringen av tidsbegränsade lås robustare, isolerade fel mellan flöden och byggde skydd för konfigurationsändringar och utrullningar. Vi använder köer för olevererbara meddelanden så att permanenta leveransfel inte blockerar kön. Vi klarar regionala avbrott genom att växla läsarna till alternativa Cosmos-regioner. I vår skala har vi till och med behövt ändra Azures CDC-SDK för effektivare hantering av kontrollpunkter, genom att samla dem i minnet och bara skriva ut dem periodiskt.

Habitats interna användning av Azure Cosmos DB är komplex, men värdet har alltid legat i att dölja infrastrukturdetaljer för produktutvecklarna så att produktutvecklingen går snabbare. Detsamma gäller vår CDC-plattform.

Ett litet team kunde stödja en snabbt växande lagringsplattform genom att avsiktligt begränsa lagrings-API:t, fortsätta skala Python-tjänsten och prioritera de mest akuta tekniska utmaningarna. Vi fokuserade först på tillförlitlighet för verksamhetskritisk produkttrafik, sedan på läsprestanda för användare världen över och slutligen på effektiv drift i stor skala. Detta möjliggjorde snabb tillväxt och nya användningsfall, samtidigt som tillförlitlighet, prestanda och produktutvecklingstakt förbättrades.

För att skala Habitat och konversationslagringen för nästa miljard användare måste vi lösa svårigheterna med att replikera våra data över infrastrukturen i ännu större skala. För att förekomma detta har vi börjat bygga ett eget onlinelagringssystem i exabyteskala, optimerat för Habitats skrymmande datatyper. Systemet är under utveckling och kombinerar RocksDB Cloud-kärnan från Rockset med Raft-baserad replikering. Det implementerar samma dokumentmodell som Azure Cosmos DB, men använder disaggregerad lagring och fysisk replikering för att minska behovet av flashkapacitet, i utbyte mot lägre maximal QPS.

Vill du arbeta med den här typen av datainfrastruktur i banbrytande skala? Se våra lediga tjänster⁠.