Kepiye cara telusuran Yandex.Market lan apa sing kedadeyan yen salah sawijining server gagal

Halo, jenengku Evgeniy. Aku kerja ing infrastruktur telusuran Yandex.Market. Aku pengin ngandhani komunitas Habr babagan pawon ing Pasar - lan akeh sing dakkandhakake. Kaping pisanan, kepiye cara kerja, proses lan arsitektur Pasar. Kepiye cara ngatasi kahanan darurat: apa sing kedadeyan yen siji server mudhun? Apa yen ana 100 server kasebut?

Sampeyan uga bakal sinau carane kita ngleksanakake fungsi anyar ing Bunch saka server bebarengan. Lan carane kita nyoba layanan Komplek langsung ing produksi, tanpa nyebabake ora nyaman kanggo pangguna. Umumé, carane telusuran Pasar bisa dianggo supaya saben wong duwe wektu sing apik.

A little bab kita: apa masalah kita ngatasi

Nalika sampeyan ngetik teks, nelusuri produk miturut paramèter, utawa mbandhingaké prices ing toko beda, kabeh panjalukan dikirim menyang layanan search. Panelusuran minangka layanan paling gedhe ing Pasar.

Kita ngolah kabeh panjaluk telusuran: saka situs market.yandex.ru, beru.ru, layanan Supercheck, Yandex.Advisor, aplikasi seluler. Kita uga kalebu tawaran produk ing asil panelusuran ing yandex.ru.

Miturut layanan telusuran Maksudku ora mung telusuran dhewe, nanging uga database karo kabeh tawaran ing Pasar. Skala iki: luwih saka milyar panjalukan panelusuran diproses saben dina. Lan kabeh kudu cepet, tanpa gangguan lan tansah ngasilake asil sing dikarepake.

Apa apa: arsitektur pasar

Aku bakal njlèntrèhaké sedhela arsitektur Market saiki. Kira-kira bisa diterangake kanthi diagram ing ngisor iki:

Ayo dadi toko partner teka kanggo kita. Kandhane aku arep dodolan dolanan: kucing jahat iki karo squeaker. Lan kucing nesu liyane tanpa squeaker. Lan mung kucing. Banjur toko kudu nyiapake tawaran sing ditelusuri Pasar. Toko ngasilake xml khusus karo tawaran lan komunikasi dalan menyang xml iki liwat antarmuka afiliasi. Indexer banjur ngundhuh xml iki kanthi periodik, mriksa kesalahan lan nyimpen kabeh informasi menyang database gedhe.

Ana akeh xml sing disimpen. Indeks telusuran digawe saka database iki. Indeks disimpen ing format internal. Sawise nggawe indeks, layanan Layout diunggah menyang server telusuran.

Akibaté, kucing duka karo squeaker katon ing database, lan indeks kucing katon ing server.

Aku bakal pitutur marang kowe carane kita nggoleki kucing ing bagean babagan arsitektur panelusuran.

arsitektur panelusuran pasar

Kita manggon ing jagad layanan mikro: saben panjaluk sing mlebu market.yandex.ru nimbulaké akèh subqueries, lan Welasan layanan melu Processing sing. Diagram kasebut mung nuduhake sawetara:

Skema pangolahan panjaluk sing disederhanakake

Saben layanan duwe barang sing apik - penyeimbang dhewe kanthi jeneng unik:

Balance menehi keluwesan sing luwih gedhe kanggo ngatur layanan: sampeyan bisa, contone, mateni server, sing asring dibutuhake kanggo nganyari. Balancer ndeleng manawa server ora kasedhiya lan kanthi otomatis ngarahake panjaluk menyang server utawa pusat data liyane. Nalika nambah utawa mbusak server, beban kasebut kanthi otomatis disebarake ing antarane server.

Jeneng unik saka balancer ora gumantung ing pusat data. Nalika layanan A njaluk panjalukan kanggo B, banjur kanthi gawan balancer B pangalihan panjalukan kanggo pusat data saiki. Yen layanan ora kasedhiya utawa ora ana ing pusat data saiki, panjaluk kasebut dialihake menyang pusat data liyane.

FQDN siji kanggo kabeh pusat data ngidini layanan A rampung abstrak saka lokasi. Panjaluke kanggo layanan B mesthi bakal diproses. Pangecualian yaiku nalika layanan kasebut ana ing kabeh pusat data.

Nanging ora kabeh dadi rosy karo balancer iki: kita duwe komponen penengah tambahan. Balance bisa uga ora stabil, lan masalah iki ditanggulangi dening server sing berlebihan. Ana uga wektu tundha tambahan antarane layanan A lan B. Nanging ing laku iku kurang saka 1 ms lan kanggo paling layanan iki ora kritis.

Nanggulangi sing Ora Dikarepke: Telusuri Balancing lan Ketahanan Layanan

Mbayangno yen ana ambruk: sampeyan kudu nemokake kucing kanthi squeaker, nanging server nabrak. Utawa 100 server. Carane metu? Apa kita pancene bakal ninggalake pangguna tanpa kucing?

Kahanan iki medeni, nanging kita siyap. Aku bakal ngandhani sampeyan kanthi urutan.

Infrastruktur telusuran dumunung ing sawetara pusat data:

Nalika ngrancang, kita kalebu kamungkinan mateni siji pusat data. Urip kebak kejutan - contone, excavator bisa ngethok kabel lemah (ya, kedadeyan kasebut). Kapasitas ing pusat data sing isih ana kudu cukup kanggo nahan beban puncak.

Ayo nimbang pusat data siji. Saben pusat data duwe skema operasi balancer sing padha:

Siji balancer paling ora telung server fisik. Redundansi iki digawe kanggo linuwih. Balancers mbukak ing HAProx.

Kita milih HAProx amarga kinerja dhuwur, syarat sumber daya kurang lan fungsi sudhut. Piranti lunak telusuran kita mlaku ing saben server.

Kemungkinan salah siji server gagal sithik. Nanging yen sampeyan duwe akeh server, kemungkinan sing paling siji bakal mudhun mundhak.

Iki kedadeyan ing kasunyatan: server crash. Mulane, perlu kanggo terus-terusan ngawasi status kabeh server. Yen server mandheg nanggapi, iku kanthi otomatis pedhot saka lalu lintas. Kanggo tujuan iki, HAProxy duwe pemeriksaan kesehatan sing dibangun. Iku menyang kabeh server sapisan detik karo panjalukan HTTP "/ ping".

Fitur HAProxy liyane: mriksa agen ngidini sampeyan mbukak kabeh server kanthi merata. Kanggo nindakake iki, HAProxy nyambung menyang kabeh server, lan padha bali bobot gumantung ing mbukak saiki saka 1 kanggo 100. Bobot wis diwilang adhedhasar nomer panjalukan ing antrian kanggo Processing lan mbukak ing prosesor.

Saiki babagan golek kucing. Hasil panelusuran ing panjalukan kaya: /search?text=angry+cat. Supaya telusuran dadi cepet, kabeh indeks kucing kudu pas karo RAM. Malah maca saka SSD ora cukup cepet.

Biyen, database tawaran cilik, lan RAM siji server cukup kanggo. Nalika basis tawaran tansaya tambah, kabeh ora pas karo RAM iki, lan data dipérang dadi rong bagéan: shard 1 lan shard 2.

Nanging iki mesthi kedadeyan: solusi apa wae, sanajan sing apik, nyebabake masalah liyane.

Balance tetep menyang server apa wae. Nanging ing mesin ngendi panjalukan teka, ana mung setengah saka indeks. Liyane ana ing server liyane. Mulane, server kudu pindhah menyang sawetara mesin tetanggan. Sawise nampa data saka loro server, asil digabungake lan reranked.

Wiwit balancer mbagekke panjalukan roto-roto, kabeh server padha melu re-ranking, lan ora mung ngirim data.

Masalah kasebut kedadeyan yen server tetanggan ora kasedhiya. Solusi kasebut yaiku nemtokake sawetara server kanthi prioritas sing beda-beda minangka server "tangga". Kaping pisanan, panjaluk kasebut dikirim menyang server ing rak saiki. Yen ora ana respon, panjaluk kasebut dikirim menyang kabeh server ing pusat data iki. Lan pungkasane, panjaluk kasebut menyang pusat data liyane.
Nalika jumlah proposal saya tambah, data kasebut dipérang dadi patang bagean. Nanging iki ora dadi watesan.

Saiki, konfigurasi wolung shards digunakake. Kajaba iku, kanggo ngirit memori luwih akeh, indeks kasebut dipérang dadi bagean telusuran (sing digunakake kanggo nggoleki) lan bagean snippet (sing ora melu telusuran).

Siji server ngemot informasi mung siji shard. Mulane, kanggo nggoleki indeks lengkap, sampeyan kudu nggoleki ing wolung server sing ngemot shards beda.

Server diklompokaké dadi kluster. Saben kluster ngemot wolung mesin telusur lan siji server snippet.

Server snippet mbukak database nilai kunci kanthi data statis. Padha dibutuhake kanggo ngetokake dokumen, contone, katrangan kucing karo squeaker. Data kasebut ditransfer khusus menyang server sing kapisah supaya ora mbukak memori server telusuran.

Amarga ID dokumen unik mung ing siji indeks, kahanan bisa kedadeyan yen ora ana dokumen ing cuplikan kasebut. Ya, utawa yen kanggo siji ID bakal ana konten sing beda. Mula, supaya telusuran bisa ditindakake lan ngasilake asil, perlu konsistensi ing kabeh kluster. Aku bakal pitutur marang kowe ing ngisor iki carane kita ngawasi konsistensi.

Panelusuran dhewe disusun kaya mangkene: panjaluk telusuran bisa teka ing wolung server. Ayo dadi ngomong dheweke teka menyang server 1. Server iki ngolah kabeh bantahan lan ngerti apa lan carane goleki. Gumantung ing panjalukan sing mlebu, server bisa nggawe panjalukan tambahan menyang layanan eksternal kanggo informasi sing dibutuhake. Siji panjalukan bisa diterusake nganti sepuluh panjalukan menyang layanan eksternal.

Sawise ngumpulake informasi sing dibutuhake, telusuran diwiwiti ing database tawaran. Kanggo nindakake iki, subqueries digawe kanggo kabeh wolung server ing kluster.

Sawise respon ditampa, asil digabungake. Pungkasane, sawetara subquery liyane menyang server snippet bisa uga dibutuhake kanggo ngasilake asil.

Pitakon telusuran ing kluster katon kaya: /shard1?text= duka+kucing. Kajaba iku, subquery saka formulir terus-terusan digawe ing antarane kabeh server ing kluster sapisan sapisan: /status.

Panjaluk /status ndeteksi kahanan sing server ora kasedhiya.

Iki uga ngontrol manawa versi mesin telusur lan versi indeks padha ing kabeh server, yen ora bakal ana data sing ora konsisten ing kluster kasebut.

Senadyan kasunyatan manawa siji server snippet ngolah panjaluk saka wolung mesin telusur, prosesor kasebut dimuat kanthi entheng. Mulane, saiki kita nransfer data cuplikan menyang layanan sing kapisah.

Kanggo nransfer data, kita ngenalake kunci universal kanggo dokumen. Saiki mokal kanggo kahanan ing ngendi isi saka dokumen liyane bali nggunakake siji tombol.

Nanging transisi menyang arsitektur liyane durung rampung. Saiki kita pengin nyisihake server snippet darmabakti. Banjur pindhah saka struktur kluster kabeh. Iki bakal ngidini kita terus ukuran kanthi gampang. Bonus tambahan yaiku tabungan wesi sing signifikan.

Lan saiki crita medeni karo happy endings. Ayo nimbang sawetara kasus server ora kasedhiya.

Ana kedadeyan sing nggegirisi: siji server ora kasedhiya

Ayo dadi siji server ora kasedhiya. Banjur server sing isih ana ing kluster bisa terus nanggapi, nanging asil panelusuran bakal ora lengkap.

Via mriksa status /status server tetanggan ngerti sing siji ora kasedhiya. Mulane, kanggo njaga jangkep, kabeh server ing kluster saben request /ping padha wiwiti nanggapi balancer sing padha uga kasedhiya. Pranyata kabeh server ing kluster mati (sing ora bener). Iki minangka kekurangan utama skema kluster kita - mula kita pengin nyingkiri.

Panyuwunan sing gagal amarga kesalahan bakal diganggu dening balancer ing server liyane.
Balancer uga mandheg ngirim lalu lintas pangguna menyang server mati, nanging terus mriksa statuse.

Nalika server kasedhiya, wiwit nanggapi /ping. Sanalika respon normal kanggo ping saka server mati wiwit teka, balancers wiwit ngirim lalu lintas pangguna ana. Operasi cluster dibalekake, hore.

Luwih elek: akeh server sing ora kasedhiya

Sebagéyan penting saka server ing pusat data dipotong. Apa sing kudu ditindakake, menyang ngendi arep mlayu? Balance teka kanggo ngluwari maneh. Saben balancer terus-terusan nyimpen ing memori jumlah server urip saiki. Iku terus ngetung jumlah maksimum lalu lintas sing pusat data saiki bisa proses.

Nalika akeh server ing pusat data mudhun, balancer nyadari yen pusat data iki ora bisa ngolah kabeh lalu lintas.

Banjur keluwihan lalu lintas wiwit disebarake kanthi acak menyang pusat data liyane. Kabeh bisa, kabeh seneng.

Kepiye carane: nerbitake rilis

Saiki ayo ngomong babagan carane nerbitake owah-owahan sing digawe kanggo layanan kasebut. Ing kene kita wis njupuk dalan kanggo nyederhanakake proses: ngluncurake rilis anyar meh rampung otomatis.
Nalika sawetara owah-owahan diklumpukake ing proyek kasebut, rilis anyar digawe kanthi otomatis lan mbangun diwiwiti.

Banjur layanan kasebut diluncurake kanggo nyoba, ing ngendi stabilitas operasi dicenthang.

Ing wektu sing padha, tes kinerja otomatis diluncurake. Iki ditangani dening layanan khusus. Aku ora bakal ngomong babagan saiki - deskripsi kasebut pantes kanggo artikel sing kapisah.

Yen publikasi ing testing kasil, publikasi release ing prestable otomatis diwiwiti. Prestable minangka kluster khusus ing ngendi lalu lintas pangguna normal diarahake. Yen ngasilake kesalahan, balancer nggawe panjalukan maneh kanggo produksi.

Ing prestable, wektu nanggepi diukur lan dibandhingake karo release sadurungé ing produksi. Yen kabeh apik, mula ana wong sing nyambung: mriksa grafik lan asil tes beban lan banjur miwiti produksi.

Kabeh sing paling apik kanggo pangguna: A/B testing

Ora mesthi ketok apa owah-owahan ing layanan bakal nggawa keuntungan nyata. Kanggo ngukur kegunaan saka owah-owahan, wong teka karo testing A/B. Aku bakal ngandhani sethithik babagan cara kerjane ing panelusuran Yandex.Market.

Iku kabeh diwiwiti karo nambah parameter CGI anyar sing mbisakake fungsi anyar. Ayo parameter kita dadi: market_new_functionality=1. Banjur ing kode, kita ngaktifake fungsi iki yen ana gendera:

If (cgi.experiments.market_new_functionality) {
// enable new functionality
}

Fungsi anyar diluncurake menyang produksi.

Kanggo ngotomatisasi tes A/B, ana layanan khusus sing nyedhiyakake informasi rinci diterangake ing kene. Eksperimen digawe ing layanan kasebut. Pangsa lalu lintas disetel, contone, 15%. Persentase disetel ora kanggo pitakon, nanging kanggo pangguna. Durasi eksperimen uga dituduhake, contone, seminggu.

Sawetara eksperimen bisa ditindakake bebarengan. Ing setelan sampeyan bisa nemtokake manawa persimpangan karo eksperimen liyane bisa.

Akibaté, layanan kanthi otomatis nambah argumen market_new_functionality=1 kanggo 15% pangguna. Uga kanthi otomatis ngetung metrik sing dipilih. Sawise eksperimen rampung, analis ndeleng asil lan nggawe kesimpulan. Adhedhasar temuan kasebut, keputusan digawe kanggo ngasilake produksi utawa panyulingan.

Tangan deft pasar: testing ing produksi

Asring kedadeyan yen sampeyan kudu nyoba operasi fungsi anyar ing produksi, nanging sampeyan ora yakin carane bakal nindakake ing "pertempuran" kahanan ing beban abot.

Ana solusi: gendera ing paramèter CGI bisa digunakake ora mung kanggo testing A / B, nanging uga kanggo nyoba fungsi anyar.

Kita nggawe alat sing ngidini sampeyan ngganti konfigurasi kanthi cepet ing ewonan server tanpa menehi risiko kanggo layanan kasebut. Iki diarani "Stop Tap". Ide asli yaiku bisa mateni sawetara fungsi kanthi cepet tanpa tata letak. Banjur alat ditambahi lan dadi luwih rumit.

Diagram alur layanan ditampilake ing ngisor iki:

Nilai gendera disetel liwat API. Layanan manajemen nyimpen nilai kasebut ing database. Kabeh server pindhah menyang database sapisan saben sepuluh detik, kumpa metu nilai gendera lan aplikasi nilai iki kanggo saben request.

Ing tunyuk Stop sampeyan bisa nyetel rong jinis nilai:

1) Ekspresi kahanan. Aplikasi nalika salah sawijining nilai bener. Tuladhane:

{
	"condition":"IS_DC1",
	"value":"3",
}, 
{
	"condition": "CLUSTER==2 and IS_BERU", 
	"value": "4!" 
}

Nilai "3" bakal ditrapake nalika panyuwunan diproses ing lokasi DC1. Lan nilai "4" nalika panjalukan diproses ing kluster kapindho kanggo situs beru.ru.

2) Nilai tanpa syarat. Aplikasi kanthi gawan yen ora ana syarat sing ditemoni. Tuladhane:

nilai, nilai!

Yen nilai dipungkasi kanthi tanda seru, bakal diwenehi prioritas sing luwih dhuwur.

Parser parameter CGI ngurai URL. Banjur ditrapake nilai saka Stop Tap.

Nilai kanthi prioritas ing ngisor iki ditrapake:

1. Kanthi tambah prioritas saka Stop Tap (tandha seru).
2. Nilai saka panjalukan.
3. Nilai standar saka Stop tunyuk.
4. Nilai standar ing kode.

Ana akeh panji sing dituduhake ing nilai kondisional - cukup kanggo kabeh skenario sing kita kenal:

• Pusat data.
• Lingkungan: produksi, pengujian, bayangan.
• Panggonan: pasar, beru.
• Nomer klaster.

Kanthi alat iki, sampeyan bisa ngaktifake fungsi anyar ing klompok server tartamtu (contone, mung ing siji pusat data) lan nyoba operasi fungsi iki tanpa resiko tartamtu kanggo kabeh layanan. Sanajan sampeyan nggawe kesalahan serius ing endi wae, kabeh wiwit tiba lan kabeh pusat data mudhun, balancers bakal ngarahake panjalukan menyang pusat data liyane. Pangguna pungkasan ora bakal weruh apa-apa.

Yen sampeyan ngelingi masalah, sampeyan bisa langsung bali gendéra menyang Nilai sadurungé lan owah-owahan bakal mbalek maneh.

Layanan iki uga duwe kekurangan: para pangembang seneng banget lan asring nyoba nyurung kabeh owah-owahan menyang Stop Tap. Kita nyoba kanggo nglawan penyalahgunaan.

Pendekatan Stop Tap bisa digunakake nalika sampeyan wis duwe kode stabil sing siap diluncurake menyang produksi. Ing wektu sing padha, sampeyan isih duwe keraguan, lan sampeyan pengin mriksa kode kasebut ing kahanan "pertempuran".

Nanging, Stop Tap ora cocog kanggo nyoba sajrone pangembangan. Ana kluster kapisah kanggo pangembang sing diarani "kluster bayangan".

Testing Rahasia: Kluster Shadow

Panjaluk saka salah siji kluster diduplikasi menyang kluster bayangan. Nanging balancer rampung nglirwakake respon saka klompok iki. Diagram operasi kasebut ditampilake ing ngisor iki.

We njaluk kluster test sing ana ing kondisi "pertempuran" nyata. Lalu lintas pangguna normal ana. Hardware ing loro kluster padha, supaya kinerja lan kasalahan bisa dibandhingake.

Lan wiwit balancer rampung nglirwakake respon, pangguna pungkasan ora bakal weruh respon saka kluster bayangan. Mulane, iku ora medeni kanggo nggawe kesalahan.

temonan

Dadi, kepiye carane nggawe panelusuran Pasar?

Supaya kabeh bisa lancar, kita misahake fungsi dadi layanan sing kapisah. Kanthi cara iki, kita mung bisa nggedhekake komponen sing dibutuhake lan nggawe komponen luwih gampang. Gampang kanggo nemtokake komponen sing kapisah menyang tim liyane lan nuduhake tanggung jawab kanggo nggarap. Lan tabungan pinunjul ing wesi karo pendekatan iki plus ketok.

Kluster bayangan uga mbantu kita: kita bisa ngembangake layanan, nyoba ing proses kasebut lan ora ngganggu pangguna.

Ya, tes ing produksi, mesthi. Kudu ngganti konfigurasi ing ewu server? Gampang, gunakake Stop Tap. Kanthi cara iki, sampeyan bisa langsung muter solusi kompleks sing wis siap lan muter maneh menyang versi stabil yen ana masalah.

Mugi aku bisa kanggo nuduhake carane kita nggawe Market cepet lan stabil karo basis tau-akeh tawaran. Kepiye cara ngatasi masalah server, ngatasi panjaluk sing akeh, nambah keluwesan layanan lan nindakake iki tanpa ngganggu proses kerja.

Source: www.habr.com