Pilier d'efficacité des ElastiCache performances des objectifs Amazon Well-Architected - Amazon ElastiCache
PE 1 : Comment surveillez-vous les performances de votre ElastiCache cluster Amazon ?PE 2 : Comment répartissez-vous le travail entre les nœuds de votre ElastiCache cluster ?EP 3 : Pour la mise en cache des charges de travail, comment suivez-vous et rendez-vous compte de l'efficacité et des performances de votre cache ? EP 4 : Comment votre charge de travail optimise-t-elle l'utilisation des ressources de mise en réseau et des connexions ?EP 5 : Comment gérez-vous la suppression et/ou l'expulsion de clés ?PE 6 : Comment modélisez-vous les données et interagissez-vous avec celles-ci ElastiCache ? PE 7 : Comment enregistrez-vous les commandes lentes dans votre ElastiCache cluster Amazon ?PE8: Comment Auto Scaling contribue-t-il à améliorer les performances du ElastiCache cluster ?

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.

Pilier d'efficacité des ElastiCache performances des objectifs Amazon Well-Architected

Le pilier Efficacité des performances met l'accent sur l'utilisation efficace des ressources informatiques et de calcul. Les sujets clés incluent la sélection des types et des tailles de ressources appropriés en fonction des exigences de charge de travail, la surveillance des performances et la prise de décisions éclairées pour maintenir l'efficacité à mesure que les besoins de l'entreprise évoluent.

PE 1 : Comment surveillez-vous les performances de votre ElastiCache cluster Amazon ?

Introduction au niveau de la question : en comprenant les métriques de surveillance existantes, vous pouvez identifier l'utilisation actuelle. Une surveillance appropriée peut aider à identifier les goulots d'étranglement potentiels ayant une incidence sur les performances de votre cluster.

Avantage au niveau de la question : la compréhension des métriques associées à votre cluster peut aider à orienter les techniques d'optimisation susceptibles de réduire la latence et d'augmenter le débit.

  • [Obligatoire] Tests de performance de base en utilisant un sous-ensemble de votre charge de travail.

    • Vous devez surveiller les performances de la charge de travail réelle à l'aide de mécanismes tels que les tests de charge.

    • Surveillez les CloudWatch indicateurs lors de l'exécution de ces tests afin de comprendre les indicateurs disponibles et d'établir une référence de performance.

  • [Idéal] Pour les charges de travail ElastiCache (RedisOSS), renommez les commandes coûteuses en termes de calcul, par exemple pour limiter la capacité des utilisateurs à exécuter des commandes de blocage sur des clusters de production. KEYS

    • ElastiCache Les charges de travail (RedisOSS) exécutant le moteur 6.x peuvent tirer parti du contrôle d'accès basé sur les rôles pour restreindre certaines commandes. L'accès aux commandes peut être contrôlé en créant des utilisateurs et des groupes d'utilisateurs avec la AWS console ou CLI en associant les groupes d'utilisateurs à un cluster ElastiCache (RedisOSS). Dans Redis OSS 6, lorsqu'il RBAC est activé, nous pouvons utiliser « - @dangerous » et cela interdira les commandes coûteuses telles queKEYS,, MONITORSORT, etc. pour cet utilisateur.

    • Pour la version 5.x du moteur, renommez les commandes à l'aide du rename-commands paramètre du groupe de paramètres du cluster ElastiCache (RedisOSS).

  • [Pratique encore meilleure] Analysez les requêtes lentes et recherchez des techniques d'optimisation.

    • Pour les charges de travail ElastiCache (RedisOSS), apprenez-en plus sur vos requêtes en analysant le Slow Log. Par exemple, vous pouvez utiliser la commande valkey-cli slowlog get 10 pour afficher les 10 dernières commandes qui ont dépassé les seuils de latence (10 secondes par défaut).

    • Certaines requêtes peuvent être effectuées plus efficacement à l'aide de structures de données complexes ElastiCache (RedisOSS). Par exemple, pour les consultations de plages de style numérique, une application peut implémenter des index numériques simples avec des ensembles triés. La gestion de ces index permet de réduire les analyses effectuées sur l'ensemble de données et de renvoyer les données avec une meilleure efficacité en termes de performances.

    • Pour les charges de travail ElastiCache (RedisOSS), redis-benchmark fournit une interface simple permettant de tester les performances de différentes commandes à l'aide d'entrées définies par l'utilisateur, telles que le nombre de clients et la taille des données.

    • Étant donné que Memcached ne prend en charge que les commandes simples au niveau de la clé, pensez à créer des clés supplémentaires sous forme d'index afin d'éviter d'itérer dans l'espace de clé pour répondre aux requêtes des clients.

  • [Ressources] :

PE 2 : Comment répartissez-vous le travail entre les nœuds de votre ElastiCache cluster ?

Introduction au niveau des questions : la façon dont votre application se connecte ElastiCache aux nœuds Amazon peut avoir un impact sur les performances et l'évolutivité du cluster.

Avantage au niveau de la question : l'utilisation appropriée des nœuds disponibles dans le cluster garantira la répartition du travail entre les ressources disponibles. Les techniques suivantes permettent également d'éviter les ressources inactives.

  • [Obligatoire] Demandez aux clients de se connecter au point de ElastiCache terminaison approprié.

    • ElastiCache (RedisOSS) implémente différents points de terminaison en fonction du mode cluster utilisé. Si le mode cluster est activé, ElastiCache fournira un point de terminaison de configuration. Lorsque le mode cluster est désactivé, ElastiCache fournit un point de terminaison principal, généralement utilisé pour les écritures, et un point de terminaison de lecteur pour équilibrer les lectures entre les répliques. L’implémentation correcte de ces points de terminaison se traduit par de meilleures performances et des opérations de mise à l'échelle simplifiées. Évitez de vous connecter à des points de terminaison de nœuds individuels, sauf exigences particulières.

    • Pour les clusters Memcached à nœuds multiples, ElastiCache fournit un point de terminaison de configuration qui active la découverte automatique. Il est recommandé d'utiliser un algorithme de hachage pour répartir le travail de manière uniforme entre les nœuds de cache. De nombreuses bibliothèques clientes Memcached implémentent un hachage cohérent. Consultez la documentation de la bibliothèque que vous utilisez pour voir si elle prend en charge le hachage cohérent et comment le mettre en œuvre. Vous trouverez plus d'informations sur l’implémentation de ces fonctionnalités ici.

  • [Mieux] Tirez parti du mode cluster ElastiCache (RedisOSS) activé pour améliorer l'évolutivité.

    • ElastiCache (RedisOSS) (mode cluster activé) les clusters prennent en charge les opérations de dimensionnement en ligne (out/in et haut/down) pour aider à distribuer les données de manière dynamique entre les partitions. L'utilisation du point de terminaison de configuration permet à vos clients qui connaissent le cluster de s'adapter aux modifications de la topologie du cluster.

    • Vous pouvez également rééquilibrer le cluster en déplaçant les hashslots entre les partitions disponibles dans votre cluster ElastiCache (RedisOSS) (mode cluster activé). Vous pourrez ainsi répartir le travail de manière plus efficace entre les partitions disponibles.

  • [Pratique encore meilleure] Implémentez une stratégie pour identifier et corriger les touches de raccourci de votre charge de travail.

    • Tenez compte de l'impact des structures de OSS données multidimensionnelles Valkey ou Redis telles que les listes, les flux, les ensembles, etc. Ces structures de données sont stockées dans des clés uniques, qui résident sur un seul nœud. Une clé multidimensionnelle très volumineuse est susceptible d'utiliser davantage de capacité réseau et de mémoire que les autres types de données et peut entraîner une utilisation disproportionnée de ce nœud. Si possible, concevez votre charge de travail de manière à répartir l'accès aux données sur de nombreuses clés discrètes.

    • Les touches de raccourci de la charge de travail peuvent avoir un impact sur les performances du nœud utilisé. Pour les charges de travail ElastiCache (RedisOSS), vous pouvez détecter les touches de raccourci en indiquant valkey-cli --hotkeys si une politique de LFU mémoire maximale est en place.

    • Envisagez de répliquer les touches de raccourci sur plusieurs nœuds afin de répartir leur accès de manière plus uniforme. Cette approche nécessite que le client écrive sur plusieurs nœuds principaux (le OSS nœud Valkey ou Redis lui-même ne fournit pas cette fonctionnalité) et qu'il conserve une liste de noms de clés à lire, en plus du nom de clé d'origine.

    • ElastiCache avec Valkey 7.2 et versions ultérieures et Redis OSS version 6 et versions ultérieures prennent en charge la mise en cache côté client assistée par le serveur. Cela permet aux applications d'attendre que des modifications soient apportées à une clé avant de renvoyer des appels réseau àElastiCache.

  • [Ressources] :

EP 3 : Pour la mise en cache des charges de travail, comment suivez-vous et rendez-vous compte de l'efficacité et des performances de votre cache ?

Introduction au niveau des questions : La mise en cache est une charge de travail courante ElastiCache et il est important que vous sachiez comment gérer l'efficacité et les performances de votre cache.

Avantage au niveau de la question : votre application peut montrer des signes de lenteur des performances. Votre capacité à utiliser des métriques spécifiques au cache pour prendre des décisions éclairées quant à la manière d'améliorer les performances des applications est essentielle pour la charge de travail de votre cache.

  • [Obligatoire] Mesurez et suivez au fil du temps le taux d'accès au cache. L'efficacité de votre cache est déterminée par son « taux d'accès au cache ». Le taux d'accès au cache est défini par le nombre total d’accès à une clé divisé par le nombre total d’accès et d’échecs. Plus le taux est proche de 1, plus votre cache est efficace. Un faible taux d'accès au cache est dû au volume d'échecs d’accès au cache. Les échecs d’accès au cache se produisent lorsque la clé demandée n'est pas trouvée dans le cache. Une clé est introuvable dans le cache, car elle a été expulsée ou supprimée, a expiré ou n'a jamais existé. Déterminez pourquoi les clés ne figurent pas dans le cache et développez des stratégies appropriées pour les conserver dans le cache.

    [Ressources] :

  • [Obligatoire] Mesurez et collectez les performances du cache de votre application en conjonction avec les valeurs de latence et d'CPUutilisation pour déterminer si vous devez apporter des modifications à vos composants time-to-live ou à d'autres composants de l'application. ElastiCache fournit un ensemble de CloudWatch mesures pour les latences agrégées pour chaque structure de données. Ces mesures de latence sont calculées à l'aide des statistiques commandstats de la INFO commande ElastiCache (RedisOSS) et n'incluent ni le réseau ni le temps d'E/S. Il s'agit uniquement du temps utilisé par ElastiCache (RedisOSS) pour traiter les opérations.

    [Ressources] :

  • [Meilleure pratique] Choisissez la stratégie de mise en cache adaptée à vos besoins. Un faible taux d'accès au cache est dû au volume d'échecs d’accès au cache. Si votre charge de travail est conçue pour présenter un faible volume d’échecs d’accès au cache (telles que les communications en temps réel), il est préférable de passer en revue vos stratégies de mise en cache et d'appliquer les résolutions les plus appropriées à votre charge de travail, telles que l'instrumentation des requêtes pour mesurer la mémoire et les performances. Les stratégies réelles que vous mettez en œuvre pour remplir et assurer la maintenance de votre cache dépendent des données que vos clients ont besoin de mettre en cache et des modèles d'accès à ces données. Par exemple, il est peu probable que vous utilisiez la même stratégie à la fois pour les recommandations personnalisées sur une application de streaming et pour les actualités tendances.

    [Ressources] :

EP 4 : Comment votre charge de travail optimise-t-elle l'utilisation des ressources de mise en réseau et des connexions ?

Introduction au niveau des questions : ElastiCache (RedisOSS) et ElastiCache (Memcached) sont pris en charge par de nombreux clients d'applications, et les implémentations peuvent varier. Vous devez comprendre la gestion de la mise en réseau et des connexions en place pour analyser l'impact potentiel sur les performances.

Avantage au niveau de la question : une utilisation efficace des ressources de mise en réseau peut améliorer l'efficacité des performances de votre cluster. Les recommandations suivantes peuvent réduire les demandes de mise en réseau et améliorer la latence et le débit du cluster.

  • [Obligatoire] Gérez les connexions à votre ElastiCache cluster de manière proactive.

    • Le regroupement des connexions dans l'application réduit la surcharge sur le cluster créée par l'ouverture et la fermeture de connexions. Surveillez le comportement de connexion sur Amazon à CloudWatch l'aide CurrConnections de etNewConnections.

    • Évitez les fuites de connexion en fermant correctement les connexions client, le cas échéant. Les stratégies de gestion des connexions consistent notamment à fermer correctement les connexions qui ne sont pas utilisées et à définir des délais d'expiration de connexion.

    • Pour les charges de travail Memcached, il existe une quantité configurable de mémoire réservée à la gestion des connexions appelée memcached_connections_overhead.

  • [Pratique encore meilleure] Compressez les objets volumineux pour réduire la mémoire et améliorer le débit du réseau.

    • La compression des données peut réduire le débit réseau requis (Gbit/s), mais augmente la charge de travail de l'application pour compresser et décompresser les données.

    • La compression réduit également la quantité de mémoire consommée par les touches.

    • En fonction des besoins de votre application, trouvez le juste équilibre entre le taux de compression et la vitesse de compression.

  • [Ressources] :

EP 5 : Comment gérez-vous la suppression et/ou l'expulsion de clés ?

Introduction au niveau des questions : les charges de travail ont des exigences et un comportement attendu différents lorsqu'un nœud de cluster approche des limites de consommation de mémoire. ElastiCache (RedisOSS) applique différentes politiques pour gérer ces situations.

Avantage au niveau de la question : une gestion appropriée de la mémoire disponible et la compréhension des politiques d’expulsion permettent de prendre conscience du comportement du cluster lorsque les limites de mémoire de l'instance sont dépassées.

  • [Obligatoire] Instrumentez l'accès aux données pour déterminer la politique à appliquer. Identifiez une politique de mémoire maximale appropriée pour contrôler si et comment les expulsions sont effectuées sur le cluster.

    • L'expulsion se produit lorsque la mémoire maximale du cluster est consommée et qu'une politique est en place pour autoriser l'expulsion. Le comportement du cluster dans cette situation dépend de la politique d'expulsion spécifiée. Cette politique peut être gérée à l'aide maxmemory-policy du groupe de paramètres du cluster ElastiCache (RedisOSS).

    • La politique par défaut volatile-lru libère de la mémoire en expulsant les clés dont le délai d'expiration (TTLvaleur) est défini. Les politiques les moins fréquemment utilisées (LFU) et les politiques les moins récemment utilisées (LRU) suppriment les clés en fonction de leur utilisation.

    • Pour les charges de travail Memcached, une LRU politique par défaut est en place pour contrôler les expulsions sur chaque nœud. Le nombre d'expulsions sur votre ElastiCache cluster Amazon peut être surveillé à l'aide de la métrique Expulsions sur Amazon. CloudWatch

  • [Pratique encore meilleure] Normalisez le comportement de suppression de sorte à contrôler l'impact sur les performances de votre cluster afin d'éviter les goulets d'étranglement inattendus en matière de performances.

    • Pour les charges de travail ElastiCache (RedisOSS), lorsque vous supprimez explicitement des clés du cluster, cela UNLINK revient à supprimer les DEL clés spécifiées. Cependant, la commande effectue la récupération de mémoire proprement dite dans un thread différent, de sorte qu'elle ne bloque pas, contrairement à DEL. La suppression proprement dite se fera ultérieurement de manière asynchrone.

    • Pour les charges de travail ElastiCache (RedisOSS) 6.x, le comportement de la DEL commande peut être modifié dans le groupe de paramètres à l'aide du paramètre. lazyfree-lazy-user-del

  • [Ressources] :

PE 6 : Comment modélisez-vous les données et interagissez-vous avec celles-ci ElastiCache ?

Introduction au niveau des questions : ElastiCache dépend fortement de l'application des structures de données et du modèle de données utilisés, mais elle doit également prendre en compte le magasin de données sous-jacent (le cas échéant). Comprenez les structures de données ElastiCache (RedisOSS) disponibles et assurez-vous d'utiliser les structures de données les mieux adaptées à vos besoins.

Avantage au niveau des questions : la modélisation des données ElastiCache comporte plusieurs couches, notamment les cas d'utilisation des applications, les types de données et les relations entre les éléments de données. De plus, chaque type de données et chaque commande ElastiCache (RedisOSS) ont leurs propres signatures de performance bien documentées.

  • [Meilleure pratique] L'une des meilleures pratiques consiste à réduire la réécriture involontaire de données. Utilisez une convention de dénomination qui minimise le chevauchement des noms de clé. La dénomination conventionnelle de vos structures de données utilise une méthode hiérarchique telle que : APPNAME:CONTEXT:ID, par exemple : ORDER-APP:CUSTOMER:123.

    [Ressources] :

  • Les commandes [Best] ElastiCache (RedisOSS) ont une complexité temporelle définie par la notation Big O. La complexité temporelle d'une commande est une représentation algorithmique/mathématique de son impact. Lorsque vous introduisez un nouveau type de données dans votre application, vous devez examiner attentivement la complexité temporelle des commandes associées. Les commandes dont la complexité temporelle est O(1) sont constantes dans le temps et ne dépendent pas de la taille de l'entrée. Toutefois, les commandes dont la complexité temporelle est O(N) sont linéaires dans le temps et dépendent de la taille de l'entrée. En raison de la conception monothread de ElastiCache (RedisOSS), un volume important d'opérations complexes dans le temps se traduira par une baisse des performances et des délais d'exécution potentiels.

    [Ressources] :

  • [Idéal] APIs À utiliser pour gagner en GUI visibilité sur le modèle de données de votre cluster.

    [Ressources] :

PE 7 : Comment enregistrez-vous les commandes lentes dans votre ElastiCache cluster Amazon ?

Introduction au niveau de la question : l’optimisation des performances bénéficie à la capture, l'agrégation et la notification des commandes de longue durée. En comprenant le temps nécessaire à l'exécution des commandes, vous pouvez déterminer les commandes qui nuisent aux performances et celles qui empêchent le moteur de fonctionner de manière optimale. ElastiCache (RedisOSS) a également la capacité de transmettre ces informations à Amazon CloudWatch ou Amazon Kinesis Data Firehose.

Avantage au niveau de la question : la journalisation dans un emplacement permanent dédié et la fourniture d'événements de notification pour les commandes lentes peuvent faciliter l'analyse détaillée des performances et peuvent être utilisées pour déclencher des événements automatisés.

  • [Obligatoire] Amazon ElastiCache (RedisOSS) exécute la version 6.0 du moteur ou une version plus récente, groupe de paramètres correctement configuré et SLOWLOG journalisation activée sur le cluster.

    • Les paramètres requis ne sont disponibles que lorsque la compatibilité des versions du moteur est définie sur Valkey 7.2 ou version ultérieure, ou sur Redis OSS version 6.0 ou supérieure.

    • SLOWLOGla journalisation se produit lorsque le temps d'exécution d'une commande par le serveur est supérieur à une valeur spécifiée. Le comportement du cluster dépend des paramètres du groupe de paramètres associés, qui sont slowlog-log-slower-than et slowlog-max-len.

    • Les modifications prennent effet immédiatement.

  • [Mieux] Tirez parti des fonctionnalités de CloudWatch Kinesis Data Firehose.

    • Utilisez les fonctionnalités de filtrage et d'alarme de CloudWatch CloudWatch Logs Insights et Amazon Simple Notification Services pour surveiller les performances et notifier les événements.

    • Utilisez les fonctionnalités de streaming de Kinesis Data Firehose SLOWLOG pour archiver les journaux dans un espace de stockage permanent ou pour déclencher le réglage automatique des paramètres du cluster.

    • Déterminez si JSON le TEXT format brut répond le mieux à vos besoins.

    • Donnez IAM les autorisations de publication sur Kinesis Data CloudWatch Firehose ou sur Kinesis Data Firehose.

  • [Pratique encore meilleure] Définissez slowlog-log-slower-than sur une valeur autre que la valeur par défaut.

    • Ce paramètre détermine la durée pendant laquelle une commande peut être exécutée dans le OSS moteur Valkey ou Redis avant d'être enregistrée en tant que commande lente. La valeur par défaut est 10 000 microsecondes (10 millisecondes). La valeur par défaut est peut-être trop élevée pour certaines charges de travail.

    • Déterminez une valeur plus adaptée à votre charge de travail en fonction des besoins de l'application et des résultats des tests ; toutefois, une valeur trop faible peut générer un volume de données excessif.

  • [Pratique encore meilleure]  Conservez slowlog-max-len comme valeur par défaut.

    • Ce paramètre détermine la limite supérieure du nombre de commandes lentes capturées dans la OSS mémoire Valkey ou Redis à un moment donné. La valeur 0 désactive effectivement la capture. Plus la valeur est élevée, plus le nombre d'entrées stockées en mémoire est élevé, ce qui réduit le risque d’expulsion d’informations importantes avant qu’elles aient pu être consultées. La valeur par défaut est 128.

    • La valeur par défaut convient à la plupart des charges de travail. S'il est nécessaire d'analyser les données dans une fenêtre temporelle étendue depuis le valkey-cli via la SLOWLOG commande, envisagez d'augmenter cette valeur. Cela permet à davantage de commandes de rester dans la mémoire de Valkey ou RedisOSS.

      Si vous envoyez les SLOWLOG données vers CloudWatch Logs ou Kinesis Data Firehose, elles seront conservées et pourront être analysées en dehors du système, ce qui réduit le besoin ElastiCache de stocker un grand nombre de commandes lentes dans la mémoire Valkey ou Redis. OSS

  • [Ressources] :

PE8: Comment Auto Scaling contribue-t-il à améliorer les performances du ElastiCache cluster ?

Introduction au niveau des questions : en implémentant la fonctionnalité de mise à l'échelle OSS automatique de Valkey ou Redis, vos ElastiCache composants peuvent s'ajuster au fil du temps pour augmenter ou diminuer automatiquement les fragments ou les répliques souhaités. Pour ce faire, vous pouvez implémenter le suivi des cibles ou une politique de mise à l’échelle planifiée.

Avantage au niveau des questions : la compréhension et la planification des pics de charge de travail peuvent garantir des performances de mise en cache améliorées et la continuité des activités. ElastiCache (RedisOSS) Auto Scaling surveille en permanence l'utilisation de votre CPU /Memory pour s'assurer que votre cluster fonctionne aux niveaux de performance souhaités.

  • [Obligatoire] Lors du lancement d'un cluster pour ElastiCache (RedisOSS) :

    1. Assurez-vous que le mode Cluster est activé.

    2. Assurez-vous que l'instance appartient à une famille d'un certain type et d'une certaine taille qui prend en charge l’autoscaling.

    3. Assurez-vous que le cluster ne s'exécute pas dans des entrepôts de données globaux, des outposts  ou des zones locales.

    [Ressources] :

  • [Meilleure pratique] Déterminez si votre charge de travail est à lecture ou à écriture intensive pour définir une politique de mise à l’échelle. Pour de meilleures performances, utilisez une seule métrique de suivi. Il est recommandé de ne pas appliquer plusieurs politiques à chaque dimension. En effet, les stratégies d’autoscaling montent en puissance lorsque la cible est atteinte, mais ne sont mises à l’échelle horizontale que lorsque toutes les politiques de suivi des cibles sont prêtes à être mises à l’échelle horizontale.

    [Ressources] :

  • [Meilleure pratique] La surveillance des performances au fil du temps peut vous aider à détecter les modifications de la charge de travail qui passeraient inaperçues si elles étaient surveillées à un moment donné. Vous pouvez analyser les CloudWatch mesures correspondantes relatives à l'utilisation du cluster sur une période de quatre semaines afin de déterminer le seuil de valeur cible. Si vous n'êtes toujours pas sûr de la valeur à choisir, nous vous recommandons de commencer par une valeur de métrique prédéfinie minimale prise en charge.

    [Ressources] :

  • [Pratique encore meilleure] Il est recommandé de tester votre application avec les charges de travail minimales et maximales attendues, afin d'identifier le nombre exact de partitions/réplicas requis pour que le cluster puisse développer des politiques de mise à l’échelle et atténuer les problèmes de disponibilité.

    [Ressources] :