Me kaikki rakastamme tarinoita. Haluamme istua tulen ympärillä ja puhua menneistä voitoistamme, taisteluistamme tai vain työkokemuksestamme.
Tänään on juuri sellainen päivä. Ja vaikka et olisi tulella juuri nyt, meillä on sinulle tarina. Tarina siitä, kuinka aloimme työskennellä tallennustilan kanssa Tarantoolissa.
Olipa kerran yrityksellämme pari ”monoliittia” ja yksi ”katto” kaikille, joille nämä monoliitit hitaasti mutta varmasti lähestyivät rajoittaen yrityksemme lentoa, kehitystämme. Ja oli selvä ymmärrys: jonain päivänä osumme tähän kattoon lujasti.
Nykyään vallitseva ideologia erottaa kaikki ja kaikki, laitteista liiketoimintalogiikkaan. Tämän seurauksena meillä on esimerkiksi kaksi DC:tä, jotka ovat käytännössä riippumattomia verkkotasolla. Ja sitten kaikki oli täysin erilaista.
Nykyään on olemassa paljon työkaluja ja työkaluja muutosten tekemiseen CI/CD, K8S jne. "Monoliittisena" aikana emme tarvinneet niin paljon vieraita sanoja. Se riitti yksinkertaisesti korjaamaan "tallennus" tietokannassa.
Mutta aika meni eteenpäin ja pyyntöjen määrä eteni sen mukana, ja toisinaan RPS ylitti kykymme. IVY-maiden tullessa markkinoille, ensimmäisen monoliitin tietokantaprosessorin kuormitus ei laskenut alle 90 % ja RPS pysyi 2400:n tasolla. Eivätkä nämä olleet vain pieniä valitsimia, vaan isoja kyselyitä, joissa oli joukko tarkistuksia ja JOINeja, jotka voisivat suorittaa lähes puolet tiedoista suuren IO:n taustalla.
Kun täysimittaista Black Friday -myyntiä alkoi ilmestyä näyttämölle - ja Wildberries oli yksi ensimmäisistä, jotka järjestivät ne Venäjällä - tilanne muuttui täysin surulliseksi. Loppujen lopuksi kuormitus tällaisina päivinä kasvaa kolme kertaa.
Voi näitä "monoliittisia aikoja"! Olen varma, että olet kokenut jotain vastaavaa, etkä edelleenkään ymmärrä, kuinka tämä voi tapahtua sinulle.
Mitä voit tehdä - muoti on luontainen tekniikka. Noin 5 vuotta sitten jouduimme harkitsemaan uudelleen yhtä näistä modeista olemassa olevan .NET-sivuston ja MS SQL -palvelimen muodossa, joka tallensi huolellisesti koko sivuston logiikan. Pidin sitä niin huolellisesti, että tällaisen monoliitin sahaaminen osoittautui pitkäksi ja ei ollenkaan helpoksi iloksi.
Pieni digressio.
Monissa tapahtumissa sanon: "Jos et nähnyt monoliittia, niin et kasvanut!" Olen kiinnostunut mielipiteestäsi tästä asiasta, kirjoita se kommentteihin.
Ukkosen ääni
Palataan "kokkoon". "Monoliittisen" toiminnallisuuden kuormituksen jakamiseksi päätimme jakaa järjestelmän avoimen lähdekoodin teknologioihin perustuviin mikropalveluihin. Koska ne ovat ainakin halvempia skaalata. Ja meillä oli 100-prosenttinen ymmärrys siitä, että meidän piti skaalata (ja paljon). Loppujen lopuksi jo tuolloin oli mahdollista päästä naapurimaiden markkinoille, ja rekisteröintien määrä sekä tilausten määrä alkoi kasvaa entistä voimakkaammin.
Analysoituamme ensimmäiset ehdokkaat monoliitista mikropalveluihin lähtöön, huomasimme, että 80 % niiden kirjoituksesta tulee back office -järjestelmistä ja lukeminen front office -järjestelmistä. Ensinnäkin tämä koski paria meille tärkeää alajärjestelmää - käyttäjätietoja ja järjestelmää, jolla lasketaan tavaroiden lopullinen hinta, joka perustuu tietoihin lisäalennuksista ja -kuponkeista.
Sisennetty. Nyt on pelottavaa kuvitella, mutta monoliitistamme poistettiin edellä mainittujen alijärjestelmien lisäksi myös tuoteluettelot, käyttäjän ostoskori, tuotehakujärjestelmä, tuoteluetteloiden suodatusjärjestelmä ja erilaiset suositusjärjestelmät. Jokaisen niiden toimintaa varten on erilliset luokat kapeasti räätälöityjä järjestelmiä, mutta kerran he kaikki asuivat yhdessä "talossa".
Suunnittelimme välittömästi siirtää asiakkaitamme koskevia tietoja sirpaloituun järjestelmään. Tavaran lopullisen kustannuslaskennan toiminnallisuuden poistaminen edellytti hyvää skaalautuvuutta lukemiseen, koska se loi suurimman RPS-kuormituksen ja oli vaikein toteuttaa tietokannassa (laskentaprosessissa on paljon dataa mukana).
Tuloksena saimme suunnitelman, joka sopii hyvin Tarantoolin kanssa.
Tuolloin mikropalveluiden toimintaa varten valittiin järjestelmiä useiden virtuaali- ja laitteistokoneiden datakeskusten työskentelyyn. Kuten kuvista näkyy, Tarantoolin replikointivaihtoehtoja käytettiin sekä isäntä-isäntä- että isäntä-orja-tilassa.
Arkkitehtuuri. Vaihtoehto 1. Käyttäjäpalvelu
Tällä hetkellä käytössä on 24 sirpaletta, joista jokaisessa on 2 esiintymää (yksi jokaiselle DC:lle), kaikki master-master-tilassa.
Tietokannan päällä on sovelluksia, jotka käyttävät tietokannan replikoita. Sovellukset toimivat Tarantoolin kanssa mukautetun kirjastomme kautta, joka toteuttaa Tarantool Go -ohjainliittymän. Hän näkee kaikki kopiot ja voi työskennellä mestarin kanssa lukea ja kirjoittaa. Pohjimmiltaan se toteuttaa replikasarjamallin, joka lisää logiikkaa replikoiden valitsemiseen, uudelleenyritysten suorittamiseen, katkaisijan ja nopeusrajoituksen.
Tässä tapauksessa on mahdollista määrittää replikoiden valintakäytäntö sirpaleiden yhteydessä. Esimerkiksi roundrobin.
Arkkitehtuuri. Vaihtoehto 2. Palvelu tavaroiden lopullisten kustannusten laskemiseksi
Muutama kuukausi sitten suurin osa tavaroiden lopullisten kustannusten laskemista koskevista pyynnöistä meni uuteen palveluun, joka periaatteessa toimii ilman tietokantoja, mutta jokin aika sitten kaikki käsiteltiin 100-prosenttisesti palvelulla Tarantoolilla konepellin alla.
Palvelutietokanta koostuu neljästä isännästä, joihin synkronoija kerää tietoja, ja jokainen näistä replikointimastereista jakaa tietoja vain luku -replikoihin. Jokaisella masterilla on noin 4 tällaista jäljennöstä.
Joko ensimmäisessä tai toisessa menetelmässä, jos yksi DC ei ole käytettävissä, sovellus voi vastaanottaa dataa toisessa.
On syytä huomata, että Tarantoolin replikointi on melko joustavaa ja se voidaan määrittää ajon aikana. Muissa järjestelmissä ilmeni vaikeuksia. Esimerkiksi parametrien max_wal_senders ja max_replication_slots muuttaminen PostgreSQL:ssä vaatii ohjatun toiminnon uudelleenkäynnistyksen, mikä voi joissain tapauksissa johtaa sovelluksen ja DBMS:n välisten yhteyksien katkaisemiseen.
Etsi ja löydä!
Miksi emme tehneet sitä "kuten tavalliset ihmiset", vaan valitsimme epätyypillisen tavan? Se riippuu siitä, mitä pidetään normaalina. Monet ihmiset tekevät yleensä klusterin Mongosta ja levittävät sen kolmeen maantieteellisesti hajautettuun DC:hen.
Tuolloin meillä oli jo kaksi Redis-projektia. Ensimmäinen oli välimuisti, ja toinen oli pysyvä tallennustila ei liian kriittisille tiedoille. Hänen kanssaan se oli melko vaikeaa, osittain meidän syytämme. Joskus avainasemassa olivat melko suuret volyymit, ja silloin tällöin sivusto huononi. Käytimme tätä järjestelmää master-slave-versiossa. Ja oli monia tapauksia, joissa jotain tapahtui isännälle ja replikointi katkesi.
Eli Redis on hyvä valtiottomiin tehtäviin, ei tilallisiin tehtäviin. Periaatteessa se mahdollisti useimpien ongelmien ratkaisemisen, mutta vain jos ne olivat avainarvoratkaisuja indeksiparilla. Mutta Redis oli tuolloin melko surullinen sinnikkyydestä ja replikaatiosta. Lisäksi valituksia tehtiin suorituskyvystä.
Ajattelimme MySQL:ää ja PostgreSQL:ää. Mutta ensimmäinen ei jotenkin osunut meihin, ja toinen on sinänsä melko hienostunut tuote, jonka päälle ei olisi tarkoituksenmukaista rakentaa yksinkertaisia palveluita.
Kokeilimme RIAKia, Cassandraa, jopa graafitietokantaa. Nämä ovat kaikki melko niche-ratkaisuja, jotka eivät sopineet yleisen universaalin työkalun rooliin palveluiden luomisessa.
Lopulta päädyimme Tarantooliin.
Käännyimme siihen, kun se oli versiossa 1.6. Kiinnostuimme siitä avainarvon ja relaatiotietokannan toiminnallisuuden symbioosista. On toissijaisia indeksejä, tapahtumia ja välilyöntejä, nämä ovat kuin taulukoita, mutta eivät yksinkertaisia, niihin voi tallentaa eri määrän sarakkeita. Mutta Tarantoolin tappava ominaisuus oli toissijaiset indeksit yhdistettynä avainarvoon ja transaktioon.
Myös reagoivalla venäjänkielisellä yhteisöllä, joka oli valmis auttamaan chatissa, oli oma roolinsa. Käytimme tätä aktiivisesti ja elämme suoraan chatissa. Ja älä unohda kunnollista sinnikkyyttä ilman ilmeisiä virheitä. Jos katsot historiaamme Tarantoolin kanssa, meillä oli paljon kipua ja epäonnistumisia replikaatiossa, mutta emme koskaan menettäneet tietoja sen virheen vuoksi!
Toteutus alkoi nihkeästi
Tuolloin pääkehityspinomme oli .NET, johon ei ollut liitintä Tarantoolille. Aloimme heti tehdä jotain Gossa. Hyvin toimi myös Luan kanssa. Suurin ongelma tuolloin oli virheenkorjaus: .NET:ssä on kaikki hienoa tämän kanssa, mutta sen jälkeen oli vaikea sukeltaa sulautetun Luan maailmaan, kun sinulla ei ole virheenkorjausta paitsi lokit. Lisäksi jostain syystä replikaatio ajoittain hajosi, joten jouduin syventymään Tarantool-moottorin rakenteeseen. Chat auttoi tässä ja vähemmässä määrin dokumentaatiossa; joskus katsoimme koodia. Tuolloin dokumentaatio oli niin ja niin.
Joten onnistuin useiden kuukausien aikana saamaan pääni ympäri ja saamaan kunnollisia tuloksia työskennellessäni Tarantoolin kanssa. Kokosimme gitiin referenssikehityksiä, jotka auttoivat uusien mikropalvelujen muodostumisessa. Esimerkiksi kun tehtävä syntyi: luoda toinen mikropalvelu, kehittäjä katsoi arkistosta viiteratkaisun lähdekoodia, ja uuden luomiseen meni enintään viikko.
Nämä olivat erikoisia aikoja. Perinteisesti voit mennä järjestelmänvalvojan luo seuraavaan pöytään ja kysyä: "Anna minulle virtuaalikone." Noin XNUMX minuuttia myöhemmin auto oli jo mukanasi. Yhdistit itse, asensit kaiken ja liikenne lähetettiin sinulle.
Nykyään tämä ei enää toimi: pitää lisätä palveluun valvontaa ja kirjautumista, peittää toiminnallisuus testeillä, tilata virtuaalikoneen tai toimitus Kuberille jne. Yleensä se on parempi tällä tavalla, vaikka se kestää kauemmin ja on hankalampaa.
Hajoita ja hallitse. Mitä Lualle kuuluu?
Oli vakava dilemma: jotkin tiimit eivät pystyneet luomaan luotettavasti muutoksia palveluun, jossa oli paljon logiikkaa Luassa. Tähän liittyi usein se, että palvelu ei toiminut.
Eli kehittäjät valmistelevat jonkinlaista muutosta. Tarantool alkaa tehdä siirtoa, mutta replika on edelleen vanhalla koodilla; Jokin DDL tai jotain muuta saapuu sinne replikaation kautta, ja koodi yksinkertaisesti hajoaa, koska sitä ei oteta huomioon. Tämän seurauksena järjestelmänvalvojien päivitysmenettely asetettiin A4-arkille: lopeta replikointi, päivitä tämä, ota replikointi käyttöön, sammuta tästä, päivitä siellä. Painajainen!
Tämän seurauksena nyt emme useimmiten yritä tehdä mitään Luassa. Käytä vain iprotoa (binääriprotokollaa vuorovaikutukseen palvelimen kanssa), ja siinä se. Ehkä tämä on kehittäjien tietämyksen puute, mutta tästä näkökulmasta järjestelmä on monimutkainen.
Emme aina sokeasti seuraa tätä käsikirjoitusta. Nykyään meillä ei ole mustavalkoista: joko kaikki on Luassa tai kaikki on Gossa. Ymmärrämme jo, kuinka voimme yhdistää ne, jotta emme päädy muuttoongelmiin myöhemmin.
Missä Tarantool on nyt?
Tarantoolia käytetään palvelussa tavaroiden lopullisten kustannusten laskemiseen alennuskupongit huomioiden, jotka tunnetaan myös nimellä "Promoter". Kuten aiemmin sanoin, hän on nyt eläkkeellä: hänet korvataan uudella luettelopalvelulla, jossa hinnat on laskettu etukäteen, mutta kuusi kuukautta sitten kaikki laskelmat tehtiin Promotizerissa. Aiemmin puolet sen logiikasta oli kirjoitettu luassa. Kaksi vuotta sitten palvelu muutettiin varastotilaksi ja Go:ssa kirjoitettiin logiikka uudelleen, koska alennusten mekaniikka oli hieman muuttunut ja palvelusta puuttui suorituskyky.
Yksi kriittisimmistä palveluista on käyttäjäprofiili. Eli kaikki Wildberryn käyttäjät on tallennettu Tarantooliin, ja heitä on noin 50 miljoonaa. Käyttäjätunnuksen jakama järjestelmä, joka on jaettu useisiin Go-palveluihin kytkettyihin DC:ihin.
RPS:n mukaan Promoter oli kerran johtaja ja saavutti 6 tuhatta pyyntöä. Jossain vaiheessa meillä oli 50-60 kappaletta. Nyt RPS:n kärjessä ovat käyttäjäprofiilit, noin 12 20. Tämä palvelu käyttää mukautettua shardingia, joka on jaettu käyttäjätunnuksilla. Palvelu palvelee yli 4 konetta, mutta tämä on liikaa, aiomme vähentää allokoituja resursseja, koska siihen riittää 5-XNUMX koneen kapasiteetti.
Istuntopalvelu on ensimmäinen vshard- ja Cartridge-palvelumme. Vshardin asentaminen ja kasetin päivittäminen vaati meiltä vaivaa, mutta lopulta kaikki sujui.
Palvelu erilaisten bannerien näyttämiseen verkkosivuilla ja mobiilisovelluksessa oli ensimmäisiä, jotka julkaistiin suoraan Tarantoolissa. Tämä palvelu on tunnettu siitä, että se on 6-7 vuotta vanha, se on edelleen toiminnassa eikä sitä ole koskaan käynnistetty uudelleen. Master-master replikaatiota käytettiin. Mikään ei koskaan mennyt rikki.
On esimerkki Tarantoolin käyttämisestä varastojärjestelmän pikaohjetoimintoihin tietojen nopeaan uudelleentarkistamiseen joissakin tapauksissa. Yritimme käyttää Redistä tähän, mutta muistissa olevat tiedot veivät enemmän tilaa kuin Tarantool.
Tarantoolin kanssa toimivat myös jonotuslistan, asiakastilausten, tällä hetkellä muodikkaiden tarinoiden ja viivästettujen tavaroiden palvelut. Viimeinen palvelu muistissa vie noin 120 Gt. Tämä on kattavin palvelu yllä olevista.
Johtopäätös
Toissijaisten indeksien, avainarvojen ja transaktioiden yhdistämisen ansiosta Tarantool sopii hyvin mikropalvelupohjaisiin arkkitehtuureihin. Kohtasimme kuitenkin vaikeuksia ottaessamme käyttöön muutoksia palveluihin, joissa oli paljon logiikkaa Luassa - palvelut lakkasivat usein toimimasta. Emme voineet voittaa tätä, ja ajan myötä päädyimme erilaisiin Lua- ja Go-yhdistelmiin: tiedämme, missä käyttää yhtä kieltä ja missä toista.
Mitä muuta luettavaa aiheesta
- Suuren kuormituksen sovelluksen luominen alusta alkaen Tarantoolilla
- Luotettu johtajavalinta Tarantool-patruunassa
- Telegram-kanava Tarantool uutisilla tuotteesta
- Keskustele Tarantoolista yhteisön chatissa
Lähde: will.com