1 млрд-тан астам ChatGPT пайдаланушысы үшін онлайн сақтау жүйесін жылдам масштабтау

Біреу жүйеге кірсе де, Codex параметрлерін тексерсе де немесе ChatGPT‑де жаңа әңгіме бастаса да, әр OpenAI өнімі деректерге жылдам әрі сенімді қол жеткізуге тәуелді. Өнім жауап бермес бұрын осы әрекеттердің әрқайсысы деректерді бірнеше рет бөлек іздеуді қажет етуі мүмкін. Бұл сұраулар баяу болса, өнім де баяу сезіледі. Бұл сұраулар орындалмаса, өнім мүлдем жұмысын тоқтатады.

Habitat — OpenAI өнімдері қажетті ақпаратқа жылдам әрі сенімді қол жеткізуі үшін біз жасаған онлайн сақтау платформасы. Қазір Habitat секундына 70 миллионнан астам сұрауды өңдеп, 40-қа жуық географиялық аймақта апта сайын 1 миллиардтан астам адам пайдаланатын өнімдерді қолдайды. Habitat алғаш рет DevDay 2023 шарасында GPTs өнімдерін қолдау үшін бір дерекқорға қосылған қарапайым клиенттік Python кітапханасы ретінде іске қосылды. Бүгінде ол 500 петабайттан астам дерекке қол жеткізуді қамтамасыз ететін күрделі таратылған жүйе.

Мұндай ауқымдағы инфрақұрылымды құру және пайдалану оңай емес, бірақ аса қиын да емес. Жағдайымызды ерекше еткен нәрсе — жетілген платформаны қатар құра отырып, пайдаланушылар саны мен өнім сұранысының таңғаларлық өсуін қолдау үшін бұрын-соңды болмаған қарқынмен масштабтау қажеттігі. Жүйе инженерлері көбіне келесі 10 есе өсімге дайындала отырып, жүйені 10 есе ауқымға құрады және ол бірнеше жылға жетеді деп үміттенеді. Ал біз соңғы үш жылда жыл сайын 10 еседен астам өстік. Сондықтан Habitat-ты құру және пайдалану тактикалық шешімдер мен дұрыс реттіліктен тұрды: негізгі инвестицияларға уақыт ұту үшін сақтау мен есептеу қуатының тапшылығын еңсере отырып, қолданыстағы стек мүмкіндігін барынша пайдалану мақсатында әр компонентті ең төменгі деңгейіне дейін түсіну.

OpenAI өскен сайын Habitat та бірге өсуге тиіс болды: алдымен аса маңызды өнім трафигі үшін жеткілікті сенімді, кейін жаһандық пайдаланушылар үшін жеткілікті жылдам болып, ақырында алып ауқымда шебер жұмыс істейтін деңгейге жетті. Бұл жазба — онлайн сақтау жүйесін қалай масштабтағанымыз туралы екі бөлімді топтаманың алғашқысы. Бұл жазбада Habitat-тың қалай дамығанын, оны неліктен кітапханадан қызметке айналдырғанымызды және серверлік стекте сирек қолданылатын Python тілінде жазылған қызметті қалай сенімді сақтау платформасының қабатына айналдырғанымызды баяндаймыз.

Келесі жазбада көп клиентті ортаның ауқымдағы сенімділігін қалай қамтамасыз еткенімізді, оқу өнімділігін оңтайландырудың қабатты стратегиясын және бұрын-соңды болмаған сұранысты сенімді өңдеу үшін Azure Cosmos DB-мен серіктестікті қалай кеңейткенімізді егжей-тегжейлі қарастырамыз.

Habitat қарапайым идеядан басталды: өнім инженерлері дерекқорды басқару туралы ойламауы керек. Habitat алғаш рет DevDay 2023 шарасында GPTs өнімдерін қолдау үшін ChatGPT‑дің негізгі серверімен әрекеттесетін шағын Python кітапханасы ретінде іске қосылды. Ол ішкі жағында Azure Cosmos DB дерекқор қолданбасына сәйкестендірілген шағын операциялар жиынын қолдады.

Кітапхананың міндеті — өнім командаларына негізгі техникалық егжей-тегжейлерді меңгермей-ақ деректерді сақтау мен алудың қарапайым жолын ұсыну. Habitat қажетті жұмысты өз мойнына алды: дерек түрін, оның қайдан келуі не қайда баруы керектігін, сұрауға рұқсат бар-жоғын және басқасын анықтады.

Өнім инженерлеріне схеманы іздеу, бағыттау, авторизация, шифрлау, сериализация, сұрауды қалыптастыру және қосылымдарды біріктіру жайын ойлаудың қажеті болмады. Тіпті деректің Azure Cosmos DB-ден, кэштерден не басқа сақтау түрлерінен келетінін ескерудің де қажеті жоқ еді.

Бұл Python кітапханасы жақсы жұмыс істеді және Postgres пен Azure Cosmos DB-ді өз бетінше пайдаланудан бас тартуға бағытталған орталықтандырылған бастама болмаса да, OpenAI өнім инженерлері Habitat-ты тез қабылдады.

Өнім қажеттіліктері өзгерген сайын, өнім әзірлеушілері ортақ кітапханаға клиенттік кэштеу, сығу немесе шифрлау сияқты мүмкіндіктерді оңай қоса алды.

2025 жылдың ортасына қарай Habitat клиенттік іске асыру ретіндегі шегіне жетті. Habitat қабаты күрделеніп, OpenAI қызметтерінің саны артқан сайын, кері үйлесімді протокол өзгерістерін енгізу мүмкін болмай қалды.

Бір жағдайда аса маңызды деректер жиындарын аймақтарға таратылған Azure Cosmos DB тіркелгілеріне көшіру арқылы кез келген бір аймақтағы ақаудың таралу ауқымын азайтқымыз келді. Бұл өзгеріс үшін клиентке функция жалаушасының артында өшірілген қосымша бағыттау логикасын қосып, оның барлық клиентке өрістетілгеніне көз жеткізіп, кейін функция жалаушасын қосу қажет болды.

Ондаған қызметтегі өрістетулерді үйлестіру және оны іске қосу үшін әр командамен жұмыс істеу бірнеше күнге созылды. Оны қоспас бұрын бөлу логикасының дұрыстығына көз жеткізу үшін көлеңкелеуді енгізу керек екенін түсіндік. Оны өрістетуге тағы бірнеше күн кетті. Қате екенін кейін түсінген тұсты түзету ше? Оған тағы бірнеше күн. Ақырында жалаушаны қосуға дайын болғанда, командалардың бірі қатысы жоқ себеппен өз қызметін бұрынғы ақаулы клиент нұсқасына қайтарды да, біз барынша болдырмауға тырысқан үзіліс орын алды.

Клиенттік кітапхананы өзгерту ондаған қызмет арасында күрделі үйлестіруді талап етті; бұл процесс барған сайын осал, тиімсіз және пайдалану ақауларына бейім бола түсті. Болашақ өрістетулердегі осы операциялық таралуды азайту үшін Habitat-ты жеке қызметке айналдыруды шештік.

Сақтау логикасын дербес қызметке бөлу арқылы өрістету, бақыланғыштық және платформаны жетілдіру үшін бірыңғай басқару нүктесін құрдық. Бөлшектенген жаңартуларды басқарудың орнына, жақсартуларды орталықтан енгізіп, әр OpenAI өніміне дереу пайда бере алдық.

Орталықтандырылған қызмет деректер қауіпсіздігі мен құпиялылықтың ең мықты базалық тетіктерін ұсынатын бірыңғай бақылау нүктесін де береді. Habitat қызметінде қол жеткізуді басқару саясаттарын орталықтан орындап, аудит журналын жүргізіп, Azure Cosmos DB сияқты негізгі сақтау ресурстарына қатынасты шектей аламыз. Habitat пайдаланушы деректерін қорғауда және сыртқы, ішкі әрі агент субъектілерінің рұқсатсыз қол жеткізуіне жол бермеуде шешуші рөл атқарады.

Бізге қызмет қажет екенін білдік, бірақ Python қызмет ретінде қосымша шығын келтірсе де, одан әзірге көшкіміз келмеді. Өткізу қабілеті жоғары қызметте Python қолдану жергілікті кітапхананы орындаумен салыстырғанда желі кідірісін арттырып, CPU мен жадты масштабтауға елеулі шығын қосты. Бұған қоса, Python тиімсіздігі 100 есе ауқымда қолайсыз болатынын түсіндік, сондықтан түбінде қайта жазу қажет болары анық еді.

Алайда біз мұны техникалық қарызды саналы түрде қабылдау деп қарастырдық. Ол кездегі басты мақсатымыз шығынды не ресурстарды оңтайландыру емес, өнім әзірлеушілеріне жол ашып, платформаның тұрақтылығына қол жеткізу еді. Python қызметінің өнімділік тұрғысындағы ымыраларын қысқа мерзімге қабылдау арқылы біз шұғыл мәселелерге басымдық беріп, негізгі API интерфейстерімізді орнықтырып, сенімді инфрақұрылым құра алдық.

Сондай-ақ өз кодтау модельдеріміздің жылдам дамуы болашақтағы техникалық жолды жеңілдетеді деп есептелген тәуекелге бардық. Python-нан толық көшу қажет болғанда, Codex пен GPT бұл көшуді жүзеге асыруға мүмкіндік береді деп сендік. Ақырында бұл болжам дұрыс болып шықты.

Habitat-ты Python қызметі ретінде іске қосу өнімділік жағынан оңтайлы болмағанымен, қажет таңдау еді. Python жылдам ілгерілеуге мүмкіндік береді, бірақ бұл сақтықты ұмытып, айтарлықтай ұзағырақ кідірістерге келісе салуға болады деген сөз емес. Пайдаланушының орташа сұрауы дерекқорға жүздеген рет жүгінсе, ол ең баяу сұраудың кідірісін сезеді. Біздің байқауымызша, Python қызметін осындай ауқымда іске қосудың негізгі қиындығы — шеткі кідірістерді басқару.

Asyncio Python-ға енгізу-шығаруға тәуелді жүктемелерді қатар орындауға көмектеседі, бірақ Python GIL шектеуін айналып өтіп, CPU параллелизмін қамтамасыз етпейді. Енгізу-шығаруы көп сұрауларды проксилеумен қатар, Habitat CPU-ді көп қажет ететін көптеген міндет пен фондық тапсырманы орындайды: бағыттау, сығу, шифрлау, бақылау сомасын есептеу, төменгі жүйелердің күйін тексеру, сұрауларды көлеңкелеу және сақтандыру сұрауларын жіберу.

Қызметімізде CPU-ді көп қажет ететін жүктемелер мен фондық тапсырмалар соншалық көп болғандықтан, asyncio жоспарлау кідірісі сұраулардың шеткі кідірісіндегі негізгі факторға оңай айналады. Қызметті алғаш іске қосар алдындағы баптауға дейін p99 және одан жоғары кідірісті сұраулар трассаларынан төменгі сақтау жүйесі жылдам жауап бергенімен, жауапты талдайтын корутина қайта жоспарланғанша сұраулардың жиі тұрып қалатынын көрдік.

OpenAI-дағы Python қызметтері үшін жад, CPU, желі және диск қолданысының стандартты жүктелу мен қанығу метрикаларын өлшеумен қатар, asyncio циклін және оның жүктеме деңгейін бақылап, соған сәйкес баптау аса маңызды деп санаймыз.

Фондық тапсырмаларды мерзімді жоспарлап, күтілетін және нақты орындалу уақытының айырмасын жазу арқылы оқиғалар циклінің жоспарлау кідірісін нақты уақытта эмпирикалық түрде өлшей аламыз. Жүктелу жоғары әрі ресурсты көп қажет ететін тапсырмалар көп болғанда, әр процестегі қатар орындалатын сұраулардың аз ғана санының өзі жүздеген миллисекундқа, ал кейбір шеткі жағдайларда бірнеше секундқа жететін елеулі жоспарлау ауытқуын туғызады.

Сондықтан әр процесте қатар орындалатын сұраулар санын аз ұстап, оның орнына Python жұмысшы процестерінің санын жаппай арттырамыз.

Қызметті алғаш іске қосқанда, жұмыс істеп тұрған қызметтің CPU профилін жасау арқылы asyncio кідірісінің жоғары болуының және соның салдарынан шеткі кідірістердің артуының бір түпкі себебін анықтадық: функция жалаушаларын басқаратын әрі A/B сынақтарын және басқа әрекеттерді орындауға мүмкіндік беретін Statsig құралы арқылы олардың конфигурацияларын мерзімді JSON талдау.

Әдепкіде Statsig жаңартылған конфигурацияларды әр минут сайын ауытқусыз сұрауға бапталған еді, ал конфигурацияда барлық қызметтегі бүкіл өндірістік ережелер қамтылды. Бұдан бөлек, CPU қолданысын арттырып, кідірісті азайту үшін әр pod-та 8-ге дейін Python процесін іске қосу туралы архитектуралық шешім қабылданды. Осының бәрі әр минут сайын әр pod-тағы барлық жұмысшы ағымдағы сұрауларды өңдеуді тоқтатып, CPU циклдерін алып конфигурация файлын талдауға жұмсайтын бір сәт болатынын білдірді.

CPU профилі мәселенің түпкі себебін анықтауға көмектескен соң, шешімі қарапайым болды: кішірек әрі нысаналы конфигурацияны өрістету, жаңарту аралығын ұзарту және осындай фондық тапсырмаларға аздап уақыт ауытқуын қосу.

asyncio кідірісін төмен ұстау үшін сұраулардың сервер процестері арасында дұрыс теңестірілуі де өте маңызды; бапталмаса, қосылымдарды пулға біріктіру бұған кері әсер етуі мүмкін.

Клиенттік қосылымдар пулын пайдаланғанда, көптеген сұрауды қатар орындайтын бір клиент процесі серверге санаулы ғана қосылым орнатып, нәтижесінде бүкіл жүктемесін санаулы процестерге жіберуі мүмкін. Жүктемені теңестіру тәсілін өзгертпей тұрып, қызметіміздегі жүктелу деңгейі қатты ауытқитын: ең көп жүктелген кейбір процестер орташа көрсеткішпен салыстырғанда қатар орындалатын сұрауларды 5–10 есе көп өңдейтін.

Мұны кездейсоқ оқиға кезінде анықтадық: қызметіміздің бір бөлігін шамадан тыс жүктеген клиентті тоқтатсақ та, процестердің бір бөлігі күрт трафик басылғаннан кейін де ұзақ уақыт нашар күйде қалды. Іс жүзінде бұл процестерді қайта іске қосқанға дейін олар барған сайын көбірек сұрау алып, күйі бақылаусыз нашарлай бергенін байқадық. Pod шамадан тыс жүктелген соң, әлдебір механизм оған одан да көп трафикті бекітіп жіберетін. Бұл кейбір әріптестеріміз алдыңғы жұмысынан жақсы білетін ақау түрі еді: метатұрақты ақау⁠(жаңа терезеде ашылады).

Қосылымдар пулы кінәлі деп күдіктеніп, қосылымды қайта пайдаланудың ең ұзақ мерзімін шектеу арқылы бұл болжамды тексердік. Бұл нашарлауды шынымен тежеп, зерттеу бағытымыздың дұрыстығын растады. Қосымша зерттеу Python-ның aiohttp TCPConnector компоненті әдепкіде қосылымдарды LIFO тәртібімен қайта пайдаланатынын көрсетті: келесі сұрау үшін ең соңғы қайтарылған қосылым таңдалады. Қалыпты жағдайда бұл орынды әдепкі тәсіл: жақында пайдаланылған қосылымдарды қайта пайдалану күрт трафикті өңдеу үшін жасалған артық қосылымдардың бос тұрып, күту уақыты аяқталған соң жабылуына мүмкіндік береді, осылайша артық қосылымдарды сақтауға кететін шығын азаяды. Алайда бұл жағдайда ол бізде метатұрақты ақау туғызды. Сұраулар күрт артқанда, баяу әрі шамадан тыс жүктелген серверлерге жіберілген сұраулардың қосылымдары пулға кешірек қайтарылатын. Сондықтан кейінгі сұраулар сол қосылымдарды жиірек таңдап, жүктемесі онсыз да жоғары pod-тарға трафикті біртіндеп көбірек шоғырландырды. Қосылымдар пулын FIFO тәртібімен қайта пайдаланатындай өзгерту осы кері байланыс циклін үзіп, тұрақты күйдегі сұраулар жүктемесінің ауытқуын да азайтты.

Қазір OpenAI инфрақұрылымында қосылымдарды пулға біріктіру және сервер жүктемесін жақсырақ ескеретін теңестіру стратегияларын қамтамасыз ету үшін негізінен Istio мен Envoy-ға сүйенеміз, осылайша бұл мәселені толығымен болдырмаймыз.

asyncio кідірісін азайтуға бағытталған баптаудың және Python процестерінің өте көп болуының бір жанама әсері — төменгі деңгейдегі тәуелді жүйелерді орасан көп қосылыммен оңай шамадан тыс жүктеп жіберуге болады; бұл «thundering herd» құбылысы деп аталады.

Кәдімгі күнделікті өрістету баяу жүруге бапталмаса, қосылымдардың үздіксіз ашылып-жабылуынан CPU-ға елеулі қосымша жүктеме түсуі мүмкін. Ал қосылымның ағып кетуі NAT шлюзін қанықтырып, желіні істен шығаруы мүмкін. Мұндай мәселелер басқа қызметтерде де сирек емес, бірақ процестер саны бір реттік шамадан он есе көп болғанда, олардың туындау шегі айтарлықтай төмендейді. Соның салдарынан тек өткізу қабілетіне негізделген тұрақты күйдегі есеп бойынша клиенттер мұндай деңгейде пайдалануды күтпейтін желілік ресурстар жиі қанығып қалады.

Қосылымдарды бір нүктеге барынша шоғырландыру үшін Envoy-ға да сүйенеміз. Мультиплекстеу мүмкіндігін пайдалану үшін оны Python-ның HTTP/1 қосылымдарын HTTP/2-ге ауыстыруға, содан кейін сол қосылымдарды пулға біріктіріп, олардың қызмет ету мерзімін ұзартуға қолданамыз. Сондай-ақ Envoy әр дербес Python процесінде тиімділігі төмен болатын сұраныс шектеуілері мен circuit breaker қорғаныс тетіктерін орталықтан енгізуге мүмкіндік береді.

Python-ды осыншалық масштабтай алуымыздың бір себебі — сұрау құнын болжамды ететін Habitat-тың шектеулі API интерфейсі. Клиенттерге үлкен кестелерді сканерлеуге немесе көптеген кестені біріктіруге әкелетін еркін SQL сұрауларын құруға мүмкіндік берудің орнына, Habitat қарапайым NoSQL API ұсынады. Қуатты API интерфейсінің болмауы — Habitat дизайнындағы саналы ымыра.

Біз қарапайым, болжамды және тұрақты көлемде жұмыс орындайтын сұрауларды оңтайландыруды көздейміз. Тәжірибеміз бойынша мұндай жүйелерді масштабтау едәуір оңай, ал оларды қате не теріс пайдалану қиын. Таралу ауқымы болжанбайтын сұраулар пайдалану тұрғысынан қауіпті: олар оқшаулауды және жүктемені теңестіруді қиындатып, қызметке де, оның клиенттеріне де масштабтау қиын болатын кідіріс құздарын тудырады.

Habitat пен Azure Cosmos DB-ге көшкенге дейін OpenAI онлайн деректерінің көбі Postgres-те сақталды. Ол кезде өндіріске шығармас бұрын барлық сұрау мен схема өзгерісін қарап, олардың дұрыс жұмыс істейтініне және индекстелген деректермен орындалатынына көз жеткізу оңай еді. Команда мен өнімдер өскен сайын бұл тез арада басқаруға келмейтін жағдайға жетті: жиі қолданылатын жолдағы бір жаңа қымбат сұрау дерекқорды істен шығарып, үзілістерге жиі себеп болатын.

Мұндағы мәселе — шығын теңгерімсіздігі: орындау қымбат әрі қиын SQL сұрауларын жазу арзан әрі оңай. Habitat-та біз бұған жол бермейміз әрі қымбат сұрауларды клиент жағында бірден байқалатындай етеміз. Habitat-қа шамадан тыс жүктеме түсіретін шектеусіз сұраулар жоқ, ал күрделі біріктірулер мен графты аралау өнім командаларынан жұмыстың ауыр бөлігін орындауды талап етеді, бұл жалпы тиімдірек дизайнды таңдауға ықпал етеді.

Habitat клиент анықтайтын нысандар мен қырлар түрлеріне негізделген, TAO⁠(жаңа терезеде ашылады) жүйесінен шабыт алған NoSQL API ұсынады. Клиенттер нысандарды, қырларды және олардың өзара байланысын алдын ала анықтайды, бірақ әр түрдің мазмұнын анықтамайды. Нәтижедегі байланыстар графқа ұқсайды, бірақ Habitat белгілі бір нысанның тікелей қырларын сұраудан басқа қалыпты графты аралау сұрауларын қолдамайды.

Бұл графты әр нысан мен оның тиісті қырлары сақтау деңгейіндегі бір бөлімде орналасатындай бөлеміз, бірақ нысандарды олардың қырлары нұсқайтын қашықтағы нысандармен бірге орналастыруға дерекқор деңгейінде арнайы күш салмаймыз. Нәтижесінде модель көлденең масштабтау үшін оңай бөлінеді, бірақ графты аралау тиімсіз: нысандар арасындағы кез келген қадам әртүрлі аймақтарда сақталған екі бөлек Azure Cosmos DB тіркелгісінен дерек алуды қажет етуі мүмкін.

Күрделірек сұраулар қажет клиенттерге Habitat-тың Rockset арқылы қолжетімді офлайн қосалқы көрінісін ұсынамыз. Өзгерістерді онлайн сақтау жүйесінен оқшауланған Rockset даналарына нақты уақытқа жуық режимде ағынмен жіберу үшін өзгерістер деректерін қармауды (CDC) қолданамыз. Әр клиент командасы күрделі сұрау қажеттіліктері үшін өз Rockset данасын масштабтауға жауапты.

Rockset ресурстарын дайындау клиенттерімізге қосымша қиындық туғызады, бірақ қазіргі сәтте бұл дұрыс ымыра деп санаймыз: әдепкіде қарапайым сұрауларды қолданып, күрделі сұраулар қажет адамдарға балама жол беру. Бұл дизайн онлайн сақтау жүйемізді оқуы көп аналитикалық және іздеу жүктемелерінен оқшаулайды.

Python кодын қайта жазуды бір жылға шегеру қарқынды өсу кезінде шұғыл әрі ықпалды мәселелерге назар аударуға мүмкіндік берді. Платформа жетіліп, өсуіміз үдей түскенде әрі қызмет OpenAI-де ядро саны бойынша екінші, Envoy ауқымы бойынша төртінші орынға жеткенде, Python-нан көшетін уақыт келді. Шарықтау кезінде Python бізге секундына 20 миллионнан астам сұрауды өңдеуге көмектесті.

2026 жылдың екінші тоқсанында небәрі 2 инженердің, Codex және GPT‑5.5 көмегімен бүкіл қызметті Rust тілінде қайта жаза алдық. Жаңа Rust қызметі қазір өндірістік сұрауларымыздың 95%-ын өңдейді; алдағы апталарда Python-нан толық бас тартамыз. Деректеріміз Rust қызметінің Python нұсқасына қарағанда CPU-ді 6 есе, жадты 15 есе тиімді пайдаланатынын әрі орташа және шеткі кідірістерінің айтарлықтай төмен екенін көрсетеді. Болашақ блог жазбасында басқа да тәжірибелерімізбен бөлісуді жоспарлап отырмыз.

Python, ал қазір Rust қызметі — Habitat-тың бір ғана қыры. Онлайн сақтау жүйесін 1 миллиардтан астам ChatGPT пайдаланушысына қызмет көрсететіндей қалай жылдам масштабтағанымыз туралы топтаманың екінші бөлімінде сақтау қабаты және Habitat-тың 500 петабайттан астам дерек пен секундына 70 миллионнан астам сұрауды қалай өңдейтіні жайлы айтамыз.

Озық ауқымдағы OLTP жүйелерімен жұмыс істегіңіз келсе және осындай инженерия қызықтырса, командамыздағы осы бос орынды қараңыз⁠.