Ciao a tutti e bentornati.
Nel video di oggi discuteremo le basi del proxy di Rrd.
Prima di approfondire l'argomento, è importante comprendere le basi
e i vantaggi offerti dal proxy di database.
Per prima cosa, quindi, analizziamo le basi del proxy di database con una panoramica di alto livello.
Il proxy di database è un intermediario tra l'utente e il database, e lo stesso può essere rappresentato da
questo diagramma in cui il proxy agisce come intermediario tra il client e il database.
Ora, uno dei vantaggi di questo approccio è che, poiché tutte le query del client passano attraverso questo
specifico proxy, ci sono molti controlli e ottimizzazioni che possono essere applicati a livello di proxy.
Ad esempio, supponiamo di voler bloccare un tipo specifico di richiesta.
Questo è qualcosa che si può fare a livello di proxy.
Quindi, se una richiesta di questo tipo viene ricevuta da un client, ogni volta che viene bloccata direttamente da un proxy, la richiesta
non arriva mai al database e quindi ci sono molti controlli e ottimizzazioni che si possono applicare in questa architettura.
Per capire meglio le cose, prendiamo un semplice caso d'uso associato a uno scenario di failover.
In questo diagramma specifico, abbiamo un singolo database e tutte le connessioni al database passano
attraverso il proxy.
Ora, per qualche motivo, diciamo che questo database primario fallisce in questi casi.
Se è disponibile un database di standby, il proxy può procedere a reindirizzare la richiesta all'istanza
del database di standby.
Va bene.
In questo caso, il cliente non deve preoccuparsi dell'indirizzo IP dell'istanza del DB in standby,
perché se il primario cambia l'indirizzo IP del DB cambierà anche l'URL del database.
Ma poiché il client si sta connettendo al proxy, quest'ultimo si occupa di reindirizzare la richiesta,
insieme a quella esistente che era arrivata al proxy e che doveva andare al database primario.
Poiché il database primario si è guastato, il proxy può reindirizzare le richieste al DB di standby.
Queste richieste non falliranno e questo migliorerà anche la resilienza complessiva dell'applicazione.
Altrimenti, se il client comunicasse direttamente con il DB primario e se quest'ultimo si guastasse,
l'intera applicazione andrebbe in tilt e questo non è consigliabile per la produzione.
Ora, per comprendere il proxy AIDS, è importante capire le basi della
connessione al database.
Ad esempio, quando un client invia una richiesta a un database, diciamo che un client invia una richiesta di scrittura
in cui vuole scrivere un dato specifico nel database.
Quindi, dietro le quinte, anche se un piccolo dato viene scritto nel database, ci sono molti passaggi che vengono
effettuati dietro le quinte.
Quindi, uno dei primi passi è che l'applicazione utilizza il driver del database per aprire la connessione
al database.
Questa è la prima parte.
In secondo luogo, il socket di rete è aperto a livello di sistema operativo per collegare l'applicazione
al database.
Poi c'è anche l'autenticazione che avviene.
Inoltre, i dati vengono scritti una volta completata l'autenticazione e una volta completata l'operazione,
qualunque sia l'operazione del database, la connessione può essere chiusa dal lato dell'applicazione e quindi il
socket di rete viene chiuso.
Da qui si capisce che anche se un client vuole leggere una piccola quantità di dati o scrivere una piccola
quantità di dati, dietro le quinte avvengono molte cose.
E questo a sua volta costa in termini di CPU e memoria.
Ora, se c'è una sola richiesta, questo non ha un vero impatto, ma diciamo che ci sono milioni di richieste, ci
sono milioni di utenti che visitano il sito web, ci sono milioni di richieste che
vanno al database.
Il mantenimento della connessione al database aumenta notevolmente il carico.
Per ovviare a questo problema, esiste un concetto chiamato connection pooling.
Il pooling delle connessioni al database è quindi un modo per ridurre i costi di apertura e chiusura delle connessioni
mantenendo un pool di connessioni aperte.
In questo caso si ha un esempio di proxy tra un proxy e un database.
Esiste una connessione aperta già stabilita.
Quindi, quando il client invia la richiesta al proxy, dato che le connessioni sono già presenti, il proxy
userà la connessione esistente per andare avanti ed eseguire l'operazione richiesta dal
client.
Quindi un certo insieme o un certo pool di connessioni aperte viene mantenuto dal proxy e questo riduce
il costo in termini di CPU e memoria.
Va bene.
Spero quindi che abbiate compreso alcuni dei vantaggi che un proxy di database può offrire.
In modo simile, quando parliamo di annunci, abbiamo una funzione chiamata RDF Proxy.
Quindi, in una panoramica di alto livello, Ideas proxy è un proxy di database completamente gestito per Amazon ideas, come stiamo discutendo.
Simile alle idee di Proxy di database, anche Proxy fornisce una serie di vantaggi come il pooling delle connessioni.
Abbiamo discusso come la disponibilità nel caso in cui il DB primario si guasti, il proxy può connettersi automaticamente
all'istanza di standby e le connessioni non vengono interrotte.
Inoltre, si ha il vantaggio dell'autenticazione: a livello di proxy è possibile applicare l'autenticazione IAM per il
database, senza dover specificare le credenziali del database.
Quindi tutte queste operazioni possono essere eseguite a livello di proxy.
Quindi facciamo una cosa.
Procediamo con una rapida dimostrazione.
Per la dimostrazione di oggi ho un'istanza di database disponibile.
Apriamo rapidamente la discussione.
È l'endpoint del database.
Procediamo ora a collegarci rapidamente ad esso dal CLA.
Procedo con la connessione rapida all'endpoint del database.
Specifico il nome utente di admin e la password come previsto.
Siamo connessi e se facciamo qualcosa come mostrare i database, siamo in grado di vedere l'elenco delle
griglie dei database.
Quindi andiamo avanti e usciamo.
In questa fase abbiamo preso un esempio in cui il client comunica direttamente con il database.
Ora facciamo un esempio di proxy Rrd, in cui il client si connette al database attraverso
un proxy Rrd.
Ora, dalla console IDS, ho già configurato il proxy.
Lasciate che vi mostri rapidamente.
Quindi è stato configurato un proxy.
Ora, se guardiamo qui, c'è un endpoint proxy.
Questo è l'endpoint a cui il client deve connettersi.
In genere, una volta disponibile il proxy, occorre configurare il client in modo che
invii le richieste solo al proxy e non al database.
Se lo si desidera, è possibile applicare questo metodo utilizzando il gruppo di sicurezza.
E all'interno di voi vedete che avete il gruppo target e il gruppo target qui è il database uno.
Quindi il database associato è il database uno, che non è altro che questo database specifico.
Quindi il proxy è collegato al database.
Ora andiamo avanti e inviamo la richiesta all'endpoint del proxy.
Quindi, sempre dal mio CLA, proviamo a connetterci al proxy.
Specifichiamo la password.
E come vedete, siamo collegati al database.
Se si esegue di nuovo il comando mostra database, si vedrà lo stesso elenco di database disponibili
Ora, dato che è presente il proxy degli ID.
Diverse cose, come il pooling delle connessioni e altre, sono gestite automaticamente dal proxy.
Oltre a questo, ci sono anche altre cose che potete far rispettare.
Vi fornisco rapidamente un esempio.
Quindi, nell'autenticazione IAM, è possibile specificare se è necessario o meno.
A volte, come in questo caso, abbiamo fornito manualmente l'amministratore, l'utente e la password.
Diciamo che non volete o non volete assolutamente permetterlo.
Anche questo è un aspetto che può essere applicato a livello di proxy.
Quindi, se lo si seleziona come richiesto, significa che è consentita solo l'autenticazione IM, le credenziali del database non possono essere utilizzate,
quindi tutte queste cose possono essere configurate.
Se lo si desidera, si può anche configurare il TLS.
Ottimo.
Spero quindi che con questa panoramica di alto livello abbiate capito le basi di ciò che il nostro proxy ci permette
di fare e con questo concludo il video di oggi.