Gestione dei carichi di lavoro di produzione su database ospitati

Fornito da Servizi Web Amazon

AWS offre più opzioni per ospitare i tuoi database che servono carichi di lavoro OLTP: ospita il tuo database gestito Amazon EC2 istanze o uso Amazon RDS gestito da AWS. RDS gestisce l'alta disponibilità, i backup automatici, gli aggiornamenti del database, le patch del sistema operativo, la sicurezza e la replica di lettura. RDS offre anche l'opzione nativa per il cloud Amazzonia-Aurora motore di database, compatibile con MySQL e PostgreSQL. Aurora offre un throughput maggiore rispetto ai database MySQL e PostgreSQL standard.

Durante l'esecuzione di carichi di lavoro di produzione su database ospitati con Amazon RDS o Amazon EC2, potresti aver riscontrato le seguenti domande:

• Quali sono le migliori opzioni per il tipo di archiviazione del database?
• Come risolvere i problemi di prestazioni di archiviazione?
• Quali sono le opzioni di configurazione RAID per i database ospitati da istanze EC2?
• Quali sono le modifiche dell'applicazione per prestazioni ottimali?
• Come risolvere i problemi relativi alle prestazioni di archiviazione utilizzando Amazon Cloud Watch ?
• Prestazioni operative di Amazon RDS e Aurora?

In questo post, fornisco le migliori pratiche di storage per l'esecuzione di carichi di lavoro di produzione su Amazon RDS o database ospitati da istanze EC2.

Rispetto agli ambienti di test, QA o staging, i carichi di lavoro di produzione richiedono prestazioni I/O veloci e coerenti. Sebbene i database relazionali possano essere utilizzati per molteplici scopi, il loro caso d'uso più comune consiste nell'ospitare un carico di lavoro OLTP (Online Transaction Processing). RDS, database ospitati EC2 e Aurora utilizzano diversi tipi di tecniche di archiviazione come mostrato di seguito:

• Le istanze del database Amazon RDS utilizzano Amazon EBS volumi per la conservazione.
• Le istanze Aurora utilizzano volumi di storage proprietari di AWS.
• Le istanze EC2 abilitano una varietà di opzioni per l'archiviazione.

Le migliori opzioni per il tipo di archiviazione del database

Amazon RDS fornisce tre tipi di archiviazione :

• SSD per uso generico (noto anche come volumi gp2 )
• SSD IOPS con provisioning (noto anche come io1 )
• Magnetico

La capacità di I/O dell'istanza si basa sul tipo e sulle dimensioni di storage dell'istanza. Se l'istanza database è configurata con un volume gp2, la capacità IOPS di base è 3 volte lo storage GiB. Se l'istanza database ha allocato un volume gp2 da 100 GiB, la capacità IOPS di base è 300. Maggiore è lo spazio di archiviazione di cui esegui il provisioning, maggiore è la capacità IOPS.

Oltre alla capacità IOPS di base, i volumi gp2 offrono anche una capacità burst fino a 3.000 IOPS per lunghi periodi di tempo. La funzione burst è limitata a volumi uguali o inferiori a 1 TiB di storage. Le istanze database per MySQL, MariaDB, Oracle e PostgreSQL possono essere configurate con 20 GiB–32 TiB, ma l'IOPS di base massimo è limitato da 100 a 16.000 IOPS. Quindi, un volume gp2 di 5,34 TiB o più fornisce la stessa linea di base: 16.000 IOPS.

Se il carico di lavoro di produzione richiede un OLTP elevato e prestazioni di throughput veloci e costantemente elevate, è necessario configurare l'istanza database con volumi io1. Rispetto ai volumi gp2, che offrono una linea di base massima di 16.000 IOPS, i volumi io1 possono fornire fino a 40.000 IOPS per istanze database per MySQL, MariaDB, Oracle e PostgreSQL e fino a 32.000 per istanze SQL Server.

Se trovi che il modello di utilizzo degli IOPS va costantemente oltre i 16.000, dovresti modificare il DB istanza e cambia il tipo di archiviazione da gp2 a io1. Amazon RDS offre anche storage magnetico, ma non è adatto per un carico di lavoro OLTP che richiede prestazioni I/O coerenti e bassa latenza.

Il tipo di archiviazione magnetica non è consigliato per carichi di lavoro ad alta intensità di I/O perché lo spazio di archiviazione massimo è inferiore a quello di gp2 o io1. Anche la capacità IOPS è limitata a un massimo di 1.000 IOPS.

Problemi di prestazioni di archiviazione

L'uso dello storage gp2 è l'ideale per un'ampia varietà di carichi di lavoro DB. Per questo tipo di archiviazione, l'architettura dei carichi di lavoro di lettura e scrittura del database in modo tale che la somma di Leggi IOPS e Scrivi IOPS i valori non superano la capacità IOPS di base in un dato momento.

La capacità di burst potrebbe essere disponibile per un periodo di tempo prolungato. Tuttavia, dopo l'utilizzo della capacità burst, un valore elevato e costante di IOPS in lettura e scrittura riduce le prestazioni dell'istanza. Questo degrado può essere visto da un aumento WriteLatency o ReadLatency i valori. Idealmente, l'archiviazione gp2 è utile per la latenza di millisecondi a una cifra, ma l'uso eccessivo di IOPS può causare una latenza di > 10 ms.

Le immagini seguenti mostrano un aumento WriteLatency valori come WriteIOPS consuma costantemente 300 IOPS di base su un'istanza database Amazon RDS. In questo esempio, l'istanza Amazon RDS PostgreSQL è ospitata su un'istanza t2.small con un volume gp2 da 100 GiB.

L'immagine sopra mostra IOPS in scrittura che consumano costantemente 300 IOPS, che è la prestazione di base.

L'immagine sopra mostra la latenza di scrittura aumentata fino a 25 millisecondi a causa dell'uso eccessivo di IOPS.

Come best practice, assicurati che il tuo carico di lavoro non vada oltre la capacità IOPS dell'istanza. Alcuni dei modi per ridurre Leggi IOPS i valori sono:

• Utilizza una replica di lettura Amazon RDS.
• Usa una RAM maggiore.

Utilizzo di una replica di lettura Amazon RDS

Offerta di istanze database Amazon RDS per MySQL, MariaDB, Oracle e PostgreSQL Repliche di lettura RDS . Queste istanze sono istanze database separate sincronizzate con l'istanza database di origine riproducendo i log delle transazioni del database. Qualsiasi modifica dei dati sull'istanza database di origine viene applicata alla replica di lettura. Con una replica di lettura, riduci il carico sull'istanza database di origine instradando le query di lettura dalle tue applicazioni alla replica di lettura. Stai anche liberando capacità IOPS per attività di scrittura aggiuntive nell'istanza database di origine.

Con le repliche di lettura, è importante monitorare il ritardo di replica. In genere, un ritardo di replica elevato è causato da un'attività di scrittura elevata nell'istanza database di origine.

Nelle istanze database Amazon RDS, puoi monitorare il ritardo di replica in base al parametro CloudWatch ReplicaLag . Se trovi un ritardo di replica elevato, dovresti anche monitorare l'attività di scrittura nell'istanza database di origine. Questo può essere ottenuto monitorando i parametri CloudWatch Scrivi IOPS e Scrivi Throughput . Se l'istanza database di origine è carente di IOPS (ovvero, tutta la capacità IOPS viene utilizzata dal carico di lavoro di scrittura e lettura), anche la replica continua a essere in ritardo.

Uno dei motivi alla base delle repliche in ritardo è che nella maggior parte dei motori DB il ripristino delle repliche di lettura coinvolge processi single-tread. Ciò significa che maggiore è il carico su un'istanza master, il ripristino esponenzialmente più lento alle repliche di lettura. Qualsiasi ulteriore attività di scrittura elevata nell'istanza database di origine aumenta esponenzialmente il ritardo della replica di lettura. Oltre ai parametri CloudWatch, con ReplicaLag puoi anche monitorare il ritardo tramite query SQL.

In PostgreSQL, il ritardo della replica di lettura può essere calcolato utilizzando la query seguente:

|_+_|

In MySQL, puoi controllare lo stato della replica con il seguente comando:

|_+_|

Con una replica di lettura Amazon RDS, configura il client in modo tale che un determinato livello di latenza o errore di replica rilevato in una replica attivi il tentativo di connessione con un altro endpoint di replica.

Un buon modo per assicurarti che la tua applicazione possa trovare la replica più sana è chiamare i parametri CloudWatch per trovare i valori correnti di ReplicaLag e latenza di lettura/scrittura. Il ritardo di replica può essere trovato con i comandi SQL, come mostrato negli esempi precedenti. Puoi anche trovare lo stato corrente della replica chiamando il file Interfaccia della riga di comando di AWS (AWS CLI) comando describe-db-instances. Se lo stato corrente della replica è diverso dalla replica, il client dovrebbe provare a connettersi a un'altra replica.

Oltre al vantaggio della distribuzione delle transazioni di lettura, le repliche di lettura possono essere utilizzate anche per eseguire lo shard dei dati. Seguendo l'architettura share-nothing degli shard, puoi creare repliche di lettura corrispondenti a ciascuno dei tuoi shard e promuoverli quando decidi di convertirli in shard autonomi.

Utilizzo di una RAM maggiore

Le istanze database Amazon RDS devono disporre di RAM sufficiente in modo che l'intero set di lavoro risieda in memoria. Poiché le query di lettura possono leggere i dati dalla memoria, riduce la comunicazione con i volumi di archiviazione. In quanto tale, riduce l'utilizzo di Leggi IOPS capacità che può essere utilizzata per scopi di scrittura.

Non esiste un modo semplice per trovare le dimensioni di un set di dati funzionante. Guarda le query di lettura e scopri quanti dati vengono colpiti. Ad esempio, se la dimensione di un database è 100 GiB e il working set è 20 GiB, dovresti usare un Istanza database Amazon RDS con almeno 20 GiB di memoria. Ciò consente di avere in memoria il working set completo.

Opzioni di configurazione RAID per i database ospitati da istanze EC2

I volumi EBS sono volumi di storage a livello di blocco che forniscono storage a blocchi persistente. Questi volumi sono volumi di storage a disponibilità elevata e possono essere collegati a un'istanza EC2 nella stessa zona di disponibilità. I volumi EBS sono ideali per i database ospitati da istanze EC2. Non è consigliabile utilizzare l'archiviazione temporanea dell'istanza EC2 per un database.

Utilizzando i volumi di storage EBS con le istanze EC2, puoi configurare i volumi con qualsiasi livello RAID. Ad esempio, per prestazioni I/O migliori, puoi optare per RAID 0, che può eseguire lo striping di più volumi insieme. RAID 1 può essere utilizzato per la ridondanza dei dati perché esegue il mirroring di due volumi insieme.

Indipendentemente dalla configurazione RAID, i dati del volume EBS vengono replicati su server secondari per evitare qualsiasi perdita di dati. RAID 5 e RAID 6 non sono consigliati sui database ospitati da istanze EC2 perché le prestazioni di I/O non sono buone come RAID 0 o RAID 1.

La tabella seguente mostra i vantaggi e gli svantaggi dell'utilizzo di queste due diverse configurazioni RAID e suggerisce possibili casi d'uso.

Configurazione	Vantaggi	Svantaggi	Caso d'uso
RAID 0	Prestazioni I/O superiori rispetto alla tolleranza agli errori	La perdita di un singolo volume provoca la perdita completa dei dati	Se il database richiede una velocità effettiva maggiore rispetto alla disponibilità dei dati e i dati sono riproducibili
RAID 1	La tolleranza ai guasti è superiore rispetto alle prestazioni I/O	Prestazioni di scrittura basse	Se i dati sono critici e la tolleranza agli errori del database è più importante delle prestazioni di I/O

Modifiche all'applicazione per prestazioni ottimali

Se un'istanza di database deve affrontare problemi di archiviazione e problemi come tempi di commit elevati e latenze elevate, a volte le modifiche nell'applicazione possono mitigare questo degrado. È possibile modificare le applicazioni per abilitare il backoff esponenziale o i tentativi di errore.

Il backoff esponenziale consente alle applicazioni attese progressivamente più lunghe tra i tentativi per risposte di errore consecutive. Mentre alcuni algoritmi utilizzano un ritardo incrementale, la maggior parte degli algoritmi di backoff esponenziale utilizza un ritardo randomizzato. Ecco alcuni esempi per un algoritmo diverso:

Ritardo casuale:

1. L'applicazione avvia la richiesta.
2. Se la richiesta non riesce, attendere rand(1000.3000) millisecondi e avviare nuovamente la richiesta.
3. Se la richiesta non riesce, attendere rand(1000.3000) millisecondi e avviare nuovamente la richiesta.
4. Se la richiesta non riesce, attendere rand(1000.3000) millisecondi e avviare nuovamente la richiesta.

Ritardo incrementale:

1. L'applicazione avvia la richiesta.
2. Se la richiesta non riesce, attendere 1 = 1000 millisecondi e avviare nuovamente la richiesta.
3. Se la richiesta non riesce, attendere 2 = attendere 1 + 1000 millisecondi e avviare nuovamente la richiesta.
4. Se la richiesta non riesce, attendere 3 = attendere 2 + 1000 millisecondi e avviare nuovamente la richiesta.

Utilizza determinate best practice per ottenere un failover più rapido nelle istanze Amazon RDS Multi-AZ e nei cluster Aurora. Abilita i parametri keepalive TCP e impostali in modo aggressivo per garantire che se il tuo client non è più in grado di connettersi all'istanza database, tutte le connessioni attive vengano chiuse rapidamente. Questa modifica consente inoltre alle applicazioni di reagire più rapidamente al failover e di connettersi rapidamente al nuovo endpoint.

Puoi anche ridurre il timeout della cache DNS sul client. Le connessioni di lettura e scrittura vengono stabilite rapidamente agli endpoint appropriati. È anche possibile modificare alcuni dei parametri di impostazione TCP del server. Queste modifiche consentono un failover più rapido. Ad esempio, in PostgreSQL, questo può essere controllato da tcp_keepalives_count, tcp_keepalives_idle e tcp_keepalives_interval parametri .

Risoluzione dei problemi delle prestazioni di archiviazione utilizzando CloudWatch

Il monitoraggio regolare dell'integrità dell'archiviazione delle istanze identifica l'insorgenza precoce di un problema di prestazioni prima che abbia un grave effetto sulle prestazioni del database. Alcuni dei parametri di archiviazione relativi a CloudWatch che dovresti monitorare regolarmente sono elencati qui.

Scrivere operazioni

• Scrivi IOPS: Misurato a una frequenza di conteggi/secondo, questo parametro CloudWatch determina il numero medio di operazioni di I/O di scrittura su disco al secondo. Concentrati su questa metrica se l'istanza del database è configurata con un'impostazione Multi-AZ.
  Utilizzando Multi-AZ, viene creata un'istanza secondaria in un'altra zona di disponibilità con la stessa configurazione dell'istanza del master e del volume di storage EBS collegato. Questo spazio di archiviazione viene sincronizzato in modo sincrono con lo spazio di archiviazione dell'istanza master. Per la ridondanza dei dati, per impostazione predefinita, i dati in ciascun volume EBS vengono copiati in un altro volume EBS secondario situato nella stessa zona di disponibilità. Ciò significa che una transazione di scrittura deve eseguire il commit in quattro posizioni prima di inviare un riconoscimento al client. L'attività di scrittura massiccia al di sopra degli IOPS e della capacità di throughput delle istanze peggiora le prestazioni complessive.
• Scrittura Throughput: Questo parametro CloudWatch rappresenta il numero medio di byte scritti su disco al secondo. Il superamento della velocità effettiva dell'istanza o del limite della velocità effettiva di archiviazione danneggia le prestazioni dell'istanza. Suggerisco di monitorare l'attività di scrittura e di distribuire il carico di lavoro di scrittura con un ritardo appropriato per ottimizzare le prestazioni.
• Latenza di scrittura: Questa è la quantità di tempo media impiegata per l'operazione di I/O del disco. La maggior parte delle volte WriteLatency gli aumenti sono dovuti all'uso eccessivo delle risorse dell'istanza, come CPU, IOPS e throughput.

Leggi le operazioni

• Leggi IOPS: Misurato a una frequenza di conteggi/secondo, questo parametro CloudWatch determina il numero medio di operazioni di I/O di lettura del disco al secondo. L'aumento del valore di Leggi IOPS suggerisce che il carico di lavoro di lettura è elevato o che l'istanza richiede più memoria libera.
• Read Throughput: Questa metrica rappresenta il numero medio di byte letti dal disco al secondo. Superare l'istanza e i limiti EBS può aumentare la latenza.
• Latenza di lettura: Questa è la quantità di tempo media impiegata per l'operazione di I/O del disco. Se disponi di un valore elevato per questa metrica, esamina il carico di lavoro di lettura e assicurati che non stia abusando delle risorse dell'istanza.

Altre metriche

Oltre ai parametri menzionati in precedenza, dovresti monitorare anche i seguenti parametri CloudWatch:

• DiskQueueDepth rappresenta il numero di I/O in sospeso (richieste di lettura/scrittura) in attesa di accedere al disco. In genere, questo è il risultato di un carico di lavoro elevato.
• Spazio di archiviazione gratuito determina la quantità di spazio di archiviazione disponibile. Come best practice, dovresti impostare Avvisi CloudWatch in modo da poter ricevere notifiche SNS non appena lo spazio di archiviazione gratuito dell'istanza scende al di sotto di un valore di soglia, ad esempio il 15%.

Prestazioni operative di Amazon RDS e Aurora

Come accennato in precedenza, le istanze database Amazon RDS e le istanze EC2 hanno una dipendenza IOPS dai volumi di storage. I tipi di archiviazione gp2 e io1 hanno i propri limiti IOPS.

Se il tuo carico di lavoro richiede prestazioni IOPS più elevate e un throughput più elevato, puoi pianificare la migrazione ad Aurora, che è una soluzione ad alte prestazioni, altamente disponibile ed economica, adatta per carichi di lavoro ad alto throughput. Attualmente, Alba offre motori compatibili con MySQL e PostgreSQL.

Durante l'utilizzo di Aurora, assicurati che tecnicamente non vi siano limiti di IOPS, ma il throughput potrebbe essere limitato al sottostante Istanza Aurora limite. Per una migliore velocità effettiva, scegli una classe di istanza Aurora superiore.

Aurora è più adatto per applicazioni che richiedono una latenza minima o nulla per un determinato IOPS. È progettato per gestire un'elevata velocità di dati fornendo un throughput maggiore rispetto ai tradizionali motori MySQL e PostgreSQL. Essendo un database di archivio di righe, è ideale per carichi di lavoro OLTP ad alto volume e simultanei.

Un altro caso d'uso di Aurora è l'elaborazione analitica delle transazioni ibride (HTAP). Aurora supporta fino a 15 repliche. Ognuna di queste repliche viene eseguita entro 15–20 millisecondi dall'istanza di scrittura. Con l'aggiunta di recente Funzionalità di query parallela di Amazon Aurora , l'elaborazione della query viene inviata successivamente allo storage Aurora. La query utilizza potenzialmente migliaia di nodi di archiviazione in un cluster Aurora per elaborare, perfezionare e aggregare i dati prima di inviarli al nodo di calcolo.

Conclusione

In questo post, hai appreso le migliori pratiche di storage per l'esecuzione di un carico di lavoro di produzione su un'istanza database Amazon RDS e su database ospitati da istanze EC2. Queste pratiche hanno comportato quanto segue:

• Allocazione dei carichi di lavoro di lettura a una replica di lettura.
• Comprendere la capacità IOPS e la sua dipendenza dalle dimensioni e dal tipo di storage.
• Modifica dell'architettura dell'applicazione.
• Esame delle opzioni RAID.
• Monitoraggio dei parametri CloudWatch.

Hai anche appreso di Aurora e di come il suo storage proprietario si comporta in modo diverso rispetto ai volumi EBS. Tutta questa conoscenza ti aiuta a eseguire un carico di lavoro di produzione senza problemi e senza problemi sui database AWS. Puoi anche esaminare i dettagli di come Aurora gestisce la velocità e la disponibilità del database utilizzando il livello di archiviazione in questo post sul blog del database: Presentazione dell'Aurora Storage Engine.

nascondere