Top fakapov Cyan

Onena! 

Nikita dut izena, Cian ingeniaritza taldeko taldeburua naiz. Enpresan dudan ardurenetako bat ekoizpeneko azpiegiturekin lotutako gorabeherak zerora murriztea da.
Jarraian eztabaidatuko denak min handia ekarri digu, eta artikulu honen helburua beste pertsona batzuek gure akatsak errepika ez daitezen edo, gutxienez, haien eragina gutxitzea da. 

hitzaurrean

Aspaldi, Cian monolitoz osatuta zegoenean eta oraindik mikrozerbitzuen arrastorik ez zegoenean, baliabide baten erabilgarritasuna neurtu genuen 3-5 orrialde egiaztatuz. 

Erantzuten dute - dena ondo dago, denbora luzez erantzuten ez badute - erne. Lanetik kanpo zenbat denbora egon behar zuten gertakaritzat jotzeko jendeak erabakitzen zuen bileretan. Gertakariaren ikerketan ingeniari talde batek beti parte hartzen zuen. Ikerketa amaitu zenean, postmortem bat idatzi zuten -formatu elektroniko bidezko txosten moduko bat: zer gertatu zen, zenbat iraun zuen, zer egin genuen momentuan, zer egingo dugun etorkizunean-. 

Gunearen orrialde nagusiak edo nola ulertzen dugun hondoa jo dugula

 
Errorearen lehentasuna nolabait ulertzeko, negozioaren funtzionaltasunerako gune kritikoenak identifikatu ditugu. Horiek erabiliz, arrakastatsu/ez egindako eskaerak eta denbora-muga zenbatzen ditugu. Horrela neurtzen dugu funtzionamendu-denbora. 

Demagun jakin dugula guneko atal oso garrantzitsu batzuk daudela zerbitzu nagusiaz arduratzen direnak: iragarkiak bilatu eta bidaltzea. Huts egiten duten eskaeren kopurua % 1etik gorakoa bada, gertakari larria da. Prime time garaian 15 minuturen buruan errore-tasa % 0,1 gainditzen badu, hori ere gertakari kritikotzat hartzen da. Irizpide hauek gorabehera gehienak hartzen dituzte; gainontzekoak artikulu honen esparrutik kanpo daude.

Gorabehera onenak Cian

Beraz, behin betiko ikasi dugu gertakari bat gertatu zela zehazten. 

Orain gertakari bakoitza zehatz-mehatz deskribatzen da eta Jira epikoan islatzen da. Bide batez: horretarako aparteko proiektu bat hasi genuen, FAIL izenekoa - bertan epikak soilik sor daitezke. 

Azken urteotako porrot guztiak biltzen badituzu, liderrak hauek dira: 

• mssql erlazionatutako gorabeherak;
• kanpoko faktoreek eragindako gorabeherak;
• admin akatsak.

Azter ditzagun zehatzago administratzaileen akatsak, baita beste huts interesgarri batzuk ere.

Bosgarren postua - "Gauzak ordenan jartzea DNSn"

Astearte ekaitztsua zen. DNS klusterrean ordena berrezartzea erabaki genuen. 

Barneko DNS zerbitzariak bind-etik powerdns-era transferitu nahi nituen, horretarako zerbitzari guztiz bereiziak esleituz, non ez dagoen DNSa izan ezik. 

DNS zerbitzari bat jarri genuen gure DCen kokapen bakoitzean, eta unea iritsi zen zonak bind-etik powerdnetara mugitzeko eta azpiegitura zerbitzari berrietara aldatzeko. 

Mugimenduaren erdian, zerbitzari guztietan tokiko cache-ko loturak zehazten ziren zerbitzari guztien artean, bakarra geratu zen, San Petersburgoko datu-zentroan zegoena. DC hau hasiera batean ez-kritikoa zela deklaratu zen guretzat, baina bat-batean porrot puntu bakar bihurtu zen.
Lekualdatze garai horretan erori zen Mosku eta San Petersburgo arteko kanala. Egia esan, bost minutuz DNS gabe geratu ginen eta ostalariak arazoa konpondu zuenean berriro jaiki ginen. 

Ondorioak:

Lehen lana prestatzeko garaian kanpoko faktoreak alde batera utzi bazituen, orain prestatzen ari garen zerrendan ere sartzen dira. Eta orain osagai guztiak n-2 erreserbatuta daudela ziurtatzen ahalegintzen gara, eta lanean zehar maila hori n-1era jaitsi dezakegu.

• Ekintza-plan bat egitean, markatu zerbitzuak huts egin dezakeen puntuak, eta pentsatu aldez aurretik dena "txarretik okerrago" joan den eszenatoki bat.
• Banatu barneko DNS zerbitzariak geokokapen/datu zentro/rack/switches/sarrera desberdinetan.
• Zerbitzari bakoitzean, instalatu cacheko DNS zerbitzari lokal bat, eskaerak DNS zerbitzari nagusietara birbideratzen dituena, eta erabilgarri ez badago, cachetik erantzungo du. 

Laugarren postua - "Gauzak ordenatu Nginx-en"

Egun on batean, gure taldeak erabaki zuen "nahikoa izan dugula honetaz" eta nginx konfigurazioak birfaktorizatzeko prozesua hasi zen. Helburu nagusia konfigurazioak egitura intuitibo batera ekartzea da. Aurretik, dena "historikoki ezarrita" zegoen eta ez zuen inolako logikarik. Orain zerbitzari_izen bakoitza izen bereko fitxategi batera eraman da eta konfigurazio guztiak karpetetan banatu dira. Bide batez, konfigurazioak 253949 lerro edo 7836520 karaktere ditu eta ia 7 megabyte hartzen ditu. Egitura maila gorena: 

Nginx egitura

├── access
│   ├── allow.list
...
│   └── whitelist.conf
├── geobase
│   ├── exclude.conf
...
│   └── geo_ip_to_region_id.conf
├── geodb
│   ├── GeoIP.dat
│   ├── GeoIP2-Country.mmdb
│   └── GeoLiteCity.dat
├── inc
│   ├── error.inc
...
│   └── proxy.inc
├── lists.d
│   ├── bot.conf
...
│   ├── dynamic
│   └── geo.conf
├── lua
│   ├── cookie.lua
│   ├── log
│   │   └── log.lua
│   ├── logics
│   │   ├── include.lua
│   │   ├── ...
│   │   └── utils.lua
│   └── prom
│       ├── stats.lua
│       └── stats_prometheus.lua
├── map.d
│   ├── access.conf
│   ├── .. 
│   └── zones.conf
├── nginx.conf
├── robots.txt
├── server.d
│   ├── cian.ru
│   │   ├── cian.ru.conf
│   │   ├── ...
│   │   └── my.cian.ru.conf
├── service.d
│   ├── ...
│   └── status.conf
└── upstream.d
    ├── cian-mcs.conf
    ├── ...
    └── wafserver.conf

Askoz hobetu zen, baina konfigurazioen izena aldatzeko eta banatzeko prozesuan, horietako batzuek luzapen okerra zuten eta ez ziren include *.conf zuzentarauan sartu. Ondorioz, ostalari batzuk ez zeuden erabilgarri eta 301 orri nagusira itzuli ziren. Erantzun kodea 5xx/4xx ez zenez, hori ez zen berehala ohartu, goizean baizik. Horren ostean, azpiegituraren osagaiak egiaztatzeko probak idazten hasi ginen.

Ondorioak: 

• Egituratu zure konfigurazioak behar bezala (ez bakarrik nginx) eta pentsatu egitura proiektuaren hasierako fasean. Horrela, taldearentzat ulergarriagoak izango dira, eta horrek TTM murriztuko du.
• Azpiegiturako osagai batzuen probak idaztea. Adibidez: gako zerbitzari_izen guztiek egoera zuzena + erantzunaren gorputza ematen dutela egiaztatzea. Nahikoa izango da osagaiaren oinarrizko funtzioak egiaztatzen dituzten script batzuk eskuan edukitzea, 3:XNUMXetan amorruz gogoratzeko zer gehiago egiaztatu behar den. 

Hirugarren postua - "Bat-batean lekurik gabe geratu zen Cassandran"

Datuak etengabe hazi ziren, eta dena ondo egon zen Cassandra klusterrean kasu-espazio handien konponketa huts egiten hasi zen unera arte, trinkotzeak ezin zuelako haietan funtzionatu. 

Ekaitz egun batean, multzoa ia kalabaza bihurtu zen, hots:

• klusterrean espazio osoaren %20 inguru geratzen zen;
• Ezinezkoa da nodoak guztiz gehitzea, garbiketa ez delako pasatzen nodo bat gehitu ondoren partizioetan leku falta dela eta;
• produktibitatea pixkanaka jaisten da trinkotzeak funtzionatzen ez duen heinean; 
• Klusterra larrialdi moduan dago.

Irten - garbiketarik gabe 5 nodo gehiago gehitu genituen, ondoren klustertik sistematikoki kentzen eta berriro sartzen hasi ginen, lekurik gabe geratu ziren nodo hutsak bezala. Nahi baino askoz denbora gehiago eman zen. Klusterraren erabilgarritasun partziala edo osoa ez izateko arriskua zegoen. 

Ondorioak:

• Cassandra zerbitzari guztietan, partizio bakoitzeko espazioaren % 60 baino gehiago ez da okupatu behar. 
• Ez dira %50eko CPUan kargatu behar.
• Ez zenuke ahaztu behar gaitasunaren plangintzaz eta osagai bakoitzari buruz hausnartu behar duzu, bere berezitasunetan oinarrituta.
• Zenbat eta nodo gehiago klusterrean, orduan eta hobeto. Datu kopuru txikia duten zerbitzariak azkarrago gainkargatzen dira, eta kluster hori errazagoa da berpizten. 

Bigarren postua - "Kontsularen gako-balioaren biltegitik datuak desagertu dira"

Zerbitzua aurkitzeko, guk, askok bezala, kontsul erabiltzen dugu. Baina bere gako-balioa ere erabiltzen dugu monolitoaren diseinu urdin-berderako. Upstream aktibo eta inaktiboei buruzko informazioa gordetzen du, hedapenean lekuz aldatzen direnak. Horretarako, KVrekin elkarreragiten zuen hedapen-zerbitzu bat idatzi zen. Noizbait, KVren datuak desagertu egin ziren. Memoriatik berreskuratua, baina akats ugarirekin. Ondorioz, kargatzean, upstream-en karga modu irregularrean banatu zen, eta 502 errore asko jaso genituen CPUan gainkargatuta zeuden backendak. Ondorioz, kontsul KVtik postgresera pasatu ginen, eta hortik ez baita hain erraza kentzea.  

Ondorioak:

• Inolako baimenik gabeko zerbitzuek ez dute gunearen funtzionamendurako funtsezko daturik eduki behar. Esaterako, ES-en baimenik ez baduzu, hobe litzateke sare mailan sarbidea ukatzea beharrezkoa ez den toki guztietan, beharrezkoak direnak bakarrik utzi eta action.destructive_requires_name: egia ezartzea ere.
• Landu zure babeskopia eta berreskuratzeko mekanismoa aldez aurretik. Adibidez, egin aldez aurretik script bat (adibidez, Python-en) babeskopia eta leheneratu ahal izateko.

Lehen postua - "Captain Unobvious" 

Noizbait, kargaren banaketa irregularra nabaritu dugu nginx-en upstream-en backend-ean 10+ zerbitzari zeuden kasuetan. Round-robin-ek 1.etik azkenera igoerako eskaerak ordenan bidaltzen zituelako eta nginx birkargatu bakoitza berriro hasi zenez, lehenengo upstream-ek beti jasotzen zituzten gainerakoek baino eskaera gehiago.Ondorioz, motelago lan egiten zuten eta gune osoak sufritu zuen. Hau gero eta nabariagoa zen trafiko kopurua handitu ahala. Ausazko gaitzeko nginx eguneratzeak ez zuen funtzionatu - 1.15 bertsioan (momentu horretan) abiatzen ez zen lua kode mordo bat berregin behar dugu. Gure nginx 1.14.2 adabaki behar izan genuen, ausazko laguntza sartuz. Honek arazoa konpondu zuen. Akats honek "Captain Non-Obviousness" kategoria irabazten du.

Ondorioak:

Oso interesgarria eta zirraragarria izan zen akats hau aztertzea). 

• Antolatu zure jarraipena, hala nola, gorabeherak azkar aurkitzen lagunduko dizu. Adibidez, ELK erabil dezakezu upstream bakoitzaren backend bakoitzean rps monitorizatzeko, haien erantzun denbora nginx-en ikuspuntutik kontrolatzeko. Kasu honetan, honek arazoa identifikatzen lagundu digu. 

Ondorioz, hutsegite gehienak saihestu zitezkeen egiten ari zinenaren ikuspegi zorrotzago batekin. Beti gogoratu behar dugu Murphyren legea: Gaizki joan daitekeen edozer gaizki aterako da, eta horretan oinarritutako osagaiak eraiki. 

Iturria: www.habr.com