PERF04-BP02 Valutazione delle opzioni disponibili - Framework AWS Well-Architected
Guida all'implementazioneLivello di impegno per il piano di implementazione: Risorse

PERF04-BP02 Valutazione delle opzioni disponibili

Prima di selezionare una soluzione di gestione dei dati, è importante capire come può migliorare le prestazioni e quali sono le opzioni disponibili per il database. Utilizza il test di carico per identificare i parametri del database più importanti per il tuo carico di lavoro. Nella valutazione delle opzioni per il database, tieni in considerazione diversi aspetti, come i gruppi di parametri, le opzioni di archiviazione, la memoria, il calcolo, la replica di lettura, l'eventuale coerenza, il pooling di connessioni e le opzioni di caching. Esegui prove con le diverse opzioni di configurazione per migliorare i parametri.

Risultato desiderato: un carico di lavoro può avere una o più soluzioni di database in base al tipo di dati. Le funzionalità e i vantaggi del database corrispondono in maniera ottimale alle caratteristiche dei dati, agli schemi di accesso e ai requisiti del carico di lavoro. Per ottimizzare le prestazioni e i costi del database, devi valutare gli schemi di accesso ai dati per determinare le opzioni di database appropriate. Valuta i tempi di query accettabili per accertarti che le opzioni di database selezionate possano rispettare i requisiti.

Anti-pattern comuni:

  • Non identificare gli schemi di accesso.

  • Non conoscere le opzioni di configurazione della soluzione di gestione dei dati scelta.

  • Basarsi soltanto sull'aumento delle dimensioni dell'istanza, senza tenere conto di altre opzioni di configurazione disponibili.

  • Non testare le caratteristiche di scalabilità della soluzione scelta.

Vantaggi dell'adozione di questa best practice: Esplorare le opzioni di database e sperimentare con esse può consentire di ridurre il costo dell'infrastruttura, migliorare le prestazioni e la scalabilità e ridurre l'impegno richiesto per mantenere i carichi di lavoro.

Livello di rischio associato se questa best practice non fosse adottata: Alto

  • L'ottimizzazione per un database universale comporta inutili compromessi.

  • Costi più elevati dovuti alla mancata corrispondenza fra la configurazione della soluzione di database e gli schemi di traffico.

  • Possibili problemi operativi come conseguenza dei problemi di dimensionamento.

  • Sicurezza dei dati non al livello richiesto.

Guida all'implementazione

Comprendi le caratteristiche dei dati del carico di lavoro per configurare al meglio le opzioni del database. Esegui test di carico per identificare i parametri prestazionali chiave e i colli di bottiglia. Utilizza queste caratteristiche e questi parametri per valutare le opzioni di database e sperimentare con diverse configurazioni.

Servizi AWS Amazon RDS, Amazon Aurora Amazon DynamoDB Amazon DocumentDB Amazon ElastiCache Amazon Neptune Amazon Timestream Amazon Keyspaces Amazon QLDB
Dimensionamento del calcolo Aumento della dimensione dell'istanza, le istanze Aurora Serverless si dimensionano automaticamente in risposta ai cambiamenti di carico Dimensionamento automatico in lettura/scrittura con la modalità capacità on demand o dimensionamento automatico della capacità assegnata in lettura/scrittura nella modalità capacità assegnata Aumento della dimensione dell'istanza Aumento della dimensione dell'istanza, aggiunta di nodi al cluster Aumento della dimensione dell'istanza Dimensionamento automatico per regolare la capacità Dimensionamento automatico in lettura/scrittura con la modalità capacità on demand o dimensionamento automatico della capacità assegnata in lettura/scrittura nella modalità capacità assegnata Dimensionamento automatico per regolare la capacità
Dimensionamento orizzontale delle letture Tutti i motori supportano le repliche di lettura. Aurora supporta il dimensionamento automatico delle istanze con replica di lettura Aumento delle unità di capacità in lettura assegnate Repliche di lettura Repliche di lettura Repliche di lettura. Supporta il dimensionamento automatico delle istanze con replica di lettura Dimensionamento automatico Aumento delle unità di capacità in lettura assegnate Aumento del dimensionamento in risposta a limiti di simultaneità documentati
Dimensionamento orizzontale delle scritture Aumento della dimensione dell'istanza, raggruppamento in batch delle scritture nell'applicazione o aggiunta di una coda davanti al database. Dimensionamento orizzontale tramite partizione a livello dell'applicazione fra più istanze Aumento delle unità di capacità in scrittura assegnate. Garanzia di una chiave di partizione ottimale per evitare limitazioni in scrittura a livello di partizione Aumento delle dimensioni dell'istanza principale Utilizzo di Redis in modalità cluster per distribuire le scritture tra le partizioni Aumento della dimensione dell'istanza Le richieste di scrittura potrebbero subire limitazioni durante il dimensionamento. Se riscontri eccezioni di limitazione, continua a inviare dati ad almeno la stessa velocità di trasmissione effettiva per attivare il dimensionamento automatico. Scritture in batch per ridurre le richieste di scrittura simultanee Aumento delle unità di capacità in scrittura assegnate. Garanzia di una chiave di partizione ottimale per evitare limitazioni in scrittura a livello di partizione Aumento del dimensionamento in risposta a limiti di simultaneità documentati
Configurazione del motore Gruppi di parametri Non applicabile Gruppi di parametri Gruppi di parametri Gruppi di parametri Non applicabile Non applicabile Non applicabile
Caching Caching in memoria, configurabile tramite gruppi di parametri. Associazione a una cache dedicata come ElastiCache per Redis a cui assegnare le richieste per gli elementi con accesso più frequente Cache DAX completamente gestita disponibile Caching in memoria. Facoltativo: associazione a una cache dedicata come ElastiCache per Redis a cui assegnare le richieste per gli elementi con accesso più frequente La funzione principale è il caching Utilizzo della cache dei risultati delle query per memorizzare in cache il risultato delle query di sola lettura Timestream dispone di due livelli di archiviazione, uno dei quali è in memoria e ad alte prestazioni Implementazione di una cache dedicata separata come ElastiCache per Redis a cui assegnare le richieste per gli elementi con accesso più frequente Non applicabile
Alta disponibilità/ripristino di emergenza Per i carichi di lavoro, la configurazione consigliata prevede l'esecuzione di un'istanza in stand-by in una seconda zona di disponibilità, al fine di garantire la resilienza all'interno di una Regione.  Per la resilienza tra Regioni è possibile utilizzare Aurora Global Database Disponibilità elevata all'interno di una Regione. Possibilità di replicare le tabelle tra Regioni grazie alle tabelle globali di DynamoDB Creazione di più istanze in diverse zone di disponibilità per una maggiore disponibilità.  Possibilità di condividere snapshot tra Regioni e cluster grazie a DMS, per garantire funzionalità di replica tra Regioni/ripristino di emergenza La configurazione consigliata per i cluster di produzione prevede la creazione di almeno un nodo in una zona di disponibilità secondaria.  Per la replica di cluster tra Regioni è possibile utilizzare ElastiCache Global Datastore. Le repliche di lettura in altre zone di disponibilità servono come destinazioni di failover.  È possibile condividere snapshot tra Regioni e replicare cluster tramite i flussi Neptune, che consentono di replicare dati tra due cluster in due diverse Regioni. Disponibilità elevata all'interno di una Regione. La replica tra Regioni richiede lo sviluppo di un'applicazione personalizzata tramite SDK Timestream Disponibilità elevata all'interno di una Regione.  La replica tra Regioni richiede una logica applicativa personalizzata o strumenti di terze parti Disponibilità elevata all'interno di una Regione.  Per la replica tra Regioni, esporta i contenuti del registro Amazon QLDB in un bucket S3 e configura tale bucket per la replica tra Regioni.

Passaggi dell'implementazione

  1. Quali opzioni di configurazione sono disponibili per i database selezionati?

    1. I gruppi di parametri per Amazon RDS e Aurora consentono di regolare le impostazioni comuni del database a livello di motore, ad esempio la memoria allocata per la cache o la regolazione del fuso orario del database

    2. Per i servizi di database assegnati, come Amazon RDS, Aurora, Neptune, Amazon DocumentDB e quelli implementati su Amazon EC2, è possibile modificare il tipo di istanza e l'archiviazione assegnata, nonché aggiungere repliche di lettura.

    3. DynamoDB consente di specificare due modalità di capacità: on-demand e assegnata. Per rispondere ai diversi carichi di lavoro, puoi passare da una modalità all'altra e aumentare in qualsiasi momento la capacità allocata nella modalità assegnata.

  2. Il carico di lavoro comporta operazioni intensive in lettura o scrittura? 

    1. Quali sono le soluzioni disponibili per eliminare il carico delle letture (repliche di lettura, caching, ecc.)? 

      1. Per le tabelle DynamoDB, è possibile eliminare il carico delle letture grazie a DAX per il caching.

      2. Per i database relazionali è possibile creare un cluster ElastiCache per Redis e configurare l'applicazione perché legga prima dalla cache, passando poi al database se l'elemento richiesto non è presente.

      3. I database relazionali come Amazon RDS e Aurora, nonché i database assegnati NoSQL come Neptune e Amazon DocumentDB, supportano tutti l'aggiunta di repliche di lettura per eliminare il carico creato dalle parti di lettura nel carico di lavoro.

      4. I database serverless come DynamoDB si dimensionano automaticamente. Assicurati di avere abbastanza unità di capacità di lettura (RCU) assegnate per gestire il carico di lavoro.

    2. Quali soluzioni sono disponibili per il dimensionamento delle operazioni in scrittura (sharding della chiave di partizione, introduzione di una coda, ecc.)?

      1. Per i database relazionali, è possibile aumentare la dimensione dell'istanza per gestire un maggiore carico di lavoro o aumentare la capacità di IOPS allocata per gestire una maggiore velocità di trasmissione effettiva verso l'archiviazione sottostante.

        • È anche possibile introdurre una coda davanti al database, invece di eseguire direttamente la scrittura su di esso. Questo schema consente di disaccoppiare l'acquisizione dal database e controllare il flusso, in modo che il database sia in grado di gestirlo. 

        • Raggruppare in batch le richieste di scrittura, anziché creare molte transazioni di breve durata, può aiutare a migliorare la velocità di trasmissione effettiva in database relazionali con un elevato volume in scrittura.

      2. I database serverless come DynamoDB possono dimensionare automaticamente la velocità di trasmissione effettiva in scrittura oppure è possibile regolare le unità di capacità in scrittura (WCU) assegnate, a seconda della modalità di capacità. 

        • È comunque possibile che si verifichino problemi con partizioni ad accesso frequente quando si raggiungono i limiti di velocità di trasmissione effettiva per una data chiave di partizione. Questo problema può essere arginato scegliendo una chiave di partizione con una distribuzione più uniforme o eseguendo lo sharding in lettura della chiave di partizione. 

  3. Qual è il picco di transazioni per secondo (TPS) attuale o previsto? Esegui un test con questo volume di traffico da solo e con l'aggiunta di un X% per comprendere le caratteristiche di dimensionamento.

    1. È possibile utilizzare strumenti nativi come pg_bench for PostgreSQL per mettere sotto stress il database e comprendere dove si creano colli di bottiglia e quali sono le caratteristiche di dimensionamento.

    2. È utile acquisire il traffico in contesti simili alla produzione perché possa essere riprodotto per simulare condizioni reali in aggiunta ai carichi di lavoro sintetici.

  4. Se utilizzi capacità di calcolo serverless o a dimensionamento elastico, testa l'impatto del suo dimensionamento sul database. Se necessario, prevedi una gestione o un pooling delle connessioni per ridurre l'impatto sul database. 

    1. È possibile utilizzare RDS Proxy con Amazon RDS e Aurora per gestire le connessioni al database. 

    2. I database serverless come DynamoDB non hanno connessioni associate, ma valuta la capacità assegnata e le policy di dimensionamento automatico per affrontare i picchi nel carico.

  5. Se il carico è prevedibile, sono presenti picchi e periodi di inattività?

    1. In presenza di periodi di inattività, valuta la possibilità di ridurre la capacità assegnata o la dimensione dell'istanza durante questi momenti. Aurora Serverless V2 aumenterà o ridurrà automaticamente le dimensioni in base al carico.

    2. Valuta la possibilità di mettere in pausa o interrompere le istanze non di produzione al di fuori degli orari lavorativi.

  6. Devi segmentare e suddividere i tuoi modelli di dati in base agli schemi di accesso e alle caratteristiche dei dati?

    1. Valuta la possibilità di utilizzare AWS DMS o AWS SCT per spostare i dati su altri servizi.

Livello di impegno per il piano di implementazione: 

Per attuare questa best practice è necessario conoscere caratteristiche e parametri attuali dei dati. Raccogliere tali parametri, definire una linea di base e quindi utilizzare i parametri per identificare le opzioni ideali per la configurazione del database richiede un livello di impegno da basso a moderato livello di impegno La convalida migliore passa attraverso test di carico e sperimentazioni.

Risorse

Documenti correlati:

Video correlati:

Esempi correlati: