Cosa significa IOPS (in Amazon EBS) nella pratica?

Question

Ho alcune immagini necessarie per un'applicazione. Ci sono molte immagini (50.000+) ma la dimensione complessiva è piccola (40 Mb). Inizialmente, pensavo che avrei semplicemente usato S3 ma è dolorosamente lento da caricare. Come soluzione temporanea, volevo collegare un EBS contenente le immagini e andrebbe bene. Tuttavia, leggendo un po 'su EBS General Purpose (gp2) ho notato la seguente descrizione:

GP2 è il tipo di volume EBS predefinito per istanze Amazon EC2. Questi volumi sono supportati da unità a stato solido (SSD) e sono adatti per un ampio intervallo di carichi di lavoro transazionali , inclusi ambienti di sviluppo/test , applicazioni interattive a bassa latenza e volumi di avvio. GP2 è progettato per offrire latenze di un millisecondo a una cifra, fornire una prestazione di base costante di 3 IOPS/GB a un massimo di 10.000 IOPS e fornire fino a 160 MB/s di throughput per volume.

È la quantità di 3 IOPS/GB che mi preoccupa. Cosa significa in termini pratici? Supponiamo che sia necessario un sito di e-commerce per una piccola quantità di utenti (ad esempio < 10.000 richieste al minuto) e che queste immagini debbano essere recuperate. Amazon describes come IOPS sono misurati:

Quando piccole operazioni di I/O sono fisicamente contigue, Amazon EBS tentativi di unirli in un unico I/O fino alla dimensione massima. Nell'esempio , per i volumi SSD, una singola operazione I/O 1.024 KiB conta come 4 operazioni, mentre 256 operazioni I/O a 4 KiB ciascuna contano come 256 operazioni.

Questo significa in realtà che se voglio recuperare 50 immagini di 10kB ciascuna in meno di un secondo, richiedere 50 IOPS e superare facilmente la linea di base di 3 IOPS?

UPDATE:

Grazie al suggerimento di Mark B, sono stato in grado di utilizzare S3 per caricare i miei file. Tuttavia, mi sto ancora chiedendo la quantità di IOPS necessari per eseguire attività comuni come l'esecuzione di un database o la pubblicazione di altri file per un'applicazione web. Sarei lieto di ascoltare alcuni valori di riferimento relativi ai valori minimi di IOPS in base alla tua esperienza.

Answer 1

Ti manca la parte "/GB" di tale istruzione. La linea di base è 3 IOPS per GB. Se il tuo volume EBS è 100GB, allora avresti una baseline di 300 IOPS. Per un volume EBS GP2 è necessario moltiplicare le dimensioni del volume per 3 per ottenere IOPS.

Si noti che qualsiasi volume GP2 inferiore a 1 TB è in grado anche di scoppiare fino a 3.000 IOPS, quindi eventuali aumenti limitati dell'IO dovrebbero comunque funzionare molto bene.

---

Inoltre, aggiungerò che S3 suona come una soluzione migliore per il tuo caso d'uso. Se vedi velocità di caricamento lente su S3, è un problema che può essere risolto. È possibile utilizzare CloudFront per fornire una posizione periferica vicina a cui è possibile caricare.

In base alla mia esperienza, i caricamenti su S3 non sono mai più lenti dei caricamenti su un'istanza EC2 a cui sarà collegato il volume EBS.

---

Aggiornamento:

Per rispondere alla tua domanda aggiuntiva, le IOPS minimi necessari dipenderà da molte variabili, come la quantità di RAM disponibile, il tipo di applicazione in esecuzione, quanto bene l'applicazione memorizza nella cache i valori in memoria, la dimensione media delle operazioni di I/O, ecc. È molto difficile definire un numero esatto e indicare che è necessario esattamente X IOPS per un'applicazione.

È inoltre necessario ricordare che qualsiasi volume con dimensioni inferiori a 1 TB può ancora scoppiare fino a 3.000 IOP per diversi secondi. Pertanto, anche se l'applicazione richiede un IOPS elevato quando è in uso, se non rileva un utilizzo eccessivo, la funzione di burst IOPS potrebbe essere l'unica cosa di cui abbia bisogno.

In generale, di solito inizio con qualcosa come un volume da 100 GB con 300 IOPS e testare le prestazioni della mia app contro questo. Un server web che opera interamente nella RAM potrebbe non aver bisogno di più di questo. Per qualcosa come un database, probabilmente inizierai con la quantità di spazio su disco che pensi di aver bisogno e poi avvii il test delle prestazioni. CloudWatch mostrerà la quantità di IOPS utilizzata dalla tua applicazione e, se la vedi al massimo del volume, saprai che è necessario aumentare gli IOPS disponibili. Risciacquare e ripetere fino a quando non si raggiunge la massima lunghezza degli IOPS disponibili durante i test delle prestazioni.

Answer 2

La risposta di @Mark B è probabilmente corretta, in quanto indica che gli IOP sono basati sulla dimensione del volume EBS. Per quello che vuoi, S3 è l'opzione migliore.

Tuttavia, a seconda dei casi e dei requisiti di utilizzo, potrebbe essere necessario EBS. Questo è particolarmente vero se si vuole eseguire un database. In tal caso, hai un paio di opzioni.

È possibile ottenere IOPS Provisioning: se si sa che sono necessari 5000 IOPS, ma è necessario solo dire 100 GB di spazio di archiviazione (che con gp2 normalmente fornirà circa 300 IOPS), è possibile utilizzare i volumi io1. C'è un costo aggiuntivo per questo, e vorrete assicurarvi che sia collegato a un'istanza ottimizzata EBS, ma se necessario è possibile ottenere fino a 20k di IOPS.

Se stai facendo un sacco di letture sequenziali (lettura in un grande set di dati?), Allora c'è un nuovo tipo di EBS, st1. Questo è buono per 500 MB/s, ed è inferiore al 1/2 del costo di gp2.

Infine, c'è un altro scenario che potresti considerare (ad esempio, sei un po 'pazzo e vuoi provare a fare cose strane). Se riesci a prendere un archivio da qualche parte, e tutto quello che ti interessa è servirlo da un file system molto veloce, potresti metterli su un'istanza che ha una memoria di istanza. Questo è un SSD collegato localmente, quindi è molto veloce. L'unico inconveniente è che quando l'istanza si interrompe, i dati sono spariti.

Per indirizzare l'aggiornamento, "quanti IOPS sono necessari per un database", la risposta è "dipende". Ogni motore di database ha requisiti diversi e ogni utilizzo di database ha modelli di utilizzo diversi. Dai uno sguardo allo this se vuoi maggiori informazioni. Ma fondamentalmente, prova il monitor &. Se sei preoccupato, prevedi un rifornimento al momento del lancio e riduci se necessario. Oppure, immagina e aumenta se ti imbatti in problemi: è più importante ridurre al minimo i costi o fornire buone prestazioni ai tuoi utenti finali?