Comment doubler les performances de MySQL AWS par rapport à Amazon RDS au même coût

AWS est le fournisseur de cloud n°1 pour l'hébergement de bases de données open source et le cloud incontournable pour les déploiements MySQL. Alors que les organisations continuent de migrer vers le cloud, il est important de faire face aux problèmes de performances, tels que la latence élevée, le faible débit et le décalage de réplication avec des distances plus élevées entre vos utilisateurs et l'infrastructure cloud. Alors que de nombreux utilisateurs AWS utilisent par défaut leur solution de base de données gérée, Amazon RDS, il existe des alternatives disponibles qui peuvent améliorer vos performances MySQL sur AWS grâce à des options de personnalisation avancées et à une prise en charge illimitée du type d'instance EC2. ScaleGrid offre une alternative convaincante à l'hébergement de MySQL sur AWS qui offre de meilleures performances, plus de contrôle et aucun verrouillage du fournisseur cloud et le même prix qu'Amazon RDS. Dans cet article, nous comparons les performances de MySQL Amazon RDS par rapport à l'hébergement MySQL chez ScaleGrid sur les instances AWS hautes performances.

TLDR

Le déploiement MySQL sur AWS hautes performances de ScaleGrid peut fournir un débit deux à trois fois supérieur à la moitié de la latence d'Amazon RDS pour MySQL, avec l'avantage supplémentaire d'avoir 2 réplicas en lecture contre 1 dans RDS.

Test de performances MySQL sur AWS

Comme vous pouvez le voir dans le tableau ci-dessus, le prix de MySQL RDS est à moins de 10 $ de la solution d'hébergement MySQL entièrement gérée et tout compris de ScaleGrid.

Que sont les ensembles de répliques hautes performances de ScaleGrid ?

L'ensemble de réplicas ScaleGrid MySQL sur AWS haute performance utilise un hybride de disque SSD local et EBS pour atteindre à la fois des performances élevées et une grande fiabilité. Une configuration typique est déployée à l'aide d'un jeu de répliques à 3 nœuds :

• Le maître et l'esclave-1 utilisent des disques SSD locaux.
• L'esclave 2 utilise un disque EBS (il peut s'agir d'un disque à usage général ou d'un disque IOPS provisionné).

Qu'est-ce que cela signifie ? Étant donné que le maître et l'esclave-1 s'exécutent sur un SSD local, vous obtenez les meilleures performances de disque possibles de vos machines AWS. Plus d'EBS basé sur le réseau, juste un SSD local ultra-rapide. Les lectures et écritures sur votre primaire, et même les lectures à partir de Slave-1 fonctionneront à la vitesse du SSD. Slave-2 utilise un disque de données EBS et vous pouvez configurer la quantité d'IOPS requise pour votre cluster. Cette configuration offre une sécurité totale pour vos données, même en cas de perte des disques SSD locaux.

L'ensemble de réplicas MySQL AWS haute performance XLarge de ScaleGrid utilise des instances i3.xlarge (30,5 Go de RAM) avec un SSD local pour le maître et l'esclave-1, et un i3.2xlarge (61 Go RAM) instance pour Slave-2.

Configuration MySQL

Une configuration MySQL similaire est utilisée sur les déploiements ScaleGrid et RDS :

Configuration de l'analyse comparative des performances MySQL

Scénarios et résultats des tests de performances MySQL

Pour nous assurer que nous fournissons des résultats informatifs pour tous les types de charge de travail MySQL AWS, nous avons divisé nos tests en trois scénarios afin que vous puissiez évaluer en fonction de l'intensité de votre charge de travail en lecture/écriture :

1. Charge de travail intensive en lecture : 80 % de lectures et 20 % d'écritures
2. Charge de travail équilibrée : 50 % de lectures et 50 % d'écritures
3. Charge de travail intensive en écriture : 20 % de lectures et 80 % d'écritures

Chaque scénario est exécuté avec un nombre variable de threads client sysbench allant de 50 à 400, et chaque test est exécuté pendant une durée de 10 minutes. Nous mesurons le débit en termes de requêtes par seconde (RPS) et de latence au 95e centile, et nous nous assurons que le délai de réplication maximal sur les esclaves ne dépasse pas 30 s. Pour certains des tests sur le déploiement de ScaleGrid, la configuration MySQL binlog_group_commit_sync_delay est réglée de manière à ce que le décalage de réplication de l'esclave ne dépasse pas 30 secondes. Cette technique est appelée « ralentir le maître pour accélérer les esclaves » et est expliquée dans le blog de J-F Gagné.

Scénario 1 :charge de travail intensive en lecture avec 80 % de lectures et 20 % d'écritures

Comme nous pouvons le voir à partir des tests de charge de travail intensifs en lecture, les instances MySQL hautes performances de ScaleGrid sur AWS sont capables de gérer de manière cohérente environ 27 800 RPS allant de 50 à 400 fils. Il s'agit d'une augmentation de près de 200 % par rapport aux performances de MySQL RDS, qui n'affichent en moyenne que 9 411 RPS sur la même gamme de threads.

ScaleGrid maintient également une latence inférieure de 53 % en moyenne tout au long des tests de performances MySQL AWS. La latence d'Amazon RDS et de ScaleGrid augmente régulièrement à mesure que le nombre de threads augmente, où ScaleGrid atteint un maximum de 383 ms pour 400 threads tandis qu'Amazon RDS est à 831 ms au même niveau.

Scénario 2 :charge de travail équilibrée avec 50 % de lectures et 50 % d'écritures

Dans nos tests de performances de charges de travail équilibrées, le déploiement MySQL High Performance de ScaleGrid sur AWS surpasse à nouveau avec une moyenne de 20 605 RPS sur des threads allant de 50 à 400. Amazon RDS seulement 8 296 en moyenne pour le même nombre de threads, ce qui a entraîné une amélioration de 148 % avec ScaleGrid.

La latence de ScaleGrid et d'Amazon RDS a considérablement diminué dans les tests de charge de travail équilibrée par rapport aux tests intensifs en lecture couverts ci-dessus. Amazon RDS a enregistré une latence moyenne de 258 ms dans les tests de charge de travail équilibrée, alors que ScaleGrid n'a atteint qu'une moyenne de 125 ms, réalisant une réduction de plus de 52 % de la latence par rapport à MySQL sur Amazon RDS.

Scénario 3 :charge de travail intensive en écriture avec 20 % de lectures et 80 % d'écritures

Dans notre dernier scénario de charge de travail MySQL AWS intensive en écriture, ScaleGrid a atteint des performances de débit nettement supérieures avec une moyenne de 17 007 RPS sur la plage de 50 à 400 threads. Il s'agit d'une amélioration de 123 % par rapport à Amazon RDS qui n'a atteint que 7 638 RPS sur le même nombre de threads.

Les tests de latence au 95e centile ont également produit une latence significativement plus faible pour ScaleGrid, à une moyenne de 114 ms sur 50 à 400 threads. Amazon RDS a atteint une moyenne de 247 ms lors de ses tests de latence, ce qui a entraîné une réduction moyenne de 54 % de la latence lors du déploiement des services MySQL haute performance de ScaleGrid sur AWS via Amazon RDS.

Analyse

Comme nous l'avons observé à partir des résultats des tests, les charges de travail intensives en lecture ont entraîné à la fois un débit et une latence plus élevés que les charges de travail équilibrées et les charges de travail intensives en écriture, quelle que soit la manière dont MySQL a été déployé sur AWS :

Explication des résultats

• Nous constatons que le déploiement de ScaleGrid MySQL sur AWS a fourni un débit près de 3 fois supérieur pour la charge de travail intensive en lecture par rapport au déploiement RDS.
• À mesure que la charge d'écriture augmentait, bien que le débit absolu diminuait, ScaleGrid fournissait toujours des performances de débit près de 2,5 fois supérieures.
• Pour les charges de travail intensives en écriture, nous avons constaté que le décalage de réplication commençait à se déclencher pour l'esclave EBS sur le déploiement ScaleGrid. Étant donné que notre objectif était de maintenir le délai de réplication de l'esclave dans les 30 secondes pour nos exécutions, nous avons introduit binlog_group_commit_sync_delay pour garantir que l'esclave puisse réaliser une meilleure exécution parallèle. Cela a permis de contrôler le délai et a entraîné un débit absolu moindre sur le déploiement de ScaleGrid, mais nous pouvions toujours voir un débit 2,2 x meilleur par rapport au déploiement RDS.
• Pour tous les scénarios de charges de travail intensives en lecture, en écriture et équilibrées, ScaleGrid offrait des caractéristiques de latence 0,5 fois plus faibles que RDS.