Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Considerazioni sull'applicazione e sul carico di lavoro
Argomenti
Multi-tenant e ambienti multiutente
Per quanto riguarda la scalabilità e il miglioramento della gestione delle connessioni, i vantaggi dell'utilizzo di RDS Proxy dipendono dalla sua capacità di eseguire il pool di connessioni e, in misura molto maggiore, il multiplexing delle connessioni. Il pool di connessioni riduce il sovraccarico associato all'apertura e alla chiusura delle connessioni. Il multiplexing delle connessioni consente al proxy di riutilizzare una connessione al database di back-end dopo una transazione. Per ulteriori informazioni, consulta Concetti e terminologia RDS Proxy.
Quando una connessione non può essere multiplexata, il proxy ricorre a un comportamento chiamato blocco della connessione. Il pinning è una situazione in cui un client è costretto a utilizzare la stessa connessione proxy sottostante per l'intera sessione. La connessione proxy è riservata a quell'unico client, quindi non può essere riutilizzata da altri client. In altre parole, il pinning crea un'associazione 1:1 esclusiva tra una connessione client-proxy e una connessione proxy-database. Evitare il pinning è importante in tutti gli scenari in cui RDS Proxy viene utilizzato principalmente per motivi di scalabilità ed efficienza. Per il comportamento del pinning più aggiornato, consulta Evitare di effettuare il pinning di un Server proxy per RDS.
Come regola generale, le connessioni possono essere multiplexate quando hanno lo stesso stato. Le connessioni non possono essere multiplexate quando contengono informazioni personalizzate sullo stato specifico della sessione. Uno degli aspetti che definiscono lo stato della sessione è il nome utente del database associato a una connessione. Quando ci si connette al proxy come «User_a», il proxy deve aprire una connessione al database di back-end anche come «User_a». Il proxy può potenzialmente raggruppare e riutilizzare questa connessione back-end per altri client che accedono come «User_a», ma non per i client che utilizzano un nome utente diverso.
Questo comportamento può ridurre in modo significativo l'efficienza del pooling e del multiplexing in ambienti multiutente con un gran numero di account di database unici. Ciò è particolarmente vero nelle architetture che utilizzano la multi-tenancy a livello di database o a livello di schema. Se il database contiene un migliaio di schemi (uno per tenant) e ogni tenant si connette al database con un nome utente diverso, il pool di connessioni viene frammentato in micropool specifici dell'utente, riducendo l'efficienza complessiva.
Inoltre, aspetti specifici del motore di database potrebbero influire ulteriormente sull'efficienza del pooling e sulla capacità del proxy di multiplexare le connessioni:
-
In Amazon RDS e Aurora PostgreSQL, la multi-tenancy viene spesso implementata utilizzando un database per tenant. Tuttavia, in PostgreSQL, le connessioni sono specifiche del database: una connessione aperta su un database non può accedere ai dati di altri database. Pertanto, la multi-tenancy a livello di database riduce l'efficienza del pooling e del multiplexing a livello di proxy. Questa considerazione vale anche se il carico di lavoro utilizza la modalità multi-tenancy a livello di schema e le sessioni client utilizzano una soluzione personalizzata.
search_pathTuttavia, se tutte le sessioni utilizzano il percorso di ricerca predefinito e fanno riferimento a tabelle utilizzando nomi completi (schema_name.table_name), tali sessioni possono essere multiplexate. -
In Amazon RDS e Aurora MySQL, i termini «database» e «schema» sono sinonimi. Multi-tenancy viene spesso implementato utilizzando uno schema per tenant, che in MySQL equivale a un database per tenant. Le connessioni vengono aperte su un server MySQL nel suo insieme e non sono legate a uno schema. Se l'applicazione utilizza la multi-tenancy a livello di schema, il multiplexing delle connessioni è ancora possibile per i client che utilizzano lo stesso nome utente del database, anche se tali connessioni devono accedere ai dati in schemi diversi. Il multiplexing sarà più efficace se la separazione dei tenant viene effettuata a livello di applicazione anziché utilizzare account di database diversi per ogni tenant.
In ambienti con più schemi, l'efficienza del multiplexing dipende dal modo in cui si fa riferimento ai nomi delle tabelle:
-
Per i client che scelgono lo schema corrente utilizzando variabili di sessione (
SET search_path ...in PostgreSQL e in MySQL)USE schema;e quindi utilizzano nomi di tabella non qualificati nelle query (SELECT ... FROM table_namecome), il multiplexing delle connessioni funziona solo tra client che utilizzano lo stesso schema o lo stesso percorso di ricerca. -
Per i client che non modificano lo stato della sessione per definire lo schema corrente, ma utilizzano invece nomi di tabella completi nelle istruzioni SQL (come
SELECT ... FROM schema_name.table_name), il multiplexing non è vincolato allo stesso modo.
Database che servono più applicazioni o stack software
Come illustrato nella sezione precedente, alcune caratteristiche dello stato di connessione non causano il pinning, ma riducono comunque la capacità del proxy di riutilizzare le connessioni tra client diversi. Se utilizzato con destinazioni MySQL, RDS Proxy tiene traccia di una serie di istruzioni e variabili di sessione che configurano lo stato della sessione, come il set di caratteri, il fuso orario e le impostazioni di confronto. Quando un client utilizza istruzioni o variabili tracciate per configurare le impostazioni della sessione, la connessione proxy può essere riutilizzata solo per altri client che hanno gli stessi valori per tali impostazioni.
Di conseguenza, determinati comportamenti delle applicazioni e dei driver potrebbero ridurre la capacità di riutilizzare le connessioni all'interno del proxy. Ad esempio, è possibile consentire a diverse applicazioni di connettersi al database utilizzando lo stesso nome utente, presupponendo che il proxy possa riutilizzare e moltiplicare le connessioni tra tali applicazioni. Tuttavia, se un'applicazione avvia le connessioni con il fuso orario A (SET time_zone = ?) e un'altra applicazione utilizza il fuso orario B, le connessioni sono riutilizzabili all'interno di un'applicazione ma non tra le applicazioni. Ciò porta alla frammentazione del pool di connessioni, con un impatto negativo sull'efficacia del pooling e del multiplexing.
Per ulteriori informazioni, consulta Istruzioni tracciate da Server proxy per RDS per database RDS per MariaDB e RDS per MySQL. Il tracciamento dello stato della sessione non è attualmente supportato per destinazioni di database diverse da MySQL.
Consulta Linee guida di configurazione le linee guida di configurazione e le migliori pratiche per la gestione dello stato della sessione per evitare il blocco della connessione.
Utilizzo del pooling a livello di applicazione e dei driver avanzati con RDS Proxy
RDS Proxy aiuta a migliorare la scalabilità e l'efficienza della connessione in situazioni in cui l'applicazione stessa non utilizza il pool di connessioni. Allo stesso tempo, molti driver e framework includono funzionalità di pooling. Potresti anche utilizzare wrapper o driver avanzati che implementano alcune delle funzionalità del proxy a livello di driver.
L'utilizzo del pooling a livello di applicazione e di altri miglioramenti alla gestione delle connessioni non è intrinsecamente in conflitto con l'utilizzo di RDS Proxy e non ne annulla i vantaggi. Ad esempio, potresti utilizzare il pool di connessioni nei contenitori delle tue applicazioni, ma il numero di contenitori è abbastanza grande da esaurire i limiti di connessione al database senza utilizzare un proxy. Quando utilizzi RDS Proxy con pool a livello di applicazione e altre funzionalità relative alla connessione, esamina e comprendi i motivi dell'esistenza di funzionalità avanzate di gestione delle connessioni a livello di applicazione. Decidi quali di queste funzionalità vale la pena mantenere (o sono innocue) e quali possono sovrapporsi o interferire con il comportamento del proxy. Esempio:
-
Le funzionalità di pooling integrate nei driver e nei framework possono essere utili anche se sembrano sovrapporsi alla funzionalità del proxy RDS. Se un pool a livello di applicazione migliora l'efficienza della connessione locale oltre ai vantaggi offerti dal proxy, puoi mantenerlo.
-
Le funzionalità relative alla gestione del failover potrebbero interferire con la logica del proxy RDS o aumentare la complessità complessiva dello stack senza offrire vantaggi. Ad esempio, se l'applicazione monitora attivamente la topologia dei cluster Aurora per DNS-related evitare ritardi nel failover, non è più necessario farlo con RDS Proxy. Mantenere questa logica di tracciamento della topologia potrebbe portare a comportamenti indesiderati, ad esempio i thread dell'applicazione aggirano il proxy e si connettono direttamente alle singole istanze del database. In questo scenario, è possibile disabilitare la logica di tracciamento a livello di applicazione e consentire a RDS Proxy di astrarre automaticamente la topologia del cluster.
-
Le librerie di pool di connessioni potrebbero utilizzare funzionalità di gestione dello stato che sembrano utili in teoria, ma interferiscono con il comportamento dei proxy. Un esempio sono le librerie PostgreSQL che chiamano la query per ripristinare lo stato di connessione
DISCARD ALLtra i prestiti. Potrebbe sembrare che la reimpostazione delle connessioni possa facilitare il pooling e il multiplexing, ma interferisce con la gestione dello stato della sessione interna di Amazon RDS Proxy. Durante l'usoDISCARD, il proxy aggancia la connessione client al momento del rilascio, riducendo l'efficienza del multiplexing.
Per tutti i componenti di gestione delle connessioni a livello di applicazione che conservi, assicurati che la loro configurazione non interferisca con la logica di gestione della connessione utilizzata da Amazon RDS Proxy. Esempio:
-
Allinea le dimensioni del pool su tutti i livelli dello stack. Se i pool a livello di applicazione sono sovradimensionati (o il pool di proxy è sottodimensionato), l'applicazione potrebbe provare ad aprire connessioni per le quali il proxy non è configurato. Tali connessioni possono subire ritardi nel migliore dei casi e errori di rifiuto nel peggiore dei casi.
-
Allinea le impostazioni di timeout per ridurre il tasso di abbandono ed evitare confusione sul comportamento della connessione. Se il pool di applicazioni mantiene attive le connessioni per 300 secondi, ma il proxy è configurato per chiudere le connessioni dopo 60 secondi, l'applicazione vedrà chiusure premature delle connessioni anziché il comportamento previsto.
Alcune di queste decisioni architettoniche e scelte di configurazione potrebbero richiedere test e sperimentazioni. Non è sempre possibile prevedere con precisione il comportamento delle applicazioni in un ambiente con più livelli di pooling e gestione delle connessioni.
Linee guida di configurazionePer le linee guida di configurazione comuni, fare riferimento a.
