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à.

Esecuzione di un proof of concept con Amazon Aurora

Di seguito, troverai una spiegazione di come impostare ed eseguire un proof of concept per Aurora. Un proof of concept è una verifica che esegui per capire se Aurora è la scelta giusta per la tua applicazione. Il proof of concept permette di comprendere le funzionalità di Aurora nel contesto delle tue applicazioni di database e di confrontare Aurora con il tuo attuale ambiente di database. Inoltre, mostra il livello di impegno necessario per spostare i dati, trasferire il codice SQL, ottimizzare le prestazioni e adattare le procedure di gestione correnti.

In questo argomento, troverai una panoramica e un riepilogo dettagliato delle procedure e delle decisioni generali associate all'esecuzione di un proof of concept, elencate di seguito. Per istruzioni dettagliate, puoi utilizzare i link alla documentazione completa per argomenti specifici.

Panoramica di un proof of concept di Aurora

L'esecuzione di un proof of concept per Amazon Aurora ti permette di capire cosa devi fare per trasferire i dati e le applicazioni SQL esistenti in Aurora. Puoi mettere in pratica gli aspetti importanti di Aurora su scala, utilizzando un volume di dati e attività rappresentativo del tuo ambiente di produzione. L'obiettivo è accertarti che i punti di forza di Aurora rispondano efficacemente alle sfide che ti hanno portato ad abbandonare la tua precedente infrastruttura di database. Al termine di un proof of concept, disporrai di un solido piano per il benchmark delle prestazioni su più vasta scala e il test dell'applicazione. A quel punto, sarai in grado di comprendere i maggiori elementi di lavoro per una distribuzione in produzione.

I seguenti consigli sulle best practice ti aiutano a evitare errori comuni che causano problemi durante il benchmark. Tuttavia, questo argomento non illustra il processo dettagliato per eseguire i benchmark e l'ottimizzazione delle prestazioni. Tali procedure variano a seconda del carico di lavoro e delle funzionalità di Aurora che utilizzi. Per informazioni dettagliate, consulta la documentazione relativa alle prestazioni, ad esempio Gestione delle prestazioni e del dimensionamento dei cluster DB Aurora, Miglioramenti alle prestazioni di Amazon Aurora MySQL, Prestazioni e dimensionamento per Amazon Aurora PostgreSQL e Monitoraggio del carico DB con Performance Insights su Amazon Aurora.

Le informazioni in questo argomento si riferiscono principalmente alle applicazioni in cui la tua organizzazione scrive il codice e progetta lo schema e che supportano i motori di database open source MySQL e PostgreSQL. Se stai testando un'applicazione commerciale o un codice generato dal framework di un'applicazione, potresti non avere la flessibilità necessaria per applicare tutte le linee guida. In tal caso, rivolgiti al tuo rappresentante di AWS per sapere se esistono best practice o casi di studio di Aurora per il tuo tipo di applicazione.

1. Individuare gli obiettivi

Quando valuti Aurora nell'ambito di un proof of concept, puoi scegliere quali misurazioni eseguire e come valutare il successo della prova.

Devi accertarti che tutte le funzionalità dell'applicazione siano compatibili con Aurora. Poiché le versioni principali di Aurora sono compatibili con le corrispondenti versioni principali di MySQL e PostgreSQL, anche la maggior parte delle applicazioni sviluppate per tali motori è compatibile con Aurora. Tuttavia, è sempre necessario convalidare la compatibilità per ciascuna applicazione.

Ad esempio, alcune scelte relative alla configurazione fatte durante l'impostazione di un cluster Aurora influenzano la possibilità o la necessità di utilizzare specifiche funzionalità del database. Potresti iniziare con il tipo di cluster Aurora destinato a scopi più generici, detto assegnato. Successivamente, puoi stabilire se una configurazione specifica, ad esempio serverless o con query in parallelo, offre vantaggi per il tuo carico di lavoro.

Le domande seguenti aiutano a individuare e quantificare gli obiettivi:

Ti invitiamo ad acquisire conoscenza sui motori di database e sulle funzionalità della piattaforma di Aurora e a consultare la documentazione sui servizi. Prendi nota di tutte le funzionalità che possono aiutarti a raggiungere i risultati desiderati. Una di queste potrebbe essere il consolidamento dei carichi di lavoro, descritto nel post di AWS Database Blog Come pianificare e ottimizzare la compatibilità di Amazon Aurora con MySQL per carichi di lavoro consolidati. Un'altra potrebbe essere la scalabilità in base alla domanda, descritta in Dimensionamento automatico di Amazon Aurora con le repliche Aurora nella Guida per l'utente di Amazon Aurora. Altre ancora potrebbero essere l'aumento delle prestazioni o la semplificazione delle operazioni di database.

2. Comprendere le caratteristiche del carico di lavoro

Valuta Aurora nel contesto del caso d'uso previsto. Aurora è una valida scelta per i carichi di lavoro di elaborazione di transazioni online (OLTP). Inoltre, è possibile eseguire report sul cluster che ospita i dati OLTP in tempo reale senza il provisioning di un cluster di data warehouse separato. Per capire se il tuo caso d'uso rientra in queste categorie, verifica le caratteristiche seguenti:

Uno dei principali fattori che influenzano le scelte relative al database è la velocità dei dati. Velocità elevata significa che i dati vengono inseriti e aggiornati molto frequentemente. Un sistema di questo tipo potrebbe avere migliaia di connessioni e centinaia di migliaia di query simultanee con lettura e scrittura da e verso un database. Di solito, le query in sistemi a velocità elevata interessano un numero relativamente ridotto di righe e in genere accedono a più colonne nella stessa riga.

Aurora è concepito per gestire dati a velocità elevata. A seconda del carico di lavoro, un cluster Aurora con un'unica istanza di database r4.16xlarge può elaborare più di 600.000 istruzioni SELECT al secondo. Anche in questo caso, a seconda del carico di lavoro, tale cluster può elaborare 200.000 INSERT, UPDATE e DELETE istruzioni al secondo Aurora è un database con archiviazione su righe, ideale per carichi di lavoro OLTP con elevati livelli di volume, throughput e parallelismo.

Aurora può inoltre eseguire query di report nello stesso cluster che gestisce il carico di lavoro OLTP. Aurora supporta fino a 15 repliche, ciascuna delle quali è in media a 10-20 millisecondi dall'istanza primaria. Gli analisti possono eseguire query su dati OLTP in tempo reale senza copiare i dati in un cluster di data warehouse separato. Con i cluster Aurora che utilizzano la funzionalità di query in parallelo, puoi effettuare l'offload di gran parte del lavoro di elaborazione, filtraggio e aggregazione al sottosistema di storage Aurora a elevata distribuzione.

Utilizza questa fase di pianificazione per acquisire familiarità con le funzionalità di Aurora, altri servizi AWS, la Console di gestione AWS e la AWS CLI. Inoltre, verifica il modo in cui queste funzionalità interagiscono con gli strumenti che prevedi di utilizzare nel proof of concept.

3. Fare pratica con la Console di gestione AWS o la AWS CLI

La fase successiva è fare pratica con la Console di gestione AWS o la AWS CLI, per prendere dimestichezza con questi strumenti e con Aurora.

Pratica con la Console di gestione AWS

Le seguenti attività iniziali con i cluster database Aurora consentono principalmente di familiarizzare con l'ambiente Console di gestione AWSe fare pratica con la configurazione e la modifica di cluster Aurora. Se utilizzi motori di database compatibili con MySQL e PostgreSQL con Amazon RDS, puoi sfruttare le stesse conoscenze per usare Aurora.

Sfruttando il modello di storage condiviso di Aurora e funzionalità come la replica e le snapshot, puoi trattare interi cluster database come un altro tipo di oggetto che gestisci liberamente. Durante il proof of concept, puoi frequentemente impostare, eliminare e modificare la capacità dei cluster Aurora. Non sei vincolato alle scelte iniziali relative a capacità, impostazioni del database e layout fisico dei dati.

Per iniziare, imposta un cluster Aurora vuoto. Scegli il tipo di capacità assegnato e l'ubicazione regionale per gli esperimenti iniziali.

Collegati al cluster utilizzando un programma client come un'applicazione a riga di comando SQL. Inizialmente, ti colleghi tramite l'endpoint del cluster. Ti collegi a tale endpoint per eseguire qualsiasi operazione di scrittura, come le istruzioni DDL (Data Definition Language) e i processi di estrazione, trasformazione e caricamento (ETL). Nelle fasi successive del proof of concept, colleghi sessioni con un numero elevato di query utilizzando l'endpoint di lettura, che distribuisce il carico di lavoro di query su più istanze database nel cluster.

Dimensiona il cluster aggiungendo altre repliche Aurora. Per queste procedure, consulta Replica con Amazon Aurora. Aumenta e riduci le istanze database modificando la classe di istanza AWS. Osserva come Aurora semplifica questi tipi di operazioni in modo tale che, se le stime iniziali della capacità di sistema non sono accurate, puoi regolarle in un secondo momento senza dover ricominciare da capo.

Crea una snapshot e ripristinala in un cluster diverso.

Esamina i parametri del cluster per visualizzare l'attività nel tempo e il modo in cui i parametri si applicano alle istanze database nel cluster.

È utile capire bene fin dall'inizio come svolgere queste operazioni mediante la Console di gestione AWS. Dopo aver capito cosa è possibile fare con Aurora, puoi procedere con l'automazione di tali operazioni tramite la AWS CLI. Le sezioni seguenti forniscono ulteriori dettagli sulle procedure e le best practice per queste attività durante il periodo del proof of concept.

Pratica con la AWS CLI

Consigliamo di automatizzare le procedure di distribuzione e gestione, anche nell'ambito di un proof of concept. Per farlo, acquisisci familiarità con la AWS CLI se non la conosci già. Se utilizzi motori di database compatibili con MySQL e PostgreSQL con Amazon RDS, puoi sfruttare le stesse conoscenze per usare Aurora.

Aurora include generalmente gruppi di istanze database disposte in cluster. Pertanto, molte operazioni prevedono di stabilire quali istanze database sono associate a un cluster ed eseguire poi le operazioni amministrative in un loop per tutte le istanze.

Ad esempio, potresti automatizzare passaggi come la creazione di cluster Aurora e il successivo dimensionamento con classi di istanze più grandi o il dimensionamento orizzontale con ulteriori istanze database. Questo aiuta a ripetere qualsiasi fase nel proof of concept e a esplorare scenari ipotetici con diversi tipi di configurazioni di cluster Aurora.

Scopri le funzionalità e le limitazioni degli strumenti di distribuzione dell'infrastruttura come AWS CloudFormation. Potresti constatare che le attività che esegui nel contesto di un proof of concept non sono indicate per l'utilizzo in produzione. Ad esempio, il comportamento di CloudFormation per la modifica è creare una nuova istanza ed eliminare quella corrente, compresi i relativi dati. Per maggiori dettagli su questo comportamento, consulta Aggiornamento dei comportamenti delle risorse stack nella Guida per l’utente di AWS CloudFormation.

4. Creare il cluster Aurora

Con Aurora, puoi esplorare scenari ipotetici aggiungendo istanze database al cluster e dimensionando le istanze database a classi di istanze più potenti. Puoi anche creare cluster con diverse impostazioni di configurazione per eseguire lo stesso carico di lavoro contemporaneamente. Con Aurora, hai molta flessibilità per impostare, eliminare e riconfigurare i cluster database. Pertanto, è utile fare pratica con queste tecniche nelle prime fasi del processo di proof of concept. Per le procedure generali per la creazione di cluster Aurora, consulta Creazione di un cluster database Amazon Aurora.

Se utile, inizia con un cluster con le seguenti impostazioni. Salta questo passaggio solo se prevedi casi d'uso specifici. Ad esempio, potresti saltare questo passaggio se il caso d'uso richiede un tipo speciale di cluster Aurora oppure se necessiti di una particolare combinazione di versione e motore di database.

5. Configurare lo schema

Nel cluster Aurora, configura i database, le tabelle, gli indici, le chiavi esterne e gli altri oggetti dello schema per l'applicazione. Se effettui il passaggio da un altro sistema di database compatibile con MySQL o con PostgreSQL, questa fase sarà semplice e diretta. Per il motore di database, utilizzi le stesse sintassi e riga di comando di SQL o altre applicazioni client che già conosci.

Per inviare istruzioni SQL al cluster, individua l'endpoint del cluster e fornisci quel valore come parametro di connessione all'applicazione client. Puoi trovare l'endpoint del cluster nella scheda Connectivity (Connettività) della pagina dei dettagli del cluster. L'endpoint del cluster è quello con l'etichetta Writer (di scrittura). L'altro endpoint, con etichetta Reader (di lettura), rappresenta una connessione di sola lettura che puoi fornire agli utenti finali che eseguono report o altre query di sola lettura. Per eventuali problemi di connessione al cluster, consulta Connessione a un cluster database Amazon Aurora.

Se trasferisci lo schema e i dati da un sistema di database diverso, probabilmente a questo punto dovrai apportare modifiche allo schema. Queste modifiche allo schema devono essere in linea con la sintassi e le funzionalità SQL disponibili in Aurora. A questo punto, potresti tralasciare alcuni vincoli, colonne e trigger o altri oggetti dello schema. Questo può essere utile soprattutto se tali oggetti richiedono la rielaborazione per la compatibilità Aurora e non sono importanti per gli obiettivi del proof of concept.

Se esegui la migrazione da un sistema di database con un motore sottostante diverso da quello di Aurora, valuta l'utilizzo di AWS Schema Conversion Tool (AWS SCT) per semplificare il processo. Per informazioni dettagliate, consulta la Guida per l'utente di AWS Schema Conversion Tool. Per informazioni generiche sulle attività di migrazione e trasferimento, consulta il whitepaper AWS Migrazione dei database su Amazon Aurora .

Durante questa fase, puoi valutare se vi sono inefficienze nell'impostazione dello schema, ad esempio nella strategia di indicizzazione o altre strutture a tabella come le tabelle partizionate. Tali inefficienze possono essere amplificate quando implementi l'applicazione su un cluster con più istanze database e un carico di lavoro pesante. Valuta se è possibile ottimizzare questi aspetti prestazionali ora o durante attività successive come un test di benchmark completo.

6. Importare i dati

Durante il proof of concept, trasferisci i dati o un campione rappresentativo degli stessi dal precedente sistema di database. Se utile, imposta almeno alcuni dati in ciascuna delle tue tabelle. Ciò aiuta a testare la compatibilità di tutti i tipi di dati e le funzionalità dello schema. Dopo aver fatto pratica con le funzionalità base di Aurora, aumenta la quantità dei dati. Al termine del proof of concept, dovresti testare gli strumenti ETL, le query e il carico di lavoro complessivo con un set di dati abbastanza grande da consentire di trarre conclusioni accurate.

Puoi utilizzare diverse tecniche per importare dati di backup fisici o logici in Aurora. Per i dettagli, consulta Migrazione di dati a un cluster di database Amazon Aurora MySQL o Migrazione di dati su Amazon Aurora con compatibilità PostgreSQL a seconda del motore di database che utilizzi nel proof of concept.

Esegui gli esperimenti con gli strumenti e le tecnologie ETL che stai valutando. Individua quelli che soddisfano meglio le tue esigenze. Prendi in considerazione sia il throughput che la flessibilità. Ad esempio, alcuni strumenti ETL eseguono un trasferimento una tantum e altri implicano la replica continua dal sistema precedente ad Aurora.

Se effettui la migrazione da un sistema compatibile con MySQL ad Aurora MySQL, puoi utilizzare gli strumenti di trasferimento dati nativi. Lo stesso vale se effettui la migrazione da un sistema compatibile con PostgreSQL ad Aurora PostgreSQL. Se effettui la migrazione da un sistema di database che utilizza un motore sottostante diverso da quello di Aurora, puoi continuare a sperimentare con AWS Database Migration Service (AWS DMS). Per ulteriori dettagli su AWS DMS, consulta la Guida per l'utente di AWS Database Migration Service.

Per informazioni sulle attività di migrazione e trasferimento, consulta il whitepaper AWS Manuale di migrazione ad Aurora.

7. Trasferire il codice SQL

Provare SQL e le applicazioni correlate richiede diversi livelli di impegno a seconda dei casi. In particolare, il livello di impegno dipende dal fatto che il passaggio avvenga da un sistema compatibile con MySQL o con PostgreSQL oppure da un altro tipo di sistema.

Durante questa fase, puoi valutare se vi sono inefficienze nell'impostazione dello schema, ad esempio nella strategia di indicizzazione o altre strutture a tabella come le tabelle partizionate. Valuta se è possibile ottimizzare questi aspetti prestazionali ora o durante attività successive come un test di benchmark completo.

Puoi verificare la logica di connessione del database nella tua applicazione. Per sfruttare l'elaborazione distribuita di Aurora, potresti dover utilizzare connessioni separate per le operazioni di lettura e scrittura e utilizzare sessioni relativamente brevi per le operazioni di query. Per informazioni sulle connessioni, consulta 9. Connettere ad Aurora.

Prendi in considerazione l'eventualità di dover scendere a compromessi o fare rinunce per risolvere problemi nel database di produzione. Nella pianificazione del proof of concept prevedi del tempo da dedicare al miglioramento della progettazione dello schema e alle query. Per capire se puoi facilmente ottenere vantaggi in termini di prestazioni, costi operativi e scalabilità, prova l'applicazione originale e quella modificata contemporaneamente su cluster Aurora diversi.

Per informazioni sulle attività di migrazione e trasferimento, consulta il whitepaper AWS Manuale di migrazione ad Aurora.

8. Specificare le impostazioni di configurazione

Nell'ambito del proof of concept di Aurora, puoi anche rivedere i parametri di configurazione del database. Nell'ambiente corrente potresti già avere impostazioni di configurazione di MySQL o PostgreSQL ottimizzate per le prestazioni e la scalabilità. Il sottosistema di storage Aurora è adattato e ottimizzato per un ambiente basato sul cloud e distribuito con un sottosistema di storage ad alta velocità. Di conseguenza, molte impostazioni del motore di database precedente non sono valide. Consigliamo di condurre gli esperimenti iniziali con le impostazioni di configurazione di Aurora predefinite. Riapplica le impostazioni dell'ambiente corrente solo in caso di colli di bottiglia di prestazioni e scalabilità. Ulteriori informazioni su questo tema sono disponibili nel post Introduzione al motore di archiviazione Aurora su AWS Database Blog.

Aurora agevola il riutilizzo delle impostazioni di configurazione ottimali per una particolare applicazione o caso d'uso. Anziché modificare un file di configurazione separato per ciascuna istanza database, gestisci set di parametri che assegni a interi cluster o a specifiche istanze database. Ad esempio, l'impostazione del fuso orario si applica a tutte le istanze database nel cluster e puoi regolare l'impostazione della dimensione della cache della pagina per ciascuna istanza database.

Inizi con uno dei set di parametri predefiniti e applichi le modifiche solo ai parametri che devi ottimizzare. Per informazioni sull'utilizzo dei gruppi di parametri, consulta Parametri dell’istanza database e del cluster database di Amazon Aurora. Per le impostazioni di configurazione che sono o non sono applicabili ai cluster Aurora, consulta Parametri di configurazione Aurora MySQL o Amazon Aurora PostgreSQL parametri a seconda del motore di database in uso.

9. Connettere ad Aurora

Proprio come per l'impostazione dello schema e dei dati iniziali e l'esecuzione di query di esempio, puoi connetterti a diversi endpoint in un cluster Aurora. L'endpoint da utilizzare dipende dal fatto che l'operazione sia una lettura come l'istruzione SELECT oppure una scrittura come l'istruzione CREATE o INSERT. Quando incrementi il carico di lavoro su un cluster Aurora e sperimenti le funzionalità di Aurora, è importante che l'applicazione assegni ciascuna operazione all'endpoint appropriato.

Utilizzando l'endpoint del cluster per operazioni di scrittura, ti connetti sempre a un'istanza database nel cluster che ha funzionalità di lettura e scrittura. Per impostazione predefinita, solo un'istanza database in un cluster Aurora ha funzionalità di lettura e scrittura. Questa istanza database è detta istanza primaria. Se l'istanza primaria originale diventa non disponibile, Aurora attiva un meccanismo di failover e un'istanza database diversa diventa quella primaria.

Analogamente, indirizzando istruzioni SELECT all'endpoint di lettura, distribuisci il lavoro di elaborazione delle query tra le istanze database nel cluster. Ciascuna connessione viene assegnata a un'istanza database diversa tramite risoluzione DNS round robin. L'esecuzione della maggior parte del lavoro di query sulle repliche database Aurora di sola lettura riduce il carico sull'istanza primaria, liberandola per la gestione delle istruzioni DDL e DML.

L'utilizzo di questi endpoint riduce la dipendenza a nomi host hardcoded e aiuta l'applicazione a eseguire un ripristino più rapido in caso di errori delle istanze database.

Le repliche Aurora sono soggette a un ritardo di replica, anche se tale ritardo è di solito da 10 a 20 millisecondi. Puoi monitorare il ritardo di replica e stabilire se rientra nell'intervallo dei requisiti di coerenza dei tuoi dati. In alcuni casi, le query di lettura potrebbero richiedere un'elevata coerenza di lettura (coerenza lettura dopo scrittura). In questi casi, puoi continuare a utilizzare l'endpoint del cluster anziché l'endpoint di lettura.

Per sfruttare appieno le funzionalità di Aurora per l'esecuzione in parallelo distribuita, potresti dover modificare la logica della connessione. L'obiettivo è evitare di inviare tutte le richieste di lettura all'istanza primaria. Le repliche Aurora di sola lettura sono in stand by, con tutti gli stessi dati, pronte per gestire le istruzioni SELECT. Codifica la logica dell'applicazione per utilizzare l'endpoint appropriato per ciascun tipo di operazione. Segui queste linee guida generali:

Per informazioni generali sulla gestione della connessione e sugli endpoint per Aurora, consulta Connessione a un cluster database Amazon Aurora. Per un approfondimento di questo argomento, consulta l'argomento relativo alla gestione delle connessioni in Aurora MySQL Database Administrator's Handbook –.

10. Eseguire il carico di lavoro

Dopo aver eseguito le impostazioni di schema, dati e configurazione, puoi iniziare a esercitarti con il cluster eseguendo il carico di lavoro. Nel proof of concept utilizza un carico di lavoro che rispecchi i numerosi aspetti del tuo carico di lavoro di produzione. Consigliamo di prendere sempre le decisioni relative alle prestazioni utilizzando test e carichi di lavoro realistici anziché benchmark sintetici come sysbench o TPC-C. Nel caso, raccogli le misurazioni in base allo schema, ai modelli di query e al volume di utilizzo.

Nella misura in cui risulta utile, replica le effettive condizioni in cui verrà eseguita l'applicazione. Ad esempio, generalmente esegui il codice dell'applicazione su istanze Amazon EC2 nella stessa regione AWS e nello stesso Virtual Private Cloud (VPC) del cluster Aurora. Se l'applicazione di produzione viene eseguita su più istanze EC2 disposte in più zone di disponibilità, imposta l'ambiente del proof of concept nello stesso modo. Per ulteriori informazioni sulle regioni AWS, consulta Regioni e zone di disponibilità nella Guida per l'utente di Amazon RDS. Per ulteriori informazioni sul servizio Amazon VPC, consulta Che cos'è Amazon VPC? nella Guida per l'utente di Amazon VPC.

Dopo aver verificato il funzionamento delle funzionalità di base dell'applicazione e la possibilità di accedere ai dati tramite Aurora, puoi fare pratica con gli aspetti del cluster Aurora. Alcune funzionalità che potresti voler provare sono connessioni simultanee con il bilanciamento del carico, transazioni simultanee e replica automatica.

A questo punto, i meccanismi di trasferimento dei dati dovrebbero essere familiari e puoi quindi eseguire i test con una maggiore quantità di dati campione.

Questa è la fase in cui puoi vedere gli effetti della modifica delle impostazioni di configurazione come i limiti di memoria e di connessione. Rivedi le procedure che hai esplorato in 8. Specificare le impostazioni di configurazione.

Puoi inoltre sperimentare meccanismi come la creazione e il ripristino di snapshot. Ad esempio, puoi creare cluster con diverse classi di istanze AWS, numeri di repliche AWS e così via. In ogni cluster, puoi quindi ripristinare la stessa snapshot che contiene lo schema e tutti i dati. Per i dettagli su questo ciclo, consulta Creazione di uno snapshot del cluster database e Ripristino da uno snapshot cluster database.

11. Misurare le prestazioni

Le best practice in questa area sono state concepite per assicurare l'impostazione di tutti gli strumenti e i processi giusti per isolare velocemente comportamenti anomali durante le operazioni del carico di lavoro. Servono inoltre a constatare la possibilità di identificare in modo attendibile eventuali cause applicabili.

Puoi sempre visualizzare lo stato corrente del cluster o esaminare le tendenze nel tempo, analizzando la scheda Monitoring (Monitoraggio). Questa scheda è disponibile nella pagina dei dettagli della console per ciascun cluster Aurora o istanza database. Mostra i parametri del servizio di monitoraggio di Amazon CloudWatch sotto forma di grafici. Puoi filtrare i parametri per nome, per istanza database e per periodo di tempo.

Per avere più scelte nella scheda Monitoring (Monitoraggio), abilita Enhanced Monitoring (Monitoraggio avanzato) e Performance Insights nelle impostazioni del cluster. Inoltre, se non abiliti queste scelte al momento della configurazione del cluster, puoi farlo in un secondo momento.

Per misurare le prestazioni, puoi utilizzare i grafici che mostrano l'attività dell'intero cluster Aurora. Puoi verificare se le repliche Aurora hanno simili tempi di caricamento e risposta. Puoi anche visualizzare la suddivisione del lavoro tra l'istanza primaria di lettura e scrittura e le repliche Aurora di sola lettura. Se le istanze database non sono bilanciate o nel caso in cui un problema interessi solo un'istanza database, puoi esaminare la scheda Monitoring (Monitoraggio) di quella specifica istanza.

Dopo l'impostazione dell'ambiente e del carico di lavoro effettivo per emulare l'applicazione di produzione, puoi misurare le prestazioni di Aurora. Le domande più importanti da porsi sono le seguenti:

Per visualizzare le metriche di throughput e latenza, consulta la scheda Monitoraggio per un determinato cluster Aurora nella console Amazon RDS. Lo screenshot seguente mostra un esempio delle metriche Select Latency (Seleziona latenza), DML Latency (Latenza DML), Select Throughput (Seleziona throughput) e DML Throughput (Throughput DML) nella scheda Monitoraggio.

Se possibile, stabilisci valori di base per questi parametri nell'ambiente corrente. Se ciò non è pratico, crea una baseline nel cluster Aurora eseguendo un carico di lavoro equivalente all'applicazione di produzione. Ad esempio, esegui il carico di lavoro Aurora con un numero simile di utenti e query simultanei. Osserva quindi in che modo i valori cambiano durante l'esperimento con diverse classi di istanze, dimensioni del cluster, impostazioni di configurazione e così via.

Se i valori del throughput sono inferiori a quanto previsto, analizza ulteriormente i fattori che influenzano le prestazioni del database per il carico di lavoro. Analogamente, se i valori della latenza sono superiori rispetto a quanto previsto, effettua ulteriori analisi. Per farlo, monitora i parametri secondari per il server database (CPU, memoria e così via). Puoi vedere se le istanze database sono vicine ai loro limiti. Inoltre, puoi vedere quanta capacità aggiuntiva hanno le istanze database per gestire più query simultanee, query su tabelle di grandi dimensioni e così via.

Quando valuti le dimensioni e la capacità ideali del cluster Aurora, puoi trovare la configurazione che raggiunge le massime prestazioni dell'applicazione senza l'overprovisioning delle risorse. Un fattore importante è trovare le dimensioni giuste per le istanze database nel cluster Aurora. Inizia selezionando le dimensioni di un'istanza che ha CPU e capacità di memoria simili al tuo attuale ambiente di produzione. Raccogli i valori di throughput e latenza per il carico di lavoro con queste dimensioni dell'istanza. Dopo di che, aumenta l'istanza alla dimensione successiva più grande. Verifica se i valori di throughput e latenza migliorano. Inoltre, riduci le dimensioni dell'istanza per vedere se i valori di latenza e throughput rimangono invariati. L'obiettivo è ottenere il massimo throughput e la minima latenza sull'istanza più piccola possibile.

Esegui test delle prestazioni abbastanza lunghi da misurare le prestazioni del database in uno stato attivo e costante. Potresti dover eseguire il carico di lavoro per molti minuti o anche qualche ora prima di raggiungere questo stato costante. All'inizio di un'esecuzione è normale avere delle variazioni. Queste variazioni avvengono perché ciascuna replica Aurora attiva le proprie cache in base alle query SELECT che gestisce.

Aurora offre massime prestazioni con carichi di lavoro transazionali che implicano più utenti e query simultanei. Per accertarti che il carico sia sufficiente per prestazioni ottimali, esegui benchmark che utilizzano multithreading o esegui più istanze dei test prestazionali simultaneamente. Misura le prestazioni con centinaia o anche migliaia di thread client simultanei. Simula il numero di thread simultanei che prevedi nel tuo ambiente di produzione. Potresti anche eseguire ulteriori stress test con più thread per misurare la scalabilità di Aurora.

12. Fare pratica con la disponibilità elevata di Aurora

Molte delle principali funzionalità di Aurora implicano disponibilità elevata. Queste funzionalità includono la replica automatica, il failover automatico, i backup automatici con ripristino point-in-time e la possibilità di aggiungere istanze database al cluster. La sicurezza e l'affidabilità derivanti da funzionalità come queste sono importanti per le applicazioni mission critical.

La valutazione di tali funzionalità richiede un determinato approccio. Nelle attività precedenti, come la misurazione delle prestazioni, puoi osservare le prestazioni del sistema quando tutto funziona correttamente. Il test della disponibilità elevata richiede di ipotizzare il peggiore comportamento possibile. Occorre considerare vari tipi di errore, anche se tali condizioni sono rare. Potresti creare intenzionalmente dei problemi per accertarti che il sistema effettui il ripristino in modo corretto e veloce.

Consigliamo di utilizzare almeno due istanze in ciascun cluster Aurora. Le istanze database in un cluster Aurora possono coprire fino a tre zone di disponibilità. Posiziona ciascuna delle prime due o tre istanze database in una zona di disponibilità diversa. Quando inizi a utilizzare cluster più grandi, distribuisci le istanze database in tutte le zone di disponibilità della tua regione AWS. In questo modo, aumenta la tolleranza agli errori. Anche se un problema colpisce un'intera zona di disponibilità, Aurora esegue il failover su un'istanza database in un'altra zona di disponibilità. Se esegui un cluster con più di tre istanze, distribuisci le istanze database il più equamente possibile in tutte e tre le zone di disponibilità.

Per capire come simulare condizioni di errore per testare le funzionalità di disponibilità elevata, consulta Test di Amazon Aurora MySQL mediante query Fault Injection.

Nell'ambito del proof of concept, uno degli obiettivi è trovare il numero ideale di istanze database e la classe di istanza ottimale per tali istanze. Ciò richiede il bilanciamento dei requisiti di disponibilità elevata e delle prestazioni.

Per Aurora, più istanze database sono presenti in un cluster, maggiori sono i vantaggi per la disponibilità elevata. Inoltre, avere più istanze database migliora la scalabilità delle applicazioni a lettura intensiva. Aurora può distribuire più connessioni per query SELECT tra le repliche Aurora di sola lettura.

Dall'altro lato, limitare il numero di istanze database riduce il traffico di replica dal nodo primario. Il traffico di replica consuma larghezza di banda di rete, altro aspetto delle prestazioni complessive e della scalabilità. Pertanto, per le applicazioni OLTP con scrittura intensiva, è preferibile un numero ridotto di grandi istanze database anziché numerose istanze database di piccole dimensioni.

In un cluster Aurora tipico, un'unica istanza database (istanza primaria) gestisce tutte le istruzioni DDL e DML. Le altre istanze database (repliche Aurora) gestiscono solo le istruzioni SELECT. Sebbene le istanze database non svolgano esattamente la stessa quantità di lavoro, consigliamo di utilizzare la stessa classe di istanza per tutte le istanze database nel cluster. In questo modo, se si verifica un errore e Aurora promuove una delle istanze database di sola lettura a nuova istanza primaria, l'istanza primaria ha la stessa capacità di prima.

Se devi utilizzare istanze database con capacità diverse nello stesso cluster, imposta i tier di failover per le istanze database. Questi tier determinano l'ordine in cui le repliche Aurora vengono promosse dal meccanismo di failover. Le istanze database che sono molto più grandi o più piccole delle altre vanno collocate in un tier di failover inferiore. Ciò assicura che verranno scelte per ultime per la promozione.

Fai pratica con le funzionalità di ripristino dei dati di Aurora, come il ripristino point-in-time automatico, le snapshot e il ripristino manuali e il backtrack del cluster. Se appropriato, copia le snapshot in altre regioni AWS ed esegui il ripristino in altre regioni AWS per simulare scenari di DR.

Scopri quali sono i requisiti della tua organizzazione in termini di RTO (Restore Time Objective), RPO (Restore Point Objective) e ridondanza geografica. La maggior parte delle organizzazioni raggruppa questi elementi nell'ampia categoria del disaster recovery. Valuta le funzionalità di disponibilità elevata di Aurora descritte in questa sezione nel contesto del tuo processo di disaster recovery per accertarti che i tuoi requisiti di RTO e RPO siano soddisfatti.

13. Cosa fare in seguito

Il buon esito del processo di proof of concept conferma che Aurora è la soluzione giusta per il tuo carico di lavoro previsto. Durante il processo precedente, hai verificato il funzionamento di Aurora in un ambiente operativo realistico e lo hai valutato a fronte dei tuoi criteri di successo.

Dopo aver impostato e avviato l'ambiente di database con Aurora, puoi procedere a una valutazione più dettagliata, che porta alla migrazione finale e alla distribuzione della produzione. A seconda della situazione, questi ulteriori passaggi potrebbero essere inclusi o meno nel processo del proof of concept. Per informazioni sulle attività di migrazione e trasferimento, consulta il whitepaper AWS Manuale di migrazione ad Aurora.

In un altro passaggio successivo, prendi in considerazione le configurazioni di sicurezza pertinenti per il tuo carico di lavoro e concepite per rispondere ai requisiti di sicurezza in un ambiente di produzione. Pianifica i controlli da predisporre per proteggere l'accesso alle credenziali degli utenti master del cluster Aurora. Definisci i ruoli e le responsabilità degli utenti del database per controllare l'accesso ai dati archiviati nel cluster Aurora. Prendi in considerazione i requisiti di accesso al database per le applicazioni, gli script e gli strumenti o i servizi di terze parti. Esplora i servizi e le funzionalità di AWS, come l'autenticazione Gestione dei segreti AWS e AWS Identity and Access Management (IAM).

A questo punto, le procedure e le best practice per l'esecuzione di test di benchmark con Aurora dovrebbero essere chiare. Potresti dover effettuare un'ulteriore ottimizzazione delle prestazioni. Per i dettagli, consulta Gestione delle prestazioni e del dimensionamento dei cluster DB Aurora, Miglioramenti alle prestazioni di Amazon Aurora MySQL, Prestazioni e dimensionamento per Amazon Aurora PostgreSQL e Monitoraggio del carico DB con Performance Insights su Amazon Aurora. Se effettui un'ulteriore ottimizzazione, assicurati di conoscere bene i parametri che hai raccolto durante il proof of concept. Come passaggio successivo, potresti creare nuovi cluster con diverse scelte per le impostazioni di configurazione, il motore di database e la versione del database. In alternativa, potresti creare tipi di cluster Aurora per rispondere ai requisiti di specifici casi d'uso.

Ad esempio, puoi esplorare i cluster di query in parallelo di Aurora per le applicazioni HTAP (Hybrid Transaction/Analytical Processing). Se un'ampia distribuzione geografica è fondamentale per il disaster recovery o per ridurre al minimo la latenza, puoi esaminare Aurora Global Database. Se il tuo carico di lavoro è intermittente o se utilizzi Aurora in uno scenario di sviluppo/test, puoi esaminare i cluster Aurora Serverless.

I cluster di produzione potrebbero inoltre dover gestire elevati volumi di connessioni in entrata. Per conoscere queste tecniche, consulta il whitepaper AWSManuale per l'amministratore del database Aurora MySQL: gestione delle connessioni.

Se, dopo il proof of concept, stabilisci che il tuo caso d'uso non è adatto per Aurora, valuta questi altri sevizi AWS: