Gestion des clusters DAX - Amazon DynamoDB

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.

Gestion des clusters DAX

Cette section traite de certaines des tâches de gestion courantes pour les clusters Amazon DynamoDB Accelerator (DAX).

Autorisations IAM pour gérer un cluster DAX

Lorsque vous administrez un cluster DAX à l'aide du AWS Management Console ou du AWS Command Line Interface (AWS CLI), nous vous recommandons vivement de limiter le champ des actions que les utilisateurs peuvent effectuer. Vous limiterez ainsi les risques tout en suivant le principe du moindre privilège.

La discussion suivante se concentre sur le contrôle d'accès pour les API de gestion DAX. Pour plus d'informations, consultez Amazon DynamoDB accelerator dans la Référence d'API Amazon DynamoDB.

Note

Pour des informations plus détaillées sur la gestion des autorisations AWS Identity and Access Management (IAM), consultez les rubriques suivantes :

Pour les API de gestion DAX, vous ne pouvez pas limiter des actions d'API à une ressource spécifique. L'élément Resource doit être défini sur "*". Cela diffère des opérations d'API de plan de données DAX, telles que GetItem, Query et Scan. Les opérations de plan de données sont exposées via le client DAX, et ces opérations peuvent être limitées à des ressources spécifiques.

A titre d'illustration, prenez en compte le document de politique IAM suivant.

{ "Version": "2012-10-17", "Statement": [ { "Action": [ "dax:*" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ] } ] }

Supposons que le but de cette politique soit d'autoriser les appels d'API de gestion DAX pour le cluster DAXCluster01, et uniquement pour ce cluster.

Supposons maintenant qu'un utilisateur émette la AWS CLI commande suivante.

aws dax describe-clusters

Cette commande échouera avec une exception Not Authorized (Non autorisé), car l'appel d'API DescribeClusters sous-jacent ne peut pas être attribué à un cluster spécifique. Bien que la stratégie soit valide au niveau de la syntaxe, la commande échoue car l'élément Resource doit être défini sur "*". Cependant, si l'utilisateur exécute un programme qui envoie des appels de plan de données DAX (tels que GetItem ou Query) à DAXCluster01, ces appels aboutissent. En effet, les API de plan de données DAX peuvent être limitées à des ressources spécifiques (dans ce cas, DAXCluster01).

Si vous souhaitez écrire une seule politique IAM complète regroupant à la fois des API de gestion DAX et des API de plan de données DAX, nous vous suggérons d'inclure deux instructions distinctes dans le document de politique. L'une de ces instructions doit traiter des API de plan de données DAX, tandis que l'autre traite des API de gestion DAX.

L'exemple de stratégie ci-dessous montre cette approche. Notez que l'instruction DAXDataAPIs est attribuée à la ressource DAXCluster01, mais la ressource pour DAXManagementAPIs doit être "*". Les actions affichées dans chaque instruction ne le sont qu'à titre d'illustration. Vous pouvez personnaliser ces ressources en fonction des besoins de votre application.

{ "Version": "2012-10-17", "Statement": [ { "Sid": "DAXDataAPIs", "Action": [ "dax:GetItem", "dax:BatchGetItem", "dax:Query", "dax:Scan", "dax:PutItem", "dax:UpdateItem", "dax:DeleteItem", "dax:BatchWriteItem" ], "Effect": "Allow", "Resource": [ "arn:aws:dax:us-west-2:123456789012:cache/DAXCluster01" ]}, { "Sid": "DAXManagementAPIs", "Action": [ "dax:CreateParameterGroup", "dax:CreateSubnetGroup", "dax:DecreaseReplicationFactor", "dax:DeleteCluster", "dax:DeleteParameterGroup", "dax:DeleteSubnetGroup", "dax:DescribeClusters", "dax:DescribeDefaultParameters", "dax:DescribeEvents", "dax:DescribeParameterGroups", "dax:DescribeParameters", "dax:DescribeSubnetGroups", "dax:IncreaseReplicationFactor", "dax:ListTags", "dax:RebootNode", "dax:TagResource", "dax:UntagResource", "dax:UpdateCluster", "dax:UpdateParameterGroup", "dax:UpdateSubnetGroup" ], "Effect": "Allow", "Resource": [ "*" ] } ] }

Mise à l'échelle d'un cluster DAX

Les options disponibles pour la mise à l'échelle d'un cluster DAX sont au nombre de deux. La première option correspond au dimensionnement horizontal, qui consiste à ajouter des réplicas en lecture au cluster. La deuxième option est la mise à l'échelle verticale, où vous sélectionnez différents types de nœuds. Pour obtenir des conseils sur la façon de choisir une taille de cluster et un type de nœud appropriés pour votre application, veuillez consulter Guide de dimensionnement de cluster DAX.

Mise à l'échelle horizontale

Avec la mise à l'échelle horizontale, vous pouvez améliorer le débit des opérations de lecture en ajoutant davantage de réplicas en lecture au cluster. Un même cluster DAX prend en charge jusqu'à 10 réplicas en lecture, et vous pouvez ajouter ou supprimer des réplicas pendant que le cluster s'exécute.

Lorsque vous ajoutez un nouveau nœud, vous devez synchroniser les données du cache à partir d'un nœud homologue. Par conséquent, le délai supplémentaire varie en fonction de la taille du cache et de la charge de travail de votre application. En tant que bonne pratique, nous vous recommandons de prédimensionner votre cluster pour répondre aux pics de trafic attendus. Pour plus d'informations sur les directives relatives au dimensionnement correct et aux recommandations de surveillance, voir. Guide de dimensionnement de cluster DAX

Les AWS CLI exemples suivants montrent comment augmenter ou diminuer le nombre de nœuds. L'argument --new-replication-factor spécifie le nombre total de nœuds du cluster. L'un des nœuds est le nœud principal et les autres nœuds sont des réplicas en lecture.

aws dax increase-replication-factor \ --cluster-name MyNewCluster \ --new-replication-factor 5
aws dax decrease-replication-factor \ --cluster-name MyNewCluster \ --new-replication-factor 3
Note

Le statut du cluster passe à modifying lorsque vous modifiez le facteur de réplication. Le statut devient available lorsque la modification est terminée.

Mise à l'échelle verticale

Si vous disposez d'un ensemble de données actif volumineux, l'utilisation de types de nœuds plus grands peut s'avérer bénéfique pour votre application. En effet, les nœuds de grande taille peuvent conférer au cluster une plus grande capacité de stockage de données en mémoire, ce qui limite les échecs de cache et améliore les performances globales de l'application. (Tous les nœuds dans un cluster DAX doivent être du même type.)

Si votre cluster DAX présente un taux élevé d'échecs d'opérations d'écriture ou de cache, il se peut que votre application bénéficie également de l'utilisation de types de nœuds plus importants. Les opérations d'écriture et les échecs de cache consomment des ressources sur le nœud principal du cluster. Par conséquent, l'utilisation de types de nœuds plus importants peut augmenter les performances du nœud principal et permettre ainsi un débit plus élevé pour ces types d'opérations.

Vous ne pouvez pas modifier les types de nœuds sur un cluster DAX en cours d'exécution. Au lieu de cela, vous devez créer un nouveau cluster avec le type de nœud souhaité. Pour obtenir la liste des types de nœuds pris en charge, consultez Nœuds.

Vous pouvez créer un nouveau cluster DAX à l'aide du AWS Management ConsoleAWS CloudFormation AWS CLI, du ou du AWS SDK. (Pour le AWS CLI, utilisez le --node-type paramètre pour spécifier le type de nœud.)

Personnalisation des paramètres de cluster DAX

Lors de la création d'un cluster DAX, les paramètres par défaut utilisés sont les suivants :

  • Expulsion de cache automatique activée avec un time-to-live (TTL) de 5 minutes

  • Aucune préférence pour les zones de disponibilité

  • Aucune préférence pour les fenêtres de maintenance

  • Notifications désactivées

Pour les nouveaux clusters, vous pouvez personnaliser les paramètres au moment de leur création. Pour ce faire, dans la AWS Management Console, désélectionnez Utiliser les paramètres par défaut pour modifier les paramètres suivants :

  • Réseau et sécurité : vous permet d'exécuter des nœuds de cluster DAX individuels dans différentes zones de disponibilité de la région actuelle AWS . Si vous choisissez Aucune préférence, les nœuds sont répartis automatiquement entre les zones de disponibilité.

  • Parameter Group (Groupe de paramètres) – Ensemble nommé de paramètres appliqués à chaque nœud du cluster. Vous pouvez utiliser un groupe de paramètres pour spécifier le comportement du paramètre de durée de vie (TTL) du cache. Vous pouvez modifier la valeur d'un paramètre donné dans un groupe de paramètres à tout moment (à l'exception de default.dax.1.0 du groupe de paramètres par défaut).

  • Maintenance Window (Fenêtre de maintenance) – Temps hebdomadaire pendant lequel les mises à niveau et les correctifs logiciels sont appliqués aux nœuds du cluster. Vous pouvez choisir le jour de début, l'heure de début et la durée de la fenêtre de maintenance. Si vous choisissez No Preference (Aucune préférence), la fenêtre de maintenance est sélectionnée de façon aléatoire dans une plage de temps de 8 heures par région. Pour plus d’informations, consultez Fenêtre de maintenance.

Note

Le groupe de paramètres et la fenêtre de maintenance peuvent également être modifiés à tout moment sur un cluster en cours d'exécution.

Quand un événement de maintenance se produit, DAX peut vous avertir à l'aide d'Amazon Simple Notification Service (Amazon SNS). Pour configurer les notifications, choisissez une option dans le sélecteur Rubrique pour notification SNS. Vous pouvez créer une rubrique Amazon SNS ou utiliser une rubrique existante.

Pour plus d'informations sur la configuration d'une rubrique Amazon SNS et sur l'abonnement à celle-ci, consultez Mise en route avec Amazon SNS dans le Guide du développeur Amazon Simple Notification Service.

Configuration des paramètres de durée de vie (TTL)

DAX gère deux caches pour les données lues à partir de DynamoDB :

  • Cache d'élément – Pour les éléments extraits à l'aide des opérations GetItem ou BatchGetItem.

  • Cache de requête – Pour les jeux de résultats extraits à l'aide des opérations Query ou Scan.

Pour plus d’informations, consultez Cache d'élément et Cache de requête.

La durée de vie (TTL) par défaut de chacun de ces caches est de 5 minutes. Si vous souhaitez utiliser d'autres paramètres TTL, vous pouvez lancer un cluster DAX en utilisant un groupe de paramètres personnalisés. Pour ce faire, dans la console, choisissez DAX | Groupes de paramètres dans le volet de navigation.

Vous pouvez également effectuer ces tâches à partir de AWS CLI. L'exemple suivant montre comment lancer un nouveau cluster DAX en utilisant un groupe de paramètres personnalisé. Dans cet exemple, la durée de vie (TTL) du cache d'élément définie est de 10 minutes et celle du cache de requête est de 3 minutes.

  1. Créez un groupe de paramètres.

    aws dax create-parameter-group \ --parameter-group-name custom-ttl
  2. Définissez la durée de vie de cache de l'élément sur 10 minutes (600 000 millisecondes).

    aws dax update-parameter-group \ --parameter-group-name custom-ttl \ --parameter-name-values "ParameterName=record-ttl-millis,ParameterValue=600000"
  3. Définissez la durée de vie de cache de la requête sur 3 minutes (180 000 millisecondes).

    aws dax update-parameter-group \ --parameter-group-name custom-ttl \ --parameter-name-values "ParameterName=query-ttl-millis,ParameterValue=180000"
  4. Vérifiez que les paramètres ont été définis correctement.

    aws dax describe-parameters --parameter-group-name custom-ttl \ --query "Parameters[*].[ParameterName,Description,ParameterValue]"

Vous pouvez maintenant lancer un nouveau cluster DAX avec ce groupe de paramètres.

aws dax create-cluster \ --cluster-name MyNewCluster \ --node-type dax.r3.large \ --replication-factor 3 \ --iam-role-arn arn:aws:iam::123456789012:role/DAXServiceRole \ --parameter-group custom-ttl
Note

Vous ne pouvez pas modifier un groupe de paramètres utilisé par une instance DAX en cours d'exécution.

Prise en charge de l'étiquetage pour DAX

De nombreux AWS services, dont DynamoDB, prennent en charge le balisage, c'est-à-dire la possibilité d'étiqueter les ressources avec des noms définis par l'utilisateur. Vous pouvez attribuer des tags aux clusters DAX, ce qui vous permet d'identifier rapidement toutes vos AWS ressources qui ont le même tag, ou de classer vos AWS factures en fonction des tags que vous attribuez.

Pour plus d’informations, consultez Ajout d'identifications et d'étiquettes aux ressources.

À l'aide du AWS Management Console

Pour gérer des étiquettes de cluster DAX
  1. Ouvrez la console DynamoDB à l'adresse https://console.aws.amazon.com/dynamodb/.

  2. Dans le panneau de navigation, sous DAX, choisissez Clusters.

  3. Choisissez le cluster que vous souhaitez utiliser.

  4. Sélectionnez l’onglet Tags (Identifications). Vous pouvez ajouter, répertorier, modifier ou supprimer vos balises ici.

    Lorsque les paramètres vous conviennent, choisissez Apply Changes.

À l'aide du AWS CLI

Lorsque vous utilisez les balises de cluster AWS CLI pour gérer le DAX, vous devez d'abord déterminer le nom de ressource Amazon (ARN) du cluster. L'exemple suivant montre comment déterminer l'ARN pour un cluster nommé MyDAXCluster.

aws dax describe-clusters \ --cluster-name MyDAXCluster \ --query "Clusters[*].ClusterArn"

Dans la sortie, l'ARN ressemblera à ceci : arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

L'exemple suivant montre comment baliser le cluster.

aws dax tag-resource \ --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \ --tags="Key=ClusterUsage,Value=prod"

Affiche toutes les balises d'un cluster.

aws dax list-tags \ --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster

Pour supprimer une balise, vous devez spécifier sa clé.

aws dax untag-resource \ --resource-name arn:aws:dax:us-west-2:123456789012:cache/MyDAXCluster \ --tag-keys ClusterUsage

AWS CloudTrail intégration

DAX est intégré AWS CloudTrail, ce qui vous permet d'auditer les activités du cluster DAX. Vous pouvez utiliser les CloudTrail journaux pour afficher toutes les modifications apportées au niveau du cluster. Vous pouvez aussi afficher les modifications apportées aux composants d'un cluster, tels que nœuds, groupes de sous-réseau et groupes de paramètres. Pour plus d’informations, consultez Journalisation des opérations de DynamoDB à l'aide d' AWS CloudTrail.

Suppression d'un cluster DAX

Si vous n'utilisez plus un cluster DAX, supprimez-le afin d'éviter d'être facturé pour des ressources non utilisées.

Vous pouvez supprimer un cluster DAX à l'aide de la console ou de l' AWS CLI. Voici un exemple.

aws dax delete-cluster --cluster-name mydaxcluster