Configuration de votre cluster DAX
Le cluster DAX est un cluster géré, mais vous pouvez ajuster ses configurations en fonction des exigences de votre application. En raison de son étroite intégration avec les opérations de l’API DynamoDB, vous devez prendre en compte les aspects suivants lors de l’intégration de votre application à DAX.
Dans cette section
Tarification de DAX
Le coût d’un cluster dépend du nombre et de la taille des nœuds qu’il a provisionnés. Chaque nœud est facturé pour chaque heure d’exécution dans le cluster. Pour plus d’informations, consultez Tarification Amazon DynamoDB
Les accès au cache n’entraînent aucun coût pour DynamoDB, mais ont un impact sur les ressources du cluster DAX. Les erreurs de cache entraînent des coûts de lecture DynamoDB et nécessitent des ressources DAX. Les écritures entraînent des coûts d’écriture DynamoDB et ont un impact sur les ressources du cluster DAX pour l’utilisation du proxy sur l’écriture.
Cache d’éléments et cache de requêtes
DAX maintient un cache d’éléments et un cache de requêtes. Le fait de comprendre les différences entre ces caches peut vous aider à déterminer les caractéristiques de performance et de cohérence qu’ils offrent à votre application.
| Caractéristiques du cache | Cache d’élément | Cache de requête |
|---|---|---|
|
Objectif |
Stocke les résultats des opérations d’API GetItem et BatchGetItem. |
Stocke les résultats des opérations d’API Query et Scan. Ces opérations peuvent renvoyer plusieurs éléments en fonction des conditions de requête au lieu de clés d’éléments spécifiques. |
|
Type d’accès |
Utilise un accès basé sur les clés. Lorsqu’une application demande des données en utilisant |
Utilise un accès basé sur un paramètre. DAX met en cache le jeu de résultats de |
|
Invalidation du cache |
DAX réplique automatiquement les éléments mis à jour dans le cache d’éléments des nœuds du cluster DAX dans les scénarios suivants :
|
Le cache de requêtes est plus difficile à invalider que le cache d’éléments. Les mises à jour des éléments peuvent ne pas mapper directement aux requêtes ou aux analyses mises en cache. Vous devez régler avec soin la TTL du cache de requêtes pour garantir la cohérence des données. Les écritures via DAX ou la table de base ne sont pas reflétées dans le cache de requêtes tant que la TTL ne fait pas expirer la réponse précédemment mise en cache et que DAX n’exécute pas une nouvelle requête sur DynamoDB. |
|
GSI |
Comme l’opération d’API GetItem n’est pas prise en charge sur les index secondaires locaux ou les index secondaires globaux, le cache d’éléments met uniquement en cache les lectures de la table de base. |
Le cache de requêtes met en cache les requêtes portant à la fois sur les tables et sur les index. |
Sélection du paramètre TTL pour les caches
La TTL détermine la période pendant laquelle les données sont stockées dans le cache avant de devenir obsolètes. Après cette période, les données sont automatiquement actualisées lors de la prochaine demande. Pour choisir le bon paramètre TTL pour vos caches DAX, vous devez trouver un équilibre entre l’optimisation des performances des applications et la cohérence des données. Comme il n’existe pas de paramètre TTL universel qui fonctionne pour toutes les applications, le paramètre TTL optimal varie en fonction des caractéristiques et des exigences spécifiques de votre application. Nous vous conseillons de commencer avec un paramètre TTL prudent, en suivant ces recommandations. Ajustez ensuite de manière itérative votre paramètre TTL en fonction des données de performance et des informations de votre application.
DAX gère une liste LRU (moins récemment utilisé) pour le cache d’éléments. La liste LRU indique le moment où les éléments ont été écrits pour la première fois ou lus pour la dernière fois depuis le cache. Si la mémoire du nœud DAX est pleine, DAX expulse les anciens éléments même s’ils n’ont pas encore expiré, afin de ménager de la place pour les nouveaux. L’algorithme LRU est toujours activé et ne peut pas être configuré par l’utilisateur.
Pour définir une durée TTL adaptée à vos applications, tenez compte des points suivants :
Compréhension de vos modèles d’accès aux données
-
Charges de travail intensives en lecture : pour les applications présentant des charges de travail lourdes en lecture et des mises à jour de données peu fréquentes, définissez une durée TTL plus longue afin de réduire le nombre d’erreurs de cache. Une durée TTL plus longue réduit également le besoin d’accéder à la table DynamoDB sous-jacente.
-
Charges de travail intensives en écriture : pour les applications soumises à des mises à jour fréquentes qui ne sont pas écrites via DAX, définissez une durée TTL plus courte afin de garantir la cohérence du cache avec la base de données. Une durée TTL plus courte réduit également le risque de diffusion de données périmées.
Évaluation des exigences de performance de votre application
-
Sensibilité à la latence : si votre application nécessite une faible latence par rapport à la fraîcheur des données, utilisez une durée TTL plus longue. Une durée TTL plus longue optimise les accès au cache, ce qui réduit la latence de lecture moyenne.
-
Débit et capacité de mise à l’échelle : une durée TTL plus longue réduit la charge sur les tables DynamoDB et améliore le débit et la capacité de mise à l’échelle. Cependant, vous devez trouver un équilibre entre cela et le besoin de données à jour.
Analyse de l’éviction du cache et de l’utilisation de la mémoire
-
Limites de mémoire cache : surveillez l’utilisation de la mémoire de votre cluster DAX. Une durée TTL plus longue peut stocker davantage de données dans le cache, ce qui peut atteindre les limites de mémoire et entraîner des évictions basées sur des LRU.
Utilisation des métriques et de la surveillance pour ajuster la TTL
Passez régulièrement en revue les métriques, par exemple les accès et les échecs du cache, ainsi que l’utilisation du processeur et de la mémoire. Ajustez votre paramètre TTL en fonction de ces métriques afin de trouver un équilibre optimal entre les performances et l’actualisation des données. Si les erreurs de cache sont importantes et que l’utilisation de la mémoire est faible, augmentez la durée TTL pour augmenter le taux d’accès au cache.
Tenez compte des exigences commerciales et de la conformité
Les politiques de conservation des données peuvent dicter la durée TTL maximale que vous pouvez définir pour les informations sensibles ou personnelles.
Comportement du cache si vous définissez TTL sur zéro
Si vous définissez TTL sur 0, le cache d’éléments et le cache de requêtes présentent les comportements suivants :
-
Cache d’éléments : les éléments du cache sont actualisés uniquement en cas d’éviction du LRU ou d’une opération d’écriture simultanée.
-
Cache de requêtes : les réponses aux requêtes ne sont pas mises en cache.
Mise en cache de plusieurs tables avec un cluster DAX
Pour les charges de travail comportant plusieurs petites tables DynamoDB qui ne nécessitent pas de caches individuels, un seul cluster DAX met en cache les demandes relatives à ces tables. Cela permet une utilisation plus flexible et plus efficace de DAX, en particulier pour les applications qui accèdent à plusieurs tables et nécessitent des lectures hautes performances.
À l’instar des API du plan de données DynamoDB, les requêtes DAX nécessitent un nom de table. Si vous utilisez plusieurs tables dans le même cluster DAX, aucune configuration spécifique n’est nécessaire. Cependant, vous devez vous assurer que les autorisations de sécurité du cluster autorisent l’accès à toutes les tables mises en cache.
Considérations relatives à l’utilisation de DAX avec plusieurs tables
Lorsque vous utilisez DAX avec plusieurs tables DynamoDB, vous devez tenir compte des points suivants :
-
Gestion de la mémoire : lorsque vous utilisez DAX avec plusieurs tables, vous devez tenir compte de la taille totale de votre jeu de données de travail. Toutes les tables de votre jeu de données partageront le même espace mémoire que le type de nœud que vous avez sélectionné.
-
Allocation de ressources : les ressources du cluster DAX sont partagées entre toutes les tables mises en cache. Cependant, une table à trafic élevé peut entraîner l’éviction des données des tables plus petites voisines.
-
Économies d’échelle : regroupez les petites ressources dans un cluster DAX plus grand afin de répartir le trafic sortant selon un schéma plus stable. Pour le nombre total de ressources de lecture dont le cluster DAX a besoin, il est également économique de disposer de trois nœuds ou plus. Cela augmente également la disponibilité de toutes les tables mises en cache dans le cluster.
Réplication des données dans les tables globales DAX et DynamoDB
DAX est un service basé sur une région, de sorte qu’un cluster ne connaît que le trafic au sein de sa Région AWS. Les tables globales contournent le cache lorsqu’elles répliquent des données d’une autre région.
Avec une durée de TTL plus longue, les données périmées peuvent rester plus longtemps dans votre région secondaire que dans la région principale. Cela peut entraîner des erreurs de cache dans le cache local de la région secondaire.
Le schéma suivant montre la réplication des données qui se produit au niveau de la table globale dans la région source A. Le cluster DAX de la région B ne connaît pas immédiatement les données récemment répliquées à partir de la région source A.
Disponibilité de région DAX
Les régions qui prennent en charge les tables DynamoDB ne prennent pas toutes en charge le déploiement de clusters DAX. Si votre application nécessite une faible latence de lecture via DAX, consultez d’abord la liste des régions qui prennent en charge DAX. Sélectionnez ensuite une région pour votre table DynamoDB.
Comportement de mise en cache DAX
DAX effectue une mise en cache des métadonnées et négative. La compréhension de ces comportements de mise en cache vous aidera à gérer efficacement les métadonnées d’attribut des éléments mis en cache et des entrées de cache négatives.
-
Mise en cache des métadonnées : les clusters DAX conservent indéfiniment les métadonnées sur les noms d’attribut des éléments mis en cache. Ces métadonnées sont conservées même après l’expiration de l’élément ou son éviction du cache.
Au fil du temps, les applications qui utilisent un nombre illimité de noms d’attributs peuvent entraîner un épuisement de la mémoire du cluster DAX. Cette limitation s’applique uniquement aux noms d’attributs de niveau supérieur, mais pas aux noms d’attributs imbriqués. Citons comme exemple de noms d’attributs illimités les horodatages, les UUID et les ID de session. Bien que vous puissiez utiliser des horodatages et des identifiants de session comme valeurs d’attribut, nous vous recommandons d’utiliser des noms d’attributs plus courts et plus prévisibles.
-
Mise en cache négative : si une erreur de cache se produit et que la lecture d’une table DynamoDB ne produit aucun élément correspondant, DAX ajoute une entrée de cache négative dans le cache d’éléments ou de requêtes correspondant. Cette entrée est conservée jusqu’à ce que la durée TTL du cache expire ou qu’une écriture simultanée soit effectuée. DAX continue de renvoyer cette entrée de cache négative pour les demandes futures.
Si le comportement de mise en cache négatif ne correspond pas au modèle de votre application, lisez la table DynamoDB directement lorsque DAX renvoie un résultat vide. Nous vous recommandons également de définir une durée de cache TTL inférieure afin d’éviter des résultats vides persistants dans le cache et d’améliorer la cohérence avec la table.
