Kaixo guztioi, nire izena Alexander da, CIANen ingeniari gisa lan egiten dut eta sistemaren administrazioan eta azpiegituren prozesuen automatizazioan parte hartzen dut. Aurreko artikuluetako baten iruzkinetan, egunean 4 TB erregistro non lortzen ditugun eta haiekin zer egiten dugun esatea eskatu ziguten. Bai, erregistro asko ditugu, eta horiek prozesatzeko azpiegitura-kluster bereizi bat sortu da, eta horrek arazoak azkar konpontzeko aukera ematen digu. Artikulu honetan, urte batean zehar nola moldatu ginen gero eta hazten ari den datu-fluxuarekin lan egiteko hitz egingo dut.
Nondik hasi ginen?
Azken urteotan, cian.ru-ko karga oso azkar hazi da, eta 2018ko hirugarren hiruhilekoan, baliabideen trafikoa hilero 11.2 milioi erabiltzaile bakarrera iritsi zen. Garai hartan, momentu kritikoetan erregistroen % 40 arte galtzen genuen, horregatik ezin izan genien gertakariei azkar aurre egin eta denbora eta esfortzu handia eman genuen horiek konpontzen. Askotan ere ezin izan dugu aurkitu arazoaren kausa, eta denbora pixka bat igaro ondoren errepikatuko litzateke. Infernua zen eta zerbait egin beharra zegoen.
Garai hartan, ElasticSearch 10 bertsioarekin 5.5.2 datu-nodoko multzoa erabili genuen indize-ezarpen estandarrekin erregistroak gordetzeko. Duela urtebete baino gehiago aurkeztu zen irtenbide ezagun eta merkean: orduan erregistroen fluxua ez zen hain handia, ez zen balio estandarrik gabeko konfigurazioekin etortzea.
Sarrerako erregistroak prozesatzea Logstash-ek ElasticSearch-eko bost koordinatzaile portu ezberdinetan eman zuen. Indize bat, tamaina edozein dela ere, bost zatik osatzen zuten. Orduko eta eguneroko txanda bat antolatu zen, ondorioz, orduro klusterrean 100 zati berri inguru agertzen ziren. Erregistro asko ez zeuden arren, klusterrak ondo egin zuen aurre eta inork ez zien bere ezarpenei erreparatu.
Hazkunde azkarraren erronkak
Sortutako erregistroen bolumena oso azkar hazi zen, bi prozesu gainjarri baitziren. Alde batetik, zerbitzuaren erabiltzaile kopurua hazi egin zen. Bestalde, aktiboki mikrozerbitzuen arkitektura batera aldatzen hasi ginen, gure monolito zaharrak C# eta Python-en zerratuz. Monolitoaren zatiak ordezkatu zituzten dozena mikrozerbitzu berrik askoz ere erregistro gehiago sortu zituzten azpiegitura-klustererako.
Eskalatzeak eraman gintuen klusterra ia kudeaezina bihurtu zen puntura. Erregistroak 20 mila mezu segundoko abiaduran iristen hasi zirenean, maiz alferrikako errotazioak zati kopurua 6 milara igo zuen, eta 600 zati baino gehiago zeuden nodo bakoitzeko.
Horrek RAMaren esleipenarekin arazoak sortu zituen, eta nodo bat huts egiten zuenean, zati guztiak aldi berean mugitzen hasi ziren, trafikoa biderkatuz eta beste nodo batzuk kargatuz, eta horrek ia ezinezkoa zen klusterean datuak idaztea. Eta tarte horretan enborrik gabe geratu ginen. Eta zerbitzariarekin arazoren bat bazen, funtsean klusterren 1/10 galdu genuen. Indize txiki kopuru handi batek konplexutasuna gehitu zuen.
Erregistrorik gabe, ez genituen istiluaren arrazoiak ulertzen eta lehenago edo beranduago berriro zapal genezake arraste bera, eta gure taldearen ideologian hori onartezina zen, gure lan-mekanismo guztiak guztiz kontrakoa egiteko diseinatuta daude - inoiz ez errepikatu. arazo berdinak. Horretarako, erregistroen bolumen osoa eta haien entrega ia denbora errealean behar genituen, laneko ingeniari talde batek neurgailuetatik ez ezik, erregistroetatik ere alertak kontrolatzen baitzituen. Arazoaren tamaina ulertzeko, garai hartan erregistroen bolumen osoa eguneko 2 TB ingurukoa zen.
Erregistroen galera guztiz kentzeko eta ELK klusterera bidaltzeko denbora gehienez 15 minutura murrizteko helburua ezarri genuen ezinbesteko kasuetan (geroago zifra horretan oinarritu ginen barne KPI gisa).
Errotazio mekanismo berria eta nodo bero-bero
Kluster bihurtzeari ekin genion ElasticSearch bertsioa 5.5.2tik 6.4.3ra eguneratuz. Berriro ere gure 5. bertsioa kluster hil egin zen, eta itzaltzea eta guztiz eguneratzea erabaki genuen - oraindik ez dago erregistrorik. Beraz, trantsizio hau pare bat ordutan egin genuen.
Etapa honetako eskala handieneko eraldaketa Apache Kafka hiru nodotan ezartzea izan zen, koordinatzaile bat tarteko buffer gisa. Mezu-artekariak ElasticSearch-ekin izandako arazoetan erregistroak galtzetik salbatu gaitu. Aldi berean, klusterrean 2 nodo gehitu ditugu eta datu-zentroko bastidor desberdinetan kokatutako hiru nodo "bero" dituen arkitektura bero-bero batera aldatu dugu. Erregistroak inolaz ere galdu behar ez den maskara erabiliz birbideratu ditugu - nginx, baita aplikazioetako erroreen erregistroak ere. Erregistro txikiak gainerako nodoetara bidali ziren - arazketa, abisua, etab., eta 24 ordu igaro ondoren, nodo "beroetatik" erregistro "garrantzitsuak" transferitu ziren.
Indize txikien kopurua ez handitzeko, denbora-errotatzetik rollover mekanismora pasatu ginen. Foroetan informazio asko zegoen indizearen tamainaren araberako biraketa oso fidagarria ez dela, beraz, indizeko dokumentu kopuruaren araberako biraketa erabiltzea erabaki genuen. Indize bakoitza aztertu dugu eta errotazioak funtzionatu behar duen dokumentu kopurua erregistratu dugu. Horrela, zatien tamaina optimoa lortu dugu - 50 GB baino gehiago.
Kluster optimizazioa
Hala ere, ez ditugu arazoetatik guztiz kendu. Zoritxarrez, oraindik ere indize txikiak agertzen ziren: ez ziren zehaztutako bolumenera iritsi, ez ziren biratu eta hiru egun baino zaharragoak diren indizeen garbiketa globalaren bidez ezabatu ziren, dataren araberako errotazioa kendu genuenetik. Horrek datuak galtzea ekarri zuen, klusterreko indizea guztiz desagertu zelako, eta existitzen ez zen indize batean idazteko saiakerak kudeaketarako erabiltzen genuen komisarioaren logika hautsi zuen. Idazterako alias indize bihurtu zen eta rollover logika hautsi zuen, indize batzuen kontrolik gabeko hazkundea eraginez 600 GB-ra arte.
Adibidez, biraketa konfiguraziorako:
Ρ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
Ez bazegoen aldatzeko aliasik, errore bat gertatu 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".
Arazo honen irtenbidea hurrengo iteraziorako utzi genuen eta beste kontu bat hartu genuen: Logstash-en tira logikara aldatu ginen, sarrerako erregistroak prozesatzen dituena (alferrikako informazioa kenduz eta aberastuz). Docker-en jarri genuen, docker-compose bidez abiarazten duguna, eta logstash-exporter ere jarri genuen bertan, Prometheus-i neurketak bidaltzen dizkiona log-korrontearen jarraipena egiteko. Horrela, erregistro mota bakoitza prozesatzeaz arduratzen diren logstash instantzia kopurua erraz aldatzeko aukera eman genion.
Klusterra hobetzen ari ginen bitartean, cian.ru-ren trafikoa hilero 12,8 milioi erabiltzaile bakarrera igo zen. Ondorioz, gure eraldaketak ekoizpen-aldaketen apur bat atzean zeudela ikusi genuen, eta nodo "beroak" kargari aurre egin ezinik eta erregistroen entrega osoa moteldu egin genuen. Datu βberoakβ akatsik gabe jaso genituen, baina gainerakoen entregan esku hartu behar izan genuen eta eskuzko iraulketa egin behar izan genuen indizeak uniformeki banatzeko.
Aldi berean, klusterreko logstash instantzien ezarpenak eskalatzea eta aldatzea zaildu zen docker-konposaketa lokala zelako, eta ekintza guztiak eskuz egiten zirelako (mutur berriak gehitzeko, beharrezkoa zen eskuz pasatzea guztiak. zerbitzariak eta docker-compose up -d nonahi).
Erregistroen birbanaketa
Aurtengo irailean, monolitoa mozten ari ginen oraindik, klusterraren karga handitzen ari zen eta erregistroen fluxua segundoko 30 mila mezura hurbiltzen ari zen.
Hurrengo iterazioa hardware eguneraketa batekin hasi genuen. Bost koordinatzailetik hiru izatera pasatu ginen, datu-nodoak ordezkatu eta diruari eta biltegiratze-espazioaren aldetik irabazi genuen. Nodoetarako bi konfigurazio erabiltzen ditugu:
- Nodo "beroetarako": E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 Hot1 eta 3 Hot2).
- Nodo "beroetarako": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Iterazio honetan, lehen lerroko nginx erregistroen espazio bera hartzen duten mikrozerbitzuen sarbide-erregistroekin indizea mugitu dugu hiru nodo "beroak" osatutako bigarren taldera. Orain 20 orduz nodo "beroetan" gordetzen ditugu datuak, eta gero nodo "beroetara" transferitzen ditugu gainerako erregistroetara.
Indize txikiak desagertzearen arazoa haien biraketa birkonfiguratuz konpondu genuen. Orain indizeak 23 orduz behin biratzen dira edonola ere, nahiz eta hor datu gutxi egon. Horrek apur bat handitu zuen zati kopurua (800 inguru zeuden), baina clusterren errendimenduaren ikuspuntutik, onargarria da.
Ondorioz, sei nodo "bero" eta lau "bero" bakarrik zeuden klusterrean. Horrek denbora tarte luzeetan eskaerak atzerapen txiki bat eragiten du, baina etorkizunean nodo kopurua handitzeak arazo hau konponduko du.
Iterazio honek eskalatze erdi-automatikorik ezaren arazoa ere konpondu zuen. Horretarako, azpiegitura Nomad kluster bat zabaldu dugu, ekoizpenean dagoeneko zabaldu dugunaren antzekoa. Oraingoz, Logstash-en zenbatekoa ez da automatikoki aldatzen kargaren arabera, baina horretara iritsiko gara.
Etorkizunerako planak
Inplementatutako konfigurazioa ezin hobeto eskalatzen da, eta orain 13,3 TB datu gordetzen ditugu; erregistro guztiak 4 egunez, beharrezkoa da alertak larrialdietan aztertzeko. Erregistro batzuk metrika bihurtzen ditugu, Graphite-ra gehitzen ditugunak. Ingeniarien lana errazteko, azpiegitura-klustererako neurketak eta ohiko arazoen konponketa erdi-automatikorako script-ak ditugu. Datorren urterako aurreikusita dagoen datu-nodo kopurua handitu ondoren, 4 egunetik 7 egunera pasako gara datuak biltegiratzera. Hori nahikoa izango da lan operatiborako, beti saiatzen garelako gertakariak ahalik eta azkarren ikertzen, eta epe luzerako ikerketetarako telemetria datuak daude.
2019ko urrian, cian.ru-rako trafikoa hilean 15,3 milioi erabiltzaile bakar izatera iritsi zen. Hau erregistroak entregatzeko irtenbide arkitektonikoaren proba serio bihurtu zen.
Orain ElasticSearch 7. bertsiora eguneratzeko prestatzen ari gara. Hala ere, horretarako ElasticSearch-en indize askoren mapak eguneratu beharko ditugu, 5.5 bertsiotik mugitu baitziren eta 6. bertsioan zaharkituta daudelako (bertsioan ez dira besterik gabe existitzen). 7). Horrek esan nahi du eguneratze prozesuan zehar ezinbesteko kasuren bat egongo dela, eta horrek erregistrorik gabe utziko gaitu arazoa konpondu bitartean. 7. bertsiotik, Kibanara espero dugu interfaze hobetu batekin eta iragazki berriekin.
Gure helburu nagusia lortu genuen: erregistroak galtzeari utzi eta azpiegituren klusterraren geldialdi-denbora gutxitu genuen astean 2-3 hutsegitetik hilean pare bat ordu mantentze lanetara. Ekoizpeneko lan hori guztia ia ikusezina da. Hala ere, orain zehatz-mehatz zehaztu dezakegu zer gertatzen den gure zerbitzuarekin, azkar egin dezakegu modu isilean eta ez kezkatu erregistroak galduko direlako. Orokorrean, pozik, pozik eta balentria berrietarako prestatzen ari gara, eta horietaz gero hitz egingo dugu.
Iturria: www.habr.com