Salvete omnes, nomen mihi est Alexander, et apud CIAN laboro ut ingeniarius, in administratione systematum et automatione processuum infrastructurae operam dans. In commentariis unius ex prioribus nostris articulis, rogati sumus ut explicaremus unde quattuor TB diariorum per diem accipiamus et quid cum eis faciamus. Ita, multa diaria habemus, et proprium gregem infrastructurae creavimus ad ea tractanda, quod nobis permittit ut problemata celeriter solvamus. In hoc articulo, communicabo quomodo eum per annum proximum aptavimus ad hunc fluxum datorum semper crescentem tractandum.
Ubi incipimus?
Per annos proximos, onus in cian.ru celeriter crevit, et tertio quadrante anni 2018, commeatus ad 11.2 miliones utentium singularium per mensem pervenit. Hoc tempore, usque ad 40% inscriptionum nostrarum momentis criticis amittebamus, quod nos impediebat ne casus celeriter solveremus et magnum tempus et laborem in eis solvendis perdebat. Saepe etiam causam principalem problematis invenire non poteramus, et post aliquod tempus recurrebat. Incubus erat cui occurrendum erat.
Eo tempore, gregem decem nodorum datorum, ElasticSearch versionem 5.5.2 cum ordinationibus indicum ad conservationem diariorum currentibus, utebamur. Hoc plus quam annum abhinc tamquam solutionem popularem et pretio moderato instituimus: fluxus diariorum tum non tam magnus erat, ergo nulla causa erat configurationes proprias excogitare.
Logstash tractationem diariorum advenientium in portibus diversis per quinque coordinatores ElasticSearch curavit. Quisque index, magnitudine non obstante, ex quinque fragmentis constabat. Rotationes horariae et diurnae effectae sunt, quod effecit ut circiter centum novae fragmentae gregi singulis horis adderentur. Dummodo volumen diariorum modestum esset, grex negotium efficaciter peragebat, et nemo in eius configurationibus animum intenderet.
Problemata celeris incrementi
Volumen diariorum generatorum celeriter crevit, dum duo processus inter se congruebant. Ex una parte, numerus utentium servitii crescebat. Ex altera parte, active ad architecturam microservitiorum transire coepimus, monolithis nostris C# et Pythonicis veteribus dissolventes. Plures novae microservitiae, partes monolithi substituentes, multo plura diaria pro grege infrastructurae generaverunt.
Ipsa amplificatio nos ad gregem paene inadministrabilem perduxit. Cum acta (logs) viginti milium nuntiorum per secundum advenire coeperunt, rotationes frequentes et inutiles numerum fragmentorum (shards) ad sex milia auxerunt, cum plus quam sexcentis fragmentis per nodum.
Hoc ad difficultates cum assignatione memoriae RAM duxit, et cum nodus corrueret, omnes fragmenta simul migrarent, augentes commeatum et reliquos nodos onerantes, ita ut data in gregem scribere paene impossibile esset. Et per hoc tempus, sine actis relicti eramus. Et si problema cum... server Decimam partem totius gregis amittebamus. Magnus numerus indicum minorum complexitati augebat.
Sine diariis, causam incidentis intellegere non possemus et citius aut serius eadem errata repetere possemus. Hoc in philosophia turmae nostrae intolerabile erat, cum omnes nostri modi operandi ita designati sint ut eadem problemata iterum iterumque non repeterentur. Ad hoc assequendum, plenam collectionem diariorum et eorum traditionem fere tempore reali requirebamus, cum turma ingeniariorum qui parati erant admonitiones non solum ex metris sed etiam ex diariis observaret. Ad magnitudinem problematis intellegendam, volumen totale diariorum eo tempore circiter duo TB per diem erat.
Propositum nobis statuimus ut iacturam diariorum omnino tolleremus et tempus quod diariorum ad gregem ELK tradendorum requiritur ad maximum quindecim minutarum tempore casuum vis maioris reduceremus (hoc numero deinde ut KPI internum adhibuimus).
Novus mechanismus rotationis et nodi calidi-tepidi
Conversionem gregis incepimus ElasticSearch ex versione 5.5.2 ad 6.4.3 promovendo. Gregis noster versio 5 iterum collapsus erat, itaque eum claudere et omnino promovere decrevimus—nullae enim acta erant. Itaque transitionem intra paucas horas perfecimus.
Mutatio gravissima hoc tempore fuit implementatio Apache Kafka in tribus nodis cum coordinatore quasi intermedio. Intermediarius nuntiorum nos prohibuit ne acta perderemus inter difficultates ElasticSearch. Simul, duos nodos gregi addidimus et ad architecturam calidam-timidam cum tribus nodis "calidis" in diversis armariis in centro datorum sitis transiimus. Acta ad hos nodos direximus quae omnino non amitti debent — NGINX, necnon acta errorum applicationum — utentes larva. Acta minora — debug, monitiones, et similia — ad nodos reliquos missa sunt, et acta "critica" etiam a nodis "calidis" post viginti quattuor horas migrata sunt.
Ne numerus indicum minorum augeretur, a rotatione secundum tempus ad mechanismum "rollover" transiimus. Multae informationes in foris de incertitudine rotationis secundum magnitudinem indicis repertae sunt, itaque rotationem secundum numerum documentorum in indice adhibere decrevimus. Singulum indicem analyzavimus et numerum documentorum post quem rotatio incipienda esset determinavimus. Hoc modo, optimam magnitudinem fragmenti non plus quam 50 GB consecuti sumus.
Optimizatio gregum
Attamen, difficultates non omnino eliminavimus. Infeliciter, indices parvi adhuc apparebant: magnitudinem definitam non attigerunt, non rotati sunt, et per purgationem indicum globalem pro indicibus vetustioribus quam tres dies remoti sunt, cum rotationem secundum datam removeramus. Hoc ad iacturam datorum duxit quia index omnino e grege evanuit, et conatus scribendi ad indicem non existentem logicam curatoris quem ad administrationem utebamur fregit. Alias scribendi in indicem conversum est et logicam transitionis fregit, quo facto nonnulli indices ad 600 GB sine moderatione crescere coeperunt.
Exempli gratia, pro configuratione rotationis:
с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
Si nullum alias rollover aderat, sequens error accidit:
ERROR alias "nginx_write" not found.
ERROR Failed to complete action: rollover. <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".
Hoc problema ad iterationem sequentem reliquimus et in aliam rem intenti sumus: ad logicam tractationis Logstash per "pull-based" pro diariis advenientibus transiimus (informatione superflua remota et locupletata). Eam in Docker collocavimus, quem per Docker-compose administramus, et etiam "logstash-exporter" hospitio recepimus, qui mensuras ad Prometheum mittit ad monitorandum fluxum diariorum in tempore reali. Hoc nobis permisit ut numerum instantiarum Logstash quae pro tractando unoquoque genere diarii responsabiles sunt sine difficultate mutaremus.
Dum gregem emendabamus, frequentia cian.ru ad 12,8 miliones utentium singularium per mensem crevit. Quam ob rem, transformationes nostrae paulum post mutationes productionis fuerunt, et in condicionem incidimus ubi nodi calidae onus ferre non poterant et traditionem diariorum tardabant. Data calida sine interruptione accepimus, sed pro aliis datis, intervenire et translationes manuales facere debuimus ut indices aequaliter distribueremus.
Simul, amplificatio et mutatio configurationum exemplorum logstash in grege difficilior erat eo quod docker-compose localis erat, et omnes actiones manu peragebantur (ad novos fines addendos, necesse erat per omnes servores manu ire et docker-compose up -d ubique currere).
Redistributio diarii
Mense Septembri huius anni, monolithum adhuc serrabamus, onus in grege crescebat, et fluxus diarii ad triginta milia nuntiorum per secundum appropinquabat.
Iterationem sequentem cum emendatione apparati incepimus. A quinque coordinatoribus ad tres progressi sumus, nodos datorum substituimus, et pecuniam et spatium repositionis lucrati sumus. Duabus configurationibus nodorum utimur:
- Pro nodis calidis: E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 pro Calido1 et 3 pro Calido2).
- Pro nodis "calidis": E3-1230 v6 / 4Tb SSD / 32 Gb x 4.
In hac iteratione, indicem cum actis accessus microservitiorum, qui idem spatium occupat ac acta Nginx anterioris, ad secundum gregem trium nodorum "calidorum" transtulimus. Nunc notitias in nodis "calidis" per viginti horas servamus, deinde ad nodos "calidos" transferimus ut actis reliquis coniungantur.
Problema indicum parvorum evanescentium solvimus rotationem eorum reconfigurando. Nunc indices singulis viginti tribus horis rotantur, etiamsi pauca data continent. Hoc numerum fragmentorum (nunc circiter octingentos) paulum auxit, sed ex prospectu perfunctionis gregis, hoc tolerabile est.
Propterea, greges nunc sex nodos "calidos" et tantum quattuor nodos "calidos" habent. Hoc moram levem in interrogationibus per longas temporis intervallas efficit, sed numerus nodorum auctus hanc quaestionem in futuro solvet.
Haec iteratio etiam defectum amplificationis semi-automaticae tractavit. Ad hanc rem corrigendam, gregem infrastructurae Nomad collocavimus—similem ei quem iam in productione habemus. Nunc, numerus instantiarum Logstash non sponte secundum onus amplificatur, sed eo perveniemus.
Consilia pro futuro
Configuratio implementata bene amplificatur, et nunc 13,3 TB notitiarum servamus—omnia acta per quattuor dies, quod necessarium est ad analysin monituum in casu necessitatis. Nonnulla acta in mensuras convertimus, quas in Graphite servamus. Ad laborem ingeniariorum faciliorem reddendum, mensuras pro grege infrastructurae et scripta ad reparationem semi-automaticam problematum communium habemus. Post auctum numerum nodorum notitiarum, quod pro anno proximo designatur, ad retentionem notitiarum a quattuor ad septem dies transibimus. Hoc sufficiet ad opus operativum, cum semper conemur casus quam celerrime investigare, et notitia telemetrica ad investigationes diuturnas praesto est.
Mense Octobri anni 2019, numerus utentium singularium apud cian.ru ad 15,3 miliones per mensem crevit. Hoc grave experimentum architecturae traditionis diariorum factum est.
ElasticSearch ad versionem 7 nunc paramus. Attamen, hoc requiret ut mappae multorum indicum ElasticSearch renoventur, cum ex versione 5.5 migrati sint et in versione 6 obsoleti (simpliciter in versione 7 non existunt). Hoc significat, durante processu renovationis, inevitabiliter eventurum esse eventum quendam inexpectatum, qui nos sine actis relinquet dum quaestio solvitur. Ex omnibus functionibus versionis 7, maxime Kibanam exspectamus cum interfacie emendata et novis filtris.
Propositum principale consecuti sumus: amissionem diariorum cessavimus et tempus inoperabile gregis infrastructurae nostrae a duabus vel tribus interruptionibus per hebdomadam ad paucas tantum horas sustentationis per mensem redegimus. Hoc totum opus in productione paene impervium est. Attamen, nunc accurate discernere possumus quid cum servitio nostro fiat, celeriter et certo modo, et sine cura de amissione diariorum. In summa, contenti et laeti sumus, et ad nova facta nos paramus, quae postea communicabimus.
Source: www.habr.com
