Guide de dimensionnement de cluster DAX - Amazon DynamoDB
PrésentationEstimation du traficTest de charge

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Guide de dimensionnement de cluster DAX

Ce guide fournit des conseils pour choisir une taille de cluster Amazon DynamoDB Accelerator (DAX) et un type de nœud appropriés pour votre application. Ces instructions vous guident dans les étapes d'estimation du trafic DAX de votre application, de sélection d'une configuration de cluster et de test de celle-ci.

Si vous avez un cluster DAX et souhaitez évaluer s'il a le nombre et la taille appropriés de nœuds, consultez Mise à l'échelle d'un cluster DAX.

Présentation

Il est important de mettre à l'échelle votre cluster de façon appropriée pour votre charge de travail, que vous créiez un cluster ou mainteniez un cluster existant. Au fur et à mesure que le temps passe et que la charge de travail de votre application change, vous devez revoir périodiquement vos décisions de mise à l'échelle pour vous assurer qu'elles sont toujours appropriées.

Le processus suit généralement les étapes suivantes :

  1. Estimation du trafic. Au cours de cette étape, vous faites des prédictions sur le volume de trafic que votre application enverra à DAX, la nature du trafic (opérations de lecture et d'écriture) et le taux d'accès attendu au cache.

  2. Test de charge. Dans cette étape, vous créez un cluster et lui envoyez un trafic reflétant en miroir vos estimations de l'étape précédente. Répétez cette étape jusqu'à ce que vous trouviez une configuration de cluster appropriée.

  3. Surveillance de la production. Pendant que votre application utilise DAX en production, vous devez surveiller le cluster pour vérifier en permanence qu'il est toujours mis à l'échelle correctement à mesure que votre charge de travail évolue au fil du temps.

Estimation du trafic

Trois facteurs principaux caractérisent une charge de travail DAX typique :

Estimation du taux d'accès au cache

Si vous possédez déjà un cluster DAX, vous pouvez utiliser les CloudWatch métriques ItemCacheHits et ItemCacheMisses Amazon pour déterminer le taux de réussite du cache. Le taux d'accès au cache est égal à ItemCacheHits / (ItemCacheHits + ItemCacheMisses). Si votre charge de travail inclut les opérations Query ou Scan, vous devez également examiner les métriques QueryCacheHits, QueryCacheMisses, ScanCacheHits et ScanCacheMisses. Les taux d'accès au cache varient d'une application à l'autre et sont fortement influencés par le paramètre de time-to-live (TTL) du cluster. Les taux d'accès typiques pour les applications utilisant DAX sont de 85 à 95 %.

Estimation des unités de capacité en lecture et en écriture

Si vous disposez déjà de tables DynamoDB pour votre application, consultez les métriques et. ConsumedReadCapacityUnitsConsumedWriteCapacityUnits CloudWatch Utilisez la statistique Sum et divisez par le nombre de secondes de la période.

Si vous disposez également d'un cluster DAX, n'oubliez pas que la métrique DynamoDB ConsumedReadCapacityUnits ne tient compte que des échecs d'accès au cache. Donc, pour avoir une idée des unités de capacité de lecture par seconde gérées par votre cluster DAX, divisez le nombre par votre taux d'échec d'accès au cache (c'est-à-dire 1 - taux d'accès au cache).

Si vous ne possédez pas encore de table DynamoDB, consultez la documentation sur les unités de capacité de lecture et d'écriture pour estimer votre trafic en fonction du taux de demandes estimé de votre application, des éléments consultés par demande et de la taille des éléments.

Lors de l'estimation du trafic, planifiez la croissance future et les pics prévus et imprévus pour vous assurer que votre cluster dispose d'une marge de manœuvre suffisante pour augmenter le trafic.

Test de charge

L'étape suivante après l'estimation du trafic consiste à tester la configuration du cluster sous charge.

  1. Pour votre test de charge initial, nous vous recommandons de commencer avec le type de nœud dax.r4.large, type de nœud optimisé pour la mémoire aux performances fixes les moins coûteuses.

  2. Un cluster tolérant les pannes nécessite au moins trois nœuds répartis sur trois zones de disponibilité. Dans ce cas, si une zone de disponibilité devient indisponible, le nombre effectif de zones de disponibilité est réduit d'un tiers. Pour votre test de charge initial, nous vous recommandons de commencer par un cluster à deux nœuds, qui simule l'échec d'une zone de disponibilité dans un cluster à trois nœuds.

  3. Conduisez un trafic soutenu (tel qu'estimé à l'étape précédente) vers votre cluster de test pendant toute la durée du test de charge.

  4. Surveillez les performances du cluster pendant l'essai de charge.

Idéalement, le profil de trafic que vous conduisez pendant le test de charge devrait être aussi similaire que possible au trafic réel de votre application. Cela inclut la répartition des opérations (par exemple, 70 % GetItem, 25 % Query, et 5 % PutItem), le taux de demande pour chaque opération, le nombre d'éléments consultés par demande et la répartition des tailles d'articles. Pour obtenir un taux d'accès au cache similaire au taux de succès attendu de votre application, portez une attention particulière à la distribution des clés dans votre trafic de test.

Note

Soyez prudent lors du test de charge des types de nœuds T2 (dax.t2.small et dax.t2.medium). Les types de nœuds T2 offrent des performances CPU extensibles qui varient au fil du temps en fonction du solde de crédit CPU du nœud. Un cluster DAX s'exécutant sur des nœuds T2 peut sembler fonctionner normalement, mais si un nœud dépasse les performances de base de son instance, le nœud dépense son solde de crédits UC accumulé. Lorsque le solde créditeur est bas, les performances sont progressivement ramenées au niveau de performance de base.

Surveillez votre cluster DAX pendant le test de charge afin de déterminer si le type de nœud que vous utilisez pour le test de charge est le type de nœud qui vous convient. En outre, lors d'un test de charge, vous devez surveiller le taux de demande et le taux d'accès au cache afin de vous assurer que votre infrastructure de test entraîne réellement la quantité de trafic que vous souhaitez.

Vous devez faire attention à la consommation d'octets réseau pour le type d'instance de cluster que vous avez choisi. Le dépassement de la bande passante de référence disponible pour une instance Amazon EC2 indique que votre cluster risque de ne pas supporter la charge de travail de votre application et qu'il doit être mis à l'échelle.

Si le test de charge indique que la configuration de cluster choisie ne peut pas supporter la charge de travail de votre application, vous avez tout intérêt à passer à un type de nœud de plus grande taille, surtout si vous constatez une utilisation d'UC élevée sur le nœud primaire du cluster, des taux d'expulsion élevés ou une utilisation de mémoire cache élevée. Si les taux d'accès sont constamment élevés et que le rapport entre le trafic lecture-écriture est élevé, vous pouvez envisager d'ajouter d'autres nœuds à votre cluster. Reportez-vous à la section Mise à l'échelle d'un cluster DAX pour savoir quand utiliser un type de nœud plus grand (mise à l'échelle verticale) ou ajouter d'autres nœuds (mise à l'échelle horizontale).

Vous devez répéter votre test de charge après avoir apporté des modifications à la configuration de votre cluster.