Szybkie skalowanie magazynu online dla ponad miliarda użytkowników ChatGPT

Każdy produkt OpenAI wymaga szybkiego i niezawodnego dostępu do danych — niezależnie od tego, czy ktoś się loguje, sprawdza ustawienia Codex, czy rozpoczyna nową rozmowę w ChatGPT. Każda z tych czynności może wymagać wielu osobnych odczytów danych, zanim produkt zareaguje. Jeśli te żądania są powolne, produkt wydaje się działać wolno. Jeśli te żądania się nie powiodą, produkt całkowicie przestaje działać.

Habitat to zbudowana przez nas platforma magazynowa online, która zapewnia produktom OpenAI szybki i niezawodny dostęp do potrzebnych informacji. Habitat obsługuje obecnie ponad 70 milionów żądań na sekundę i wspiera produkty używane co tydzień przez ponad miliard osób w niemal 40 regionach geograficznych. Habitat uruchomiono po raz pierwszy do obsługi GPT podczas DevDay 2023 jako prostą bibliotekę kliencką w Pythonie, połączoną z jedną bazą danych. Dziś jest to złożony system rozproszony obsługujący ponad 500 petabajtów danych.

Budowanie i obsługa infrastruktury w tej skali nie są łatwe, ale też nie stanowią szczególnie trudnego wyzwania. Naszą sytuację wyróżniało bezprecedensowe tempo skalowania niezbędnego do obsługi ogromnego wzrostu liczby użytkowników i popytu na produkty przy jednoczesnym budowaniu dojrzałej platformy. Inżynierowie systemowi często projektują rozwiązania na 10-krotnie większą skalę i liczą, że wystarczą one na kilka lat przygotowań do kolejnego 10-krotnego wzrostu. W naszym przypadku przez ostatnie trzy lata rośliśmy ponad 10-krotnie rok do roku. Dlatego budowanie i obsługa Habitat stały się ciągiem decyzji taktycznych podejmowanych we właściwej kolejności: analizowaliśmy każdy komponent na najniższym poziomie, aby maksymalnie wykorzystać istniejący stos, a jednocześnie odpieraliśmy kryzysy pojemności magazynu i mocy obliczeniowej, zyskując czas na fundamentalne inwestycje.

Wraz z rozwojem OpenAI musiał rosnąć także Habitat: najpierw osiągnąć niezawodność niezbędną do obsługi krytycznego ruchu produktów, potem szybkość potrzebną użytkownikom na całym świecie, a wreszcie sprawnie działać na ogromną skalę. To pierwszy z dwóch wpisów o skalowaniu naszego magazynu online. Opisujemy w nim ewolucję Habitat, powody przekształcenia biblioteki w usługę oraz sposób, w jaki rozwinęliśmy usługę napisaną w nietypowym dla tego zastosowania języku — Pythonie — w niezawodną warstwę platformy magazynowej.

W kolejnym wpisie szczegółowo omówimy niezawodność wielodostępności na dużą skalę, warstwową strategię optymalizacji odczytu oraz rozwój współpracy z Azure Cosmos DB, dzięki któremu niezawodnie obsługujemy bezprecedensowy popyt.

Habitat powstał na bazie prostej idei: inżynierowie produktów nie powinni zajmować się zarządzaniem bazami danych. Habitat uruchomiono po raz pierwszy do obsługi GPT podczas DevDay 2023 jako małą bibliotekę Python współpracującą z głównym serwerem ChatGPT. Obsługiwała niewielki zestaw operacji, które wewnętrznie odwzorowywano na operacje bazy danych Azure Cosmos DB.

Biblioteka miała zapewnić zespołom produktowym prosty sposób zapisywania i pobierania danych bez konieczności poznawania szczegółów warstwy bazowej. Habitat wykonywał wszystkie niezbędne czynności: ustalał rodzaj danych, ich źródło lub miejsce docelowe, dopuszczalność żądania i wiele więcej.

Inżynierowie produktów nie muszą zajmować się wyszukiwaniem schematów, trasowaniem, autoryzacją, szyfrowaniem, serializacją, kształtowaniem żądań ani pulami połączeń. Nie muszą nawet rozważać, skąd pochodzą dane — z Azure Cosmos DB, pamięci podręcznych czy innych rodzajów magazynów.

Ta biblioteka Python działała dobrze i została szybko przyjęta przez inżynierów produktów OpenAI, mimo braku skoordynowanych działań zmierzających do odejścia od samodzielnego korzystania z baz Postgres i Azure Cosmos DB.

Wraz ze zmianą potrzeb produktowych programiści mogli też łatwo dodawać do współdzielonej biblioteki obsługę takich funkcji jak buforowanie po stronie klienta, kompresja czy szyfrowanie.

W połowie 2025 roku Habitat osiągnął granice możliwości implementacji klienckiej. Wraz ze wzrostem złożoności warstwy Habitat i liczby usług OpenAI zachowanie zgodności wstecznej przy zmianach protokołu stało się niewykonalne.

W pewnym przypadku chcieliśmy ograniczyć zasięg skutków awarii pojedynczego regionu dla naszych najważniejszych zbiorów danych, przenosząc je do zestawu regionalnie rozproszonych kont Azure Cosmos DB. Zmiana wymagała dodania do klienta logiki trasowania, początkowo wyłączonej flagą funkcji, wdrożenia jej u wszystkich klientów, a następnie włączenia flagi.

Koordynacja wdrożeń w dziesiątkach usług i współpraca z każdym zespołem trwały kilka dni. Przed włączeniem funkcji uznaliśmy, że chcemy dodać dublowanie ruchu, aby sprawdzić poprawność logiki partycjonowania. Wdrożenie tego zajęło kolejne dwa dni. Poprawka wykrytego błędu? Kolejne dwa dni. Gdy wreszcie byliśmy gotowi włączyć flagę, jeden z zespołów z niezwiązanych powodów przywrócił swoją usługę do wersji z wcześniejszym, wadliwym klientem, wywołując awarię, której tak usilnie próbowaliśmy uniknąć.

Zmiany biblioteki klienckiej wymagały złożonej koordynacji dziesiątek usług, a proces ten stawał się coraz bardziej kruchy, nieefektywny i podatny na awarie operacyjne. Aby ograniczyć ten operacyjny efekt rozgałęzienia w przyszłych wdrożeniach, postanowiliśmy wydzielić Habitat jako osobną usługę.

Wydzielenie logiki magazynu do samodzielnej usługi zapewniło jeden punkt kontroli wdrożeń, obserwowalności i ulepszeń platformy. Zamiast zarządzać rozproszonymi aktualizacjami mogliśmy wprowadzać ulepszenia centralnie, zapewniając natychmiastowe korzyści każdemu produktowi OpenAI.

Scentralizowana usługa zapewnia również jeden punkt, w którym możemy wdrażać najsilniejsze mechanizmy bezpieczeństwa i prywatności danych. W usłudze Habitat możemy centralnie egzekwować zasady kontroli dostępu, rejestrować zdarzenia audytowe i ograniczać dostęp do bazowych zasobów magazynowych, takich jak Azure Cosmos DB. Habitat odgrywa kluczową rolę w ochronie danych użytkowników i zapobieganiu nieautoryzowanemu dostępowi podmiotów zewnętrznych, wewnętrznych oraz agentów.

Wiedzieliśmy, że potrzebujemy usługi, ale nie chcieliśmy jeszcze odchodzić od Pythona, mimo dodatkowego narzutu związanego z użyciem go w usłudze. Użycie Pythona w usłudze o wysokiej przepustowości zwiększyło opóźnienia sieciowe oraz znacznie podniosło koszty skalowania CPU i pamięci w porównaniu z lokalnym wykonywaniem kodu biblioteki. Zdawaliśmy sobie też sprawę, że nieefektywność Pythona będzie nie do przyjęcia przy 100-krotnie większej skali, więc późniejsze przepisanie usługi było niemal pewne.

Traktowaliśmy to jednak jako strategiczne zaciągnięcie długu technicznego. Naszym głównym celem nie była wtedy optymalizacja kosztów ani zasobów, lecz odblokowanie pracy twórców produktów i ustabilizowanie platformy. Akceptując krótkoterminowe kompromisy wydajnościowe usługi Python, mogliśmy zająć się pilniejszymi wyzwaniami, ustalić podstawowe interfejsy API i zbudować solidną infrastrukturę.

Założyliśmy też, że szybki rozwój naszych modeli do programowania uprości w przyszłości techniczną stronę migracji. Postawiliśmy na to, że gdy pełne odejście od Pythona stanie się konieczne, Codex i GPT umożliwią taką migrację. Ostatecznie mieliśmy rację.

Uruchomienie Habitat jako usługi Python nie było optymalne pod względem wydajności, ale stanowiło konieczny wybór. Python pozwala nam działać szybko, ale nie mogliśmy przez to porzucić ostrożności i zaakceptować znacznie większych opóźnień. Gdy przeciętne żądanie użytkownika powoduje setki wywołań bazy danych, użytkownik odczuwa czas tego najwolniejszego. Ustaliliśmy, że głównym wyzwaniem związanym z usługą Python w tej skali jest zarządzanie opóźnieniami ogona rozkładu.

Asyncio umożliwia Pythonowi współbieżne wykonywanie zadań zależnych od operacji wejścia/wyjścia, ale nie omija blokady GIL ani nie zapewnia równoległości na CPU. Oprócz intensywnego pod względem operacji wejścia/wyjścia przekazywania żądań Habitat wykonuje wiele operacji obciążających CPU oraz zadań działających w tle: trasowanie, kompresję, szyfrowanie, obliczanie sum kontrolnych, kontrolę kondycji usług podrzędnych, dublowanie żądań i hedging.

Przy tak wielu obciążeniach intensywnie wykorzystujących CPU i zadaniach działających w tle opóźnienie planowania asyncio może łatwo stać się główną przyczyną opóźnień żądań w ogonie rozkładu. Przed optymalizacją poprzedzającą pierwsze uruchomienie usługi ślady żądań o opóźnieniu p99 i wyższym pokazywały, że choć magazyn podrzędny odpowiadał szybko, żądania często zatrzymywały się, czekając na ponowne zaplanowanie odpowiedniej korutyny, która miała przeanalizować odpowiedź.

W przypadku usług Python w OpenAI kluczowe jest nie tylko mierzenie standardowych wskaźników wykorzystania i nasycenia pamięci, CPU, sieci oraz dysku, lecz także monitorowanie pętli asyncio i jej obciążenia, a następnie odpowiednie dostrajanie systemu.

Okresowo planując zadania w tle i rejestrując różnicę między oczekiwanym a rzeczywistym czasem wykonania, możemy empirycznie mierzyć w czasie rzeczywistym opóźnienie planowania pętli zdarzeń. Przy wysokim wykorzystaniu i wielu kosztownych zadaniach nawet niewielka liczba współbieżnych żądań na proces wystarcza, by wywołać znaczne wahania planowania — do setek milisekund, a w skrajnych przypadkach kilku sekund.

Dlatego każdy proces obsługuje tylko niewielką liczbę współbieżnych żądań, a zamiast tego ogromnie zwiększamy liczbę procesów roboczych Pythona.

Podczas pierwszego uruchomienia usługi profilowanie CPU na żywo ujawniło jedną z głównych przyczyn dużych opóźnień asyncio (i wynikających z nich opóźnień ogona rozkładu): okresowe analizowanie konfiguracji flag funkcji w formacie JSON za pomocą Statsig — narzędzia do zarządzania flagami funkcji, testów A/B i nie tylko.

Domyślnie Statsig co minutę, bez losowego przesunięcia, sprawdzał dostępność odświeżonych konfiguracji, które obejmowały wszystkie reguły produkcyjne ze wszystkich usług. Niezależnie podjęto decyzję architektoniczną, aby w każdym podzie uruchamiać do ośmiu procesów Pythona, zwiększając wykorzystanie CPU i zmniejszając opóźnienia. W efekcie co minutę następował moment, w którym wszystkie procesy robocze każdego poda wstrzymywały obsługę trwających żądań i zużywały cykle CPU na analizowanie ogromnego pliku konfiguracyjnego.

Gdy profilowanie CPU pomogło ustalić źródło problemu, rozwiązanie było proste: wdrożyć mniejszą, ukierunkowaną konfigurację, wydłużyć interwał odświeżania i dodać losowe przesunięcie do takich zadań w tle.

Aby utrzymać małe opóźnienie asyncio, trzeba również dobrze równoważyć żądania między procesami serwera. Bez odpowiedniego dostrojenia pule połączeń mogą działać wbrew temu celowi.

Przy puli połączeń po stronie klienta pojedynczy proces klienta wykonujący wiele współbieżnych żądań może nawiązać zaledwie kilka połączeń z serwerem i kierować całe obciążenie tylko do kilku procesów. Przed zmianą sposobu równoważenia obciążenia wykorzystanie naszej usługi było bardzo nierówne: niektóre skrajnie obciążone procesy obsługiwały 5–10 razy więcej współbieżnych żądań niż wynosiła średnia.

Odkryliśmy to przypadkiem, gdy mimo zatrzymania klienta przeciążającego część usługi niektóre procesy pozostawały w pogorszonym stanie długo po ustaniu gwałtownego ruchu. Co więcej, stan tych procesów pogarszał się lawinowo: otrzymywały coraz więcej żądań, dopóki ich nie zrestartowaliśmy. Po przeciążeniu poda pewien mechanizm kierował do niego jeszcze więcej ruchu. Była to klasa awarii dobrze znana części naszych współpracowników z wcześniejszej pracy: awaria metastabilna⁠(otwiera nowe okno).

Podejrzewaliśmy pulę połączeń. Przetestowaliśmy tę hipotezę, ograniczając maksymalny czas ponownego użycia połączenia, co rzeczywiście ograniczyło degradację i potwierdziło właściwy kierunek analizy. Dalsza analiza wykazała, że TCPConnector biblioteki aiohttp w Pythonie domyślnie używa połączeń w kolejności LIFO: do następnego żądania wybierane jest ostatnio zwrócone połączenie. Zwykle jest to rozsądne ustawienie domyślne: ponowne użycie niedawnych połączeń pozwala dodatkowym połączeniom utworzonym na czas gwałtownego ruchu wygasnąć z powodu bezczynności, zmniejszając narzut ich utrzymania. W naszym przypadku spowodowało to awarię metastabilną. Podczas nagłego wzrostu ruchu żądania kierowane do wolniejszych, przeciążonych serwerów później zwracały połączenia do puli, dlatego kolejne żądania częściej je wybierały, stopniowo koncentrując coraz więcej ruchu na podach, które już miały problemy. Zmiana puli połączeń na ponowne użycie połączeń w kolejności FIFO przerwała tę pętlę sprzężenia zwrotnego, a także zmniejszyła zróżnicowanie liczby żądań w stanie stabilnym.

Obecnie w całej infrastrukturze OpenAI polegamy głównie na Istio i Envoy, które zapewniają pule połączeń oraz lepsze strategie równoważenia uwzględniające obciążenie serwerów, co pozwala całkowicie uniknąć tego problemu.

Skutkiem ubocznym optymalizacji pod kątem małego opóźnienia asyncio i uruchamiania tak wielu procesów Pythona jest możliwość łatwego przeciążenia zależności podrzędnych ogromną liczbą połączeń (zjawiskiem zwanym „thundering herd”).

Zwykłe codzienne wdrożenie, jeśli nie zostanie celowo spowolnione, może powodować znaczne obciążenie CPU wskutek ciągłego zamykania i otwierania połączeń. Z kolei wyciek połączeń może wyłączyć sieć przez nasycenie bramy NAT. Takie problemy występują również w innych usługach, ale dziesięciokrotnie większa liczba procesów znacznie obniża próg ich wywołania. Często prowadzi to do nasycenia zasobów sieciowych, czego klienci — sądząc wyłącznie po przepustowości — nie spodziewają się w stanie stabilnym.

Korzystamy też z Envoy, aby maksymalizować agregację połączeń. Envoy przekształca połączenia HTTP/1 Pythona w HTTP/2, co pozwala korzystać z multipleksowania, a następnie grupuje te połączenia w pule i wydłuża ich czas życia. Envoy zapewnia też centralne miejsce do wdrażania limitów szybkości i bezpieczników, które byłyby mniej skuteczne w każdym samodzielnym procesie Pythona.

Jednym z powodów, dla których mogliśmy tak znacznie skalować Pythona, był ograniczony interfejs API Habitat, dzięki któremu koszt żądań pozostaje przewidywalny. Zamiast pozwalać klientom tworzyć dowolne zapytania SQL, które mogłyby powodować skanowanie dużych tabel lub złączenia wielu tabel, Habitat udostępnia prosty interfejs API NoSQL. Brak rozbudowanego interfejsu API jest świadomym kompromisem w projekcie Habitat.

Optymalizujemy system pod kątem prostych, przewidywalnych żądań wymagających stałej ilości pracy. Z naszego doświadczenia wynika, że takie systemy znacznie łatwiej skalować, a trudno użyć ich niewłaściwie lub popełnić błąd. Żądania o nieprzewidywalnym rozgałęzieniu są niebezpieczne operacyjnie: komplikują izolację i równoważenie obciążenia oraz powodują gwałtowne skoki opóźnień, które utrudniają skalowanie zarówno usługi, jak i jej klientów.

Zanim przeszliśmy na Habitat i Azure Cosmos DB, większość danych online OpenAI była przechowywana w Postgresie. Można było wtedy łatwo sprawdzać wszystkie zmiany zapytań i schematów, aby przed wdrożeniem produkcyjnym upewnić się, że działają prawidłowo i korzystają z indeksowanych danych. Wraz z rozwojem zespołu i produktów szybko stało się to niewykonalne i często powodowało awarie, gdy jedno nowe, kosztowne zapytanie na intensywnie używanej ścieżce wyłączało bazę danych.

Problem polega na dysproporcji kosztów: łatwo i tanio napisać zapytania SQL, których wykonanie jest trudne i kosztowne. Habitat pozwala tego uniknąć i sprawia, że kosztowne zapytania są wyjątkowo łatwe do rozpoznania po stronie klienta. Nie ma nieograniczonych zapytań, które mogłyby przeciążyć Habitat, a złożone złączenia i przechodzenie po grafie wymagają od zespołów produktowych wykonania części ciężkiej pracy, co sprzyja wydajniejszym projektom.

Habitat udostępnia interfejs API NoSQL oparty na definiowanych przez klienta typach obiektów i krawędzi, inspirowany systemem TAO⁠(otwiera nowe okno). Klienci z góry definiują obiekty, krawędzie i relacje między nimi, ale nie zawartość poszczególnych typów. Powstałe relacje przypominają graf, ale sam Habitat nie obsługuje typowych zapytań przechodzących po grafie poza odpytywaniem bezpośrednich krawędzi konkretnego obiektu.

Dzielimy ten graf tak, aby każdy obiekt i odpowiadające mu krawędzie znajdowały się w tej samej partycji warstwy magazynu, ale na poziomie bazy danych nie próbujemy celowo umieszczać razem obiektów i obiektów zdalnych wskazywanych przez ich krawędzie. Dzięki temu model łatwo podzielić na potrzeby skalowania poziomego, ale przechodzenie po grafie jest nieefektywne, ponieważ każdy skok między obiektami może wymagać pobrania danych z dwóch zupełnie różnych kont Azure Cosmos DB w różnych regionach.

Klientom o bardziej złożonych potrzebach udostępniamy dodatkowy widok offline Habitat za pośrednictwem Rockset. Korzystamy z przechwytywania zmian danych (CDC), aby niemal w czasie rzeczywistym przesyłać zmiany z magazynu online do odizolowanych instancji Rockset. Każdy zespół kliencki odpowiada za skalowanie własnej instancji Rockset pod kątem złożonych zapytań.

Udostępnianie Rockset powoduje dodatkowe utrudnienia dla klientów, ale obecnie uważamy ten kompromis za właściwy: proste zapytania są domyślne, a osoby potrzebujące złożonych zapytań mają alternatywę. Taka architektura izoluje nasz magazyn online od obciążeń analitycznych i wyszukiwawczych wymagających intensywnego odczytu.

Odłożenie przepisania usługi Python o rok pozwoliło nam podczas gwałtownego wzrostu skupić się na pilniejszych i bardziej znaczących wyzwaniach. Gdy platforma dojrzała, a nasz wzrost nadal przyspieszał, Habitat był już drugą co do liczby rdzeni usługą w OpenAI (i czwartą pod względem wykorzystania Envoy). Nadszedł czas, by odejść od Pythona. W szczytowym okresie Python pomagał nam obsługiwać ponad 20 milionów żądań na sekundę.

W drugim kwartale 2026 roku zaledwie dwóch inżynierów, wspieranych przez Codex i GPT‑5.5, przepisało całą usługę w języku Rust. Nowa usługa Rust obsługuje już 95% naszych żądań produkcyjnych. W nadchodzących tygodniach całkowicie wycofamy Pythona. Nasze dane pokazują, że usługa Rust jest 6 razy bardziej wydajna pod względem wykorzystania CPU i 15 razy bardziej wydajna pod względem wykorzystania pamięci niż wersja Python przy znacznie niższych opóźnieniach średnich i w ogonie rozkładu. Więcej wniosków przedstawimy w przyszłym wpisie.

Usługa napisana wcześniej w Pythonie, a teraz w Ruście, to tylko jeden z elementów Habitat. W drugiej części tej serii, opisującej szybkie skalowanie magazynu online do obsługi ponad miliarda użytkowników ChatGPT, omówimy warstwę magazynu oraz sposób, w jaki Habitat obsługuje ponad 500 petabajtów danych i ponad 70 milionów żądań na sekundę.

Jeśli chcesz pracować nad systemami OLTP w pionierskiej skali i interesuje Cię taka inżynieria, sprawdź tę ofertę pracy w naszym zespole⁠.