Esecuzione di un proof of concept con Amazon Aurora

PDFRSS

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. Può anche mostrare il livello di impegno necessario per spostare dati, SQL codice porta, ottimizzare le prestazioni e adattare le procedure di gestione correnti.

In questo argomento, è possibile trovare una panoramica e una step-by-step descrizione delle procedure e delle decisioni di alto livello necessarie per l'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

Quando esegui un proof of concept per Amazon Aurora, impari cosa serve per trasferire i dati e SQL le applicazioni esistenti su 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 copre il step-by-step processo di esecuzione dei benchmark e di 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 scalabilità per Amazon Aurora Postgre SQL e Monitoraggio del carico del DB con Performance Insights su Amazon Aurora.

Le informazioni contenute in questo argomento si applicano principalmente alle applicazioni in cui l'organizzazione scrive il codice e progetta lo schema e che supportano i motori di database open source My SQL e SQL Postgre. 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 questi casi, rivolgiti al tuo AWS rappresentante per verificare se esistono le best practice o i case study 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 via cavo con le corrispondenti versioni principali di My SQL e PostgreSQL, la maggior parte delle applicazioni sviluppate per tali motori sono compatibili anche 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:

• Aurora supporta tutti i casi d'uso funzionali del tuo carico di lavoro?

• Qual è la dimensione del set di dati o il livello di carico che desideri? Sei in grado di raggiungere tale livello?

• Quali sono i requisiti specifici in termini di throughput delle query o latenza? Sei in grado di soddisfarli?

• Qual è la quantità minima accettabile di tempo di inattività pianificato e non pianificato per il carico di lavoro? Sei in grado di raggiungerla?

• Quali sono i parametri necessari per l'efficienza operativa? Sei in grado di monitorarli in modo accurato?

• Aurora supporta obiettivi di business specifici, come la riduzione dei costi e l'aumento della velocità di distribuzione o provisioning? Hai un modo per quantificare questi obiettivi?

• Puoi soddisfare tutti i requisiti di sicurezza e conformità per il carico di lavoro?

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. Uno di questi potrebbe essere il consolidamento del carico di lavoro, descritto nel post del blog AWS Database Come pianificare e ottimizzare Amazon Aurora with SQL My compatibility for consolidated workload. Un'altra potrebbe essere la scalabilità in base alla domanda, descritta in Auto Scaling di Amazon Aurora con 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 è un'ottima scelta per i carichi di lavoro di elaborazione delle transazioni online (OLTP). È inoltre possibile eseguire report sul cluster che contiene i OLTP dati in tempo reale senza dover fornire un cluster di data warehouse separato. Per capire se il tuo caso d'uso rientra in queste categorie, verifica le caratteristiche seguenti:

• Elevata simultaneità, con decine, centinaia o migliaia di client simultanei.

• Ampio volume di query a bassa latenza (da millisecondi a secondi).

• Transazioni brevi e in tempo reale.

• Modelli di query altamente selettivi, con ricerche basate su indici.

• PerHTAP, query analitiche che possono sfruttare la query parallela Aurora.

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 di archiviazione a righe ed è ideale per carichi di lavoro ad alto volume, throughput elevato e altamente parallelizzati. OLTP

Aurora può anche eseguire query di reporting sullo 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 interrogare OLTP i dati in tempo reale senza copiarli 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 AWS servizi, e. AWS Management Console AWS CLI Inoltre, verifica il modo in cui queste funzionalità interagiscono con gli strumenti che prevedi di utilizzare nel proof of concept.

3. Esercitati con o AWS Management ConsoleAWS CLI

Come passaggio successivo, esercitati con il AWS Management Console o il AWS CLI, per acquisire familiarità con questi strumenti e con Aurora.

Esercitati con AWS Management Console

Le seguenti attività iniziali con i cluster di database Aurora servono principalmente a familiarizzare con l' AWS Management Console ambiente ed esercitarsi a configurare e modificare i cluster Aurora. Se utilizzi i motori di SQL database compatibili con My e Postgre SQL con AmazonRDS, puoi sfruttare queste conoscenze quando usi 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.

Connect a quel cluster utilizzando un programma client, ad esempio un'applicazione da SQL riga di comando. Inizialmente, ti colleghi tramite l'endpoint del cluster. Ti connetti a quell'endpoint per eseguire qualsiasi operazione di scrittura, come le istruzioni Data Definition Language (DDL) e i processi di estrazione, trasformazione, 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 o riduci le istanze DB modificando la classe dell' AWS istanza. 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 acquisire familiarità con queste operazioni sin dall' AWS Management Console inizio. Dopo aver capito cosa è possibile fare con Aurora, puoi procedere con l'automazione di tali operazioni tramite la AWS CLI. Nelle sezioni seguenti, puoi trovare maggiori dettagli sulle procedure e le migliori pratiche per queste attività durante il proof-of-concept periodo.

Esercitati con AWS CLI

Consigliamo di automatizzare le procedure di implementazione e gestione, anche in un proof-of-concept ambiente. A tal fine, acquisisci familiarità con il AWS CLI se non lo sei già. Se utilizzi i motori di SQL database compatibili con My e Postgre SQL con AmazonRDS, puoi sfruttare queste conoscenze quando usi 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 scoprire che le attività che svolgi in un proof-of-concept contesto non sono adatte all'uso in produzione. Ad esempio, il AWS CloudFormation comportamento di modifica consiste nel creare una nuova istanza ed eliminare quella corrente, inclusi 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. Detto questo, è utile mettere in pratica queste tecniche nelle prime fasi del proof-of-concept processo. 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.

• Disattiva Creazione rapida. Per il proof of concept, ti consigliamo di conoscere tutte le impostazioni scelte in modo da poter creare cluster identici o leggermente diversi in un secondo momento.

• Usa una versione recente del motore DB. Queste combinazioni di motore di database e versione hanno un'ampia compatibilità con altre funzionalità di Aurora e un notevole utilizzo da parte dei clienti per le applicazioni di produzione.

  • Aurora My SQL versione 3.x (compatibilità con My SQL 8.0)

  • Aurora Postgre SQL versione 15.x o 16.x

• Scegli il modello Dev/Test (Sviluppo/Test). Questa scelta non è importante per le tue attività. proof-of-concept

• Per DB instance class (Classe dell’istanza database), scegli Memory optimized classes (Classi ottimizzate per la memoria) e una delle classi di istanze xlarge. Puoi modificare la classe di istanza in un secondo momento.

• Sotto Multi-AZ Deployment (Implementazione Multi-AZ), scegli Create an Aurora Replica or Reader node in a different AZ (Crea una replica Aurora o nodo di lettura in un AZ differente). Molti degli aspetti più utili di Aurora riguardano i cluster e le diverse istanze database. È utile iniziare sempre con almeno due istanze database in qualsiasi nuovo cluster. L'utilizzo di una diversa zona di disponibilità per la seconda istanza database aiuta a testare diversi scenari di disponibilità elevata.

• Quando scegli i nomi per le istanze database, utilizza una convenzione di denominazione generica. Non fate riferimento a nessuna istanza DB del cluster come «writer», perché istanze DB diverse assumono quei ruoli in base alle esigenze. Consigliamo di utilizzare una denominazione di tipo clustername-az-serialnumber, ad esempio myprodappdb-a-01. Tali denominazioni identificano l'istanza database e il suo posizionamento.

• Imposta una conservazione elevata del backup per il cluster Aurora. Con un periodo di conservazione lungo, puoi eseguire point-in-time recovery (PITR) per un periodo fino a 35 giorni. È possibile ripristinare lo stato noto del database dopo aver eseguito test che coinvolgono DDL le istruzioni Data Manipulation Language (DML). Inoltre, puoi eseguire il ripristino in caso di eliminazione o modifica involontaria dei dati.

• Abilita ulteriori funzionalità di ripristino, registrazione e monitoraggio delle funzioni al momento della creazione del cluster. Attiva tutte le opzioni disponibili in Backtrack, Performance Insights, Monitoring e Log exports. L'attivazione di queste funzionalità consente di testare l'idoneità di funzionalità come backtracking, Enhanced Monitoring (Monitoraggio avanzato) o Performance Insights per il carico di lavoro in uso. Inoltre, puoi eseguire facilmente l'analisi delle prestazioni e la risoluzione dei problemi durante il proof of concept.

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 stai passando da un altro sistema di database SQL SQL compatibile con My o Postgre, aspettati che questa fase sia semplice e diretta. Utilizzate la stessa SQL sintassi e la stessa riga di comando o altre applicazioni client che conoscete per il vostro motore di database.

Per emettere SQL istruzioni sul tuo 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 corrispondere alla SQL sintassi e alle funzionalità 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 stai migrando da un sistema di database con un motore sottostante diverso da quello di Aurora, prendi in considerazione 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 dettagli generali sulle attività di migrazione e porting, consulta il white paper Migrating Your Databases to Amazon AWS 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. Una volta completata la dimostrazione concettuale, dovresti testare ETL gli strumenti, le query e il carico di lavoro complessivo con un set di dati sufficientemente grande da trarre conclusioni accurate.

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

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

Se stai migrando da un sistema SQL compatibile con My ad Aurora MySQL, puoi utilizzare gli strumenti di trasferimento dati nativi. Lo stesso vale se stai migrando da un SQL sistema compatibile con Postgre ad Aurora Postgre. SQL Se stai migrando da un sistema di database che utilizza un motore sottostante diverso da Aurora, puoi sperimentare con AWS Database Migration Service ().AWS DMS Per ulteriori informazioni AWS DMS, consulta la Guida per l'AWS Database Migration Service utente.

Per i dettagli sulle attività di migrazione e porting, consulta il AWS white paper Aurora migration handbook.

7. Trasferisci il tuo codice SQL

Provare SQL le applicazioni associate richiede diversi livelli di impegno a seconda dei diversi casi. In particolare, il livello di impegno dipende dal fatto che si passi da un sistema SQL SQL compatibile con My o Postgre o da un altro tipo.

• Se stai passando da RDS for My SQL o RDS PostgreSQL, le SQL modifiche sono abbastanza piccole da poter provare il SQL codice originale con Aurora e incorporare manualmente le modifiche necessarie.

• Allo stesso modo, se passi da un database locale compatibile con My SQL o PostgreSQL, puoi provare il codice originale SQL e incorporare manualmente le modifiche.

• Se provieni da un database commerciale diverso, le SQL modifiche richieste sono più ampie. In questo caso, prendi in considerazione l'utilizzo di AWS SCT.

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. Dedica tempo alla proof-of-concept pianificazione per apportare miglioramenti alla 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 i dettagli sulle attività di migrazione e porting, consulta il AWS white paper Aurora migration handbook.

8. Specificare le impostazioni di configurazione

È inoltre possibile esaminare i parametri di configurazione del database come parte dell'esercizio Aurora proof-of-concept . È possibile che le impostazioni di SQL configurazione di My SQL o Postgre siano già state ottimizzate per garantire prestazioni e scalabilità nell'ambiente corrente. 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à. Se sei interessato, puoi approfondire questo argomento in Introduzione al motore di archiviazione Aurora sul blog del AWS database.

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 Aurora I miei SQL parametri di configurazione 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. Ogni connessione di lettura viene assegnata a un'istanza DB diversa utilizzando una risoluzione DNS round-robin. L'esecuzione della maggior parte del lavoro di interrogazione su DB Aurora Replicas di sola lettura riduce il carico sull'istanza principale, liberandola di gestione e istruzioni. DDL 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.

Nota

Inoltre Aurora consente di creare endpoint personalizzati. Questi endpoint non sono generalmente necessari durante un proof of concept.

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 una forte coerenza di lettura (coerenza). read-after-write 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:

• Evita di utilizzare un'unica stringa di connessione hardcoded per tutte le sessioni di database.

• Se possibile, includi operazioni di scrittura come DDL e DML istruzioni nelle funzioni nel codice dell'applicazione client. In questo modo, diversi tipi di applicazioni possono utilizzare connessioni specifiche.

• Creare funzioni separate per le operazioni di query. Aurora assegna ciascuna nuova connessione all'endpoint di lettura a una replica Aurora diversa per bilanciare il carico per applicazioni con attività di lettura intensiva.

• Per le operazioni che implicano set di query, chiudi e riapri la connessione all'endpoint di lettura quando ciascun set di query correlate è terminato. Utilizza il pooling della connessione se tale funzionalità è disponibile nello stack del software. L'indirizzamento di query a diverse connessioni aiuta Aurora a distribuire il carico di lavoro di lettura tra le istanze database nel cluster.

Per informazioni generali sulla gestione della connessione e sugli endpoint per Aurora, consulta Connessione a un cluster database Amazon Aurora. Per un approfondimento su questo argomento, consulta Aurora My SQL database administrator's handbook — Connection management.

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 sempre di prendere decisioni sulle prestazioni utilizzando test e carichi di lavoro reali anziché benchmark sintetici come sysbench o -C. TPC Ovunque sia possibile, raccogliete le misurazioni in base al vostro 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, in genere esegui il codice dell'applicazione su EC2 istanze Amazon nella stessa AWS regione e sullo stesso cloud privato virtuale (VPC) del cluster Aurora. Se la tua applicazione di produzione viene eseguita su più EC2 istanze che si estendono su più zone di disponibilità, configura l' proof-of-concept ambiente nello stesso modo. Per ulteriori informazioni sulle AWS regioni, consulta Regioni e zone di disponibilità nella Amazon RDS User Guide. Per ulteriori informazioni sul VPC servizio Amazon, consulta What is AmazonVPC? nella Amazon VPC User Guide.

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 classi di AWS istanze diverse, numeri di AWS repliche 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. Visualizza le metriche del servizio di CloudWatch monitoraggio Amazon 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:

• Quante query al secondo elabora Aurora? Puoi esaminare i parametri Throughput per visualizzare i dati per diversi tipi di operazioni.

• Quanto tempo impiega in media Aurora per elaborare una determinata query? Puoi esaminare i parametri Latency (Latenza) per visualizzare i dati per diversi tipi di operazioni.

Per visualizzare i parametri di throughput e latenza, controlla la scheda Monitoraggio per un determinato cluster Aurora nella console Amazon. RDS La schermata seguente mostra un esempio delle metriche Select Latency, Latency, DML Select Throughput e Throughput nella scheda Monitoraggio. DML

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. A tale scopo, monitora le metriche secondarie per il server DB (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.

Suggerimento

Per rilevare i valori delle metriche che non rientrano negli intervalli previsti, imposta gli allarmi CloudWatch .

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 un'istanza di dimensioni CPU e capacità di memoria simili a quelle dell'ambiente di produzione corrente. 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.

Suggerimento

Dimensiona i cluster Aurora e le istanze database correlate con abbastanza capacità esistente per gestire picchi di traffico improvvisi e imprevedibili. Per i database mission-critical, lasciate almeno il 20% di spazio libero CPU e di memoria.

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 point-in-time ripristino e la possibilità di aggiungere istanze DB 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.

Suggerimento

Per una dimostrazione del concetto, configura tutte le istanze DB in un cluster Aurora con la AWS stessa classe di istanza. In questo modo è possibile provare la funzionalità di disponibilità di Aurora senza importanti modifiche alle prestazioni e alla scalabilità quando porti le istanze database offline per simulare gli errori.

Consigliamo di utilizzare almeno due istanze in ciascun cluster Aurora. Le istanze DB in un cluster Aurora possono estendersi su un massimo di tre zone di disponibilità (). AZs 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 DB in tutta la tua regione. AZs 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 gestisci un cluster con più di tre istanze, distribuisci le istanze DB nel modo più uniforme possibile su tutte e tre. AZs

Suggerimento

Lo storage di un cluster Aurora è indipendente dalle istanze database. Lo storage per ogni cluster Aurora si estende sempre su tre. AZs

Quando testi le funzionalità di disponibilità elevata, utilizza sempre istanze database con capacità identica nel cluster del test. Ciò permette di evitare cambiamenti imprevisti di prestazioni, latenza e così via quando un'istanza database prende il posto di un'altra.

Per capire come simulare condizioni di errore per testare le funzionalità di disponibilità elevata, consulta Test di Amazon Aurora My SQL using Fault Injection.

Come parte dell' proof-of-concept esercizio, uno degli obiettivi è quello di trovare il numero ideale di istanze DB e la classe di istanze ottimale per tali istanze DB. 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 OLTP le applicazioni che richiedono un uso intensivo di scrittura, è preferibile disporre di un numero inferiore di istanze DB di grandi dimensioni piuttosto che di molte istanze DB di piccole dimensioni.

In un tipico cluster Aurora, un'istanza DB (l'istanza principale) gestisce tutte le istruzioni DDL andDML. 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.

Sfrutta le funzionalità di ripristino dei dati di Aurora, come il point-in-time ripristino automatico, le istantanee e il ripristino manuali e il backtracking del cluster. Se necessario, copia le istantanee in altre AWS regioni e ripristinale in altre AWS regioni per simulare gli scenari di DR.

Analizza i requisiti della tua organizzazione per quanto riguarda l'obiettivo del tempo di ripristino (RTO), l'obiettivo del punto di ripristino (RPO) e la ridondanza geografica. La maggior parte delle organizzazioni raggruppa questi elementi nell'ampia categoria del disaster recovery. Valuta le funzionalità di alta disponibilità di Aurora descritte in questa sezione nel contesto del processo di disaster recovery per assicurarti che RTO i tuoi RPO requisiti siano soddisfatti.

13. Cosa fare in seguito

Al termine di un proof-of-concept processo di successo, confermi che Aurora è la soluzione adatta a te in base al 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 altri passaggi potrebbero essere inclusi o meno nel processo. proof-of-concept Per i dettagli sulle attività di migrazione e porting, consulta il AWS white paper Aurora migration handbook.

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 AWS servizi e funzionalità come l'autenticazione and (). AWS Secrets Manager 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 scalabilità per Amazon Aurora Postgre SQL e Monitoraggio del carico del 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 parallele Aurora per applicazioni ibride di transazione/elaborazione analitica (). HTAP 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 apprendere queste tecniche, consulta il AWS white paper Aurora SQL My database administrator's handbook — Connection management.

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

• Per i casi d'uso puramente analitici, i carichi di lavoro traggono vantaggio da un formato di archiviazione colonnare e da altre funzionalità più adatte ai carichi di lavoro. OLAP AWS i servizi che si occupano di tali casi d'uso includono quanto segue:

  • Amazon Redshift

  • Amazon EMR

  • Amazon Athena

• Molti carichi di lavoro traggono vantaggio da una combinazione di Aurora con uno o più di questi servizi. Puoi spostare i dati tra questi servizi utilizzando quanto segue:

  • AWS Glue

  • AWS DMS

  • Importazione da Amazon S3, come descritto nella Guida per l'utente di Amazon Aurora

  • Esportazione verso Amazon S3, come descritto nella Guida per l'utente di Amazon Aurora

  • Molti altri ETL strumenti popolari