Hei, nimeni on Evgeniy. Työskentelen Yandex.Market-hakuinfrastruktuurissa. Haluan kertoa Habr-yhteisölle Marketin sisäkeittiöstä - ja minulla on paljon kerrottavaa. Ensinnäkin Market Searchin toiminta, prosessit ja arkkitehtuuri. Miten toimimme hätätilanteissa: mitä tapahtuu, jos yksi palvelin kaatuu? Entä jos tällaisia palvelimia on 100?
Opit myös kuinka toteutamme uusia toimintoja useilla palvelimilla kerralla. Ja kuinka testaamme monimutkaisia palveluita suoraan tuotannossa aiheuttamatta käyttäjille haittaa. Yleisesti ottaen Market-haku toimii niin, että kaikilla on hauskaa.
Hieman meistä: minkä ongelman ratkaisemme
Kun kirjoitat tekstiä, etsit tuotetta parametreillä tai vertailet hintoja eri myymälöissä, kaikki pyynnöt lähetetään hakupalveluun. Haku on markkinoiden suurin palvelu.
Käsittelemme kaikki hakupyynnöt: sivustoilta market.yandex.ru, beru.ru, Supercheck-palvelusta, Yandex.Advisorista, mobiilisovelluksista. Sisällytämme myös tuotetarjoukset yandex.ru-sivuston hakutuloksiin.
Hakupalvelulla en tarkoita pelkästään itse hakua, vaan myös tietokantaa kaikista Marketin tarjouksista. Mittakaava on tämä: yli miljardi hakupyyntöä käsitellään päivässä. Ja kaiken pitäisi toimia nopeasti, ilman keskeytyksiä ja tuottaa aina haluttu tulos.
Mikä on mitä: Markkina-arkkitehtuuri
Kuvaan lyhyesti Marketin nykyistä arkkitehtuuria. Sitä voidaan kuvata karkeasti alla olevalla kaaviolla:
Oletetaan, että kumppanikauppa tulee meille. Hän sanoo, että haluan myydä lelun: tämän ilkeän kissan vinkujalla. Ja toinen vihainen kissa ilman vinkujaa. Ja vain kissa. Sitten kaupan on valmisteltava tarjouksia, joita Market etsii. Kauppa luo erityisen xml-tiedoston tarjouksista ja välittää polun tähän xml-tiedostoon kumppaniliittymän kautta. Indeksoija lataa ajoittain tämän xml-tiedoston, tarkistaa virheet ja tallentaa kaikki tiedot valtavaan tietokantaan.
Tällaisia tallennettuja xml-tiedostoja on monia. Tästä tietokannasta luodaan hakuindeksi. Hakemisto on tallennettu sisäisessä muodossa. Indeksin luomisen jälkeen Layout-palvelu lataa sen hakupalvelimille.
Tämän seurauksena tietokantaan ilmestyy vihainen kissa vinkujalla ja kissan hakemisto ilmestyy palvelimelle.
Kerron sinulle, kuinka etsimme kissaa hakuarkkitehtuuria käsittelevässä osassa.
Markkinahakuarkkitehtuuri
Elämme mikropalvelujen maailmassa: jokainen saapuva pyyntö aiheuttaa paljon alikyselyjä, ja niiden käsittelyyn osallistuu kymmeniä palveluita. Kaavio näyttää vain muutaman:
Yksinkertaistettu pyyntöjen käsittelyjärjestelmä
Jokaisessa palvelussa on ihana asia - oma tasapainottaja ainutlaatuisella nimellä:
Tasapainotin antaa meille enemmän joustavuutta palvelun hallinnassa: voit esimerkiksi kytkeä palvelimet pois päältä, mitä päivityksiä usein tarvitaan. Tasapainottaja huomaa, että palvelin ei ole käytettävissä, ja ohjaa pyynnöt automaattisesti toisiin palvelimiin tai tietokeskuksiin. Kun lisäät tai poistat palvelinta, kuorma jaetaan automaattisesti uudelleen palvelimien kesken.
Tasapainottimen yksilöllinen nimi ei riipu datakeskuksesta. Kun palvelu A tekee pyynnön B:lle, tasapainottaja B uudelleenohjaa pyynnön oletusarvoisesti nykyiseen datakeskukseen. Jos palvelu ei ole käytettävissä tai sitä ei ole nykyisessä palvelinkeskuksessa, pyyntö ohjataan uudelleen muihin palvelinkeskuksiin.
Yksi FQDN kaikille palvelinkeskuksille mahdollistaa palvelun A täydellisen abstraktion paikoista. Hänen pyyntönsä palveluun B käsitellään aina. Poikkeuksena on tapaus, jossa palvelu sijaitsee kaikissa datakeskuksissa.
Mutta kaikki ei ole niin ruusuista tämän tasapainottimen kanssa: meillä on ylimääräinen välikomponentti. Tasapainotin voi olla epävakaa, ja tämän ongelman ratkaisevat redundantit palvelimet. Palveluiden A ja B välillä on myös ylimääräinen viive. Käytännössä se on kuitenkin alle 1 ms, eikä useimmille palveluille tämä ole kriittistä.
Odottamattomien asioiden käsittely: Hakupalvelujen tasapaino ja kestävyys
Kuvittele, että tapahtuu romahdus: sinun on löydettävä kissa, jolla on vinkuja, mutta palvelin kaatuu. Tai 100 palvelinta. Miten päästä ulos? Aiommeko todella jättää käyttäjän ilman kissaa?
Tilanne on pelottava, mutta olemme valmiita siihen. Kerron järjestyksessä.
Hakuinfrastruktuuri sijaitsee useissa palvelinkeskuksissa:
Sisällytämme suunnittelussa mahdollisuuden sulkea yksi palvelinkeskus. Elämä on täynnä yllätyksiä - esimerkiksi kaivinkone voi katkaista maanalaisen kaapelin (kyllä, niin tapahtui). Muiden datakeskusten kapasiteetin pitäisi olla riittävä kestämään huippukuormitus.
Ajatellaanpa yhtä datakeskusta. Jokaisella datakeskuksella on sama tasapainottimen toimintamalli:
Yksi balansoija on vähintään kolme fyysistä palvelinta. Tämä redundanssi on tehty luotettavuuden vuoksi. Tasapainottimet toimivat HAProxilla.
Valitsimme HAProxin sen korkean suorituskyvyn, alhaisten resurssivaatimusten ja laajan toiminnallisuuden vuoksi. Hakuohjelmistomme toimii jokaisen palvelimen sisällä.
Yhden palvelimen epäonnistumisen todennäköisyys on pieni. Mutta jos sinulla on useita palvelimia, todennäköisyys, että ainakin yksi kaatuu, kasvaa.
Näin tapahtuu todellisuudessa: palvelimet kaatuvat. Siksi on tarpeen seurata jatkuvasti kaikkien palvelimien tilaa. Jos palvelin lakkaa vastaamasta, se katkaistaan automaattisesti liikenteestä. Tätä tarkoitusta varten HAProxyssa on sisäänrakennettu terveystarkastus. Se menee kaikille palvelimille kerran sekunnissa HTTP-pyynnöllä "/ping".
Toinen HAProxyn ominaisuus: agenttitarkistuksen avulla voit ladata kaikki palvelimet tasaisesti. Tätä varten HAProxy muodostaa yhteyden kaikkiin palvelimiin, ja ne palauttavat painonsa nykyisestä kuormituksesta 1 - 100. Paino lasketaan käsittelyjonossa olevien pyyntöjen lukumäärän ja prosessorin kuormituksen perusteella.
Nyt kissan löytämisestä. Hakutuloksia pyyntöihin, kuten: /search?text=vihainen+kissa. Jotta haku olisi nopeaa, koko kissahakemiston on mahduttava RAM-muistiin. Edes SSD-levyltä lukeminen ei ole tarpeeksi nopeaa.
Aikoinaan tarjoustietokanta oli pieni ja yhden palvelimen RAM-muisti riitti siihen. Kun tarjouskanta kasvoi, kaikki ei enää mahtunut tähän RAM-muistiin, ja tiedot jaettiin kahteen osaan: shard 1 ja shard 2.
Mutta näin tapahtuu aina: mikä tahansa ratkaisu, myös hyvä, aiheuttaa muita ongelmia.
Tasapainotin meni silti mille tahansa palvelimelle. Mutta koneessa, jossa pyyntö tuli, oli vain puolet indeksistä. Loput olivat muilla palvelimilla. Siksi palvelimen piti mennä jollekin naapurikoneelle. Kun tiedot oli saatu molemmilta palvelimilta, tulokset yhdistettiin ja järjestettiin uudelleen.
Koska tasapainottaja jakaa pyynnöt tasaisesti, kaikki palvelimet olivat mukana uudelleen luokittelussa eivätkä vain tietojen lähettämisessä.
Ongelma ilmeni, jos naapuripalvelin ei ollut käytettävissä. Ratkaisu oli määrittää "naapuripalvelimeksi" useita palvelimia erilaisilla prioriteeteilla. Ensin pyyntö lähetettiin nykyisen telineen palvelimille. Jos vastausta ei saatu, pyyntö lähetettiin kaikille tämän datakeskuksen palvelimille. Ja lopuksi pyyntö meni muihin palvelinkeskuksiin.
Ehdotusten määrän kasvaessa tiedot jaettiin neljään osaan. Mutta tämä ei ollut raja.
Tällä hetkellä käytössä on kahdeksan sirpaleen kokoonpano. Lisäksi muistin säästämiseksi hakemisto jaettiin hakuosaan (jota käytetään hakuun) ja katkelmaosaan (joka ei ole mukana haussa).
Yksi palvelin sisältää tietoja vain yhdestä sirpaleesta. Siksi, jotta voit etsiä koko hakemistosta, sinun on tehtävä haku kahdeksalta palvelimelta, jotka sisältävät erilaisia sirpaleita.
Palvelimet on ryhmitelty klustereihin. Jokainen klusteri sisältää kahdeksan hakukonetta ja yhden katkelmapalvelimen.
Katkelmapalvelin käyttää avainarvotietokantaa, jossa on staattisia tietoja. Niitä tarvitaan asiakirjojen myöntämiseen, esimerkiksi kuvaus kissasta, jolla on vinkuja. Tiedot siirretään erityisesti erilliselle palvelimelle, jotta hakupalvelimien muistia ei kuormiteta.
Koska asiakirjatunnukset ovat yksilöllisiä vain yhdessä hakemistossa, voi syntyä tilanne, jossa katkelmissa ei ole asiakirjoja. Tai sitten yhdelle tunnukselle tulee eri sisältöä. Siksi, jotta haku toimisi ja tulokset palautettaisiin, tarvitaan johdonmukaisuutta koko klusterissa. Kerron alla, kuinka valvomme johdonmukaisuutta.
Itse haku on rakenteeltaan seuraava: hakupyyntö voi tulla mille tahansa kahdeksasta palvelimesta. Oletetaan, että hän tuli palvelimelle 1. Tämä palvelin käsittelee kaikki argumentit ja ymmärtää mitä ja miten etsiä. Saapuvasta pyynnöstä palvelin voi tehdä lisäpyyntöjä ulkopuolisille palveluille tarvittavien tietojen saamiseksi. Yhtä pyyntöä voi seurata enintään kymmenen pyyntöä ulkopuolisille palveluille.
Kun tarvittavat tiedot on kerätty, haku alkaa tarjoustietokannasta. Tätä varten alikyselyt tehdään kaikkiin klusterin kahdeksaan palvelimeen.
Kun vastaukset on saatu, tulokset yhdistetään. Lopulta koodinpätkäpalvelimelle voidaan tarvita useita lisäkyselyjä tulosten luomiseen.
Hakukyselyt klusterin sisällä näyttävät tältä: /shard1?text=vihainen+kissa. Lisäksi lomakkeen alikyselyjä tehdään jatkuvasti kaikkien klusterin palvelimien välillä kerran sekunnissa: /Tila.
Tiedustelu /Tila havaitsee tilanteen, jossa palvelin ei ole käytettävissä.
Se hallitsee myös sitä, että hakukoneen versio ja hakemistoversio ovat samat kaikilla palvelimilla, muuten klusterin sisällä on epäjohdonmukaisia tietoja.
Huolimatta siitä, että yksi katkelmapalvelin käsittelee pyyntöjä kahdeksalta hakukoneelta, sen prosessori on erittäin kevyesti ladattu. Siksi siirrämme nyt katkelman tiedot erilliseen palveluun.
Tietojen siirtämistä varten otimme käyttöön yleisavaimet asiakirjoille. Nyt on mahdotonta tilanne, jossa sisältö toisesta dokumentista palautetaan yhdellä avaimella.
Mutta siirtyminen toiseen arkkitehtuuriin ei ole vielä valmis. Nyt haluamme päästä eroon erillisestä katkelmapalvelimesta. Ja sitten siirtyä kokonaan pois klusterirakenteesta. Tämä antaa meille mahdollisuuden jatkaa skaalaamista helposti. Lisäbonuksena on merkittävät raudan säästöt.
Ja nyt pelottaviin tarinoihin onnellisilla lopuilla. Tarkastellaan useita tapauksia, joissa palvelin ei ole käytettävissä.
Jotain kauheaa tapahtui: yksi palvelin ei ole käytettävissä
Oletetaan, että yksi palvelin ei ole käytettävissä. Sitten klusterin jäljellä olevat palvelimet voivat jatkaa vastaamista, mutta hakutulokset ovat epätäydellisiä.
Tilatarkistuksen kautta /Tila viereiset palvelimet ymmärtävät, että yksi ei ole käytettävissä. Siksi täydellisyyden säilyttämiseksi kaikki klusterin palvelimet pyyntöä kohti /ping he alkavat vastata tasapainottimelle, että he eivät myöskään ole käytettävissä. Osoittautuu, että kaikki klusterin palvelimet kuolivat (mikä ei ole totta). Tämä on klusterimallimme suurin haittapuoli - siksi haluamme päästä eroon siitä.
Tasapainottaja lähettää uudelleen pyynnöt, jotka epäonnistuvat virheen vuoksi.
Tasapainotin lopettaa myös käyttäjäliikenteen lähettämisen kuolleille palvelimille, mutta jatkaa niiden tilan tarkistamista.
Kun palvelin tulee saataville, se alkaa vastata /ping. Heti kun normaalit vastaukset kuolleilta palvelimilta saapuviin ping-kutsuihin alkavat saapua, balansoijat alkavat lähettää käyttäjäliikennettä sinne. Klusterin toiminta on palautettu, hurraa.
Vielä pahempaa: monet palvelimet eivät ole käytettävissä
Merkittävä osa konesalin palvelimista leikataan. Mitä tehdä, minne juosta? Tasapainotin tulee jälleen apuun. Jokainen tasapainotin tallentaa jatkuvasti muistiin nykyisen reaaliaikaisten palvelimien määrän. Se laskee jatkuvasti, kuinka paljon liikennettä nykyinen palvelinkeskus pystyy käsittelemään.
Kun monet palvelinkeskuksen palvelimet hajoavat, tasapainottaja ymmärtää, että tämä palvelinkeskus ei pysty käsittelemään kaikkea liikennettä.
Sitten ylimääräistä liikennettä aletaan jakaa satunnaisesti muihin datakeskuksiin. Kaikki toimii, kaikki ovat tyytyväisiä.
Kuinka teemme sen: julkaisemme julkaisuja
Puhutaan nyt siitä, kuinka julkaisemme palveluun tehdyt muutokset. Tässä olemme ottaneet prosessien yksinkertaistamisen polun: uuden julkaisun käyttöönotto on lähes täysin automatisoitua.
Kun projektiin on kertynyt tietty määrä muutoksia, uusi julkaisu luodaan automaattisesti ja sen rakentaminen alkaa.
Tämän jälkeen palvelu käännetään testaukseen, jossa toiminnan vakaus tarkistetaan.
Samalla käynnistetään automaattinen suorituskyvyn testaus. Asiasta huolehtii erikoispalvelu. En puhu siitä nyt - sen kuvaus on erillisen artikkelin arvoinen.
Jos julkaisu testauksessa onnistuu, julkaisun julkaisu prestable-versiona alkaa automaattisesti. Prestable on erityinen klusteri, johon ohjataan normaalia käyttäjäliikennettä. Jos se palauttaa virheen, tasapainotin pyytää uudelleen tuotantoa.
Prestabilissa vasteajat mitataan ja verrataan edelliseen tuotantoversioon. Jos kaikki on kunnossa, niin henkilö ottaa yhteyttä: tarkistaa kuormitustestauksen kaaviot ja tulokset ja alkaa sitten rullata tuotantoon.
Kaikki paras menee käyttäjälle: A/B-testaus
Aina ei ole selvää, tuovatko palvelun muutokset todellista hyötyä. Muutosten hyödyllisyyden mittaamiseksi ihmiset keksivät A/B-testauksen. Kerron sinulle hieman, kuinka se toimii Yandex.Market-haussa.
Kaikki alkaa uuden CGI-parametrin lisäämisellä, joka mahdollistaa uusia toimintoja. Olkoon parametrimme: market_new_functionality=1. Sitten koodissa otamme tämän toiminnon käyttöön, jos lippu on läsnä:
If (cgi.experiments.market_new_functionality) {
// enable new functionality
}Uusia toimintoja otetaan käyttöön tuotantoon.
A/B-testauksen automatisoimiseksi on olemassa oma palvelu, joka tarjoaa yksityiskohtaisia tietoja . Palveluun luodaan kokeilu. Liikenteen osuus on asetettu esimerkiksi 15 %:iin. Prosentteja ei aseteta kyselyille vaan käyttäjille. Kokeen kesto on myös ilmoitettu, esimerkiksi viikko.
Useita kokeita voidaan suorittaa samanaikaisesti. Asetuksissa voit määrittää, onko leikkaus muiden kokeiden kanssa mahdollista.
Tämän seurauksena palvelu lisää automaattisesti argumentin market_new_functionality=1 15 prosenttiin käyttäjistä. Se myös laskee automaattisesti valitut mittarit. Kokeen päätyttyä analyytikot tarkastelevat tuloksia ja tekevät johtopäätökset. Tulosten perusteella tehdään päätös tuotantoon tai jalostukseen siirtymisestä.
Markkinoiden taitava käsi: testaus tuotannossa
Usein tapahtuu, että joudut testaamaan uuden toiminnon toimintaa tuotannossa, mutta et ole varma, kuinka se käyttäytyy "taistelu" olosuhteissa raskaan kuormituksen alla.
Ratkaisu on olemassa: CGI-parametreissa olevia lippuja voidaan käyttää A/B-testauksen lisäksi myös uusien toimintojen testaamiseen.
Teimme työkalun, jonka avulla voit muuttaa tuhansien palvelimien asetuksia välittömästi ilman, että palvelu altistuu riskeille. Sitä kutsutaan Stop Tap. Alkuperäisenä ideana oli pystyä nopeasti poistamaan käytöstä joitakin toimintoja ilman asettelua. Sitten työkalu laajeni ja muuttui monimutkaisemmaksi.
Palvelun kulkukaavio on esitetty alla:
Lippuarvot asetetaan API:n kautta. Hallintapalvelu tallentaa nämä arvot tietokantaan. Kaikki palvelimet menevät tietokantaan kymmenen sekunnin välein, pumppaavat lippuarvot ja käyttävät näitä arvoja jokaiseen pyyntöön.
Pysäytä-napautuksella voit asettaa kahdenlaisia arvoja:
1) Ehdolliset lausekkeet. Käytä, kun jokin arvoista on tosi. Esimerkiksi:
{
"condition":"IS_DC1",
"value":"3",
},
{
"condition": "CLUSTER==2 and IS_BERU",
"value": "4!"
}Arvoa "3" käytetään, kun pyyntö käsitellään sijainnissa DC1. Ja arvo on "4", kun pyyntö käsitellään beru.ru-sivuston toisessa klusterissa.
2) Ehdottomat arvot. Käytä oletusarvoisesti, jos mikään ehdoista ei täyty. Esimerkiksi:
arvo, arvo!
Jos arvo päättyy huutomerkkiin, sille annetaan korkeampi prioriteetti.
CGI-parametrin jäsentäjä jäsentää URL-osoitteen. Sen jälkeen käyttää arvoja Stop Tapista.
Arvoja, joilla on seuraavat prioriteetit, sovelletaan:
- Lisätty etusijalla Stop Tap (huutomerkki).
- Pyynnöstä saatu arvo.
- Oletusarvo kohdassa Pysäytä napautus.
- Oletusarvo koodissa.
On monia lippuja, jotka on merkitty ehdollisiin arvoihin - ne riittävät kaikkiin meille tuntemiinmme skenaarioihin:
- Datakeskus.
- Ympäristö: tuotanto, testaus, varjo.
- Paikka: Market, Beru.
- Klusterin numero.
Tämän työkalun avulla voit ottaa käyttöön uusia toimintoja tietylle palvelinryhmälle (esimerkiksi vain yhdessä palvelinkeskuksessa) ja testata tämän toiminnon toimintaa ilman erityistä riskiä koko palvelulle. Vaikka olisit tehnyt vakavan virheen jossain, kaikki alkoi kaatua ja koko palvelinkeskus kaatui, tasapainottimet ohjaavat pyynnöt muihin palvelinkeskuksiin. Loppukäyttäjät eivät huomaa mitään.
Jos huomaat ongelman, voit välittömästi palauttaa lipun aiempaan arvoonsa ja muutokset peruutetaan.
Tällä palvelulla on myös huonot puolensa: kehittäjät pitävät siitä kovasti ja yrittävät usein työntää kaikki muutokset Stop Tapiin. Yritämme torjua väärinkäyttöä.
Stop Tap -lähestymistapa toimii hyvin, kun sinulla on jo vakaa koodi valmiina tuotantoon. Samaan aikaan sinulla on edelleen epäilyksiä ja haluat tarkistaa koodin "taisteluolosuhteissa".
Stop Tap ei kuitenkaan sovellu testattavaksi kehitysvaiheessa. Kehittäjille on olemassa erillinen klusteri nimeltä "varjoklusteri".
Salainen testaus: Shadow Cluster
Pyynnöt yhdestä klusterista kopioidaan varjoklusteriin. Mutta tasapainottaja jättää täysin huomioimatta tämän klusterin vastaukset. Sen toimintakaavio on esitetty alla.
Saamme testiklusterin, joka on todellisissa "taisteluolosuhteissa". Normaali käyttäjäliikenne menee sinne. Molempien klustereiden laitteisto on sama, joten suorituskykyä ja virheitä voidaan verrata.
Ja koska tasapainotin jättää vastaukset täysin huomioimatta, loppukäyttäjät eivät näe vastauksia varjoklusterista. Siksi virheen tekeminen ei ole pelottavaa.
Tulokset
Joten miten rakensimme Market-haun?
Jotta kaikki sujuisi sujuvasti, erottelemme toiminnallisuuden erillisiin palveluihin. Näin voimme skaalata vain tarvitsemamme komponentit ja tehdä komponenteista yksinkertaisempia. On helppoa antaa erillinen komponentti toiselle tiimille ja jakaa sen parissa työskentelevä vastuu. Ja merkittävät rautasäästöt tällä lähestymistavalla on ilmeinen plus.
Varjoklusteri auttaa myös meitä: voimme kehittää palveluita, testata niitä prosessissa emmekä häiritse käyttäjää.
No, tuotannossa testataan tietysti. Tarvitseeko tuhansien palvelimien asetuksia muuttaa? Helppoa, käytä Stop Tapa. Näin voit heti ottaa käyttöön valmiin monimutkaisen ratkaisun ja palata takaisin vakaaseen versioon, jos ongelmia ilmenee.
Toivon, että pystyin näyttämään, kuinka teemme Marketista nopean ja vakaan jatkuvasti kasvavalla tarjouspohjalla. Kuinka ratkaisemme palvelinongelmia, käsittelemme valtavan määrän pyyntöjä, parannamme palvelun joustavuutta ja teemme tämän keskeyttämättä työprosesseja.
Lähde: will.com