Preporuke za Geosharded 2. dio: Arhitektura

Autori: Frank Ren | Direktor, Backend inženjering, Xiaohu Li | Voditelj, Backend inženjering, Devin Thomson | Olovo, Backend inženjer, Daniel Geng | Backend inženjer

Pokrili smo mehanizam zašiljenja u prethodnom postu, u kojem smo postavili teoretski temelj geoshardiranih klastera.

U drugom dijelu objasnit ćemo kako smo izgradili visoko učinkovitu, skalabilnu i uravnoteženu infrastrukturu za podupiranje naših poslovnih potreba, kao i raspravljati o nekim zanimljivim inženjerskim izazovima koje smo savladali i razmatranjima koja stoje iza njih.

Arhitektura visoke razine

Nakon što smo finalizirali algoritam izoštravanja i implementirali sloj apstrakcije kao unutarnji mikroservis, vidjeli smo arhitekturu klastera visoke razine prikazanu u nastavku:

Jednom kada se korisnik promijeni, on prolazi kroz profil korisnika, pogađa usluge lokacije kako bi otkrio je li promjena lokacije rezultirao premještanjem sjenke, a zatim udara u čvor podataka s određenim podacima o ruti kako bi obavio pomicanje dijelova.

Kada korisnici dobivaju preporuke, naš mehanizam za preporuke koristi logički sloj kako bi utvrdio koliko komada treba upiti (na temelju trenutnog filtra lokacije i udaljenosti korisnika), a zatim uputi indekse s tim podacima. Rezultati se prikupljaju i objedinjuju preko ovih komada i šalju natrag klijentima.

U ovom smo koraku naišli na sljedeća otvorena pitanja:

  • Koja bi bila najbolja inženjerijska primjena „frakcije“ u našem indeksu?
  • Kako odlučiti optimalno postavljanje za geosharding klaster?
  • Kako uravnotežimo opterećenje?

Multi-indeks u odnosu na više-klastera

Riječ "shard" o kojoj smo govorili do sad je samo logičan pojam koji predstavlja izolaciju indeksa na temelju korisničke geolokacije, ali nismo odlučili koja bi bila inženjerska implementacija. U svijetu Elasticsearcha imamo po jedan indeks za svaki dio, ali svi indeksi pripadaju jednom klasteru, ili, možemo imati više klastera, od kojih svaki predstavlja dio.

Evo prednosti i nedostataka za svaki scenarij:

Multi-indeks: Pros: Elasticsearch podržava multi-indeksno pretraživanje bez okvira, lakše ga je održavati s operativnog stajališta. Kontra: Teže je skalirati prema gore ili dolje, kad se ugrije, može utjecati na još jedan dio

Višestruki klaster: Pros: Niža razina odvojenosti, lakše skaliranje gore / dolje po klasteru nedostaci: Još nije podržan upit s više klastera; moramo ih eksplicitno paralelno ispaliti, isto i za situaciju da se kreće

Pažljivo smo odlučili krenuti s multi-indeksnim scenarijem, jer je on značajno pojednostavio logiku na strani našeg poslužitelja, kao i operativne troškove. Odatle smo razvili strategiju uravnoteženja opterećenja kako bismo prevladali nedostatke ovog scenarija. I uvijek možemo povećati komadić dodavanjem više replika.

Pronalaženje prave veličine

Sljedeći je inženjerski izazov odabrati pravu veličinu klastera, pogotovo kada postoji toliko mnogo varijabli koje možemo prilagoditi. Neka pitanja o varijablama uključuju:

  • Koja je najbolja veličina za svaki dio?
  • Koliko nam ukupno treba domaćina?
  • Kolika je računalna snaga potrebna za svaki domaćin?
  • Koliko replika trebamo za svaki dio?
  • Koje su optimalne konfiguracije Elasticsearch / jvm za naše postavljanje?

Da biste pronašli odgovore na ta pitanja iznad, potrebno je opsežno testiranje performansi. JMeter smo koristili za postavljanje našeg testnog okvira performansi koji sadrži koordinirajući čvor, podatkovni čvor i JMeter udaljeni čvor poslužitelja. JMeter daljinski poslužiteljski čvor odgovoran je za ispaljivanje zahtjeva u koordinacijski čvor, koji u osnovi preusmjerava promet u čvor podataka, a zatim skuplja rezultate iz njega i vraća ga natrag na udaljeni poslužiteljski čvor za usporedbu.

Većina varijabli koje smatramo nisu izolirane jedna od druge. Na primjer, vrsta primjerice, veličina dijeljenja i broj replika utječu jedni na druge: veća veličina oštrice, manji brojčići koje možete uklopiti u istu vrstu instance, rezultira manjim brojem replika koje možete imati unutar istog broja hosta.

Umjesto da testiramo sve moguće kombinacije ovih dimenzija, odlučili smo ih odrediti jednu po jednu, počevši od veličine osipa, s obzirom na broj korisnika i geološka područja.

Da bismo stekli smisao za to, objedinimo naše korisničke lokacije i mapiramo ih kako bismo saznali najgušće područje populacije Tinder-a. Odatle cjelokupno područje premjestimo u jedan sjenik, tako da će korisnici unutar tog gustog područja imati manje šanse da izvršavaju unakrsne upite i pomicanje oštrica.

Zatim smo pripremili testne podatke postavljanjem korisničkih dokumenata u čvor podataka, čija količina ovisi o projiciranom broju korisnika po dijeljenju. Također odabiremo tipičnu veličinu područja sjemena kada se sijeku geografski položaji svakog korisničkog dokumenta, tako da se nasumično - ali jednoliko - distribuiraju unutar četvornog područja.

Također uzimamo stvarnu raspodjelu filtera za dob i dob našeg korisnika i primjenjujemo slučajnosti tijekom hranjenja, pokušavajući najbolje da simuliramo uzorak prometa i veličinu učitavanja za svaki upit.

Polazeći od malog volumena prometa i uspona do točke u kojoj su čvor upita ili čvor podataka maksirali svoj CPU ili memoriju, testiramo izvedbu različitih scenarija (promjena veličine dijeljenja, broj replika, vrsta instanci AWS, konfiguracije jvm, itd.) i identificirati optimalnu postavku za naš geosharded klaster u proizvodnom okruženju.

Suočavanje s vremenskim zonama

Korisnici unutar istog geosharda obično su u istim ili susjednim vremenskim zonama jer su geografski u susjedstvu. Ova priroda podrazumijeva neuravnotežen promet, jer će se vršni i van-vršni sati razlikovati zbog vremenskih zona, a također i različitih obrazaca upotrebe za korisnike po zemljopisnoj lokaciji.

Ovaj grafikon prikazuje hipotetički obrazac prometa dvaju geosada u vremenskom rasponu od 24 sata:

Kao što vidite, njihov vršni promet je otprilike isti, ali se događaju u različito doba dana. Ako dodijelimo samo jedan komad u jednom fizičkom okviru, opterećenje će biti neuravnoteženo na različitim čvorovima. Najveća razlika u pogledu zahtjeva u sekundi može biti više od 10x u bilo kojem trenutku između različitih komada.

Naš je cilj izgraditi geosharded grozd koji može podnijeti opterećenje s oštrim bodovima po komadu i učiniti ga što je moguće uravnoteženijim tako da naša globalna korisnička baza može doživjeti slične latencije, bez obzira na to u kojem se geoshardu nalaze i koliko geosharda oni potencijalno udaraju.

Da bi se postigao ovaj cilj, jedno je rješenje ručno rasporediti više komada u iste čvorove kako bi se osiguralo da je njihovo opterećenje slično bilo kojem trenutku u danu dana. Vjerujemo da ovo može proizvesti najuravnoteženiji teret u teoriji; međutim, za održavanje dinamičkog klastera potrebna je velika ručna intervencija i to je težak problem riješiti.

Uz to, kad trebamo ponovno razmotriti zbog rasta baze korisnika, taj problem moramo ponovno izračunati. Zbog toga smo na kraju odlučili iskoristiti snagu slučajnosti.

Upotrebom ovog modela pojednostavili smo NP tvrdi problem u tipičan statistički problem: da u M ladice stavite ukupno N kuglica (N = broj komada * broj replike po komadu) pet različitih boja (M = broj fizičkih domaćina) , koliki je udio dvije kuglice iste boje u bilo kojoj ladici?

Ponavljali smo s različitom vrijednošću N podešavanjem broja replika po djeliću i izračunavanjem mogućnosti. Na kraju smo uspostavili slatku točku za broj replika. To je u biti kompromis: što više replika imamo, to će biti uravnoteženiji; ali kapacitet pisanja i memorija trpjet će po osnovi glavnog računala.

Završna faza

Nakon svih ovih preinaka i testiranja, evo kako izgleda naša arhitektura klastera sa geoshdrima:

Pod tri glavna čvora imamo dva ASG-a, jedan sadrži samo koordinirajuće čvorove (ovo je onaj na koji šaljemo sve zahtjeve), a drugi ASG sadrži sve čvorove podataka. Svaki čvor podataka čuva nasumično raspoređene četiri indeksa, od kojih su neki primarni od određenog dijela, dok su drugi replike nekih drugih komada. Ovisno o tome koliko geosharda dolazi na upit, koordinirajući čvor distribuirat će zahtjeve odgovarajućim čvorovima podataka koji sadrže ciljne geosharde.

Na ovaj način možemo ugostiti sve geoshardirane indekse u jednom klasteru i uravnotežiti opterećenje.

takeaways

Do sada imamo opsežni, uravnoteženi indeksni klaster. Prema našem mjerenju u proizvodnji, geosharded indeksi obavljaju 20 puta više izračuna u odnosu na prethodno postavljanje.

Ključni dijelovi:

  • Testiranje performansi presudan je element u razvijanju nove infrastrukture
  • Razmislite o korištenju slučajnosti za rješavanje teških problema u inženjerskoj praksi

Jeste li zainteresirani za izgradnju rješenja složenih problema poput ovih na globalnoj razini? Uvijek tražimo vrhunske talente i inventivne rješavatelje problema koji bi se pridružili našem inženjerskom timu. Pogledajte naše otvore ovdje!