Come sopravvivere a un database SQL nel 21° secolo: cloud, Kubernetes e PostgreSQL multimaster

Ciao, membri di Habr. Oggi inizia il corso della prima classe «PostgreSQL». Pertanto, vogliamo parlarvi di come si è svolto il webinar aperto su questo corso.

In il prossimo open lesson abbiamo discusso delle sfide che hanno affrontato i database SQL nell'era del cloud e di Kubernetes. Abbiamo anche esaminato come i database SQL si adattano e mutano in risposta a queste sfide.

Il webinar è stato condotto da Valeriy Bezrukov, Google Cloud Practice Delivery Manager in EPAM Systems.

Quando gli alberi erano piccoli…

Iniziamo a ricordare come è iniziata la scelta dei DBMS alla fine del secolo scorso. Non sarà difficile, dato che la scelta del DBMS in quel periodo iniziava e finiva Oracle.

Alla fine degli anni '90 e all'inizio degli anni 2000, in effetti non c'era molta scelta, parlando di database scalabili industriali. Sì, c'erano IBM DB2, Sybase e altri database che apparivano e scomparivano, ma in generale erano meno visibili rispetto a Oracle. Di conseguenza, le competenze degli ingegneri di quel periodo erano in qualche modo legate a quell'unica scelta esistente.

Un DBA Oracle doveva sapere:

• installare Oracle Server dal pacchetto;
• configurare Oracle Server:

• init.ora;
• listener.ora;

— creare:

• spazi di tabella;
• schemi;
• utenti;

— eseguire backup e ripristino;
— effettuare monitoraggio;
— combattere le query non ottimali.

A questo proposito, non era richiesto da Oracle DBA:

• saper scegliere il DBMS ottimale o un'altra tecnologia di archiviazione e elaborazione dei dati;
• garantire alta disponibilità e scalabilità orizzontale (questo non era sempre un compito del DBA);
• conoscere bene il dominio, l'infrastruttura, l'architettura applicativa, il sistema operativo;
• eseguire caricamento e scaricamento dei dati, migrazione dei dati tra diversi DBMS.

In generale, se parliamo della scelta in quei tempi, ricorda la scelta in un negozio sovietico alla fine degli anni '80:

Il nostro tempo

Da allora, ovviamente, gli alberi sono cresciuti, il mondo è cambiato, e ora è così:

È cambiato anche il mercato dei DBMS, come ben evidenziato nel recente rapporto di Gartner:

E qui non possiamo non notare che il cloud ha trovato la sua nicchia, la cui popolarità è in crescita. Se leggiamo lo stesso rapporto di Gartner, vedremo le seguenti conclusioni:

1. Molti clienti sono in procinto di trasferire le applicazioni nel cloud.
2. Le nuove tecnologie emergono inizialmente nel cloud e non è detto che in futuro possano trasferirsi in un'infrastruttura non cloud.
3. Il modello di pricing pay-as-you-go è ormai diventato consueto. Tutti preferiscono pagare solo per ciò che utilizzano, e questo non è più un trend, ma una pura constatazione di fatto.

Cosa succede adesso?

Oggi siamo tutti nel cloud. Le domande che ci poniamo riguardano la scelta. E le opzioni sono enormi, anche se parliamo solo della selezione delle tecnologie DBMS in formato On-premises. Inoltre, abbiamo servizi gestiti e SaaS. Di conseguenza, la scelta diventa sempre più complessa ogni anno.

Accanto alle questioni relative alla scelta, ci sono anche fattori limitanti:

• il prezzo. Molte tecnologie continuano a comportare costi;
• abilità. Quando parliamo di software open source, sorge la questione delle competenze, poiché il software gratuito richiede da parte delle persone che lo implementano e lo gestiscono una competenza adeguata;
• funzionalità. Non tutti i servizi disponibili nel cloud e costruiti, ad esempio, anche sulla base di Postgres, presentano le stesse funzionalità di Postgres On-premises. Questo è un fattore significativo che bisogna conoscere e comprendere. Inoltre, questo fattore assume un'importanza maggiore rispetto alla conoscenza di alcune funzionalità nascoste di un sistema di gestione di database specifico.

Cosa ci si aspetta attualmente da DA/DE:

• buona comprensione del dominio e dell'architettura applicativa;
• capacità di scegliere correttamente la tecnologia del DBMS in base al compito assegnato;
• abilità nel selezionare il metodo ottimale per implementare la tecnologia scelta nel contesto delle limitazioni esistenti;
• competenza nel trasferire e migrare i dati;
• capacità di realizzare e gestire le soluzioni scelte.

L'esempio seguente basato su GCP mostra come avviene la scelta di una determinata tecnologia di gestione dei dati in base alla loro struttura:

Si noti che nello schema non è presente PostgreSQL, e questo perché si rifugia sotto la terminologia Cloud SQL. E quando accediamo a Cloud SQL, dobbiamo nuovamente fare una scelta:

È importante notare che questa scelta non è sempre evidente, per cui gli sviluppatori dell'applicazione spesso si guidano dall'intuizione.

In totale:

1. Man mano che ci si allontana, la questione della scelta diventa sempre più rilevante. E anche se ci si concentra solo su GCP, servizi gestiti e SaaS, una menzione di RDBMS appare solo al quarto passo (e lì vicino c'è Spanner). Inoltre, la scelta di PostgreSQL appare addirittura al quinto passo, con MySQL e SQL Server nelle vicinanze, ovvero ce n'è davvero tanto, ma bisogna scegliere..
2. Non si possono dimenticare neppure le limitazioni di fronte alle tentazioni. In generale, tutti vogliono Spanner, ma è costoso. Alla fine, una richiesta tipica appare più o meno così: «Fateci pure Spanner, ma al prezzo di Cloud SQL, insomma, siete dei professionisti!»

E ora cosa si deve fare?

Senza pretesa di proporre l'ultima parola, diciamo quanto segue:

È necessario cambiare approccio all'apprendimento:

• insegnare come si faceva con i DBA in passato non ha senso;
• la conoscenza di un solo prodotto non è più sufficiente;
• e conoscere decine di essi a livello di uno solo è impossibile.

Bisogna conoscere non solo il prodotto, ma anche:

• l'uso pratico della sua applicazione;
• diversi metodi di distribuzione;
• i vantaggi e gli svantaggi di ciascun metodo;
• prodotti simili e alternativi per fare una scelta consapevole e ottimale, senza sempre optare per il prodotto familiare.

Inoltre, è essenziale saper migrare i dati e comprendere i principi di base dell'integrazione con ETL.

Caso reale

Di recente ho dovuto sviluppare il backend per un'app mobile. All'inizio del lavoro su di essa, il backend 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 assegnate:

• costruire CI/CD;
• effettuare la revisione dell'architettura;
• mettere tutto in produzione.

L'applicazione stessa era microservizi, e il codice in Python/Django era stato sviluppato da zero e immediatamente su GCP. Per quanto riguarda il pubblico di destinazione, si prevedeva che ci sarebbero stati due regioni - US e EU, e il traffico veniva distribuito tramite 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).

Può sorgere la domanda: perché è stato scelto Cloud SQL? A dire il vero, questa domanda provoca un certo imbarazzo negli ultimi anni — sembra che le persone si stiano vergognando dei database relazionali, eppure continuano a usarli attivamente ;-).

Per quanto riguarda il nostro caso, Cloud SQL è stato scelto per le seguenti ragioni:

1. Come accennato, l'applicazione è stata sviluppata utilizzando Django, che dispone di un modello per mappare i dati persistenti da un database SQL a oggetti Python (Django ORM).
2. Il framework supportava una lista piuttosto limitata di DBMS:

• PostgreSQL;
• MariaDB;
• MySQL;
• Oracle;
• SQLite.

Di conseguenza, abbiamo scelto PostgreSQL da questo elenco più per intuizione (d'altronde, non possiamo davvero scegliere Oracle).

Cosa mancava:

• l'applicazione era distribuita solo in 2 regioni, e ne era prevista una 3ª (Asia);
• Il database si trovava nella regione nordamericana (Iowa);
• c'erano preoccupazioni da parte del cliente riguardo a potenziali ritardi di accesso dall'Europa e dall'Asia e interruzioni nel servizio in caso di inattività del DBMS.

Anche se Django stesso può lavorare con più database in parallelo e dividerli tra lettura e scrittura, le registrazioni nell'applicazione non erano così numerose (oltre il 90% sono letture). In generale, se fosse stato possibile fare una replica in lettura del database principale in Europa e Asia, sarebbe stata una soluzione compromissoria. Ma qual è il problema qui?

La difficoltà stava nel fatto che il cliente non voleva rinunciare all'uso dei servizi gestiti e di Cloud SQL. E al momento, le funzionalità di Cloud SQL sono limitate. Cloud SQL supporta l'High availability (HA) e la Read Replica (RR), ma la stessa RR è supportata solo in una regione. Creando un database nella regione americana, non è possibile fare una replica in lettura nella regione europea con gli strumenti di Cloud SQL, anche se PostgreSQL non lo impedisce. La corrispondenza con i dipendenti di Google non ha portato a nulla e si è conclusa con promesse del tipo "sappiamo del problema e ci stiamo lavorando, prima o poi la questione sarà risolta."

Se elenchiamo le funzionalità di Cloud SQL in forma di punti, apparirà circa così:

1. High availability (HA):

• all'interno di una sola regione;
• tramite replicazione del disco;
• non vengono utilizzati meccanismi di PostgreSQL;
• è possibile un controllo automatico e manuale — failover/failback;
• durante il passaggio, il DBMS è inattivo per qualche minuto.

2. Read Replica (RR):

• all'interno di una sola regione;
• hot standby;
• replicazione streaming PostgreSQL.

Inoltre, come è comune, quando si sceglie una tecnologia, ci si imbatte in limitazioni:

• il cliente non voleva generare entità e utilizzare IaaS, se non attraverso GKE;
• il cliente non sarebbe interessato a implementare self service PostgreSQL/MySQL;
• e in generale, Google Spanner sarebbe andato bene, se non fosse per il suo costo, ma con Django ORM non può funzionare, anche se è un'ottima soluzione.

Data la situazione, è arrivata una domanda da parte del cliente: «Potete fare qualcosa di simile, che funzioni come Google Spanner, ma che funzioni anche con Django ORM?»

Opzione di soluzione № 0

La prima cosa che mi è venuta in mente:

• rimanere all'interno di CloudSQL;
• non ci sarà replicazione integrata tra regioni in nessuna forma;
• cercare di collegare una replica al Cloud SQL by PostgreSQL esistente;
• lanciare un'istanza PostgreSQL in un modo o nell'altro, ma senza toccare almeno il master.

Sfortunatamente, si è scoperto che non era possibile, poiché non c'era accesso all'host (è in un altro progetto) — pg_hba e così via, e non c'era accesso come superutente.

Opzione di soluzione № 1

Dopo ulteriori riflessioni e considerando le circostanze precedenti, il nostro modo di pensare è cambiato leggermente:

• cerchiamo comunque di rimanere nell'ambito di CloudSQL, ma passiamo a MySQL, poiché Cloud SQL by MySQL offre un master esterno che:

— funge da proxy per un MySQL esterno;
— appare come un'istanza di MySQL;
— è concepito per la migrazione di dati da altri cloud o On-premises.

Poiché la configurazione della replica MySQL non richiede accesso all'host, in linea di principio tutto funzionava, ma era molto instabile e scomodo. Quando abbiamo proseguito, la situazione è diventata ancora più preoccupante, poiché stavamo distribuendo l'intera struttura con terraform e potrebbe essere risultato che il master esterno non fosse supportato da terraform. Sì, Google ha un CLI, ma per qualche motivo anche qui tutto funzionava a singhiozzo — a volte veniva creato, altre no. Forse perché il CLI è stato pensato per la migrazione di dati da esterno, non per le repliche.

A questo punto è stato chiaro che Cloud SQL non era affatto adatto. Come si suol dire, abbiamo fatto tutto ciò che potevamo.

Opzione di soluzione n. 2

Poiché non siamo riusciti a rimanere nell'ambito di Cloud SQL, abbiamo cercato di formulare i requisiti per una soluzione di compromesso. I requisiti sono risultati i seguenti:

• lavoro con Kubernetes, massimizzazione delle risorse e delle funzionalità 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 da RR della regione principale più una copia (per affidabilità);
• multi master (non volevo interagire con esso, ma non era molto cruciale)

.
Di conseguenza, a lungo termine, sono emerse finalmente popzioni di DBMS e integrazione adatte:

• MySQL Galera;
• CockroachDB;
• strumenti PostgreSQL

:
— pgpool-II;
— Patroni.

MySQL Galera

La tecnologia MySQL Galera è stata sviluppata da Codership ed è un plugin per InnoDB. Caratteristiche:

• multi master;
• replicazione sincrona;
• lettura da qualsiasi nodo;
• scrittura su qualsiasi nodo;
• meccanismo HA incorporato;
• disponibile Helm chart da Bitnami.

CockroachDB

Secondo la descrizione, è un prodotto eccezionale e rappresenta un progetto open source scritto in Go. Il principale contributore è Cockroach Labs (fondata da ex membri di Google). Questo DBMS relazionale è stato progettato fin dall'inizio per essere distribuito (con scalabilità orizzontale "out of the box") e tollerante ai guasti. I suoi autori hanno dichiarato l'obiettivo di "combinare la ricchezza delle funzionalità SQL con la disponibilità orizzontale, tipica delle soluzioni NoSQL".

Come piacevole bonus, supporta il protocollo di connessione PostgreSQL.

Pgpool

È un'estensione di PostgreSQL, in realtà, una nuova entità che gestisce tutte le connessioni e le elabora. Ha il proprio bilanciatore di carico e parser, è concesso in licenza sotto la licenza BSD. Offre ampie possibilità, ma può apparire un po' spaventoso, poiché la presenza di una nuova entità potrebbe diventare fonte di ulteriori complicazioni.

Patroni

Questo è l'ultimo sguardo e, a quanto pare, non è stato invano. Patroni è uno strumento open source che funge essenzialmente da demone in Python, permettendo la gestione automatica di cluster PostgreSQL con diversi tipi di replica e il failover automatico. Si è rivelato molto interessante, poiché si integra bene con Kubernetes e non introduce entità nuove.

Cosa abbiamo scelto alla fine

La scelta non è stata facile:

1. CockroachDB — fantastico, ma rischioso;
2. MySQL Galera — anche piuttosto valido, usato in molte situazioni, ma MySQL;
3. Pgpool — molte entità superflue, integrazione così così con il cloud e K8s;
4. Patroni — eccellente integrazione con K8s, nessuna entità superflua, si integra bene con GCP LB.

Pertanto, la scelta è caduta su Patroni.

Conclusioni

È tempo di tirare le somme. Sì, il mondo dell'infrastruttura IT è cambiato drasticamente e questo è solo l'inizio. Se prima i cloud erano solo un altro tipo di infrastruttura, ora le cose sono diverse. Inoltre, le innovazioni nei cloud stanno emergendo continuamente e, probabilmente, continueranno a farlo, sviluppandosi principalmente nei cloud per poi essere trasferite On-premises da startup.

Per quanto riguarda SQL, SQL vivrà. Ciò significa che è fondamentale conoscere e saper lavorare con PostgreSQL e MySQL, ma è ancor più importante saperli applicare correttamente.

Fonte: habr.com