Ciao, habrovichiani. Oggi iniziano le lezioni nel primo gruppo del corso . A questo proposito, vogliamo raccontarvi com'è andato il webinar aperto su questo corso.
In abbiamo parlato delle sfide che le basi di dati SQL stanno affrontando nell'era del cloud e di Kubernetes. Inoltre, abbiamo visto come i database SQL si adattino e si trasformino a seguito di queste sfide.
Il webinar è stato condotto da , Google Cloud Practice Delivery Manager in EPAM Systems.
Quando gli alberi erano piccoli…
Per cominciare, ricordiamo come iniziava la scelta del DBMS alla fine del secolo scorso. D'altra parte, non è difficile, poiché la scelta del DBMS in quei tempi iniziava e finiva Oracle.
Alla fine degli anni '90 e all'inizio degli anni 2000, in realtà non c'era molta scelta, per quanto riguarda i database scalabili industriali. Sì, esistevano IBM DB2, Sybase e altri database che apparivano e sparivano, ma nel complesso non erano così evidenti rispetto a Oracle. Di conseguenza, le competenze degli ingegneri di quel periodo erano in un certo senso legate a quella unica scelta che esisteva.
Un Oracle DBA doveva saper fare:
- installare Oracle Server da un pacchetto;
- configurare Oracle Server:
- init.ora;
- listener.ora;
— creare:
- spazi di tabella;
- schemi;
- utenti;
— eseguire backup e ripristino;
— monitorare;
— affrontare le query non ottimali.
Tuttavia, da un Oracle DBA non era richiesto molto:
- saper scegliere il DBMS ottimale o un'altra tecnologia di archiviazione e elaborazione dei dati;
- assicurare alta disponibilità e scalabilità orizzontale (questo non era sempre un problema del DBA);
- conoscere bene il dominio, l'infrastruttura, l'architettura applicativa, il sistema operativo;
- effettuare il caricamento e lo scaricamento dei dati, la migrazione dei dati tra diversi DBMS.
In generale, se parliamo della scelta in quel periodo, ricorda la scelta in un negozio sovietico alla fine degli anni '80:
I nostri tempi
Da allora, ovviamente, gli alberi sono cresciuti, il mondo è cambiato e le cose sono andate così:
È cambiato anche il mercato dei DBMS, come è evidente dal recente rapporto di Gartner:
E non possiamo non notare che il cloud ha trovato una sua nicchia, la cui popolarità è in crescita. Se leggiamo lo stesso rapporto di Gartner, vedremo le seguenti conclusioni:
- Molti clienti sono sulla strada per trasferire le applicazioni nel cloud.
- Le nuove tecnologie appaiono prima nel cloud e non è detto che prima o poi migrino a un'infrastruttura on-premises.
- La modalità di pricing pay-as-you-go è diventata abituale. Tutti vogliono pagare solo per ciò che utilizzano, e questo non è più nemmeno un trend, ma una semplice constatazione dei fatti.
Cosa succede ora?
Oggi siamo tutti nel cloud. Le domande che ci poniamo riguardano la scelta. E questa è enorme, anche se parliamo solo della scelta delle tecnologie di database in formato On-premises. Inoltre, abbiamo servizi gestiti e SaaS. Pertanto, la scelta diventa ogni anno più complessa.
Insieme alle interrogazioni sulle scelte, ci sono anche fattori limitanti:
- il prezzo. Molte tecnologie richiedono ancora un investimento economico;
- abilità. Se parliamo di software libero, sorge il problema delle competenze, poiché il software gratuito richiede dagli utenti che lo implementano e lo gestiscono un'adeguata competenza;
- funzionalità. Non tutti i servizi disponibili nel cloud e costruiti, ad esempio, sulla base di PostgreSQL hanno le stesse caratteristiche di PostgreSQL On-premises. Questo è un fattore significativo che è importante conoscere e capire. Inoltre, questo fattore acquisisce una rilevanza maggiore rispetto alla semplice conoscenza di funzionalità nascoste di un singolo sistema di gestione di database.
Cosa si aspetta attualmente da DA/DE:
- una buona comprensione dell'area tematica e dell'architettura applicativa;
- la capacità di scegliere la tecnologia di database più adatta tenendo conto del compito assegnato;
- la capacità di selezionare il metodo ottimale per implementare la tecnologia scelta in relazione ai vincoli esistenti;
- la capacità di eseguire il trasferimento e la migrazione dei dati;
- la capacità di implementare e gestire le soluzioni scelte.
Il seguente esempio basato su GCP dimostra come viene effettuata la scelta della tecnologia da utilizzare in base alla loro struttura:
Si prega di notare che nel diagramma non è presente PostgreSQL, e questo perché si cela dietro il termine Cloud SQL. E quando ci troviamo in Cloud SQL, dobbiamo nuovamente fare una scelta:
Va notato che questa scelta non è sempre chiara, pertanto gli sviluppatori di applicazioni spesso si lasciano guidare dall'intuizione.
In totale:
- Man mano che ci si allontana, la questione della scelta diventa sempre più attuale. E anche se ci si concentra solo su GCP, i servizi gestiti e SaaS, l'unico accenno ai RDBMS appare solo al 4° passo (e lì c'è Spanner accanto). Inoltre, la scelta di PostgreSQL compare addirittura al 5° passo, insieme a MySQL e SQL Server, quindi ci sono molte opzioni, ma bisogna scegliere.
- Non si possono dimenticare i limiti rispetto alle tentazioni. In generale, tutti vogliono Spanner, ma è costoso. Alla fine, una richiesta tipica appare più o meno così: "Fateci avere Spanner per il prezzo di Cloud SQL, siete professionisti!"
E cosa dobbiamo fare?
Senza pretendere di avere l'ultima parola, diciamo quanto segue:
È necessario cambiare approccio all'istruzione:
- non ha senso insegnare come si faceva prima ai DBA;
- la conoscenza di un singolo prodotto ora è già insufficiente;
- e conoscere decine di prodotti a livello di uno solo è impossibile.
Non è necessario conoscere solo e non tanto il prodotto, ma:
- l'uso delle sue applicazioni;
- diversi metodi di distribuzione;
- i vantaggi e gli svantaggi di ciascun metodo;
- prodotti analoghi e alternativi, per fare una scelta consapevole e ottimale, non sempre a favore del prodotto familiare.
E in più, bisogna saper migrare i dati e comprendere i principi fondamentali dell'integrazione con ETL.
Caso reale
Recentemente ho dovuto realizzare il back-end per un'app mobile. Al momento dell'inizio del lavoro, il back-end era già stato sviluppato e pronto per l'implementazione, e il team di sviluppo aveva impiegato circa due anni per questo progetto. Le seguenti attività erano state previste:
- costruire CI/CD;
- fare una revisione dell'architettura;
- lanciare tutto in produzione.
L'app stessa era microservizi, e il codice in Python/Django era stato sviluppato da zero e direttamente in GCP. Per quanto riguarda il pubblico target, si prevedeva di avere due regioni — US ed EU, e il traffico era distribuito tramite il Global Load balancer. Tutti i Workloads e il carico computazionale operavano in Google Kubernetes Engine.
Per quanto riguarda i dati, c'erano 3 strutture:
- Cloud Storage;
- Datastore;
- Cloud SQL (PostgreSQL).
Potrebbe sorgere la domanda, perché è stato scelto Cloud SQL? A dire il vero, tale domanda negli ultimi anni provoca una certa imbarazzante pausa — si ha l'impressione che le persone si siano vergognate delle basi relazionali, ma continuano ad usarle attivamente ;-).
Nel nostro caso, Cloud SQL è stato scelto per i seguenti motivi:
- Come accennato, l'applicazione è stata sviluppata utilizzando Django, e dispone di un modello che visualizza i dati persistenti da un database SQL in oggetti Python (Django ORM).
- Il framework supportava un elenco finale piuttosto completo di DBMS:
- PostgreSQL;
- MariaDB;
- MySQL;
- Oracle;
- SQLite.
Pertanto, PostgreSQL è stato scelto da questo elenco piuttosto intuitivamente (non è proprio il caso di scegliere Oracle, in effetti).
Cosa mancava:
- l'applicazione era implementata solo in 2 regioni, e nel piano era prevista una terza (Asia);
- Il database si trovava nella regione nordamericana (Iowa);
- ci sono state preoccupazioni da parte del cliente riguardo a possibili ritardi di accesso dall'Europa e dall'Asia e interruzioni nella gestione in caso di downtime del DBMS.
Considerato che lo stesso Django può lavorare con più DB in parallelo e dividerli per lettura e scrittura, le registrazioni nell'applicazione non erano così numerose (oltre il 90% — lettura). In generale, se si poteva creare una replica di lettura del database principale in Europa e Asia, sarebbe stata una soluzione di compromesso. E cosa c'è di così difficile in questo?
La difficoltà stava nel fatto che il cliente non voleva rinunciare all'uso dei servizi gestiti e di Cloud SQL. Le capacità di Cloud SQL al momento sono limitate. Cloud SQL supporta High availability (HA) e Read Replica (RR), ma quest'ultima è supportata solo in una regione. Creando un database nella regione americana, non è possibile fare una replica di lettura nella regione europea tramite Cloud SQL, anche se lo stesso PostgreSQL non lo impedisce. La corrispondenza con i dipendenti di Google non ha portato a nulla e si è conclusa con promesse di tipo "conosciamo il problema e ci stiamo lavorando, un giorno verrà risolto".
Se si elencano a punti le capacità di Cloud SQL, apparirà all'incirca così:
1. High availability (HA):
- nell'ambito di una singola regione;
- tramite replicazione su disco;
- non vengono utilizzati meccanismi PostgreSQL;
- è possibile la gestione automatica e manuale — failover/failback;
- durante la commutazione, il DBMS non è disponibile per alcuni minuti.
2. Read Replica (RR):
- nell'ambito di una singola regione;
- hot standby;
- replicazione streaming PostgreSQL.
Inoltre, come è consueto, quando si sceglie una tecnologia ci si scontra sempre con qualche limitazione.:
- Il cliente non voleva creare entità e utilizzare l'IaaS, tranne che tramite GKE;
- il cliente non voleva implementare PostgreSQL/MySQL self-service;
- Beh, in generale, Google Spanner andrebbe bene, se non fosse per il suo prezzo, però con Django ORM non funziona, ma in effetti è uno strumento valido.
Considerando la situazione, dal cliente è arrivata una domanda sorprendente: «Potete fare qualcosa di simile, che funzioni come Google Spanner, ma che funzioni anche con Django ORM?»
Opzione di soluzione n. 0
La prima idea che mi è venuta in mente:
- restare nell'ambito di CloudSQL;
- non ci sarà replicazione integrata tra le regioni in alcuna forma;
- cercare di collegare una replica al Cloud SQL esistente by PostgreSQL;
- avviare un'istanza di PostgreSQL da qualche parte e in qualche modo, ma toccare almeno il master.
Purtroppo, si è scoperto che non era possibile farlo, poiché non c'era accesso all'host (che si trova in un altro progetto) — pg_hba e così via, e inoltre non c'era accesso come superuser.
Opzione di soluzione n. 1
Dopo alcune nuove riflessioni e tenendo conto delle circostanze precedenti, il pensiero si è leggermente adattato:
- continuiamo a cercare di restare nell'ambito di CloudSQL, ma passiamo a MySQL, poiché Cloud SQL by MySQL ha un master esterno che:
— funge da proxy per MySQL esterno;
— appare come un'istanza di MySQL;
— è stato progettato per la migrazione dei dati da altri cloud o da On-premises.
Poiché la configurazione della replicazione MySQL non richiede accesso all'host, in linea di principio funzionava, ma era molto instabile e scomoda. E quando siamo andati oltre, è diventato spaventoso, poiché stavamo distribuendo l'intera struttura con terraform, e improvvisamente è emerso che il master esterno non è supportato da terraform. Sì, Google ha un CLI, ma per qualche motivo anche qui funzionava a singhiozzo — a volte si creava, a volte no. Forse perché il CLI era stato pensato per la migrazione dei dati dall'esterno e non per le repliche.
Di fatto, è diventato chiaro che Cloud SQL non andava bene per niente. Come si suol dire, abbiamo fatto tutto ciò che potevamo.
Opzione di soluzione n. 2
Dal momento che non siamo riusciti a rimanere nell'ambito di Cloud SQL, abbiamo cercato di formulare i requisiti per una soluzione compromissoria. I requisiti sono stati i seguenti:
- lavorare in Kubernetes, massimizzare l'uso delle risorse e delle capacità di Kubernetes (DCS, ...) e GCP (LB, ...);
- assenza di zavorra da una miriade di cose inutili nel cloud come HA proxy;
- possibilità di eseguire HA PostgreSQL o MySQL nella regione principale; nelle altre regioni — HA derivante dalla regione principale più una copia (per affidabilità);
- multi master (non volevamo collegarci a esso, ma non era fondamentale)
.
Di conseguenza, con questi requisiti, finalmente è apparsa una proposta.opzioni appropriate per DBMS e interfacce:
- MySQL Galera;
- CockroachDB;
- strumenti PostgreSQL
:
— pgpool-II;
— Patroni.
MySQL Galera
La tecnologia MySQL Galera è stata sviluppata dall'azienda Codership e consiste in un plugin per InnoDB. Caratteristiche:
- multi master;
- replica sincrona;
- lettura da qualsiasi nodo;
- scrittura su qualsiasi nodo;
- meccanismo HA integrato;
- disponibile un Helm chart da Bitnami.
CockroachDB
Dalla descrizione sembra un'ottima soluzione ed è un progetto open source scritto in Go. Il principale partecipante è Cockroach Labs (fondata da ex membri di Google). Questo DBMS relazionale è stato originariamente progettato per essere distribuito (con scalabilità orizzontale "out of the box") e resiliente. I suoi autori hanno dichiarato di voler "combinare la ricchezza delle funzionalità SQL con l'accessibilità orizzontale tipica delle soluzioni NoSQL."
Un piacevole vantaggio è il supporto al protocollo di connessione PostgreSQL.
Pgpool
È un'estensione per PostgreSQL, in realtà, una nuova entità che gestisce tutte le connessioni. Ha il proprio bilanciatore di carico e parser, è soggetto a licenza BSD. Offre ampie possibilità, ma può sembrare un po' complicato, poiché la presenza di una nuova entità potrebbe portare a qualche imprevisto.
Patroni
Questo è l'ultimo che ha catturato la mia attenzione e, a quanto pare, non a caso. Patroni è un'utilità open source che, in sostanza, è un demone scritto in Python, che consente la gestione automatica dei cluster PostgreSQL con vari tipi di replica e switch automatico dei ruoli. Si è rivelata molto interessante, poiché si integra bene con Kubernetes e non introduce nuove entità.
Cosa abbiamo scelto alla fine
La scelta non è stata affatto semplice:
- CockroachDB — ottima, ma rischiosa;
- MySQL Galera — anche buona, usata in molti contesti, ma MySQL;
- Pgpool — molte entità superflue, integrazione scadente con il cloud e K8s;
- Patroni — eccellente integrazione con K8s, senza entità superflue, si integra bene con GCP LB.
Pertanto, la scelta è caduta su Patroni.
Conclusioni
È giunto il momento di riassumere brevemente. Sì, il mondo dell'infrastruttura IT è cambiato sostanzialmente ed è solo l'inizio. Se un tempo i cloud erano solo un altro tipo di infrastruttura, ora è tutto diverso. Non solo, le innovazioni nei cloud appaiono costantemente e continueranno ad apparire, e forse appariranno solo nei cloud e successivamente, grazie ai startup, verranno trasferite in On-premises.
Per quanto riguarda SQL, SQL continuerà a vivere. Ciò significa che è necessario conoscere PostgreSQL e MySQL e saperci lavorare, ma è ancora più importante saperli applicare correttamente.
Fonte: habr.com
