Sveiki visiem, mani sauc Aleksandrs, es strÄdÄju CIAN par inženieri un esmu saistÄ«ts ar sistÄmu administrÄÅ”anu un infrastruktÅ«ras procesu automatizÄciju. KomentÄros pie viena no iepriekÅ”Äjiem rakstiem mums lÅ«dza pastÄstÄ«t, kur mÄs saÅemam 4 TB baļķu dienÄ un ko mÄs ar tiem darÄm. JÄ, mums ir daudz žurnÄlu, un to apstrÄdei ir izveidots atseviŔķs infrastruktÅ«ras klasteris, kas ļauj Ätri atrisinÄt problÄmas. Å ajÄ rakstÄ es runÄÅ”u par to, kÄ mÄs to gada laikÄ pielÄgojÄm darbam ar arvien pieaugoÅ”u datu plÅ«smu.
Kur mÄs sÄkÄm?
Dažu pÄdÄjo gadu laikÄ cian.ru slodze ir augusi ļoti strauji, un lÄ«dz 2018. gada treÅ”ajam ceturksnim resursu trafika sasniedza 11.2 miljonus unikÄlo lietotÄju mÄnesÄ«. TobrÄ«d kritiskos brīžos pazaudÄjÄm lÄ«dz pat 40% baļķu, tÄpÄc nevarÄjÄm operatÄ«vi tikt galÄ ar incidentiem un veltÄ«jÄm daudz laika un pūļu to risinÄÅ”anai. MÄs arÄ« bieži nevarÄjÄm atrast problÄmas cÄloni, un pÄc kÄda laika tÄ atkÄrtojÄs. TÄ bija elle, un kaut kas bija jÄdara lietas labÄ.
Tolaik žurnÄlu glabÄÅ”anai izmantojÄm 10 datu mezglu kopu ar ElasticSearch versiju 5.5.2 ar standarta indeksa iestatÄ«jumiem. Tas tika ieviests pirms vairÄk nekÄ gada kÄ populÄrs un pieÅemams risinÄjums: tad baļķu plÅ«sma nebija tik liela, nebija jÄgas izdomÄt nestandarta konfigurÄcijas.
IenÄkoÅ”o žurnÄlu apstrÄdi nodroÅ”inÄja Logstash dažÄdos piecu ElasticSearch koordinatoru portos. Viens indekss neatkarÄ«gi no izmÄra sastÄvÄja no piecÄm lauskas. Tika organizÄta stundu un dienas rotÄcija, kÄ rezultÄtÄ katru stundu klasterÄ« parÄdÄ«jÄs apmÄram 100 jaunas lauskas. Lai gan žurnÄlu nebija ļoti daudz, klasteris tika galÄ labi, un neviens nepievÄrsa uzmanÄ«bu tÄ iestatÄ«jumiem.
Straujas izaugsmes izaicinÄjumi
Izveidoto baļķu apjoms pieauga ļoti Ätri, jo divi procesi pÄrklÄjÄs viens ar otru. No vienas puses, pieauga pakalpojuma lietotÄju skaits. No otras puses, mÄs sÄkÄm aktÄ«vi pÄriet uz mikropakalpojumu arhitektÅ«ru, zÄÄ£Äjot savus vecos monolÄ«tus C# un Python. VairÄki desmiti jaunu mikropakalpojumu, kas nomainÄ«ja monolÄ«ta daļas, radÄ«ja ievÄrojami vairÄk žurnÄlu infrastruktÅ«ras klasterim.
TÄ bija mÄrogoÅ”ana, kas noveda mÅ«s lÄ«dz vietai, kur klasteris kļuva praktiski nevadÄms. Kad žurnÄli sÄka pienÄkt ar Ätrumu 20 tÅ«kstoÅ”i ziÅojumu sekundÄ, bieža bezjÄdzÄ«ga rotÄcija palielinÄja lauskas skaitu lÄ«dz 6 tÅ«kstoÅ”iem, un vienÄ mezglÄ bija vairÄk nekÄ 600 lauskas.
Tas radÄ«ja problÄmas ar RAM pieŔķirÅ”anu, un, kad mezgls avarÄja, visas Ŕķembas sÄka kustÄties vienlaicÄ«gi, palielinot trafiku un ielÄdÄjot citus mezglus, kas padarÄ«ja gandrÄ«z neiespÄjamu datu ierakstÄ«Å”anu klasterÄ«. Un Å”ajÄ periodÄ mÄs palikÄm bez baļķiem. Un, ja radÄs problÄma ar serveri, mÄs bÅ«tÄ«bÄ zaudÄjÄm 1/10 no klastera. Liels skaits mazu indeksu palielinÄja sarežģītÄ«bu.
Bez baļķiem nesapratÄm incidenta iemeslus un agrÄk vai vÄlÄk varÄjÄm atkal uzkÄpt uz tÄ paÅ”a grÄbekļa, un mÅ«su komandas ideoloÄ£ijÄ tas bija nepieÅemami, jo visi mÅ«su darba mehÄnismi ir izstrÄdÄti, lai darÄ«tu tieÅ”i pretÄjo - nekad neatkÄrtotos. tÄs paÅ”as problÄmas. Lai to izdarÄ«tu, mums bija nepiecieÅ”ams pilns žurnÄlu apjoms un to piegÄde gandrÄ«z reÄllaikÄ, jo dežurÄjoÅ”u inženieru komanda uzraudzÄ«ja brÄ«dinÄjumus ne tikai no metrikas, bet arÄ« no žurnÄliem. Lai saprastu problÄmas mÄrogu, tobrÄ«d kopÄjais žurnÄlu apjoms bija aptuveni 2 TB dienÄ.
MÄs izvirzÄ«jÄm mÄrÄ·i nepÄrvaramas varas apstÄkļos pilnÄ«bÄ novÄrst baļķu zudumus un samazinÄt to piegÄdes laiku ELK klasterim lÄ«dz maksimÄli 15 minÅ«tÄm nepÄrvaramas varas apstÄkļos (vÄlÄk mÄs paļÄvÄmies uz Å”o skaitli kÄ iekÅ”Äjo KPI).
Jauns rotÄcijas mehÄnisms un karsti silti mezgli
MÄs sÄkÄm klastera konvertÄÅ”anu, atjauninot ElasticSearch versiju no 5.5.2 uz 6.4.3. Atkal mÅ«su 5. versijas klasteris nomira, un mÄs nolÄmÄm to izslÄgt un pilnÄ«bÄ atjauninÄt ā joprojÄm nav neviena žurnÄla. TÄpÄc mÄs veicÄm Å”o pÄreju tikai pÄris stundu laikÄ.
VislielÄkÄ mÄroga transformÄcija Å”ajÄ posmÄ bija Apache Kafka ievieÅ”ana trÄ«s mezglos ar koordinatoru kÄ starpposma buferi. ZiÅojumu brokeris pasargÄja mÅ«s no žurnÄlu zaudÄÅ”anas ElasticSearch problÄmu laikÄ. TajÄ paÅ”Ä laikÄ mÄs klasterim pievienojÄm 2 mezglus un pÄrgÄjÄm uz karsto un silto arhitektÅ«ru ar trim ākarstajiemā mezgliem, kas atrodas dažÄdos datu centra plauktos. MÄs novirzÄ«jÄm uz viÅiem žurnÄlus, izmantojot masku, kuru nekÄdÄ gadÄ«jumÄ nevajadzÄtu pazaudÄt - nginx, kÄ arÄ« lietojumprogrammu kļūdu žurnÄlus. Uz atlikuÅ”ajiem mezgliem tika nosÅ«tÄ«ti nelieli žurnÄli - atkļūdoÅ”ana, brÄ«dinÄjums utt., Un pÄc 24 stundÄm tika pÄrsÅ«tÄ«ti āsvarÄ«giā žurnÄli no ākarstajiemā mezgliem.
Lai nepalielinÄtu mazo indeksu skaitu, no laika rotÄcijas pÄrgÄjÄm uz apgÄÅ”anÄs mehÄnismu. Forumos bija daudz informÄcijas, ka rotÄcija pÄc indeksa lieluma ir ļoti neuzticama, tÄpÄc nolÄmÄm izmantot rotÄciju pÄc indeksÄ esoÅ”o dokumentu skaita. MÄs analizÄjÄm katru indeksu un reÄ£istrÄjÄm dokumentu skaitu, pÄc kura jÄdarbojas rotÄcijai. TÄdÄjÄdi esam sasnieguÅ”i optimÄlo shard izmÄru - ne vairÄk kÄ 50 GB.
Klasteru optimizÄcija
TomÄr mÄs neesam pilnÄ«bÄ atbrÄ«vojuÅ”ies no problÄmÄm. DiemžÄl joprojÄm parÄdÄ«jÄs nelieli indeksi: tie nesasniedza norÄdÄ«to apjomu, netika pagriezti un tika izdzÄsti, globÄli tÄ«rot indeksus, kas vecÄki par trim dienÄm, jo āāmÄs noÅÄmÄm rotÄciju pÄc datuma. Tas izraisÄ«ja datu zudumu, jo indekss no klastera pilnÄ«bÄ pazuda, un mÄÄ£inÄjums rakstÄ«t neesoÅ”Ä indeksÄ pÄrkÄpa kuratora loÄ£iku, kuru izmantojÄm pÄrvaldÄ«bai. RakstÄ«Å”anas aizstÄjvÄrds tika pÄrveidots par indeksu un salauza apgÄÅ”anÄs loÄ£iku, izraisot dažu indeksu nekontrolÄtu pieaugumu lÄ«dz 600 GB.
PiemÄram, rotÄcijas konfigurÄcijai:
Ń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
Ja nebija apgÄÅ”anÄs aizstÄjvÄrda, radÄs kļūda:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
MÄs atstÄjÄm Ŕīs problÄmas risinÄjumu nÄkamajai iterÄcijai un pievÄrsÄmies citai problÄmai: pÄrgÄjÄm uz Logstash vilkÅ”anas loÄ£iku, kas apstrÄdÄ ienÄkoÅ”os žurnÄlus (noÅemot nevajadzÄ«go informÄciju un bagÄtinot). MÄs ievietojÄm to dockerÄ, kuru palaižam, izmantojot docker-compose, un tur ievietojÄm arÄ« logstash-exporter, kas nosÅ«ta metriku uz Prometheus žurnÄlu straumes operatÄ«vai uzraudzÄ«bai. TÄdÄ veidÄ mÄs devÄm sev iespÄju vienmÄrÄ«gi mainÄ«t logstash gadÄ«jumu skaitu, kas ir atbildÄ«gi par katra veida žurnÄlu apstrÄdi.
KamÄr mÄs uzlabojÄm kopu, cian.ru trafika palielinÄjÄs lÄ«dz 12,8 miljoniem unikÄlo lietotÄju mÄnesÄ«. RezultÄtÄ izrÄdÄ«jÄs, ka mÅ«su pÄrvÄrtÄ«bas nedaudz atpalika no izmaiÅÄm ražoÅ”anÄ, un mÄs saskÄrÄmies ar faktu, ka āsiltieā mezgli netika galÄ ar slodzi un palÄninÄja visu baļķu piegÄdi. āKarstosā datus saÅÄmÄm bez kļūmÄm, bet pÄrÄjo piegÄdÄ bija jÄiejaucas un jÄveic manuÄla apgÄÅ”anÄs, lai vienmÄrÄ«gi sadalÄ«tu indeksus.
TajÄ paÅ”Ä laikÄ logstash gadÄ«jumu mÄrogoÅ”anu un iestatÄ«jumu mainÄ«Å”anu klasterÄ« sarežģīja fakts, ka tas bija lokÄls docker-compose, un visas darbÄ«bas tika veiktas manuÄli (lai pievienotu jaunus galus, bija manuÄli jÄiziet visas serveri un docker-compose up -d visur).
Baļķu pÄrdale
Å Ä« gada septembrÄ« vÄl griezÄm monolÄ«tu, klastera slodze pieauga, un žurnÄlu plÅ«sma tuvojÄs 30 tÅ«kstoÅ”iem ziÅojumu sekundÄ.
MÄs sÄkÄm nÄkamo iterÄciju ar aparatÅ«ras atjauninÄjumu. MÄs pÄrgÄjÄm no pieciem koordinatoriem uz trim, nomainÄ«jÄm datu mezglus un uzvarÄjÄm naudas un uzglabÄÅ”anas vietas ziÅÄ. Mezglum mÄs izmantojam divas konfigurÄcijas:
- āKarstajiemā mezgliem: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 ā Hot1 un 3 ā Hot2).
- āSiltiemā mezgliem: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Å ajÄ iterÄcijÄ mÄs pÄrvietojÄm indeksu ar mikropakalpojumu piekļuves žurnÄliem, kas aizÅem tÄdu paÅ”u vietu kÄ priekÅ”ÄjÄs lÄ«nijas nginx žurnÄli, uz otro trÄ«s ākarstoā mezglu grupu. Tagad mÄs glabÄjam datus par ākarstajiemā mezgliem 20 stundas un pÄc tam pÄrsÅ«tÄm tos uz āsiltajiemā mezgliem uz pÄrÄjiem žurnÄliem.
MÄs atrisinÄjÄm mazo indeksu pazuÅ”anas problÄmu, pÄrkonfigurÄjot to rotÄciju. Tagad indeksi jebkurÄ gadÄ«jumÄ tiek pagriezti ik pÄc 23 stundÄm, pat ja tur ir maz datu. Tas nedaudz palielinÄja shardu skaitu (to bija ap 800), taÄu no klasteru veiktspÄjas viedokļa tas ir pieļaujams.
RezultÄtÄ klasterÄ« bija seÅ”i ākarstiā un tikai Äetri āsiltiā mezgli. Tas rada nelielu pieprasÄ«jumu aizkavÄÅ”anos ilgos laika intervÄlos, taÄu, palielinot mezglu skaitu nÄkotnÄ, Ŕī problÄma tiks atrisinÄta.
Å Ä« iterÄcija arÄ« novÄrsa pusautomÄtiskÄs mÄrogoÅ”anas trÅ«kuma problÄmu. Lai to izdarÄ«tu, mÄs izvietojÄm infrastruktÅ«ras Nomad kopu ā lÄ«dzÄ«gu tam, ko jau esam izvietojuÅ”i ražoÅ”anÄ. PagaidÄm Logstash daudzums automÄtiski nemainÄs atkarÄ«bÄ no slodzes, bet pie tÄ tiksim.
PlÄni nÄkotnei
IeviestÄ konfigurÄcija lieliski mÄrogojas, un tagad mÄs glabÄjam 13,3 TB datu - visus žurnÄlus 4 dienas, kas nepiecieÅ”ami brÄ«dinÄjumu ÄrkÄrtas analÄ«zei. MÄs pÄrvÄrÅ”am dažus žurnÄlus par metriku, ko pievienojam Graphite. Lai atvieglotu inženieru darbu, mums ir infrastruktÅ«ras klastera metrika un skripti bieži sastopamu problÄmu pusautomÄtiskai laboÅ”anai. PÄc datu mezglu skaita palielinÄÅ”anas, kas plÄnots nÄkamgad, pÄriesim uz datu glabÄÅ”anu no 4 uz 7 dienÄm. OperatÄ«vajam darbam ar to pietiks, jo vienmÄr cenÅ”amies pÄc iespÄjas ÄtrÄk izmeklÄt incidentus, bet ilgstoÅ”ai izmeklÄÅ”anai ir telemetrijas dati.
2019. gada oktobrÄ« cian.ru datplÅ«sma jau bija pieaugusi lÄ«dz 15,3 miljoniem unikÄlo lietotÄju mÄnesÄ«. Tas kļuva par nopietnu baļķu piegÄdes arhitektoniskÄ risinÄjuma pÄrbaudi.
Tagad mÄs gatavojamies atjauninÄt ElasticSearch uz versiju 7. TomÄr, lai to izdarÄ«tu, mums bÅ«s jÄatjaunina daudzu indeksu kartÄÅ”ana programmÄ ElasticSearch, jo tie tika pÄrvietoti no versijas 5.5 un tika deklarÄti kÄ novecojuÅ”i 6. versijÄ (versijÄ tie vienkÄrÅ”i nepastÄv 7). Tas nozÄ«mÄ, ka atjauninÄÅ”anas procesa laikÄ noteikti bÅ«s kÄda veida force majeure, kas atstÄs mÅ«s bez žurnÄliem, kamÄr problÄma tiks atrisinÄta. No 7. versijas mÄs visvairÄk gaidÄm Kibana ar uzlabotu saskarni un jauniem filtriem.
MÄs sasniedzÄm savu galveno mÄrÄ·i: pÄrtraucÄm baļķu zudumu un samazinÄjÄm infrastruktÅ«ras klastera dÄ«kstÄves no 2-3 avÄrijÄm nedÄÄ¼Ä lÄ«dz pÄris stundÄm apkopes darbiem mÄnesÄ«. Viss Å”is darbs ražoÅ”anÄ ir gandrÄ«z neredzams. TaÄu tagad varam precÄ«zi noteikt, kas notiek ar mÅ«su servisu, varam Ätri to izdarÄ«t klusÄ režīmÄ un neuztraukties, ka žurnÄli pazudÄ«s. KopumÄ esam apmierinÄti, priecÄ«gi un gatavojamies jauniem varoÅdarbiem, par kuriem runÄsim vÄlÄk.
Avots: www.habr.com