Helo bawb, fy enw i yw Alexander, rwy'n gweithio yn CIAN fel peiriannydd ac yn ymwneud â gweinyddu systemau ac awtomeiddio prosesau seilwaith. Yn y sylwadau i un o'r erthyglau blaenorol, gofynnwyd i ni ddweud o ble rydyn ni'n cael 4 TB o foncyffion y dydd a beth rydyn ni'n ei wneud â nhw. Oes, mae gennym lawer o foncyffion, ac mae clwstwr seilwaith ar wahân wedi’i greu i’w prosesu, sy’n ein galluogi i ddatrys problemau’n gyflym. Yn yr erthygl hon byddaf yn siarad am sut y gwnaethom ei addasu dros gyfnod o flwyddyn i weithio gyda llif data cynyddol.
Ble wnaethon ni ddechrau?
Dros yr ychydig flynyddoedd diwethaf, mae'r llwyth ar cian.ru wedi tyfu'n gyflym iawn, ac erbyn trydydd chwarter 2018, cyrhaeddodd traffig adnoddau 11.2 miliwn o ddefnyddwyr unigryw y mis. Bryd hynny, ar adegau tyngedfennol collwyd hyd at 40% o'r cofnodion, a dyna pam na allem ddelio'n gyflym â digwyddiadau a threulio llawer o amser ac ymdrech yn eu datrys. Yn aml hefyd ni allem ddod o hyd i achos y broblem, a byddai'n digwydd eto ar ôl peth amser. Roedd yn uffern ac roedd yn rhaid gwneud rhywbeth amdano.
Bryd hynny, gwnaethom ddefnyddio clwstwr o 10 nod data gyda fersiwn ElasticSearch 5.5.2 gyda gosodiadau mynegai safonol i storio logiau. Fe'i cyflwynwyd fwy na blwyddyn yn ôl fel ateb poblogaidd a fforddiadwy: yna nid oedd llif y boncyffion mor fawr, nid oedd unrhyw ddiben llunio ffurfweddiadau ansafonol.
Darparwyd prosesu logiau sy'n dod i mewn gan Logstash ar wahanol borthladdoedd ar bum cydlynydd ElasticSearch. Roedd un mynegai, waeth beth fo'i faint, yn cynnwys pum darn. Trefnwyd cylchdro bob awr a dyddiol, o ganlyniad, roedd tua 100 o ddarnau newydd yn ymddangos yn y clwstwr bob awr. Er nad oedd llawer iawn o gofnodion, fe wnaeth y clwstwr ymdopi'n dda ac ni thalodd unrhyw un sylw i'w osodiadau.
Heriau twf cyflym
Tyfodd cyfaint y boncyffion a gynhyrchwyd yn gyflym iawn, wrth i ddwy broses orgyffwrdd â'i gilydd. Ar y naill law, cynyddodd nifer defnyddwyr y gwasanaeth. Ar y llaw arall, dechreuon ni newid i bensaernïaeth meicrowasanaeth, gan lifio ein hen fonolithau yn C# a Python. Cynhyrchodd sawl dwsin o ficrowasanaethau newydd a ddisodlodd rhannau o'r monolith lawer mwy o foncyffion ar gyfer y clwstwr seilwaith.
Graddio a'n harweiniodd at y pwynt lle daeth y clwstwr bron yn amhosibl ei reoli. Pan ddechreuodd y logiau gyrraedd cyfradd o 20 mil o negeseuon yr eiliad, cynyddodd cylchdroi diwerth aml nifer y darnau i 6 mil, ac roedd mwy na 600 o ddarnau fesul nod.
Arweiniodd hyn at broblemau gyda dyrannu RAM, a phan chwalodd nod, dechreuodd yr holl ddarnau symud ar yr un pryd, gan luosi traffig a llwytho nodau eraill, a oedd yn ei gwneud bron yn amhosibl ysgrifennu data i'r clwstwr. Ac yn ystod y cyfnod hwn cawsom ein gadael heb foncyffion. Ac os oedd problem gyda'r gweinydd, fe gollon ni 1/10 o'r clwstwr yn y bôn. Ychwanegodd nifer fawr o fynegeion bach gymhlethdod.
Heb logiau, nid oeddem yn deall y rhesymau dros y digwyddiad a gallem gamu ar yr un rhaca eto yn hwyr neu'n hwyrach, ac yn ideoleg ein tîm roedd hyn yn annerbyniol, gan fod ein holl fecanweithiau gwaith wedi'u cynllunio i wneud yn union i'r gwrthwyneb - peidiwch byth ag ailadrodd. yr un problemau. I wneud hyn, roedd angen y swm llawn o logiau a'u danfoniad bron mewn amser real, gan fod tîm o beirianwyr ar ddyletswydd yn monitro rhybuddion nid yn unig o fetrigau, ond hefyd o logiau. Er mwyn deall maint y broblem, ar y pryd cyfanswm cyfaint y boncyffion oedd tua 2 TB y dydd.
Fe wnaethom osod nod i ddileu colli boncyffion yn llwyr a lleihau'r amser y cânt eu danfon i'r clwstwr ELK i uchafswm o 15 munud yn ystod force majeure (fe wnaethom ddibynnu yn ddiweddarach ar y ffigur hwn fel DPA mewnol).
Mecanwaith cylchdroi newydd a nodau poeth-gynnes
Dechreuon ni'r trawsnewid clwstwr trwy ddiweddaru'r fersiwn ElasticSearch o 5.5.2 i 6.4.3. Unwaith eto bu farw ein clwstwr fersiwn 5, a gwnaethom benderfynu ei ddiffodd a'i ddiweddaru'n llwyr - nid oes unrhyw logiau o hyd. Felly gwnaethom y cyfnod pontio hwn mewn ychydig oriau yn unig.
Y trawsnewid mwyaf ar raddfa fawr ar hyn o bryd oedd gweithredu Apache Kafka ar dri nod gyda chydlynydd fel byffer canolradd. Arbedodd y brocer negeseuon ni rhag colli logiau yn ystod problemau gydag ElasticSearch. Ar yr un pryd, fe wnaethom ychwanegu 2 nod at y clwstwr a newid i bensaernïaeth boeth-gynnes gyda thri nod “poeth” wedi'u lleoli mewn gwahanol raciau yn y ganolfan ddata. Fe wnaethom ailgyfeirio logiau atynt gan ddefnyddio mwgwd na ddylid ei golli o dan unrhyw amgylchiadau - nginx, yn ogystal â logiau gwall cais. Anfonwyd mân foncyffion at y nodau oedd yn weddill - dadfygio, rhybudd, ac ati, ac ar ôl 24 awr, trosglwyddwyd logiau “pwysig” o nodau “poeth”.
Er mwyn peidio â chynyddu nifer y mynegeion bach, fe wnaethom newid o gylchdroi amser i'r mecanwaith treigl. Roedd llawer o wybodaeth ar y fforymau bod cylchdroi yn ôl maint mynegai yn annibynadwy iawn, felly penderfynasom ddefnyddio cylchdroi yn ôl nifer y dogfennau yn y mynegai. Gwnaethom ddadansoddi pob mynegai a chofnodi nifer y dogfennau y dylai cylchdro weithio ar ôl hynny. Felly, rydym wedi cyrraedd y maint shard gorau posibl - dim mwy na 50 GB.
Optimeiddio clwstwr
Fodd bynnag, nid ydym wedi cael gwared yn llwyr ar y problemau. Yn anffodus, roedd mynegeion bach yn dal i ymddangos: ni chyrhaeddwyd y cyfaint penodedig, ni chawsant eu cylchdroi, a chawsant eu dileu trwy lanhau mynegeion sy'n hŷn na thri diwrnod yn fyd-eang, ers i ni ddileu cylchdro yn ôl dyddiad. Arweiniodd hyn at golli data oherwydd bod y mynegai o’r clwstwr wedi diflannu’n gyfan gwbl, a thorrodd ymgais i ysgrifennu at fynegai nad oedd yn bodoli resymeg y curadur a ddefnyddiwyd gennym ar gyfer rheoli. Troswyd Alias ar gyfer ysgrifennu yn fynegai a thorrodd y rhesymeg treigl, gan achosi twf afreolus o rai mynegeion hyd at 600 GB.
Er enghraifft, ar gyfer y ffurfwedd cylchdro:
с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
Os nad oedd alias treiglo drosodd, digwyddodd gwall:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Gadawsom yr ateb i'r broblem hon ar gyfer yr iteriad nesaf a chodwyd mater arall: fe wnaethom newid i resymeg tynnu Logstash, sy'n prosesu logiau sy'n dod i mewn (gan ddileu gwybodaeth ddiangen a chyfoethogi). Fe wnaethon ni ei roi mewn docwr, rydyn ni'n ei lansio trwy docker-compose, a gwnaethom hefyd osod allforiwr logstash yno, sy'n anfon metrigau at Prometheus ar gyfer monitro gweithredol y ffrwd log. Fel hyn, rhoesom gyfle i ni'n hunain newid yn ddidrafferth nifer yr achosion logstash sy'n gyfrifol am brosesu pob math o log.
Er ein bod yn gwella'r clwstwr, cynyddodd traffig cian.ru i 12,8 miliwn o ddefnyddwyr unigryw y mis. O ganlyniad, daeth yn amlwg bod ein trawsnewidiadau ychydig y tu ôl i'r newidiadau mewn cynhyrchu, ac roeddem yn wynebu'r ffaith na allai'r nodau “cynnes” ymdopi â'r llwyth a'u bod wedi arafu'r broses gyfan o gyflenwi logiau. Cawsom ddata “poeth” heb fethiannau, ond bu'n rhaid i ni ymyrryd wrth gyflwyno'r gweddill a symud ymlaen â llaw er mwyn dosbarthu'r mynegeion yn gyfartal.
Ar yr un pryd, roedd graddio a newid gosodiadau achosion logstash yn y clwstwr yn cael ei gymhlethu gan y ffaith ei fod yn gyfansoddiad docwr lleol, a chyflawnwyd yr holl gamau â llaw (i ychwanegu nodau newydd, roedd angen mynd trwy'r cyfan â llaw. y gweinyddion a docker-compose up -d yn mhob man).
Ailddosbarthu log
Ym mis Medi eleni, roeddem yn dal i dorri'r monolith, roedd y llwyth ar y clwstwr yn cynyddu, ac roedd llif y boncyffion yn agosáu at 30 mil o negeseuon yr eiliad.
Dechreuon ni'r iteriad nesaf gyda diweddariad caledwedd. Fe wnaethom newid o bum cydlynydd i dri, disodli nodau data ac ennill o ran arian a gofod storio. Ar gyfer nodau rydym yn defnyddio dau ffurfweddiad:
- Ar gyfer nodau “poeth”: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 ar gyfer Hot1 a 3 ar gyfer Hot2).
- Ar gyfer nodau “cynnes”: E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
Ar yr iteriad hwn, gwnaethom symud y mynegai gyda logiau mynediad o ficrowasanaethau, sy'n cymryd yr un gofod â logiau nginx rheng flaen, i'r ail grŵp o dri nod “poeth”. Rydyn ni nawr yn storio data ar nodau “poeth” am 20 awr, ac yna'n eu trosglwyddo i nodau “cynnes” i weddill y logiau.
Fe wnaethom ddatrys y broblem o fynegeion bach yn diflannu trwy ad-drefnu eu cylchdro. Nawr mae'r mynegeion yn cael eu cylchdroi bob 23 awr beth bynnag, hyd yn oed os nad oes llawer o ddata yno. Cynyddodd hyn y nifer o ddarnau mân (roedd tua 800 ohonynt), ond o safbwynt perfformiad clwstwr mae'n oddefadwy.
O ganlyniad, roedd chwe nod “poeth” a dim ond pedwar “cynnes” yn y clwstwr. Mae hyn yn achosi ychydig o oedi ar geisiadau dros gyfnodau hir, ond bydd cynyddu nifer y nodau yn y dyfodol yn datrys y broblem hon.
Roedd yr iteriad hwn hefyd yn datrys y broblem o ddiffyg graddio lled-awtomatig. I wneud hyn, fe wnaethom ddefnyddio clwstwr seilwaith Nomad - tebyg i'r hyn yr ydym eisoes wedi'i ddefnyddio ym maes cynhyrchu. Am y tro, nid yw swm y Logstash yn newid yn awtomatig yn dibynnu ar y llwyth, ond byddwn yn dod at hyn.
Cynlluniau ar gyfer y dyfodol
Mae'r graddfeydd cyfluniad a weithredir yn berffaith, ac yn awr rydym yn storio 13,3 TB o ddata - pob log am 4 diwrnod, sy'n angenrheidiol ar gyfer dadansoddiad brys o rybuddion. Rydyn ni'n trosi rhai o'r logiau yn fetrigau, rydyn ni'n eu hychwanegu at Graffit. Er mwyn gwneud gwaith peirianwyr yn haws, mae gennym fetrigau ar gyfer y clwstwr seilwaith a sgriptiau ar gyfer atgyweirio problemau cyffredin yn lled-awtomatig. Ar ôl cynyddu nifer y nodau data, sydd wedi'u cynllunio ar gyfer y flwyddyn nesaf, byddwn yn newid i storio data o 4 i 7 diwrnod. Bydd hyn yn ddigon ar gyfer gwaith gweithredol, gan ein bod bob amser yn ceisio ymchwilio i ddigwyddiadau cyn gynted â phosibl, ac ar gyfer ymchwiliadau hirdymor mae data telemetreg.
Ym mis Hydref 2019, roedd traffig i cian.ru eisoes wedi tyfu i 15,3 miliwn o ddefnyddwyr unigryw y mis. Daeth hyn yn brawf difrifol o'r ateb pensaernïol ar gyfer dosbarthu boncyffion.
Nawr rydym yn paratoi i ddiweddaru ElasticSearch i fersiwn 7. Fodd bynnag, ar gyfer hyn bydd yn rhaid i ni ddiweddaru mapio llawer o fynegeion yn ElasticSearch, gan iddynt symud o fersiwn 5.5 a chael eu datgan yn anghymeradwy yn fersiwn 6 (yn syml, nid ydynt yn bodoli yn y fersiwn 7). Mae hyn yn golygu y bydd rhyw fath o force majeure yn ystod y broses ddiweddaru yn bendant, a fydd yn ein gadael heb logiau tra bydd y mater yn cael ei ddatrys. O fersiwn 7, rydym yn edrych ymlaen yn fawr at Kibana gyda rhyngwyneb gwell a hidlwyr newydd.
Cyflawnwyd ein prif nod: rhoesom y gorau i golli boncyffion a lleihau amser segur y clwstwr seilwaith o 2-3 damwain yr wythnos i ychydig oriau o waith cynnal a chadw y mis. Mae'r holl waith hwn ym maes cynhyrchu bron yn anweledig. Fodd bynnag, nawr gallwn benderfynu yn union beth sy'n digwydd gyda'n gwasanaeth, gallwn ei wneud yn gyflym mewn modd tawel a pheidio â phoeni y bydd y logiau'n cael eu colli. Yn gyffredinol, rydym yn fodlon, yn hapus ac yn paratoi ar gyfer campau newydd, y byddwn yn siarad amdanynt yn nes ymlaen.
Ffynhonnell: hab.com