Les IOPS provisionnés AWS RDS en valent-ils vraiment la peine?
Si je comprends bien, les IOPS provisionnés RDS sont assez chers par rapport au taux d'E/S standard.
Dans la région de Tokyo, le taux P-IOPS est de 0,15 $/Go, 0,12 $/IOP pour le déploiement standard. ( Doublez le prix du déploiement Multi-AZ ... )
Pour P-IOPS, le stockage minimum requis est de 100 Go, IOP est 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 que le taux d'E/S standard.
Cela peut être une question très subjective, mais veuillez donner votre avis.
Dans la base de données la plus optimisée pour RDS P-IOPS, les performances en valent-elles le prix?
ou
Le site AWS donne un aperçu de la manière dont P-IOPS peut améliorer les performances. Existe-t-il une référence réelle?
AUTO-RÉPONSE
En plus de la réponse que zeroSkillz a écrite, j'ai fait d'autres recherches. Cependant, veuillez noter que je ne suis pas un expert en lecture de références de bases de données. En outre, la référence et la réponse étaient basées sur EBS.
Selon n article écrit par "Rodrigo Campos", les performances s'améliorent réellement de manière significative.
De 1000 IOPS à 2000 IOPS, les performances en lecture/écriture (y compris en lecture/écriture aléatoire) doublent. D'après ce que zeroSkillz a dit, le bloc EBS standard fournit environ 100 IOPS. Imaginez l'amélioration des performances lorsque 100 IOPS va jusqu'à 1000 IOPS (qui est le minimum d'IOPS pour le déploiement P-IOPS).
Conclusion
Selon le benchmark, le rapport performance/prix semble raisonnable. Pour les situations critiques en termes de performances, je suppose que certaines personnes ou entreprises devraient choisir P-IOPS même lorsqu'elles sont facturées 100 fois plus.
Cependant, si j'étais consultant financier dans une petite ou moyenne entreprise, je ferais simplement évoluer (comme dans le processeur, la mémoire) sur mes instances RDS progressivement jusqu'à ce que les performances/prix correspondent à P-IOPS.
D'accord. C'est une mauvaise question car elle ne mentionne pas la taille du stockage alloué ni aucun autre détail de la configuration. Nous utilisons RDS et il a ses avantages et ses inconvénients. Tout d'abord, 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 étant dit - le support de stockage pour RDS est supposé être basé sur une variante d'EBS d'Amazon. Les performances des IOPS standard dépendent de la taille du volume et de nombreuses sources indiquent qu'au-dessus de 100 Go de stockage, elles commencent à "répartir" les volumes EBS. Cela permet un meilleur accès aux données de cas moyen en lecture et en écriture.
Nous exécutons actuellement environ 300 Go d'allocation de stockage et pouvons obtenir 2 k d'écriture IOP et 1 k IOP environ 85% du temps sur une période de plusieurs heures. Nous utilisons le datadog pour enregistrer ceci afin que nous puissions réellement le voir. Nous avons vu des rafales allant jusqu'à 4 000 IOP d'écriture, mais rien de tel n'a été maintenu.
Le principal symptôme que nous voyons du côté de l'application est le conflit de verrouillage si les IOPS pour l'écriture ne suffisent pas. Le nombre et la fréquence que vous obtenez de ces derniers dans vos journaux d'application vous donneront des symptômes pour épuiser les IOPS du 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 constants 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 commencé à résoudre les services cloud. La seule assurance que vous obtenez avec P-IOPS est que vous aurez une capacité de débit maximale réservée. Si vous ne l'utilisez pas, vous le payez quand même.
Si vous êtes d'accord avec l'exécution de 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 standard. Vous pouvez obtenir de meilleures IOPS de lecture à un prix beaucoup moins cher en gérant vous-même la réplique. Nous configurons même des répliques en dehors d'AWS à l'aide de stunnel et plaçons les disques SSD comme périphérique de blocage principal et nous obtenons des vitesses de lecture ridicules pour nos systèmes de rapports - littéralement 100 fois plus rapides que celles obtenues avec RDS.
J'espère que cela aide à donner des détails sur le monde réel. En bref, à mon avis - à moins que vous ne deviez garantir un certain niveau de capacité de débit (ou que votre application échoue) sur une base constante (ou à un moment donné), il existe de meilleures alternatives aux IOPS provisionnés, y compris le fractionnement en lecture-écriture avec lecture -replicas memcache etc.
Donc, je viens de quitter un appel avec un ingénieur système Amazon, et il avait quelques idées intéressantes liées à cette question. (c.-à-d. c'est une connaissance de seconde main.)
les blocs EBS standard peuvent bien gérer le trafic en rafale, mais ils finiront par diminuer à environ 100 iops. Il y avait plusieurs alternatives que cet ingénieur a suggérées.
certains clients utilisent plusieurs petits blocs EBS et les rayent. Cela améliorera les IOPS et sera le plus rentable. Vous n'avez pas à vous soucier de la mise en miroir car EBS est mis en miroir dans les coulisses.
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 l'EBS. Vous pouvez même utiliser des instances EC2 provisionnées SSD.
certains clients configureront le maître pour utiliser les IOPS provisionnés ou le stockage éphémère SSD, puis utiliseront le stockage EBS standard pour les esclaves. Les performances attendues sont bonnes, mais les performances de basculement sont dégradées (mais toujours disponibles)
de toute façon, si vous décidez d'utiliser l'une de ces stratégies, je revérifierais avec Amazon pour m'assurer que je n'ai oublié aucune étape importante. Comme je l'ai déjà dit, c'est une connaissance de seconde main.