Առցանց տվյալների պահեստավորման արագ ընդլայնում՝ ChatGPT‑ի ավելի քան 1 մլրդ օգտատիրոջ համար (մաս II)
Ինչպես օպտիմալացրինք Azure Cosmos DB-ն մեր հավելվածների պահեստավորման հարթակում՝ Habitat-ում, աննախադեպ աճը կառավարելու համար։
OpenAI-ի բոլոր արտադրանքներին անհրաժեշտ է տվյալների արագ և հուսալի հասանելիություն, որն ապահովում է մեր պահեստավորման հարթակը՝ Habitat-ը։ Այն պետք է միլիվայրկյանների ընթացքում պատասխանի 40 աշխարհագրական տարածաշրջանների ավելի քան 1 միլիարդ օգտատերերի հարցումներին։ Մեր ենթակառուցվածքն արտասովոր մարտահրավերի առաջ էր․ ապահովել սրընթաց աճն ու նոր կիրառությունները՝ շարունակելով բարելավել հուսալիությունը, արագագործությունը և արտադրանքների մշակման տեմպը։ Այդ խնդիրը լուծելու համար պետք էր վերանայել մեր առցանց պահեստավորման հարթակի կառուցվածքն ու շահագործումը։ Մենք մշտապես կշռադատում էինք փոխզիջումները՝ հետևյալ հերթականությամբ․ նախ՝ բավարար հուսալիություն կենսական նշանակության տրաֆիկի համար, հետո՝ բավարար արագություն ամբողջ աշխարհի օգտատերերի համար, և վերջում՝ հսկայական մասշտաբով արդյունավետ շահագործում։
Այս երկմաս շարքը պատմում է, թե ինչպես Habitat-ը պարզ հաճախորդային գրադարանից և տվյալների բազայից վերածեցինք աշխարհով մեկ բաշխված պահեստավորման հարթակի, որը սպասարկում է ավելի քան 500 պետաբայթ տվյալ։ I մասը նվիրված էր Habitat-ի՝ Python հաճախորդից ծառայության վերածվելու ընթացքին։ Այն նաև ներկայացնում էր այն մեթոդները, որոնք թույլ տվեցին Python-ի վրա հիմնված ծառայությունը զարգացնել շատերի պատկերացրած գործնական սահմաններից շատ ավելի հեռու։
Այս՝ II մասում ներկայացնում ենք, թե ինչպես մասշտաբավորեցինք հիմքում ընկած պահեստավորման բաղադրիչը՝ Azure Cosmos DB-ն։ Azure-ի թիմի հետ սերտ համագործակցությամբ մշակեցինք բազմավարձակալության կենսունակ մոտեցում՝ համատեղ կառավարվող կոնտեյներներով և ընթերցման գերազանց արագագործությամբ՝ հսկայական համաշխարհային մասշտաբով։
Գծապատկեր 01 · Ի՞նչ է Habitat-ը
Առցանց պահոցի հարթակ
Habitat-ը մեր ստեղծած առցանց պահոցի հարթակն է, որի շնորհիվ OpenAI-ի պրոդուկտներն արագ ու հուսալի հասանելիություն են ստանում անհրաժեշտ տեղեկությանը։
- Հարցում
- Պատասխան
- Փոփոխություններ (CDC)
Ընկերությունների աճին զուգընթաց ենթակառուցվածքի թիմերը հաճախ միավարձակալ համակարգերից անցնում են բազմավարձակալ համակարգերի։ Միավարձակալության դեպքում արտադրանքի յուրաքանչյուր բաղադրիչի թիմ սպասարկում է իր համակարգը։ Սա սահմանափակում է խափանումների ազդեցությունը, հստակեցնում պատասխանատվության սահմաններն ու մեկուսացնում բեռները։ Թիմերի և արտադրանքի բաղադրիչների ավելացման հետ այս մոտեցումը թանկ է դառնում։ Միավարձակալության դեպքում յուրաքանչյուր արտադրանքի թիմ պատասխանատու է հզորությունների պլանավորման համար, ինչը հաճախ հանգեցնում է զգալիորեն ավելորդ ռեսուրսների հատկացման։
Իսկ բազմավարձակալության դեպքում կառավարումը վստահվում է տվյալների բազաների կենտրոնացված թիմին, որն ավելի մեծ գիտելիք ու փորձ ունի ռեսուրսների հատկացման հարցում։ Սակայն բազմավարձակալությունն ունի իր խնդիրները, օրինակ՝ աղմկոտ հարևանները, երբ մի վարձակալ սպառում է ռեսուրսների անհամաչափ մեծ բաժինը՝ ի վնաս մյուսների։
Habitat-ում ստիպված էինք կշռադատել այս բոլոր փոխզիջումները՝ մեծ մասշտաբով հուսալի ու արդյունավետ պահեստավորման համակարգ նախագծելու համար։ Այսօր Habitat-ը OpenAI-ի բազմաթիվ արտադրանքների տվյալների բազայի բազմավարձակալ շերտն է։ Բայց մենք շրջանաձև ճանապարհ անցանք՝ Azure Cosmos DB-ի մեկ բազմավարձակալ կոնտեյներից անցնելով առանձին միավարձակալ կոնտեյներների, ապա վերադառնալով ըստ կանխադրման բազմավարձակալ կոնտեյների օգտագործմանը։ Habitat-ում բազմավարձակալության մեր պատմությունը դեռ նոր է սկսվում։ Մենք սպասարկում ենք բազմաթիվ կիրառություններ, բայց կարողացել ենք հետաձգել այս ոլորտի ներդրումները՝ հնարավորության դեպքում օգտագործելով Azure Cosmos DB-ի ներկառուցված բազային մեխանիզմները։
Նախքան Azure Cosmos DB-ի հետ մեր անցած ուղին ներկայացնելը՝ մի քանի հիմնական փաստ․
Azure Cosmos DB հաշիվը սահմանում է կոնտեյներների հավաքածու և կրկնօրինակման քաղաքականություն
Յուրաքանչյուր կոնտեյների հատկացվում է որոշակի թողունակություն՝ վայրկյանում հարցման միավորներով (RU/s)
Յուրաքանչյուր կոնտեյների տվյալները մասնատվում են ըստ նշված տրամաբանական բաժնի բանալիի․ յուրաքանչյուր բանալիի համար փաստաթղթերում սահմանված են պահեստավորման և թողունակության սահմանաչափեր
Azure Cosmos DB-ն տրամաբանական բաժինների բանալիները բաշխում է ավելի փոքր թվով ֆիզիկական բաժինների միջև։ Դրանք տրոհվում են, երբ տվյալների ծավալը գերազանցում է շեմը, կամ երբ կոնտեյներին ավելի շատ ֆիզիկական բաժիններ են պետք՝ հատկացված թողունակությունն ապահովելու համար
Սկզբում ընդունում էինք հաճախորդի ցանկացած բեռ՝ մուտքային հոսքը զսպելու համար հենվելով յուրաքանչյուր տրամաբանական բաժնի բանալիի նշված 10 հազ. RU/s սահմանաչափի վրա։ Սկզբնական շրջանում յուրաքանչյուր հաշվում նաև օգտագործում էինք միայն մեկ կանխադրված Azure Cosmos DB կոնտեյներ։ Սա բավական լավ էր աշխատում, բայց մի քանի պատճառով խնդիրներ առաջացրեց․
API-ի նախագծման սկզբնական որոշումների պատճառով տրամաբանական բաժնի բանալիի ընտրությունն ուղղակիորեն թողել էինք հաճախորդներին։ Արդյունքում տարբեր արտադրանքային կիրառություններում հաճախ համընկնում են տարածված բաժինների բանալիները, օրինակ՝ user_id-ը կամ workspace_id-ը։ Քանի որ այս կիրառությունները կիսում էին նույն տրամաբանական բաժինների բանալիների Azure Cosmos DB սահմանաչափերը, այդ կառուցվածքը սահմանափակում էր տվյալ օգտատիրոջ ընդհանուր թողունակությունը։
Մինչև Habitat-ին և Azure Cosmos DB-ին անցնելը Postgres-ի մասշտաբավորման տարածված խնդիրներից մեկն այն էր, որ շատ ակտիվ կազմակերպության կամ բանալիի բազմաթիվ հարցումները՝ մեկ վարձակալի անհամաչափ մեծ բեռը, կարող էին շարքից հանել ամբողջ տվյալների բազան։ Մեծ համատեղ ջանքեր ներդրեցինք այդ բանալիները քեշավորելու և քեշում բացակայող տվյալների հարցումների համար ժամանակավոր բացառիկ իրավունքի մեխանիզմ ստեղծելու մեջ, որպեսզի դրանց առաջացրած բեռը չգերբեռներ հիմքում ընկած տվյալների բազան։
Figure 02a · Logical partition key limits
Different clients, the same partition key
Թեև փաստաթղթերում տվյալների ծավալի և թողունակության սահմանաչափերը նշված են տրամաբանական բաժինների բանալիների համար, իրականում դրանք կիրառվում են ֆիզիկական բաժնի մակարդակում։ Գործնականում սա նշանակում է, որ տրամաբանական բաժինները չեն կարող հասնել 10 000 RU/s-ի։ Փոխարենը՝ դրանք կիսում են ֆիզիկական բաժնի սահմանաչափերը նույն բաժնում տեղակայված մյուս բոլոր տրամաբանական բաժինների բանալիների հետ։
Սա թույլ էր տալիս «աղմկոտ հարևաններին» ազդել իրար հետ կապ չունեցող բազմաթիվ տրամաբանական բաժինների բանալիների վրա․ նեղ կիրառության գործառույթների տվյալները մշակող բեռները խաթարում էին մուտքի և գրանցման հիմնական գործընթացները։
Figure 02b · Noisy neighbors
Different users, the same physical partition
Յուրաքանչյուր ֆիզիկական բաժնի թողունակության սահմանաչափը նույնպես փոփոխական է և կախված է Azure Cosmos DB կոնտեյներին հատկացված ընդհանուր թողունակությունից։ Կոնտեյներին հատկացված թողունակությունը մոտավորապես հավասարաչափ բաշխվում է դրա ֆիզիկական բաժինների միջև։
Տվյալների ծավալի աճին զուգընթաց ֆիզիկական բաժինները տրոհվում են, և դրանց ընդհանուր թիվն ավելանում է, մինչդեռ հատկացված ընդհանուր թողունակությունը մնում է անփոփոխ։ Արդյունքում տվյալների ծավալի աճին զուգընթաց յուրաքանչյուր բաժնի փաստացի թողունակության սահմանաչափը նվազում է։
Մեծածավալ բինար օբյեկտների նման տվյալներ պահող մեր ամենատարողունակ կիրառություններում սա խափանման վտանգ է ստեղծում․ միայն պահվող տվյալների աճը նվազեցնում է ակտիվ բեռների հասանելի թողունակությունը, նույնիսկ երբ հարցումների հաճախականությունն ու օգտագործումը կայուն են մնում։
Figure 02C · Weak partitions
The limit falls below demand
A partition splits when it reaches its storage limit. Each child receives half the throughput capacity.
Առանձին կոնտեյներները մասամբ լուծում են բաժինների բանալիների սահմանաչափերի և աղմկոտ հարևանների խնդիրները։ Առանձին կոնտեյներներից յուրաքանչյուրին կարելի է հատկացնել անկախ ֆիզիկական բաժիններ։ Այդ դեպքում միայն տվյալ կոնտեյների տարբեր բեռները կարող են դառնալ աղմկոտ հարևաններ կամ համընկնել բաժինների բանալիների տիրույթում։ Մյուս կողմից՝ նոր կոնտեյներների հատկացումը լրացուցիչ աշխատանք է պահանջում․ յուրաքանչյուրի հզորությունները պետք է առանձին պլանավորել։ Ուստի ցանկանում ենք դրանք ստեղծել միայն ծառայության կամ կիրառության տրամաբանական սահմաններով։
Սկսեցինք առանձին Azure Cosmos DB կոնտեյներներ օգտագործել խիստ մեկուսացում պահանջող ամենակարևոր նոր կիրառությունների համար։ Դրան ավելացրինք թույլ բաժինները կառավարող սկրիպտ, որը յուրաքանչյուր կոնտեյների ընդհանուր հատկացված թողունակությունը համապատասխանեցնում էր դրա ֆիզիկական բաժինների թվին։ Այսպես հիմնականում խուսափեցինք մեր առջև եղած բոլոր խնդիրներից։
Սակայն քանի որ սկսել էինք կանխադրված կոնտեյներից, շատ կարևոր հին կիրառություններ, ցավոք, մնացել էին այնտեղ և պահանջում էին տվյալների տեղափոխում։ Համատեղ օգտագործվող կանխադրված կոնտեյների տվյալներից դեռ կախված կարևոր ծառայությունները պաշտպանելու համար հաճախ թիմերին խորհուրդ էինք տալիս նոր ծառայությունների կամ խոշոր գործառույթների համար առանձին կոնտեյներներ ստեղծել։ Մեր մասշտաբների մեծացման հետ աճում էին և՛ կանխադրված կոնտեյների բեռը, և՛ արտադրական միջավայրի միջադեպերը։ Սկսեցինք կոնտեյներներ հատկացնել յուրաքանչյուր նոր ծառայության կամ խոշոր գործառույթի համար՝ պարզապես կանխադրված կոնտեյները լրացուցիչ բեռից պաշտպանելու նպատակով։
Սա մեզ փրկեց ամբողջ կայքն ընդգրկող բազմաթիվ խափանումներից՝ դրանց ազդեցությունը սահմանափակելով առանձին գործառույթների կամ ծառայությունների աշխատանքի վատացմամբ։ Սակայն նոր կոնտեյներներ հատկացնելու լրացուցիչ բարդություններն ի վերջո զգացնել տվեցին․
Հին համատեղ օգտագործվող կանխադրված կոնտեյներում որևէ նոր կիրառության աճը՝ 0-ից մինչև վայրկյանում 1 միլիոն հարցում (QPS), հազիվ թե զգալիորեն փոխեր ընդհանուր օգտագործումը։ Սակայն մեկուսացված կոնտեյներում նոր կիրառության աճը՝ 0-ից մինչև 1 միլիոն QPS, կարող էր նշանակել 1000 անգամ ավելի մեծ բեռ՝ համեմատած միայն ներքին փորձարկումներով պայմանավորված սկզբնական մակարդակի հետ։
Առանձնացված կոնտեյներների դեպքում թիմերը պետք է հիշեին գործարկումից առաջ ապահովել սպասվող թողունակությանը համապատասխան ռեսուրսներ։ Արտադրանքների թիմերը հաճախ գործառույթները թողարկում էին՝ մոռանալով նախապես մեծացնել հզորությունները։ Ու գործարկման օրը մենք հայտնվում էինք լուրջ միջադեպերի արձագանքման հանդիպումներում՝ վերջին պահին փորձելով մեծացնել կոնտեյներները։
Բեռների համատեղումը բազմավարձակալ համակարգերի կարևոր առավելություններից է, որը կոնտեյներների այս ռազմավարությամբ զոհաբերում ենք հանուն ավելի լավ մեկուսացման։
Figure 03 · Lack of stable aggregate growth
The same workload, different headroom
1K RU/s during load testing → 1M RU/s at launch
Ժամանակի ընթացքում առանձնացված կոնտեյներների օգտագործմանը հետևելու համար նաև անհրաժեշտ դարձավ արտադրանքի խոր իմացություն՝ հասկանալու, թե երբ կփոխվի կամ կաճի տրաֆիկը։
Կարող ենք տրամադրել կառավարման շերտի պարզ սկրիպտ, որն աճի միտումների հիման վրա կմեծացնի յուրաքանչյուր կոնտեյների հատկացված թողունակությունը։ Բայց կայուն ընդհանուր աճի բացակայության պայմաններում ճիշտ մասշտաբավորումն ըստ էության պահանջում էր OpenAI-ի գրեթե բոլոր արտադրանքային թիմերի ներգրավումը հզորությունների պլանավորման մեջ։
Կազմակերպական առումով այս մոտեցումը չէր մասշտաբավորվում․ տարբեր ծառայությունների պատասխանատու թիմերը խիստ տարբեր ուշադրություն էին դարձնում Azure Cosmos DB-ի ռեսուրսների հատկացմանը։
Կազմակերպության աճին զուգընթաց շահագործման այս խնդիրներն ավելի դժվար էր լուծել մեծ մասշտաբով։ Պլանավորման մեկ կենտրոնացված թիմ չունենալու հետևանքով բազմաթիվ թիմեր վատ էին պլանավորում։ Արդյունքում վերադարձանք բազմավարձակալ լուծման և Azure-ի թիմի հետ սերտ համագործակցությամբ մշակեցինք համատեղ վարձակալության կառուցվածք՝ մեր սկզբնական խնդիրները լուծելու համար․
Ամենաակտիվ բանալիների հարցումներն առաջինը սահմանափակելը թույլ չի տալիս, որ աղմկոտ հարևանները սպառեն տվյալ ֆիզիկական բաժնի ամբողջ հասանելի թողունակությունը։ Սա նվազեցնում է այն ազդեցությունը, որի դեպքում մեկ ակտիվ բանալին կարող է խաթարել ամբողջ կայքի աշխատանքը։
Հարցումների առաջնահերթությունների վրա հիմնված QoS-ը նմանապես թույլ չի տալիս, որ ֆոնային բեռները, օրինակ՝ տվյալների զանգվածային ավելացումը կամ տվյալների արտահանումը, օգտագործեն տվյալ ֆիզիկական բաժնի ամբողջ թողունակությունը։ Այս բեռների հարցումներին ավելի ցածր առաջնահերթություն տալով՝ առաջինը սահմանափակվում են հենց դրանք, ոչ թե վերջնական օգտատերերին սպասարկող ավելի բարձր առաջնահերթության ինտերակտիվ հարցումները։
Azure Cosmos DB-ն արդեն ուներ առանց սերվերների կառավարման ռեժիմ, որը կլուծեր նախապես հատկացված ռեսուրսների ռեժիմում առաջացած թույլ բաժինների մեր խնդիրը։ Սակայն այն ուներ լուրջ թերություն․ մասշտաբավորվում էր միայն պահեստի օգտագործման հիման վրա և RU-ի օգտագործումը սահմանափակում յուրաքանչյուր ֆիզիկական բաժնի համար 5 հազ. RU/s-ով։ Սա կլուծեր թույլ բաժինների խնդիրը, բայց թույլ չէր տա ընդլայնել մեծ քանակով RU պահանջող կիրառությունները։
Azure Cosmos DB-ի թիմը մեզ համար մշակեց այդ ռեժիմի բարելավված տարբերակը․ յուրաքանչյուր ֆիզիկական բաժին կարող էր աճել մինչև 10 հազ. RU/s, իսկ պահեստի օգտագործման հիման վրա տրոհմանը ավելացավ RU-ի օգտագործման հիման վրա տրոհումը։ Այսպիսով, այլևս պետք չէր ձեռքով վերահսկել և մեծացնել կոնտեյներները։
Այս փոփոխություններով կարողացանք վերադառնալ մեկ համատեղ օգտագործվող կոնտեյների։ Սա զգալիորեն պարզեցրեց արտադրանքների թիմերի՝ հզորությունների նախնական և ընթացիկ պլանավորման աշխատանքը՝ պահպանելով բեռների մեկուսացումը։ Դրանից հետո անցած ամիսներին ռեսուրսների հատկացման կամ աղմկոտ հարևանների հետ կապված միջադեպեր չենք ունեցել՝ չնայած արտադրանքների մշակման արագացմանը։
Երբ ընկերությունները հասնում են OpenAI-ի մասշտաբներին, կառավարվող ծառայությունները պակաս «կառավարվող» են դառնում։ Շատ բեռներ այլևս չեն տեղավորվում ամպային մատակարարի ենթակառուցվածքի սովորական օգտագործման շրջանակում։ Երբ OpenAI-ն դարձավ Azure Cosmos DB-ի խոշորագույն օգտատերերից մեկը, հաջող շահագործման համար այլ մոդել պահանջվեց՝ համատեղ թեստեր ու վերահսկման վահանակներ, ինժեներների ուղիղ հաղորդակցման ուղիներ և համատեղ պատասխանատվություն միայն մեր մասշտաբում ի հայտ եկող խափանումների համար։ Այսօր մեր ամենամեծ Azure Cosmos DB հաշիվը պահում է տասնյակ պետաբայթ տվյալ և սպասարկում վայրկյանում ավելի քան 20 միլիոն հարցում։ Մեր տեղեկություններով՝ մենք միակ ընկերությունն ենք, որն Azure Cosmos DB-ն գործարկել է այս մասշտաբով։
2024-ի վերջին տարածաշրջանային խափանումը հստակ ցույց տվեց, թե ինչու էր անհրաժեշտ այս համագործակցությունը։ Այդ ժամանակ էլեկտրամատակարարումն ընդհատվեց մեր խոշորագույն Azure Cosmos DB հաշիվներից մեկի հիմնական Azure տարածաշրջանում։ Դրան հաջորդած պահուստային տարածաշրջանին անցման փորձարկման ընթացքում պարզեցինք, որ մեր ամենամեծ հաշիվների անցումը պահուստային տարածաշրջան կտևի մի քանի ժամ։ Ո՛չ մեր թիմը, ո՛չ էլ Azure Cosmos DB-ի թիմը դա չէին փորձարկել մեր մասշտաբով։
Մոտ մեկ ամիս անց, այդ հաշիվները սկզբնական տարածաշրջան վերադարձնելիս, առաջացրինք ևս մեկ լուրջ խափանում։ Դեպի սկզբնական տարածաշրջան միացումների միաժամանակյա հոսքը գերբեռնեց այնտեղի Azure Cosmos DB դարպասը։ Դարպասի ռեժիմում Azure Cosmos DB հաճախորդի՝ տարածաշրջանների միջև անցումները մշակելու առանձնահատկության պատճառով բոլոր հաճախորդներն անմիջապես միացումներ հաստատեցին և հարցումներ ուղարկեցին սկզբնական տարածաշրջան, թեև ֆիզիկական բաժինների միայն մի մասն էր վերադարձել այնտեղ։
Յուրաքանչյուր խափանման ժամանակ և՛ OpenAI-ն, և՛ Azure-ը գործարկեցին միջադեպերի կառավարման իրենց ընթացակարգերը՝ բացահայտելով մի շարք արմատական պատճառներ և ներդնելով շտկումներ։ Բայց այս խափանումներն ավելի մեծ համակարգային խնդրի ախտանիշներ էին՝ կապված մեր և Azure Cosmos DB-ի թիմերի աշխատանքի ու փորձարկման եղանակների հետ։ Սկզբում կառավարվող ծառայությունները մեզ թույլ էին տալիս արագ առաջ շարժվել և կենտրոնանալ բիզնեսի նպատակների վրա։ Մեծ մասշտաբներում այդ ծառայությունները պակաս կառավարվող են դառնում և պահանջում մատակարարի հետ խոր ինտեգրում բոլոր մակարդակներում՝ նախագծումից մինչև շահագործում։
Այսօր Habitat-ի և Azure-ի ինժեներական թիմերը համատեղ վերահսկում են Habitat-ի բոլոր շերտերը՝ մեր ծառայություններից մինչև Azure Cosmos DB-ի ֆիզիկական պահեստավորման շերտերը։ Մենք փոփոխությունները գործարկում և փորձարկում ենք Azure Cosmos DB-ի ոչ արտադրական, բայց արտադրականին համարժեք չափի հաշվում։ Միասին փորձարկում ու բարելավում ենք SDK-ները և որոշում Azure Cosmos DB հաշիվների չափերն ընտրելու և մասշտաբավորելու լավագույն գործելակերպերը։ Teams-ի միջոցով մեր ինժեներներն անմիջական կապ ունեն միմյանց հետ։ Նույնիսկ ստեղծել ենք միմյանց ուղիղ շտապ ծանուցելու եղանակներ՝ շրջանցելով աջակցության հերթական օղակները։
Անցած տարվա ընթացքում համատեղ մեծ աշխատանք ենք կատարել՝ Azure Cosmos DB-ի կառավարման շերտի և դարպասի մասշտաբավորելիությունը բարելավելու համար։ Դարպասում ավելացրել ենք գերբեռնվածությունից պաշտպանություն և Azure Cosmos DB-ի տարբեր մետատվյալների քեշավորում՝ մետատվյալների բաժինը պաշտպանելու նպատակով։ Միացումների պուլերի և դրանց ավելի հաճախակի վերօգտագործման միջոցով նվազեցրել ենք Python-ով աշխատող habitat-service պրոցեսների բեռը, հնարավորության դեպքում աշխատանքային բեռները տեղակայել նույն վայրում և տարբեր VPC-ների միջոցով կարևոր բեռներն առանձնացրել ֆոնային բեռներից։
Ինժեներական այս սերտ համագործակցությունը վճռորոշ է եղել անցած տարվա ընթացքում մեր Azure Cosmos DB-ի կայունության համար։ Բավականաչափ մեծ կամ կարևոր ցանկացած համակարգ պահանջում է նման թիմային աշխատանք՝ պատասխանատվության ոլորտների միջև պատնեշների վերացում և համագործակցություն կազմակերպական սահմաններից դուրս։
Ինչպես նշել ենք I մասում, մեր հիմնական սկզբունքն է՝ նախ ապահովել աշխատանքը, հետո՝ արագությունը, ապա՝ ցածր ծախսը։ Նախ՝ հուսալիություն, հետո՝ արագագործություն, ապա՝ արդյունավետություն։ Habitat-ը դարձել էր OpenAI-ի համար կենսական ենթակառուցվածք, ուստի առաջնահերթ էր դրա հուսալիության ապահովումը։ Երբ 2025-ին համակարգը կայունացավ, իսկ OpenAI-ն ընդլայնվեց ամբողջ աշխարհում, օգտատերերի և արտադրանքների թիմերի համար հաջորդ սահմանափակող գործոնը դարձավ ուշացումը։
Հաշվարկային և պահեստավորման ռեսուրսները հաճախ գտնվում էին տարբեր տարածաշրջաններում, ուստի միջտարածաշրջանային հարցումներն անխուսափելի էին։
Figure 04 · Improving performance at a global scale
Global traffic
Compute and storage capacity were often located in different regions, making cross-region requests unavoidable.
Հաշվարկային և պահեստավորման ռեսուրսների աշխարհագրական դիրքերը ներկայացված են միայն պատկերավորման նպատակով։
Ուշացումը խիստ տարբերվում էր՝ կախված տվյալների պահման և հարցման սպասարկման վայրերից։ Habitat-ի հարցումներն արագացնելու համար մշակողները դիմում էին հաճախորդի կողմում լրացուցիչ քեշավորման, հարցումների խմբավորման, տվյալների բազայից ընթերցումների ու գրառումների նվազեցման և հնարավոր գործառնությունները կրիտիկական ուղուց դուրս բերելու միջոցներին։ Սա հանգեցրեց արտադրանքների հետաքրքիր լուծումների, որոնք ավելի դիմացկուն էին տվյալների բազայի խնդիրների նկատմամբ։ Բայց նաև բարդացրեց արտադրանքներն ու դանդաղեցրեց դրանց բարելավումը՝ չիրագործելով Habitat-ի նպատակը՝ խթանել արագ մշակումը՝ առանց տվյալների բազայի մանրամասներին տիրապետելու անհրաժեշտության։
2026-ին սա մեր ուշադրության հիմնական ուղղություններից է։ Մենք մշակել ենք բազմաշերտ ռազմավարություն՝ ընթերցումներն արագացնելու համար, որոնք կազմում են Habitat-ի հարցումների ավելի քան 90%-ը․
Տվյալների մշակման հավելվածի պահանջներ ունեցող օգտատերերի համար աշխարհի տարբեր Azure տարածաշրջաններում ունենք Azure Cosmos DB-ի մի շարք հաշիվներ։ Նույնիսկ տվյալների մշակման հավելվածի խիստ պահանջներ չունեցող օգտատերերի դեպքում տվյալները նրանց մոտ պահելը նվազեցնում է ուշացումն ու բարելավում օգտագործման փորձը։
Գործնականում չենք կարող սա լայնորեն կիրառել տվյալների մշակման հավելվածի դեպքերից դուրս, քանի որ տեղակայումը սահմանափակված է ամպային ֆիզիկական ռեսուրսներով։ Մեր տվյալների հավաքածուներն այնքան մեծ են, որ շատ տարածաշրջաններ չունեն իրենց բաժին օգտատերերի տրաֆիկին համապատասխանող հսկայական պահեստային տարածք։
Տվյալների կենտրոնների, էլեկտրասնուցման կամ հովացման սահմանափակ ռեսուրսներ ունեցող տարածաշրջաններում երբեմն ստիպված ենք ընտրել՝ ռեսուրսներն օգտագործել տեղային պահեստավորման և Habitat-ի ուշացումը նվազեցնելու՞, թե՞ լրացուցիչ հաշվարկային սպասարկման համար՝ պահեստավորման հարցումներն ուղարկելով ավելի հեռու։
Ուստի տեղակայման որոշումները հաճախ փոխզիջում են՝ ա) տարբեր արտադրանքների ու օգտատերերի խմբերի ուշացումն օպտիմալացնելու և բ) առկա պահեստային ու հաշվարկային հզորությունների միջև։
Ուշացման նկատմամբ առավել զգայուն բեռների, օրինակ՝ յուրաքանչյուր հարցման համար անհրաժեշտ նույնականացման մետատվյալների դեպքում կրճատում ենք հաշվարկային շերտի և Habitat-ի միջև հարցման ու պատասխանի ընդհանուր ժամանակը (RTT)՝ օգտագործելով բազմաթիվ երկրորդային տարածաշրջաններում կրկնօրինակվող Azure Cosmos DB հաշիվներ։ Որոշ հաշիվներ կրկնօրինակվում են Azure-ի բոլոր 40 տարածաշրջաններում, որտեղ տրաֆիկ ենք սպասարկում, մյուսները՝ յուրաքանչյուր մայրցամաքի առնվազն մեկ տարածաշրջանում։
Ստիպված եղանք նախատեսվածից շուտ Habitat-ում ներդնել տվյալների տեղափոխման և երթուղավորման՝ օգտատերերի համար թափանցիկ շերտ, որպեսզի կարողանանք տվյալների հավաքածուները տեղափոխել կրկնօրինակման տարբեր տոպոլոգիաներով հաշիվների միջև։
Սակայն այս մոտեցումը նույնպես ի վերջո սահմանափակվում է ռեսուրսներով և կիրառվում է միայն մի քանի հատուկ ընտրված տվյալների հավաքածուների համար։
Habitat-ի բեռներում գերակշռում են ընթերցումները․ հավելվածներն անընդհատ բեռնում են կարգավորումներ, վիճակ և այլ հատկություններ։ Տրաֆիկի անհամաչափ մեծ մասը բաժին է ընկնում հաճախ օգտագործվող տիպերի համեմատաբար փոքր աշխատանքային հավաքածուին։ Ուստի համակարգը հատկապես հարմար է բաշխված քեշավորման համար։ Քեշավորումն արագացնում է մեկ տարածաշրջանի ենթակառուցվածքը, իսկ տարբեր տարածաշրջանների դեպքում օգուտն ավելի է մեծանում․ այն կարող է «թաքցնել» միջտարածաշրջանային ուշացումը։
Habitat-ում ինտեգրել ենք բաշխված քեշավորման շերտ, որին դիմում ենք մինչև հիմնական պահեստից ընթերցելը։ Այն վերջերս օգտագործված օբյեկտների և կապերի պատճենները պահում է մեր ենթակառուցվածքի Valkey սերվերներում՝ օգտատերերի հարցումների մշակման վայրին մոտ։ Նման քեշերը սովորաբար օգտագործում են պահպանման ժամկետ (TTL)՝ հավասարակշռելով քեշում տվյալները գտնելու հաճախականությունն ու դրանց հնացումը։ Կարճ TTL-ները նվազեցնում են հնացումը, բայց թուլացնում քեշավորման օգուտը․ տարրերն արագ հեռացվում են քեշից և պետք է ավելի հաճախ նորից բեռնվեն։ Երկար TTL-ները մեծացնում են քեշում տվյալները գտնելու հավանականությունը, բայց ավելի երկար են մատուցում հնացած տվյալներ՝ վատացնելով օգտագործման փորձն ու արտադրանքի վարքագիծը դարձնելով անկանխատեսելի։
Մեկ այլ մոտեցում է քեշի տվյալների բացահայտ անվավերացումը, երբ հավելվածը գրառում է կատարում նույն սկզբնաղբյուր տվյալներում։ Սա զգալիորեն բարելավում է քեշավորված տվյալների արդիականությունը, բայց ճիշտ իրագործելը կարող է դժվար լինել։ Պահպանվում են նաև մի շարք բացառիկ դեպքեր, օրինակ՝ մասնակի խափանումները, որոնց հետևանքով քեշը մնում է հնացած։ Բազմատարածաշրջանային տեղակայումները սրում են այս խնդիրները․ միջտարածաշրջանային ցանցերն ավելի պակաս հուսալի են, իսկ քեշի թարմացումն ու հիմնական պահեստի կրկնօրինակումը կարող են մրցակցել։ TTL ավելացնելը սահմանափակում է հնացման առավելագույն տևողությունը, բայց պահպանում է վերոնշյալ փոխզիջումը։
Մենք անվավերացման ավելի առաջադեմ մոտեցում ենք ընտրել՝ հետևելով Meta-ի TAO-ի նման համակարգերի օրինակին։ Habitat-ի ինտեգրված քեշը Azure Cosmos DB-ի փոփոխությունների հոսքի միջոցով որսում է տվյալների փոփոխությունները (CDC) և վայրկյանների ընթացքում անվավերացումները տարածում աշխարհով մեկ՝ տվյալների հնացման ցածր մակարդակով և քեշում դրանք գտնելու բարձր հաճախականությամբ։ Մեր ենթակառուցվածքի ծառայություններից մեկը կարդում է այս հոսքը և հիմնական տվյալների թարմացման դեպքում անվավերացնում տեղային քեշերը։ Հաջորդ ընթերցման ժամանակ տվյալը քեշում չի գտնվում, և քեշը լրացվում է դրա վերջին տարբերակով։
Նաև զգալիորեն կրճատել ենք ուշացումը՝ նվազեցնելով հենց Habitat ծառայության լրացուցիչ հաշվարկային ծախսը։ Կոդը վերագրել ենք Rust-ով, որն ավելի արագագործ է, քան սկզբնական Python-ը։
Այս փոփոխությունները միասին ընթերցման համաշխարհային ընդհանուր p50 ուշացումը մոտ 120 մվ-ից իջեցրել են մոտ 10 մվ-ի՝ 12-ապատիկ բարելավում այս տարվա սկզբին արագագործության վրա կենտրոնանալուց ի վեր։
Figure 05 · Improving performance at a global scale
p50 latency for reads
Three major design changes improved read latency
Թեև քեշավորումը կտրուկ նվազեցրել է միջնարժեքային ուշացումը, ամենադանդաղ հարցումները դեռ պահանջում են չքեշավորված տվյալների բեռնում հիմնական պահեստից՝ հաճախ հեռավոր տարածաշրջաններից։ Նոր հզորությունների գործարկմանը և պահեստավորման արդյունավետության բարելավմանը զուգընթաց ծրագրում ենք լուծել ավելի հիմնարար խնդիր՝ տվյալներն ի սկզբանե տեղակայել դրանց օգտագործման վայրին մոտ։
Հուսալի և մասշտաբավորվող CDC-ն՝ տվյալների բազայի փոփոխությունները հետագա համակարգերին փոխանցելը, կարևոր է ոչ միայն Habitat-ի քեշավորման ռազմավարության համար։ Հազարավոր կոնտեյներներից ու դրանց միլիոնավոր բաժիններից վայրկյանում որսվող միլիոնավոր փոփոխություններն անցնում են Kafka-ի ավելի քան հարյուր թեմաներով։ Դրանք նաև ապահովում են ի վերջո համաձայնեցվող երկրորդային ինդեքսների, տվյալների տեղափոխման հոսքագծերի, ֆոնային վերլուծության և իրական ժամանակում գործող այլ գործառույթների աշխատանքը։ Մեր բազային ենթակառուցվածքի համաշխարհային աճի հետ տողերի փոփոխություններին հետևելը գնալով բարդացել է։ Իր տիպի տողերի յուրաքանչյուր փոփոխության ժամանակ կանչվող ֆունկցիա գրանցելու համար հաճախորդը նախ պետք է պարզի՝ Cosmos-ի որ հաշիվներում ու կոնտեյներներում են իր տվյալները, որ տարածաշրջաններում CDC-ի որ տեղակայումն է հետևում դրանց, և պատշաճ մասշտաբավորի CDC-ի աշխատող պրոցեսները, Kafka-ն ու իր սպառող պրոցեսը։ Մեր CDC հարթակի նպատակն է այս ամենը թաքցնել արտադրանքների մշակողներից և տալ պարզ միջերես․ հաճախորդները գրանցում են փոփոխված տողերի համար կանչվող ֆունկցիան, իսկ ամբողջ ներքին կապակցումն ու մասշտաբավորումը կատարում ենք մենք։
Ներքին կառավարման շերտը մշտապես ապահովում է բոլոր անհրաժեշտ կոնտեյներների փոփոխությունների որսումը, ընտրում Cosmos-ի ընթերցման տարածաշրջանները և աշխատանքն արդյունավետ բաշխում տարբեր տարածաշրջանների հազարավոր աշխատող պրոցեսների միջև։ Կրկնօրինակ տարածաշրջաններն ու հոսքի ցածր առաջնահերթությամբ ընթերցումները Habitat-ի ուշացման նկատմամբ զգայուն տրաֆիկը պաշտպանում են ֆոնային որսման բեռներից։ Այսքան մեծ համակարգում անընդհատ պատահում են աշխատող պրոցեսների խափանումներ, կոնտեյներների խնդիրներ, ժամանակավոր իրավունքների պահեստի սխալներ, անվավեր կարգավորումներ և նպատակակետի խափանումներ։ Ամրապնդել ենք CDC-ի աշխատող պրոցեսների կենսացիկլի և ժամանակավոր իրավունքների կառավարումը, մեկուսացրել հոսքերի խափանումները և պաշտպանիչ մեխանիզմներ ներդրել կարգավորումների փոփոխման ու գործարկումների համար։ Օգտագործում ենք չառաքված հաղորդագրությունների հերթեր, որպեսզի առաքման մշտական խափանումները չարգելափակեն հերթի սկիզբը։ Տարածաշրջանային խափանումների դեպքում ընթերցող պրոցեսներն անցկացնում ենք Cosmos-ի այլ տարածաշրջանների։ Մեր մասշտաբում նույնիսկ ստիպված ենք եղել փոխել Azure-ի CDC SDK-ն՝ վերահսկիչ կետերի պահպանումն ավելի արդյունավետ դարձնելու համար․ դրանք խմբավորում ենք հիշողության մեջ և միայն պարբերաբար գրում պահեստում։
Թեև Habitat-ում Azure Cosmos DB-ի ներքին օգտագործումը բարդ է, դրա արժեքը միշտ եղել է ենթակառուցվածքի մանրամասները մշակողներից թաքցնելը՝ արտադրանքների ստեղծումն արագացնելու համար։ Մեր CDC հարթակը բացառություն չէ։
Փոքր թիմը կարողացավ սպասարկել արագ աճող պահեստավորման հարթակը՝ պահեստի API-ն միտումնավոր սահմանափակ պահելով, շարունակելով մասշտաբավորել Python ծառայությունը և առաջնահերթ լուծելով ամենահրատապ ինժեներական խնդիրները։ Նախ կենտրոնացանք կենսական նշանակության տրաֆիկի հուսալիության վրա, հետո՝ ամբողջ աշխարհի օգտատերերի ընթերցումների արագագործության, իսկ վերջում՝ մեծ մասշտաբով շահագործման արդյունավետության։ Այս մոտեցումն ապահովեց արագ աճ և նոր կիրառություններ՝ միաժամանակ բարելավելով հուսալիությունը, արագագործությունն ու արտադրանքների մշակման տեմպը։
Հաջորդ միլիարդ օգտատերերի համար Habitat-ն ու զրույցների տվյալների պահեստավորումը մասշտաբավորելու նպատակով պետք է լուծենք մեր ենթակառուցվածքում տվյալներն ավելի մեծ մասշտաբով կրկնօրինակելու բարդ խնդիրը։ Դրան նախապես պատրաստվելու համար սեփական ուժերով ստեղծում ենք էքսաբայթային մասշտաբի առցանց պահեստավորման հատուկ համակարգ՝ օպտիմալացված Habitat-ի ծավալուն տվյալների տիպերի համար։ Մշակվող այս համակարգը համադրում է Rockset-ի RocksDB Cloud միջուկը Raft-ի վրա հիմնված կրկնօրինակման հետ։ Այն կիրառում է փաստաթղթերի նույն մոդելը, ինչ Azure Cosmos DB-ն, բայց օգտագործում է տարանջատված պահեստավորում և ֆիզիկական կրկնօրինակում՝ ֆլեշ հիշողության պահանջվող ծավալը նվազեցնելու համար՝ առավելագույն QPS-ի նվազման գնով։
Եթե ցանկանում եք աշխատել տվյալների ենթակառուցվածքի նման նախագծերի վրա՝ առաջադեմ մասշտաբով, ծանոթացեք մեր թափուր հաստիքներին։
