{"id":92806,"date":"2020-08-31T07:42:03","date_gmt":"2020-08-31T05:42:03","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita"},"modified":"2020-08-31T07:42:03","modified_gmt":"2020-08-31T05:42:03","slug":"kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","status":"publish","type":"post","link":"https:\/\/prohoster.info\/it\/blog\/administrirovanie\/kak-perestat-bespokoitsya-i-nachat-zhit-bez-monolita","title":{"rendered":"Come smettere di preoccuparsi e iniziare a vivere senza monoliti","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n
\nTutti noi amiamo le storie. Ci piace raccontare i nostri successi, battaglie o semplicemente esperienze passate attorno al fuoco.<\/p>\n

Oggi \u00e8 esattamente quel tipo di giorno. E anche se ora non sei attorno al fuoco, abbiamo una storia per te. Una storia su come abbiamo iniziato a lavorare con il database su Tarantool.<\/p>\n

Tanto tempo fa, nella nostra azienda, c'erano un paio di \"monoliti\" e un \"soffitto\" condiviso, verso cui questi monoliti si avvicinavano lentamente ma inesorabilmente, limitando la crescita e lo sviluppo della nostra azienda. E c'era una chiara consapevolezza: un giorno saremmo stati costretti a batterci contro questo soffitto.
\n<\/a><\/noindex>
\nOra abbiamo un'ideologia che promuove la separazione di tutto, dall'hardware alla logica aziendale. Di conseguenza, abbiamo, ad esempio, due datacenter praticamente indipendenti a livello di rete. Ma allora tutto era molto diverso.<\/p>\n

Oggi abbiamo a disposizione una miriade di strumenti e risorse come CI\/CD, K8S, e cos\u00ec via, per apportare modifiche. All'epoca dei \"monoliti\", non avevamo bisogno di tutti questi termini strani. Era sufficiente correggere semplicemente il \"database\".<\/p>\n

Ma il tempo \u00e8 andato avanti, e il numero delle richieste \u00e8 aumentato con esso, arrivando a superare le nostre capacit\u00e0. Entrando nei mercati dell'area CIS, il carico sulla CPU del primo monolito non scendeva mai sotto il 90%, mentre il RPS si mantenva attorno a 2400. E non si trattava solo di piccole selezioni, ma di grandi richieste con un sacco di controlli e JOIN che potevano coinvolgere quasi met\u00e0 dei dati a causa di un grande IO.<\/p>\n

Quando sono iniziate le vere vendite del \"Black Friday\" \u2014 e Wildberries \u00e8 stata una delle prime in Russia a farlo \u2014 la situazione \u00e8 diventata davvero critica. Infatti, il carico in quei giorni triplica.
\nOh, i tempi dei \"monoliti\"! Sono certo che anche tu hai vissuto esperienze simili e non riesci ancora a capire come sia potuto succedere.<\/p>\n

Che ci vuoi fare, anche la moda riguarda le tecnologie. Solo cinque anni fa, ci \u00e8 stato necessario ripensare una di queste mode, il sito esistente su .NET e il server MS SQL, che custodiva gelosamente tutta la logica del sito stesso. Custodiva cos\u00ec bene che dividere un tale monolito \u00e8 diventato un processo lungo e decisamente complicato.
\nUna breve digressione. <\/p>\n

Durante vari eventi dico: \"Se non hai diviso un monolito, significa che non sei cresciuto!\" Mi piacerebbe conoscere la tua opinione in merito, scrivila nei commenti.<\/p>\n

E il tuono si fece sentire<\/h3>\n

\nTornando al nostro \"fuoco\". Per distribuire il carico della funzionalit\u00e0 \"monolitica\", abbiamo deciso di suddividere il sistema in microservizi basati su tecnologie open source. Perch\u00e9, almeno, il loro scalabilit\u00e0 \u00e8 pi\u00f9 economica. E avevamo ben chiaro che sarebbe stato necessario scalare (e non poco) al 100%. Gi\u00e0 a quel tempo avevamo iniziato a entrare nei mercati dei paesi vicini e il numero di registrazioni e ordini iniziava a crescere ancora di pi\u00f9.<\/p>\n

Analizzando i primi candidati ad uscire dal monolito verso i microservizi, abbiamo compreso che nell'80% dei casi le scritture avvengono per il 99% tramite sistemi di back office, mentre le letture provengono dalla fascia anteriore. Questo riguardava principalmente un paio di sottosistemi importanti per noi: i dati degli utenti e il sistema di calcolo del costo finale dei prodotti in base alle informazioni su sconti e coupon.<\/p>\n

A margine. Oggi \u00e8 spaventoso da immaginare, ma oltre ai sottosistemi menzionati, dal nostro monolito sono stati estratti anche cataloghi di prodotti, carrelli, sistemi di ricerca, filtri per cataloghi e vari sistemi di raccomandazione. Ogni sistema ha le proprie classi specializzate, ma un tempo vivevano tutti insieme in un unico \"spazio\". <\/p>\n

Abbiamo pianificato di estrarre subito i dati sui nostri clienti in un sistema shardato. L'estrazione della funzionalit\u00e0 di calcolo del costo finale dei prodotti richiedeva una buona scalabilit\u00e0 nella lettura, poich\u00e9 comportava il maggior carico in RPS ed era molto complessa per il database (in quanto coinvolti molti dati nel processo di calcolo). <\/p>\n

Di conseguenza, abbiamo sviluppato uno schema che si adatta bene a Tarantool.<\/p>\n

A quel tempo, per i microservizi sono stati scelti schemi di lavoro con pi\u00f9 datacenter su macchine virtuali e hardware. Come mostrato nelle immagini, sono state utilizzate configurazioni di replica di Tarantool sia in modalit\u00e0 master-master che master-slave. <\/p>\n

\"Come
\nArchitettura. Opzione 1. Servizio utenti<\/i><\/p>\n

Attualmente ci sono 24 shard, ognuno con 2 istanze (una per ogni datacenter), tutte in modalit\u00e0 master-master.<\/p>\n

Sopra il database ci sono applicazioni che accedono alle repliche del database. Le applicazioni comunicano con Tarantool tramite la nostra libreria personalizzata, che implementa l'interfaccia del driver Go per Tarantool. Essa vede tutte le repliche e pu\u00f2 lavorare con il master sia in lettura che in scrittura. Fondamentalmente, implementa un modello di replica set, con logica per la selezione delle repliche, retry, circuit breaker e rate limiting.<\/p>\n

Inoltre, \u00e8 possibile configurare la politica di selezione della replica per ogni shard. Ad esempio, tramite round-robin.<\/p>\n

\"Come
\nArchitettura. Opzione 2. Servizio per il calcolo del costo finale del prodotto.<\/i><\/p>\n

Alcuni mesi fa, la maggior parte delle richieste per il calcolo del costo finale dei prodotti sono state trasferite a un nuovo servizio che, in sostanza, funziona senza database, ma fino a quel momento il 100% era gestito da un servizio con Tarantool sotto il cofano.<\/p>\n

Il database del servizio \u00e8 composto da 4 master, che sincronizzano i dati, e ognuno di questi master distribuisce i dati alle repliche in sola lettura tramite replicazione. Ogni master ha circa 15 di queste repliche.<\/p>\n

In entrambe le schemi, in caso di inaccessibilit\u00e0 di un data center, l'applicazione pu\u00f2 ottenere dati dall'altro.<\/p>\n

Va notato che in Tarantool la replicazione \u00e8 piuttosto flessibile e configurabile in runtime. In altri sistemi ci sono stati problemi. Ad esempio, in PostgreSQL la modifica dei parametri max_wal_senders e max_replication_slots richiede il riavvio del master, il che in alcuni casi pu\u00f2 causare interruzioni delle connessioni tra l'applicazione e il DBMS.<\/p>\n

Cerca e troverai!<\/h3>\n

\nPerch\u00e9 non abbiamo fatto \"come le persone normali\" e abbiamo scelto un approccio atipico? Dipende da cosa si considera normale. Molti realizzano cluster con Mongo e li distribuiscono su tre data center geo-distribuiti.<\/p>\n

All'epoca, avevamo gi\u00e0 due progetti su Redis. Il primo era una cache, mentre il secondo rappresentava uno storage persistente per dati non troppo critici. Con quest'ultimo ci sono stati molti problemi, in parte a causa nostra. A volte grandi volumi di dati erano memorizzati in una chiave e di tanto in tanto il sito ne risentiva. Questa sistema veniva utilizzato in modalit\u00e0 master-slave. Ci sono stati molti casi in cui qualcosa accadeva al master e la replicazione si interrompeva. <\/p>\n

Quindi Redis \u00e8 buono per compiti stateless, non per stateful. In linea di massima, consentiva di risolvere la maggior parte dei problemi, ma solo se si trattava di soluzioni key-value con un paio di indici. Tuttavia, la persistenza e la replicazione di Redis a quel tempo erano piuttosto deludenti. Inoltre, ci sono stati reclami riguardo le prestazioni.<\/p>\n

Abbiamo considerato MySQL e PostgreSQL. Ma il primo non ha trovato spazio da noi, mentre il secondo \u00e8 di per s\u00e9 un prodotto piuttosto complesso e costruire servizi semplici su di esso sarebbe stato poco pratico.
\nAbbiamo provato RIAK, Cassandra, persino un database grafico. Tutte queste sono soluzioni di nicchia che non si adattavano al ruolo di strumento universale per la creazione di servizi.<\/p>\n

Alla fine ci siamo fermati su Tarantool.<\/p>\n

Ci siamo rivolti a esso quando era alla versione 1.6. Siamo rimasti colpiti dalla sinergia tra key-value e funzionalit\u00e0 di un database relazionale. Ci sono indici secondari, transazioni e spazi, che sono come tabelle, ma non semplici, poich\u00e9 possono contenere un numero variabile di colonne. Ma la killer feature di Tarantool erano gli indici secondari combinati con key-value e transazionalit\u00e0.<\/p>\n

Allo stesso modo, ha giocato un ruolo importante la comunit\u00e0 di lingua russa, pronta ad aiutare in chat. Ne abbiamo approfittato attivamente e vivevamo praticamente in chat. Inoltre, \u00e8 fondamentale menzionare la buona persistenza senza evidenti problemi e bug. Se guardiamo alla nostra storia con Tarantool, ci sono stati molti dolori e fallimenti con la replicazione, ma non abbiamo mai perso dati a causa sua!<\/p>\n

L'implementazione \u00e8 iniziata in modo difficile.<\/h3>\n

\nA quel tempo, il nostro stack di sviluppo principale era .NET, per il quale non esisteva un connettore per Tarantool. Abbiamo subito iniziato a lavorare su Go. Anche con Lua andava piuttosto bene. Il problema principale era il debug: in .NET la situazione era ottimale, ma immergersi nel mondo di embedded Lua, con solo i log disponibili e senza alcun debug, era complicato. Inoltre, per qualche motivo la replicazione si rompeva periodicamente, e abbiamo dovuto approfondire il funzionamento del motore di Tarantool. In questo ci ha aiutato la chat, in misura minore la documentazione, a volte abbiamo guardato il codice. A quel tempo, la documentazione non era delle migliori.<\/p>\n

Cos\u00ec, nel corso di alcuni mesi, siamo riusciti a fare esperienza e ottenere risultati soddisfacenti nel lavoro con Tarantool. Abbiamo formalizzato in git le soluzioni standard che aiutavano nella creazione di nuovi microservizi. Ad esempio, quando sorgeva la necessit\u00e0 di realizzare un nuovo microservizio, lo sviluppatore guardava il codice sorgente della soluzione di riferimento nel repository, e la creazione di un nuovo microservizio richiedeva non pi\u00f9 di una settimana. <\/p>\n

Erano tempi particolari. All'epoca potevi avvicinarti all'amministratore al tavolo accanto e chiedere: \u00abDammi una virtual machine\u00bb. Dopo circa trenta minuti, la macchina era gi\u00e0 a tua disposizione. Ti connettevi da solo, installavi tutto, e veniva instradato il traffico verso di essa.<\/p>\n

Oggi non funziona pi\u00f9 cos\u00ec: bisogna attivare il monitoraggio del servizio, registrare le attivit\u00e0, coprire la funzionalit\u00e0 con test, ordinare una virtual machine o installarla in Kubernetes, ecc. In generale, sar\u00e0 meglio, anche se pi\u00f9 lungo e complicato.<\/p>\n

Dividi e conquista. Com'\u00e8 la situazione con Lua?<\/h3>\n

\nC'era un serio dilemma: alcune squadre non riuscivano a gestire l'implementazione di modifiche nei servizi con una grande quantit\u00e0 di logica in Lua. Spesso questo comportava l'inefficienza del servizio. <\/p>\n

In altre parole, gli sviluppatori preparano una modifica. Tarantool inizia a eseguire la migrazione, mentre la replica \u00e8 ancora con il vecchio codice; viene ricevuto tramite replica qualche DDL o altro, e il codice si rompe semplicemente, perch\u00e9 non \u00e8 stato previsto. Di conseguenza, la procedura di aggiornamento per gli amministratori era scritta su un foglio A4: fermare la replica, aggiornare questo, riattivare la replica, disattivare qui, aggiornare l\u00ec. Un vero incubo! <\/p>\n

Di conseguenza, ora cerchiamo di non utilizzare Lua. Semplicemente tramite iproto (protocollo binario per l'interazione con il server), e basta. Forse \u00e8 una mancanza di conoscenze da parte degli sviluppatori, ma da questa prospettiva il sistema \u00e8 complesso.<\/p>\n

Non seguiamo sempre ciecamente questo scenario. Oggi per noi non esiste pi\u00f9 un bianco o nero: o tutto in Lua, o tutto in Go. Comprendiamo gi\u00e0 come combinare le due cose per evitare problemi di migrazione in futuro.<\/p>\n

Dove \u00e8 attualmente presente Tarantool?
\nTarantool \u00e8 utilizzato nel servizio di calcolo del prezzo finale dei prodotti tenendo conto dei coupon sconto, noto come \u00abPromotizer\u00bb. Come detto in precedenza, adesso sta uscendo di scena: sar\u00e0 sostituito da un nuovo servizio di catalogo con prezzi pre-calcolati, ma fino a sei mesi fa, tutti i calcoli venivano effettuati in \u00abPromotizer\u00bb. Prima, met\u00e0 della sua logica era scritta in Lua. Due anni fa, il servizio \u00e8 stato trasformato in un repository, e la logica \u00e8 stata riscritta in Go, poich\u00e9 la meccanica degli sconti \u00e8 cambiata e il servizio necessitava di maggiore prestazioni. <\/p>\n

Uno dei servizi pi\u00f9 critici \u00e8 il profilo utente. Cio\u00e8, tutti gli utenti di Wildberries vengono memorizzati in Tarantool, circa 50 milioni. Un sistema shardizzato per ID utente, distribuito su diversi data center con l'ausilio di servizi Go.
\nIn passato, il leader per RPS era \u00abPromotizer\u00bb, raggiungeva fino a 6.000 richieste. A un certo punto avevamo 50-60 istanze. Ora, per\u00f2, il leader per RPS \u00e8 il profilo utente, che raggiunge circa 12.000. In questo servizio viene applicato uno sharding personalizzato suddiviso per range di ID utente. Il servizio gestisce pi\u00f9 di 20 macchine, ma sono troppe; prevediamo di ridurre le risorse dedicate, poich\u00e9 bastano le capacit\u00e0 di 4-5 macchine.<\/p>\n

Il servizio delle sessioni \u00e8 il nostro primo servizio su vshard e Cartridge. L'impostazione di vshard e l'aggiornamento di Cartridge hanno richiesto un certo impegno, ma alla fine tutto ha funzionato.<\/p>\n

Il servizio per visualizzare diversi banner sul sito e nell'app mobile \u00e8 stato uno dei primi a essere rilasciato direttamente su Tarantool. Questo servizio \u00e8 notevole perch\u00e9 ha circa 6-7 anni, \u00e8 ancora operativo e non \u00e8 mai stato riavviato. Sono stati utilizzati la replica master-master. Non \u00e8 mai successo nulla di rotto.<\/p>\n

C'\u00e8 un esempio di utilizzo di Tarantool per funzionalit\u00e0 di prontuari rapidi in un sistema di magazzino, per verificare rapidamente informazioni in alcuni casi. Abbiamo provato a usare Redis per questo, ma i dati in memoria occupavano pi\u00f9 spazio rispetto a Tarantool.<\/p>\n

I servizi della lista d'attesa, delle iscrizioni ai clienti, delle attuali storie di moda e dei prodotti in sospeso funzionano anche con Tarantool. L'ultimo servizio occupa in memoria circa 120 GB. \u00c8 il servizio con il maggior volume tra quelli elencati. <\/p>\n

Conclusione<\/h3>\n

\nGrazie agli indici secondari combinati con key-value e transazionalit\u00e0, Tarantool \u00e8 ottimo per architetture basate su microservizi. Tuttavia, abbiamo incontrato difficolt\u00e0 quando implementavamo modifiche nei servizi con una grande quantit\u00e0 di logica in Lua: i servizi smettevano spesso di funzionare. Non siamo riusciti a superare questo problema, e col tempo siamo arrivati a varie combinazioni di Lua e Go: sappiamo dove utilizzare un linguaggio e dove l'altro.<\/p>\n

Ulteriori letture sull'argomento<\/b><\/p>\n