Sæl öll, ég heiti Alexander, ég vinn hjá CIAN sem verkfræðingur og tek þátt í kerfisstjórnun og sjálfvirkni innviðaferla. Í athugasemdum við eina af fyrri greinunum vorum við beðin um að segja frá því hvar við fáum 4 TB af logum á dag og hvað við gerum við þá. Já, við erum með fullt af annálum og sérstakur innviðaklasi hefur verið búinn til til að vinna úr þeim, sem gerir okkur kleift að leysa vandamál fljótt. Í þessari grein mun ég tala um hvernig við aðlöguðum það á ári til að vinna með sívaxandi gagnaflæði.
Hvar byrjuðum við?
Undanfarin ár hefur álagið á cian.ru vaxið mjög hratt og á þriðja ársfjórðungi 2018 náði auðlindaumferð 11.2 milljón einstaka notendur á mánuði. Á þeim tíma, á mikilvægum augnablikum, misstum við allt að 40% af annálunum, sem er ástæðan fyrir því að við gátum ekki brugðist hratt við atvikum og eyddum miklum tíma og fyrirhöfn í að leysa þau. Við gátum líka oft ekki fundið orsök vandans og það kom aftur eftir nokkurn tíma. Þetta var helvíti og eitthvað varð að gera í þessu.
Á þeim tíma notuðum við þyrping af 10 gagnahnútum með ElasticSearch útgáfu 5.5.2 með stöðluðum vísitölustillingum til að geyma annála. Það var kynnt fyrir meira en ári síðan sem vinsæl og hagkvæm lausn: þá var flæði stokka ekki svo mikið, það var ekkert mál að koma með óstaðlaðar stillingar.
Vinnsla á innkomnum annálum var veitt af Logstash á mismunandi höfnum á fimm ElasticSearch umsjónarmönnum. Ein vísitala, óháð stærð, samanstóð af fimm brotum. Skipulagður var klukkutíma og daglegur skiptagangur, í kjölfarið komu um 100 ný brot í þyrpinguna á klukkutíma fresti. Þó að það væru ekki mjög margir logs, tókst þyrpingin vel og enginn veitti stillingum hans athygli.
Áskoranir örs vaxtar
Rúmmál myndaðra annála jókst mjög hratt þar sem tvö ferli skarast hvort annað. Annars vegar fjölgaði notendum þjónustunnar. Á hinn bóginn byrjuðum við að skipta virkan yfir í örþjónustuarkitektúr og sáum upp gömlu einlitana okkar í C# og Python. Nokkrir tugir nýrra örþjónustur sem leystu af hólmi hluta af einliðanum bjuggu til umtalsvert fleiri annála fyrir innviðaklasann.
Það var mælikvarði sem leiddi okkur á þann stað að þyrpingin varð nánast óviðráðanleg. Þegar annálarnir fóru að berast á hraðanum 20 þúsund skilaboð á sekúndu jók tíður ónýtur snúningur fjölda brota í 6 þúsund og voru meira en 600 brot á hnút.
Þetta leiddi til vandræða með úthlutun vinnsluminni og þegar hnútur hrundi fóru öll brot að hreyfast samtímis, margfaldaði umferð og hleðslu annarra hnúta, sem gerði það að verkum að nánast ómögulegt var að skrifa gögn í þyrpinguna. Og á þessu tímabili vorum við skilin eftir án timburs. Og ef það var vandamál með þjóninn, misstum við í rauninni 1/10 af þyrpingunni. Mikill fjöldi lítilla vísitalna jók á flókið.
Án annála skildum við ekki ástæður atviksins og gætum fyrr eða síðar stigið á sömu hrífuna aftur, og í hugmyndafræði liðsins okkar var þetta óviðunandi, þar sem öll vinnubrögð okkar eru hönnuð til að gera hið gagnstæða - aldrei endurtaka sömu vandamálin. Til að gera þetta þurftum við allt magn annála og afhendingu þeirra nánast í rauntíma, þar sem teymi vakthafandi verkfræðinga fylgdist ekki aðeins með viðvörunum frá mælingum, heldur einnig frá annálum. Til að skilja umfang vandans, þá var heildarmagn logs um 2 TB á dag.
Við settum okkur það markmið að útrýma algjörlega tapi á annálum og stytta afhendingartíma þeirra til ELK klasans í að hámarki 15 mínútur á meðan á óviðráðanlegu ástandi stendur (við treystum síðar á þessa tölu sem innri KPI).
Nýr snúningsbúnaður og heitheitir hnútar
Við hófum klasabreytinguna með því að uppfæra ElasticSearch útgáfuna úr 5.5.2 í 6.4.3. Enn og aftur dó útgáfa 5 þyrpingin okkar og við ákváðum að slökkva á honum og uppfæra hann alveg - það eru enn engir logs. Þannig að við gerðum þessa umskipti á aðeins nokkrum klukkustundum.
Stærsta umbreytingin á þessu stigi var innleiðing Apache Kafka á þremur hnútum með samræmingarbúnaði sem millibuffi. Skilaboðamiðlarinn bjargaði okkur frá því að missa annála í vandræðum með ElasticSearch. Á sama tíma bættum við 2 hnútum við þyrpinguna og skiptum yfir í heitt heitt arkitektúr með þremur „heitum“ hnútum staðsettum í mismunandi rekkum í gagnaverinu. Við beinum annálum til þeirra með því að nota grímu sem ætti ekki að tapast undir neinum kringumstæðum - nginx, sem og villuskrám forrita. Minniháttar annálar voru sendar til hnútanna sem eftir voru - kembiforrit, viðvörun osfrv., og eftir 24 klukkustundir voru „mikilvægir“ annálar fluttir frá „heitum“ hnútum.
Til þess að fjölga ekki litlum vísitölum, skiptum við frá tímasnúningi yfir í veltibúnað. Það var mikið af upplýsingum á spjallborðunum að snúningur eftir vísitölustærð er mjög óáreiðanlegur, svo við ákváðum að nota snúning eftir fjölda skjala í vísitölunni. Við greindum hverja vísitölu og skráðum fjölda skjala sem snúningur ætti að virka eftir. Þannig höfum við náð ákjósanlegri stærð brotsins - ekki meira en 50 GB.
Hagræðing klasa
Hins vegar höfum við ekki alveg losnað við vandamálin. Því miður birtust enn litlar vísitölur: þær náðu ekki tilgreindu rúmmáli, þeim var ekki snúið og þeim var eytt með alþjóðlegri hreinsun á vísitölum eldri en þriggja daga, þar sem við fjarlægðum snúning eftir dagsetningu. Þetta leiddi til gagnataps vegna þess að vísitalan úr klasanum hvarf alveg og tilraun til að skrifa á vísitölu sem ekki var til braut rökfræði sýningarstjórans sem við notuðum við stjórnun. Samnefni fyrir ritun var breytt í vísitölu og braut rúllunarrökfræðina, sem olli stjórnlausum vexti sumra vísitalna allt að 600 GB.
Til dæmis, fyrir snúningsstillinguna:
с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
Ef það var ekkert rollover alias kom upp villa:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Við skildum lausnina á þessu vandamáli eftir í næstu endurtekningu og tókum upp annað mál: við skiptum yfir í dráttarrökfræði Logstash, sem vinnur úr komandi annálum (fjarlægir óþarfa upplýsingar og auðgar). Við settum það í docker, sem við ræsum í gegnum docker-compose, og við settum líka logstash-exporter þar, sem sendir mælikvarða til Prometheus til að fylgjast með rekstri logstraumsins. Þannig gáfum við okkur tækifæri til að breyta hnökralaust fjölda logstash tilvika sem bera ábyrgð á vinnslu hverrar tegundar logs.
Á meðan við vorum að bæta klasann jókst umferð cian.ru í 12,8 milljónir einstakra notenda á mánuði. Fyrir vikið kom í ljós að umbreytingar okkar voru aðeins á bak við breytingar á framleiðslunni og við stóðum frammi fyrir þeirri staðreynd að „hlýju“ hnúðarnir réðu ekki við álagið og hægðu á allri afhendingu logs. Við fengum „heit“ gögn án bilana, en við þurftum að grípa inn í afhendingu afgangsins og gera handvirka veltingu til að dreifa vísitölunum jafnt.
Á sama tíma flæktist skala og breyta stillingum logstash tilvika í þyrpingunni vegna þess að það var staðbundið docker-compose og allar aðgerðir voru gerðar handvirkt (til að bæta við nýjum endum var nauðsynlegt að fara handvirkt í gegnum alla netþjónana og gerðu docker-compose up -d alls staðar).
Endurdreifing logs
Í september á þessu ári vorum við enn að klippa einlitinn upp, álagið á þyrpinguna jókst og flæði logs var að nálgast 30 þúsund skilaboð á sekúndu.
Við byrjuðum á næstu endurtekningu með vélbúnaðaruppfærslu. Við skiptum úr fimm umsjónarmönnum í þrjá, skiptum um gagnahnúta og unnum hvað varðar peninga og geymslupláss. Fyrir hnúta notum við tvær stillingar:
- Fyrir „heita“ hnúta: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 fyrir Hot1 og 3 fyrir Hot2).
- Fyrir „hlýja“ hnúta: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Við þessa endurtekningu færðum við vísitöluna með aðgangsskrám örþjónustu, sem tekur sama pláss og nginx logs í fremstu víglínu, í annan hóp þriggja „heitra“ hnúta. Við geymum nú gögn á „heitum“ hnútum í 20 klukkustundir og flytjum þau síðan yfir á „heita“ hnúta yfir í restina af annálunum.
Við leystum vandamálið með því að litlar vísitölur hverfa með því að endurstilla snúning þeirra. Nú er vísitölunum snúið á 23 klukkustunda fresti hvort sem er, jafnvel þótt lítil gögn séu þar. Þar með fjölgaði brotunum lítillega (þeir voru um 800 talsins) en frá sjónarhóli klasaafkasta er það þolanlegt.
Fyrir vikið voru sex „heitir“ og aðeins fjórir „heitir“ hnútar í þyrpingunni. Þetta veldur smá töf á beiðnum á löngum tíma, en fjölgun hnúta í framtíðinni mun leysa þetta vandamál.
Þessi endurtekning lagaði einnig vandamálið vegna skorts á hálfsjálfvirkri mælingu. Til að gera þetta sendum við inn innviða Nomad klasa - svipað því sem við höfum þegar sett upp í framleiðslu. Í bili breytist magn Logstash ekki sjálfkrafa eftir álagi, en við munum koma að þessu.
Áætlanir fyrir framtíðina
Innleiddar stillingar mælist fullkomlega og nú geymum við 13,3 TB af gögnum - allar annálar í 4 daga, sem er nauðsynlegt fyrir neyðargreiningu á viðvörunum. Við umbreytum sumum annálum í mælikvarða, sem við bætum við Grafít. Til að auðvelda verkfræðinga vinnuna höfum við mæligildi fyrir innviðaklasann og forskriftir fyrir hálfsjálfvirkar viðgerðir á algengum vandamálum. Eftir að gagnahnútum hefur fjölgað, sem stefnt er að á næsta ári, munum við skipta yfir í gagnageymslu úr 4 í 7 daga. Þetta mun duga fyrir rekstrarvinnu þar sem við reynum alltaf að rannsaka atvik eins fljótt og auðið er og fyrir langtímarannsóknir eru til fjarmælingargögn.
Í október 2019 var umferð á cian.ru þegar orðin 15,3 milljónir einstakra notenda á mánuði. Þetta varð alvarlegt próf á arkitektúrlausninni til að afhenda logs.
Nú erum við að undirbúa uppfærslu ElasticSearch í útgáfu 7. Hins vegar verðum við að uppfæra kortlagningu margra vísitölu í ElasticSearch, þar sem þær fluttu úr útgáfu 5.5 og voru lýstar úreltar í útgáfu 6 (þær eru einfaldlega ekki til í útgáfunni) 7). Þetta þýðir að í uppfærsluferlinu verður örugglega einhvers konar force majeure, sem mun skilja okkur eftir án annála á meðan málið er leyst. Af útgáfu 7 hlökkum við mest til Kibana með bættu viðmóti og nýjum síum.
Við náðum meginmarkmiði okkar: við hættum að tapa annálum og fækkuðum niðurtíma innviðaklasans úr 2-3 hrunum á viku í nokkrar klukkustundir af viðhaldsvinnu á mánuði. Öll þessi vinna í framleiðslu er nánast ósýnileg. Hins vegar, nú getum við ákvarðað nákvæmlega hvað er að gerast með þjónustu okkar, við getum fljótt gert það í hljóðlátum ham og ekki haft áhyggjur af því að annálarnir glatist. Almennt séð erum við ánægð, ánægð og undirbúum okkur fyrir nýjar hetjudáðir, sem við munum tala um síðar.
Heimild: www.habr.com