Gestion des charges de travail de production sur les bases de données hébergées

Fourni par Services Web Amazon

AWS propose plusieurs options pour héberger vos bases de données servant des charges de travail OLTP - hébergez votre propre base de données gérée sur Amazon EC2 instances ou utiliser Amazon RDS géré par AWS. RDS gère la haute disponibilité, les sauvegardes automatisées, les mises à niveau de la base de données, les correctifs du système d'exploitation, la sécurité et la réplique en lecture. RDS propose également l'option cloud-native Amazon Aurora moteur de base de données compatible avec MySQL et PostgreSQL. Aurora offre un débit plus élevé que les bases de données MySQL et PostgreSQL standard.

Lors de l'exécution de charges de travail de production sur des bases de données hébergées avec Amazon RDS ou Amazon EC2, vous avez peut-être rencontré les questions suivantes :

• Quelles sont les meilleures options de type de stockage de base de données ?
• Comment résoudre les problèmes de performances de stockage ?
• Quelles sont les options de configuration RAID pour les bases de données hébergées sur une instance EC2 ?
• Quelles sont les modifications de l'application pour des performances optimales ?
• Comment résoudre les problèmes de performances de stockage à l'aide de Amazon Cloud Watch ?
• Performances opérationnelles d'Amazon RDS par rapport à Aurora ?

Dans cet article, je propose les meilleures pratiques de stockage pour exécuter des charges de travail de production sur des bases de données hébergées sur des instances Amazon RDS ou EC2.

Par rapport aux environnements de test, d'assurance qualité ou de mise en scène, les charges de travail de production nécessitent des performances d'E/S rapides et cohérentes. Bien que les bases de données relationnelles puissent être utilisées à plusieurs fins, leur cas d'utilisation le plus courant consiste à héberger une charge de travail de traitement des transactions en ligne (OLTP). RDS, les bases de données hébergées EC2 et Aurora utilisent différents types de techniques de stockage, comme indiqué ci-dessous :

• Les instances de base de données Amazon RDS utilisent AmazonEBS volume de stockage.
• Les instances Aurora utilisent des volumes de stockage propriétaires AWS.
• Les instances EC2 permettent une variété d'options de stockage.

Meilleures options de type de stockage de base de données

Amazon RDS fournit trois types de stockage :

• SSD à usage général (également appelé volumes gp2 )
• SSD IOPS provisionné (également appelé io1 )
• Magnétique

La capacité d'E/S de l'instance est basée sur le type et la taille de stockage de l'instance. Si l'instance de base de données est configurée avec un volume gp2, la capacité IOPS de base correspond à 3 fois le stockage en Gio. Si l'instance de base de données a alloué un volume gp2 de 100 Gio, la capacité IOPS de base est de 300. Plus vous provisionnez de stockage, plus la capacité IOPS est élevée.

En plus de la capacité IOPS de base, les volumes gp2 offrent également une capacité de rafale jusqu'à 3 000 IOPS pendant de longues périodes. La fonctionnalité de rafale est limitée aux volumes égaux ou inférieurs à 1 Tio de stockage. Les instances de base de données pour MySQL, MariaDB, Oracle et PostgreSQL peuvent être configurées avec 20 Gio à 32 Tio, mais les IOPS de base maximales sont limitées entre 100 et 16 000 IOPS. Ainsi, un volume gp2 de 5,34 Tio ou plus offre la même ligne de base : 16 000 IOPS.

Si votre charge de travail de production nécessite un OLTP élevé et des performances de débit rapides et constantes, vous devez configurer votre instance de base de données avec des volumes io1. Par rapport aux volumes gp2, qui fournissent une base de référence maximale de 16 000 IOPS, les volumes io1 peuvent fournir jusqu'à 40 000 IOPS pour les instances de base de données pour MySQL, MariaDB, Oracle et PostgreSQL et jusqu'à 32 000 pour les instances SQL Server.

Si vous constatez que le modèle d'utilisation des IOPS dépasse systématiquement plus de 16 000, vous devez modifier la BD instanceet modifiez le type de stockage de gp2 à io1. Amazon RDS propose également un stockage magnétique, mais il n'est pas adapté à une charge de travail OLTP nécessitant des performances d'E/S constantes et une faible latence.

Le type de stockage magnétique n'est pas recommandé pour les charges de travail gourmandes en E/S, car le stockage maximal est inférieur à celui de gp2 ou io1. La capacité IOPS est également limitée à un maximum de 1 000 IOPS.

Problèmes de performances de stockage

L'utilisation du stockage gp2 est idéale pour une grande variété de charges de travail de base de données. Pour ce type de stockage, concevez les charges de travail de lecture et d'écriture de la base de données de manière à ce que la somme de LireIOPS et WriteIOPS les valeurs ne dépassent pas la capacité IOPS de base à un moment donné.

La capacité de rafale peut être disponible pendant une période prolongée. Cependant, une fois la capacité de rafale utilisée, une valeur élevée constante d'IOPS en lecture et en écriture dégrade les performances de l'instance. Cette dégradation se traduit par une augmentation Latence d'écriture ou Latence de lecture valeurs. Idéalement, le stockage gp2 est bon pour une latence à un chiffre en millisecondes, mais une utilisation excessive des IOPS peut entraîner une latence > 10 ms.

Les images suivantes montrent une augmentation Latence d'écriture car WriteIOPS consomme systématiquement une capacité de base de 300 IOPS sur une instance de base de données Amazon RDS. Dans cet exemple, l'instance Amazon RDS PostgreSQL est hébergée sur une instance t2.small avec un volume gp2 de 100 Gio.

L'image ci-dessus montre Write IOPS consommant 300 IOPS de manière constante, ce qui correspond aux performances de base.

L'image ci-dessus montre que la latence d'écriture a atteint 25 millisecondes en raison d'une utilisation excessive des IOPS.

Comme bonne pratique, assurez-vous que votre charge de travail ne dépasse pas la capacité IOPS de l'instance. Quelques-unes des façons de réduire LireIOPS les valeurs sont de :

• Utilisez un réplica en lecture Amazon RDS.
• Utilisez plus de RAM.

Utilisation d'un réplica en lecture Amazon RDS

Offre d'instances de base de données Amazon RDS pour MySQL, MariaDB, Oracle et PostgreSQL Réplicas en lecture RDS . Ces instances sont des instances de base de données distinctes synchronisées avec l'instance de base de données source en relisant les journaux transactionnels de la base de données. Toute modification de données sur l'instance de base de données source est appliquée sur le réplica en lecture. Avec un réplica en lecture, vous réduisez la charge sur votre instance de base de données source en acheminant les requêtes de lecture de vos applications vers le réplica en lecture. Vous libérez également de la capacité IOPS pour une activité d'écriture supplémentaire sur l'instance de base de données source.

Avec les réplicas en lecture, il est important de surveiller le décalage de réplication. Généralement, un décalage de réplication élevé est dû à une activité d'écriture élevée sur l'instance de base de données source.

Dans les instances de base de données Amazon RDS, vous pouvez surveiller le décalage de réplica par la métrique CloudWatch ReplicaLag . Si vous trouvez un décalage de réplica élevé, vous devez également surveiller l'activité d'écriture sur l'instance de base de données source. Cela peut être accompli en surveillant les métriques CloudWatch WriteIOPS et Débit d'écriture . Si l'instance de base de données source est déficiente en IOPS (c'est-à-dire que toute la capacité IOPS est utilisée par la charge de travail d'écriture et de lecture), le réplica reste également en retard.

L'une des raisons derrière les réplicas en retard est que dans la plupart des moteurs de base de données, la récupération des réplicas en lecture implique des processus à une seule bande de roulement. Cela signifie que plus la charge est élevée sur une instance maître, plus la récupération est exponentiellement lente sur les réplicas en lecture. Toute activité d'écriture élevée supplémentaire au niveau de l'instance de base de données source augmente de manière exponentielle le retard de lecture du réplica. Outre les métriques CloudWatch, avec ReplicaLag vous pouvez également surveiller le décalage par des requêtes SQL.

Dans PostgreSQL, le décalage de lecture du réplica peut être calculé à l'aide de la requête suivante :

|__+_|

Dans MySQL, vous pouvez vérifier l'état de la réplication avec la commande suivante :

|__+_|

Avec un réplica en lecture Amazon RDS, configurez le client de telle sorte qu'un certain niveau de latence ou d'erreur de réplication trouvé au niveau d'un réplica déclenche une tentative de connexion avec un autre point de terminaison de réplica.

Un bon moyen de vous assurer que votre application peut trouver le réplica le plus sain consiste à appeler les métriques CloudWatch pour trouver les valeurs actuelles de ReplicaLag et latence de lecture/écriture. Le décalage de réplication peut être trouvé avec les commandes SQL, comme indiqué dans les exemples précédents. Vous pouvez également trouver l'état actuel de la réplique en appelant le Interface de ligne de commande AWS (AWS CLI) commande describe-db-instances. Si l'état actuel de la réplique est autre que la réplication, le client doit essayer de se connecter à une autre réplique.

Outre l'avantage de distribuer les transactions en lecture, les réplicas en lecture peuvent également être utilisés pour partitionner vos données. En suivant l'architecture sans partage des fragments, vous pouvez créer des répliques en lecture correspondant à chacun de vos fragments et les promouvoir lorsque vous décidez de les convertir en fragments autonomes.

Utiliser plus de RAM

Les instances de base de données Amazon RDS doivent disposer de suffisamment de RAM pour que votre ensemble de travail complet réside en mémoire. Comme les requêtes de lecture peuvent lire les données de la mémoire, cela réduit la communication avec les volumes de stockage. En tant que tel, il réduit l'utilisation de LireIOPS capacité pouvant être utilisée à des fins d'écriture.

Il n'y a pas de moyen simple de trouver la taille d'un ensemble de données de travail. Regardez les requêtes de lecture et découvrez combien de données sont touchées. Par exemple, si la taille d'une base de données est de 100 Gio et que la plage de travail est de 20 Gio, vous devez utiliser un Instance de base de données Amazon RDS avec au moins 20 Go de mémoire. Cela vous permet d'avoir l'ensemble de travail complet en mémoire.

Options de configuration RAID pour les bases de données hébergées sur une instance EC2

Les volumes EBS sont des volumes de stockage de niveau bloc qui fournissent un stockage de bloc persistant. Ces volumes sont des volumes de stockage hautement disponibles et peuvent être attachés à une instance EC2 dans la même zone de disponibilité. Les volumes EBS sont idéaux pour les bases de données hébergées sur des instances EC2. L'utilisation du stockage éphémère d'instance EC2 pour une base de données n'est pas recommandée.

En utilisant des volumes de stockage EBS avec des instances EC2, vous pouvez configurer des volumes avec n'importe quel niveau RAID. Par exemple, pour de meilleures performances d'E/S, vous pouvez opter pour RAID 0, qui peut répartir plusieurs volumes ensemble. RAID 1 peut être utilisé pour la redondance des données car il met en miroir deux volumes ensemble.

Quelle que soit la configuration RAID, les données de volume EBS sont répliquées sur les serveurs secondaires pour éviter toute perte de données. RAID 5 et RAID 6 ne sont pas recommandés sur les bases de données hébergées sur une instance EC2 car les performances d'E/S ne sont pas aussi bonnes que RAID 0 ou RAID 1.

Le tableau suivant montre les avantages et les inconvénients entre l'utilisation de ces deux configurations différentes de RAID et suggère des cas d'utilisation possibles.

Configuration	Avantages	Désavantages	Cas d'utilisation
RAID 0	Performances d'E/S supérieures par rapport à la tolérance aux pannes	La perte d'un seul volume entraîne une perte complète de données	Si la base de données nécessite un débit plus élevé par rapport à la disponibilité des données et que les données sont reproductibles
RAID 1	La tolérance aux pannes est supérieure par rapport aux performances d'E/S	Performances d'écriture faibles	Si les données sont critiques et que la tolérance aux pannes de la base de données est plus importante que les performances d'E/S

Modifications de l'application pour des performances optimales

Si une instance de base de données est confrontée à des problèmes de stockage et rencontre des problèmes tels qu'un temps de validation élevé et des latences élevées, des modifications de l'application peuvent parfois atténuer cette dégradation. Vous pouvez modifier les applications pour activer l'interruption exponentielle ou les nouvelles tentatives d'erreur.

L'interruption exponentielle permet aux applications d'attendre progressivement plus longtemps entre les tentatives pour des réponses d'erreur consécutives. Alors que certains algorithmes utilisent un délai incrémentiel, la plupart des algorithmes de temporisation exponentielle utilisent un délai aléatoire. Voici des exemples pour un algorithme différent :

Délai aléatoire :

1. L'application lance la demande.
2. Si la demande échoue, attendez rand(1000,3000) millisecondes et relancez la demande.
3. Si la demande échoue, attendez rand(1000,3000) millisecondes et relancez la demande.
4. Si la demande échoue, attendez rand(1000,3000) millisecondes et relancez la demande.

Retard incrémentiel :

1. L'application lance la demande.
2. Si la demande échoue, attendez 1 = 1000 millisecondes et relancez la demande.
3. Si la demande échoue, attendez 2 = attendez 1 + 1000 millisecondes et relancez la demande.
4. Si la demande échoue, attendez 3 = attendez 2 + 1000 millisecondes et relancez la demande.

Utilisez certaines bonnes pratiques pour accélérer le basculement dans les instances Amazon RDS Multi-AZ et les clusters Aurora. Activez les paramètres TCP keepalive et définissez-les de manière agressive pour vous assurer que si votre client n'est plus en mesure de se connecter à l'instance de base de données, toutes les connexions actives sont fermées rapidement. Cette modification permet également aux applications de réagir plus rapidement au basculement et de se connecter rapidement au nouveau point de terminaison.

Vous pouvez également réduire le délai d'expiration de la mise en cache DNS sur le client. Les connexions de lecture et d'écriture sont établies rapidement vers les terminaux appropriés. Certains des paramètres de réglage TCP du serveur peuvent également être modifiés. Ces modifications permettent un basculement plus rapide. Par exemple, dans PostgreSQL, cela peut être contrôlé par tcp_keepalives_count, tcp_keepalives_idle et tcp_keepalives_interval paramètres .

Dépannage des performances de stockage à l'aide de CloudWatch

La surveillance régulière de l'intégrité du stockage d'instance permet d'identifier l'apparition précoce d'un problème de performances avant qu'il n'ait un effet grave sur les performances de la base de données. Certaines des métriques liées au stockage CloudWatch que vous devez surveiller régulièrement sont répertoriées ici.

Opérations d'écriture

• WriteIOPS : Mesurée à un taux de nombres/seconde, cette métrique CloudWatch détermine le nombre moyen d'opérations d'E/S d'écriture sur disque par seconde. Concentrez-vous sur cette métrique si votre instance de base de données est configurée avec un paramètre Multi-AZ.
  À l'aide de Multi-AZ, une instance secondaire est créée dans une autre zone de disponibilité avec la même configuration d'instance que le volume de stockage EBS principal et attaché. Ce stockage est synchronisé de manière synchrone avec le stockage d'instance maître. Pour la redondance des données, par défaut, les données de chaque volume EBS sont copiées vers un autre volume EBS secondaire situé dans la même zone de disponibilité. Cela signifie qu'une transaction d'écriture doit être validée à quatre endroits avant d'envoyer un accusé de réception au client. Une activité d'écriture massive au-dessus des IOPS et de la capacité de débit des instances détériore les performances globales.
• Débit d'écriture : Cette métrique CloudWatch représente le nombre moyen d'octets écrits sur le disque par seconde. Dépasser le débit de l'instance ou la limite de débit de stockage nuit aux performances de l'instance. Je suggère de surveiller l'activité d'écriture et de répartir la charge de travail d'écriture avec un délai approprié pour optimiser les performances.
• Latence d'écriture : Il s'agit du temps moyen pris par opération d'E/S de disque. Le plus souvent Latence d'écriture les augmentations sont dues à une utilisation excessive des ressources de l'instance, telles que le processeur, les IOPS et le débit.

Opérations de lecture

• LireIOPS : Mesurée à un taux de comptages/seconde, cette métrique CloudWatch détermine le nombre moyen d'opérations d'E/S de lecture de disque par seconde. La valeur accrue de LireIOPS suggère que la charge de travail en lecture est élevée ou que l'instance nécessite plus de mémoire libre.
• Débit de lecture : Cette métrique représente le nombre moyen d'octets lus sur le disque par seconde. Dépasser les limites d'instance et d'EBS peut augmenter la latence.
• Latence de lecture : Il s'agit du temps moyen pris par opération d'E/S de disque. Si vous avez une valeur élevée pour cette métrique, examinez la charge de travail de lecture et assurez-vous qu'elle n'utilise pas trop les ressources de l'instance.

Autres métriques

Outre les métriques mentionnées précédemment, vous devez également surveiller les métriques CloudWatch suivantes :

• DiskQueueDepthDiskQueueDepth représente le nombre d'E/S en attente (requêtes de lecture/écriture) attendant d'accéder au disque. En règle générale, cela est le résultat d'une charge de travail élevée.
• Espace de stockage gratuit détermine la quantité d'espace de stockage disponible. Comme meilleure pratique, vous devriez définir Alertes CloudWatch afin que vous puissiez recevoir des notifications SNS dès que le stockage gratuit de l'instance passe en dessous d'une valeur seuil, telle que 15 %.

Performances opérationnelles d'Amazon RDS par rapport à Aurora

Comme mentionné précédemment, les instances de base de données Amazon RDS et les instances EC2 ont une dépendance IOPS sur les volumes de stockage. Les types de stockage gp2 et io1 ont leurs propres limites IOPS.

Si votre charge de travail nécessite des performances IOPS et un débit plus élevés, vous pouvez envisager de migrer vers Aurora, qui est une solution hautes performances, hautement disponible et économique adaptée aux charges de travail à haut débit. Actuellement, Aube propose des moteurs compatibles MySQL et PostgreSQL.

Lors de l'utilisation d'Aurora, assurez-vous qu'il n'y a techniquement aucune limite d'IOPS, mais que le débit peut être limité au sous-jacent Instance d'Aurora limite. Pour un meilleur débit, optez pour une classe d'instance Aurora supérieure.

Aurora est le mieux adapté aux applications nécessitant peu ou pas de latence pour un IOPS donné. Il est conçu pour gérer une grande vitesse de données offrant un débit plus élevé par rapport aux moteurs MySQL et PostgreSQL traditionnels. En tant que base de données de stockage en ligne, elle est parfaitement adaptée aux charges de travail OLTP à volume élevé et simultanées.

Un autre cas d'utilisation d'Aurora est le traitement analytique des transactions hybrides (HTAP). Aurora prend en charge jusqu'à 15 répliques. Chacune de ces répliques s'exécute dans les 15 à 20 millisecondes suivant l'instance d'écriture. Avec le récemment ajouté Fonctionnalité de requête parallèle d'Amazon Aurora , le traitement des requêtes est transmis ultérieurement au stockage Aurora. La requête utilise potentiellement des milliers de nœuds de stockage dans un cluster Aurora pour traiter, affiner et agréger les données avant de les envoyer au nœud de calcul.

Conclusion

Dans cet article, vous avez découvert les meilleures pratiques de stockage pour exécuter une charge de travail de production sur une instance de base de données Amazon RDS et des bases de données hébergées sur une instance EC2. Ces pratiques impliquaient ce qui suit :

• Allocation de charges de travail de lecture à un réplica en lecture.
• Comprendre la capacité IOPS et sa dépendance à la taille et au type de stockage.
• Modification de l'architecture des applications.
• Examen des options RAID.
• Surveillance des métriques CloudWatch.

Vous avez également découvert Aurora et comment son stockage propriétaire fonctionne différemment des volumes EBS. Toutes ces connaissances vous aident à exécuter une charge de travail de production en douceur et sans problème sur les bases de données AWS. Vous pouvez également consulter les détails de la façon dont Aurora gère la vitesse et la disponibilité de la base de données à l'aide de la couche de stockage dans cet article du blog de la base de données : Présentation du moteur de stockage Aurora.

cacher