Surveillance de DAX - Amazon DynamoDB

Surveillance de DAX

Vous pouvez surveiller les métriques clés, comme le taux d’accès au cache, afin de garantir des performances optimales du cluster DAX, de diagnostiquer les problèmes et de déterminer à quel moment vous devez mettre à l’échelle le cluster. La vérification régulière des métriques clés vous aide à maintenir les performances, la stabilité et la rentabilité en mettant à l’échelle le cluster selon les exigences de votre charge de travail. Pour plus d’informations sur la surveillance de DAX, consultez Surveillance en production.

La liste suivante présente certaines des métriques clés que vous devez surveiller :

  • Taux d’accès au cache : indique l’efficacité avec laquelle DAX traite les données mises en cache, réduisant ainsi le besoin d’accéder aux tables DynamoDB sous-jacentes. Quelques erreurs de cache pour le cluster indiquent une bonne efficacité de la mise en cache. Cependant, un faible nombre d’accès au cache suggère que vous devrez peut-être revoir le paramètre TTL de mise en cache ou que la charge de travail ne convient pas à la mise en cache.

    Utilisez Amazon CloudWatch pour calculer le taux d’accès au cache de votre cluster DAX. Comparez les métriques ItemCacheHits, ItemCacheMisses, QueryCacheHits et QueryCacheMisses pour obtenir ce ratio. La formule suivante indique comment le taux d’accès au cache est calculé. Pour calculer le ratio à l’aide de cette formule, divisez le nombre d’accès au cache par la somme des accès et des échecs.

    Cache hit ratio = Cache hits / (Cache hits + Cache misses)

    Le taux d’accès du cache est un nombre compris entre 0 et 1, qui est représenté en pourcentage. Un pourcentage supérieur indique une meilleure utilisation globale du cache.

  • ErrorRequestCount : nombre de demandes ayant entraîné des erreurs utilisateur signalées par le nœud ou le cluster. ErrorRequestCount inclut les demandes qui ont été limitées par le nœud ou le cluster. La surveillance des erreurs des utilisateurs peut vous aider à identifier les erreurs de mise à l’échelle ou les modèles d’éléments chauds/de partitions critiques dans votre application.

  • Latences opérationnelles : la surveillance de la latence des opérations de lecture et d’écriture vers et depuis le cluster DAX peut vous aider à identifier les goulots d’étranglement liés aux performances. L’augmentation des latences peut indiquer des problèmes liés à la configuration de votre cluster DAX, au réseau ou à la nécessité d’une mise à l’échelle.

  • Consommation réseau : surveillez les métriques NetworkBytesIn et NetworkBytesOut pour surveiller le trafic réseau de votre cluster DAX. Une augmentation inattendue du débit du réseau peut entraîner une augmentation du nombre de demandes des clients ou des modèles de requêtes inefficaces entraînant le transfert d’une plus grande quantité de données.

    La surveillance de la consommation du réseau vous aide à gérer les coûts de votre cluster DAX. Cela garantit également que le réseau ne devient pas un goulot d’étranglement pour les performances du cluster.

  • Taux d’éviction : indique la fréquence à laquelle des éléments sont retirés de votre cache pour faire de la place à de nouveaux éléments. Si le taux d’éviction augmente au fil du temps, votre cache est peut-être trop petit ou votre stratégie de mise en cache n’est pas efficace.

    Surveillez la métrique EvictedSize dans CloudWatch pour déterminer si la taille de votre cache est adaptée à votre charge de travail. Si la taille totale faisant l’objet d’une éviction ne cesse de croître, vous devrez peut-être augmenter verticalement votre cluster DAX pour qu’il puisse accueillir un cache plus important.

  • Utilisation du CPU : désigne le pourcentage d’utilisation du CPU du nœud ou du cluster. Il s’agit d’une métrique essentielle à surveiller pour n’importe quelle base de données ou système de mise en cache. Une utilisation élevée du CPU peut indiquer que votre cluster DAX est peut-être surchargé et doit être mis à l’échelle pour faire face à la demande accrue.

    Surveillez la métrique CPUUtilization de votre cluster DAX. Si l’utilisation de votre CPU approche ou dépasse régulièrement 70 à 80 %, pensez à augmenter verticalement votre cluster DAX comme décrit dans la section suivante.

    Si le nombre de demandes envoyées à DAX dépasse la capacité d’un nœud, DAX limite le taux d’acceptation des demandes supplémentaires. Pour ce faire, il renvoie une exception ThrottlingException. DAX évalue en continu l’utilisation du CPU de votre cluster pour déterminer le volume de demandes qu’il peut traiter tout en conservant un état de cluster sain.

    Vous pouvez surveiller la métrique ThrottledRequestCount que DAX publie dans CloudWatch. Si ces exceptions s’affichent régulièrement, vous devez envisager de mettre à l’échelle votre cluster.

Mise à l’échelle de votre cluster DAX à l’aide des données de surveillance

Vous pouvez déterminer si vous devez augmenter ou réduire verticalement votre cluster DAX en surveillant ses indicateurs de performance.

  • Augmentation verticale ou horizontale : si votre cluster DAX utilise beaucoup le processeur, présente de faibles taux d’accès au cache (après optimisation de la stratégie de mise en cache) ou des latences de fonctionnement élevées, vous devez augmenter verticalement votre cluster. L’ajout de nœuds supplémentaires, également appelé augmentation horizontale, peut aider à répartir la charge de manière plus uniforme. Pour les charges de travail impliquant une augmentation du nombre d’écritures par seconde, vous devrez peut-être choisir des nœuds plus puissants (augmentation verticale).

  • Réduction verticale : si vous constatez régulièrement une faible utilisation du CPU et des latences de fonctionnement inférieures à vos seuils, vous avez peut-être surprovisionné les ressources. Dans ce cas, réduisez verticalement le nombre de nœuds pour réduire les coûts. Vous pouvez réduire le nombre de nœuds à 1 pendant les périodes de faible utilisation, mais vous ne pouvez pas arrêter complètement le cluster.