Fonctionnement de DAX

Amazon DynamoDB Accelerator (DAX) est conçu pour s'exécuter dans un environnement Amazon Virtual Private Cloud (Amazon VPC). Le service Amazon VPC définit un réseau virtuel qui ressemble de près à un centre de données classique. Avec un VPC, vous contrôlez la plage d'adresses IP, les sous-réseaux, les tables de routage, les passerelles réseau et les paramètres de sécurité. Vous pouvez lancer un cluster DAX dans votre réseau privé et contrôler l'accès au cluster à l'aide de groupes de sécurité Amazon VPC.

Note

Si vous avez créé votre compte AWS après le 4 décembre 2013, vous disposez déjà d'un VPC par défaut dans chaque région AWS. Le VPC immédiatement utilisable. Il ne nécessite aucune configuration.

Pour plus d'informations, consultez VPC par défaut et sous-réseaux par défaut dans le Guide de l'utilisateur Amazon VPC.

Le diagramme suivant est une présentation générale de DAX.

Pour créer un cluster DAX, vous devez utiliser l'AWS Management Console. Sauf spécification contraire, votre cluster DAX s'exécute au sein de votre VPC par défaut. Pour exécuter votre application, vous lancez une instance Amazon EC2 dans votre VPC Amazon. Vous déployez ensuite votre application (avec le client DAX) sur l'instance EC2.

Au moment de l'exécution, le client DAX dirige toutes les demandes d'API DynamoDB de votre application vers le cluster DAX. Si DAX peut traiter l'une de ces demandes d'API directement, il le fait. Sinon, il transmet la demande à DynamoDB.

Enfin, le cluster DAX renvoie les résultats à votre application.

Comment DAX traite les demandes

Un cluster DAX est constitué d'un ou plusieurs nœuds. Chaque nœud exécute sa propre instance du logiciel de mise en cache DAX. L'un des nœuds sert de nœud principal pour le cluster. Les autres nœuds éventuels servent de réplicas en lecture. Pour plus d'informations, consultez Nœuds.

Votre application peut accéder à DAX en spécifiant le point de terminaison du cluster DAX. Le logiciel client DAX utilise le point de terminaison du cluster pour effectuer un équilibrage de charge et un routage intelligents.

Opérations de lecture

DAX peut répondre aux appels d'API suivants :

• GetItem

• BatchGetItem

• Query

• Scan

Si la demande spécifie des lectures éventuellement cohérentes (comportement par défaut), elle tente de lire l'élément à partir de par défaut :

• Si l'élément est disponible dans DAX (accès au cache), DAX le renvoie à l'application sans accéder à DynamoDB.

• Si l'élément n'est pas disponible dans DAX (échec d'accès au cache), DAX transmet la demande à DynamoDB. Après réception de la réponse de DynamoDB, DAX renvoie les résultats à l'application. Mais les résultats sont aussi écrits dans le cache sur le nœud principal.

Note

S'il existe des réplicas en lecture dans le cluster, DAX assure automatiquement leur synchronisation avec le nœud principal. Pour plus d'informations, consultez Clusters.

Si la demande spécifie des lectures fortement cohérentes, DAX transmet la demande à DynamoDB. Les résultats de DynamoDB ne sont pas mis en cache dans DAX. Ils sont à la place retournés à l'application.

Opérations d'écriture

Les opérations d'API DAX suivantes sont considérées comme des opérations d'« écriture simultanée » :

• BatchWriteItem

• UpdateItem

• DeleteItem

• PutItem

Avec ces opérations, les données sont d'abord écrites dans la table DynamoDB, puis dans le cluster DAX. L'opération ne réussit que si les données sont correctement écrites tant dans la table que dans DAX.

Autres opérations

DAX ne reconnaît pas les opérations DynamoDB pour la gestion des tables (telles que CreateTable, UpdateTable, etc.). Si votre application a besoin d'effectuer ces opérations, elle doit accéder directement à DynamoDB au lieu d'utiliser DAX.

Pour plus d'informations sur la cohérence entre DAX et DynamoDB, consultez Modèles de cohérence DAX et DynamoDB.

Pour plus d'informations sur le fonctionnement des transactions dans DAX, consultez Utilisation d'API transactionnelles dans DynamoDB Accelerator (DAX).

Limitation du débit de demande

Si le nombre de requêtes envoyées à DAX dépasse la capacité d'un nœud, DAX limite le rythme d'acceptation des demandes supplémentaires en renvoyant une exception ThrottlingException. DAX évalue en continu l'utilisation de votre UC pour déterminer le volume de demandes qu'elle peut traiter tout en conservant un état de cluster sain.

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

Cache d'élément

DAX gère un cache d'élément pour stocker les résultats des opérations GetItem et BatchGetItem. Les éléments dans le cache représentent des données éventuellement cohérentes de DynamoDB, et sont stockés sur la base de leurs valeurs de clé primaire.

Quand une application envoie une demande GetItem ou BatchGetItem, DAX tente de lire les éléments directement dans le cache d'élément à partir des valeurs de clé spécifiées. Si les éléments sont trouvés (accès au cache), DAX les renvoie immédiatement à l'application. Si les éléments ne sont pas trouvés (échec d'accès au cache), DAX envoie la demande à DynamoDB. DynamoDB traite les demandes en utilisant des lectures éventuellement cohérentes et renvoie les éléments à DAX. DAX les stocke dans le cache d'éléments, puis les renvoie à l'application.

Le cache d'éléments dispose d'un paramètre de time-to-live (TTL) dont la valeur par défaut est de 5 minutes. DAX assigne un horodatage à chaque élément qu'il écrit dans le cache d'éléments. Un élément expire s'il reste dans le cache plus longtemps que la durée de vie définie. Une demande GetItem émise sur un élément expiré est considérée comme un échec d'accès au cache, et DAX envoie la demande GetItem à DynamoDB.

Note

Vous pouvez spécifier le paramètre de durée de vie (TTL) pour le cache d'éléments lorsque vous créez un cluster DAX. Pour plus d'informations, consultez Gestion des clusters DAX .

DAX gère par ailleurs une liste LRU (moins récemment utilisé) pour le cache d'éléments. La liste LRU garde une trace du moment où un élément est écrit pour la première fois dans le cache et du moment où il est lu pour la dernière fois dans le cache. Si le cache d'éléments arrive à saturation, 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é pour le cache d'élément et ne peut pas être configuré par l'utilisateur.

Si vous spécifiez zéro comme paramètre TTL du cache d'éléments, les éléments figurant dans celui-ci ne sont actualisés que suite à une expulsion LRU ou à une opération d'« écriture simultanée ».

Pour plus d'informations sur la cohérence du cache d'éléments dans DAX, consultez Comportement du cache d'éléments DAX.

Cache de requête

DAX gère également un cache de requêtes pour stocker les résultats des opérations Query et Scan. Les éléments figurant dans ce cache représentent les jeux de résultats des requêtes et des analyses effectuées sur les tables DynamoDB. Ces jeux de résultats sont stockées en fonction des valeurs de leurs paramètres.

Quand une application envoie une demande Query ou Scan, DAX tente de lire un ensemble de résultats correspondant à partir du cache de requêtes à l'aide des valeurs de paramètres spécifiées. Si le jeu de résultats est trouvé (correspondance dans le cache), le retourne immédiatement à l'application. Si l'ensemble de résultats n'est pas trouvé (échec d'accès au cache), DAX envoie la demande à DynamoDB. DynamoDB traite les demandes en utilisant des lectures éventuellement cohérentes et renvoie l'ensemble de résultats à DAX. DAX stocke celui-ci dans le cache de requêtes, puis le renvoie à l'application.

Note

Vous pouvez spécifier le paramètre de time-to-live (TTL) pour le cache de requêtes lorsque vous créez un cluster DAX. Pour plus d'informations, consultez Gestion des clusters DAX .

DAX conserve aussi une liste LRU pour le cache de requêtes. La liste LRU garde une trace du moment où un jeu de résultats est écrit pour la première fois dans le cache et du moment où il est lu pour la dernière fois dans le cache. Si le cache de requêtes arrive à saturation, DAX expulse les anciens ensembles de résultats (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é pour le cache de requête et ne peut pas être configuré par l'utilisateur.

Si vous spécifiez zéro comme paramètre TTL de cache de requêtes, la réponse à la requête n'est pas mise en cache.

Pour plus d'informations sur la cohérence du cache de requêtes dans DAX, consultez Comportement du cache de requêtes DAX.