In qualche modo, storicamente, il settore IT è diviso in due campi condizionali per qualsiasi motivo: quelli che sono “a favore” e quelli che sono “contro”. Inoltre, l'oggetto delle controversie può essere del tutto arbitrario. Quale sistema operativo è migliore: Win o Linux? Su uno smartphone Android o iOS? Dovresti conservare tutto tra le nuvole o metterlo in un archivio RAID freddo e mettere le viti in una cassaforte? Le persone PHP hanno il diritto di essere chiamate programmatori? Tali controversie hanno, a volte, carattere esclusivamente esistenziale e non hanno altro fondamento se non l'interesse sportivo.
È successo così che con l'avvento dei container e tutta questa amata cucina con docker e k8 condizionali, sono iniziati i dibattiti "a favore" e "contro" l'uso di nuove funzionalità in varie aree del backend. (Riserviamo in anticipo che, sebbene Kubernetes verrà spesso indicato come orchestratore in questa discussione, la scelta di questo particolare strumento non è di fondamentale importanza. Puoi invece sostituirlo con qualsiasi altro che ti sembra più conveniente e familiare .)
E, a quanto pare, si tratterebbe di una semplice disputa tra due facce della stessa medaglia. Insensato e spietato come l'eterno confronto tra Win vs Linux, in cui nel mezzo esistono le persone adeguate. Ma nel caso della containerizzazione, non tutto è così semplice. Di solito in tali controversie non c'è una parte giusta, ma nel caso di contenitori "usati" o "non usati" per l'archiviazione di database, tutto si capovolge. Perché in un certo senso hanno ragione sia i sostenitori che gli oppositori di questo approccio.
Il lato positivo
L’argomentazione di The Light Side può essere brevemente descritta in una frase: “Ciao, 2k19 è fuori dalla finestra!” Sembra populismo, certo, ma se si analizza la situazione nel dettaglio, ha i suoi vantaggi. Risolviamoli adesso.
Diciamo che hai un grande progetto web. Potrebbe essere stato inizialmente costruito sulla base di un approccio a microservizi, oppure ad un certo punto vi si è arrivati attraverso un percorso evolutivo: questo non è molto importante, in effetti. Hai suddiviso il nostro progetto in microservizi separati, hai configurato l'orchestrazione, il bilanciamento del carico e il ridimensionamento. E ora, con la coscienza pulita, sorseggi un mojito su un'amaca durante gli effetti habra invece di rialzare i server caduti. Ma in tutte le azioni devi essere coerente. Molto spesso, solo l'applicazione stessa, ovvero il codice, è containerizzata. Cos'altro abbiamo oltre al codice?
Esatto, dati. Il cuore di ogni progetto sono i suoi dati: possono essere un tipico DBMS - MySQL, Postgre, MongoDB, o l'archiviazione utilizzata per la ricerca (ElasticSearch), l'archiviazione di valori-chiave per la memorizzazione nella cache - ad esempio, redis, ecc. Attualmente non lo siamo parleremo di opzioni di implementazione del backend storte quando il database si blocca a causa di query scritte male, e parleremo invece di garantire la tolleranza agli errori di questo stesso database sotto carico del client. Dopotutto, quando containerizziamo la nostra applicazione e le permettiamo di scalare liberamente per elaborare un numero qualsiasi di richieste in entrata, ciò aumenta naturalmente il carico sul database.
Infatti, il canale di accesso al database e il server su cui gira diventano la cruna dell'ago nel nostro bellissimo backend containerizzato. Allo stesso tempo, il motivo principale della virtualizzazione dei container è la mobilità e la flessibilità della struttura, che ci consente di organizzare la distribuzione dei carichi di punta sull'intera infrastruttura a nostra disposizione nel modo più efficiente possibile. Cioè, se non containerizziamo e non implementiamo tutti gli elementi esistenti del sistema nel cluster, stiamo commettendo un errore molto grave.
È molto più logico raggruppare non solo l'applicazione stessa, ma anche i servizi responsabili dell'archiviazione dei dati. Raggruppando e distribuendo server Web che funzionano in modo indipendente e distribuiscono il carico tra loro in k8, stiamo già risolvendo il problema della sincronizzazione dei dati: gli stessi commenti sui post, se prendiamo come esempio una piattaforma multimediale o di blog. In ogni caso abbiamo una rappresentazione intra-cluster, anche virtuale, del database come un ExternalService. La domanda è che il database stesso non è ancora in cluster: i server Web distribuiti nel cubo raccolgono informazioni sui cambiamenti dal nostro database di combattimento statico, che ruota separatamente.
Percepisci un problema? Usiamo k8s o Swarm per distribuire il carico ed evitare il crash del server web principale, ma non lo facciamo per il database. Ma se il database si blocca, la nostra intera infrastruttura in cluster non ha senso: a cosa servono le pagine Web vuote che restituiscono un errore di accesso al database?
Ecco perché è necessario raggruppare non solo i server web, come si fa di solito, ma anche l'infrastruttura del database. Solo in questo modo possiamo garantire una struttura che funzioni pienamente in un unico team, ma allo stesso tempo indipendente gli uni dagli altri. Inoltre, anche se metà del nostro backend "crolla" sotto carico, il resto sopravviverà e il sistema di sincronizzazione dei database tra loro all'interno del cluster e la capacità di scalare e implementare all'infinito nuovi cluster aiuteranno a raggiungere rapidamente la capacità richiesta - se solo ci fossero i rack nel data center.
Inoltre, il modello di database distribuito in cluster consente di portare proprio questo database dove serve; Se parliamo di un servizio globale, è del tutto illogico creare un cluster web da qualche parte nell'area di San Francisco e allo stesso tempo inviare pacchetti quando si accede a un database nella regione di Mosca e ritorno.
Inoltre, la containerizzazione del database consente di costruire tutti gli elementi del sistema allo stesso livello di astrazione. Il che, a sua volta, consente di gestire proprio questo sistema direttamente dal codice, da parte degli sviluppatori, senza il coinvolgimento attivo degli amministratori. Gli sviluppatori hanno pensato che per il nuovo sottoprogetto fosse necessario un DBMS separato: facile! ha scritto un file yaml, lo ha caricato nel cluster e il gioco è fatto.
E, naturalmente, il funzionamento interno è notevolmente semplificato. Dimmi, quante volte hai chiuso gli occhi quando un nuovo membro del team ha messo le mani nel database di combattimento per lavoro? Quale, in effetti, è l'unico che hai e che sta girando in questo momento? Certo, qui siamo tutti adulti, e da qualche parte abbiamo un nuovo backup, e anche più lontano - dietro lo scaffale con i cetrioli della nonna e i vecchi sci - un altro backup, forse anche in una cella frigorifera, perché il tuo ufficio era già in fiamme una volta. Tuttavia, ogni introduzione di un nuovo membro del team con accesso all'infrastruttura di combattimento e, ovviamente, al database di combattimento è un secchio di validol per tutti intorno. Beh, chi lo conosce, un novellino, magari è un trasgressore? È spaventoso, sarai d'accordo.
La containerizzazione e, di fatto, la topologia fisica distribuita del database del progetto aiuta a evitare tali momenti di convalida. Non ti fidi di un principiante? OK! Diamogli il proprio cluster con cui lavorare e disconnettiamo il database dagli altri cluster: sincronizzazione solo tramite push manuale e rotazione sincrona di due chiavi (una per il team leader, l'altra per l'amministratore). E tutti sono felici.
E ora è il momento di trasformarsi in oppositori del clustering di database.
Lato oscuro
Discutendo sul perché non valga la pena containerizzare il database e continuare a eseguirlo su un server centrale, non ci piegheremo alla retorica delle ortodossie e ad affermazioni come "i nonni gestivano i database sull'hardware, e lo faremo anche noi!" Proviamo invece a creare una situazione in cui la containerizzazione possa effettivamente dare dividendi tangibili.
D'accordo, i progetti che necessitano davvero di una base in un contenitore possono essere contati sulle dita di una mano anche dal miglior operatore di fresatrice. Nella maggior parte dei casi, anche l'uso di k8 o dello stesso Docker Swarm è ridondante: molto spesso si ricorre a questi strumenti a causa del clamore generale delle tecnologie e dell'atteggiamento dell'"onnipotente" nella persona dei sessi di spingere tutto nel dimenticatoio. nuvole e contenitori. Beh, perché adesso va di moda e lo fanno tutti.
In almeno la metà dei casi, l’utilizzo di Kubernetis o semplicemente di Docker in un progetto è ridondante. Il problema è che non tutti i team o le società di outsourcing assunte per mantenere l’infrastruttura del cliente ne sono consapevoli. È peggio quando vengono imposti i container, perché costa una certa quantità di monete al cliente.
In generale, si ritiene che la mafia docker/cubo stia stupidamente schiacciando i clienti che esternalizzano questi problemi infrastrutturali. Dopotutto, per lavorare con i cluster, abbiamo bisogno di ingegneri che siano in grado di farlo e generalmente comprendano l'architettura della soluzione implementata. Una volta abbiamo già descritto il nostro caso con la pubblicazione Republic: lì abbiamo formato il team del cliente a lavorare nelle realtà di Kubernetis e tutti erano soddisfatti. Ed è stato decente. Spesso gli "implementatori" di K8 prendono in ostaggio l'infrastruttura del cliente, perché ora solo loro capiscono come funziona tutto lì, non ci sono specialisti dalla parte del cliente.
Immaginiamo ora che in questo modo esternalizziamo non solo la parte web server, ma anche la manutenzione del database. Abbiamo detto che BD è il cuore e che la perdita del cuore è fatale per qualsiasi organismo vivente. Insomma, le prospettive non sono delle migliori. Quindi, invece di pubblicizzare Kubernetis, molti progetti semplicemente non dovrebbero preoccuparsi della tariffa normale per AWS, che risolverà tutti i problemi con il carico sul loro sito/progetto. Ma AWS non è più di moda e le esibizioni valgono più dei soldi, purtroppo anche nell'ambiente IT.
OK. Forse il progetto ha davvero bisogno del clustering, ma se tutto è chiaro con le applicazioni stateless, come possiamo organizzare una connettività di rete decente per un database in cluster?
Se parliamo di una soluzione ingegneristica senza soluzione di continuità, che è ciò che rappresenta la transizione a K8, il nostro principale grattacapo è la replica dei dati in un database in cluster. Alcuni DBMS inizialmente sono piuttosto fedeli alla distribuzione dei dati tra le loro singole istanze. Molti altri non sono così accoglienti. E molto spesso l'argomento principale nella scelta di un DBMS per il nostro progetto non è la capacità di replicarlo con costi minimi di risorse e ingegneria. Soprattutto se inizialmente il progetto non era stato concepito come un microservizio, ma si è semplicemente evoluto in questa direzione.
Pensiamo che non sia necessario parlare della velocità delle unità di rete: sono lente. Quelli. Non abbiamo ancora una reale opportunità, se succede qualcosa, di riavviare un'istanza DBMS da qualche parte dove c'è più potenza, ad esempio, potenza del processore o RAM libera. Ci imbatteremo molto rapidamente nelle prestazioni del sottosistema del disco virtualizzato. Di conseguenza, il DBMS deve essere inchiodato al proprio insieme personale di macchine situate nelle immediate vicinanze. Oppure è necessario in qualche modo raffreddare separatamente una sincronizzazione dei dati sufficientemente veloce per le presunte riserve.
Continuando l'argomento dei file system virtuali: i volumi Docker, sfortunatamente, non sono esenti da problemi. In generale, in materia di archiviazione affidabile dei dati a lungo termine, vorrei accontentarmi degli schemi tecnicamente più semplici. E aggiungere un nuovo livello di astrazione dal FS del contenitore al FS dell’host principale è di per sé un rischio. Ma quando anche il funzionamento del sistema di supporto alla containerizzazione incontra difficoltà nella trasmissione dei dati tra questi livelli, allora è davvero un disastro. Al momento, la maggior parte dei problemi noti all’umanità progressista sembrano essere stati sradicati. Ma capisci, più il meccanismo è complesso, più è facile che si rompa.
Alla luce di tutte queste “avventure”, è molto più redditizio e più semplice mantenere il database in un unico posto e, anche se è necessario containerizzare l’applicazione, lasciarla funzionare da sola e attraverso il gateway di distribuzione ricevere la comunicazione simultanea con il database, che verrà letto e scritto una sola volta e in un unico posto. Questo approccio riduce al minimo la probabilità di errori e desincronizzazione.
A cosa stiamo portando? Inoltre, la containerizzazione del database è appropriata laddove ce n’è una reale necessità. Non puoi riempire un database di app completo e farlo girare come se avessi due dozzine di microservizi: non funziona in questo modo. E questo deve essere ben compreso.
Invece di output
Se stai aspettando una conclusione chiara "virtualizzare o meno il database", allora ti deluderemo: non sarà qui. Perché quando si crea una soluzione infrastrutturale bisogna lasciarsi guidare non dalla moda e dal progresso, ma, prima di tutto, dal buon senso.
Ci sono progetti per i quali i principi e gli strumenti forniti con Kubernetis si adattano perfettamente, e in tali progetti c'è pace almeno nell'area backend. E ci sono progetti che non necessitano di containerizzazione, ma di una normale infrastruttura server, perché fondamentalmente non possono scalare al modello di cluster di microservizi, perché cadranno.
Fonte: habr.com