Strategia del pool di connessioni per Database di Azure per PostgreSQL - Server flessibile che usa PgBouncer

SI APPLICA A: Database di Azure per PostgreSQL - Server flessibile

Linee guida strategiche per la selezione del meccanismo di pool di connessioni per il server flessibile di Database di Azure per PostgreSQL.

Introduzione

Quando si usa il server flessibile di Database di Azure per PostgreSQL, per stabilire una connessione al database è necessario creare un canale di comunicazione tra l'applicazione client e il server. Questo canale è responsabile della gestione dei dati, dell'esecuzione di query e dell'avvio delle transazioni. Una volta stabilita la connessione, l'applicazione client può inviare comandi al server e ricevere risposte. Tuttavia, la creazione di una nuova connessione per ogni operazione può causare problemi di prestazioni per le applicazioni cruciali. Ogni volta che viene creata una nuova connessione, il server flessibile di Database di Azure per PostgreSQL genera un nuovo processo usando il processo postmaster, che utilizza più risorse.

Per mitigare questo problema, il pool di connessioni viene usato per creare una cache di connessioni che possono essere riutilizzate nel server flessibile di Database di Azure per PostgreSQL. Quando un'applicazione o un client richiede una connessione, questa viene creata dal pool di connessioni. Al termine della sessione o della transazione, la connessione viene restituita al pool che può riutilizzarla. Riutilizzando le connessioni, si riduce l'uso delle risorse e le prestazioni migliorano.

Anche se sono disponibili diversi strumenti per il pool di connessioni, in questa sezione vengono illustrate le diverse strategie per usare il pool di connessioni usando PgBouncer.

Che cos'è PgBouncer?

PgBouncer è un pooler di connessioni efficiente progettato per PostgreSQL, che offre il vantaggio di ridurre il tempo di elaborazione e ottimizzare l'uso delle risorse nella gestione di più connessioni client a uno o più database. PgBouncer incorpora tre modalità di pooling distinte per la rotazione della connessione:

• Pool di sessioni: questo metodo assegna una connessione server all'applicazione client per l'intera durata della connessione del client. Dopo la disconnessione dell'applicazione client, PgBouncer restituisce tempestivamente la connessione server al pool. Il meccanismo di pool di sessioni è la modalità predefinita in PgBouncer open source. Consultare la configurazione di PgBouncer
• Pool di transazioni: con il pool di transazioni, una connessione server è dedicata all'applicazione client durante una transazione. Al termine della transazione, PgBouncer rilascia in modo intelligente la connessione al server, rendendola nuovamente disponibile all'interno del pool. Il pool di transazioni è la modalità predefinita in PgBouncer predefinito nel server flessibile di Database di Azure per PostgreSQL e non supporta transazioni preparate.
• Pooling dell'istruzione: nel pooling dell'istruzione, viene allocata una connessione server all'applicazione client per ogni singola istruzione. Al termine dell'istruzione, la connessione server viene immediatamente restituita al pool di connessioni. È importante notare che le transazioni con più istruzioni non sono supportate in questa modalità.

L'utilizzo effettivo di PgBouncer può essere suddiviso in tre modelli di utilizzo distinti.

• Distribuzione con coubicazione di PgBouncer e dell'applicazione
• Distribuzioni di PgBouncer centralizzate indipendenti dall'applicazione
• Distribuzione predefinita di PgBouncer e del database

Ognuno di questi modelli presenta vantaggi e svantaggi specifici.

1. Distribuzione con coubicazione di PgBouncer e dell'applicazione

Quando si usa questo approccio, PgBouncer viene distribuito nello stesso server in cui è ospitata l'applicazione. L'applicazione e PgBouncer possono essere distribuiti in macchine virtuali tradizionali o all'interno di un'architettura basata su microservizi, come evidenziato:

I. PgBouncer distribuito nella macchina virtuale dell'applicazione

Se l'applicazione viene eseguita in una macchina virtuale di Azure, è possibile configurare PgBouncer nella stessa macchina virtuale. Per installare e configurare PgBouncer come proxy del pool di connessioni con il server flessibile di Database di Azure per PostgreSQL, seguire le istruzioni fornite nel collegamento seguente.

La distribuzione di PgBouncer in un server applicazioni può offrire diversi vantaggi, in particolare quando si lavora con i database del server flessibile di Database di Azure per PostgreSQL. Ecco alcuni tra i principali vantaggi e limitazioni di questo metodo di distribuzione:

Vantaggi:

• Latenza ridotta: distribuendo PgBouncer nella stessa macchina virtuale dell'applicazione, la comunicazione tra l'applicazione primaria e il pool di connessioni è efficiente grazie alla loro prossimità. La distribuzione di PgBouncer nella macchina virtuale dell'applicazione riduce al minimo la latenza e garantisce interazioni rapide e senza ostacoli.
• Maggiore sicurezza: PgBouncer può fungere da intermediario sicuro tra l'applicazione e il database, fornendo un ulteriore livello di sicurezza. Può applicare l'autenticazione e la crittografia, assicurando l'accesso al database solo ai client autorizzati.

In generale, la distribuzione di PgBouncer in un server applicazioni offre un approccio più efficiente, sicuro e scalabile alla gestione delle connessioni ai database del server flessibile di Database di Azure per PostgreSQL, migliorando le prestazioni e l'affidabilità dell'applicazione.

Limitazioni:

• Singolo punto di guasto: se PgBouncer viene distribuito come singola istanza nel server applicazioni, diventa un possibile singolo punto di guasto. Se l'istanza di PgBouncer è inattiva, può interrompere l'intero pool di connessioni di database, causando tempi di inattività per l'applicazione. Per mitigare il singolo punto di guasto è possibile configurare più istanze di PgBouncer dietro un servizio di bilanciamento del carico per ottenere disponibilità elevata.
• Scalabilità limitata: la scalabilità di PgBouncer dipende dalla capacità del server in cui è distribuito. Se il server applicazioni raggiunge il limite di connessione, PgBouncer può diventare un collo di bottiglia, limitando la possibilità di dimensionare l'applicazione. Potrebbe essere necessario distribuire il carico della connessione tra più istanze di PgBouncer o prendere in considerazione soluzioni alternative come il pool di connessioni a livello di applicazione.
• Complessità della configurazione: la configurazione e l'ottimizzazione di PgBouncer possono essere operazioni complesse, soprattutto quando si considerano fattori come limiti di connessione, dimensionamento del pool e bilanciamento del carico. Gli amministratori devono ottimizzare attentamente la configurazione di PgBouncer per soddisfare i requisiti dell'applicazione e garantire prestazioni e stabilità ottimali.

È importante considerare queste limitazioni rispetto ai vantaggi e valutare se PgBouncer è la scelta giusta per l'applicazione specifica e la configurazione del database.

II. PgBouncer distribuito come sidecar del servizio Azure Kubernetes

È possibile usare PgBouncer come contenitore sidecar se l'applicazione è in contenitori ed è in esecuzione nel servizio Azure Kubernetes, in un'istanza di Azure Container, in App contenitore di Azure o in Azure Red Hat OpenShift (ARO). Il modello sidecar trae ispirazione dal concetto di sidecar collegato a una moto, dove un contenitore ausiliario, noto come contenitore sidecar, è collegato a un'applicazione padre. Questo modello arricchisce l'applicazione padre estendendone le funzionalità e fornendo un supporto aggiuntivo.

Il modello sidecar viene in genere usato con i contenitori che vengono programmati insieme come gruppo atomico di contenitori. La distribuzione di PgBouncer in un sidecar del servizio Azure Kubernetes crea una stretta associazione tra i cicli di vita dell'applicazione e del sidecar e condivide risorse come nome host e rete per un uso efficiente delle risorse. Il sidecar PgBouncer opera insieme al contenitore dell'applicazione nello stesso pod nel servizio Azure Kubernetes con mapping 1:1 e funge da proxy del pool di connessioni per il server flessibile di Database di Azure per PostgreSQL.

Questo modello sidecar viene in genere usato con i contenitori che vengono programmati insieme come gruppo atomico di contenitori. Il modello sidecar crea una stratta associazione tra i cicli di vita dell'applicazione e del sidecar e dispone di risorse condivise, ad esempio nome host e rete. Usando questa configurazione, PgBouncer ottimizza la gestione delle connessioni e semplifica la comunicazione efficiente tra l'applicazione e l'istanza del server flessibile di Database di Azure per PostgreSQL.

Microsoft ha pubblicato un'immagine proxy del sidecar PgBouncer nel registro contenitori di Microsoft.

Per altri dettagli, vedere questo articolo.

Ecco alcuni tra i principali vantaggi e limitazioni di questo metodo di distribuzione:

Vantaggi:

• Latenza ridotta: distribuendo PgBouncer come sidecar del servizio Azure Kubernetes, la comunicazione tra l'applicazione primaria e il pool di connessioni è efficiente e non presenta problemi grazie alla loro prossimità. La distribuzione di PgBouncer come sidecar del servizio Azure Kubernetes riduce al minimo la latenza e garantisce interazioni rapide e senza ostacoli.
• Gestione e distribuzione semplificate: la stretta associazione tra PgBouncer e il contenitore dell'applicazione semplifica il processo di gestione e distribuzione. Entrambi i componenti sono strettamente integrati, consentendo di semplificare l'amministrazione e di avere un coordinamento senza problemi.
• Disponibilità elevata e resilienza della connessione: se si verifica un errore o un riavvio del contenitore dell'applicazione, il contenitore sidecar PgBouncer segue subito queste operazioni, garantendo una disponibilità elevata. Questa configurazione garantisce la resilienza della connessione e mantiene prestazioni prevedibili anche durante i failover, contribuendo a creare un sistema affidabile e solido.

Considerando PgBouncer come sidecar del servizio Azure Kubernetes, è possibile usare questi vantaggi per migliorare le prestazioni dell'applicazione, semplificare la gestione e garantire la disponibilità continua del pool di connessioni.

Limitazioni:

• Problemi di prestazioni della connessione: nelle applicazioni su larga scala che usano migliaia di pod e che eseguono ognuna il sidecar PgBouncer, si possono riscontrare potenziali problemi correlati all'esaurimento delle connessioni al database. Questa situazione può comportare una riduzione delle prestazioni e un'interruzione del servizio. La distribuzione di un PgBouncer sidecar per ogni pod aumenta il numero di connessioni simultanee al server di database, che può superare la sua capacità. Di conseguenza, il database potrebbe faticare a gestire il volume elevato di connessioni in ingresso, potrebbe causare problemi di prestazioni, ad esempio tempi di risposta più lunghi o persino interruzioni del servizio.
• Distribuzione complessa: l'utilizzo del modello sidecar introduce un livello di complessità per il processo di distribuzione, poiché prevede l'esecuzione di due contenitori all'interno dello stesso pod. Ciò può potenzialmente complicare le attività di risoluzione dei problemi e debug, richiedendo ulteriori sforzi per identificare e risolvere i problemi.
• Problemi di dimensionamento: è importante notare che il modello sidecar potrebbe non essere la scelta ideale per le applicazioni che richiedono una scalabilità elevata. L'inclusione di un contenitore sidecar può imporre più requisiti di risorse, limitando potenzialmente il numero di pod che possono essere creati e gestiti in modo efficiente.

Quando si prende in considerazione il modello sidecar, è fondamentale valutare attentamente i compromessi tra la complessità della distribuzione e i requisiti di scalabilità per determinare l'approccio più appropriato per lo scenario specifico dell'applicazione.

2. Distribuzione di PgBouncer centralizzate indipendenti dall'applicazione

Quando si usa questo approccio, PgBouncer viene distribuito come servizio centralizzato, indipendente dall'applicazione. Il servizio PgBouncer può essere distribuito nelle macchine virtuali tradizionali o all'interno di un'architettura basata su microservizi, come evidenziato:

I. PgBouncer distribuito in una macchina virtuale Ubuntu dietro Azure Load Balancer

Il proxy di connessione PgBouncer viene configurato tra il livello dell'applicazione e del database dietro Azure Load Balancer, come illustrato nell'immagine. In questo modello più istanze di PgBouncer vengono distribuite dietro un bilanciamento del carico come servizio per mitigare un singolo punto di guasto. Questo modello è adatto anche negli scenari in cui l'applicazione è in esecuzione in un servizio gestito, ad esempio Servizi app di Azure o Funzioni di Azure, e si connette al servizio PgBouncer per semplificare l'integrazione con l'infrastruttura esistente.

Per installare e configurare il proxy del pool di connessioni PgBouncer con il server flessibile di Database di Azure per PostgreSQL, fare riferimento al collegamento.

Ecco alcuni tra i principali vantaggi e limitazioni di questo metodo di distribuzione:

Vantaggi:

• Rimozione di un singolo punto di guasto: la connettività dell'applicazione potrebbe non essere interessata dall'errore di una singola macchina virtuale PgBouncer, perché sono presenti diverse istanze di PgBouncer dietro Azure Load Balancer.
• Integrazione semplice con i servizi gestiti: se l'applicazione è ospitata in una piattaforma di servizi gestiti, ad esempio Servizi app di Azure o Funzioni di Azure, la distribuzione di PgBouncer in una macchina virtuale consente una facile integrazione con l'infrastruttura esistente.
• Configurazione semplificata nella macchina virtuale di Azure: se l'applicazione è già in esecuzione in una macchina virtuale di Azure, configurare PgBouncer nella stessa macchina virtuale è semplice. La distribuzione di PgBouncer nella macchina virtuale garantisce che PgBouncer venga distribuito in prossimità dell'applicazione, riducendo al minimo la latenza di rete e ottimizzando le prestazioni.
• Configurazione non intrusiva: distribuendo PgBouncer in una macchina virtuale, è possibile evitare di modificare i parametri del server nel server flessibile di Database di Azure per PostgreSQL. Ciò è utile quando si vuole configurare PgBouncer in un'istanza del server flessibile di Database di Azure per PostgreSQL. Ad esempio, se si modifica il parametro SSLMODE su "obbligatorio" nel server flessibile di Database di Azure per PostgreSQL si potrebbe verificare un errore in alcune applicazioni che si basano su SSLMODE=FALSE. La distribuzione di PgBouncer in una macchina virtuale separata consente di mantenere la configurazione del server predefinita, pur sfruttando i vantaggi di PgBouncer.

Considerando questi vantaggi, la distribuzione di PgBouncer in una macchina virtuale offre una soluzione conveniente ed efficiente per migliorare le prestazioni e la compatibilità dell'applicazione in esecuzione nell'infrastruttura di Azure.

Limitazioni:

• Sovraccarico di gestione: poiché PgBouncer è installato nella macchina virtuale, potrebbe verificarsi un sovraccarico di gestione per gestire più file di configurazione. Ciò complica la gestione degli aggiornamenti delle versioni, delle nuove versioni e degli aggiornamenti del prodotto.
• Parità delle funzionalità: se si esegue la migrazione da PostgreSQL tradizionale al server flessibile di Database di Azure per PostgreSQL e si usa PgBouncer, potrebbero verificarsi alcune problemi con le funzionalità. Ad esempio, potrebbe mancare il supporto md5 nel server flessibile di Database di Azure per PostgreSQL.

II. PgBouncer centralizzato distribuito come servizio all'interno del servizio Azure Kubernetes

Se si usano distribuzioni altamente scalabili e di grandi dimensioni in contenitori nel servizio Azure Kubernetes, costituite da centinaia di pod o in situazioni in cui più applicazioni devono connettersi a un database condiviso, è possibile usare PgBouncer come servizio autonomo anziché come contenitore sidecar.

Usando PgBouncer come servizio separato, è possibile gestire e usare in modo efficiente il pool di connessioni per le applicazioni su scala più ampia. Questo approccio permette di centralizzare la funzionalità del pool di connessioni, consentendo a più applicazioni di connettersi alla stessa risorsa di database mantenendo al contempo prestazioni ottimali e un buon utilizzo delle risorse.

L'immagine proxy del sidecar PgBouncer pubblicata nel registro contenitori Microsoft può essere usata per creare e distribuire un servizio.

Ecco alcuni tra i principali vantaggi e limitazioni di questo metodo di distribuzione:

Vantaggi:

• Affidabilità avanzata: la distribuzione di PgBouncer come servizio autonomo consente la configurazione a disponibilità elevata. Ciò migliora l'affidabilità complessiva dell'infrastruttura di pool di connessioni, garantendo la disponibilità continua anche in caso di errori o interruzioni.
• Utilizzo ottimale delle risorse: se l'applicazione o il server di database dispone di risorse limitate, scegliere un computer separato dedicato all'esecuzione del servizio PgBouncer può essere vantaggioso. Distribuendo PgBouncer in un computer con abbondanti risorse, è possibile garantire prestazioni ottimali ed evitare problemi di contesa delle risorse.
• Gestione centralizzata della connessione: Quando è richiesta la gestione centralizzata delle connessioni alle banche dati, un servizio PgBouncer autonomo offre un approccio più semplificato. Consolidando le attività di gestione delle connessioni in un servizio centralizzato, è possibile monitorare e controllare in modo efficace le connessioni alle banche dati tra più applicazioni, semplificando l'amministrazione e garantendo la coerenza.

Considerando PgBouncer come servizio autonomo all'interno del servizio Azure Kubernetes, è possibile usare questi vantaggi per ottenere un miglioramento dell'affidabilità, dell'efficienza delle risorse e della gestione centralizzata delle connessioni alle banche dati.

Limitazioni:

• Maggiore latenza di rete: durante la distribuzione di PgBouncer come servizio autonomo, è importante considerare la possibile introduzione di una maggiore latenza. Ciò è dovuto alla necessità di passare le connessioni tra l'applicazione e il servizio PgBouncer tramite la rete. È fondamentale valutare i requisiti di latenza dell'applicazione e prendere in considerazione i compromessi tra la gestione centralizzata delle connessioni e i possibili problemi di latenza.

Sebbene l'esecuzione di PgBouncer come servizio autonomo offre vantaggi come la gestione centralizzata e l'ottimizzazione delle risorse, è importante valutare l'impatto della possibile latenza sulle prestazioni dell'applicazione per assicurarsi che sia allineato ai requisiti specifici.

3. PgBouncer predefinito nel server flessibile di Database di Azure per PostgreSQL

Database di Azure per PostgreSQL - Server flessibile offre PgBouncer come soluzione predefinita per pool di connessioni. Questo è un servizio facoltativo che può essere abilitato per ogni server di database. PgBouncer viene eseguito nella stessa macchina virtuale dell'istanza del server flessibile di Database di Azure per PostgreSQL. Man mano che il numero di connessioni aumenta superando alcune centinaia o migliaia, il server flessibile di Database di Azure per PostgreSQL può riscontrare limitazioni delle risorse. In questi casi, PgBouncer predefinito può offrire un vantaggio significativo migliorando la gestione delle connessioni inattive e di breve durata nel server di database.

Per abilitare e configurare il pool di connessioni PgBouncer nel server flessibile di Database di Azure per PostgreSQL, fare riferimento al collegamento.

Ecco alcuni tra i principali vantaggi e limitazioni di questo metodo di distribuzione:

Vantaggi:

• Configurazione facile: con PgBouncer predefinito nel server flessibile di Database di Azure per PostgreSQL, non è necessaria un'installazione separata o una configurazione complessa. Può essere facilmente configurato direttamente dai parametri del server, garantendo un'esperienza semplice.
• Vantaggi del servizio gestito: come servizio gestito, gli utenti possono usufruire dei vantaggi di altri servizi gestiti di Azure. Sono inclusi gli aggiornamenti automatici, che eliminano la necessità di manutenzione manuale e assicurano che PgBouncer rimanga aggiornato con le funzionalità e le patch di sicurezza più recenti.
• Supporto per connessioni private e pubbliche: PgBouncer predefinito nel server flessibile di Database di Azure per PostgreSQL offre supporto per connessioni sia pubbliche che private. Ciò consente agli utenti di stabilire connessioni sicure su reti private o connettersi esternamente, a seconda dei requisiti specifici.
• Disponibilità elevata: in caso di failover, in cui a un server di standby viene assegnato ruolo primario, PgBouncer si riavvia senza problemi al momento dello standby appena avviato senza dover modificare la stringa di connessione dell'applicazione. Ciò garantisce la disponibilità continua e riduce al minimo le interruzioni dell'applicazione.
• Conveniente: è conveniente perché gli utenti non devono pagare per un calcolo aggiuntivo, ad esempio una macchina virtuale o un contenitore, anche se ha un impatto sulla CPU perché si tratta di un altro processo che viene eseguito nello stesso computer.

Con PgBouncer predefinito nel server flessibile di Database di Azure per PostgreSQL, gli utenti possono usufruire della praticità della configurazione semplificata, dell'affidabilità di un servizio gestito, del supporto per varie modalità di pooling e della disponibilità elevata senza problemi durante gli scenari di failover.

Limitazioni:

• Non supportato con possibilità di burst: PgBouncer non è attualmente supportato con il livello di calcolo del server con possibilità di burst. Se si modifica il livello di calcolo da Utilizzo generico o Ottimizzato per la memoria a Con possibilità di burst, si perde la funzionalità di PgBouncer.
• Ristabilire le connessioni dopo il riavvio: ogni volta che il server viene riavviato durante le operazioni di scalabilità, il failover della disponibilità elevata o un riavvio, viene riavviato anche PgBouncer insieme alla macchina virtuale del server. Di conseguenza, le connessioni esistenti devono essere ristabilite.

Sono stati illustrati diversi modi per implementare PgBouncer e la tabella riepiloga i metodi di distribuzione che è possibile scegliere:

Criteri di selezione	PgBouncer nella macchina virtuale dell'app	PgBouncer nella macchina virtuale con ALB*	PgBouncer sul sidecar del servizio Azure Kubernetes	PgBouncer come servizio	PgBouncer predefinito nel server flessibile di Database di Azure per PostgreSQL
Gestione semplificata
DISPONIBILITÀ ELEVATA
App nei contenitori
Sovraccarico e latenza di rete ridotto
Controllo con granularità fine sul monitoraggio e sul debug

Legenda

Livello di difficoltà	Simbolo
Facile
Medio
Difficile

*ALB: Azure Load Balancer.