Përshëndetje të gjithëve, unë quhem Aleksandër, punoj në CIAN si inxhinier dhe jam i përfshirë në administrimin e sistemit dhe automatizimin e proceseve të infrastrukturës. Në komentet e një prej artikujve të mëparshëm, na u kërkua të tregonim se ku i marrim 4 TB shkrime në ditë dhe çfarë bëjmë me to. Po, ne kemi shumë regjistra dhe është krijuar një grup i veçantë infrastrukture për t'i përpunuar ato, gjë që na lejon të zgjidhim shpejt problemet. Në këtë artikull do të flas se si e përshtatëm atë gjatë një viti për të punuar me një rrjedhë gjithnjë në rritje të të dhënave.
Ku e nisëm?
Gjatë viteve të fundit, ngarkesa në cian.ru është rritur shumë shpejt, dhe deri në tremujorin e tretë të 2018, trafiku i burimeve arriti në 11.2 milion përdorues unikë në muaj. Në atë kohë, në momente kritike ne humbëm deri në 40% të trungjeve, prandaj nuk mund t'i përballonim shpejt incidentet dhe harxhuam shumë kohë dhe përpjekje për t'i zgjidhur ato. Gjithashtu shpesh nuk mund të gjenim shkakun e problemit dhe ai përsëritej pas njëfarë kohe. Ishte ferr dhe diçka duhej bërë për të.
Në atë kohë, ne përdorëm një grup prej 10 nyjesh të dhënash me versionin 5.5.2 të ElasticSearch me cilësimet standarde të indeksit për të ruajtur regjistrat. Ajo u prezantua më shumë se një vit më parë si një zgjidhje popullore dhe e përballueshme: atëherë fluksi i shkrimeve nuk ishte aq i madh, nuk kishte kuptim të dilnim me konfigurime jo standarde.
Përpunimi i regjistrave hyrës u sigurua nga Logstash në porte të ndryshme në pesë koordinatorë të ElasticSearch. Një indeks, pavarësisht nga madhësia, përbëhej nga pesë copëza. U organizua një rrotullim për orë dhe ditor, si rezultat, rreth 100 copëza të reja shfaqeshin në grup çdo orë. Ndërsa nuk kishte shumë regjistra, grupi u përball mirë dhe askush nuk i kushtoi vëmendje cilësimeve të tij.
Sfidat e rritjes së shpejtë
Vëllimi i regjistrave të gjeneruar u rrit shumë shpejt, pasi dy procese mbivendosen me njëri-tjetrin. Nga njëra anë, numri i përdoruesve të shërbimit u rrit. Nga ana tjetër, ne filluam të kalojmë në mënyrë aktive në një arkitekturë mikroservice, duke parë monolitet tona të vjetra në C# dhe Python. Disa dhjetëra mikroshërbime të reja që zëvendësuan pjesë të monolitit gjeneruan dukshëm më shumë regjistra për grupin e infrastrukturës.
Ishte shkallëzimi që na çoi në pikën ku grupi u bë praktikisht i pamenaxhueshëm. Kur regjistrat filluan të mbërrinin me një shpejtësi prej 20 mijë mesazhesh në sekondë, rrotullimi i shpeshtë i padobishëm e rriti numrin e copëzave në 6 mijë, dhe kishte më shumë se 600 copëza për nyje.
Kjo çoi në probleme me shpërndarjen e RAM-it dhe kur një nyje u rrëzua, të gjitha copëzat filluan të lëviznin njëkohësisht, duke shumëzuar trafikun dhe ngarkuar nyjet e tjera, gjë që e bëri pothuajse të pamundur shkrimin e të dhënave në grup. Dhe gjatë kësaj periudhe kemi mbetur pa trungje. Dhe nëse kishte një problem me serverin, ne në thelb humbëm 1/10 e grupit. Një numër i madh indeksesh të vogla shtuan kompleksitetin.
Pa regjistra, ne nuk i kuptuam arsyet e incidentit dhe herët a vonë mund të shkelnim përsëri në të njëjtin grabujë, dhe në ideologjinë e ekipit tonë kjo ishte e papranueshme, pasi të gjithë mekanizmat tanë të punës janë krijuar për të bërë të kundërtën - të mos përsëriten kurrë të njëjtat probleme. Për ta bërë këtë, na duhej vëllimi i plotë i regjistrave dhe shpërndarja e tyre pothuajse në kohë reale, pasi një ekip inxhinierësh në detyrë monitoruan alarmet jo vetëm nga metrikat, por edhe nga regjistrat. Për të kuptuar shkallën e problemit, në atë kohë vëllimi i përgjithshëm i shkrimeve ishte rreth 2 TB në ditë.
Ne vendosëm një qëllim për të eliminuar plotësisht humbjen e regjistrave dhe për të zvogëluar kohën e dorëzimit të tyre në grupin ELK në një maksimum prej 15 minutash gjatë forcës madhore (më vonë u mbështetëm në këtë shifër si një KPI i brendshëm).
Mekanizëm i ri rrotullimi dhe nyje të nxehta të ngrohta
Ne filluam konvertimin e grupit duke përditësuar versionin ElasticSearch nga 5.5.2 në 6.4.3. Edhe një herë grupi ynë i versionit 5 vdiq, dhe ne vendosëm ta çaktivizojmë dhe ta përditësojmë plotësisht - ende nuk ka regjistra. Kështu që ne e bëmë këtë tranzicion në vetëm disa orë.
Transformimi më i madh në këtë fazë ishte zbatimi i Apache Kafka në tre nyje me një koordinator si një tampon të ndërmjetëm. Ndërmjetësi i mesazheve na shpëtoi nga humbja e regjistrave gjatë problemeve me ElasticSearch. Në të njëjtën kohë, ne shtuam 2 nyje në grup dhe kaluam në një arkitekturë të ngrohtë me tre nyje "të nxehta" të vendosura në rafte të ndryshme në qendrën e të dhënave. Ne i ridrejtuam regjistrat tek ata duke përdorur një maskë që nuk duhet humbur në asnjë rrethanë - nginx, si dhe regjistrat e gabimeve të aplikacionit. Regjistrimet e vogla u dërguan në nyjet e mbetura - korrigjimi, paralajmërimi, etj., Dhe pas 24 orësh, regjistrat "të rëndësishëm" nga nyjet "të nxehta" u transferuan.
Për të mos rritur numrin e indekseve të vogla, ne kaluam nga rrotullimi i kohës në mekanizmin e rrotullimit. Kishte shumë informacione në forume se rotacioni sipas madhësisë së indeksit është shumë i pasigurt, kështu që vendosëm të përdorim rotacionin sipas numrit të dokumenteve në indeks. Ne analizuam çdo indeks dhe regjistruam numrin e dokumenteve pas të cilave duhet të funksionojë rotacioni. Kështu, ne kemi arritur madhësinë optimale të copëzave - jo më shumë se 50 GB.
Optimizimi i grupeve
Megjithatë, ne nuk i kemi hequr plotësisht problemet. Fatkeqësisht, indekset e vogla u shfaqën akoma: ato nuk arritën vëllimin e specifikuar, nuk u rrotulluan dhe u fshinë nga pastrimi global i indekseve më të vjetër se tre ditë, pasi hoqëm rotacionin sipas datës. Kjo çoi në humbjen e të dhënave për faktin se indeksi nga grupi u zhduk plotësisht dhe një përpjekje për të shkruar në një indeks joekzistent theu logjikën e kuratorit që përdorëm për menaxhim. Pseudonimi për shkrimin u shndërrua në indeks dhe theu logjikën e rrokullisjes, duke shkaktuar rritje të pakontrolluar të disa indekseve deri në 600 GB.
Për shembull, për konfigurimin e rrotullimit:
с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
Nëse nuk kishte pseudonim rollover, ndodhi një gabim:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Ne e lamë zgjidhjen e këtij problemi për përsëritjen tjetër dhe morëm një çështje tjetër: kaluam në logjikën tërheqëse të Logstash, e cila përpunon regjistrat hyrës (duke hequr informacionin e panevojshëm dhe duke pasuruar). Ne e vendosëm atë në docker, të cilin e nisim përmes docker-compose, dhe vendosëm gjithashtu logstash-exporter atje, i cili dërgon metrikë te Prometheus për monitorimin operacional të rrjedhës së log. Në këtë mënyrë i dhamë vetes mundësinë për të ndryshuar pa probleme numrin e rasteve të logstash përgjegjëse për përpunimin e secilit lloj regjistri.
Ndërsa po përmirësonim grupin, trafiku i cian.ru u rrit në 12,8 milionë përdorues unikë në muaj. Si rezultat, doli që transformimet tona ishin pak prapa ndryshimeve në prodhim, dhe ne u përballëm me faktin se nyjet "të ngrohta" nuk mund të përballonin ngarkesën dhe ngadalësuan të gjithë shpërndarjen e trungjeve. Ne morëm të dhëna "të nxehta" pa dështime, por duhej të ndërhynim në shpërndarjen e pjesës tjetër dhe të bënim një përmbysje manuale për të shpërndarë në mënyrë të barabartë indekset.
Në të njëjtën kohë, shkallëzimi dhe ndryshimi i cilësimeve të rasteve logstash në grup u ndërlikua nga fakti se ishte një kompozim lokal docker, dhe të gjitha veprimet kryheshin manualisht (për të shtuar skaje të reja, ishte e nevojshme që të kalonin manualisht të gjitha serverët dhe bëni docker-compose up -d kudo).
Rishpërndarja e regjistrit
Në shtator të këtij viti, ne ishim ende duke prerë monolitin, ngarkesa në grup po rritej dhe fluksi i shkrimeve po i afrohej 30 mijë mesazheve në sekondë.
Ne filluam përsëritjen tjetër me një përditësim të harduerit. Ne kaluam nga pesë koordinatorë në tre, zëvendësuam nyjet e të dhënave dhe fituam për sa i përket parave dhe hapësirës së ruajtjes. Për nyjet ne përdorim dy konfigurime:
- Për nyjet "hot": E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 për Hot1 dhe 3 për Hot2).
- Për nyjet "të ngrohta": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Në këtë përsëritje, ne e zhvendosëm indeksin me regjistrat e aksesit të mikroshërbimeve, të cilat zënë të njëjtën hapësirë si regjistrat e linjës së përparme nginx, në grupin e dytë të tre nyjeve "të nxehta". Tani ne ruajmë të dhënat në nyjet "të nxehta" për 20 orë, dhe më pas i transferojmë ato në nyjet "të ngrohta" në pjesën tjetër të regjistrave.
Ne e zgjidhëm problemin e zhdukjes së indekseve të vegjël duke rikonfiguruar rrotullimin e tyre. Tani indekset rrotullohen çdo 23 orë në çdo rast, edhe nëse ka pak të dhëna atje. Kjo e rriti pak numrin e copëzave (ishin rreth 800 të tilla), por nga pikëpamja e performancës së grupit është e tolerueshme.
Si rezultat, kishte gjashtë nyje "të nxehta" dhe vetëm katër "të ngrohta" në grup. Kjo shkakton një vonesë të lehtë në kërkesat në intervale të gjata kohore, por rritja e numrit të nyjeve në të ardhmen do ta zgjidhë këtë problem.
Ky përsëritje rregulloi gjithashtu problemin e mungesës së shkallëzimit gjysmë automatik. Për ta bërë këtë, ne vendosëm një grup Nomad të infrastrukturës - të ngjashme me atë që kemi vendosur tashmë në prodhim. Tani për tani, sasia e Logstash nuk ndryshon automatikisht në varësi të ngarkesës, por ne do të vijmë tek kjo.
Planet për të ardhmen
Konfigurimi i zbatuar shkallëzohet në mënyrë të përsosur, dhe tani ne ruajmë 13,3 TB të dhëna - të gjitha regjistrat për 4 ditë, gjë që është e nevojshme për analizën emergjente të alarmeve. Ne konvertojmë disa nga regjistrat në metrikë, të cilat i shtojmë në Graphite. Për të lehtësuar punën e inxhinierëve, ne kemi metrikë për grupin e infrastrukturës dhe skriptet për riparimin gjysmë automatik të problemeve të zakonshme. Pas rritjes së numrit të nyjeve të të dhënave, që është planifikuar për vitin e ardhshëm, ne do të kalojmë në ruajtjen e të dhënave nga 4 në 7 ditë. Kjo do të mjaftojë për punë operative, pasi ne gjithmonë përpiqemi të hetojmë sa më shpejt incidentet dhe për hetimet afatgjata ka të dhëna telemetrike.
Në tetor 2019, trafiku në cian.ru ishte rritur tashmë në 15,3 milion përdorues unikë në muaj. Kjo u bë një provë serioze e zgjidhjes arkitekturore për dërgimin e trungjeve.
Tani po përgatitemi të përditësojmë ElasticSearch në versionin 7. Megjithatë, për këtë do të duhet të përditësojmë hartën e shumë indekseve në ElasticSearch, pasi ato u zhvendosën nga versioni 5.5 dhe u deklaruan si të vjetëruar në versionin 6 (ato thjesht nuk ekzistojnë në versionin 7). Kjo do të thotë që gjatë procesit të përditësimit do të ketë patjetër një lloj force madhore, e cila do të na lërë pa regjistra ndërsa çështja zgjidhet. Nga versioni 7, mezi presim Kibana me një ndërfaqe të përmirësuar dhe filtra të rinj.
Ne e arritëm qëllimin tonë kryesor: ndaluam humbjen e regjistrave dhe reduktuam kohën e ndërprerjes së grupit të infrastrukturës nga 2-3 përplasje në javë në disa orë punë mirëmbajtjeje në muaj. E gjithë kjo punë në prodhim është pothuajse e padukshme. Sidoqoftë, tani mund të përcaktojmë saktësisht se çfarë po ndodh me shërbimin tonë, mund ta bëjmë shpejt në një mënyrë të qetë dhe të mos shqetësohemi se regjistrat do të humbasin. Në përgjithësi, ne jemi të kënaqur, të lumtur dhe duke u përgatitur për shfrytëzime të reja, për të cilat do të flasim më vonë.
Burimi: www.habr.com