Cu toții iubim poveștile. Ne place să stăm în jurul focului și să vorbim despre victoriile noastre trecute, bătăliile sau pur și simplu despre experiența noastră de lucru.
Astăzi este doar o astfel de zi. Și chiar dacă nu ești la foc chiar acum, avem o poveste pentru tine. Povestea cum am început să lucrăm cu stocarea pe Tarantool.
Pe vremuri, compania noastră avea câțiva „monoliți” și un „tavan” pentru toți, de care acești monoliți se apropiau încet, dar sigur, limitând zborul companiei noastre, dezvoltarea noastră. Și a existat o înțelegere clară: într-o zi vom lovi puternic acest plafon.
Acum este ideologia predominantă a separării totul și a tuturor, de la echipamente la logica de afaceri. Ca rezultat, avem, de exemplu, două DC-uri care sunt practic independente la nivel de rețea. Și apoi totul a fost complet diferit.
Astăzi, există o mulțime de instrumente și instrumente pentru a face modificări sub formă de CI/CD, K8S etc. În timpul „monolitic”, nu aveam nevoie de atâtea cuvinte străine. A fost suficient să corectăm pur și simplu „stocarea” din baza de date.
Dar timpul a avansat și numărul de solicitări a evoluat odată cu el, uneori împușcând RPS peste capacitățile noastre. Odată cu intrarea pe piață a țărilor CSI, sarcina procesorului de baze de date al primului monolit nu a scăzut sub 90%, iar RPS a rămas la nivelul de 2400. Și acestea nu erau doar selectoare mici, ci interogări puternice cu o o grămadă de verificări și JOIN-uri care ar putea rula aproape jumătate din date pe fundalul unei IO mari.
Când vânzările cu drepturi depline de Black Friday au început să apară pe scenă - iar Wildberries a fost unul dintre primii care le-a ținut în Rusia - situația a devenit complet tristă. La urma urmei, sarcina în astfel de zile crește de trei ori.
Oh, aceste „vremuri monolitice”! Sunt sigur că ați trăit ceva asemănător și încă nu puteți înțelege cum vi se poate întâmpla asta.
Ce poți face - moda este inerentă tehnologiei. În urmă cu aproximativ 5 ani, a trebuit să regândim unul dintre aceste moduri sub forma unui site existent pe serverul .NET și MS SQL, care a stocat cu grijă toată logica site-ului în sine. L-am păstrat atât de atent încât să fie ferăstrăul unui astfel de monolit s-a dovedit a fi o plăcere lungă și deloc ușoară.
O mică digresiune.
La diverse evenimente spun: „dacă nu ai văzut un monolit, atunci nu ai crescut!” Ma intereseaza parerea ta in aceasta privinta, te rog sa o scrii in comentarii.
Un sunet de tunet
Să revenim la „focul” nostru. Pentru a distribui încărcătura funcționalității „monolitice”, am decis să împărțim sistemul în microservicii bazate pe tehnologii opensource. Pentru că, cel puțin, sunt mai ieftin la scară. Și am înțeles 100% că va trebui să scalam (și foarte mult). La urma urmei, deja în acel moment era posibilă intrarea pe piețele țărilor vecine, iar numărul de înregistrări, precum și numărul de comenzi, au început să crească și mai puternic.
Analizând primii candidați pentru plecarea de la monolit la microservicii, ne-am dat seama că 80% din scrisul din acestea provine din sistemele de back office, iar citirea din front office. În primul rând, aceasta a vizat câteva subsisteme importante pentru noi - datele utilizatorilor și un sistem de calculare a costului final al mărfurilor pe baza informațiilor despre reduceri și cupoane suplimentare ale clienților.
Indentat. Acum este înfricoșător de imaginat, dar pe lângă subsistemele menționate mai sus, cataloagele de produse, un coș de cumpărături pentru utilizatori, un sistem de căutare de produse, un sistem de filtrare pentru cataloagele de produse și diverse tipuri de sisteme de recomandare au fost, de asemenea, eliminate din monolit. Pentru funcționarea fiecăruia dintre ele, există clase separate de sisteme adaptate îngust, dar cândva, toți locuiau într-o singură „casă”.
Ne-am planificat imediat să transferăm datele despre clienții noștri în sistemul sharded. Eliminarea funcționalității pentru calcularea costului final al mărfurilor a necesitat o scalabilitate bună pentru citire, deoarece a creat cea mai mare încărcare RPS și a fost cel mai dificil de implementat pentru baza de date (în procesul de calcul sunt implicate o mulțime de date).
Drept urmare, am venit cu o schemă care se potrivește bine cu Tarantool.
La acel moment, pentru operarea microserviciilor, s-au ales scheme de lucru cu mai multe centre de date pe mașini virtuale și hardware. După cum se arată în figuri, opțiunile de replicare Tarantool au fost aplicate atât în modurile master-master cât și master-slave.
Arhitectură. Opțiunea 1. Serviciu utilizator
În prezent, există 24 de fragmente, fiecare dintre ele având 2 instanțe (una pentru fiecare DC), toate în modul master-master.
Pe partea de sus a bazei de date sunt aplicații care accesează replicile bazei de date. Aplicațiile funcționează cu Tarantool prin biblioteca noastră personalizată, care implementează interfața driverului Tarantool Go. Ea vede toate replicile și poate lucra cu maestrul pentru a citi și a scrie. În esență, implementează modelul setului de replici, care adaugă o logică pentru selectarea replicilor, efectuarea de reîncercări, un întrerupător și o limită de rată.
În acest caz, este posibilă configurarea politicii de selecție a replicilor în contextul fragmentelor. De exemplu, roundrobin.
Arhitectură. Opțiunea 2. Serviciu de calcul al costului final al mărfurilor
În urmă cu câteva luni, majoritatea solicitărilor de calculare a costului final al mărfurilor au mers către un serviciu nou, care, în principiu, funcționează fără baze de date, dar în urmă cu ceva timp totul a fost procesat 100% de un serviciu cu Tarantool sub capotă.
Baza de date de servicii constă din 4 master în care sincronizatorul colectează date și fiecare dintre acești master de replicare distribuie date la replici numai în citire. Fiecare maestru are aproximativ 15 astfel de replici.
Fie în prima, fie în a doua schemă, dacă un DC nu este disponibil, aplicația poate primi date în a doua.
Este demn de remarcat faptul că replicarea în Tarantool este destul de flexibilă și poate fi configurată în timpul execuției. În alte sisteme, au apărut dificultăți. De exemplu, modificarea parametrilor max_wal_senders și max_replication_slots în PostgreSQL necesită o repornire a vrăjitorului, care în unele cazuri poate duce la întreruperea conexiunilor dintre aplicație și DBMS.
Cauta si gaseste!
De ce nu am făcut-o „ca oamenii normali”, ci am ales un mod atipic? Depinde de ceea ce este considerat normal. Mulți oameni fac, în general, un cluster din Mongo și îl răspândesc în trei DC-uri geo-distribuite.
Pe atunci aveam deja două proiecte Redis. Primul a fost un cache, iar al doilea a fost o stocare persistentă pentru date nu prea critice. A fost destul de dificil cu el, parțial din vina noastră. Uneori, volume destul de mari erau în cheie, iar din când în când site-ul a devenit rău. Am folosit acest sistem în versiunea master-slave. Și au fost multe cazuri în care s-a întâmplat ceva cu maestrul și replica s-a stricat.
Adică, Redis este bun pentru sarcini fără stat, nu pentru cele cu stat. În principiu, a permis rezolvarea majorității problemelor, dar numai dacă erau soluții cheie-valoare cu o pereche de indici. Dar Redis la acea vreme era destul de trist de persistență și replicare. În plus, au existat plângeri cu privire la performanță.
Ne-am gândit la MySQL și PostgreSQL. Dar primul nu ne-a prins cumva, iar al doilea este un produs destul de sofisticat în sine și ar fi nepotrivit să construim servicii simple pe el.
Am încercat RIAK, Cassandra, chiar și o bază de date grafică. Toate acestea sunt soluții de nișă care nu erau potrivite pentru rolul unui instrument universal general pentru crearea de servicii.
Până la urmă ne-am hotărât pe Tarantool.
Am apelat la el când era în versiunea 1.6. Ne-a interesat simbioza cheie-valoare și funcționalitatea unei baze de date relaționale. Există indici secundari, tranzacții și spații, acestea sunt ca niște tabele, dar nu simple, puteți stoca diferite numere de coloane în ele. Dar caracteristica ucigașă a Tarantool a fost indici secundari combinați cu cheie-valoare și tranzacționalitate.
Comunitatea de limbă rusă receptivă, gata să ajute în chat, a jucat și ea un rol. Am folosit acest lucru în mod activ și trăim direct în chat. Și nu uitați de persistente decente, fără gafe și greșeli evidente. Dacă te uiți la istoria noastră cu Tarantool, am avut multe dureri și eșecuri cu replicarea, dar nu am pierdut niciodată date din vina lui!
Implementarea a început dur
La acea vreme, stiva noastră principală de dezvoltare era .NET, la care nu exista niciun conector pentru Tarantool. Am început imediat să facem ceva în Go. A funcționat bine și cu Lua. Problema principală la acea vreme era cu depanarea: în .NET totul este grozav cu asta, dar după aceea a fost greu să te plonjezi în lumea Lua încorporată, când nu ai nicio depanare în afară de jurnalele. În plus, din anumite motive replicarea s-a destramat periodic, așa că a trebuit să mă aprofundez în structura motorului Tarantool. Chatul a ajutat în acest sens și, într-o măsură mai mică, documentația ne uităm uneori la cod. La acea vreme, documentația era așa-așa.
Așa că, de-a lungul mai multor luni, am reușit să-mi dau capul și să obțin rezultate decente lucrând cu Tarantool. Am compilat evoluții de referință în git care au ajutat la formarea de noi microservicii. De exemplu, când a apărut o sarcină: pentru a crea un alt microserviciu, dezvoltatorul s-a uitat la codul sursă al soluției de referință din depozit și nu a durat mai mult de o săptămână pentru a crea unul nou.
Erau vremuri speciale. În mod convențional, atunci ai putea să mergi la administratorul de la masa următoare și să întrebi: „Dă-mi o mașină virtuală”. Aproximativ treizeci de minute mai târziu, mașina era deja cu tine. Te-ai conectat, ai instalat totul și ți-a fost trimis trafic.
Astăzi, acest lucru nu va mai funcționa: trebuie să adăugați monitorizare și logare la serviciu, să acoperiți funcționalitatea cu teste, să comandați o mașină virtuală sau să livrați către Kuber etc. În general, va fi mai bine așa, deși va dura mai mult și va fi mai deranjant.
Împărțiți și guvernați. Care e treaba cu Lua?
A existat o dilemă serioasă: unele echipe nu au putut să implementeze în mod fiabil modificări la un serviciu cu multă logică în Lua. Acest lucru a fost adesea însoțit de faptul că serviciul nu funcționează.
Adică, dezvoltatorii pregătesc un fel de schimbare. Tarantool începe să facă migrarea, dar replica este încă cu vechiul cod; Unele DDL sau altceva ajunge acolo prin replicare, iar codul pur și simplu se destramă pentru că nu este luat în considerare. Ca urmare, procedura de actualizare pentru administratori a fost stabilită pe o foaie A4: opriți replicarea, actualizați aceasta, activați replicarea, opriți aici, actualizați acolo. Coșmar!
Drept urmare, acum încercăm cel mai adesea să nu facem nimic în Lua. Utilizați doar iproto (un protocol binar pentru interacțiunea cu serverul) și asta este tot. Poate că aceasta este o lipsă de cunoștințe în rândul dezvoltatorilor, dar din acest punct de vedere sistemul este complex.
Nu întotdeauna urmăm orbește acest scenariu. Astăzi nu avem alb-negru: fie totul este în Lua, fie totul este în Go. Înțelegem deja cum le putem combina pentru a nu avea probleme de migrație mai târziu.
Unde este Tarantool acum?
Tarantool este folosit în serviciu pentru calcularea costului final al mărfurilor ținând cont de cupoanele de reducere, cunoscute și sub denumirea de „Promotor”. După cum spuneam mai devreme, acum se pensionează: este înlocuit cu un nou serviciu de catalog cu prețuri precalculate, dar în urmă cu șase luni toate calculele au fost făcute în Promotizer. Anterior, jumătate din logica sa era scrisă în Lua. În urmă cu doi ani, serviciul a fost transformat într-un depozit, iar logica a fost rescrisă în Go, pentru că mecanica reducerilor se schimbase puțin și serviciul lipsea de performanță.
Unul dintre cele mai critice servicii este profilul utilizatorului. Adică, toți utilizatorii Wildberries sunt stocați în Tarantool și există aproximativ 50 de milioane. Un sistem fragmentat prin ID-ul utilizatorului, distribuit în mai multe DC-uri conectate la serviciile Go.
Potrivit RPS, Promoter a fost cândva lider, ajungând la 6 mii de solicitări. La un moment dat aveam 50-60 de exemplare. Acum, liderul în RPS este profilurile de utilizatori, aproximativ 12 mii. Acest serviciu folosește sharding personalizat, împărțit pe intervale de ID-uri de utilizator. Serviciul deservește mai mult de 20 de mașini, dar acestea sunt prea multe, intenționăm să reducem resursele alocate, deoarece capacitatea de 4-5 mașini este suficientă.
Serviciul de sesiune este primul nostru serviciu pe vshard și Cartridge. Configurarea vshard și actualizarea Cartușului au necesitat un efort din partea noastră, dar în cele din urmă totul a funcționat.
Serviciul de afișare a diferitelor bannere pe site și în aplicația mobilă a fost unul dintre primele care au fost lansate direct pe Tarantool. Acest serviciu se remarcă prin faptul că are 6-7 ani, este încă în funcțiune și nu a fost niciodată repornit. S-a folosit replicarea master-master. Nimic nu s-a rupt vreodată.
Există un exemplu de utilizare a Tarantool pentru funcționalitatea de referință rapidă într-un sistem de depozit pentru a verifica rapid informațiile în unele cazuri. Am încercat să folosim Redis pentru asta, dar datele din memorie au ocupat mai mult spațiu decât Tarantool.
Cu Tarantool funcționează și serviciile unei liste de așteptare, abonamentele clienților, poveștile la modă în prezent și bunurile amânate. Ultimul serviciu din memorie ocupă aproximativ 120 GB. Acesta este cel mai cuprinzător serviciu dintre cele de mai sus.
Concluzie
Datorită indicilor secundari combinați cu cheie-valoare și tranzacționalitate, Tarantool este foarte potrivit pentru arhitecturile bazate pe microservicii. Cu toate acestea, am întâmpinat dificultăți la implementarea modificărilor la serviciile cu multă logică în Lua - serviciile au încetat adesea să funcționeze. Nu am reușit să depășim acest lucru și, de-a lungul timpului, am ajuns la diferite combinații de Lua și Go: știm unde să folosim o limbă și unde să folosim alta.
Ce să mai citești pe subiect
- Crearea unei aplicații cu încărcare mare de la zero folosind Tarantool
- Alegere lider de încredere în Cartușul Tarantool
- Canalul Telegram Tarantool cu noutăți despre produs
- Discutați despre Tarantool în chatul comunității
Sursa: www.habr.com
