Առցանց պահոցի արագ ընդլայնումը՝ ChatGPT‑ի 1 մլրդ+ օգտատիրոջ սպասարկման համար

OpenAI-ի յուրաքանչյուր պրոդուկտ կախված է տվյալների արագ ու հուսալի հասանելիությունից՝ լինի դա մուտք գործելը, Codex-ի կարգավորումները ստուգելը, թե ChatGPT‑ում նոր զրույց սկսելը։ Մինչ պրոդուկտը կպատասխանի, այդ գործողություններից յուրաքանչյուրը կարող է տվյալների բազմաթիվ առանձին որոնումներ պահանջել։ Եթե այդ հարցումները դանդաղ են, պրոդուկտն էլ է դանդաղ թվում։ Եթե այդ հարցումները ձախողվում են, պրոդուկտն ամբողջությամբ դադարում է աշխատել։

Habitat-ը մեր ստեղծած առցանց պահոցի հարթակն է, որի շնորհիվ OpenAI-ի պրոդուկտներն արագ ու հուսալի հասանելիություն են ստանում անհրաժեշտ տեղեկությանը։ Habitat-ն այժմ վայրկյանում մշակում է ավելի քան 70 միլիոն հարցում՝ գրեթե 40 աշխարհագրական տարածաշրջանում աջակցելով պրոդուկտների, որոնք շաբաթական օգտագործում է ավելի քան 1 միլիարդ մարդ։ Habitat-ն առաջին անգամ գործարկվեց DevDay 2023-ում՝ GPT‑ներին աջակցելու համար, որպես մեկ տվյալների շտեմարանին միացված պարզ Python հաճախորդային գրադարան։ Այսօր այն բարդ բաշխված համակարգ է, որը սպասարկում է ավելի քան 500 պետաբայթ տվյալ։

Այս մասշտաբի ենթակառուցվածք կառուցելն ու շահագործելը հեշտ չէ, բայց նաև առանձնապես բարդ չէ։ Մեր իրավիճակը եզակի էր աննախադեպ արագությամբ ընդլայնվելու անհրաժեշտության պատճառով. պետք էր միաժամանակ բավարարել օգտատերերի ապշեցուցիչ աճն ու պրոդուկտների պահանջարկը և կառուցել հասուն հարթակ։ Համակարգային ինժեներները հաճախ կառուցում են 10-ապատիկ մասշտաբի համար՝ հույս ունենալով, որ այն կդիմանա մի քանի տարի, մինչ պատրաստվում են հաջորդ 10-ապատիկ աճին։ Մեր դեպքում վերջին երեք տարիներից յուրաքանչյուրում աճել ենք ավելի քան 10 անգամ։ Այդ պատճառով Habitat-ի կառուցումն ու շահագործումը դարձել են մարտավարական որոշումների ճիշտ հերթականություն սահմանելու շարունակական գործընթաց՝ ամենացածր մակարդակում հասկանալ յուրաքանչյուր բաղադրիչը, առկա տեխնոլոգիական փաթեթից առավելագույնը քաղել և միաժամանակ հաղթահարել պահոցի ու հաշվարկային հզորության սահմանափակումները՝ հիմնարար ներդրումների համար ժամանակ շահելու նպատակով։

OpenAI-ի աճին զուգահեռ Habitat-ն էլ պետք է աճեր՝ նախ դառնալով բավական հուսալի՝ բիզնեսի համար վճռորոշ պրոդուկտային հոսքը սպասարկելու համար, ապա բավական արագ՝ աշխարհի տարբեր վայրերում գտնվող օգտատերերին սպասարկելու համար, և վերջապես՝ հսկայական մասշտաբով արդյունավետ աշխատելու համար։ Սա առցանց պահոցի ընդլայնման մասին երկմաս շարքի առաջին գրառումն է։ Այս գրառման մեջ կներկայացնենք Habitat-ի զարգացումը, թե ինչու գրադարանից այն վերածեցինք ծառայության և ինչպես սպասարկման համար ոչ սովորական լեզվով՝ Python-ով գրված ծառայությունը հասցրինք հուսալի պահոցային հարթակի մակարդակի։

Հաջորդ գրառման մեջ մանրամասն կներկայացնենք, թե ինչպես ենք լայն մասշտաբով ապահովել բազմավարձակալության հուսալիությունը, ինչ բազմաշերտ ռազմավարություն ենք կիրառել ընթերցման արտադրողականությունը օպտիմալացնելու համար և ինչպես ենք ընդլայնել Azure Cosmos DB-ի հետ մեր համագործակցությունը՝ աննախադեպ պահանջարկը հուսալիորեն սպասարկելու նպատակով։

Habitat-ը սկսվեց պարզ գաղափարից. պրոդուկտային ինժեներները չպետք է ստիպված լինեն մտածել տվյալների շտեմարանի կառավարման մասին։ Habitat-ն առաջին անգամ գործարկվեց DevDay 2023-ում՝ GPT‑ներին աջակցելու համար, որպես Python-ի փոքր գրադարան, որը փոխգործակցում էր ChatGPT‑ի հիմնական սերվերի հետ։ Այն աջակցում էր գործողությունների փոքր հավաքածու, որոնք ներքին մակարդակում համապատասխանեցվում էին տվյալների շտեմարանի ծառայության՝ Azure Cosmos DB-ի գործողություններին։

Գրադարանի նպատակն էր պրոդուկտային թիմերին տրամադրել տվյալները պահելու և առբերելու պարզ եղանակ՝ առանց հիմքում ընկած մանրամասներին տիրապետելու անհրաժեշտության։ Habitat-ը կատարում էր անհրաժեշտ աշխատանքը՝ որոշում էր, թե ինչ տեսակի տվյալների մասին է խոսքը, որտեղից դրանք պետք է ստացվեին (կամ ուր ուղարկվեին), արդյոք հարցումը թույլատրված էր և այլն։

Պրոդուկտային ինժեներները կարիք չունեին զբաղվելու սխեմայի որոնմամբ, երթուղավորմամբ, լիազորմամբ, գաղտնագրմամբ, սերիականացմամբ, հարցումների ձևավորմամբ և կապերի խմբավորմամբ։ Նրանք նույնիսկ կարիք չունեին հաշվի առնելու, թե որտեղից են գալիս տվյալները՝ Azure Cosmos DB-ից, քեշերից, թե այլ տեսակի պահոցներից։

Python-ի այս գրադարանը լավ էր աշխատում, և OpenAI-ի պրոդուկտային ինժեներներն արագ սկսեցին լայնորեն կիրառել Habitat-ը՝ չնայած ինքնասպասարկման սկզբունքով օգտագործվող Postgres-ից և Azure Cosmos DB-ից հրաժարվելու կենտրոնացված նախաձեռնություն չկար։

Պրոդուկտային պահանջների զարգացմանը զուգահեռ մշակողները հեշտությամբ կարող էին ընդհանուր գրադարանին ավելացնել այնպիսի գործառույթների աջակցություն, ինչպիսիք են հաճախորդային քեշավորումը, սեղմումը կամ գաղտնագրումը։

2025-ի կեսերին Habitat-ը հասել էր իր սահմաններին՝ որպես հաճախորդային իրականացում։ Habitat-ի շերտի բարդացման և OpenAI-ի ծառայությունների քանակի աճի հետևանքով հետադարձ համատեղելիությամբ արձանագրային փոփոխություններն անիրագործելի էին դարձել։

Մի դեպքում ցանկանում էինք նվազեցնել որևէ տարածաշրջանի խափանման ազդեցությունը մեր կարևորագույն տվյալների հավաքածուների վրա՝ դրանք տեղափոխելով տարածաշրջաններով բաշխված Azure Cosmos DB հաշիվների խումբ։ Այս փոփոխությունն իրականացնելու համար հարկավոր էր հաճախորդային ծրագրում ավելացնել լրացուցիչ երթուղավորման տրամաբանություն, որն ի սկզբանե անջատված էր ֆունկցիոնալ դրոշով, այն տարածել բոլոր հաճախորդների վրա, ապա միացնել ֆունկցիոնալ դրոշը։

Տասնյակ ծառայությունների տեղակայումները համակարգելը և յուրաքանչյուր թիմի հետ ներդրումն իրականացնելը տևեց օրեր։ Մինչ դա միացնելը հասկացանք, որ պետք է ստվերարկում ավելացնենք՝ համոզվելու, որ բաժանման տրամաբանությունը ճիշտ է աշխատում։ Դրա ներդրումն էլ մի քանի օր տևեց։ Իսկ մեր հայտնաբերած սխալի ուղղո՞ւմը։ Եվս մի քանի օր։ Վերջապես պատրաստ էինք միացնել դրոշը, բայց թիմերից մեկը կապ չունեցող պատճառով իր ծառայությունը հետ դարձրեց նախկին՝ սխալ պարունակող հաճախորդային տարբերակին՝ առաջացնելով հենց այն խափանումը, որից այդքան ջանում էինք խուսափել։

Հաճախորդային գրադարանի փոփոխությունները պահանջում էին տասնյակ ծառայությունների բարդ համակարգում: Այս գործընթացը գնալով դառնում էր ավելի փխրուն, անարդյունավետ և շահագործման խափանումների նկատմամբ խոցելի։ Հետագա տեղակայումների ժամանակ գործառնական այս լայն տարածումը նվազեցնելու համար որոշեցինք Habitat-ը դարձնել առանձին ծառայություն։

Պահոցի տրամաբանությունն առանձնացնելով ինքնուրույն ծառայության մեջ՝ ստեղծեցինք տեղակայումների, դիտարկելիության և հարթակի բարելավումների կառավարման միասնական կետ։ Մասնատված թարմացումներ կառավարելու փոխարեն կարող էինք բարելավումները կենտրոնացված ներդնել՝ անմիջապես օգուտ տալով OpenAI-ի բոլոր պրոդուկտներին։

Կենտրոնացված ծառայությունը նաև միասնական վերահսկման կետ է ապահովում տվյալների անվտանգության ու գաղտնիության ամենաուժեղ հիմնարար մեխանիզմների համար։ Habitat ծառայությունում կարող ենք կենտրոնացված կիրառել հասանելիության վերահսկման կանոնները, վարել աուդիտի մատյան և սահմանափակել հասանելիությունը պահոցի հիմքում ընկած ռեսուրսներին, օրինակ՝ Azure Cosmos DB-ին։ Habitat-ը վճռորոշ դեր ունի օգտատերերի տվյալները պաշտպանելու և արտաքին, ներքին ու ագենտ դերակատարների չարտոնված հասանելիությունը կանխելու գործում։

Գիտեինք, որ ծառայություն է պետք, բայց դեռ չէինք ուզում հրաժարվել Python-ից՝ նույնիսկ որպես ծառայություն դրա հավելյալ ծախսերի պայմաններում։ Բարձր թողունակությամբ ծառայության համար Python-ի օգտագործումը մեծացրեց ցանցային ուշացումը և, տեղային գրադարանի կատարման համեմատ, էապես բարձրացրեց CPU-ի ու հիշողության ընդլայնման ծախսերը։ Բացի այդ, հասկանում էինք, որ 100-ապատիկ մասշտաբում Python-ի անարդյունավետությունն անընդունելի կլինի, ուստի հետագա վերաշարադրումը գրեթե անխուսափելի էր։

Սակայն սա դիտարկում էինք որպես տեխնիկական պարտքի ռազմավարական կուտակում։ Այդ պահին մեր հիմնական նպատակը ծախսերի կամ ռեսուրսների օպտիմալացումը չէր, այլ արտադրանքի մշակողների աշխատանքը խոչընդոտող խնդիրների վերացումը և հարթակի կայունության ապահովումը։ Կարճաժամկետ հեռանկարում ընդունելով Python ծառայության արտադրողականության փոխզիջումները՝ կարողացանք առաջնահերթ լուծել ավելի հրատապ խնդիրները, սահմանել հիմնական API-ները և ստեղծել հուսալի ենթակառուցվածք։

Մենք նաև հաշվարկված խաղադրույք կատարեցինք այն բանի վրա, որ կոդավորման մեր մոդելների արագ զարգացումը հետագայում կհեշտացնի տեխնիկական անցումը։ Հույս ունեինք, որ մինչև Python-ից ամբողջական անցման անհրաժեշտությունը Codex-ը և GPT‑ն այդ անցումն իրագործելի կդարձնեն։ Ի վերջո, այդ խաղադրույքն արդարացավ։

Արդյունավետության տեսանկյունից Habitat-ը որպես Python ծառայություն գործարկելը լավագույն տարբերակը չէր, սակայն անհրաժեշտ ընտրություն էր։ Python-ը մեզ հնարավորություն է տալիս արագ աշխատել, բայց դա չի նշանակում, որ կարող էինք անտեսել ռիսկերը և ընդունել արձագանքման ժամանակի զգալի վատթարացում։ Երբ օգտատիրոջ միջին հարցումը հանգեցնում է տվյալների բազային հարյուրավոր հարցումների, օգտատերը զգում է դրանցից ամենադանդաղի ազդեցությունը։ Պարզեցինք, որ այս մասշտաբով Python ծառայության հիմնական մարտահրավերը վերջնամասային ուշացումների կառավարումն է։

Asyncio-ն օգնում է Python-ին միաժամանակ կատարել մուտք/ելքով (I/O) սահմանափակվող աշխատանքները, սակայն չի օգնում շրջանցել Python-ի GIL-ը և չի ապահովում CPU-ի զուգահեռ աշխատանք։ Մուտք/ելքի ինտենսիվ հարցումների միջնորդավորումից բացի, Habitat-ը կատարում է CPU-ի մեծ ռեսուրս պահանջող բազմաթիվ պարտականություններ ու ֆոնային առաջադրանքներ՝ երթուղավորում, սեղմում, գաղտնագրում, ստուգիչ գումարների հաշվարկ, ստորադաս համակարգերի վիճակի ստուգում, հարցումների ստվերարկում և հարցումների ապահովագրող կրկնօրինակում:

CPU-ի մեծ ռեսուրս պահանջող այսքան աշխատանքների և ֆոնային առաջադրանքների դեպքում asyncio-ի պլանավորման ուշացումը կարող է հեշտությամբ գերակշռել հարցումների վերջնամասային ուշացման մեջ։ Նախնական գործարկումից առաջ կարգավորելիս p99 և ավելի մեծ ուշացում ունեցող հարցումների հետագծերում տեսանք, որ թեև ստորադաս պահոցն արագ էր պատասխանում, հարցումները հաճախ կանգ էին առնում՝ սպասելով, որ պատասխանը վերլուծող կոռուտինը կրկին ընդգրկվի կատարման հերթում։

OpenAI-ի Python ծառայությունների դեպքում, բացի հիշողության, CPU-ի, ցանցի և սկավառակի օգտագործման ստանդարտ ծանրաբեռնվածության ու հագեցվածության ցուցանիշները չափելուց, չափազանց կարևոր է նաև վերահսկել asyncio-ի իրադարձությունների ցիկլը և դրա ծանրաբեռնվածությունը, ապա համապատասխանաբար կարգավորել համակարգը։

Պարբերաբար պլանավորելով ֆոնային առաջադրանքներ և գրանցելով ակնկալվող ու փաստացի կատարման ժամանակների տարբերությունը՝ կարողանում ենք իրական ժամանակում գործնականորեն չափել իրադարձությունների ցիկլի պլանավորման ուշացումը։ Բարձր ծանրաբեռնվածության և բազմաթիվ ծախսատար առաջադրանքների դեպքում նույնիսկ մեկ պրոցեսի համաժամանակյա հարցումների չափավոր քանակը բավարար է պլանավորման զգալի տատանում առաջացնելու համար՝ մինչև հարյուրավոր միլիվայրկյան, իսկ եզակի դեպքերում՝ մի քանի վայրկյան։

Ուստի յուրաքանչյուր պրոցեսով սպասարկում ենք միայն փոքրաթիվ համաժամանակյա հարցումներ և փոխարենը հսկայական չափով ավելացնում Python աշխատող պրոցեսների քանակը։

Ծառայության նախնական գործարկման ժամանակ CPU-ի իրական պրոֆիլավորման միջոցով գտանք Asyncio-ի մեծ ուշացման (և դրանից բխող վերջնամասային ուշացումների հիմնական պատճառներից մեկը)՝ Statsig-ի (ֆունկցիոնալ դրոշների կառավարման գործիք է, որը նաև թույլ է տալիս անցկացնել A/B թեստեր և կատարել այլ գործողություններ) միջոցով ֆունկցիոնալ դրոշների կազմաձևերի պարբերական JSON վերլուծումը։

Ըստ կանխադրման՝ Statsig-ը կազմաձևված էր այնպես, որ ամեն րոպե, առանց պատահական ժամանակային շեղման, հարցում կատարեր թարմացված կազմաձևերը ստանալու համար, իսկ կազմաձևը ներառում էր բոլոր ծառայությունների արտադրական միջավայրի բոլոր կանոնները։ Մեկ այլ ճարտարապետական որոշմամբ յուրաքանչյուր pod-ում գործարկվում էր մինչև 8 Python պրոցես՝ CPU-ի օգտագործումը բարձրացնելու և ուշացումները նվազեցնելու համար։ Այս ամենի հետևանքով ամեն րոպե յուրաքանչյուր pod-ում լինում էր պահ, երբ բոլոր աշխատողները դադարեցնում էին ընթացիկ հարցումների մշակումը և CPU-ի ցիկլերը ծախսում հսկայական կազմաձևման ֆայլի վերլուծման վրա։

CPU-ի պրոֆիլավորումը հիմնական պատճառը բացահայտելուց հետո լուծումը պարզ էր՝ տեղակայել ավելի փոքր ու նպատակային կազմաձև, երկարացնել թարմացման միջակայքը և նման ֆոնային առաջադրանքներին ավելացնել պատահական ժամանակային շեղում։

Asyncio-ի ուշացումը ցածր պահելու համար չափազանց կարևոր է նաև հարցումները պատշաճ կերպով հավասարակշռել սերվերային պրոցեսների միջև։ Առանց համապատասխան կարգավորման՝ կապերի խմբավորումը նույնպես կարող է հակառակ ազդեցությունն ունենալ։

Հաճախորդային կապերի խմբավորման դեպքում բազմաթիվ համաժամանակյա հարցումներ կատարող մեկ հաճախորդային պրոցեսը կարող է ստեղծել սերվերային ընդամենը մի քանի կապ և հետևաբար, իր ամբողջ ծանրաբեռնվածությունն ուղղել ընդամենը մի քանի պրոցեսի։ Մինչ բեռի հավասարակշռման մեր եղանակը փոխելը պրոցեսների ծանրաբեռնվածությունը խիստ տատանվում էր, իսկ բաշխման եզրին գտնվող որոշ պրոցեսներ սպասարկում էին միջինից 5-10 անգամ ավելի շատ համաժամանակյա հարցումներ։

Սա պատահաբար հայտնաբերեցինք մի միջադեպի ժամանակ, երբ մեր ծառայության մի մասը գերբեռնող հաճախորդը կանգնեցնելուց հետո էլ պրոցեսների մի ենթախումբ կտրուկ հոսքից երկար ժամանակ անց շարունակում էր վատ աշխատել։ Իրականում Նկատեցինք, որ այդ պրոցեսների վիճակն անկառավարելիորեն վատանում էր․ մինչև դրանք վերագործարկելը՝ պրոցեսները գնալով ավելի շատ հարցումներ էին ստանում։ Երբ որևէ pod գերբեռնվում էր, համակարգի ինչ-որ վարքագծի հետևանքով ավելի շատ հոսք էր ուղղվում հենց այդ pod-ին։ Սա խափանումների այն տեսակներից էր, որին մեր որոշ թիմակիցներ քաջածանոթ էին նախորդ աշխատանքից` մետակայուն խափանում⁠(բացվում է նոր պատուհանում)։

Կասկածում էինք, որ պատճառը կապերի խումբն է, և դա ստուգեցինք՝ սահմանափակելով կապի վերօգտագործման առավելագույն տևողությունը։ Դա իսկապես սահմանափակեց վատթարացումը և հաստատեց ուսումնասիրության ուղղությունը։ Հետագա ուսումնասիրությամբ պարզվեց, որ Python-ի aiohttp TCPConnector-ը լռելյայն օգտագործում է կապերի LIFO վերօգտագործում. հաջորդ հարցման համար ընտրվում է ամենավերջում վերադարձված կապը։ Սովորաբար սա ողջամիտ լռելյայն տարբերակ է. վերջերս օգտագործված կապերի վերօգտագործումը թույլ է տալիս, որ կտրուկ հոսքը սպասարկելու համար ստեղծված հավելյալ կապերն անգործության ժամանակային շեմով փակվեն՝ նվազեցնելով դրանց պահպանման ծախսը։ Այս դեպքում այն մեզ մոտ մետակայուն խափանում առաջացրեց։ Հարցումների կտրուկ հոսքի ժամանակ ավելի դանդաղ, գերբեռնված սերվերներին ուղարկված հարցումները կապերն ավելի ուշ էին վերադարձնում խմբին, ուստի հաջորդ հարցումները դրանք ավելի հաճախ էին ընտրում՝ հոսքն աստիճանաբար կենտրոնացնելով արդեն իսկ ծանրաբեռնված pod-երի վրա։ Կապերի խումբը FIFO վերօգտագործման անցկացնելն ընդհատեց հետադարձ կապի այս օղակը և նույնիսկ նվազեցրեց կայուն վիճակում հարցումների տատանումը։

Այսօր հիմնականում ապավինում ենք Istio-ին և Envoy-ին՝ OpenAI-ի ամբողջ ենթակառուցվածքում կապերի խմբավորում և սերվերի բեռը հաշվի առնող ավելի լավ հավասարակշռման ռազմավարություններ ապահովելու ու այս խնդրից ամբողջությամբ խուսափելու համար։

Asyncio-ի ցածր ուշացման համար համակարգը կարգավորելու և Python-ի այսքան մեծ թվով պրոցեսներ ունենալու կողմնակի հետևանքներից մեկն այն է, որ կապերի հսկայական քանակը կարող է շատ հեշտությամբ գերբեռնել ստորադաս կախված համակարգերը (երևույթը հայտնի է որպես «thundering herd»՝ «որոտացող հոտի» խնդիր)։

Սովորական ամենօրյա տեղակայումը, եթե միտումնավոր դանդաղ կատարման համար կարգավորված չէ, կապերի անընդհատ ստեղծման ու փակման պատճառով կարող է CPU-ի ծանրաբեռնվածության զգալի տատանումներ առաջացնել։ Իսկ կապերի արտահոսքը կարող է շարքից հանել ցանցը՝ հագեցնելով NAT դարպասի թողունակությունը։ Այս խնդիրներն այլ ծառայություններում նույնպես հազվադեպ չեն, սակայն տասնապատիկ ավելի շատ պրոցեսներ ունենալը զգալիորեն նվազեցնում է դրանց առաջացման շեմը։ Դրա հետևանքով հաճախ հագեցվում են ցանցային ռեսուրսներ, որոնց նման ծանրաբեռնվածություն հաճախորդները չէին ակնկալի կայուն վիճակում՝ միայն զուտ թողունակության հաշվարկից ելնելով։

Կապերի համախմբումն առավելագույնի հասցնելու համար ևս ապավինում ենք Envoy-ին։ Այն օգտագործում ենք Python-ի HTTP/1 կապերը HTTP/2-ի փոխարկելու և մուլտիպլեքսավորման առավելություններից օգտվելու, ապա այդ կապերը խմբավորելու ու դրանց կյանքը երկարացնելու համար։ Envoy-ն նաև կենտրոնացված կետ է տալիս հաճախականության սահմանափակումներ և շղթայի անջատիչներ ներդնելու համար, որոնք Python-ի յուրաքանչյուր առանձին պրոցեսում պակաս արդյունավետ կլինեին։

Python-ն այսքան ընդլայնելու պատճառներից մեկը Habitat-ի սահմանափակ API-ն էր, որը հարցման արժեքը կանխատեսելի է պահում։ Հաճախորդներին կամայական SQL հարցումներ կազմելու հնարավորություն տալու փոխարեն, որոնք կարող էին հանգեցնել խոշոր աղյուսակների սկանավորման կամ բազմաթիվ աղյուսակների միացման, Habitat-ը տրամադրում է պարզ NoSQL API։ Հզոր API-ի բացակայությունը Habitat-ի նախագծման գիտակցված փոխզիջում է։

Մեր նպատակը պարզ, կանխատեսելի և հաստատուն ծավալի աշխատանք պահանջող հարցումների համար օպտիմալացնելն է։ Ըստ մեր փորձի` նման համակարգերը զգալիորեն ավելի հեշտ է ընդլայնել, և դժվար է սխալ կամ ոչ պատշաճ օգտագործել։ Անկանխատեսելի ճյուղավորմամբ հարցումները շահագործման առումով վտանգավոր են. դրանք բարդացնում են մեկուսացումն ու բեռի հավասարակշռումը և առաջացնում ուշացման կտրուկ աճեր, որոնց համար դժվար է ընդլայնել թե՛ ծառայությունը, թե՛ դրա հաճախորդներին։

Մինչ Habitat-ին և Azure Cosmos DB-ին անցնելը OpenAI-ի առցանց տվյալների մեծ մասը պահվում էր Postgres-ում։ Այդ ժամանակ հեշտ էր վերանայել հարցումների ու սխեմայի բոլոր փոփոխությունները և մինչև արտադրական միջավայր ուղարկելը համոզվել, որ դրանք ճիշտ են աշխատում ինդեքսավորված տվյալների հետ։ Թիմի և պրոդուկտների աճին զուգահեռ սա արագ դարձավ անկառավարելի և հաճախ խափանումների պատճառ էր դառնում, երբ առանցքային հոսքում մեկ նոր ծախսատար հարցում շարքից հանում էր տվյալների շտեմարանը։

Խնդիրը ծախսերի անհամաչափությունն է. հեշտ ու էժան է գրել SQL հարցումներ, որոնք կատարելը թանկ ու դժվար է։ Habitat-ում խուսափում ենք դրանից և ծախսատար հարցումները հաճախորդի կողմում խիստ ակնհայտ դարձնում։ Չկան անսահմանափակ հարցումներ, որոնք կարող են գերբեռնել Habitat-ը, իսկ բարդ միացումների ու գրաֆի շրջանցումների համար պրոդուկտային թիմերը պետք է կատարեն ծանր աշխատանքի մի մասը, ինչը ընդհանուր առմամբ նպաստում է ավելի արդյունավետ լուծումների նախագծմանը։

Habitat-ը տրամադրում է հաճախորդի սահմանած օբյեկտների ու կապերի տեսակների շուրջ կառուցված NoSQL API՝ ոգեշնչված TAO-ից⁠(բացվում է նոր պատուհանում)։ Հաճախորդները նախապես սահմանում են օբյեկտներն ու կապերը և դրանց փոխհարաբերությունները, բայց ոչ յուրաքանչյուր տեսակի բովանդակությունը։ Ստացված հարաբերությունները գրաֆ են հիշեցնում, սակայն Habitat-ն ինքը չի աջակցում գրաֆի շրջանցման սովորական հարցումներ՝ բացի որոշակի օբյեկտի անմիջական կապերի հարցումից։

Այս գրաֆը բաժանում ենք այնպես, որ յուրաքանչյուր օբյեկտ և դրան համապատասխանող կապերը միասին տեղակայվեն պահոցի մակարդակի միևնույն բաժնում։ Սակայն տվյալների շտեմարանի մակարդակում նպատակային քայլեր չենք ձեռնարկում օբյեկտներն ու դրանց կապերի մատնանշած հեռակա օբյեկտները միասին տեղակայելու համար։ Արդյունքում մոդելը հեշտությամբ բաժանվում է հորիզոնական ընդլայնման համար, սակայն գրաֆի շրջանցումն անարդյունավետ է, քանի որ օբյեկտների միջև յուրաքանչյուր քայլ կարող է պահանջել տվյալների ստացում տարբեր տարածաշրջաններում պահվող երկու բոլորովին տարբեր Azure Cosmos DB հաշիվներից։

Հարցումների ավելի բարդ պահանջներ ունեցող հաճախորդներին տրամադրում ենք նաև Habitat-ի անցանց երկրորդային տեսք՝ Rockset-ի միջոցով։ Փոփոխությունների տվյալների գրանցմամբ (CDC) առցանց պահոցի փոփոխությունները գրեթե իրական ժամանակում հոսքային եղանակով փոխանցում ենք մեկուսացված Rockset ատյաններին։ Հաճախորդների յուրաքանչյուր թիմ պատասխանատու է հարցումների իր բարդ պահանջներին համապատասխան Rockset-ի սեփական ատյանը մասշտաբավորելու համար։

Rockset-ի այս տրամադրումը լրացուցիչ դժվարություն է ստեղծում հաճախորդների համար, սակայն այս պահին դա ճիշտ փոխզիջում ենք համարում՝ պարզ հարցումները դարձնել լռելյայն տարբերակ՝ միաժամանակ այլընտրանք տրամադրելով բարդ հարցումների կարիք ունեցողներին։ Այս կառուցվածքը մեր առցանց պահոցը մեկուսացնում է ընթերցման մեծ ծանրաբեռնվածությամբ վերլուծական և որոնման աշխատանքներից։

Python-ով գրված համակարգի վերաշարադրումը մեկ տարով հետաձգելը գերարագ աճի շրջանում մեզ թույլ տվեց կենտրոնանալ ավելի հրատապ ու ազդեցիկ խնդիրների վրա։ Երբ հարթակը հասունացել էր, իսկ աճը շարունակում էր արագանալ, և ծառայությունը OpenAI-ում միջուկների քանակով երկրորդն էր, (իսկ Envoy-ի ծավալով՝ չորրորդը) վերջապես ժամանակն էր հրաժարվել Python-ից։ Իր առավելագույն հզորության պահին Python-ը մեզ օգնում էր սպասարկել վայրկյանում ավելի քան 20 միլիոն հարցում։

2026 թ. երկրորդ եռամսյակում ընդամենը 2 ինժեների, Codex-ի և GPT‑5.5‑ի օգնությամբ կարողացանք ամբողջ ծառայությունը վերաշարադրել Rust-ով։ Rust-ով այս նոր ծառայությունն այժմ մշակում է մեր արտադրական հարցումների 95%-ը, իսկ առաջիկա շաբաթներին ամբողջությամբ կհրաժարվենք Python-ից։ Մեր տվյալներով՝ Rust ծառայությունը CPU-ի օգտագործման առումով 6 անգամ, իսկ հիշողության օգտագործման առումով՝ 15 անգամ ավելի արդյունավետ է, քան Python տարբերակը, և ունի զգալիորեն ավելի ցածր միջին ու վերջնամասային ուշացումներ։ Հետագա բլոգային գրառման մեջ կկիսվենք այլ եզրակացություններով։

Python-ով, իսկ այժմ Rust-ով գրված ծառայությունը Habitat-ի ընդամենը մեկ կողմն է։ Ավելի քան 1 միլիարդ ChatGPT օգտատիրոջ սպասարկման համար առցանց պահոցի արագ ընդլայնմանը նվիրված այս շարքի երկրորդ մասում կանդրադառնանք պահոցի շերտին և կպատմենք, թե Habitat-ն ինչպես է սպասարկում ավելի քան 500 պետաբայթ տվյալ ու վայրկյանում ավելի քան 70 միլիոն հարցում։

Եթե ցանկանում եք աշխատել առաջադեմ մասշտաբի OLTP համակարգերի վրա և հետաքրքրված եք նման ինժեներական աշխատանքով, ծանոթացեք մեր թիմի այս թափուր հաստիքին⁠։