Մենք բոլորս սիրում ենք պատմություններ: Մենք սիրում ենք նստել կրակի շուրջ և խոսել մեր անցյալի հաղթանակների, մարտերի կամ պարզապես աշխատանքային փորձի մասին։
Այսօր հենց այդպիսի օր է։ Եվ նույնիսկ եթե դուք այս պահին կրակի մոտ չեք, մենք ձեզ համար պատմություն ունենք: Պատմություն, թե ինչպես մենք սկսեցինք աշխատել Tarantool-ի պահեստավորման հետ:
Ժամանակին մեր ընկերությունն ուներ բոլորի համար մի երկու «մոնոլիտ» և մեկ «առաստաղ», որին դանդաղ, բայց հաստատ մոտենում էին այս մոնոլիտները՝ սահմանափակելով մեր ընկերության թռիչքը, մեր զարգացումը։ Եվ հստակ ըմբռնում կար՝ մի օր այս առաստաղին ուժեղ կխփենք։
Այժմ ամեն ինչ և բոլորին տարանջատելու գերիշխող գաղափարախոսությունն է՝ տեխնիկայից մինչև բիզնես տրամաբանություն: Արդյունքում, մենք, օրինակ, ունենք երկու DC, որոնք գործնականում անկախ են ցանցի մակարդակով: Եվ հետո ամեն ինչ լրիվ այլ էր։
Այսօր կան բազմաթիվ գործիքներ և գործիքներ CI/CD, K8S և այլնի տեսքով փոփոխություններ կատարելու համար։ «Միաձույլ» ժամանակ մեզ այդքան օտար բառեր պետք չէին. Բավական էր պարզապես ուղղել «պահեստը» տվյալների բազայում։
Սակայն ժամանակն առաջ էր շարժվում, և դրա հետ մեկտեղ առաջ էին շարժվում նաև հարցումների քանակը՝ երբեմն նկարահանելով RPS-ը մեր հնարավորություններից դուրս: ԱՊՀ երկրների շուկա մուտք գործելու դեպքում առաջին մոնոլիտի տվյալների բազայի պրոցեսորի ծանրաբեռնվածությունը չի իջել 90%-ից, իսկ RPS-ը մնաց 2400-ի մակարդակում: Եվ սրանք ոչ միայն փոքր ընտրիչներ էին, այլ ծանրակշիռ հարցումներ: չեկերի և JOIN-ների մի խումբ, որոնք կարող են աշխատել տվյալների գրեթե կեսի համար՝ մեծ IO-ի ֆոնի վրա:
Երբ «Սև ուրբաթ»-ի լիարժեք վաճառքները սկսեցին հայտնվել ասպարեզում, և Wildberries-ն առաջիններից մեկն էր, որ դրանք անցկացրեց Ռուսաստանում, իրավիճակը դարձավ ամբողջովին տխուր: Ի վերջո, նման օրերին բեռը երեք անգամ ավելանում է:
Ա՜խ, այս «միաձույլ ժամանակները»։ Համոզված եմ, որ դուք էլ եք նման բան ապրել, և դեռ չեք կարող հասկանալ, թե ինչպես դա կարող է պատահել ձեզ հետ:
Ի՞նչ կարող ես անել՝ նորաձևությունը բնորոշ է տեխնոլոգիային: Մոտ 5 տարի առաջ մենք ստիպված էինք վերանայել այս ռեժիմներից մեկը .NET և MS SQL սերվերի վրա գոյություն ունեցող կայքի տեսքով, որը խնամքով պահպանում էր հենց կայքի ողջ տրամաբանությունը: Այնքան խնամքով էի պահում, որ նման մոնոլիտ սղոցելը երկար ու ամենևին էլ հեշտ հաճույք ստացվեց։
Մի փոքր շեղում.
Տարբեր միջոցառումների ժամանակ ես ասում եմ. «եթե մոնոլիտ չես տեսել, ուրեմն չես աճել»: Ինձ հետաքրքրում է ձեր կարծիքն այս հարցի վերաբերյալ, խնդրում եմ գրեք այն մեկնաբանություններում։
A Sound of Thunder
Վերադառնանք մեր «խարույկին». «Միաձույլ» ֆունկցիոնալության բեռը բաշխելու համար մենք որոշեցինք համակարգը բաժանել բաց կոդով տեխնոլոգիաների վրա հիմնված միկրոծառայությունների: Քանի որ, նվազագույնը, դրանք ավելի էժան են մասշտաբով: Եվ մենք ունեինք 100% ըմբռնում, որ մենք պետք է մասշտաբներ անենք (և շատ): Չէ՞ որ արդեն այն ժամանակ հնարավոր էր դուրս գալ հարեւան երկրների շուկաներ, և գրանցումների, ինչպես նաև պատվերների թիվը սկսեց էլ ավելի ուժեղ աճել։
Վերլուծելով մոնոլիտից դեպի միկրոծառայություններ մեկնելու առաջին թեկնածուներին՝ մենք հասկացանք, որ դրանցում գրվածների 80%-ը գալիս է back office համակարգերից, իսկ ընթերցանությունը՝ առջևի գրասենյակից: Առաջին հերթին դա վերաբերում էր մեզ համար մի քանի կարևոր ենթահամակարգերի՝ օգտատերերի տվյալների և ապրանքների վերջնական արժեքի հաշվարկման համակարգի հիման վրա՝ հաճախորդների լրացուցիչ զեղչերի և կտրոնների մասին տեղեկատվության հիման վրա:
Նահանջված. Հիմա սարսափելի է պատկերացնել, բայց բացի վերը նշված ենթահամակարգերից, մեր մոնոլիտից հանվել են նաև ապրանքների կատալոգները, օգտագործողների գնումների զամբյուղը, ապրանքների որոնման համակարգը, ապրանքների կատալոգների զտման համակարգը և տարբեր տեսակի առաջարկությունների համակարգեր: Նրանցից յուրաքանչյուրի շահագործման համար կան նեղ հարմարեցված համակարգերի առանձին դասեր, բայց մի ժամանակ նրանք բոլորն ապրում էին մեկ «տանում»:
Մենք անմիջապես պլանավորեցինք մեր հաճախորդների մասին տվյալները փոխանցել բեկորային համակարգին: Ապրանքների վերջնական արժեքի հաշվարկման ֆունկցիոնալության հեռացումը պահանջում էր ընթերցման լավ մասշտաբայնություն, քանի որ այն ստեղծում էր RPS-ի ամենամեծ բեռը և ամենադժվարն էր իրագործվում տվյալների բազայի համար (հաշվարկման գործընթացում ներգրավված են շատ տվյալներ):
Արդյունքում մենք ստեղծեցինք մի սխեմա, որը լավ է համապատասխանում Tarantool-ին:
Այն ժամանակ միկրոծառայությունների շահագործման համար ընտրվեցին վիրտուալ և ապարատային մեքենաներով մի քանի տվյալների կենտրոնների հետ աշխատելու սխեմաներ։ Ինչպես ցույց է տրված նկարներում, Tarantool-ի կրկնօրինակման տարբերակները կիրառվել են ինչպես master-master, այնպես էլ master-slave ռեժիմներում:
Ճարտարապետություն. Տարբերակ 1. Օգտատիրոջ սպասարկում
Ներկա պահին կան 24 բեկորներ, որոնցից յուրաքանչյուրն ունի 2 օրինակ (մեկը յուրաքանչյուր DC-ի համար), բոլորը Master-Master ռեժիմում:
Տվյալների բազայի վերևում կան հավելվածներ, որոնք մուտք են գործում տվյալների բազայի կրկնօրինակներ: Հավելվածներն աշխատում են Tarantool-ի հետ մեր հատուկ գրադարանի միջոցով, որն իրականացնում է Tarantool Go վարորդի միջերեսը: Նա տեսնում է բոլոր կրկնօրինակները և կարող է աշխատել վարպետի հետ՝ կարդալ և գրել: Ըստ էության, այն իրականացնում է կրկնօրինակների հավաքածուի մոդելը, որն ավելացնում է կրկնօրինակների ընտրության տրամաբանություն, կրկնակի փորձեր կատարելու, անջատիչ և արագության սահմանաչափ:
Այս դեպքում հնարավոր է կարգավորել կրկնօրինակների ընտրության քաղաքականությունը բեկորների համատեքստում: Օրինակ, կլոր ռոբին:
Ճարտարապետություն. Տարբերակ 2. Ապրանքների վերջնական ինքնարժեքի հաշվարկման ծառայություն
Մի քանի ամիս առաջ ապրանքների վերջնական արժեքը հաշվարկելու հարցումների մեծ մասը գնաց նոր ծառայության, որը, սկզբունքորեն, աշխատում է առանց տվյալների բազաների, բայց որոշ ժամանակ առաջ ամեն ինչ 100% մշակվել է Tarantool-ի տակ գտնվող ծառայության կողմից:
Ծառայությունների տվյալների բազան բաղկացած է 4 վարպետներից, որոնցում համաժամեցիչը հավաքում է տվյալներ, և այս կրկնօրինակման վարպետներից յուրաքանչյուրը տվյալներ է բաշխում միայն կարդալու կրկնօրինակներին: Յուրաքանչյուր վարպետ ունի մոտավորապես 15 նման կրկնօրինակ:
Առաջին, կամ երկրորդ սխեմայի դեպքում, եթե մեկ DC-ն անհասանելի է, ապա հավելվածը կարող է տվյալներ ստանալ երկրորդում:
Հարկ է նշել, որ Tarantool-ում կրկնօրինակումը բավականին ճկուն է և կարող է կազմաձևվել գործարկման ժամանակ: Այլ համակարգերում դժվարություններ առաջացան։ Օրինակ՝ PostgreSQL-ում max_wal_senders և max_replication_slots պարամետրերը փոխելը պահանջում է մոգերի վերագործարկում, ինչը որոշ դեպքերում կարող է հանգեցնել հավելվածի և DBMS-ի միջև կապերի խզման:
Փնտրեք և կգտնեք:
Ինչո՞ւ մենք դա չարեցինք «նորմալ մարդկանց նման», այլ ընտրեցինք անտիպ ճանապարհ։ Դա կախված է նրանից, թե ինչն է համարվում նորմալ: Շատ մարդիկ սովորաբար կլաստեր են կազմում Մոնգոյից և տարածում այն երեք աշխարհաբաշխված DC-ների վրա:
Այն ժամանակ մենք արդեն ունեինք Redis-ի երկու նախագիծ։ Առաջինը քեշ էր, իսկ երկրորդը ոչ շատ կարևոր տվյալների համար մշտական պահեստ էր: Նրա հետ բավականին դժվար էր, մասամբ մեր մեղքով։ Երբեմն բավականին մեծ ծավալներ էին բանալին, և ժամանակ առ ժամանակ կայքը վատանում էր։ Մենք օգտագործել ենք այս համակարգը master-slave տարբերակում: Եվ շատ դեպքեր են եղել, երբ վարպետի հետ ինչ-որ բան է պատահել, և կրկնօրինակումը խափանվել է:
Այսինքն, Redis-ը լավ է քաղաքացիություն չունեցող խնդիրների համար, ոչ թե պետական: Սկզբունքորեն, այն թույլ էր տալիս լուծել խնդիրների մեծ մասը, բայց միայն այն դեպքում, եթե դրանք լինեին առանցքային արժեքային լուծումներ՝ զույգ ինդեքսներով: Բայց Ռեդիսն այն ժամանակ բավականին տխուր էր համառությամբ և կրկնօրինակմամբ: Բացի այդ, դժգոհություններ են եղել կատարողականի վերաբերյալ։
Մենք մտածեցինք MySQL-ի և PostgreSQL-ի մասին: Բայց առաջինը ինչ-որ կերպ մեզ հետ չհասավ, իսկ երկրորդն ինքնին բավականին բարդ արտադրանք է, և դրա վրա պարզ ծառայություններ կառուցելն անտեղի կլիներ:
Մենք փորձեցինք RIAK, Cassandra, նույնիսկ գրաֆիկական տվյալների բազա: Սրանք բոլորը բավականին խորշ լուծումներ են, որոնք հարմար չէին ծառայություններ ստեղծելու ընդհանուր ունիվերսալ գործիքի դերի համար:
Ի վերջո, մենք տեղավորվեցինք Տարանտուլում:
Մենք դիմեցինք դրան, երբ այն 1.6 տարբերակում էր: Մեզ դա հետաքրքրում էր բանալի-արժեքի սիմբիոզով և հարաբերական տվյալների բազայի ֆունկցիոնալությամբ: Կան երկրորդական ինդեքսներ, գործարքներ և բացատներ, դրանք նման են աղյուսակների, բայց ոչ պարզ, դրանցում կարելի է տարբեր քանակությամբ սյունակներ պահել: Բայց Tarantool-ի սպանիչ հատկանիշը երկրորդական ինդեքսներն էին, որոնք համակցված էին առանցքային արժեքի և գործարքների հետ:
Չաթում օգնելու պատրաստակամ ռուսախոս համայնքը նույնպես իր դերն ունեցավ։ Մենք ակտիվորեն օգտագործում էինք սա և ապրում անմիջապես չաթում: Եվ մի մոռացեք պարկեշտ համառության մասին՝ առանց ակնհայտ սխալների և սխալների։ Եթե դուք նայեք մեր պատմությանը Tarantool-ի հետ, ապա մենք շատ ցավեր և ձախողումներ ունեցանք կրկնօրինակման հետ կապված, բայց մենք երբեք չենք կորցրել տվյալները նրա մեղքով:
Իրականացումը կոպիտ մեկնարկ ունեցավ
Այն ժամանակ մեր զարգացման հիմնական ստեկը .NET-ն էր, որին Tarantool-ի համար միակցիչ չկար: Մենք անմիջապես սկսեցինք ինչ-որ բան անել Go-ում: Այն լավ աշխատեց նաև Լուայի հետ: Այն ժամանակ գլխավոր խնդիրը վրիպազերծման հետ էր. .NET-ում ամեն ինչ հիանալի է սրա հետ, բայց դրանից հետո դժվար էր սուզվել ներկառուցված Lua-ի աշխարհ, երբ լոգերից բացի վրիպազերծում չունես: Բացի այդ, ինչ-ինչ պատճառներով կրկնօրինակումը պարբերաբար քանդվում էր, ուստի ես ստիպված էի խորանալ Tarantool շարժիչի կառուցվածքի մեջ: Զրույցն օգնեց այս, և ավելի փոքր չափով, փաստաթղթերը, երբեմն մենք նայում էինք կոդը: Այն ժամանակ փաստաթղթավորումն այսպես էր.
Այսպիսով, մի քանի ամիսների ընթացքում ես կարողացա գլուխս հանել և արժանապատիվ արդյունքներ ստանալ Tarantool-ի հետ աշխատելուց: Մենք հավաքեցինք git-ի տեղեկատու մշակումներ, որոնք օգնեցին նոր միկրոծառայությունների ձևավորմանը: Օրինակ, երբ խնդիր էր առաջանում՝ ստեղծել մեկ այլ միկրոսերվիս, ծրագրավորողը նայեց տեղեկատու լուծման աղբյուրի կոդը պահեստում, և նորը ստեղծելու համար պահանջվեց ոչ ավելի, քան մեկ շաբաթ:
Սրանք հատուկ ժամանակներ էին: Պայմանականորեն, այնուհետև կարող եք մոտենալ ադմինիստրատորին հաջորդ սեղանի մոտ և հարցնել. «Տվեք ինձ վիրտուալ մեքենա»: Մոտ երեսուն րոպե անց մեքենան արդեն ձեզ մոտ էր։ Դուք ինքներդ միացաք, ամեն ինչ տեղադրեցիք, և երթևեկությունը ուղարկվեց ձեզ:
Այսօր դա այլևս չի աշխատի. դուք պետք է ծառայությանը ավելացնեք մոնիտորինգ և գրանցում, ծածկեք ֆունկցիոնալությունը թեստերով, պատվիրեք վիրտուալ մեքենա կամ առաքում Kuber և այլն: Ընդհանրապես, այսպես ավելի լավ կլինի, թեև ավելի երկար կպահանջվի և ավելի անհանգիստ կլինի։
Բաժանիր և տիրիր. Ի՞նչ կապ ունի Լուայի հետ:
Լուրջ երկընտրանք կար. որոշ թիմեր չկարողացան արժանահավատորեն փոփոխություններ կատարել Lua-ում մեծ տրամաբանությամբ ծառայության մեջ: Սա հաճախ ուղեկցվում էր ծառայության չաշխատելով։
Այսինքն՝ մշակողները ինչ-որ փոփոխություն են նախապատրաստում։ Tarantool-ը սկսում է միգրացիան, բայց կրկնօրինակը դեռ հին կոդով է. Որոշ DDL կամ այլ բան այնտեղ է հասնում կրկնօրինակման միջոցով, և կոդը պարզապես քանդվում է, քանի որ այն հաշվի չի առնվում: Արդյունքում, ադմինիստրատորների թարմացման կարգը դրվեց A4 թերթիկի վրա. դադարեցնել կրկնօրինակումը, թարմացնել սա, միացնել կրկնօրինակումը, անջատել այստեղ, թարմացնել այնտեղ: Մղձավանջ!
Արդյունքում, հիմա մենք ամենից հաճախ փորձում ենք ոչինչ չանել Լուայում։ Պարզապես օգտագործեք iproto (երկուական արձանագրություն սերվերի հետ փոխգործակցության համար), և վերջ: Միգուցե սա ծրագրավորողների գիտելիքների պակաս է, բայց այս տեսանկյունից համակարգը բարդ է։
Մենք միշտ չէ, որ կուրորեն հետևում ենք այս սցենարին. Այսօր մենք չունենք սև ու սպիտակ՝ կա՛մ ամեն ինչ Լուայում է, կա՛մ ամեն ինչ Գոյում է։ Մենք արդեն հասկանում ենք, թե ինչպես կարող ենք դրանք համատեղել, որպեսզի հետո չհայտնվենք միգրացիոն խնդիրների առաջ:
Որտե՞ղ է այժմ Tarantool-ը:
Tarantool-ն օգտագործվում է ապրանքների վերջնական արժեքի հաշվարկման ծառայությունում՝ հաշվի առնելով զեղչի կտրոնները, որը նաև հայտնի է որպես «Խթանող»: Ինչպես ավելի վաղ ասացի, նա այժմ թոշակի է անցնում. նրան փոխարինում է նոր կատալոգային ծառայություն՝ նախապես հաշվարկված գներով, սակայն վեց ամիս առաջ բոլոր հաշվարկները կատարվել են Promotizer-ում։ Նախկինում դրա տրամաբանության կեսը գրված էր Լուա լեզվով։ Երկու տարի առաջ ծառայությունը վերածվեց պահեստի, և տրամաբանությունը վերաշարադրվեց Go-ում, քանի որ զեղչերի մեխանիզմը մի փոքր փոխվել էր, և ծառայությունը զուրկ էր կատարողականությունից։
Ամենակարևոր ծառայություններից մեկը օգտվողի պրոֆիլն է: Այսինքն, Wildberries-ի բոլոր օգտատերերը պահվում են Tarantool-ում, և նրանց թիվը մոտ 50 միլիոն է: Համակարգ, որը բաժանված է օգտվողի ID-ով, որը բաշխված է Go ծառայություններին միացած մի քանի DC-ներում:
Ըստ RPS-ի, Promoter-ը ժամանակին առաջատարն էր՝ հասնելով 6 հազար հարցումների։ Մի պահ ունեինք 50-60 օրինակ։ Այժմ RPS-ում առաջատարը օգտատերերի պրոֆիլներն են՝ մոտ 12 հազար: Այս ծառայությունը օգտագործում է մաքսային համօգտագործում, բաժանված օգտատերերի ID-ների տիրույթներով: Ծառայությունը սպասարկում է 20-ից ավելի մեքենաներ, բայց սա չափազանց շատ է, նախատեսում ենք կրճատել հատկացված ռեսուրսները, քանի որ դրա համար 4-5 մեքենայի հզորությունը բավարար է։
Session ծառայությունը մեր առաջին ծառայությունն է vshard-ի և Cartridge-ի վրա: Vshard-ի տեղադրումը և Քարթրիջի թարմացումը մեզանից որոշակի ջանքեր պահանջեցին, բայց ի վերջո ամեն ինչ ստացվեց:
Կայքում և բջջային հավելվածում տարբեր պաստառներ ցուցադրելու ծառայությունն առաջիններից էր, որը թողարկվեց անմիջապես Tarantool-ում։ Այս ծառայությունն աչքի է ընկնում նրանով, որ այն 6-7 տարեկան է, այն դեռ գործում է և երբեք չի վերագործարկվել։ Օգտագործվել է Master-master replication: Ոչինչ երբեք չի կոտրվել:
Պահեստային համակարգում արագ հղման գործառույթի համար Tarantool-ի օգտագործման օրինակ կա՝ որոշ դեպքերում տեղեկատվությունը արագ կրկնակի ստուգելու համար: Մենք փորձեցինք օգտագործել Redis-ը դրա համար, բայց հիշողության մեջ եղած տվյալները ավելի շատ տեղ էին զբաղեցնում, քան Tarantool-ը:
Tarantool-ի հետ աշխատում են նաև սպասման ցուցակի, հաճախորդների բաժանորդագրությունների, ներկայումս մոդայիկ պատմությունների և հետաձգված ապրանքների ծառայությունները: Հիշողության վերջին ծառայությունը զբաղեցնում է մոտ 120 ԳԲ: Սա վերը նշվածներից ամենաընդգրկուն ծառայությունն է:
Ամփոփում
Շնորհիվ երկրորդական ինդեքսների, որոնք համակցված են առանցքային արժեքի և գործառնականության հետ, Tarantool-ը լավ հարմարեցված է միկրոծառայությունների վրա հիմնված ճարտարապետությունների համար: Այնուամենայնիվ, մենք դժվարությունների հանդիպեցինք Lua-ում շատ տրամաբանությամբ ծառայությունների փոփոխություններ կատարելիս. ծառայությունները հաճախ դադարում էին աշխատել: Մենք չկարողացանք դա հաղթահարել, և ժամանակի ընթացքում եկանք Lua-ի և Go-ի տարբեր համակցությունների. մենք գիտենք, թե որտեղ օգտագործել մի լեզու և որտեղ օգտագործել մյուսը:
Էլ ինչ կարդալ թեմայի շուրջ
- Բարձր բեռնված հավելվածի ստեղծում զրոյից՝ օգտագործելով Tarantool
- Վստահելի առաջնորդի ընտրություն Tarantool Cartridge-ում
- Telegram ալիք Tarantool ապրանքի մասին նորություններով
- Քննարկեք Tarantool-ը համայնքի չաթում
Source: www.habr.com