Denok maite ditugu istorioak. Gustatzen zaigu suaren inguruan esertzea eta gure iraganeko garaipenez, guduez edo, besterik gabe, gure lan-esperientziaz hitz egitea.
Gaurkoa halako eguna besterik ez da. Eta une honetan sutan ez bazaude ere, istorio bat dugu zuretzat. Tarantool-en biltegiratzearekin lan egiten hasi ginenaren istorioa.
Garai batean, gure konpainiak βmonolitoβ pare bat eta guztientzako βsabaiβ bat zituen, eta horietara monolito hauek poliki-poliki hurbiltzen ari ziren, gure konpainiaren hegaldia mugatuz, gure garapena. Eta ulermen argia zegoen: egunen batean gogor joko dugu sabai hau.
Gaur egun, dena eta denak bereizteko ideologia da nagusi, ekipamenduetatik hasi eta negozio logikaraino. Ondorioz, guk, adibidez, sare mailan ia independenteak diren bi DC ditugu. Eta orduan dena guztiz ezberdina zen.
Gaur egun, tresna eta tresna asko daude aldaketak egiteko CI/CD, K8S, etab. Garai βmonolitikoanβ ez genuen hainbeste hitz arrotz behar. Nahikoa zen datu-baseko "biltegiratzea" zuzentzea besterik gabe.
Baina denborak aurrera egin zuen, eta eskaera kopuruak aurrera egin zuen harekin batera, batzuetan RPS-a gure gaitasunetatik haratago jaurtiz. CIS herrialdeak merkatuan sartzean, lehen monolitoaren datu-basearen prozesadorearen karga ez zen % 90etik behera jaitsi, eta RPS 2400 mailan geratu zen. IO handiaren atzealdean datuen erdia ia exekutatu ahal izango diren egiaztapen eta JOIN sorta.
Black Friday osoko salmentak eszenan agertzen hasi zirenean -eta Wildberries izan zen Errusian eduki zituen lehenetarikoa- egoera erabat triste bihurtu zen. Azken finean, halako egunetan karga hiru aldiz handitzen da.
Ai, βgarai monolitikoβ hauek! Ziur nago antzeko zerbait bizi izan duzula, eta oraindik ezin duzula ulertu nola gerta dakizun hori.
Zer egin dezakezu - moda teknologiaren berezkoa da. Duela 5 urte inguru, mod horietako bat birplanteatu behar izan genuen .NET eta MS SQL zerbitzarian lehendik zegoen gune baten moduan, zeinak arreta handiz gordetzen baitzuen gunearen beraren logika guztia. Hain kontu handiz gorde nuen monolito hori zerratzea plazer luzea eta ez zen batere erraza izan zela.
Digresio txiki bat.
Hainbat ekitalditan esaten dut: "monolitorik ikusten ez bazenu, ez zinen hazi!" Gai honi buruzko zure iritzia interesatzen zait, mesedez idatzi iruzkinetan.
Trumoi Soinua
Itzuli gaitezen gure βsutaraβ. Funtzionalitate "monolitikoaren" karga banatzeko, sistema irekiko teknologietan oinarritutako mikrozerbitzuetan banatzea erabaki genuen. Gutxienez, eskalatzeko merkeagoak direlako. Eta %100ean ulertu genuen eskalatu beharko genuela (eta asko). Azken finean, garai hartan jada aldameneko herrialdeetako merkatuetan sartzea posible zen, eta erregistro-kopurua, baita eskaera-kopurua ere, are indartsuago hazten hasi ziren.
Monolitotik mikrozerbitzuetara irteteko lehen hautagaiak aztertuta, haietako idazketaren %80 back office sistemetatik datorrela konturatu ginen, eta front office-tik irakurtzea. Lehenik eta behin, guretzat azpisistema garrantzitsu batzuk ziren: erabiltzaileen datuak eta salgaien azken kostua kalkulatzeko sistema bat, bezeroen deskontu eta kupoi gehigarriei buruzko informazioan oinarrituta.
Koskatuta. Orain beldurgarria da imajinatzea, baina aipatutako azpisistemez gain, produktuen katalogoak, erabiltzaileen erosketa saskia, produktuak bilatzeko sistema, produktuen katalogoetarako iragazketa sistema eta hainbat gomendio sistema ere kendu ziren gure monolitotik. Horietako bakoitzaren funtzionamendurako, neurri estuan dauden sistemen klase bereiziak daude, baina garai batean guztiak "etxe" batean bizi ziren.
Berehala gure bezeroei buruzko datuak sharded sistemara transferitzea aurreikusi genuen. Ondasunen azken kostua kalkulatzeko funtzionalitateak kentzeak eskalagarritasun ona behar zuen irakurtzeko, RPS karga handiena sortzen zuelako eta datu-baserako ezartzeko zailena zelako (datu asko parte hartzen dute kalkulu-prozesuan).
Ondorioz, Tarantoolekin ondo egokitzen den eskema bat atera genuen.
Garai hartan, mikrozerbitzuen funtzionamendurako, hainbat datu-zentrorekin makina birtualetan eta hardwarean lan egiteko eskemak aukeratu ziren. Irudietan ikusten den bezala, Tarantool erreplikazio-aukerak maisu-maisu zein maisu-esklabo moduetan aplikatu ziren.
Arkitektura. 1. aukera. Erabiltzaile-zerbitzua
Une honetan, 24 zati daude, eta horietako bakoitzak 2 instantzia ditu (bat DC bakoitzeko), guztiak master-master moduan.
Datu-basearen gainean datu-basearen errepliketan sartzen diren aplikazioak daude. Aplikazioek Tarantool-ekin lan egiten dute gure liburutegi pertsonalizatuaren bidez, Tarantool Go kontrolatzailearen interfazea ezartzen duena. Erreplika guztiak ikusten ditu eta maisuarekin lan egin dezake irakurtzen eta idazten. Funtsean, erreplika-multzoaren eredua inplementatzen du, erreplikak hautatzeko, berriro saiakerak egiteko, etengailu bat eta tasa-muga gehitzeko logika gehitzen duena.
Kasu honetan, erreplika hautatze-politika konfiguratu daiteke zatien testuinguruan. Adibidez, roundrobin.
Arkitektura. 2. aukera. Salgaien azken kostua kalkulatzeko zerbitzua
Duela hilabete batzuk, salgaien azken kostua kalkulatzeko eskaera gehienak zerbitzu berri batera joan ziren, printzipioz datu-baserik gabe funtzionatzen duena, baina duela denbora pixka bat % 100ean prozesatu zuen Tarantool-ek kanpaia azpian zuen zerbitzu batek.
Zerbitzuaren datu-baseak 4 maisu ditu eta horietan sinkronizatzaileak datuak biltzen ditu, eta erreplika-maisu horietako bakoitzak datuak irakurtzeko soilik errepliketan banatzen ditu. Maisu bakoitzak horrelako 15 erreplika ditu gutxi gorabehera.
Lehen edo bigarren eskeman, DC bat erabilgarri ez badago, aplikazioak datuak jaso ditzake bigarrenean.
Aipatzekoa da Tarantool-en erreplikazioa nahiko malgua dela eta exekuzioan konfigura daitekeela. Beste sistemetan, zailtasunak sortu ziren. Esaterako, PostgreSQL-n max_wal_senders eta max_replication_slots parametroak aldatzeak morroia berrabiarazi behar du, eta, kasu batzuetan, aplikazioaren eta DBMSren arteko konexioak moztu daitezke.
Bilatu eta aurkituko duzu!
Zergatik ez genuen egin "pertsona normalak bezala", baina modu atipikoa aukeratu genuen? Normaltzat jotzen denaren araberakoa da. Jende askok, oro har, kluster bat egiten du Mongotik eta hiru geo-banatutako DC-tan zabaltzen du.
Garai hartan, jada bi Redis proiektu genituen. Lehenengoa cachea zen, eta bigarrena datu kritikoegiak ez izateko biltegiratze iraunkorra. Berarekin nahiko zaila izan zen, neurri batean gure erruagatik. Batzuetan nahiko bolumen handiak zeuden klabean, eta noizean behin aztarnategia ondoezik geratzen zen. Sistema hau maisu-esklabo bertsioan erabili dugu. Eta kasu asko izan ziren non maisuari zerbait gertatu zitzaion eta erreplikazioa matxuratu zen.
Hau da, Redis ona da estaturik gabeko zereginetarako, ez estatudunetarako. Printzipioz, arazo gehienak konpontzea ahalbidetzen zuen, baina indize pareko gako-balioen soluzioak balira. Baina Redis garai hartan nahiko triste zegoen iraunkortasunarekin eta errepikapenarekin. Horrez gain, errendimenduaren inguruko kexak egon ziren.
MySQL eta PostgreSQL-en inguruan pentsatu dugu. Baina lehena nolabait ez zitzaigun harrapatu, eta bigarrena produktu nahiko sofistikatua da berez, eta desegokia izango litzateke bertan zerbitzu sinpleak sortzea.
RIAK, Cassandra, baita datu-base grafiko bat ere probatu genuen. Horiek guztiak nahiko nitxoko irtenbideak dira, zerbitzuak sortzeko tresna unibertsal orokor baten zereginerako egokiak ez zirenak.
Azkenean Tarantool-en finkatu ginen.
Bertara jo genuen 1.6 bertsioan zegoenean. Gako-balioaren sinbiosia eta datu-base erlazional baten funtzionaltasuna interesatzen zitzaigun. Bigarren indizeak, transakzioak eta espazioak daude, hauek taulak bezalakoak dira, baina ez dira sinpleak, zutabe kopuru desberdinak gorde ditzakezu horietan. Baina Tarantool-en ezaugarri hilgarria bigarren mailako indizeak ziren gako-balioarekin eta transakziotasunarekin konbinatuta.
Errusieraz mintzatzen den komunitate sentikorra, txatean laguntzeko prest, zeresana izan zuen. Hau aktiboki erabili dugu eta zuzenean txatean bizi gara. Eta ez ahaztu akats eta akats nabaririk gabeko iraunkorra. Tarantool-ekin gure historiari erreparatzen badiozu, min eta hutsegite asko izan ditugu erreplikarekin, baina ez dugu inoiz datuak galdu bere erruagatik!
Inplementazioak hasiera gogorra izan zuen
Garai hartan, gure garapen pila nagusia .NET zen, eta ez zegoen Tarantoolerako konektorerik. Berehala hasi ginen Go-n zerbait egiten. Luarekin ere ondo funtzionatu zuen. Garai hartan arazo nagusia arazketarekin zegoen: .NETen dena bikaina da honekin, baina horren ostean zaila zen Lua txertatuaren munduan murgiltzea, erregistroak izan ezik arazketarik ez duzunean. Horrez gain, arrazoiren batengatik erreplikazioa aldian-aldian gainditzen zen, beraz, Tarantool motorren egituran sakondu behar izan nuen. Txatak horretan lagundu zuen, eta, neurri txikiagoan, dokumentazioan; batzuetan, kodeari erreparatzen genion. Garai hartan, dokumentazioa horrela zen.
Beraz, hainbat hilabetetan zehar, burua ateratzea eta Tarantool-ekin lan egitean emaitza duinak lortzea lortu nuen. Mikrozerbitzu berrien sorreran lagundu duten erreferentzia garapenak bildu ditugu git-en. Adibidez, zeregin bat sortzen zenean: beste mikrozerbitzu bat sortzeko, garatzaileak erreferentziako soluzioaren iturburu-kodea begiratu zuen biltegian, eta astebete baino gehiago behar izan zuen berri bat sortzeko.
Garai bereziak ziren. Ohikoki, ondoko mahaiko administratzailearengana joan eta galdetu dezakezu: "Emaidazu makina birtual bat". Hogeita hamar bat minutu geroago autoa zurekin zegoen jada. Zure burua konektatu, dena instalatu eta trafikoa bidali dizugu.
Gaur egun honek ez du gehiago funtzionatuko: jarraipena eta saioa gehitu behar diozu zerbitzuari, funtzionaltasuna probekin estali, makina birtual bat eskatu edo Kuber-era entregatu, etab. Oro har, hobe izango da horrela, nahiz eta denbora gehiago beharko duen eta traba handiagoa izan.
Zatitu eta gobernatu. Zein da Luarekin?
Dilema larri bat zegoen: talde batzuek ezin izan zuten Luan logika askoko zerbitzu batean aldaketak modu fidagarrian zabaldu. Horrek askotan zerbitzua ez funtzionatzen zuen.
Hau da, garatzaileak nolabaiteko aldaketa prestatzen ari dira. Tarantool migrazioa egiten hasten da, baina erreplikak kode zaharrarekin jarraitzen du; DDL batzuk edo beste zerbait erreplikaren bidez iristen dira bertara, eta kodea besterik gabe erortzen da, kontuan hartzen ez delako. Ondorioz, administratzaileen eguneratze-prozedura A4 orri batean ezarri zen: gelditu erreplikazioa, eguneratu hau, aktibatu erreplikazioa, itzali hemen, eguneratu han. Amesgaiztoa!
Ondorioz, orain gehienetan saiatzen gara Luan ezer egiten. Erabili iproto (zerbitzariarekin elkarreragiteko protokolo bitarra), eta kitto. Agian hau garatzaileen artean ezagutza falta da, baina ikuspuntu horretatik sistema konplexua da.
Ez dugu beti itsu-itsuan jarraitzen gidoi hau. Gaur ez dugu zuri-beltza: edo dena Luan dago, edo dena Go-n dago. Dagoeneko ulertzen dugu nola uztartu ditzakegun, gero migrazio-arazoekin ez amaitzeko.
Non dago orain Tarantool?
Tarantool produktuen azken kostua kalkulatzeko zerbitzuan erabiltzen da deskontu-kupoiak kontuan hartuta, "Sustatzailea" izenez ere ezaguna. Lehen esan bezala, orain erretiroa hartzen ari da: aldez aurretik kalkulatutako prezioak dituen katalogo zerbitzu berri batek ordezkatzen du, baina duela sei hilabete kalkulu guztiak Promotizer-en egin ziren. Aurretik, bere logikaren erdia Luan idazten zen. Duela bi urte zerbitzua biltegiratze bihurtu zen, eta Go-n logika berridatzi zuten, beherapenen mekanika apur bat aldatu zelako eta zerbitzuari errendimendua falta zitzaion.
Zerbitzu kritikoenetako bat erabiltzailearen profila da. Hau da, Wildberries-en erabiltzaile guztiak Tarantoolen gordeta daude, eta horietako 50 milioi inguru daude. Erabiltzaile IDaren arabera zatitutako sistema bat, Go zerbitzuetara konektatutako hainbat DCtan banatuta.
RPSren arabera, Sustatzailea izan zen behin liderra, 6 mila eskaeratara iritsiz. Momentu batean 50-60 ale genituen. Orain RPS-en liderra erabiltzaileen profilak dira, 12 mila inguru. Zerbitzu honek zatiketa pertsonalizatua erabiltzen du, erabiltzaile IDen barrutietan banatuta. Zerbitzuak 20 makina baino gehiago zerbitzatzen ditu, baina hori gehiegi da; esleitutako baliabideak murrizteko asmoa dugu, 4-5 makinako edukiera nahikoa delako horretarako.
Saio zerbitzua vshard eta Cartridge-n gure lehen zerbitzua da. Vshard konfiguratzeak eta Cartridge eguneratzeak esfortzu bat eskatzen zigun, baina azkenean dena ondo atera zen.
Webgunean eta mugikorrerako aplikazioan banner desberdinak erakusteko zerbitzua Tarantool-en zuzenean kaleratu zen lehenetarikoa izan zen. Zerbitzu hau nabarmentzen da 6-7 urte dituelako, oraindik martxan dagoela eta ez dela inoiz berrabiarazi. Master-master erreplikazioa erabili zen. Inoiz ez zen ezer hautsi.
Tarantool-en erabileraren adibide bat dago biltegi-sistema batean erreferentzia bizkorreko funtzionalitateetarako, kasu batzuetan informazioa bizkor egiaztatzeko. Horretarako Redis erabiltzen saiatu ginen, baina memoriako datuek Tarantoolek baino leku gehiago hartzen zuten.
Itxaron-zerrenda baten zerbitzuek, bezeroen harpidetzak, gaur egun modan dauden istorioek eta gerotutako ondasunek ere Tarantool-ekin funtzionatzen dute. Memorian dagoen azken zerbitzuak 120 GB inguru hartzen ditu. Hau da aipatutako zerbitzurik osatuena.
Ondorioa
Gako-balioarekin eta transakzionaltasunarekin konbinatutako bigarren indizeei esker, Tarantool oso egokia da mikrozerbitzuetan oinarritutako arkitekturatarako. Hala ere, zailtasunak aurkitu genituen Luan logika askoko zerbitzuetan aldaketak zabaltzean - maiz zerbitzuek funtzionatzeari uzten zioten. Ezin izan genuen hori gainditu, eta denborarekin Lua eta Go konbinazio ezberdinetara iritsi ginen: badakigu non erabili hizkuntza bat eta non erabili beste bat.
Zer gehiago irakurri gaiari buruz
- Karga handiko aplikazioa hutsetik sortzea Tarantool erabiliz
- Lider fidagarria Tarantool Kartutxoan
- Tarantool Telegram kanala produktuari buruzko albisteekin
- Eztabaidatu Tarantool komunitateko txatean
Iturria: www.habr.com