Við elskum öll sögur. Okkur finnst gaman að sitja í kringum eldinn og tala um fyrri sigra okkar, bardaga eða einfaldlega starfsreynslu okkar.
Í dag er bara svona dagur. Og jafnvel þótt þú sért ekki við eldinn núna, höfum við sögu handa þér. Sagan af því hvernig við byrjuðum að vinna með geymslu á Tarantool.
Einu sinni var fyrirtækið okkar með nokkra „einlita“ og eitt „þak“ fyrir alla, sem þessir einlitar nálguðust hægt en örugglega að, sem takmarkaði flug fyrirtækisins okkar, þróun okkar. Og það var skýr skilningur: einn daginn munum við ná þessu þaki harkalega.
Það er nú ríkjandi hugmyndafræði að aðskilja allt og alla, frá búnaði til viðskiptarökfræði. Fyrir vikið höfum við til dæmis tvo DC sem eru nánast óháðir á netstigi. Og þá var allt öðruvísi.
Í dag er mikið af verkfærum og tólum til að gera breytingar í formi CI/CD, K8S o.fl. Á „einlita“ tímanum þurftum við ekki svo mörg erlend orð. Það var nóg að leiðrétta einfaldlega „geymsluna“ í gagnagrunninum.
En tíminn færðist áfram og fjöldi beiðna færðist áfram ásamt því, stundum skaut RPS umfram getu okkar. Með innkomu CIS-landanna á markaðinn fór álagið á gagnagrunnsörgjörva fyrsta einliða ekki niður fyrir 90% og RPS hélst á stigi 2400. Og þetta voru ekki bara litlir veljarar, heldur stórar fyrirspurnir með a. fullt af ávísunum og JOINs sem gætu keyrt næstum fyrir helming gagnanna gegn bakgrunni stórra IO.
Þegar fullgild útsala á Black Friday fór að birtast á vettvangi - og Wildberries var einn af þeim fyrstu til að halda þær í Rússlandi - varð ástandið algjörlega sorglegt. Enda eykst álagið á slíkum dögum þrisvar sinnum.
Ó, þessir „einlitu tímar“! Ég er viss um að þú hefur upplifað eitthvað svipað og þú getur ekki enn skilið hvernig þetta gæti gerst fyrir þig.
Hvað getur þú gert - tíska er eðlislæg tækni. Fyrir um það bil 5 árum þurftum við að endurskoða eitt af þessum modum í formi núverandi síðu á .NET og MS SQL server, sem geymdi vandlega alla rökfræði síðunnar sjálfrar. Ég geymdi það svo vandlega að saga slíkan einliða reyndist vera löng og alls ekki auðveld ánægja.
Lítil þjöppun.
Við ýmsa atburði segi ég: "Ef þú sást ekki einlita, þá stækkaðir þú ekki!" Ég hef áhuga á áliti þínu á þessu máli, vinsamlegast skrifaðu það í athugasemdir.
Þrumuhljóð
Snúum okkur aftur að „brennunni“. Til að dreifa álaginu á „einhverfa“ virkni, ákváðum við að skipta kerfinu í örþjónustur byggðar á opnum uppspretta tækni. Vegna þess að þeir eru að minnsta kosti ódýrari í mælikvarða. Og við höfðum 100% skilning á því að við þyrftum að skala (og mikið). Þegar öllu er á botninn hvolft, þegar á þeim tíma var hægt að komast inn á markaði nágrannalandanna, og fjöldi skráninga, sem og fjöldi pantana, fór að vaxa enn meira.
Eftir að hafa greint fyrstu umsækjendurna um að fara frá einliðaleiknum yfir í örþjónustur, komumst við að því að 80% af skrifunum í þeim kemur frá bakskrifstofukerfum og lestri frá skrifstofunni. Í fyrsta lagi snerti þetta nokkur mikilvæg undirkerfi fyrir okkur - notendagögn og kerfi til að reikna út endanlegt vöruverð byggt á upplýsingum um viðbótarafslátt viðskiptavina og afsláttarmiða.
Inndregin. Nú er skelfilegt að ímynda sér það, en auk ofangreindra undirkerfa voru vörulistar, innkaupakerfa fyrir notendur, vöruleitarkerfi, síunarkerfi fyrir vörulista og ýmis konar meðmælakerfi einnig fjarlægð úr einliðaleiknum okkar. Fyrir rekstur hvers þeirra eru aðskildir flokkar af þröngt sérsniðnum kerfum, en einu sinni bjuggu þau öll í einu „húsi“.
Við ætluðum strax að flytja gögn um viðskiptavini okkar yfir í brotna kerfið. Fjarlæging á virkni til að reikna út endanlega vörukostnað krafðist góðs sveigjanleika fyrir lestur, vegna þess að það skapaði mesta RPS álag og var erfiðast í framkvæmd fyrir gagnagrunninn (mörg gögn koma við sögu í útreikningsferlinu).
Fyrir vikið komum við með kerfi sem passar vel við Tarantool.
Á þeim tíma, fyrir rekstur örþjónustu, voru kerfi til að vinna með nokkrum gagnaverum á sýndar- og vélbúnaðarvélum valin. Eins og sýnt er á myndunum var Tarantool afritunarvalkostum beitt í bæði master-master og master-slave ham.
Arkitektúr. Valkostur 1. Notendaþjónusta
Í augnablikinu eru 24 shards, sem hvert um sig hefur 2 tilvik (eitt fyrir hvern DC), öll í master-master ham.
Ofan á gagnagrunninum eru forrit sem fá aðgang að eftirmyndum gagnagrunns. Forrit vinna með Tarantool í gegnum sérsniðna bókasafnið okkar, sem útfærir Tarantool Go bílstjóraviðmótið. Hún sér allar eftirmyndirnar og getur unnið með meistaranum við að lesa og skrifa. Í meginatriðum útfærir það eftirlíkingarsett líkanið, sem bætir við rökfræði til að velja eftirlíkingar, framkvæma endurtekningar, aflrofa og hraðatakmörk.
Í þessu tilviki er hægt að stilla eftirmyndavalstefnuna í samhengi við shards. Til dæmis, roundrobin.
Arkitektúr. Valkostur 2. Þjónusta við útreikning á endanlegum vörukostnaði
Fyrir nokkrum mánuðum fóru flestar beiðnir um útreikning á endanlegum vörukostnaði til nýrrar þjónustu, sem í grundvallaratriðum virkar án gagnagrunna, en fyrir nokkru var allt afgreitt 100% af þjónustu með Tarantool undir húddinu.
Þjónustugagnagrunnurinn samanstendur af 4 herrum sem samstillingartækið safnar gögnum í og hver þessara afritunarmeistara dreifir gögnum til skrifvarins eftirmynda. Hver meistari hefur um það bil 15 slíkar eftirmyndir.
Annaðhvort í fyrra eða öðru kerfi, ef einn DC er ekki tiltækur, getur forritið tekið á móti gögnum í öðru.
Það er athyglisvert að afritun í Tarantool er nokkuð sveigjanleg og hægt að stilla hana á keyrslutíma. Í öðrum kerfum komu upp erfiðleikar. Til dæmis, til að breyta breytum max_wal_senders og max_replication_slots í PostgreSQL, krefst þess að töframaðurinn sé endurræstur, sem í sumum tilfellum getur leitt til þess að tengingar milli forritsins og DBMS rofna.
Leitaðu og þú munt finna!
Af hverju gerðum við það ekki „eins og venjulegt fólk“ en völdum óhefðbundna leið? Það fer eftir því hvað telst eðlilegt. Margir búa almennt til þyrping úr Mongo og dreifa honum yfir þrjú landdreifð DC.
Á þeim tíma vorum við þegar með tvö Redis verkefni. Hið fyrra var skyndiminni og hið síðara var viðvarandi geymsla fyrir ekki of mikilvæg gögn. Það var frekar erfitt með hann, að hluta til fyrir okkur að kenna. Stundum var töluvert mikið magn í lyklinum og af og til varð síða illa haldin. Við notuðum þetta kerfi í master-slave útgáfunni. Og það voru mörg tilvik þar sem eitthvað kom fyrir húsbóndann og eftirmyndun bilaði.
Það er að segja, Redis er gott fyrir ríkisfangslaus verkefni, ekki ríkjandi. Í grundvallaratriðum gerði það kleift að leysa flest vandamál, en aðeins ef þau voru lykilgildislausnir með par af vísitölum. En Redis á þessum tíma var frekar dapur með þrautseigju og endurtekningu. Auk þess var kvartað yfir frammistöðu.
Við hugsuðum um MySQL og PostgreSQL. En sú fyrri náði einhvern veginn ekki á okkur, og sú seinni er frekar háþróuð vara í sjálfu sér og það væri óviðeigandi að byggja einfalda þjónustu á hana.
Við prófuðum RIAK, Cassandra, jafnvel grafgagnagrunn. Allt eru þetta nokkuð sesslausnir sem hentuðu ekki hlutverki almenns alhliða tækis til að skapa þjónustu.
Á endanum settumst við á Tarantool.
Við snerum okkur að því þegar það var í útgáfu 1.6. Við höfðum áhuga á því vegna sambýlis lykilgildis og virkni tengslagagnagrunns. Það eru aukavísitölur, viðskipti og bil, þetta eru eins og töflur, en ekki einfalt, þú getur geymt mismunandi fjölda dálka í þeim. En drápseiginleikinn í Tarantool var aukavísitölur ásamt lykilgildi og viðskiptavirkni.
Móttækilegt rússneskumælandi samfélag, tilbúið til að hjálpa í spjalli, gegndi einnig hlutverki. Við notuðum þetta virkan og lifum beint í spjallinu. Og ekki gleyma ágætis þrálátri án augljósra mistaka og mistaka. Ef þú horfir á sögu okkar með Tarantool, áttum við mikinn sársauka og bilanir við afritun, en við töpuðum aldrei gögnum vegna þess að kenna!
Innleiðingin fór illa af stað
Á þeim tíma var aðal þróunarstafla okkar .NET, sem ekkert tengi var fyrir Tarantool. Við byrjuðum strax að gera eitthvað í Go. Það virkaði vel með Lua líka. Aðalvandamálið á þeim tíma var kembiforritið: í .NET er allt frábært við þetta, en eftir það var erfitt að sökkva sér inn í heim embedd Lua, þegar þú ert ekki með neina kembiforrit nema logs. Að auki, af einhverjum ástæðum féll afritun reglulega í sundur, svo ég þurfti að kafa ofan í uppbyggingu Tarantool vélarinnar. Spjallið hjálpaði við þetta, og í minna mæli, skjölin; stundum skoðuðum við kóðann. Á þeim tíma voru skjölin svo sem svo.
Svo, á nokkrum mánuðum, tókst mér að ná hausnum á mér og ná ágætis árangri af því að vinna með Tarantool. Við tókum saman tilvísunarþróun í git sem hjálpaði til við myndun nýrra örþjónustu. Til dæmis, þegar verkefni kom upp: að búa til aðra örþjónustu, skoðaði verktaki frumkóðann fyrir tilvísunarlausnina í geymslunni og það tók ekki meira en viku að búa til nýja.
Þetta voru sérstakir tímar. Venjulega gætirðu farið upp að stjórnandanum á næsta borði og spurt: "Gefðu mér sýndarvél." Um þrjátíu mínútum síðar var bíllinn þegar með þér. Þú tengdir sjálfan þig, settir allt upp og umferð var send til þín.
Í dag mun þetta ekki virka lengur: þú þarft að bæta eftirliti og skráningu við þjónustuna, ná yfir virknina með prófunum, panta sýndarvél eða afhendingu til Kuber osfrv. Almennt séð verður þetta betra með þessum hætti, þó að það taki lengri tíma og verði erfiðara.
Deila og drottna. Hvað er málið með Lua?
Það var alvarlegt vandamál: sum teymi gátu ekki framkallað breytingar á áreiðanlegan hátt á þjónustu með mikla rökfræði í Lua. Því fylgdi oft að þjónustan virkaði ekki.
Það er, verktaki eru að undirbúa einhvers konar breytingu. Tarantool byrjar að flytja, en eftirmyndin er enn með gamla kóðanum; Einhver DDL eða eitthvað annað kemur þangað í gegnum afritun og kóðinn einfaldlega fellur í sundur vegna þess að það er ekki tekið tillit til hans. Fyrir vikið var uppfærsluferlið fyrir stjórnendur sett á A4 blað: stöðva afritun, uppfærðu þetta, kveiktu á afritun, slökktu hér, uppfærðu þar. Martröð!
Þess vegna reynum við nú oftast að gera ekkert í Lua. Notaðu bara iproto (tvíundarsamskiptareglur til að hafa samskipti við netþjóninn), og það er það. Kannski er þetta skortur á þekkingu meðal þróunaraðila, en frá þessu sjónarhorni er kerfið flókið.
Við fylgjum þessu handriti ekki alltaf í blindni. Í dag höfum við ekki svart og hvítt: annað hvort er allt í Lua eða allt er í Go. Við skiljum nú þegar hvernig við getum sameinað þau svo að við lendum ekki í flutningsvandamálum síðar.
Hvar er Tarantool núna?
Tarantool er notað í þjónustunni til að reikna út endanlegan kostnað vöru að teknu tilliti til afsláttarmiða, einnig þekktur sem „Promoter“. Eins og ég sagði áðan lætur hann nú af störfum: í stað hans kemur ný vörulistaþjónusta með fyrirfram útreiknuðu verði, en fyrir hálfu ári voru allir útreikningar gerðir í Promotizer. Áður var helmingur rökfræðinnar skrifaður í Lua. Fyrir tveimur árum var þjónustunni breytt í geymsluhúsnæði og rökfræðin endurskrifuð í Go, því afslættir höfðu aðeins breyst og þjónustan vantaði afköst.
Ein mikilvægasta þjónustan er notendasniðið. Það er að segja að allir Wildberries notendur eru geymdir í Tarantool, og þeir eru um 50 milljónir. Kerfi sem er skipt niður með notendaauðkenni, dreift yfir nokkra DC sem tengjast Go þjónustu.
Samkvæmt RPS var Promoter einu sinni leiðtogi og náði 6 þúsund beiðnum. Á einum tímapunkti vorum við með 50-60 eintök. Nú er leiðandi í RPS notendasnið, um 12 þúsund. Þessi þjónusta notar sérsniðna klippingu, deilt með sviðum notendaauðkenna. Þjónustan þjónar meira en 20 vélum, en þetta er of mikið, við ætlum að draga úr úthlutað fjármagni, því afkastageta 4-5 véla dugar til þess.
Session þjónusta er fyrsta þjónusta okkar á vshard og hylki. Að setja upp vshard og uppfæra Cartridge krafðist nokkurrar fyrirhafnar af okkur, en á endanum gekk allt upp.
Þjónustan til að sýna mismunandi borða á vefsíðunni og í farsímaforritinu var ein sú fyrsta sem var gefin út beint á Tarantool. Þessi þjónusta er áberandi fyrir þá staðreynd að hún er 6-7 ára, hún er enn í gangi og hefur aldrei verið endurræst. Notast var við Master-master afritun. Aldrei brotnaði neitt.
Dæmi er um að nota Tarantool fyrir skjótviðmiðunarvirkni í vöruhúsakerfi til að tvískoða upplýsingar fljótt í sumum tilfellum. Við reyndum að nota Redis fyrir þetta, en gögnin í minni tóku meira pláss en Tarantool.
Þjónusta biðlista, áskriftar viðskiptavina, sögur í tísku og frestað vara virkar einnig með Tarantool. Síðasta þjónustan í minni tekur um 120 GB. Þetta er umfangsmesta þjónustan af ofangreindum.
Ályktun
Þökk sé aukavísitölum ásamt lykilgildi og viðskiptamöguleika hentar Tarantool vel fyrir arkitektúr sem byggir á örþjónustu. Hins vegar lentum við í erfiðleikum við að útfæra breytingar á þjónustu með mikilli rökfræði í Lua - þjónustan hætti oft að virka. Okkur tókst ekki að sigrast á þessu og með tímanum komumst við að mismunandi samsetningum af Lua og Go: við vitum hvar á að nota eitt tungumál og hvar á að nota annað.
Hvað annað að lesa um efnið
- Að búa til mikið álagsforrit frá grunni með Tarantool
- Traust leiðtogaval í Tarantool hylki
- Telegram rás Tarantool með fréttum um vöruna
- Ræddu Tarantool í samfélagsspjallinu
Heimild: www.habr.com