AWS RDS Provisioned IOPS en vaut-il vraiment la peine ?

Question

Si j'ai bien compris, les IOPS provisionnées par RDS sont assez chères par rapport au taux d'E/S standard.

Dans la région de Tokyo, le taux de P-IOPS est de 0,15$/GB, 0,12$/IOP pour un déploiement standard. ( Doublez le prix pour un déploiement Multi-AZ... )

Pour les P-IOPS, le stockage minimum requis est de 100GB, les IOP sont de 1000. Par conséquent, le coût de départ pour P-IOPS est de 135$, hors prix d'instance.

Dans mon cas, l'utilisation de P-IOPS coûte environ 100 fois plus cher que l'utilisation du taux d'E/S standard.

Il s'agit peut-être d'une question très subjective, mais veuillez donner votre avis.

Dans la base de données la plus optimisée pour les P-IOPS de RDS, les performances vaudraient-elles le prix ?

ou

El Site AWS donne un aperçu de la façon dont les P-IOPS peuvent améliorer les performances. Existe-t-il un benchmark réel ?

RÉPONSE AUTOMATIQUE

En plus de la réponse que zeroSkillz a écrite, j'ai fait quelques recherches supplémentaires. Cependant, veuillez noter que je ne suis pas un expert dans la lecture des benchmarks de base de données. De plus, le benchmark et la réponse étaient basés sur EBS.

Selon un article écrit par "Rodrigo Campos", les performances s'améliorent effectivement de manière significative.

De 1000 IOPS à 2000 IOPS, les performances de lecture/écriture (y compris la lecture/écriture aléatoire) doublent. D'après ce qu'a dit zeroSkillz, le bloc EBS standard fournit environ 100 IOPS. Imaginez l'amélioration des performances lorsque 100 IOPS passent à 1000 IOPS (qui est l'IOPS minimum pour un déploiement P-IOPS).

Conclusion

Selon le benchmark, le rapport performance/prix semble raisonnable. Pour les situations où les performances sont critiques, je pense que certaines personnes ou entreprises devraient choisir les P-IOPS même si elles doivent payer 100 fois plus.

Toutefois, si j'étais consultant financier dans une petite ou moyenne entreprise, je me contenterais d'augmenter progressivement la taille (en termes de CPU et de mémoire) de mes instances RDS jusqu'à ce que le rapport performance/prix corresponde aux P-IOPS.

Answer 1

Je viens de recevoir un appel d'un ingénieur système d'Amazon, qui m'a fait part d'observations intéressantes sur cette question. (c'est-à-dire que c'est une connaissance de seconde main).

Les blocs EBS standard peuvent bien gérer le trafic en rafale, mais il finira par se réduire à environ 100 iops. Cet ingénieur a suggéré plusieurs alternatives.

1. Certains clients utilisent plusieurs petits blocs EBS et les strippent. Cette méthode améliore les IOPS et est la plus rentable. Vous n'avez pas à vous soucier de la mise en miroir, car EBS est mis en miroir en arrière-plan.

2. certains clients utilisent le stockage éphémère sur l'instance EC2. (ou instance RDS) et ont plusieurs esclaves pour "assurer" la durabilité. Le stockage éphémère est un stockage local et beaucoup plus rapide que EBS. Vous pouvez même utiliser des instances EC2 provisionnées en SSD.

3. certains clients configureront le maître pour utiliser des IOPS provisionnés ou un stockage éphémère SSD, puis utiliseront un stockage EBS standard pour le ou les esclaves. Les performances attendues sont bonnes, mais les performances de basculement sont dégradées (mais toujours disponibles).

Quoi qu'il en soit, si vous décidez d'utiliser l'une de ces stratégies, je vérifierai de nouveau avec amazon pour m'assurer que je n'ai oublié aucune étape importante. Comme je l'ai déjà dit, ce sont des connaissances de seconde main.

Answer 2

Ok. C'est une mauvaise question car elle ne mentionne pas la taille du stockage alloué ou tout autre détail de la configuration. Nous utilisons RDS et il a ses avantages et ses inconvénients. Premièrement, vous ne pouvez pas utiliser un périphérique de stockage éphémère avec RDS. Vous ne pouvez même pas accéder directement au périphérique de stockage lorsque vous utilisez le service RDS.

Cela dit, le support de stockage de RDS est censé être basé sur une variante d'EBS d'Amazon. Les performances pour les IOPS standard dépendent de la taille du volume et de nombreuses sources indiquent qu'au-delà de 100 Go de stockage, on commence à "stripper" les volumes EBS. Cela permet un meilleur accès moyen aux données, tant en lecture qu'en écriture.

Nous utilisons actuellement environ 300 Go d'allocation de stockage et pouvons obtenir 2 000 IOP en écriture et 1 000 IOP environ 85 % du temps sur une période de plusieurs heures. Nous utilisons datadog pour enregistrer ces données afin de pouvoir les voir. Nous avons vu des rafales allant jusqu'à 4k IOP d'écriture, mais rien de durable comme cela.

Le principal symptôme que nous observons du côté de l'application est la contention du verrou si l'IOPS pour l'écriture n'est pas suffisante. Le nombre et la fréquence de ces conflits dans les journaux de votre application vous donneront les symptômes de l'épuisement des IOPS de RDS standard. Vous pouvez également utiliser un service comme datadog pour surveiller les IOPS.

Le problème avec les IOPS provisionnés est qu'ils supposent des volumes stables d'écritures/lectures afin d'être rentables. Ce n'est presque jamais un cas d'utilisation réaliste et c'est la raison pour laquelle Amazon a lancé les services de cloud computing. La seule assurance que vous obtenez avec les P-IOPS est que vous aurez une capacité de débit maximum réservée. Si vous ne l'utilisez pas, vous la payez quand même.

Si vous êtes d'accord pour exécuter des répliques, nous vous recommandons d'exécuter une réplique en lecture seule en tant qu'instance NON-RDS, et de la placer sur une instance EC2 normale. Vous pouvez obtenir de meilleurs IOPS en lecture à un prix beaucoup moins élevé en gérant vous-même la réplique. Nous avons même configuré des répliques en dehors d'AWS en utilisant stunnel et en mettant des disques SSD comme périphérique de bloc primaire et nous obtenons des vitesses de lecture ridicules pour nos systèmes de reporting - littéralement 100 fois plus rapides que celles obtenues avec RDS.

J'espère que cela vous aidera à donner quelques détails concrets. En bref, à mon avis - à moins que vous ne deviez garantir un certain niveau de capacité de débit (ou votre application échouera) sur une base constante (ou à n'importe quel moment), il existe de meilleures alternatives aux IOPS provisionnés, y compris le fractionnement de la lecture-écriture avec des memcache read-replicas, etc.