🥇Çîrokên herî baş ên Cian

Hemî xweş!

Navê min Nikita ye, ez serokê tîmê tîmê endezyariya Cian me. Yek ji berpirsiyariyên min ên li pargîdaniyê ew e ku hejmara bûyerên ku bi binesaziya hilberînê ve girêdayî ne kêm bikim.
Ya ku dê li jêr were nîqaş kirin gelek êş ji me re aniye, û mebesta vê gotarê ew e ku rê li ber kesên din bigire ku xeletiyên me dubare nekin an bi kêmanî bandora wan kêm bikin.

Preamble

Demek dirêj berê, dema ku Cyan ji monolîtan pêk dihat, û hîna îşaretên mîkroservîsan tune bûn, me hebûna çavkaniyekê bi kontrolkirina 3-5 rûpelan pîv kir.

Ew bersiv didin - her tişt baş e, heke ew ji bo demek dirêj bersiv nedin - hişyar. Ji bo ku ev bûyer wekî bûyer were hesibandin, di civînan de biryar ji aliyê mirovan ve hat dayîn. Tîmek endezyaran her tim tevlî lêkolîna bûyerê bû. Dema ku vekolîn qediya, wan postmortemek nivîsand - celebek raporek bi e-nameyê di vê formê de: çi qewimî, çiqas dom kir, me di vê gavê de çi kir, em ê di pêşerojê de çi bikin.

Rûpelên sereke yên malperê an jî em çawa fam dikin ku me li binê xwe xistiye

Ji bo ku em bi rengek pêşîya xeletiyê fam bikin, me rûpelên malperê yên herî krîtîk ji bo fonksiyona karsaziyê nas kirine. Bi karanîna wan, em hejmara daxwazên serketî / neserkeftî û demjimaran dihejmêrin. Bi vî rengî em dema xebatê dipîvin.

Ka em bibêjin me fêhm kir ku hejmarek beşên pir girîng ên malperê hene ku berpirsiyariya karûbarê sereke ne - lêgerîn û şandina reklaman. Ger hejmara daxwazên ku bi ser nekevin ji 1%, ev bûyerek krîtîk e. Ger di nav 15 hûrdeman de di dema sereke de rêjeya xeletiyê ji% 0,1 derbas bibe, wê hingê ev jî wekî bûyerek krîtîk tê hesibandin. Van pîvanan piraniya bûyeran vedihewîne;

Top best bûyerên Cian

Ji ber vê yekê, em bê guman fêr bûne ku rastiya bûyerek qewimî diyar bikin.

Niha her bûyerek bi berfirehî tê vegotin û di dastana Jîra de xuya dike. Bi awayê: ji bo vê yekê me projeyek cihê dest pê kir, jê re FAIL tê gotin - tenê epîk dikarin tê de werin afirandin.

Ger hûn hemî têkçûnên çend salên borî berhev bikin, serok ev in:

bûyerên girêdayî mssql;
bûyerên ku ji hêla faktorên derveyî ve têne çêkirin;
çewtiyên admin.

Ka em bi hûrgulî li xeletiyên rêvebiran, û hem jî li hin têkçûnên din ên balkêş binêrin.

Cihê pêncemîn - "Di DNS-ê de tiştan rêz kirin"

Sêşemeke bahoz bû. Me biryar da ku em rêzê di koma DNS de vegerînin.

Min dixwest ku serverên DNS-ya navxweyî ji bind-ê veguhezînim powerdns, ji bo vê yekê serverên bi tevahî veqetandî veqetînim, li wir ji bilî DNS-ê tiştek tune.

Me serverek DNS li her cîhê DC-yên xwe bi cîh kir, û dem hat ku em deveran ji bind berbi powerdns veguhezînin û binesaziyê veguherînin serverên nû.

Di nav tevgerê de, ji her tiştî pêşkêşkerênJi serverên ku di girêdanên caching ên herêmî de hatine destnîşankirin, tenê yek ma - ya li navenda daneyan a St. Petersburg. Ev navenda daneyan di destpêkê de ji bo me ne krîtîk hate ragihandin, lê ji nişkê ve bû xalek têkçûnê ya yekane.
Di vê serdema veguhêztinê de bû ku kanala di navbera Moskow û St. Petersburgê de qut bû. Em bi bandor pênc deqeyan bê DNS man û dema ku em baş bûn, em baş bûn. mêvandar pirsgirêkan çareser kir.

Encamên

Ger berê me di dema amadekirina xebatê de faktorên derveyî paşguh kir, naha ew jî di navnîşa tiştên ku em ji bo wan amade dikin de cih digirin. Naha em hewl didin ku pê ewle bibin ku hemî pêkhate n-2 veqetandî ne, û di dema xebatê de em dikarin vê astê daxin n-1.

Dema ku plansaziyek çalakiyê amade dikin, xalên ku dibe ku karûbar têk biçe nîşan bikin, û li ser senaryoyek bifikirin ku her tişt di pêş de "ji xirab ber bi xirabtir" ve çû.
Pêşkêşkerên DNS-ê yên hundurîn li ser erdnîgarî / navendên daneyê / racks / guheztin / têketinên cihêreng belav bikin.
Li ser her serverê, serverek DNS-a caching-a herêmî saz bikin, ku daxwazan ber bi serverên sereke yên DNS-ê veguhezîne, û heke ew tune be, ew ê ji cache-ê bersivê bide.

Cihê çaremîn - "Paqijkirina tiştan li Nginx"

Rojek xweş, tîmê me biryar da ku "me têra vê yekê kiriye," û pêvajoya veavakirina mîhengên nginx dest pê kir. Armanca sereke ew e ku mîhengan bigihîne avahiyek întuitive. Berê, her tişt "dîrokî" bû û tu mantiqê nedigirt. Naha her server_name li pelek bi heman navî hate veguheztin û hemî vesazkirin di peldankan de hatine belav kirin. Bi awayê, konfigurasyon 253949 rêzan an 7836520 karakteran dihewîne û hema hema 7 megabyte digire. Asta jorîn a strukturê:

Struktura Nginx

├── 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

Ew pir çêtir bû, lê di pêvajoya nav û belavkirina mîhengan de, hin ji wan xwedan dirêjkirina xelet bûn û ne di nav rêwerznameya *.conf de bûn. Wekî encamek, hin mêvandar neçar bûn û 301 vegeriyan rûpela sereke. Ji ber ku koda bersivê ne 5xx/4xx bû, ev yek tavilê nehate dîtin, lê tenê serê sibê. Piştî wê, me dest bi nivîsandina testan kir da ku hêmanên binesaziyê kontrol bikin.

Encamên

Mîhengên xwe rast ava bikin (ne tenê nginx) û di qonaxek destpêkê ya projeyê de bi strukturê bifikirin. Bi vî rengî hûn ê wan ji tîmê re bêtir fêm bikin, ku di encamê de dê TTM kêm bike.
Ji bo hin pêkhateyên binesaziyê ceribandinan binivîsin. Mînakî: kontrol bikin ku hemî navên server_yên sereke statûya rast + laşê bersivê didin. Dê bes be ku tenê çend nivîsar li ber destan hebin ku fonksiyonên bingehîn ên pêkhateyê kontrol dikin, da ku di demjimêr 3 danê sibê de bi dilşikestî neyê bîra we, ya din çi hewce dike ku were kontrol kirin.

Cihê sêyem - "Li Cassandra ji nişka ve ji cîh derket"

Daneyên bi domdarî mezin dibûn, û her tişt baş bû heya wê gavê ku tamîrkirina cîhên dozên mezin di koma Cassandra de dest pê kir têk çû, ji ber ku berhevkirin nekarî li ser wan bixebite.

Rojek bahoz, kom hema hema bû kumek, bi navî:

ji sedî 20 ê cîhê giştî yê di komê de mabû;
Ne gengaz e ku meriv bi tevahî girêkan lê zêde bike, ji ber ku ji ber kêmbûna cîhê li ser dabeşan piştî lê zêdekirina girêkekê paqijî derbas nabe;
berberî gav bi gav dadikeve ji ber ku komkirin nexebite;
Kom di moda acîl de ye.

Derketin - me 5 girêkên din bêyî paqijkirin lê zêde kir, pişt re me dest bi birêkûpêk derxistina wan ji komê kir û ji nû ve têkevin wan, mîna girêkên vala yên ku ji cîhê xwe xilas bûne. Ji ya ku em dixwazin pir zêdetir dem derbas bû. Metirsiya tunebûna qismî an bi tevahî ya komê hebû.

Encamên

Li ser hemî pêşkêşkerên cassandra, divê ji% 60-ê cîhê li ser her dabeşkirinê neyê dagîr kirin.
Pêdivî ye ku ew ji% 50 cpu ne bêtir werin barkirin.
Pêdivî ye ku hûn plansaziya kapasîteyê ji bîr nekin û pêdivî ye ku hûn li ser her pêkhateyê, li gorî taybetmendiyên wê, bifikirin.
Di komê de girêkên zêdetir, baştir. Pêşkêşkerên ku hejmareke piçûk a daneyê vedihewînin zûtir têne barkirin, û komek wusa ji nû ve vejandina hêsantir e.

Cihê duyemîn - "Daneyên ji hilanîna key-nirxa konsulê winda bûne"

Ji bo vedîtina karûbarê, em, mîna gelekan, konsul bikar tînin. Lê em nirxa wê ya sereke jî ji bo sêwirana şîn-kesk a monolîtê bikar tînin. Ew agahdariya li ser jorînên çalak û neçalak, yên ku di dema bicîhkirinê de cîh diguhezînin hilîne. Ji bo vê armancê, karûbarek belavkirinê hate nivîsandin ku bi KV re têkilî danî. Di demekê de, daneyên KV winda bûn. Ji bîranînê hate vegerandin, lê bi çend xeletiyan. Wekî encamek, di dema barkirinê de, barkirina li ser jorîn bi rengek neyeksan hate belav kirin, û me ji ber barkirina paşîn li ser CPU-yê gelek xeletiyên 502 wergirtin. Wekî encamek, me ji konsulê KV bar kir postgres, ji ku derê rakirina wan êdî ne ew qas hêsan e.

Encamên

Karûbarên bêyî destûrnameyê divê daneyên ku ji bo xebata malperê krîtîk nebin. Mînakî, heke di ES-ê de destûrnameya we tune be, çêtir e ku hûn gihîştina di asta torê de ji her deverê ku ne hewce ye red bikin, tenê yên pêwîst bihêlin, û her weha action.destructive_requires_name: rast jî bicîh bikin.
Mekanîzmaya hilanînê û vegerandina xwe di pêş de pratîk bikin. Mînakî, di pêş de skrîptek çêbikin (mînakî, di python de) ku dikare piştgir û sererast bike.

Cihê yekem - "Captain Unobvious"

Di hin xalan de, me di rewşên ku di paşperdeya paşîn de zêdetirî 10 pêşkêşker hebûn, belavbûnek neyeksan a barkirinê li ser jorînên nginx dît. Ji ber vê yekê ku dor-robin daxwaz ji 1-ê heya paşîn a paşîn bi rêz şandin, û her nûvekirina nginx ji nû ve dest pê kir, jorînên pêşîn her gav ji yên din bêtir daxwaz distînin Wekî encamek, ew hêdîtir xebitîn û hemî malper zirar dît . Ev yek her ku diçe zêde xuya dibû her ku diçe rêjeya trafîkê zêde dibe. Tenê nûvekirina nginx-ê ji bo çalakkirina random nexebitî - pêdivî ye ku em komek koda lua-ya ku di guhertoya 1.15-ê de derneketiye (di wê gavê de) ji nû ve bikin. Diviya bû ku me nginx 1.14.2-ya xwe patch bikira, piştgirîya rasthatî têxe nav wê. Vê yekê pirsgirêk çareser kir. Ev xelet di kategoriya "Captain Non-Obviousness" de qezenc dike.

Encamên

Vekolîna vê xeletiyê pir balkêş û heyecan bû).

Çavdêriya xwe organîze bikin da ku ew ji we re bibe alîkar ku hûn zû guheztinên weha bibînin. Mînakî, hûn dikarin ELK-ê bikar bînin da ku rps li ser her paşîn a her jorîn bişopînin, dema bersivdana wan ji hêla nginx ve bişopînin. Di vê rewşê de, ev alîkariya me kir ku pirsgirêk nas bikin.

Wekî encamek, piraniya têkçûnan dikaribû bi nêzîkatiyek hûrgulî ya ku we dikir ji holê rakira. Divê em her gav qanûna Murphy bi bîr bînin: Tiştê ku dikare xelet bibe dê xelet bibe, û li ser bingeha wê pêkhateyan ava bikin.

Source: www.habr.com