Tere kõigile, minu nimi on Alexander, töötan CIANis insenerina ja tegelen süsteemihalduse ja infrastruktuuri protsesside automatiseerimisega. Ühe eelmise artikli kommentaarides paluti meil öelda, kust me saame 4 TB logisid päevas ja mida me nendega teeme. Jah, meil on palju logisid ja nende töötlemiseks on loodud eraldi taristuklaster, mis võimaldab probleeme kiiresti lahendada. Selles artiklis räägin sellest, kuidas me seda aasta jooksul kohandasime, et töötada koos üha kasvava andmevooga.
Kust me alustasime?
Viimase paari aasta jooksul on cian.ru koormus väga kiiresti kasvanud ning 2018. aasta kolmandaks kvartaliks jõudis ressursiliiklus 11.2 miljoni unikaalse kasutajani kuus. Sel ajal kaotasime kriitilistel hetkedel kuni 40% logidest, mistõttu ei saanud me intsidentidega kiiresti hakkama ning kulutasime nende lahendamisele palju aega ja vaeva. Samuti ei leidnud me sageli probleemi põhjust ja see kordus mõne aja pärast. See oli põrgu ja sellega tuli midagi ette võtta.
Sel ajal kasutasime logide salvestamiseks 10 andmesõlmest koosnevat klastrit ElasticSearchi versiooniga 5.5.2 ja standardsete indeksiseadetega. Seda tutvustati enam kui aasta tagasi populaarse ja taskukohase lahendusena: siis polnud palgivoog nii suur, polnud mõtet välja mõelda mittestandardseid konfiguratsioone.
Logstash töötles sissetulevaid logisid viie ElasticSearchi koordinaatori erinevates portides. Üks indeks, olenemata suurusest, koosnes viiest killust. Korraldati tunni- ja päevarotatsioon, mille tulemusena ilmus klastrisse igas tunnis umbes 100 uut kildu. Kuigi logisid väga palju ei olnud, tuli klaster hästi toime ja keegi ei pööranud selle seadetele tähelepanu.
Kiire kasvu väljakutsed
Loodud palkide maht kasvas väga kiiresti, kuna kaks protsessi kattusid üksteisega. Ühest küljest kasvas teenuse kasutajate arv. Teisest küljest hakkasime aktiivselt üle minema mikroteenuste arhitektuurile, saagides oma vanu monoliite C# ja Pythonis. Mitukümmend uut mikroteenust, mis asendasid monoliidi osi, genereerisid infrastruktuuriklastri jaoks oluliselt rohkem logisid.
See oli skaleerimine, mis viis meid punktini, kus klaster muutus praktiliselt juhitamatuks. Kui logid hakkasid saabuma kiirusega 20 tuhat sõnumit sekundis, suurendas sagedane kasutu pööramine kildude arvu 6 tuhandeni ja sõlme kohta oli üle 600 killu.
See tõi kaasa probleeme RAM-i eraldamisega ja kui sõlm jooksis kokku, hakkasid kõik killud korraga liikuma, mitmekordistades liiklust ja laadides teisi sõlmpunkte, mistõttu oli andmete klastrisse kirjutamine peaaegu võimatu. Ja sel perioodil jäime palkideta. Ja kui serveriga oli probleeme, kaotasime põhimõtteliselt 1/10 klastrist. Suur hulk väikeseid indekseid lisasid keerukust.
Ilma logideta ei saanud me intsidendi põhjustest aru ja võisime varem või hiljem uuesti sama reha otsa astuda ning meie meeskonna ideoloogias oli see vastuvõetamatu, kuna kõik meie töömehhanismid on loodud tegema just vastupidist – kunagi ei kordu. samad probleemid. Selleks vajasime kogu palkide mahtu ja nende kohaletoimetamist peaaegu reaalajas, kuna valves olevate inseneride meeskond jälgis hoiatusi mitte ainult mõõdikutest, vaid ka logidest. Et mõista probleemi ulatust, oli tol ajal palkide kogumaht umbes 2 TB päevas.
Võtsime eesmärgiks täielikult välistada palkide kadu ja vähendada vääramatu jõu korral nende ELK-klastrisse toimetamise aega maksimaalselt 15 minutini (hiljem toetusime sellele näitajale kui sisemisele KPI-le).
Uus pöörlemismehhanism ja kuum-soe sõlmed
Alustasime klastri teisendamist, värskendades ElasticSearchi versiooni versioonilt 5.5.2 versioonile 6.4.3. Taas suri meie versiooni 5 klaster ja otsustasime selle välja lülitada ja täielikult värskendada – logisid pole ikka veel. Nii et me tegime selle ülemineku vaid paari tunniga.
Selles etapis oli kõige ulatuslikum teisendus Apache Kafka rakendamine kolmes sõlmes, mille vahepuhvrina oli koordinaator. Sõnumivahendaja päästis meid logide kaotamisest ElasticSearchi probleemide ajal. Samal ajal lisasime klastrisse 2 sõlme ja läksime üle kuuma-sooja arhitektuurile, kus kolm "kuuma" sõlme asuvad andmekeskuse erinevates riiulites. Suunasime logid neile ümber, kasutades maski, mis ei tohiks mingil juhul kaduda - nginx, samuti rakenduste vealogid. Ülejäänud sõlmedesse saadeti väikesed logid - silumine, hoiatus jne ning 24 tunni pärast viidi üle "kuumade" sõlmede "olulised" logid.
Selleks, et mitte suurendada väikeste indeksite arvu, läksime ajalise pöörlemise asemel ümbermineku mehhanismile. Foorumites oli palju teavet, et indeksi suuruse järgi rotatsioon on väga ebausaldusväärne, mistõttu otsustasime kasutada indeksis olevate dokumentide arvu järgi pööramist. Analüüsisime iga indeksit ja registreerisime dokumentide arvu, mille järel rotatsioon peaks toimima. Seega oleme jõudnud optimaalse killu suuruseni - mitte rohkem kui 50 GB.
Klastrite optimeerimine
Siiski pole me probleemidest täielikult vabanenud. Kahjuks ilmusid endiselt väikesed indeksid: need ei jõudnud määratud mahuni, neid ei pööratud ja need kustutati üle kolme päeva vanemate indeksite üldise puhastamisega, kuna eemaldasime kuupäeva järgi pööramise. See tõi kaasa andmete kadumise, kuna indeks klastrist kadus täielikult ja katse kirjutada olematule indeksile rikkus kuraatori loogika, mida haldasime. Kirjutamise alias muudeti indeksiks ja rikkus ümberlülitusloogika, põhjustades mõne indeksi kontrollimatu kasvu kuni 600 GB-ni.
Näiteks pööramise konfiguratsiooni jaoks:
с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
Kui aliast ei olnud, ilmnes tõrge:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Jätsime selle probleemi lahendamise järgmiseks iteratsiooniks ja käsitlesime veel üht probleemi: lülitusime Logstashi tõmbeloogikale, mis töötleb sissetulevaid logisid (eemaldab ebavajaliku teabe ja rikastab). Asetasime selle dockerisse, mille käivitame docker-compose'i kaudu, ja sinna paigutasime ka logstash-exporteri, mis saadab Prometheusele mõõdikud logivoo operatiivseks jälgimiseks. Nii andsime endale võimaluse sujuvalt muuta igat tüüpi logi töötlemise eest vastutavate logstashi eksemplaride arvu.
Sel ajal, kui me klastrit täiustasime, kasvas cian.ru liiklus 12,8 miljoni unikaalse kasutajani kuus. Selle tulemusena selgus, et meie ümberehitused jäid tootmise muutustest veidi maha ja seisime silmitsi tõsiasjaga, et “soojad” sõlmed ei tulnud koormusega toime ja pidurdasid kogu palkide tarnimist. Saime "kuumad" andmed ilma tõrgeteta, kuid ülejäänu kohaletoimetamisse tuli sekkuda ja indeksite ühtlaseks jaotamiseks käsitsi ümber pöörata.
Samal ajal tegi klastris logstashi eksemplaride skaleerimise ja seadete muutmise keeruliseks asjaolu, et tegemist oli kohaliku dokke-koostamise programmiga ning kõik toimingud tehti käsitsi (uute otste lisamiseks tuli kõik käsitsi läbi teha serverid ja docker-compose up -d kõikjal).
Palkide ümberjagamine
Selle aasta septembris alles lõikasime monoliiti, klastri koormus kasvas ja logivoog lähenes 30 tuhandele sõnumile sekundis.
Alustasime järgmist iteratsiooni riistvaravärskendusega. Vahetasime viielt koordinaatorilt kolmele, vahetasime välja andmesõlmed ning võitsime raha ja salvestusruumi osas. Sõlmede jaoks kasutame kahte konfiguratsiooni:
- Kuumade sõlmede jaoks: E3-1270 v6 / 960 Gb SSD / 32 Gb x 3 x 2 (3 jaoks Hot1 ja 3 jaoks Hot2).
- Soojade sõlmede jaoks: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Selle iteratsiooni käigus teisaldasime mikroteenuste juurdepääsulogidega indeksi, mis võtab sama ruumi kui eesliini nginxi logid, teise kolme "kuuma" sõlme rühma. Nüüd salvestame andmeid "kuumade" sõlmede kohta 20 tundi ja seejärel edastame need "soojadesse" sõlmedesse ülejäänud logidesse.
Lahendasime väikeste indeksite kadumise probleemi nende pöörlemise ümberseadistamisega. Nüüd pööratakse indekseid igal juhul iga 23 tunni järel, isegi kui andmeid on seal vähe. See suurendas veidi kildude arvu (neid oli umbes 800), kuid klastri jõudluse seisukohalt on see talutav.
Selle tulemusena oli klastris kuus "kuuma" ja ainult neli "sooja" sõlme. See põhjustab pikkade ajavahemike jooksul päringute esitamisel väikese viivituse, kuid sõlmede arvu suurendamine tulevikus lahendab selle probleemi.
See iteratsioon lahendas ka poolautomaatse skaleerimise puudumise probleemi. Selleks juurutasime infrastruktuuri Nomad klastri – sarnaselt sellega, mida oleme juba tootmises kasutusele võtnud. Praegu Logstashi kogus automaatselt sõltuvalt koormusest ei muutu, kuid selleni me tuleme.
Tuleviku plaanid
Rakendatud konfiguratsioon skaleerub suurepäraselt ja nüüd salvestame 13,3 TB andmeid - kõik logid 4 päeva jooksul, mis on vajalikud hoiatuste hädaolukorra analüüsiks. Teisendame osa logidest mõõdikuteks, mille lisame Graphite'i. Inseneride töö hõlbustamiseks on meil infrastruktuuriklastri mõõdikud ja skriptid levinud probleemide poolautomaatseks parandamiseks. Pärast andmesõlmede arvu suurendamist, mis on planeeritud järgmisel aastal, läheme andmesalvestusele üle 4 päevalt 7 päevale. Sellest piisab operatiivtööks, sest me püüame alati võimalikult kiiresti intsidente uurida ning pikaajalisteks uurimiseks on olemas telemeetriaandmed.
2019. aasta oktoobris oli cian.ru liiklus kasvanud juba 15,3 miljoni unikaalse kasutajani kuus. Sellest sai tõsine proovikivi palkide kohaletoimetamise arhitektuursele lahendusele.
Nüüd valmistume ElasticSearchi värskendamiseks versioonile 7. Selleks peame aga värskendama paljude indeksite vastendamist ElasticSearchis, kuna need kolisid versioonist 5.5 ja kuulutati versioonis 6 aegunuks (versioonis neid lihtsalt ei eksisteeri 7). See tähendab, et värskendusprotsessi käigus tekib kindlasti mingi vääramatu jõud, mis jätab meid probleemi lahendamise ajaks logideta. Versioonist 7 ootame enim täiustatud liidese ja uute filtritega Kibanat.
Täitsime oma põhieesmärgi: lõpetasime palkide kadumise ja vähendasime taristuklastri seisakuid 2-3 krahhilt nädalas paaritunnisele hooldustööle kuus. Kogu see töö tootmises on peaaegu nähtamatu. Kuid nüüd saame täpselt kindlaks teha, mis meie teenusega toimub, saame seda kiiresti teha vaikses režiimis ja mitte muretseda, et logid kaotsi lähevad. Üldiselt oleme rahul, rõõmsad ja valmistume uuteks äpardusteks, millest räägime hiljem.
Allikas: www.habr.com