{"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 il monolito","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

\"Come
\n
\nTutti noi amiamo le storie. Ci piace raccontare le nostre vittorie passate, le battaglie o semplicemente le nostre esperienze sul lavoro mentre siamo seduti attorno a un fuoco.<\/p>\n

Oggi \u00e8 proprio un giorno cos\u00ec. E anche se ora non sei attorno a un fuoco, abbiamo comunque una storia per te. La storia di come abbiamo iniziato a lavorare con il database Tarantool.<\/p>\n

Una volta, molto tempo fa, nella nostra azienda c'erano un paio di \"monoliti\" e un unico \"soffitto\" per tutti, a cui questi monoliti si avvicinavano lentamente ma inesorabilmente, limitando il volo della nostra azienda, la nostra crescita. E c'era una comprensione chiara: un giorno ci saremmo scontrati contro questo soffitto.
\n<\/a><\/noindex>
\nOra ci governa l'ideologia della separazione di tutto, dall'hardware alla logica aziendale. Di conseguenza, abbiamo, ad esempio, due data center praticamente indipendenti a livello di rete. Ma allora tutto era molto diverso.<\/p>\n

Oggi ci sono molti strumenti e mezzi per apportare modifiche, come CI\/CD, K8S, ecc. All'epoca dei \"monoliti\" non avevamo bisogno di cos\u00ec tanti termini stranieri. Era sufficiente semplicemente modificare il \"database di archivio\".<\/p>\n

Ma il tempo \u00e8 andato avanti, e il numero di richieste \u00e8 aumentato insieme ad esso, facendo schizzare le RPS a volte oltre le nostre capacit\u00e0. Con l'ingresso nel mercato degli stati post-sovietici, il carico sul processore del database del primo monolito non scendeva sotto il 90%, mentre le RPS si mantenevano attorno a 2400. E non erano semplici piccole selezioni, ma richieste massive con un sacco di controlli e JOIN, che potevano attraversare quasi met\u00e0 dei dati a causa di un alto IO.<\/p>\n

Quando sono iniziate ad apparire le vere vendite per il \"Black Friday\" - e Wildberries \u00e8 stata una delle prime in Russia a promuoverle - la situazione \u00e8 diventata decisamente preoccupante. Infatti, il carico in questi giorni aumentava di tre volte.
\nOh, quei \"tempi monolitici\"! Sono certo che anche tu hai vissuto esperienze simili e ancora non riesci a capire come possa essere successo.<\/p>\n

Cosa puoi fare? La moda \u00e8 propria anche delle tecnologie. Circa 5 anni fa, abbiamo dovuto ripensare una di queste mode in forma di un sito esistente su .NET e MS SQL Server, che custodiva gelosamente tutta la logica del sito stesso. La custodiva cos\u00ec bene che scindere un tale monolito \u00e8 risultata un'attivit\u00e0 lunga e per niente semplice.
\nUna piccola digressione. <\/p>\n

A eventi di vario genere, dico: \u00abse non hai tagliato il monolite, non sei cresciuto!\u00bb Mi interessa la tua opinione al riguardo, per favore scrivila nei commenti.<\/p>\n

E scoppi\u00f2 il tuono<\/h3>\n

\nTorniamo al nostro \u00abfocolare\u00bb. Per distribuire il carico della funzionalit\u00e0 \u00abmonolitica\u00bb, abbiamo deciso di suddividere il sistema in microservizi basati su tecnologie open source. Perch\u00e9, perlomeno, la loro scalabilit\u00e0 \u00e8 pi\u00f9 economica. E avevamo il 100% di certezza che avrebbe funzionato, visto che nel frattempo eravamo riusciti ad entrare nei mercati dei paesi vicini e il numero di registrazioni, cos\u00ec come il numero degli ordini, iniziava a crescere ancora di pi\u00f9.<\/p>\n

Analizzando i primi candidati per la migrazione dal monolito ai microservizi, abbiamo capito che nell'80% dei casi il salvataggio avviene per il 99% dalle sistemi back office, mentre la lettura proviene dal front-end. Questo riguardava soprattutto un paio di sottosistemi importanti per noi: i dati degli utenti e il sistema di calcolo del prezzo finale dei prodotti sulla base delle informazioni relative agli sconti e ai coupon dei clienti.<\/p>\n

Come parentesi, fa strano pensare che, oltre ai sottosistemi sopra menzionati, dal nostro monolito sono stati estratti anche i cataloghi dei prodotti, il carrello degli utenti, il sistema di ricerca dei prodotti, il sistema di filtraggio dei cataloghi e vari sistemi di raccomandazione. Per ciascuno di essi esistono classi separate di sistemi specializzati, ma un tempo vivevano tutti insieme in un \u201cpiccolo rifugio\u201d. <\/p>\n

Abbiamo pianificato di estrarre i dati sui nostri clienti in un sistema shardato. Tuttavia, l'estrazione della funzionalit\u00e0 per il calcolo del prezzo finale dei prodotti richiedeva una buona scalabilit\u00e0 in lettura, poich\u00e9 questa creava il maggiore carico in termini di RPS ed era la pi\u00f9 complessa da eseguire per il database (molti dati sono coinvolti nel processo di calcolo). <\/p>\n

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

In quel periodo, per il funzionamento dei microservizi, sono stati scelti schemi di lavoro con pi\u00f9 data center su macchine virtuali e fisiche. Come mostrato nelle immagini, sono state utilizzate opzioni di replicazione di Tarantool sia in modalit\u00e0 master-master che master-slave. <\/p>\n

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

Attualmente, si tratta di 24 shard, ognuno con 2 istanze (una per ogni data center), tutte in modalit\u00e0 master-master.<\/p>\n

Sopra il database si trovano applicazioni che accedono alle repliche del database. Le applicazioni lavorano con Tarantool attraverso 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 per lettura e scrittura. In sostanza, implementa un modello di replica set, a cui \u00e8 stata aggiunta la logica di selezione delle repliche, esecuzione di retry, circuit breaker e limitazione della velocit\u00e0.<\/p>\n

Inoltre, \u00e8 possibile configurare la politica di selezione delle repliche in riferimento agli shard. Ad esempio, utilizzando il round-robin.<\/p>\n

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

Qualche mese fa, la maggior parte delle richieste per il calcolo del costo finale dei prodotti \u00e8 stata trasferita a un nuovo servizio, che fondamentalmente funziona senza database, ma fino a un certo punto, il 100% era gestito dal servizio con Tarantool sotto il cofano.<\/p>\n

Il database del servizio \u00e8 composto da 4 master, nei quali il sincronizzatore raccoglie i dati, e ciascuno di questi master distribuisce i dati alle repliche in sola lettura tramite replica. Ogni master ha circa 15 di queste repliche.<\/p>\n

In entrambe le architetture, in caso di indisponibilit\u00e0 di un datacenter, l'applicazione pu\u00f2 ricevere dati dal secondo.<\/p>\n

Vale la pena notare che in Tarantool la replica \u00e8 piuttosto flessibile e pu\u00f2 essere configurata a runtime. In altri sistemi ci sono stati problemi, ad esempio per modificare i parametri max_wal_senders e max_replication_slots in PostgreSQL \u00e8 necessario riavviare il master, il che in alcuni casi pu\u00f2 portare a disconnessioni 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 modo atipico? Dipende da cosa consideriamo normale. Molti creano un cluster con Mongo e lo distribuiscono su tre datacenter geo-distribuiti.<\/p>\n

All'epoca avevamo gi\u00e0 due progetti su Redis. Il primo era una cache, e il secondo costituiva uno storage persistente per dati non troppo critici. Con quest'ultimo ci sono stati parecchi problemi, in parte per nostra responsabilit\u00e0. A volte grossi volumi di dati si accumulavano nella chiave, e di tanto in tanto il sito diventava lento. Questo sistema \u00e8 stato utilizzato in modalit\u00e0 master-slave. Ci sono stati molti casi in cui qualcosa \u00e8 accaduto con il master e la replica si \u00e8 interrotta. <\/p>\n

Cio\u00e8, Redis \u00e8 ottimo per compiti stateless, ma non per quelli stateful. Fondamentalmente, ha permesso di risolvere la maggior parte dei problemi, ma solo se si trattava di soluzioni key-value con un paio di indici. Tuttavia, all'epoca, la persistenza e la replica in Redis erano piuttosto deludenti. Inoltre, ci furono lamentele sulle prestazioni.<\/p>\n

Abbiamo considerato MySQL e PostgreSQL. Ma il primo in qualche modo non ha trovato spazio da noi, mentre il secondo \u00e8 un prodotto piuttosto complesso in s\u00e9, e costruire su di esso semplici servizi sarebbe stato poco pratico.
\nAbbiamo provato RIAK, Cassandra, persino database grafici. Tutte queste sono soluzioni piuttosto di nicchia, che non si prestavano a essere strumenti universali per la creazione di servizi.<\/p>\n

Alla fine abbiamo optato per Tarantool.<\/p>\n

Ci siamo rivolti a lui quando era in versione 1.6. Ci ha colpito la sinergia tra key-value e le funzionalit\u00e0 di un database relazionale. Ci sono indici secondari, transazioni e spazi, che sono come tabelle, ma non semplici, permettendo di memorizzare un numero variabile di colonne. Tuttavia, la killer feature di Tarantool \u00e8 stata la combinazione di indici secondari con key-value e transazionalit\u00e0.<\/p>\n

Ha anche giocato un ruolo importante la reattivit\u00e0 della comunit\u00e0 di lingua russa, pronta ad aiutare in chat. Abbiamo sfruttato attivamente questa opportunit\u00e0 e vivevamo in chat. E non va dimenticato il ragionevole livello di persistenza senza evidenti imperfezioni e difetti. Guardando la nostra storia con Tarantool, abbiamo avuto molti problemi e fallimenti con la replica, ma non abbiamo mai perso dati per colpa 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 c'era un connettore per Tarantool. Abbiamo subito iniziato a fare qualcosa in Go. Anche con Lua le cose andavano piuttosto bene. Il principale problema a quel punto era il debug: in .NET era tutto magnifico, ma immersione nel mondo di Lua embedded, quando non avevi altra opzione se non i log, era piuttosto arduo. Inoltre, per qualche motivo, la replica si interrompeva periodicamente, e abbiamo dovuto approfondire il funzionamento del motore Tarantool. In questo ci ha aiutati la chat, meno la documentazione, a volte guardavamo anche il codice. A quel tempo la documentazione era piuttosto scarsa.<\/p>\n

Cos\u00ec, nell'arco di alcuni mesi, siamo riusciti a fare esperienza e ottenere risultati soddisfacenti nel lavoro con Tarantool. Abbiamo formalizzato in git dei modelli di sviluppo, che hanno aiutato nella creazione di nuovi microservizi. Ad esempio, quando si presentava l'esigenza di realizzare un nuovo microservizio, il developer consultava il codice sorgente della soluzione di riferimento nel repository, e la creazione del nuovo richiedeva non pi\u00f9 di una settimana. <\/p>\n

Allora erano tempi speciali. In un certo senso, potevi avvicinarti all'amministratore al tavolo vicino e chiedere: \"Dammela virtual machine\". Dopo circa trenta minuti, la macchina era gi\u00e0 a tua disposizione. Ti connettevi da solo, installavi tutto e ti attivavano il traffico su di essa.<\/p>\n

Oggi non funziona pi\u00f9 cos\u00ec: \u00e8 necessario implementare il monitoraggio del servizio, la registrazione, coprire la funzionalit\u00e0 con test, ordinare una virtual machine o la fornitura in Kubernetes, e cos\u00ec via. In generale, sar\u00e0 meglio cos\u00ec, anche se pi\u00f9 lungo e complicato.<\/p>\n

Dividi e conquista. Come stanno le cose con Lua?<\/h3>\n

\nC'era un serio dilemma: alcune squadre faticavano a implementare modifiche nel servizio con molta logica su Lua. Spesso questo si accompagnava a malfunzionamenti del servizio. <\/p>\n

Cio\u00e8, gli sviluppatori preparano una certa modifica. Tarantool inizia a eseguire la migrazione, mentre la replica opera ancora con il codice vecchio; arriva per replicazione qualche DDL, qualcos'altro, e il codice semplicemente si rompe, perch\u00e9 ci\u00f2 non \u00e8 stato tenuto in considerazione. Di conseguenza, la procedura di aggiornamento per gli amministratori era scritta su un foglio A4: fermare la replicazione, aggiornare questo, riavviare la replicazione, spegnere qui, aggiornare l\u00e0. Un incubo! <\/p>\n

Alla fine, ora cerchiamo di non fare nulla su 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 questo punto di vista il sistema \u00e8 complicato.<\/p>\n

Non seguiamo sempre ciecamente questo schema. Oggi non abbiamo nero e bianco: tutto su Lua, oppure tutto su Go. Stiamo gi\u00e0 comprendendo come combinare le cose, per evitare problemi con la migrazione.<\/p>\n

Dove si trova adesso Tarantool?
\nTarantool viene utilizzato nel servizio di calcolo del costo finale dei prodotti tenendo conto dei coupon sconto, noto anche come \u00abPromotaizer\u00bb. Come gi\u00e0 detto in precedenza, attualmente sta venendo messo da parte: un nuovo servizio di catalogo con prezzi pre-calcolati lo sta sostituendo, ma sei mesi fa tutti i calcoli venivano effettuati tramite il \u00abPromotaizer\u00bb. In passato met\u00e0 della logica era scritta in Lua. Due anni fa il servizio \u00e8 stato trasformato in un magazzino, e la logica \u00e8 stata riscritta in Go, perch\u00e9 la meccanica degli sconti \u00e8 cambiata un po' e il servizio aveva bisogno di una maggiore potenza. <\/p>\n

Uno dei servizi pi\u00f9 critici \u00e8 il profilo utente. Quindi, tutti gli utenti di Wildberries sono conservati in Tarantool, e sono circa 50 milioni. Un sistema shardizzato per ID utente, distribuito su diversi centri di distribuzione con integrazioni su servizi Go.
\nNel RPS, in passato, il leader era il \u00abPromotaizer\u00bb, che raggiungeva fino a 6.000 richieste. A un certo punto avevamo 50-60 istanze. Ora, il leader nel RPS sono i profili utenti, con circa 12.000 richieste. In questo servizio viene applicato uno sharding personalizzato suddiviso per intervalli di ID utente. Servizio gestisce pi\u00f9 di 20 macchine, ma sono troppe; prevediamo di ridurre le risorse allocate, poich\u00e9 sarebbe sufficiente la potenza di 4-5 macchine.<\/p>\n

Il servizio di sessione \u00e8 il nostro primo servizio su vshard e Cartridge. La configurazione di vshard e l'aggiornamento di Cartridge hanno richiesto un certo impegno da parte nostra, ma alla fine tutto ha funzionato.<\/p>\n

Il servizio per la visualizzazione di diversi banner sul sito e nell'app mobile \u00e8 stato uno dei primi ad essere lanciato direttamente su Tarantool. Questo servizio \u00e8 notevole perch\u00e9 ha circa 6-7 anni, \u00e8 ancora in funzione e non \u00e8 mai stato riavviato. \u00c8 stata utilizzata la replicazione master-master. Non si \u00e8 mai rotto nulla.<\/p>\n

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

I servizi di lista di attesa, abbonamenti clienti, storie trendy e prodotti salvati funzionano anch'essi con Tarantool. L'ultimo servizio occupa in memoria circa 120 GB. \u00c8 il servizio pi\u00f9 voluminoso tra quelli menzionati. <\/p>\n

Conclusione<\/h3>\n

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

Cosa leggere ancora sull'argomento<\/b><\/p>\n