Scenari di utilizzo comuni

Scalabilità delle applicazioni

Gestione delle connessioni in applicazioni serverless e basate sugli eventi

Le applicazioni serverless e basate sugli eventi, come le API e i servizi Web supportati da AWS Lambda, devono spesso supportare un gran numero di richieste client di breve durata. Questo modello di utilizzo può causare l'interruzione delle connessioni sul lato del database senza la possibilità di implementare il pool di connessioni sul lato dell'applicazione. Le prestazioni del database potrebbero peggiorare a causa del solo numero di connessioni simultanee oppure il database potrebbe superare il limite di connessione, con conseguenti errori rivolti al client.

In questi scenari, RDS Proxy può offrire i seguenti vantaggi:

1. Riduce il costo di stabilire connessioni dal database al proxy e fornisce il pooling e il multiplexing delle connessioni per convertire un gran numero di connessioni client in un numero molto inferiore di connessioni al database back-end. Questo aiuta a ridurre il sovraccarico di connessione e il conflitto del database, in particolare nei motori di database come PostgreSQL, dove il costo di stabilire e mantenere le connessioni è relativamente elevato.

2. È in grado di gestire i picchi di connessione in modo più agevole. Ad esempio, quando un database supera il limite di connessione, restituisce immediatamente un errore al client. Quando il proxy RDS deve prendere in prestito una connessione dal pool ma il pool è già al massimo, il proxy può attendere che una connessione diventi disponibile. Questa funzionalità può migliorare l'esperienza del cliente trasformando gli errori gravi in un leggero aumento della latenza delle query.

3. Grazie alla dimensione configurabile del pool di connessioni, puoi anche utilizzare RDS Proxy come meccanismo di limitazione o riduzione del carico. Se il numero di connessioni supera i limiti specificati, RDS Proxy attende che una connessione diventi disponibile entro un timeout configurabile. Ciò può essere utile nei casi in cui il database gestisce più carichi di lavoro e si desidera limitare la pressione che un determinato carico di lavoro può creare sul database.

Gestione delle connessioni in applicazioni distribuite basate su container

Un'architettura applicativa distribuita basata su contenitori può contenere centinaia o addirittura migliaia di contenitori, ciascuno dei quali esegue una copia del codice dell'applicazione. Anche se i singoli contenitori sono in grado di raggruppare le connessioni, tali pool sono specifici del contenitore e quindi molto piccoli. Il numero di container moltiplicato per la dimensione di ogni mini-pool di container può potenzialmente superare i limiti di connessione sui database Amazon RDS o Aurora.

In questa situazione, la capacità di RDS Proxy di eseguire il pooling delle connessioni (riutilizzo delle connessioni) e il multiplexing (servire più client utilizzando un'unica connessione back-end) è estremamente preziosa. È comunque possibile utilizzare il pool di connessioni all'interno di ciascun contenitore per ridurre il tasso di abbandono tra i thread dell'applicazione e il proxy RDS, ma il proxy può contribuire a ridurre il numero di connessioni al database di back-end a un livello gestibile.

Miglioramento dell'utilizzo delle repliche di lettura

Read-heavy i database possono richiedere più repliche di lettura per supportare il traffico di sola lettura. Le applicazioni possono utilizzare la propria logica per scegliere a quale replica connettersi o, più comunemente, utilizzano un meccanismo DNS-based round-robin come l'endpoint Aurora Cluster Reader. Tuttavia, un DNS-based approccio può portare a un utilizzo non uniforme delle repliche a causa della memorizzazione nella cache DNS. Ad esempio, i client potrebbero «collegarsi» a una particolare replica, potrebbero non riconoscere le nuove repliche aggiunte al cluster oppure potrebbero provare a connettersi a repliche che non esistono più.

Quando si utilizza un endpoint di sola lettura del proxy RDS, il proxy instrada le connessioni client tra tutte le repliche disponibili utilizzando una logica di «connessioni meno eccezionali». Il proxy RDS non bilancia il carico del traffico in base a metriche del database come l'utilizzo della CPU, ma tenta di equalizzare il numero di connessioni client su ciascuna replica, ponderato in base al limite di connessione del database. Ad esempio, se avete tre repliche Aurora in esecuzione con un'max_connectionsimpostazione di 500, 500 e 1000 (rispettivamente), il proxy tenta di inviare circa il doppio del numero di connessioni alla terza replica rispetto alle altre due.

Puoi utilizzare gli endpoint del lettore proxy RDS con cluster Aurora o distribuzioni di cluster Amazon RDS Multi-AZ DB con due standby leggibili. Gli endpoint di lettura proxy non sono supportati per le distribuzioni di istanze DB di Amazon RDS con repliche di lettura.

Migliorare l'efficienza della connessione

Quando si introduce un proxy tra le applicazioni client e il database, l'obiettivo è in genere quello di aumentare l'efficienza della gestione delle connessioni, considerando anche il costo di latenza di un passaggio di rete aggiuntivo attraverso il proxy. Un ulteriore livello intermedio può sembrare controintuitivo per migliorare l'efficienza della connessione, perché qualsiasi connessione che sarebbe stata aperta direttamente sul database ora viene aperta con il proxy. Le fasi di handshake del protocollo sono le stesse in entrambi i casi, quindi se stai ancora spendendo risorse per gli handshake di connessione, potrebbe non essere ovvio da dove provengano i miglioramenti in termini di efficienza.

Il proxy non rende necessariamente più economiche le connessioni da stabilire. Invece, sposta la maggior parte del carico di gestione dell'handshake dal livello del database al livello proxy. Quando si pagano le risorse del database, si desidera che tali risorse vengano spese per il lavoro sul database e non per spese generali ausiliarie. Ciò diventa particolarmente importante quando si utilizzano connessioni crittografate: sebbene il sovraccarico derivante dalla trasmissione di dati crittografati tramite una connessione esistente non sia significativo, il sovraccarico iniziale legato alla configurazione di una connessione crittografata è notevole. In ambienti che utilizzano centinaia o migliaia di connessioni al secondo, questo sforzo aggiuntivo può sommarsi rapidamente. Potresti non voler spendere quel tempo dedicato alla CPU su risorse di database (relativamente costose) e invece trasferirle su un livello proxy (relativamente economico).

Per quanto riguarda la latenza introdotta da un hop di rete aggiuntivo, la sua importanza dipende da quanto «chiacchierata» è l'applicazione e dal numero di istruzioni eseguite per ogni «conversazione» con il database. In RDS Proxy, in genere si osserva una latenza aggiuntiva pari a pochi millisecondi a cifra singola, ma ciò non avrà necessariamente un impatto visibile sulle applicazioni. Esempio:

• Un carico di lavoro in cui i tempi di esecuzione delle query sono dell'ordine di decine o centinaia di millisecondi (o più) difficilmente noterà il sovraccarico del proxy, poiché si tratta di una piccola frazione del tempo totale di interrogazione.

• Un'applicazione che esegue query a una cifra in millisecondi o inferiori al millisecondo può notare una differenza perché l'overhead della query (un hop di rete aggiuntivo per query) è notevole rispetto al tempo di esecuzione della query. Questo potrebbe non essere un problema se una sessione client prevede solo una manciata di query, quindi il sovraccarico cumulativo è ancora ridotto.

Se la latenza aggiunta alla situazione è sia evidente che indesiderata, è necessario valutarla rispetto agli altri vantaggi dell'utilizzo di un proxy (pooling, multiplexing, gestione del failover).

Elevata disponibilità

Multi-AZ i database in esecuzione su Amazon RDS e Aurora (escluso Aurora DSQL) utilizzano meccanismi di failover per ripristinare la disponibilità in caso di problemi con l'istanza di database principale. I failover vengono utilizzati anche come parte dei flussi di lavoro operativi, come la scalabilità di calcolo per l'istanza principale. Un failover comporta una modifica del DNS che sposta l'endpoint del database primario (read/writecon funzionalità) dall'istanza primaria precedente a quella appena promossa. Questa modifica del DNS deve essere osservata e riconosciuta dalle applicazioni client, in modo che i client possano seguire senza indugi la modifica principale.

Alcune applicazioni possono avere difficoltà a riconoscere tempestivamente le modifiche DNS a causa della memorizzazione nella cache DNS nel sistema operativo o a livello di applicazione. Sebbene sia una buona pratica risolvere i problemi di caching DNS a livello di applicazione, non è sempre possibile a causa della complessità dell'applicazione o del costo di introduzione delle modifiche.

In questo scenario, RDS Proxy è un modo efficace per evitare ritardi nel failover. DNS-related Gli read/write endpoint e gli endpoint opzionali di sola lettura forniti da RDS Proxy sono «stabili», nel senso che gli indirizzi IP alla base di tali endpoint non cambiano quando le istanze del database si scambiano i ruoli. RDS Proxy monitora continuamente la topologia del database di back-end e astrae le modifiche apportate ai ruoli delle istanze dai client.

Esistono metodi alternativi per gestire i problemi di caching DNS, ad esempio utilizzando driver avanzati in grado di rilevare direttamente la topologia del database senza fare affidamento sul DNS. Tuttavia, potrebbe essere più semplice implementare un singolo proxy davanti al database anziché introdurre modifiche al codice e nuovi driver a livello di applicazione.

Leggi la disponibilità

Oltre a migliorare l'esperienza del cliente durante i failover del database, RDS Proxy aiuta anche a garantire la disponibilità delle applicazioni in caso di problemi di replica in lettura. Lo fa in due modi:

1. Se una replica di lettura non è disponibile, ma nel cluster sono disponibili altre repliche, il proxy può indirizzare nuove connessioni alle repliche disponibili. I client non devono preoccuparsi dei ritardi di propagazione DNS o della memorizzazione nella cache DNS.

2. Per una connessione client esistente multiplexata, il proxy può inviare le query successive da quella connessione a una replica diversa disponibile. In questa situazione, il client potrebbe anche non accorgersi che una replica back-end ha riscontrato un problema. Quando si utilizza questa tecnica, RDS Proxy garantisce che la nuova replica non sia inferiore a quella precedente in termini di ritardo di replica. In questo modo, le query successive inviate dal client non vedranno dati che potrebbero essere considerati obsoleti.

Utilizzo di più proxy con un unico obiettivo

Come best practice, usa un proxy RDS per destinazione del database, ad esempio un'istanza Amazon RDS o un cluster Aurora. Funziona bene nella maggior parte degli scenari, mantiene la configurazione semplice e rende l'esperienza del client più prevedibile. In confronto, l'utilizzo di più proxy richiede l'allineamento accurato della configurazione di tutti i proxy per evitare comportamenti imprevisti. Ad esempio, è necessario assicurarsi che la dimensione combinata di tutti i pool di proxy non superi i limiti di connessione della singola destinazione del database.

Potresti comunque esplorare l'idea di utilizzare più proxy in determinate situazioni. Le sezioni seguenti illustrano gli scenari più comuni e descrivono i pro e i contro di un approccio con proxy singolo rispetto a un approccio multiproxy.

Disponibilità dei proxy

L'infrastruttura proxy RDS è altamente disponibile e implementata su più zone di disponibilità (AZ) in base alla progettazione. La capacità del proxy è distribuita su molti nodi con monitoraggio continuo dello stato e viene regolata automaticamente in base alla dimensione dell'istanza fornita o alle impostazioni ACU massime Serverless v2 del database. Grazie alla Multi-AZ progettazione distribuita del proxy, non è necessario eseguire più proxy davanti ai cluster Amazon RDS o Aurora ai fini dell'elevata disponibilità.

In effetti, l'utilizzo di più proxy davanti a un'unica destinazione di database significa che lo stack di applicazioni è ora responsabile del rilevamento e della reazione ai problemi anziché affidarsi ai solidi meccanismi incorporati nel proxy. Di conseguenza, l'utilizzo di più proxy per motivi di elevata disponibilità è fortemente sconsigliato in quanto è probabile che comporti più problemi di quanti ne possa risolvere.

Gestione di più pool di client

Ogni proxy fornisce un read/write endpoint e (facoltativamente) endpoint aggiuntivi read/write o di sola lettura. Quando un singolo proxy viene utilizzato per gestire più gruppi di client o più carichi di lavoro, tali carichi di lavoro possono potenzialmente interferire. Ad esempio, un carico di lavoro può monopolizzare il pool di connessioni al punto che non rimangono più abbastanza connessioni libere per gestire altri carichi di lavoro. L'uso di proxy separati per isolare i carichi di lavoro potrebbe essere una soluzione convincente, ma puoi prima prendere in considerazione altre opzioni:

• Il database stesso potrebbe fornire alternative più semplici all'esecuzione di più proxy. Ad esempio, se il problema è causato da alcuni utenti che monopolizzano il pool, è possibile utilizzare il sistema di autorizzazioni del database per limitare il numero di connessioni simultanee che tali utenti possono aprire.

• Analogamente, i timeout delle query a livello di database e i timeout di inattività possono risolvere problemi relativi alle connessioni orfane o alle query in esecuzione.

• Se il problema è causato dalla durata delle query o delle transazioni o dal consumo di risorse per query anziché dal numero di connessioni simultanee, l'utilizzo di proxy aggiuntivi non sarà utile perché il proxy non impone limiti al peso delle query o delle transazioni. Se il problema non può essere risolto all'origine, puoi utilizzare lo scheduler di eventi del database per eseguire codice che rileva e interrompe l'attività del client in base a condizioni arbitrarie invece di spostare quei client problematici su un proxy separato.

Se decidi di utilizzare più proxy davanti alla stessa destinazione, assicurati che la dimensione totale di tutti i pool di connessioni non superi le capacità del database di destinazione. Ad esempio, la somma di MaxConnectionsPercent tutti i proxy deve essere inferiore a 100, altrimenti i proxy potrebbero tentare di aprire più connessioni di quelle per cui il database è configurato.

Ogni proxy viene fatturato separatamente e la tariffa di fatturazione dipende dalla dimensione delle risorse di database sottostanti e non dall'attività del carico di lavoro. Considera il costo della gestione di più proxy rispetto al costo dell'implementazione di soluzioni alternative, se esistenti.

Controllo indipendente dei pool di lettura e scrittura

Ogni proxy fornisce un read/write endpoint e (facoltativamente) endpoint aggiuntivi read/write o di sola lettura, ma i limiti e i timeout sono configurati per l'intera destinazione del proxy e non singolarmente per ogni endpoint proxy.

Ad esempio, potresti avere un cluster Aurora che gestisce un grande volume di query di sola lettura utilizzando più repliche di lettura e l'endpoint reader del proxy, ma desideri limitare il numero di read/write connessioni per ridurre la pressione delle risorse sul singolo scrittore. Poiché l'MaxConnectionsPercentimpostazione è definita per l'intero target del proxy (cluster), non è possibile limitare il numero di connessioni verso l' read/write endpoint senza influire anche sui limiti dell'endpoint di sola lettura.

Esistono diversi modi per affrontare questa sfida:

È possibile avviare repliche di lettura aggiuntive nel cluster e ridurre proporzionalmente l'impostazione del MaxConnectionsPercent proxy. Ciò preserva la dimensione totale del pool di connessioni di sola lettura riducendo al contempo il numero massimo di connessioni consentite sul writer. Tuttavia, aumenta anche il costo del cluster ed è progressivamente meno efficace quanto più numerose sono le repliche disponibili.

È possibile utilizzare gruppi di parametri a livello di istanza per configurare i limiti di connessione al database (come in max_connections Aurora MySQL o PostgreSQL) per le repliche di lettura separatamente dal writer. Tuttavia, è necessario evitare di utilizzare una configurazione asimmetrica dei parametri, poiché le repliche possono essere promosse al ruolo di scrittore durante un failover, quindi la differenziazione iniziale dei parametri non sarà permanente. È possibile prendere in considerazione la modifica delle impostazioni di priorità di failover a livello di istanza per determinare quali repliche vengono selezionate per la promozione durante i failover e utilizzarle come meccanismo di esclusione graduale del failover per rendere la configurazione asimmetrica più prevedibile. Tuttavia, le priorità di failover servono solo come suggerimenti e non costituiscono una solida garanzia del comportamento del failover. Multi-instance Le configurazioni con impostazioni asimmetriche sono quindi sconsigliate poiché richiedono un monitoraggio continuo e possono produrre comportamenti imprevisti se un failover si verifica su un'istanza che non si preferiva.

In questo scenario, l'utilizzo di più proxy potrebbe essere il modo più semplice per gestire separatamente i pool di lettura e scrittura. È possibile creare due proxy per la singola destinazione del database, quindi configurare le applicazioni per utilizzare l'endpoint writer dal primo proxy e l'endpoint di sola lettura dal secondo proxy. Un proxy gestisce solo i carichi di lavoro di scrittura, l'altro gestisce solo i carichi di lavoro di lettura e MaxConnectionsPercent (così come altre impostazioni) può essere configurato indipendentemente per ciascun proxy. Questa soluzione comporta un costo aggiuntivo per l'esecuzione del secondo proxy, ma è più semplice e prevedibile rispetto alle alternative precedenti.