Բարև բոլորին, ես Ալեքսանդրն եմ, ես աշխատում եմ CIAN-ում որպես ինժեներ և ներգրավված եմ համակարգի կառավարման և ենթակառուցվածքի գործընթացների ավտոմատացման մեջ: Նախորդ հոդվածներից մեկի մեկնաբանություններում մեզ խնդրեցին ասել, թե որտեղից ենք ստանում օրական 4 ՏԲ գերան և ինչ ենք անում դրանց հետ: Այո, մենք ունենք բազմաթիվ տեղեկամատյաններ, որոնց մշակման համար ստեղծվել է առանձին ենթակառուցվածքային կլաստեր, որը թույլ է տալիս արագ լուծել խնդիրները։ Այս հոդվածում ես կխոսեմ այն մասին, թե ինչպես ենք մենք այն հարմարեցրել մեկ տարվա ընթացքում տվյալների անընդհատ աճող հոսքի հետ աշխատելու համար:
Որտեղի՞ց սկսեցինք:
Վերջին մի քանի տարիների ընթացքում cian.ru-ի բեռը շատ արագ աճել է, և 2018 թվականի երրորդ եռամսյակում ռեսուրսների տրաֆիկը հասել է ամսական 11.2 միլիոն եզակի օգտագործողների: Այն ժամանակ կրիտիկական պահերին մենք կորցրեցինք գերանների մինչև 40%-ը, ինչի պատճառով չկարողացանք արագորեն զբաղվել միջադեպերով և շատ ժամանակ ու ջանք ծախսեցինք դրանք լուծելու համար։ Մենք նաև հաճախ չէինք կարողանում գտնել խնդրի պատճառը, և որոշ ժամանակ անց այն կրկնվում էր։ Դա դժոխք էր, և պետք էր ինչ-որ բան անել դրա դեմ:
Այն ժամանակ մենք օգտագործում էինք 10 տվյալների հանգույցներից բաղկացած կլաստեր ElasticSearch 5.5.2 տարբերակով, ստանդարտ ինդեքսի կարգավորումներով՝ տեղեկամատյանները պահելու համար: Այն ներկայացվեց ավելի քան մեկ տարի առաջ որպես հանրաճանաչ և մատչելի լուծում. այն ժամանակ գերանների հոսքն այնքան էլ մեծ չէր, ոչ ստանդարտ կոնֆիգուրացիաներով հանդես գալն իմաստ չուներ:
Մուտքային տեղեկամատյանների մշակումն իրականացվել է Logstash-ի կողմից՝ ElasticSearch-ի հինգ համակարգողների տարբեր նավահանգիստներում: Մեկ ցուցանիշը, անկախ չափից, բաղկացած էր հինգ բեկորներից։ Կազմակերպվել է ժամային և ամենօրյա պտույտ, որի արդյունքում ամեն ժամը մեկ կլաստերում հայտնվում են մոտ 100 նոր բեկորներ։ Թեև շատ տեղեկամատյաններ չկային, կլաստերը լավ էր աշխատում, և ոչ ոք ուշադրություն չդարձրեց դրա կարգավորումներին:
Արագ աճի մարտահրավերները
Ստեղծված տեղեկամատյանների ծավալը շատ արագ աճեց, քանի որ երկու գործընթացները համընկնում էին միմյանց: Մի կողմից՝ աճել է ծառայությունից օգտվողների թիվը։ Մյուս կողմից, մենք սկսեցինք ակտիվորեն անցնել միկրոսերվիսային ճարտարապետության՝ սղոցելով մեր հին մոնոլիտները C#-ում և Python-ում: Մի քանի տասնյակ նոր միկրոծառայություններ, որոնք փոխարինեցին մոնոլիտի մասերը, զգալիորեն ավելի շատ տեղեկամատյաններ ստեղծեցին ենթակառուցվածքի կլաստերի համար:
Հենց մասշտաբն էր, որ մեզ հասցրեց այն կետին, երբ կլաստերը դարձավ գործնականում անկառավարելի: Երբ տեղեկամատյանները սկսեցին հասնել վայրկյանում 20 հազար հաղորդագրություն արագությամբ, հաճախակի անօգուտ պտույտը մեծացրեց բեկորների թիվը մինչև 6 հազար, և յուրաքանչյուր հանգույցում կար ավելի քան 600 բեկոր:
Սա հանգեցրեց RAM-ի տեղաբաշխման հետ կապված խնդիրների, և երբ հանգույցը խափանվեց, բոլոր բեկորները սկսեցին միաժամանակ շարժվել՝ բազմապատկելով տրաֆիկը և բեռնելով այլ հանգույցներ, ինչը գրեթե անհնարին դարձրեց տվյալներ գրել կլաստերում: Եվ այս ընթացքում մենք մնացինք առանց գերանների։ Եվ եթե սերվերի հետ կապված խնդիր կար, մենք հիմնականում կորցրինք կլաստերի 1/10-ը: Մեծ թվով փոքր ինդեքսներ ավելացրեցին բարդություն:
Առանց տեղեկամատյանների մենք չէինք հասկանում միջադեպի պատճառները և վաղ թե ուշ կարող էինք նորից նույն փոցխի վրա դնել, և մեր թիմի գաղափարախոսության մեջ դա անընդունելի էր, քանի որ մեր աշխատանքի բոլոր մեխանիզմները նախատեսված են ճիշտ հակառակն անելու համար՝ երբեք չկրկնվել։ նույն խնդիրները: Դա անելու համար մեզ անհրաժեշտ էր տեղեկամատյանների ամբողջ ծավալը և դրանց առաքումը գրեթե իրական ժամանակում, քանի որ հերթապահ ինժեներների թիմը վերահսկում էր ահազանգերը ոչ միայն չափումների, այլև մատյաններից: Խնդրի մասշտաբները հասկանալու համար այն ժամանակ գերանների ընդհանուր ծավալը կազմում էր օրական մոտ 2 ՏԲ։
Մենք նպատակ ենք դրել ամբողջությամբ վերացնել տեղեկամատյանների կորուստը և կրճատել դրանց առաքման ժամանակը ELK կլաստերին մինչև առավելագույնը 15 րոպե ֆորս-մաժորային իրավիճակի ժամանակ (հետագայում մենք հիմնվեցինք այս ցուցանիշի վրա որպես ներքին KPI):
Պտտման նոր մեխանիզմ և տաք-տաք հանգույցներ
Մենք սկսեցինք կլաստերի փոխարկումը՝ թարմացնելով ElasticSearch տարբերակը 5.5.2-ից մինչև 6.4.3: Կրկին մեր 5 տարբերակի կլաստերը մահացավ, և մենք որոշեցինք անջատել այն և ամբողջությամբ թարմացնել այն. դեռևս տեղեկամատյաններ չկան: Այսպիսով, մենք այս անցումը կատարեցինք ընդամենը մի քանի ժամում:
Այս փուլում ամենալայնածավալ փոխակերպումը Apache Kafka-ի իրականացումն էր երեք հանգույցների վրա՝ որպես միջանկյալ բուֆեր համակարգողով: Հաղորդագրությունների միջնորդը մեզ փրկեց ElasticSearch-ի հետ կապված խնդիրների ժամանակ տեղեկամատյանները կորցնելուց: Միևնույն ժամանակ մենք ավելացրեցինք 2 հանգույց կլաստերին և անցանք տաք-տաք ճարտարապետության երեք «տաք» հանգույցներով, որոնք տեղակայված են տվյալների կենտրոնի տարբեր դարակաշարերում: Մենք վերահղել ենք տեղեկամատյանները՝ օգտագործելով դիմակ, որը չպետք է կորցնել ոչ մի դեպքում՝ nginx, ինչպես նաև հավելվածի սխալների գրանցամատյաններ: Մանր տեղեկամատյաններն ուղարկվեցին մնացած հանգույցներին՝ վրիպազերծում, նախազգուշացում և այլն, իսկ 24 ժամ անց «տաք» հանգույցներից «կարևոր» տեղեկամատյանները փոխանցվեցին:
Որպեսզի չավելացնենք փոքր ինդեքսների թիվը, ժամանակի պտույտից անցանք պտտվող մեխանիզմի։ Ֆորումներում շատ տեղեկություններ կային, որ ռոտացիան ըստ ինդեքսի չափի շատ անվստահելի է, ուստի մենք որոշեցինք օգտագործել ռոտացիան ըստ ինդեքսի փաստաթղթերի քանակի: Մենք վերլուծել ենք յուրաքանչյուր ցուցանիշ և արձանագրել փաստաթղթերի քանակը, որոնցից հետո ռոտացիան պետք է գործի: Այսպիսով, մենք հասել ենք բեկորի օպտիմալ չափին՝ ոչ ավելի, քան 50 ԳԲ:
Կլաստերների օպտիմալացում
Սակայն մենք ամբողջությամբ չենք ազատվել խնդիրներից։ Ցավոք, փոքր ինդեքսները դեռևս հայտնվեցին. դրանք չեն հասել նշված ծավալին, չեն պտտվել և ջնջվել են երեք օրից ավելի հին ինդեքսների գլոբալ մաքրման արդյունքում, քանի որ մենք հանել ենք ռոտացիան ըստ ամսաթվի: Սա հանգեցրեց տվյալների կորստի այն պատճառով, որ կլաստերի ինդեքսն ամբողջությամբ անհետացավ, և գոյություն չունեցող ինդեքսում գրելու փորձը կոտրեց կուրատորի տրամաբանությունը, որը մենք օգտագործում էինք կառավարման համար: Գրելու համար նախատեսված կեղծանունը վերածվել է ինդեքսի և խախտել է փոխակերպման տրամաբանությունը՝ առաջացնելով որոշ ինդեքսների անվերահսկելի աճ մինչև 600 ԳԲ:
Օրինակ, ռոտացիայի կազմաձևի համար.
сurator-elk-rollover.yaml
---
actions:
1:
action: rollover
options:
name: "nginx_write"
conditions:
max_docs: 100000000
2:
action: rollover
options:
name: "python_error_write"
conditions:
max_docs: 10000000
Եթե չկար rollover կեղծանուն, ապա տեղի ունեցավ սխալ.
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Մենք այս խնդրի լուծումը թողեցինք հաջորդ կրկնության համար և զբաղվեցինք մեկ այլ հարցով. անցանք Logstash-ի ձգողական տրամաբանությանը, որը մշակում է մուտքային տեղեկամատյանները (հեռացնելով ավելորդ տեղեկատվությունը և հարստացնում): Մենք այն տեղադրեցինք docker-ում, որը մենք գործարկում ենք docker-compose-ի միջոցով, և այնտեղ տեղադրեցինք նաև logstash-exporter, որն ուղարկում է չափումներ Պրոմեթևսին՝ լոգ հոսքի գործառնական մոնիտորինգի համար: Այս կերպ մենք ինքներս մեզ հնարավորություն տվեցինք սահուն կերպով փոխել logstash-ի դեպքերի քանակը, որոնք պատասխանատու են յուրաքանչյուր տեսակի լոգերի մշակման համար:
Մինչ մենք բարելավում էինք կլաստերը, cian.ru-ի տրաֆիկը ավելացավ ամսական մինչև 12,8 միլիոն եզակի օգտվող: Արդյունքում պարզվեց, որ մեր փոխակերպումները մի փոքր հետ էին մնում արտադրության փոփոխություններից, և մենք բախվեցինք այն փաստի հետ, որ «տաք» հանգույցները չեն կարողացել հաղթահարել բեռը և դանդաղեցրել են գերանների ամբողջ առաքումը: Մենք ստացանք «թեժ» տվյալներ առանց խափանումների, բայց ստիպված եղանք միջամտել մնացածի առաքմանը և ձեռքով շրջել՝ ինդեքսները հավասարաչափ բաշխելու համար։
Միևնույն ժամանակ, կլաստերում logstash-ի օրինակների մասշտաբավորումն ու կարգավորումները բարդանում էին նրանով, որ դա տեղական docker-compose էր, և բոլոր գործողությունները կատարվում էին ձեռքով (նոր ծայրեր ավելացնելու համար անհրաժեշտ էր ձեռքով անցնել բոլորը։ սերվերները և ամենուր docker-compose up -d):
Մատյանների վերաբաշխում
Այս տարվա սեպտեմբերին մենք դեռ կտրում էինք մոնոլիտը, կլաստերի ծանրաբեռնվածությունը մեծանում էր, իսկ գերանների հոսքը մոտենում էր վայրկյանում 30 հազար հաղորդագրությունների։
Մենք սկսեցինք հաջորդ կրկնությունը ապարատային թարմացմամբ: Մենք հինգ համակարգողներից անցանք երեքի, փոխարինեցինք տվյալների հանգույցները և շահեցինք փողի և պահեստային տարածքի առումով: Հանգույցների համար մենք օգտագործում ենք երկու կոնֆիգուրացիա.
- «Թեժ» հանգույցների համար՝ E3-1270 v6 / 960 Գբ SSD / 32 Գբ x 3 x 2 (3 Hot1 և 3 Hot2-ի համար):
- «Ջերմ» հանգույցների համար՝ E3-1230 v6 / 4Tb SSD / 32 Gb x 4:
Այս կրկնության ժամանակ մենք միկրոծառայությունների հասանելիության մատյաններով ինդեքսը տեղափոխեցինք, որը զբաղեցնում է նույն տարածքը, ինչ առջևի nginx տեղեկամատյանները, երեք «տաք» հանգույցներից բաղկացած երկրորդ խումբ: Այժմ մենք տվյալները պահում ենք «տաք» հանգույցների վրա 20 ժամ, այնուհետև դրանք փոխանցում ենք «տաք» հանգույցներին մնացած տեղեկամատյաններին:
Մենք լուծեցինք փոքր ինդեքսների անհետացման խնդիրը՝ վերակազմավորելով դրանց ռոտացիան։ Հիմա ամեն դեպքում ինդեքսները պտտվում են 23 ժամը մեկ, նույնիսկ եթե այնտեղ քիչ տվյալներ կան։ Սա փոքր-ինչ ավելացրեց բեկորների քանակը (դրանք մոտ 800-ն էին), բայց կլաստերի կատարողականի տեսանկյունից դա տանելի է։
Արդյունքում, կլաստերում կային վեց «տաք» և միայն չորս «տաք» հանգույցներ: Սա հանգեցնում է հարցումների մի փոքր հետաձգման երկար ժամանակային ընդմիջումներով, բայց ապագայում հանգույցների քանակի ավելացումը կլուծի այս խնդիրը:
Այս կրկնությունը շտկեց նաև կիսաավտոմատ մասշտաբի բացակայության խնդիրը: Դա անելու համար մենք տեղակայեցինք ենթակառուցվածքային Nomad կլաստերը, որը նման է այն բանին, ինչ մենք արդեն տեղակայել ենք արտադրության մեջ: Առայժմ Logstash-ի քանակը ինքնաբերաբար չի փոխվում՝ կախված ծանրաբեռնվածությունից, բայց մենք կհասնենք դրան։
Պլանները ապագայի համար
Իրականացված կոնֆիգուրացիան հիանալի կերպով չափվում է, և այժմ մենք պահում ենք 13,3 ՏԲ տվյալներ՝ բոլոր տեղեկամատյանները 4 օրվա ընթացքում, ինչը անհրաժեշտ է ահազանգերի արտակարգ վերլուծության համար: Մենք տեղեկամատյանների մի մասը վերածում ենք չափումների, որոնք ավելացնում ենք Գրաֆիտին։ Ինժեներների աշխատանքը հեշտացնելու համար մենք ունենք ենթակառուցվածքների կլաստերի չափումներ և ընդհանուր խնդիրների կիսաավտոմատ վերանորոգման սկրիպտներ: Տվյալների հանգույցների քանակի ավելացումից հետո, որը նախատեսվում է հաջորդ տարի, մենք կանցնենք տվյալների պահպանմանը 4-ից 7 օր։ Սա բավարար կլինի օպերատիվ աշխատանքի համար, քանի որ մենք միշտ փորձում ենք հնարավորինս արագ հետաքննել միջադեպերը, իսկ երկարաժամկետ հետաքննության համար կան հեռաչափական տվյալներ։
2019 թվականի հոկտեմբերին cian.ru-ի թրաֆիկը արդեն աճել էր մինչև ամսական 15,3 միլիոն եզակի օգտվող: Սա դարձավ գերանների առաքման ճարտարապետական լուծման լուրջ փորձություն:
Այժմ մենք պատրաստվում ենք թարմացնել ElasticSearch-ը 7-րդ տարբերակին: Այնուամենայնիվ, դրա համար մենք պետք է թարմացնենք ElasticSearch-ում բազմաթիվ ինդեքսների քարտեզագրումը, քանի որ դրանք տեղափոխվել են 5.5 տարբերակից և հայտարարվել են հնացած 6 տարբերակում (տարբերակում դրանք պարզապես գոյություն չունեն: 7). Սա նշանակում է, որ թարմացման գործընթացում անպայման ինչ-որ ֆորսմաժոր է լինելու, որը մեզ կթողնի առանց լոգերի, քանի դեռ հարցը լուծված է։ 7-րդ տարբերակից մենք ամենաշատը սպասում ենք Kibana-ին բարելավված ինտերֆեյսով և նոր զտիչներով:
Մենք հասանք մեր հիմնական նպատակին. մենք դադարեցրինք կորցնել տեղեկամատյանները և կրճատեցինք ենթակառուցվածքի կլաստերի աշխատանքը՝ շաբաթական 2-3 վթարից մինչև ամսական մի քանի ժամ սպասարկման աշխատանքներ: Արտադրության մեջ այս ամբողջ աշխատանքը գրեթե անտեսանելի է: Այնուամենայնիվ, այժմ մենք կարող ենք ճշգրիտ որոշել, թե ինչ է կատարվում մեր ծառայության հետ, մենք կարող ենք արագ դա անել հանգիստ ռեժիմով և չանհանգստանալ, որ տեղեկամատյանները կկորչեն: Ընդհանուր առմամբ, մենք գոհ ենք, ուրախ և պատրաստվում ենք նոր սխրանքների, որոնց մասին կխոսենք ավելի ուշ։
Source: www.habr.com