Questo articolo illustra le principali criticità e best practice per scegliere i volumi SSD più convenienti in RDS.
In RDS sono disponibili tre opzioni di storage SSD. Amazon RDS offre due tipologie di SSD General Purpose: gp2 e gp3. A queste si aggiunge l'SSD Provisioned IOPS io1. (Esiste anche il vecchio storage magnetico, troppo lento per la maggior parte delle applicazioni. Si noti che io2, disponibile in EBS, non è ancora supportato in RDS).
- gp2— Generazione precedente, gli IOPS dipendono dalla dimensione del volume, con possibilità di burst
- gp3— Generazione attuale, IOPS costanti, include IOPS di base con la possibilità di acquistare IOPS e throughput aggiuntivi
- io1— (Talvolta indicato come PIOPS). Prestazioni costanti, gli IOPS Provisioned vanno acquistati. È la soluzione più costosa.
Tutte e tre le tipologie di storage offrono latenze nell'ordine di pochi millisecondi.
In RDS il costo per GB è identico per gp2 e gp3 (a differenza di EC2, dove gp3 è più economico). Tuttavia, gp3 offre più IOPS di base (per volumi fino a 4.000 GB) senza i limiti del bursting.
Tabella comparativa dei prezzi
Il foglio di calcolo che segue mostra nel dettaglio prezzi e IOPS per un dato volume in gp2, gp3 e io1.
Confronto dei costi dei volumi SSD
Ecco alcuni esempi tratti dalla tabella:
Con un volume da 1.000 GB, su gp3 si ottengono 12.000 IOPS sostenuti. Su gp2 si ottengono gli stessi 12.000 IOPS, ma solo per burst limitati: gli IOPS sostenuti sono soltanto 3.000. Entrambi costano 115 $. Con io1 PIOPS configurato sugli stessi 12.000 IOPS, il costo sale a 425 $!
Per un volume da 5.000 GB, gp2 offre 15.000 IOPS a 525 $. Allo stesso prezzo, gp3 ne offre solo 12.000 (anche se è possibile pagare di più per averne di più). io1 PIOPS costerebbe molto di più: 2.125 $.
Striping del disco RDS
Tutti i motori RDS (ad eccezione di MS SQL Server) eseguono lo striping su 4 volumi oltre una determinata dimensione minima. Ciò significa che sia gp2 sia gp3 offrono IOPS e throughput superiori a quanto ci si aspetterebbe normalmente, come mostrato sopra.
Dettagli sullo striping:
- MariaDB, MySQL e PostgreSQL eseguono lo striping per dimensioni superiori a 400 GB
- Oracle esegue lo striping oltre i 200 GB
- Aumentare la dimensione di un volume esistente fino al punto da innescare lo striping (es. > 400 GB) può causare un incremento significativo di IOPS e latenza per diverse ore durante la modifica.
Per i dettagli su tipo e dimensione del DB, si consulti la documentazione AWS [3].
Quale tipo di storage scegliere?
Nella quasi totalità dei casi, la scelta di default dovrebbe ricadere su gp3. In passato, anche per esigenze di IOPS contenute, AWS raccomandava io1 per garantire una latenza bassa e costante. Oggi, però, sia io1 sia gp3 offrono latenze nell'ordine di pochi millisecondi. L'unica differenza è che io1 le garantisce nel 99,9% dei casi, mentre gp3 le garantisce "solo" nel 99,0% dei casi. Considerando che gp3 costa fino al 73% in meno rispetto a io1 (a parità di baseline configurata), la scelta è semplice.
Quando conviene usare io1:
- quando servono più di 64.000 IOPS
- quando servono prestazioni costanti garantite per oltre il 99,0% del tempo
Modifica del tipo di volume su un DB attivo:
- In genere il passaggio tra io1, gp2 e gp3 avviene senza downtime [2]
- Tuttavia, non è possibile effettuare più di una modifica ogni 6 ore
Insidie da considerare
- Superare i 400 GB innesca lo striping e consuma una quantità significativa di IOPS durante il processo, con possibili impatti seri sulla latenza. Per questo, se si prevede una crescita rapida, conviene partire direttamente da 400 GB. Oracle esegue lo striping a 200 GB, mentre MS SQL Server non lo esegue mai.
- L'autoscaling dello storage RDS può riservare diverse sorprese. È fondamentale conoscerne tutte le limitazioni [1]: ad esempio, potrebbe innescare lo striping in modo inatteso.
- AWS potrebbe fornirle più IOPS di quelli pagati sull'attuale volume gp2 (questo vale soprattutto per workloads attivi da diversi anni). Di conseguenza, passando a gp3 si rischia di perdere gli IOPS gratuiti e ottenere prestazioni peggiori. (Lo si può verificare in Cloudwatch, controllando se gli IOPS effettivi superano quelli previsti.)
- Limiti di IOPS per tipo di istanza: tutte le istanze RDS hanno limiti di banda e IOPS. Anche pagando per i PIOPS, l'istanza applicherà un throttling se non è sufficientemente grande. I limiti per ciascun tipo di istanza sono indicati nella documentazione AWS EC2 [4].
Esempio:
c6g.4xlarge limitata a 20.000 IOPS c7g.4xlarge limitata a 20.000 IOPS, con possibilità di burst fino a 40.000
In sintesi
Scelga con attenzione il tipo di storage per le sue istanze RDS. Optando per gp3 al posto di io1 si possono ottenere risparmi consistenti senza compromettere le prestazioni.
Riferimenti:
[1] Managing capacity automatically with Amazon RDS storage autoscaling [2] Modifying an Amazon RDS DB instance
[3] Amazon RDS DB instance storage — Amazon R DS
[4] Amazon EBS–optimized instances — Amazon Elastic Compute Cloud
Frequently asked
questions
Conviene utilizzare io1 + PIOPS?
- Solo se servono da 64.000 a 256.000 IOPS (oppure oltre 4.000 Mbps di throughput)
- Se serve una consistenza I/O del 99,9% rispetto al 99% di gp2 o gp3
- Costerà il 270% in più rispetto a gp2/gp3
- Anche se la console AWS mostra io1 come opzione predefinita (per alcuni template di configurazione), è possibile modificarla in gp3 (o in un'altra opzione).
Ha senso creare un nuovo DB RDS con gp2?
- Sì, se la dimensione del volume richiesta supera i 4.000 GB. In questo caso, gli IOPS di gp2 saranno superiori al baseline offerto da gp3 (vedere la tabella sopra). Se servono più IOPS del baseline di gp2, sarà più conveniente passare a gp3 e acquistare gli IOPS aggiuntivi.
Conviene convertire da io1 a gp3 (o gp2)?
- Sì! Se servono meno di 64.000 IOPS, conviene convertire per risparmiare fino al 73% (vedere la tabella).
Conviene convertire da gp2 a gp3?
Dipende:
- Se funziona, meglio non toccare nulla. Nessun risparmio sui costi e prestazioni che potrebbero peggiorare — vedere le insidie qui sopra.
- Se la dimensione del volume supera i 4.000 GB, gp3 fornirà meno IOPS (a meno di pagare per averne di più).
- Se il workload richiede più IOPS di quelli offerti da gp2, conviene passare a gp3 e pagare per gli IOPS aggiuntivi necessari.
- Avvertenza: come per qualsiasi modifica al DB, la best practice è clonare prima il DB e testare la conversione. Verifichi che gp3 fornisca effettivamente gli IOPS e il throughput attesi.