Sveiki visi, mano vardas Aleksandras, dirbu CIAN inžinieriumi ir užsiimu sistemų administravimu bei infrastruktūros procesų automatizavimu. Komentaruose prie vieno iš ankstesnių straipsnių buvo paprašyta pasakyti, iš kur gauname 4 TB rąstų per dieną ir ką su jais darome. Taip, žurnalų turime daug, o jiems apdoroti sukurtas atskiras infrastruktūros klasteris, leidžiantis greitai išspręsti problemas. Šiame straipsnyje kalbėsiu apie tai, kaip per metus pritaikėme jį darbui su nuolat augančiu duomenų srautu.
Nuo ko pradėjome?
Per pastaruosius kelerius metus cian.ru apkrova išaugo labai greitai, o iki trečiojo 2018 m. ketvirčio išteklių srautas pasiekė 11.2 mln. unikalių vartotojų per mėnesį. Tuo metu kritiniais momentais praradome iki 40% rąstų, todėl negalėjome greitai susidoroti su incidentais ir skyrėme daug laiko ir pastangų jiems išspręsti. Taip pat dažnai nepavykdavo rasti problemos priežasties, o po kurio laiko ji pasikartotų. Tai buvo pragaras ir reikėjo ką nors padaryti.
Tuo metu žurnalams saugoti naudojome 10 duomenų mazgų grupę su ElasticSearch 5.5.2 versija su standartiniais indekso nustatymais. Jis buvo pristatytas daugiau nei prieš metus kaip populiarus ir prieinamas sprendimas: tada rąstų srautas nebuvo toks didelis, nebuvo prasmės sugalvoti nestandartinių komplektacijų.
Įeinančių žurnalų apdorojimą teikė „Logstash“ skirtinguose penkių „ElasticSearch“ koordinatorių prievaduose. Vienas indeksas, neatsižvelgiant į dydį, susideda iš penkių skeveldrų. Buvo organizuojama valandinė ir kasdieninė rotacija, todėl kas valandą klasteryje atsirasdavo apie 100 naujų šukių. Nors rąstų nebuvo labai daug, klasteris susitvarkė gerai ir niekas nekreipė dėmesio į jo nustatymus.
Spartaus augimo iššūkiai
Sukurtų rąstų apimtis augo labai greitai, nes du procesai sutapo vienas su kitu. Viena vertus, augo paslaugos vartotojų skaičius. Kita vertus, pradėjome aktyviai pereiti prie mikro paslaugų architektūros, pjaustydami senus monolitus C# ir Python. Kelios dešimtys naujų mikropaslaugų, pakeitusių monolito dalis, sugeneravo žymiai daugiau žurnalų infrastruktūros klasteriui.
Būtent mastelio keitimas privedė mus prie taško, kai klasteris tapo praktiškai nevaldomas. Kai žurnalai pradėjo gauti 20 tūkstančių pranešimų per sekundę greičiu, dažnas nenaudingas sukimas padidino šukių skaičių iki 6 tūkstančių, o viename mazge buvo daugiau nei 600 šukių.
Dėl to kilo problemų dėl RAM paskirstymo, o kai mazgas sudužo, visos šukės pradėjo judėti vienu metu, daugindamos srautą ir įkeldamos kitus mazgus, todėl beveik neįmanoma įrašyti duomenų į klasterį. Ir per šį laikotarpį likome be rąstų. Ir jei buvo problemų su serveriu, mes iš esmės praradome 1/10 klasterio. Daugybė mažų indeksų padidino sudėtingumą.
Be rąstų nesupratome incidento priežasčių ir anksčiau ar vėliau galėjome vėl užlipti ant to paties grėblio, o mūsų komandos ideologijai tai buvo nepriimtina, nes visi mūsų darbo mechanizmai sukurti taip, kad būtų daroma kaip tik priešingai – niekada nepasikartotų. tos pačios problemos. Norėdami tai padaryti, mums reikėjo viso rąstų kiekio ir jų pristatymo beveik realiu laiku, nes budinčių inžinierių komanda stebėjo įspėjimus ne tik pagal metriką, bet ir iš žurnalų. Norint suprasti problemos mastą, tuo metu bendras rąstų kiekis buvo apie 2 TB per dieną.
Išsikėlėme tikslą visiškai panaikinti rąstų praradimą ir sutrumpinti jų pristatymo į ELK klasterį laiką force majeure metu (vėliau šiuo skaičiumi rėmėmės kaip vidiniu KPI).
Naujas sukimosi mechanizmas ir karšti-šilti mazgai
Grupės konversiją pradėjome atnaujindami ElasticSearch versiją iš 5.5.2 į 6.4.3. Dar kartą mūsų 5 versijos klasteris mirė, mes nusprendėme jį išjungti ir visiškai atnaujinti – vis dar nėra žurnalų. Taigi šį perėjimą atlikome vos per porą valandų.
Didžiausia transformacija šiame etape buvo Apache Kafka įdiegimas trijuose mazguose su koordinatoriumi kaip tarpiniu buferiu. Pranešimų tarpininkas išgelbėjo mus nuo žurnalų praradimo kilus „ElasticSearch“ problemoms. Tuo pačiu metu į klasterį įtraukėme 2 mazgus ir perėjome prie karštos-šiltos architektūros su trimis „karštais“ mazgais, esančiais skirtinguose duomenų centro stovuose. Peradresavome į juos žurnalus naudodami kaukę, kuri neturėtų būti prarasta jokiomis aplinkybėmis - nginx, taip pat programų klaidų žurnalus. Nedideli žurnalai buvo išsiųsti į likusius mazgus - derinimo, įspėjimo ir kt., O po 24 valandų buvo perkelti „svarbūs“ žurnalai iš „karštų“ mazgų.
Kad nedidėtų mažų indeksų skaičius, nuo laiko sukimosi perėjome prie apvertimo mechanizmo. Forumuose buvo daug informacijos, kad rotacija pagal indekso dydį yra labai nepatikima, todėl nusprendėme naudoti rotaciją pagal indekse esančių dokumentų skaičių. Išanalizavome kiekvieną indeksą ir užfiksavome dokumentų skaičių, po kurio rotacija turėtų veikti. Taigi, pasiekėme optimalų skeveldros dydį – ne daugiau kaip 50 GB.
Klasterio optimizavimas
Tačiau mes visiškai neatsikratėme problemų. Deja, nedideli indeksai vis tiek pasirodė: jie nepasiekė nurodytos apimties, nebuvo pasukti ir buvo ištrinti visuotiniu senesnių nei trijų dienų indeksų valymu, nes pašalinome rotaciją pagal datą. Tai lėmė duomenų praradimą dėl to, kad klasterio indeksas visiškai išnyko, o bandymas įrašyti į neegzistuojantį indeksą sulaužė kuratoriaus logiką, kurią naudojome valdymui. Rašymo slapyvardis buvo paverstas indeksu ir sulaužė perjungimo logiką, todėl kai kurie indeksai nekontroliuojamai išaugo iki 600 GB.
Pavyzdžiui, sukimosi konfigūracijai:
с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
Jei nebuvo perjungimo slapyvardžio, įvyko klaida:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Šios problemos sprendimą palikome kitai iteracijai ir ėmėmės kitos problemos: perėjome prie „Logstash“ traukos logikos, kuri apdoroja gaunamus žurnalus (pašalina nereikalingą informaciją ir praturtina). Įdėjome jį į dokerį, kurį paleidžiame per docker-compose, taip pat įdėjome ten logstash-exporter, kuris siunčia metrikas į Prometheus, kad būtų galima stebėti žurnalų srautą. Taip suteikėme galimybę sklandžiai pakeisti logstash egzempliorių, atsakingų už kiekvieno tipo žurnalų apdorojimą, skaičių.
Kol tobulinome klasterį, cian.ru srautas išaugo iki 12,8 mln. unikalių vartotojų per mėnesį. Dėl to paaiškėjo, kad mūsų transformacijos šiek tiek atsiliko nuo gamybos pokyčių ir susidūrėme su tuo, kad „šilti“ mazgai neatlaikė apkrovos ir pristabdė visą rąstų pristatymą. Gavome „karštus“ duomenis be gedimų, tačiau teko įsikišti į likusių dalių pristatymą ir atlikti rankinį perėjimą, kad indeksai pasiskirstytų tolygiai.
Tuo pačiu metu logstash egzempliorių mastelio keitimą ir nustatymų keitimą klasteryje apsunkino tai, kad tai buvo vietinis dokeris, o visi veiksmai buvo atliekami rankiniu būdu (norint pridėti naujų galų, reikėjo rankiniu būdu pereiti visus serveriai ir docker-compose iki -d visur).
Rąsto perskirstymas
Šių metų rugsėjį vis dar pjaudavome monolitą, klasteriui tenkantis krūvis didėjo, rąstų srautas artėjo prie 30 tūkstančių pranešimų per sekundę.
Kitą iteraciją pradėjome atnaujindami aparatinę įrangą. Perėjome nuo penkių koordinatorių prie trijų, pakeitėme duomenų mazgus ir laimėjome pinigų bei saugyklos vietos atžvilgiu. Mazgams naudojame dvi konfigūracijas:
- „Karštiesiems“ mazgams: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 Hot1 ir 3 Hot2).
- „Šiltiems“ mazgams: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Atlikdami šią iteraciją, indeksą su mikropaslaugų prieigos žurnalais, kurie užima tiek pat vietos, kaip ir priekinės linijos nginx žurnalai, perkėlėme į antrąją trijų „karštų“ mazgų grupę. Dabar duomenis „karštuose“ mazguose saugome 20 valandų, o tada perkeliame į „šiltus“ mazgus į likusius žurnalus.
Mažų indeksų išnykimo problemą išsprendėme perkonfigūruodami jų sukimąsi. Dabar indeksai bet kuriuo atveju keičiami kas 23 valandas, net jei ten yra mažai duomenų. Tai šiek tiek padidino skeveldrų skaičių (jų buvo apie 800), tačiau klasterio veikimo požiūriu tai yra pakenčiama.
Dėl to klasteryje buvo šeši „karšti“ ir tik keturi „šilti“ mazgai. Tai sukelia nedidelį užklausų vėlavimą ilgais laiko intervalais, tačiau ateityje padidinus mazgų skaičių ši problema bus išspręsta.
Ši iteracija taip pat išsprendė pusiau automatinio mastelio keitimo trūkumo problemą. Norėdami tai padaryti, įdiegėme infrastruktūros Nomad klasterį – panašų į tą, kurį jau įdiegėme gamyboje. Kol kas Logstash kiekis automatiškai nesikeičia priklausomai nuo apkrovos, bet mes prieisime prie to.
Ateities planai
Įdiegta konfigūracija puikiai išsiplės, o dabar saugome 13,3 TB duomenų – visus žurnalus 4 dienas, kurie reikalingi avarinei įspėjimų analizei. Dalį žurnalų paverčiame metrika, kurią pridedame prie grafito. Kad palengvintume inžinierių darbą, turime infrastruktūros klasterio metrikas ir scenarijus, skirtus pusiau automatiniam dažnų problemų taisymui. Kitais metais planuojamą padidinti duomenų mazgų skaičių, nuo 4 iki 7 dienų pereisime prie duomenų saugojimo. To pakaks operatyviniam darbui, nes incidentus visada stengiamės ištirti kuo greičiau, o ilgalaikiams tyrimams yra telemetrijos duomenys.
2019 m. spalio mėn. srautas į cian.ru jau išaugo iki 15,3 milijono unikalių vartotojų per mėnesį. Tai tapo rimtu rąstų pristatymo architektūrinio sprendimo išbandymu.
Dabar ruošiamės atnaujinti ElasticSearch į 7 versiją. Tačiau tam turėsime atnaujinti daugelio ElasticSearch indeksų susiejimą, nes jie buvo perkelti iš 5.5 versijos ir buvo paskelbti kaip nebenaudojami 6 versijoje (jų tiesiog nėra versijoje 7). Tai reiškia, kad atnaujinimo proceso metu tikrai atsiras kažkokia force majeure aplinkybė, dėl kurios liksime be žurnalų, kol problema bus išspręsta. Iš 7 versijos labiausiai laukiame „Kibana“ su patobulinta sąsaja ir naujais filtrais.
Pasiekėme pagrindinį tikslą: nustojome prarasti rąstus ir sumažinome infrastruktūros klasterio prastovą nuo 2-3 avarijų per savaitę iki poros valandų priežiūros darbų per mėnesį. Visas šis darbas gamyboje yra beveik nepastebimas. Tačiau dabar galime tiksliai nustatyti, kas vyksta su mūsų paslauga, galime greitai tai padaryti tyliuoju režimu ir nesijaudinti, kad žurnalai bus prarasti. Apskritai esame patenkinti, laimingi ir ruošiamės naujiems žygdarbiams, apie kuriuos pakalbėsime vėliau.
Šaltinis: www.habr.com