Q : En quoi consiste Amazon ElastiCache ?

Amazon ElastiCache est un service web qui simplifie le déploiement et l'exécution de nœuds de serveur compatibles avec Memcached ou Redis dans le cloud. Amazon ElastiCache améliore les performances des applications web en vous permettant de récupérer des informations depuis un système en mémoire rapide et géré, au lieu de vous en remettre entièrement à des bases de données lentes basées sur disque. Le service simplifie et décharge la gestion, la surveillance et l'exploitation d'environnements en mémoire, permettant à vos ressources d'ingénierie de se concentrer sur le développement d'applications. En utilisant Amazon ElastiCache, vous pouvez non seulement améliorer les temps de charge et de réponse aux actions et interrogations d'utilisateur, mais aussi réduire le coût associé au redimensionnement d'applications web.

Amazon ElastiCache automatise les tâches administratives courantes nécessaires à l'exploitation d'un environnement clé/valeur distribué. Grâce à Amazon ElastiCache, vous pouvez ajouter une couche de mise en cache ou en mémoire dans votre architecture d'application en seulement quelques minutes, en quelques clics dans l'AWS Management Console. Une fois le cluster mis en service, Amazon ElastiCache détecte et remplace automatiquement les nœuds en échec, fournissant ainsi un système résilient pour diminuer le risque de bases de données surchargées, lesquelles ralentissent les temps de chargement des sites web et applications. Grâce à l'intégration à la surveillance Amazon CloudWatch, Amazon ElastiCache fournit une visibilité améliorée sur les métriques de performance clé associées à vos nœuds. Amazon ElastiCache est conforme aux protocoles Memcached et Redis. Le code, les applications et les outils que vous utilisez couramment avec vos environnements Memcached ou Redis fonctionnent donc de manière transparente avec ce service. Grâce à la prise en charge de la configuration en cluster dans Amazon ElastiCache, vous profitez des avantages d'un service rapide, évolutif et facile à utiliser qui peut répondre aux besoins de vos applications les plus exigeantes. A l'instar de toutes les offres d'Amazon Web Services, il n'y a pas d'investissement initial à réaliser et vous ne payez que les ressources que vous utilisez.

Q : En quoi consiste la mise en cache en mémoire et quel en est l'intérêt pour mes applications ?

La mise en cache en mémoire fournie par Amazon ElastiCache peut être utilisée pour améliorer significativement la latence et le débit depuis plusieurs tâches de travail d'application à lecture intensive, (tels que les réseaux sociaux, le jeu, le partage de média et les portails Q&A) ou les tâches de travail de calcul intensif (tel que les moteurs de recommandations). La mise en cache en mémoire améliore les performances de l'application en stockant les segments de données les plus importants dans la mémoire pour un accès à faible latence. Les informations mises en cache peuvent inclure les résultats d'interrogations de bases de données à E/S intensives ou les résultats de calculs intensifs.

Q : Puis-je utiliser Amazon ElastiCache pour d'autres applications que la mise en cache ?

R : Oui. ElastiCache for Redis peut être utilisé pour le stockage de données de valeurs clés principales en mémoire, fournissant une performance de données rapide inférieure à la milliseconde, une haute disponibilité et une évolutivité. Vous pouvez configurer un cluster de 500 nœuds comprenant entre 83 (un maître et cinq réplicas par partition) et 500 partitions (un maître et aucun réplica), ce qui vous octroie 340 To de mémoire. La prise en charge maximale de 500 nœuds est disponible dans Amazon ElastiCache for Redis, à partir de la version 5.0.6 de Redis. Cliquez ici pour consulter d'autres cas d'utilisation, tels que les classements, la limitation de vitesse, les files d'attente et les discussions.

Q : Puis-je utiliser Amazon ElastiCache via AWS CloudFormation ?

AWS CloudFormation simplifie la mise en service et la gestion en fournissant des modèles AWS CloudFormation pour assurer le dimensionnement rapide et fiable des services ou applications. AWS CloudFormation assure une prise en charge complète d'Amazon ElastiCache en fournissant des modèles pour créer un cluster (MemCached et Redis) et des groupes de réplication. Les modèles sont mis à jour avec la dernière annonce d'ElastiCache Redis pour la configuration Redis en cluster et offrent flexibilité et facilité d'utilisation aux clients d'Amazon ElastiCache.

Q : Quelles sont les tâches qu'Amazon ElastiCache gère à ma place ?

Amazon ElastiCache gère les tâches liées à la configuration d'un environnement en mémoire distribué, de la mise en service des ressources serveur demandées à l'installation du logiciel. Une fois que votre environnement est opérationnel, le service automatise les tâches administratives courantes telles que la détection des pannes et la restauration, ainsi que l'application des patchs de logiciel. Amazon ElastiCache fournit des métriques de surveillance détaillées associées à vos nœuds, ce qui vous permet de diagnostiquer et de réagir aux problèmes très rapidement. Par exemple, vous pouvez configurer des seuils et recevoir des alarmes si l'un de vos nœuds est surchargé par les requêtes.

Q : Que sont les nœuds, les partitions et les clusters Amazon ElastiCache ?

Le nœud est la plus petite composante d'un déploiement Amazon ElastiCache. C'est une partie à taille fixe de RAM sécurisée attachée au réseau. Chaque nœud exécute une instance du service compatible avec le protocole Memcached ou Redis et possède un nom DNS et un port DNS qui lui sont propres. Plusieurs types de nœuds sont pris en charge, chacun avec différentes tailles de mémoire associées. Une partition Redis est un sous-ensemble de l'espace de clés du cluster, qui peut comprendre un nœud principal et zéro ou plusieurs réplicas en lecture. Pour en savoir plus sur les déploiements Redis, consultez la section « Redis » ci-dessous. Les partitions s'ajoutent pour former un cluster.

Q : Quels sont les moteurs pris en charge par Amazon ElastiCache ?

Amazon ElastiCache propose les offres entièrement gérées Redis, désignée comme la base de données préférée des développeurs dans le Stack Overflow 2020 Developer Survey, et Memcached, pour la plupart des applications exigeantes nécessitant des temps de réponse de moins d'une milliseconde.

Q : Comment démarrer avec Amazon ElastiCache ?

Si vous n'êtes pas encore inscrit à Amazon ElastiCache, vous pouvez cliquer sur le bouton « S'inscrire maintenant » sur la page de présentation d'Amazon ElastiCache et effectuer la procédure d'inscription. Vous devez posséder un compte Amazon Web Services ; dans le cas contraire, vous serez invité à en créer un au début de la procédure d'inscription à Amazon ElastiCache. Après vous être inscrit à ElastiCache, consultez la documentation Amazon ElastiCache, qui inclut notre manuel de démarrage Amazon ElastiCache for Redisou Amazon ElastiCache for Memcached.

Une fois familiarisé avec Amazon ElastiCache, vous pouvez lancer un cluster en quelques minutes à l'aide de la console de gestion AWS ou des API Amazon ElastiCache.

Q : Comment créer un cluster ?

Pour créer des clusters, il suffit d'utiliser la console de gestion AWS, les API Amazon ElastiCache ou les outils de ligne de commande. Pour lancer un cluster à l'aide de l'AWS Management Console, cliquez sur le bouton « Create » dans l'onglet « Memcached » ou « Redis ». Il vous suffit ensuite de spécifier l'identifiant de votre cluster, ainsi que le type et le nombre de nœuds, pour créer un cluster avec la quantité de mémoire dont vous avez besoin. Vous pouvez également créer votre cluster à l'aide de l'API CreateCacheCluster ou de la commande elasticache-create-cache-cluster. Si vous ne spécifiez aucune zone de disponibilité lors de la création d'un cluster, AWS procède automatiquement à son placement en fonction de vos exigences de mémoire et de la capacité disponible.

Q : Quels types de nœuds puis-je sélectionner ?

Amazon ElastiCache prend en charge les types de nœuds suivants :

Nœuds de la génération actuelle :

  • cache.m4.large : 6,42 Gio
  • cache.m4.xlarge : 14,28 Gio
  • cache.m4.2xlarge : 29,7 Gio
  • cache.m4.4xlarge : 60,78 Gio
  • cache.m4.10xlarge : 154,64 Gio
  • cache.m5.large : 6,38 Gio
  • cache.m5.xlarge : 12,93 Gio
  • cache.m5.2xlarge : 26,04 Gio
  • cache.m5.4xlarge : 52,26 Gio
  • cache.m5.12xlarge : 157,12 Gio
  • cache.m5.24xlarge : 314,32 Gio
  • cache.m6g.large : 6,38 Gio
  • cache.m6g.xlarge : 12,94 Gio
  • cache.m6g.2xlarge : 26,05 Gio
  • cache.m6g.4xlarge : 52,26 Gio
  • cache.m6g.8xlarge : 103,68 Gio
  • cache.m6g.12xlarge : 157,13 Gio
  • cache.m6g.16xlarge : 209,55 Gio
  • cache.r4.large : 12,3 Gio
  • cache.r4.xlarge : 25,05 Gio
  • cache.r4.2xlarge : 50,47 Gio
  • cache.r4.4xlarge : 101,38 Gio
  • cache.r4.8xlarge : 203,26 Gio
  • cache.r4.16xlarge : 407 Gio
  • cache.r5.large : 13,07 Gio
  • cache.r5.xlarge : 26,32 Gio
  • cache.r5.2xlarge : 52,82 Gio
  • cache.r5.4xlarge : 105,81 Gio
  • cache.r5.12xlarge : 317,77 Gio
  • cache.r5.24xlarge : 635,61 Gio
  • cache.r6g.large : 13,07 Gio
  • cache.r6g.xlarge : 26,32 Gio
  • cache.r6g.2xlarge : 52,82 Gio
  • cache.r6g.4xlarge : 105,81 Gio
  • cache.r6g.8xlarge : 209,55 Gio
  • cache.r6g.12xlarge : 317,77 Gio
  • cache.r6g.16xlarge : 419,1 Gio
  • cache.t2.micro : 555 Mo
  • cache.t2.small : 1,55 Gio
  • cache.t2.medium : 3,22 Gio
  • cache.t3.micro : 0,5 Gio
  • cache.t3.small : 1,37 Gio
  • cache.t3.medium : 3,09 Gio
Nœuds de la génération précédente :
 
  • cache.m1.small : 1,3 Gio
  • cache.m1.medium : 3,35 Gio
  • cache.m1.large : 7,1 Gio
  • cache.m1.xlarge : 14,6 Gio
  • cache.m2.xlarge : 16,7 Gio
  • cache.m2.2xlarge : 33,8 Gio
  • cache.m2.4xlarge : 68 Gio
  • cache.m3.medium : 2,78 Gio
  • cache.m3.large : 6,05 Gio
  • cache.m3.xlarge : 13,3 Gio
  • cache.m3.2xlarge : 27,9 Gio
  • cache.r3.large : 13,5 Gio
  • cache.r3.xlarge : 28,4 Gio
  • cache.r3.2xlarge : 58,2 Gio
  • cache.r3.4xlarge : 118 Gio
  • cache.r3.8xlarge : 237 Gio
  • cache.t1.micro : 213 Mo
  • cache.c1.xlarge : 6,6 Gio

Pour chaque type de nœud ci-dessus, la mémoire disponible pour Memcached ou Redis est indiquée après avoir pris en compte le logiciel système Amazon ElastiCache. La quantité totale de mémoire dans le cluster est un multiple entier de la mémoire disponible dans chaque partition. Par exemple, un cluster constitué de dix partitions de 6 Go chacune fournit une mémoire totale de 60 Go.

Q : Comment accéder à mes nœuds ?

Lorsque votre cluster est disponible, vous pouvez retrouver vos points de terminaison de nœuds en suivant les étapes ci-dessous dans la console de gestion AWS :

  • Naviguez dans l'onglet « Amazon ElastiCache ».
  • Cliquez sur le lien « (Nombres de) Nœuds » et naviguez dans l'onglet « Nœuds ».
  • Cliquez sur le bouton « Copier point(s) de terminaison de nœud ».

Autrement, vous pouvez utiliser l'API DescribeCacheClusters pour récupérer la liste des points de terminaison.

Vous pouvez ensuite configurer votre client Memcached ou Redis avec cette liste de points de terminaison et utiliser votre langage de programmation favori pour ajouter ou supprimer des données sur vos nœuds ElastiCache. Pour permettre les demandes réseau vers vos nœuds, vous devez autoriser l'accès. Pour une explication détaillée pour commencer, veuillez consulter notre Guide de démarrage pour Amazon ElastiCache pour Redis ou Amazon ElastiCache pour Memcached.

Q : Qu'est-ce qu'une fenêtre de maintenance ? Mes nœuds seront-ils disponibles pendant la maintenance du logiciel ?

Vous pouvez envisager la fenêtre de maintenance Amazon ElastiCache comme une opportunité de contrôler quand les patchs logiciel ont lieu, soit qu'ils soient demandés soit qu'ils soit nécessaires. Si un évènement de « maintenance » est planifié pour une semaine donnée, il sera déclenché et terminé à un moment donné pendant le créneau de maintenance de 60 minutes que vous identifiez.

Vos nœuds peuvent subir quelques ralentissements durant votre créneau de maintenance si l'application d'un patch logiciel est prévue. Pour plus d'informations, consultez le document « Engine Version Management ». Le patch peut être demandé par l'utilisateur, par exemple la mise à niveau du logiciel de mise en cache, ou réputée nécessaire (si nous identifions des vulnérabilités de sécurité dans le système ou le logiciel de mise en cache). Ce type de correction a lieu peu fréquemment (en général une fois à quelques mois d'intervalle) et ne doit que rarement nécessiter plus d'une fraction de votre créneau de maintenance. Si vous ne spécifiez pas un créneau de maintenance hebdomadaire préféré lors de la création de votre cluster, une valeur par défaut de 60 minutes est attribuée. Si vous souhaitez modifier la planification de la maintenance, vous pouvez le faire en modifiant votre instance DB dans la console de gestion AWS ou en utilisant l'API ModifyCacheCluster. Si vous le souhaitez, vous pouvez attribuer un créneau de maintenance préféré différent à chacun de vos clusters.


Q : Comment mon utilisation d'Amazon ElastiCache me sera-t-elle facturée ?

Vous payez uniquement ce que vous utilisez et il n'y a pas de frais minimum. La tarification est basée sur le nombre d'heures de nœud consommées pour chaque type de nœud. Les heures de nœud partiellement consommées sont facturées en tant qu'heures entières. Il n'y a pas de frais pour les transferts de données entre Amazon EC2 et Amazon ElastiCache au sein de la même zone de disponibilité. Alors que des frais de transfert de données régionales standard Amazon EC2 s'appliquent lors du transfert des données entre une instance Amazon EC2 et un nœud Amazon ElastiCache dans différentes zones de disponibilité de la même région, vous n'êtes facturé que pour le transfert de données entrant ou sortant de l'instance Amazon EC2. Il n'y a pas de frais de transfert de données Amazon ElastiCache pour le trafic entrant ou sortant du nœud Amazon ElastiCache lui-même. Les taux de transfert de données standard s'appliquent aux données transférées en dehors d'une région. Pour plus d'informations, consultez la page relative à la tarification.

Q : Quelles sont les dates de fin et de début de facturation pour mes nœuds Amazon ElastiCache ?

La facturation d'un nœud commence dès qu'il est disponible. La facturation se poursuit jusqu'à ce que le nœud soit arrêté, ce qui est le cas lors de sa suppression.

Q : Comment sont définies les heures d'utilisation facturables des nœuds ElastiCache ?

Des heures de nœud vous sont facturées dès que l'état de vos nœuds indique qu'ils sont disponibles. Si vous ne souhaitez plus être facturé pour un nœud, vous devez y mettre fin pour éviter que des heures d'utilisation supplémentaires ne vous soient facturées.

Q : Vos prix sont-ils toutes taxes comprises ?

Sauf indication contraire, nos prix n'incluent pas les taxes et redevances applicables, y compris la TVA et les taxes sur les ventes applicables. Pour les clients dont l'adresse de facturation est située au Japon, l'utilisation de services AWS est soumise à la taxe sur la consommation applicable dans ce pays. En savoir plus.


Q : Que sont les nœuds réservés Amazon ElastiCache ?

Les nœuds réservés ou les instances réservées (IR) représentent une option qui vous permet de profiter d'une remise importante sur l'utilisation des instances sur demande lorsque vous vous engagez pour une durée d'un an ou de trois ans. Avec les nœuds réservés, vous pouvez effectuer un paiement initial unique pour souscrire une réservation d'un ou trois ans dans le but d'exécuter votre nœud dans une région spécifique et de recevoir une réduction importante sur le coût d'utilisation horaire continu. Il existe trois options de paiement pour les instances réservées : vous avez la possibilité de ne rien payer au départ, de payer uniquement une partie des frais initiaux ou d'en régler la totalité. Cela vous permet de trouver le juste équilibre entre le montant initial payé et le tarif horaire effectif.

Q : En quoi les nœuds réservés sont-ils différents des nœuds à la demande ?

Pour ce qui est de leur fonctionnalité, les nœuds réservés et les nœuds à la demande sont exactement identiques. La seule différence est la manière dont vos nœuds sont facturés ; avec les nœuds réservés, vous effectuez un paiement initial unique et profitez d'un tarif d'utilisation horaire continu inférieur (par rapport aux nœuds à la demande) pendant la durée de la période de réservation.

Q : Comment acheter et créer des nœuds réservés ?

Vous pouvez utiliser l'option « Purchase Reserved Nodes » dans l'AWS Management Console. Autrement, vous pouvez utiliser les outils API pour afficher la liste des réservations disponibles à l'achat avec la méthode API DescribeReservedCacheNodesOfferings et ensuite acheter une réservation de nœud de cache en appelant la méthode PurchaseReservedCacheNodesOffering.

La création d'un nœud réservé est semblable au lancement d'un nœud à la demande. Il vous suffit de préciser la classe et la région du nœud que vous avez réservé. Si votre achat de réservation a été réalisé correctement, Amazon ElastiCache applique un tarif horaire réduit au nouveau nœud.

Q : Y aura-t-il toujours des réservations disponibles à l'achat ?

Oui. Les nœuds réservés sont achetés pour une région plutôt que pour une zone de disponibilité. Cela signifie que, même si la capacité est limitée dans une zone de disponibilité donnée, les réservations peuvent toujours être achetées dans cette région et utilisées dans une zone de disponibilité différente au sein de cette région.

Q : Combien de nœuds de cache réservés puis-je acheter ?

Vous pouvez acheter jusqu'à 300 nœuds réservés. Si vous souhaitez exécuter plus de 300 nœuds, remplissez le Formulaire de demande de nœud Amazon ElastiCache.

Q : Et si je souhaite convertir un nœud existant en nœud réservé ?

Il suffit d'acheter une réservation de nœud avec la même classe de nœud et dans la même région que le nœud que vous exécutez actuellement et que vous aimeriez réserver. Une fois la réservation terminée, Amazon ElastiCache applique automatiquement le nouveau coût d'utilisation horaire à votre nœud existant.

Q : Si je souscris à un nœud réservé, quand commence la période de réservation ? Qu'arrive-t-il à mon nœud lorsque la période de réservation se termine ?

Les changements de tarif associés à un nœud réservé sont activés une fois que votre demande a été reçue, lorsque l'autorisation de paiement est traitée. Vous pouvez suivre le statut de votre réservation sur la page d'activité du compte AWS ou en utilisant l'API DescribeReservedCacheNodes. Si le paiement unique ne peut pas être autorisé avant la période de facturation suivante, le tarif réduit ne sera pas appliqué.

Lorsque votre période de réservation expire, le tarif d'utilisation horaire à la demande est à nouveau appliqué à votre nœud selon la classe et la région du nœud.

Q : Comment contrôler les nœuds facturés au tarif des nœuds réservés ?

Les API d'Amazon ElastiCache permettant de créer, modifier et supprimer les nœuds ne font pas la distinction entre les nœuds à la demande et réservés ; vous pouvez donc les utiliser ensemble sans difficulté. Lors du calcul de votre facture, notre système applique automatiquement vos réservations, afin que tous les nœuds éligibles soient facturés au tarif horaire inférieur dont bénéficient les nœuds de cache réservés.

Q : Puis-je déplacer un nœud réservé depuis une région ou une zone de disponibilité vers une autre ?

Chaque nœud réservé est associé à une région spécifique, laquelle est définie pour toute la durée de la réservation et ne peut pas être modifiée. Toutefois, chaque réservation peut être utilisée dans n'importe laquelle des zones de disponibilité au sein de la région associée.

Q : Puis-je annuler une réservation ?

Non, vous ne pouvez pas annuler votre instance DB réservée, et le paiement initial (le cas échéant) n'est pas remboursable. Vous continuerez de payer chaque heure de la période définie pour votre instance DB réservée, quelle que soit son utilisation.

Q : Comment les options de paiement se répercutent-elles sur ma facture ?

Lorsque vous achetez une instance réservée avec l'option de paiement Tous les frais initiaux, vous réglez toute la durée de réservation de l'instance en un seul paiement initial. Vous avez aussi la possibilité de ne pas payer de frais initiaux, en choisissant l'option Aucuns frais initiaux. La valeur totale de l'instance réservée avec l'option de paiement Aucuns frais initiaux est répartie sur chaque heure de la durée de réservation. Vous serez donc facturé pour chaque heure, quelle que soit votre utilisation. L'option de paiement Frais initiaux partiels se situe à mi-chemin entre les options Tous les frais initiaux et Aucuns frais initiaux. Vous payez une faible somme initiale et êtes ensuite facturé selon un tarif horaire réduit pour chaque heure de réservation de l'instance, quelle que soit votre utilisation.


Q : Comment puis-je contrôler l'accès à Amazon ElastiCache ?

Lorsque vous n'utilisez pas le VPC, Amazon ElastiCache vous permet de contrôler l'accès à vos clusters par le biais de groupes de sécurité du cache. Un groupe de sécurité agit comme un pare-feu contrôlant l'accès du réseau à votre cluster. Par défaut, l'accès au réseau est désactivé pour vos clusters. Si vous souhaitez que vos applications accèdent à votre cluster, vous devez explicitement activer l'accès depuis les hôtes dans des groupes de sécurité EC2 spécifiques. Ce processus est appelé entrée.

Pour autoriser l'accès réseau à votre cluster, créez un groupe de sécurité et liez-y les groupes de sécurité EC2 désirés (qui, en retour, spécifient les instances EC2 autorisées). Le groupe de sécurité peut être associé à votre cluster au moment de sa création ou à l'aide de l'option « Modifier » dans la console de gestion AWS.

Veuillez noter que le contrôle d'accès basé sur la plage d'adresses IP est actuellement non activé pour les clusters. Tous les clients d'un cluster doivent figurer au sein du réseau EC2 et être autorisés via les groupes de sécurité comme décrit ci-dessus.

Si vous utilisez le VPC, cliquez ici pour en savoir plus.

Q : Les programmes exécutés sur les serveurs de mon propre centre de données peuvent-ils accéder à Amazon ElastiCache ?

Oui. Vous pouvez accéder à un cluster Amazon ElastiCache depuis une application exécutée sur votre centre de données, à condition qu'il existe une connexion entre votre VPC et le centre de données, que ce soit via VPN, ou Direct Connect. Les détails sont décrits ici.

Q : Les programmes s'exécutant sur les instances EC2 d'un VPC peuvent-ils accéder à Amazon ElastiCache ?

Oui. Les instances EC2 d'un VPC peuvent accéder à Amazon ElastiCache si le cluster ElastiCache a été créé dans le VPC. Pour en savoir plus sur la procédure permettant de créer un cluster Amazon ElastiCache dans un VPC, cliquez ici.

Q : En quoi consiste Amazon Virtual Private Cloud (VPC) et pourquoi devrais-je l'utiliser avec Amazon ElastiCache ?

Amazon VPC vous permet de créer un environnement de réseau virtuel dans une section privée et isolée du cloud Amazon Web Services (AWS), où vous pouvez exercer un contrôle total sur les aspects tels que les plages d'adresses IP privées, les sous-réseaux, les tables de routage et les passerelles réseau. Avec Amazon VPC, vous pouvez définir une topologie de réseau virtuel et personnaliser la configuration réseau afin qu'elle ressemble étroitement à un réseau IP classique que vous pourriez exploiter dans votre propre centre de données.

Vous pouvez, en particulier, utiliser Amazon ElastiCache dans un VPC si vous souhaitez exécuter une application web destinée au grand public, tout en continuant à exploiter des serveurs dorsaux non accessibles au public dans un sous-réseau privé. Vous pouvez créer un sous-réseau destiné au grand public pour vos serveurs web avec accès à Internet et placer votre infrastructure dorsale au sein d'un sous-réseau privé sans accès à Internet. Votre infrastructure backend peut, par exemple, contenir des instances DB RDS et un cluster Amazon ElastiCache qui fournit la couche en mémoire. Pour en savoir plus sur Amazon VPC, consultez le manuel Amazon Virtual Private Cloud User Guide.

Q : Comment créer un cluster Amazon ElastiCache dans VPC ?

Pour consulter un exemple détaillant la procédure de création d'un cluster Amazon ElastiCache dans VPC, reportez-vous au manuel Amazon ElastiCache User Guide.

Vous trouverez ci-après les prérequis à la création d'un cluster dans un VPC :

  • Vous devez disposer d'un VPC configuré avec au moins un sous-réseau. Pour en savoir plus sur la création d'une instance Amazon VPC et de sous-réseaux (subnets), reportez-vous au manuel Getting Started Guide for Amazon VPC.
  • Vous devez disposer d'un groupe de sous-réseau (pour Redis ou Memcached) défini pour votre VPC.
  • Un groupe de sécurité VPC doit être défini comme votre VPC (vous pouvez également utiliser le groupe fourni par défaut).
  • De plus, vous devez allouer des blocs d'adresse CIDR de taille égale à chacun de vos sous-réseaux de sorte qu'il y ait suffisamment d'adresses IP de rechange à disposition d'Amazon ElastiCache pendant les opérations de maintenance (par exemple, remplacement du nœud de cache).

Q : Comment créer un cluster Amazon ElastiCache dans une instance existante de VPC ?

La procédure de création d'un cluster Amazon ElastiCache dans un VPC existant est identique à celle qui est réalisée dans un nouveau VPC. Vous trouverez d'autres détails pour Redis ou Memcached.

Q : Comment se connecter à un nœud ElastiCache dans VPC ?

Les nœuds Amazon ElastiCache déployés dans un VPC sont accessibles par les instances EC2 déployées dans le même VPC. Si ces instances EC2 sont déployées dans un sous-réseau public avec des adresses IP Elastic associées, vous pouvez accéder aux instances EC2 sur Internet.

Si vous souhaitez accéder aux nœuds Amazon ElastiCache, déployés dans un VPC, depuis l'Internet ou depuis des instances EC2 à l'extérieur du VPC, veuillez suivre les directives concernant Redis ou Memcached.

ElastiCache s'assure que le nom DNS et l'adresse IP du nœud de cache restent identiques après une récupération des nœuds de cache après une défaillance. 

Q : Qu'est-ce qu'un groupe de sous-réseaux et pourquoi en ai-je besoin ?

Un groupe de sous-réseaux est un ensemble de sous-réseaux que vous devez attribuer à votre cluster Amazon ElastiCache dans un VPC. La création d'un groupe de sous-réseaux s'effectue à partir de la console Amazon ElastiCache. Chaque groupe de sous-réseaux doit disposer d'au moins un sous-réseau. Amazon ElastiCache utilise ce groupe de sous-réseaux pour sélectionner un sous-réseau. Les adresses IP du sous-réseau sélectionné sont ensuite associées aux points de terminaison du nœud. En outre, Amazon ElastiCache crée des interfaces réseau Elastic et les associe aux nœuds correspondant aux adresses IP précédemment mentionnées.

Il est fortement recommandé d'utiliser les noms DNS pour la connexion à vos nœuds, car l'adresse IP sous-jacente peut être amenée à changer (par exemple, après le remplacement d'un nœud du cache).

Q : Est-il possible de changer le groupe de sous-réseaux de mon cluster ElastiCache ?

Un groupe de sous-réseaux existant peut être mis à jour afin d'ajouter des sous-réseaux supplémentaires soit pour les zones de disponibilité existantes, soit pour les nouvelles zones de disponibilité ajoutées depuis la création du cluster ElastiCache. Toutefois, la modification d'un tel groupe de sous-réseaux d'un cluster déployé n'est actuellement pas autorisée.

Q : En quoi l'utilisation d'Amazon ElastiCache diffère-t-elle selon qu'elle se fait au sein ou en dehors d'un VPC ?

La fonctionnalité initiale d'Amazon ElastiCache reste identique, que vous utilisiez un VPC ou non. Amazon ElastiCache prend en charge l'identification automatique des pannes, la récupération, le dimensionnement, la détection automatique et l'application de correctifs logiciels, que votre cluster ElastiCache se trouve à l'intérieur ou à l'extérieur d'un VPC.

Au sein d'un VPC, les nœuds d'un cluster ElastiCache sont uniquement associés à une adresse IP privée (au sein d'un sous-réseau que vous définissez). En dehors d'un VPC, l'accès au cluster ElastiCache peut être contrôlé à l'aide des groupes de sécurité, selon la procédure décrite ici.

Q : Puis-je déplacer mon cluster ElastiCache actuellement situé hors de VPC vers mon VPC ?

Non. Il n'est pas possible de déplacer vers le VPC un cluster Amazon ElastiCache actuellement hors du VPC. Vous devez créer un autre cluster Amazon ElastiCache au sein du VPC.

Q : Puis-je déplacer mon cluster ElastiCache actuellement situé dans le VPC hors de celui-ci ?

Actuellement, la migration directe des clusters ElastiCache depuis l'intérieur vers l'extérieur d'un VPC n'est pas prise en charge. Vous devez créer un autre cluster Amazon ElastiCache en dehors du VPC.

Q : Comment contrôler les accès réseau à mon cluster ?

Amazon ElastiCache vous permet de contrôler l'accès à votre cluster et donc, aux nœuds, à partir des groupes de sécurité qui ne sont pas inclus dans un déploiement VPC. Un groupe de sécurité fonctionne comme un pare-feu contrôlant l'accès du réseau à votre nœud. Par défaut, l'accès réseau est désactivé pour vos nœuds. Si vous souhaitez que vos applications accèdent à votre nœud, vous pouvez configurer votre groupe de sécurité pour autoriser l'accès depuis les instances EC2 avec des groupes de sécurité EC2 ou des plages d'adresses IP spécifiques. Ce processus est appelé entrée. Une fois que l'entrée est configurée pour un groupe de sécurité, les mêmes règles sont appliquées à tous les nœuds associés à ce groupe. Les groupes de sécurité peuvent être configurés à partir de la section « Security Groups » de la console Amazon ElastiCache ou à l'aide des API d'Amazon ElastiCache.

Dans le cas des déploiements VPC, l'accès à vos nœuds est contrôlé par le groupe de sécurité VPC et le groupe de sous-réseaux. Le groupe de sécurité VPC est l'équivalent du groupe de sécurité au sein du VPC.

Q : Quelles précautions dois-je prendre pour m'assurer que mes nœuds ElastiCache situés dans le VPC sont accessibles par mon application ?

Vous avez la responsabilité de modifier les tables de routage et les listes de droits d'accès réseau dans votre VPC, afin de vous assurer que vos nœuds ElastiCache sont accessibles depuis vos instances clientes du VPC. Pour en savoir plus, voir la documentation Amazon ElastiCache for Redis ou Amazon ElastiCache for Memcached.

Q : Puis-je utiliser les groupes de sécurité pour configurer les clusters faisant partie de mon VPC ?

Non. Les groupes de sécurité ne sont pas utilisés dans le cas de l'exploitation du cache au sein d'un VPC. En revanche, ils sont utilisés dans les paramètres hors VPC. Lorsque vous créez un cluster dans un VPC, vous devez utiliser les groupes de sécurité VPC.

Q : Puis-je associer un groupe de sécurité EC2 classique à un cluster lancé au sein d'un VPC ?

Non. Vous pouvez seulement associer des groupes de sécurité VPC appartenant au même VPC que votre cluster.

Q : Les nœuds d'un cluster ElastiCache peuvent-ils être répartis sur plusieurs sous-réseaux ?

Oui. Les nœuds d'un cluster Amazon ElastiCache peuvent être répartis sur plusieurs sous-réseaux, à condition que ces sous-réseaux appartiennent au même groupe de sous-réseaux que celui associé au cluster ElastiCache au moment de la création.


Q : En quoi consistent les groupes de paramètres ? En quoi sont-ils utiles ?

Un groupe de paramètres agit en tant que « conteneur » pour les valeurs de configuration de moteur qui peuvent être appliquées à un ou plusieurs clusters. Si vous créez un cluster sans spécifier de groupe de paramètres, celui par défaut est utilisé. Ce groupe par défaut contient le moteur par défaut et le système Amazon ElastiCache par défaut optimisés pour le cluster que vous exécutez. Toutefois, si vous voulez que votre cluster soit exécuté avec vos valeurs de configuration de moteur sur mesure, il vous suffit de créer un nouveau groupe de paramètres et de modifier les paramètres souhaités et le cluster pour utiliser le nouveau groupe de paramètres. Une fois associés, tous les clusters qui utilisent un groupe de paramètres particulier se voient appliquer toutes les mises à jour apportées à ce groupe de paramètres. Pour plus d'informations sur la configuration des groupes de paramètres, consultez le manuel de l'utilisateur d'Amazon ElastiCache pour Redis ou Amazon ElastiCache pour Memcached.

Q : Comment choisir les bons paramètres de configuration pour mon ou mes clusters ?

Amazon ElastiCache choisit par défaut les paramètres de configuration optimaux pour votre cluster, en prenant en compte les capacités de mémoire/calcul du type de nœud. Toutefois si vous souhaitez les changer, vous pouvez le faire en utilisant nos API de gestion de configuration. Veuillez noter que changer les paramètres de configuration à partir des valeurs recommandées peut avoir des effets inattendus, allant d'une performance dégradée aux plantages de système ; ceci ne doit être effectué que par des utilisateurs avancés qui sont disposés à assumer ces risques. Pour plus d'informations sur la modification des paramètres, consultez le Guide de l'utilisateur Amazon ElastiCache.

Q : Comment puis-je voir la configuration actuelle de mes paramètres pour un groupe de paramètres donné ?

Vous pouvez utiliser la console de gestion AWS, les API d'Amazon ElastiCache ou les outils de ligne de commande pour afficher les informations concernant vos groupes de paramètres et la manière dont leurs paramètres sont configurés.


Q : Que puis-je mettre en cache en utilisant Amazon ElastiCache for Memcached ?

Vous pouvez mettre en cache divers objets en utilisant le service, depuis le contenu des banques de données persistantes (telles qu'Amazon RDS, DynamoDB, ou des bases de données gérées personnellement et hébergées sur EC2) jusqu'aux pages web générées dynamiquement (avec Nginx par exemple), en passant par les données de session transitoire qui ne nécessitent pas un stockage de sauvegarde persistant. Vous pouvez aussi utiliser ce service pour implémenter des compteurs à haute fréquence afin de déployer un contrôle des admissions dans les applications web à volume élevé.

Q : Puis-je utiliser Amazon ElastiCache pour Memcached avec un magasin de données persistant AWS tel qu'Amazon RDS or Amazon DynamoDB ?

Oui. Amazon ElastiCache est une interface frontale idéale pour les magasins de données comme Amazon RDS ou Amazon DynamoDB, fournissant un niveau intermédiaire à hautes performances pour les applications avec des vitesses de requêtes extrêmement élevées et/ou des exigences de faible latence.

Q : J'utilise déjà Memcached. Comment puis-je migrer vers Amazon ElastiCache ?

Amazon ElastiCache est compatible avec le protocole Memcached. Ainsi, vous pouvez utiliser les opérations Memcached standard comme « get », « set », « incr » et « decr » exactement de la même manière que vous le feriez dans vos déploiements Memcached existants. Amazon ElastiCache supporte à la fois les protocoles texte et binaire. Il supporte aussi la plupart des résultats statistiques standards, qui peuvent aussi être affichés sous forme de graphiques via CloudWatch. Ainsi, vous pouvez passer à l'utilisation d'Amazon ElastiCache sans recompiler ou relier vos applications ; les bibliothèques que vous utilisez continuent de fonctionner. Pour configurer les serveurs auxquels accèdent votre application, il vous suffit de mettre à jour le fichier « config » Memcached de votre application pour inclure les points de terminaison des serveurs (nœuds) que nous vous fournissons. Vous pouvez simplement utiliser l'option « Copier points de terminaison de nœud » dans l'AWS Management Console ou l'API « DescribeCacheClusters » pour obtenir une liste des points de terminaison. Comme pour tout processus de migration, nous recommandons des tests approfondis de votre nouveau déploiement Amazon ElastiCache avant de mettre fin à votre solution actuelle.

Vous pouvez accéder au cluster Amazon ElastiCache dans un VPC Amazon, soit depuis le réseau Amazon EC2, soit depuis votre propre centre de données. Pour plus d'informations, consultez les modèles d'accès Amazon VPC.

Amazon ElastiCache utilise des entrées DNS pour permettre aux applications clientes de situer les serveurs (nœuds). Le nom DNS d'un nœud reste constant, mais l'adresse IP d'un nœud peut changer avec le temps, par exemple, quand les nœuds sont remplacés automatiquement après une défaillance sur une installation sans VPC. Consultez ces FAQ pour obtenir des recommandations sur la gestion des échecs des nœuds.


Q : Comment sélectionner un type de nœud adapté à mon application ?

Bien qu'il n'y ait pas de réponse précise à cette question, avec Amazon ElastiCache, vous n'avez pas besoin de vous inquiéter d'obtenir le nombre exact de nœuds, car vous pouvez très facilement ajouter ou supprimer des nœuds par la suite. Les deux aspects interdépendants suivants peuvent être considérés pour le choix de votre configuration initiale :

  • La mémoire totale requise pour que vos données atteignent le taux de réussite de votre cache cible, et
  • Le nombre de nœuds requis pour maintenir une performance d'application acceptable sans surcharger le backend de base de données en cas de panne des nœuds.

La quantité de mémoire requise dépend de la taille de votre ensemble de données et des modèles d'accès de votre application. Pour améliorer la tolérance aux pannes, une fois que vous avez une idée approximative de la mémoire totale requise, divisez cette mémoire en suffisamment de nœuds de manière à ce que votre application puisse survivre à la perte d'un ou de deux nœuds. Par exemple, si vous avez besoin d'une mémoire de 13 Go, vous pouvez utiliser deux nœuds cache.m4.large au lieu d'utiliser un nœud cache.m4.xlarge. Il est important que les autres systèmes tels que les bases de données ne soient pas surchargés si le taux de réussite du cache est temporairement réduit pendant une reprise après panne d'un ou de plusieurs nœuds. Pour en savoir plus, consultez le manuel Guide de l'utilisateur Amazon ElastiCache.

Q : Un cluster peut-il s'étendre sur plusieurs zones de disponibilité ?

Oui. Lorsque vous créez un cluster ou que vous ajoutez des nœuds à un cluster existant, vous pouvez sélectionner les zones de disponibilité des nouveaux nœuds. Vous pouvez soit spécifier le nombre de nœuds nécessaire pour chaque zone de disponibilité, soit sélectionner « Spread nodes across zones » (répartir les nœuds sur les différentes zones). Si le cluster se trouve dans un VPC, les nœuds peuvent uniquement être placés dans les zones de disponibilité du groupe de sous-réseaux du cache sélectionné. Pour plus d'informations, consultez la documentation sur les VPC ElastiCache.

Q : Combien de nœuds par région puis-je exécuter dans Amazon ElastiCache Memcached ?

Vous pouvez exécuter au maximum 300 nœuds par région. Si vous avez besoin de plus de nœuds, veuillez remplir le formulaire de demande d'augmentation des limites ElastiCache.

Q : Comment réagit Amazon ElastiCache en cas de panne au niveau d'un nœud ?

Le service détecte la panne et réagit en effectuant les actions automatiques suivantes :

  • Amazon ElastiCache répare le nœud en acquérant de nouvelles ressources de service et redirige ensuite le nom DNS existant du nœud pour indiquer ces nouvelles ressources de service. Pour les installations à VPC, ElastiCache s'assure que le nom DNS et l'adresse IP du nœud restent identiques lors de la récupération des nœuds après une défaillance. Pour les installations sans VPC, ElastiCache s'assure que le nom DNS d'un nœud ne change pas. Cependant, son adresse IP sous-jacente peut varier.
  • Si vous associez un sujet SNS à votre cluster, quand le nouveau nœud est configuré et prêt à être utilisé, Amazon ElastiCache envoie une notification SNS pour vous faire savoir que la restauration du nœud a eu lieu. Cela vous permet, si vous le souhaitez, de vous organiser pour que vos applications forcent la bibliothèque cliente Memcached à tenter de se reconnecter aux nœuds réparés. Cela peut s'avérer important, car certaines bibliothèques Memcached cesseront d'utiliser un serveur (nœud) indéfiniment si elles rencontrent des erreurs de communication ou des dépassements de délais avec ce serveur.

Q : Si j'estime avoir besoin de davantage de mémoire pour prendre en charge mon application, comment puis-je augmenter la mémoire totale avec Amazon ElastiCache ?

Vous pouvez ajouter plus de nœuds à votre cluster Memcached existant en utilisant l'option « Add Node » dans l'onglet « Nodes » de votre cluster de cache dans l'AWS Management Console ou à l'aide de l'API ModifyCacheCluster.


Q : Comment Amazon ElastiCache interagit-elle avec les autres solutions Amazon Web Services ?

Amazon ElastiCache convient parfaitement en tant qu'interface frontale pour les solutions Amazon Web Services telles qu'Amazon RDS et Amazon DynamoDB, fournissant une latence extrêmement faible pour les applications à haute performance et déchargeant une partie du volume de requêtes tandis que ces solutions assurent la durabilité des données sur le très long terme. Le service peut aussi être utilisé pour améliorer les performances des applications en association avec Amazon EC2 et EMR.

Q : Amazon ElastiCache est-il mieux adapté à un langage de programmation particulier ?

Les bibliothèques clientes Memcached sont disponibles pour beaucoup, si ce n'est tous les langages de programmation. Si vous rencontrez des problèmes avec des clients Memcached spécifiques lors de l'utilisation d'Amazon ElastiCache, veuillez nous en informer via le forum de la communauté Amazon ElastiCache.

Q : Quelles sont les bibliothèques Memcached les plus populaires compatibles avec Amazon ElastiCache ?

Amazon ElastiCache ne requiert pas de bibliothèques clientes spécifiques et fonctionne avec les bibliothèques clientes Memcached existantes sans recompilation ni reconnexion d'application (Memcached 1.4.5 et versions ultérieures). Vous pouvez par exemple utiliser libMemcached (C) et ses dérivés (notamment PHP, Perl et Python), spyMemcached (Java) et fauna (Ruby).


Q : En quoi consiste la détection automatique et à quoi sert-elle ?

La détection automatique est une fonctionnalité qui simplifie la tâche des développeurs et leur permet de gagner du temps en réduisant la complexité de leurs applications. Elle permet aux clients de repérer automatiquement les nœuds de cache qui sont ajoutés ou retirés d'un cluster Amazon ElastiCache. Jusqu'à présent, pour traiter les changements au niveau de l'appartenance au cluster, les développeurs devaient mettre à jour manuellement la liste des points de terminaison des nœuds de cache. Or, selon l'architecture de l'application client, cette opération nécessitait généralement une réinitialisation du client, en quittant l'application puis en la redémarrant, ce qui impliquait une interruption de l'activité. Grâce à la détection automatique, cette complication est résolue. Outre une rétrocompatibilité avec le protocole Memcached, la fonctionnalité de détection automatique associée à Amazon ElastiCache fournit aux clients des informations concernant l'appartenance au cluster de cache. Tout client capable de traiter ces informations supplémentaires peut alors effectuer une reconfiguration automatique, sans passer par une réinitialisation, afin d'utiliser les nœuds les plus à jour du cluster Amazon ElastiCache.

Q : Comment fonctionne la détection automatique ?

Un cluster Amazon ElastiCache peut être créé avec des nœuds auxquels il est possible de s'adresser via des points de terminaison nommés. Avec la détection automatique, le cluster Amazon ElastiCache dispose d'un point de terminaison de configuration unique. Ce point de terminaison correspond à un enregistrement DNS valide pour toute la durée de vie du cluster. Cet enregistrement DNS comprend les noms DNS des nœuds du cluster. Amazon ElastiCache s'assure que le point de terminaison de configuration pointe toujours vers un de ces nœuds « cibles » au moins. L'interrogation envoyée au nœud cible renvoie les points de terminaison pour tous les nœuds du cluster considéré. Vous pouvez, ensuite, connecter les nœuds du cluster comme vous le faisiez auparavant et utiliser les commandes du protocole Memcached (par exemple, « get », « set », « incr » et « decr »). Pour plus d'informations, cliquez ici. Afin d'exploiter la fonctionnalité de détection automatique, vous devez utiliser un client capable de la prendre en charge. Les clients de détection automatique pour .Net, Java et PHP sont disponibles en téléchargement à partir de la console Amazon ElastiCache. Lors de son initialisation, le client détermine automatiquement les membres actuels du cluster Amazon ElastiCache par le biais du point de terminaison de configuration. Lorsque vous apportez des modifications à votre cluster de cache en y ajoutant ou en supprimant des nœuds, ou si un nœud est remplacé suite à une défaillance, le client de détection automatique repère automatiquement ces changements, sans que vous deviez initialiser vos clients manuellement.

Q : Comment commencer à utiliser la détection automatique ?

Pour commencer, téléchargez le client de cluster Amazon ElastiCache en cliquant sur le lien « Download ElastiCache Cluster Client » à partir de la console Amazon ElastiCache. Afin d'effectuer ce téléchargement, vous devez posséder un compte Amazon ElastiCache ; si ce n'est pas déjà le cas, inscrivez-vous sur la page de présentation d'Amazon ElastiCache. Une fois le client téléchargé, vous pouvez commencer à configurer et à activer votre cluster Amazon ElastiCache à partir de la console Amazon ElastiCache. Pour en savoir plus, cliquez ici.

Q : Si je continue à utiliser mes propres clients Memcached avec mon cluster ElastiCache, pourrai-je utiliser cette fonctionnalité ?

Non. Vous ne pourrez pas utiliser la fonctionnalité de détection automatique avec vos clients Memcached actuels. Afin d'exploiter la fonctionnalité de détection automatique, un client doit pouvoir utiliser un point de terminaison de configuration et déterminer les points de terminaison des nœuds du cluster. Vous pouvez utiliser le client de cluster Amazon ElastiCache ou étendre votre client Memcached actuel afin d'inclure le jeu de commandes de détection automatique.

Q : Quelle est la configuration matérielle/logicielle requise pour la détection automatique ?

Afin d'exploiter la fonctionnalité de détection automatique, un client prenant en charge cette fonctionnalité doit être utilisé pour se connecter au cluster Amazon ElastiCache. Amazon ElastiCache prend actuellement en charge les clients de détection automatique pour .Net, Java et PHP. Ils sont téléchargeables à partir de la console Amazon ElastiCache. Sachez que vous pouvez créer des clients pour d'autres langages à partir des clients Memcached les plus courants.

Q : Comment puis-je modifier ou écrire mon propre client Memcached pour prendre en charge la détection automatique ?

Vous pouvez utiliser n'importe quelle bibliothèque de clients Memcached et y adjoindre une fonctionnalité prenant en charge la détection automatique. Si vous souhaitez ajouter ou modifier votre propre client pour bénéficier de la détection automatique, consultez la documentation relative au jeu de commandes de détection automatique.

Q : Puis-je continuer à utiliser mon client Memcached actuel si je n'ai pas besoin de la détection automatique ?

Oui. Amazon ElastiCache reste compatible avec le protocole Memcached et ne nécessite pas que vous modifiiez vos clients. Néanmoins, pour bénéficier des avantages offerts par la fonctionnalité de détection automatique, nous avons dû renforcer les capacités du client Memcached. Si vous décidez de ne pas utiliser le client de cluster Amazon ElastiCache, vous pouvez continuer avec vos propres clients ou modifier votre bibliothèque de clients afin d'y intégrer le jeu de commandes de détection automatique.

Q : Puis-je utiliser des clients hétérogènes avec la détection automatique ?

Oui. Un même cluster Amazon ElastiCache peut être connecté à la fois à un client doté de la détection automatique et à un client Memcached classique. Amazon ElastiCache reste compatible à 100 % avec Memcached.

Q : Puis-je arrêter d'utiliser la détection automatique ?

Oui. Vous pouvez cesser d'utiliser la détection automatique à tout moment. Vous pouvez désactiver la détection automatique en précisant le mode de fonctionnement lors de l'initialisation du client de cluster Amazon ElastiCache. Par ailleurs, Amazon ElastiCache prenant toujours totalement en charge Memcached, vous pouvez utiliser tout client compatible avec le protocole Memcached comme auparavant.


Q : Puis-je contrôler si et quand la version du moteur alimentant le cluster Amazon ElastiCache doit être mise à niveau vers de nouvelles versions prises en charge ?

Amazon ElastiCache vous permet de contrôler si et quand le logiciel compatible avec le protocole Memcached alimentant votre cluster doit être mis à niveau vers de nouvelles versions prises en charge par Amazon ElastiCache. Vous pouvez donc choisir de maintenir la compatibilité avec des versions Memcached spécifiques, de tester les nouvelles versions avec votre application avant le déploiement en production et de réaliser des mises à niveau en fonction de vos propres conditions et délais. Les mises à niveau de version impliquent quelques risques de compatibilité. Par conséquent, elles ne se produiront pas automatiquement et vous devrez donc les lancer vous-même. Cette approche de l'application de patchs de logiciel vous donne le contrôle des mises à niveau de version, mais déleste quand même la tâche de l'application de patchs vers Amazon ElastiCache. Vous pouvez en apprendre plus sur la gestion des versions en lisant les FAQ suivantes. Sinon, vous pouvez vous référer au Guide de l'utilisateur Amazon ElastiCache. Même si la fonctionnalité de gestion des versions du moteur a pour but de vous donner autant de contrôle que possible sur l'application des patchs, nous nous réservons la possibilité de mettre à niveau votre cluster à votre place dès lors que nous identifions une faille de sécurité dans le logiciel système ou de cache.

Q : Comment puis-je spécifier quelle version de Memcached mon cluster doit exécuter ?

Vous pouvez spécifier n'importe quelle version actuellement prise en charge (mineure et/ou majeure) lors de la création d'un nouveau cluster. Si vous souhaitez lancer une mise à niveau vers une version de moteur prise en charge, vous pouvez utiliser l'option « Modify » pour votre cluster. Spécifiez simplement la version que vous souhaitez mettre à niveau via le champ « Cache Engine Version ». La mise à niveau est ensuite appliquée en votre nom soit immédiatement (si l'option « Applied Immediately » est cochée), soit pendant le prochain créneau de maintenance programmé pour votre cluster.

Q : Puis-je tester mon cluster par rapport à une nouvelle version avant de procéder à la mise à niveau ?

Oui. Pour cela, créez un nouveau cluster avec la nouvelle version du moteur. Vous pouvez pointer votre application de développement/travail vers ce cluster, la tester et décider de mettre à niveau ou non votre cluster d'origine.

Q : Amazon ElastiCache fournit-il des recommandations concernant la prise en charge de nouvelles versions de et/ou l'obsolescence des versions Memcached actuellement prises en charge ?

Avec le temps, nous prévoyons de prendre en charge des versions de Memcached supplémentaires pour Amazon ElastiCache, à la fois mineures et majeures. Le nombre de nouvelles versions prises en charge dans une année donnée variera en fonction de la fréquence ainsi que du contenu des parutions de version Memcached et du résultat d'un examen approfondi de la version par notre équipe d'ingénierie.

Q : Quelle version du protocole filaire de Memcached est prise en charge par Amazon ElastiCache ?

Amazon ElastiCache prend en charge le protocole texte et binaire Memcached des versions de Memcached 1.6.6, 1.5.16, 1.5.10, 1.4.34, 1.4.33, 1.4.24, 1.4.14 et 1.4.5.

Q : Comment puis-je effectuer une mise à niveau vers la dernière version de Memcached ?

Vous pouvez mettre à niveau votre cluster Memcached existant à l'aide du processus Modify. Lors de la mise à niveau d'une ancienne version de Memcached vers la version 1.4.33 ou une version ultérieure, assurez-vous que la valeur max_chunk_size du paramètre existant répond aux conditions requises pour le paramètre slab_chunk_max. Consultez les prérequis de mise à niveau ici.


Q : En quoi consiste Amazon ElastiCache for Redis ?

Amazon ElastiCache for Redis est un service web qui simplifie le déploiement et l'exécution de nœuds de serveur compatibles avec le protocole Redis dans le cloud. Ce service permet de gérer, de surveiller et d'exécuter des nœuds Redis. Ainsi, la création, la suppression et la modification des nœuds peuvent s'effectuer via la console Amazon ElastiCache, l'interface de ligne de commande (CLI) ou les API du service web. Amazon ElastiCache for Redis accepte les configurations hautement disponibles, y compris le mode cluster activé et désactivé de Redis avec basculement automatique entre le nœud principal et un réplica.

Q : La version Amazon ElastiCache for Redis est-elle compatible avec le protocole du système Redis à code source libre ?

Oui. Amazon ElastiCache for Redis est compatible avec le protocole du système Redis à code source libre. Le code, les applications, les pilotes et les outils actuellement utilisés par un client dans son magasin de données Redis autonome existant continuent de fonctionner avec Amazon ElastiCache for Redis et aucune modification ne doit être apportée au code pour les déploiements Redis existants lors de leur migration vers Amazon ElastiCache for Redis, sauf indication contraire. Nous prenons actuellement en charge les versions Redis 6.0.5, 5.0.6, 5.0.5, 5.0.4, 5.0.3, 5.0.0, 4.0.10, 3.2.10, 3.2.6, 3.2.4, 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19, 2.8.6 et 2.6.13.

Q : Combien coûte Amazon ElastiCache for Redis ?

Pour obtenir des informations sur la tarification actuelle, consultez la page de tarification.

Q : En quoi consistent les nœuds, les clusters et les groupes de réplication d'Amazon ElastiCache for Redis ?

Un nœud Amazon ElastiCache for Redis est le plus petit bloc de construction au sein d'un déploiement Amazon ElastiCache for Redis. Chaque nœud Amazon ElastiCache for Redis prend en charge le protocole Redis et possède un nom DNS et un port DNS qui lui sont propres. Plusieurs types de nœuds Amazon ElastiCache for Redis sont pris en charge et sont associés chacun à des quantités variables de capacité CPU et de mémoire. Un nœud Amazon ElastiCache for Redis peut jouer le rôle de nœud principal ou de réplica en lecture. Un nœud principal peut être répliqué en divers nœuds de réplica en lecture. Un cluster Amazon ElastiCache for Redis regroupe un ou plusieurs nœuds Amazon ElastiCache for Redis ; le nœud principal figurera dans le cluster principal et le nœud de réplica en lecture figurera dans le cluster des réplicas en lecture. Un cluster gère un espace de clés logiques au sein duquel chaque nœud est responsable d'une partie de l'espace de clés. La plupart des opérations de gestion sont effectuées au niveau du cluster. Un groupe de réplications Amazon ElastiCache for Redis regroupe le cluster principal et les clusters de réplicas en lecture d'une installation Redis. Un groupe de réplications contient un seul cluster principal et peut inclure plusieurs clusters de réplicas en lecture (ou aucun). Tous les nœuds au sein d'un groupe de réplications (et, donc, d'un cluster) sont du même type et possèdent la même configuration au niveau des paramètres et du groupe de sécurité.

Q : Amazon ElastiCache for Redis prend-elle en charge la persistance du système Redis ?

Amazon ElastiCache for Redis ne prend pas en charge la fonction AOF (fichiers en ajout seulement), mais vous pouvez obtenir une certaine persistance en prenant un instantané de vos données Redis à l'aide de la fonction de sauvegarde et de restauration. Pour plus d'informations, cliquez ici.

Q : Comment passer d'Amazon ElastiCache pour Memcached à Amazon ElastiCache pour Redis et inversement ?

Nous ne prenons actuellement pas en charge la migration automatique entre Memcached et Redis. Toutefois, vous pouvez utiliser un client Memcached pour lire à partir d'un cluster Memcached et un client Redis pour écrire sur un cluster Redis. De même, vous pouvez lire à partir d'un cluster Redis à l'aide d'un client Redis et utiliser un client Memcached pour écrire sur un cluster Memcached. Assurez-vous de prendre en compte les différences de format de données entre les deux moteurs, ainsi que la configuration des clusters.

Q : La version Amazon ElastiCache pour Redis permet-elle un fonctionnement multi-AZ ?

Oui. Avec Amazon ElastiCache for Redis, vous pouvez créer un réplica en lecture dans une autre zone de disponibilité AWS. En cas de défaillance d'un nœud, nous mettons en service un nouveau nœud. Si le nœud principal connaît une défaillance, ElastCache for Redis désignera automatiquement un réplica en lecture existant pour endosser le rôle principal. Pour en savoir plus sur la gestion des défaillances d'un nœud, cliquez ici.

Q : Quelles sont les options fournies par Amazon ElastiCache for Redis en cas de défaillance d'un nœud ?

Amazon ElastiCache for Redis répare le nœud en acquérant de nouvelles ressources de service et redirige ensuite le nom DNS existant du nœud afin qu'il pointe vers ces nouvelles ressources de service. Ainsi, le nom DNS du nœud Redis reste constant, mais son adresse IP peut changer. Si vous disposez d'un groupe de réplications composé d'un ou de plusieurs réplicas en lecture et que multi-AZ est activé, Amazon ElastiCache détectera automatiquement la défaillance, sélectionnera un réplica et le désignera comme nouveau nœud principal. Il propagera également le DNS afin que vous puissiez continuer à utiliser le point de terminaison principal. Une fois le nouveau nœud défini, le DNS redirigera vers celui-ci. Pour en savoir plus, consultez la section multi-AZ de cette FAQ. 

En cas de défaillance du nœud principal, si l'option de réplication Redis est sélectionnée, mais que multi-AZ est désactivé, vous pourrez choisir de lancer un basculement vers un nœud de réplica en lecture. La cible du basculement peut se trouver dans la même zone ou dans une zone différente. Pour un basculement vers la zone d'origine, vous devez promouvoir le réplica en lecture au sein de la zone d'origine en tant que nœud principal. Vous pouvez opter pour une architecture de votre application qui oblige la bibliothèque du client Redis à se reconnecter au nœud de serveur Redis réparé. Cela peut être utile, car certaines bibliothèques Redis cessent définitivement d'utiliser un serveur dès lors qu'elles rencontrent des erreurs ou des dépassements de délais de communication.

Q : Comment le basculement fonctionne-t-il ?

Lors du déploiement d'ElastiCache for Redis avec le mode cluster désactivé, pour des groupes de réplication avec multi-AZ activé, le comportement de basculement est décrit dans la section multi-AZ de cette FAQ. Si vous choisissez de ne pas activer multi-AZ, Amazon ElastiCache surveille le nœud principal. Si le nœud n'est plus disponible ou ne répond plus, Amazon ElastiCache for Redis répare alors le nœud en acquérant de nouvelles ressources de service, puis redirige le nom DNS existant du nœud afin qu'il pointe vers ces nouvelles ressources de service. Ainsi, le nom DNS du nœud Redis reste constant, mais son adresse IP peut changer. Cependant, si le nœud principal ne peut pas être réparé (et si votre multi-AZ est désactivé), vous pouvez décider de promouvoir un des réplicas en lecture en tant que nouveau nœud principal. Pour en savoir plus sur la sélection d'un nouveau nœud principal, cliquez ici. L'enregistrement DNS du point de terminaison du nœud principal est alors mis à jour afin de pointer vers le nœud de réplica en lecture promu. Un nœud de réplica en lecture est créé au sein de la zone de disponibilité d'origine du nœud principal en tant que réplica en lecture dans le groupe de réplications et suit les modifications apportées au nouveau nœud principal.

Lors du déploiement d'ElastiCache for Redis avec le mode cluster activé, vous distribuez l'espace de clés de cache entre plusieurs partitions. Cela signifie que vos données et votre accès en lecture/écriture à ces données sont répartis entre plusieurs nœuds Redis et de multiples AZ (obligatoire avec le mode cluster activé). Le rôle de nœud principal est automatiquement basculé vers l'un des réplicas en lecture. Comme ElastiCache gère cela de manière transparente, la création et la mise en service d'un nouveau nœud principal sont inutiles. Grâce à ce basculement et à la promotion d'un réplica, vous pouvez reprendre l'écriture dans le nouveau nœud principal dès que la promotion est accomplie.

Q : Mes réplicas en lecture sont-ils disponibles en cas de panne du nœud principal ?

Oui. En cas de panne du nœud principal, les réplicas en lecture continuent de répondre aux requêtes. Toutefois, une fois le nœud principal restauré (soit après réparation, soit par promotion d'un réplica en lecture), les réplicas en lecture ne peuvent répondre à aucune requête durant un court laps de temps pendant lequel ils synchronisent les informations de cache à partir du nœud principal.

Q : Comment configurer les paramètres de mes nœuds Amazon ElastiCache pour Redis ?

Vous pouvez configurer votre installation Redis à l'aide d'un groupe de paramètres de cache, que vous devez obligatoirement spécifier pour un cluster Redis. Tous les clusters de réplicas en lecture utilisent le groupe de paramètres de leur cluster principal. Un groupe de paramètres Redis agit en tant que « conteneur » pour les valeurs de configuration Redis qui peuvent être appliquées à un ou plusieurs clusters principaux Redis. Si vous créez un cluster principal Redis sans spécifier de groupe de paramètres de cache, celui par défaut est utilisé. Ce groupe par défaut contient les valeurs par défaut pour le type de nœud que vous souhaitez exécuter. Toutefois, si vous voulez que votre cluster principal Redis soit exécuté avec des valeurs de configuration spécifiques, il vous suffit de créer un nouveau groupe de paramètres de cache et de modifier les paramètres souhaités ainsi que le cluster Redis principal pour utiliser le nouveau groupe de paramètres.

Q : Puis-je accéder à Redis via la console Amazon ElastiCache ?

Oui. Redis figure comme une option de moteur dans la console Amazon ElastiCache. Vous pouvez créer un cluster de cache Redis avec l'assistant Launch Wizard en sélectionnant le moteur Redis. Vous pouvez également modifier ou supprimer un cluster Redis existant à partir de la console Amazon ElastiCache.

Q : Est-il possible de créer des clusters Amazon ElastiCache for Redis dans un VPC Amazon ?

Oui. Si votre compte correspond à un compte VPC par défaut, vos clusters Redis sont créés au sein du VPC par défaut associé à votre compte. À partir de la console Amazon ElastiCache, vous pouvez spécifier un autre VPC lorsque vous créez votre cluster.

Q : Comment puis-je sécuriser mon cluster Redis ?

Amazon ElastiCache for Redis vous propose deux méthodes pour sécuriser votre cluster Redis. Vous avez le choix entre la commande AUTH de Redis et le contrôle d'accès basé sur les rôles (RBAC) géré, qui sont toutes deux des fonctions opt-in et exigent l'activation du chiffrement en transit. La commande AUTH de Redis vous permet d'ajouter un mot de passe pour sécuriser l'accès à votre cluster Redis. Elle est prise en charge dans la version 3.2.6 et les versions ultérieures. En débutant avec Redis 6, la fonction RBAC vous permet de créer et de gérer des utilisateurs et des groupes d'utilisateurs pour sécuriser votre cluster Redis. Vous pouvez attribuer les utilisateurs à des groupes d'utilisateurs associés à un rôle spécifique (par exemple, administrateurs, ressources humaines, analytique, etc.), qui sont ensuite déployés dans un ou plusieurs groupes de réplication Amazon ElastiCache for Redis. Par cette action, vous pouvez établir des limites de sécurité entre les utilisateurs utilisant le ou les mêmes groupes de réplication Redis et empêcher les clients d'accéder aux données respectives des autres. Suivez ces liens pour en savoir plus sur les commandes Redis Auth et RBAC

Q : Comment passer à une version plus récente du moteur ?

Vous pouvez facilement passer à une version plus récente du moteur à l'aide des API ModifyCacheCluster ou ModifyReplicationGroup et en spécifiant votre version préférée du moteur pour le paramètre EngineVersion. Dans la console Amazon ElastiCache, vous pouvez sélectionner un cluster de cache ou un groupe de réplications et cliquer sur « Modifier ». Dans la fenêtre « Modify Cache Cluster » ou « Modify Replication Group », sélectionnez votre version préférée du moteur dans les options disponibles. Le processus de mise à niveau du moteur met tout en œuvre pour conserver vos données existantes et nécessite, pour ce faire, l'option de réplication Redis. Pour plus d'informations, cliquez ici.

Q : Puis-je revenir à une version précédente du moteur ?

Non. Il est impossible de revenir à une version précédente du moteur.

Q : Comment puis-je passer à un type de nœud d'une taille supérieure, ou effectuer une mise à l'échelle horizontale à d'autres nœuds ?

Dans Amazon ElastiCache for Redis, vous pouvez passer facilement à des types d'instances supérieures avec le mode cluster désactivé et effectuer une mise à l'échelle horizontale à d'autres instances avec le mode cluster activé. 

Vous pouvez facilement passer à un type de nœud d'une taille supérieure à l'aide des API ModifyCacheCluster ou ModifyReplicationGroup et en spécifiant votre type de nœud préféré pour le paramètre CacheNodeType. Dans la console Amazon ElastiCache, vous pouvez sélectionner un cluster de cache ou un groupe de réplications et cliquer sur « Modifier ». Dans la fenêtre « Modify Cache Cluster » ou « Modify Replication Group », sélectionnez votre type de nœud préféré dans les options disponibles. Le processus de mise à l'échelle met tout en œuvre pour conserver vos données existantes et nécessite, pour ce faire, l'option de réplication Redis. Pour plus d'informations, cliquez ici.

Le mode cluster vous permet d'effectuer une mise à l'échelle horizontale via l'ajout ou la suppression de partitions, à la différence d'une mise à l'échelle verticale à un seul nœud. La mise à l'échelle horizontale du cluster est simple à comprendre du côté serveur : elle consiste en l'ajout ou la suppression d'une partition. Chaque partition comprend un nœud principal et jusqu'à cinq réplicas en lecture seule. Une fois que le nouveau nœud est prêt, le cluster doit réattribuer ou équilibrer l'espace des clés entre les nœuds, selon la configuration. Avec ElastiCache for Redis, le rééquilibrage est automatique.

Q :Quelle métrique dois-je utiliser pour mesurer l'utilisation par Redis ?

Amazon ElastiCache fournit deux métriques pour mesurer l'utilisation du processeur pour les charges de travail Amazon ElastiCache for Redis : EngineCPUUtilization et CPUUtilization. La métrique CPUUtilization mesure l'utilisation du processeur pour l'instance (nœud) et la métrique EngineCPUUtilization mesure l'utilisation au niveau du processus Redis. Vous aurez besoin de la métrique EngineCPUUtilization en plus de la métrique CPUUtilization car le processus Redis principal n'a qu'un seul thread et n'utilise qu'un seul processeur parmi les multiples cœurs de processeur disponibles sur une instance. Par conséquent, la métrique CPUUtilization ne fournit pas une visibilité précise sur les taux d'utilisation du processeur au niveau du processus Redis. 

Nous vous recommandons d'utiliser à la fois les métriques CPUUtilization et EngineCPUUtilization pour avoir une compréhension détaillée de l'utilisation du processeur pour vos clusters Redis. Les deux métriques sont disponibles dans toutes les régions AWS et vous pouvez accéder à ces métriques à l'aide de CloudWatch ou via la console de gestion AWS.

Outre l'utilisation du processeur, Amazon ElastiCache for Redis ajoute le traitement de réseau dynamique pour améliorer la gestion des E/S dans les versions Redis 5.0.3 et ultérieures. En exploitant la puissance de CPU supplémentaire disponible dans les nœuds d'au moins 4 vCPU, ElastiCache permet une augmentation du débit jusqu'à 83 % et une réduction de la latence par nœud jusqu'à 47 %. Consultez le blog : Amélioration de la performance de l'application et réduction des coûts avec Amazon ElastiCache for Redis

Q : Puis-je avoir des réplicas sur plusieurs régions avec Amazon ElastiCache for Redis ?

Oui, vous pouvez créer des réplicas sur plusieurs régions grâce à la fonction Global Datastore dans Amazon ElastiCache for Redis. Global Datastore fournit une réplication entre régions entièrement gérée, rapide, fiable et sécurisée. Cette fonction vous permet d'écrire dans votre cluster Amazon ElastiCache for Redis dans une région et de proposer ces données en lecture dans deux autres clusters maximum entre régions, ce qui réduit la latence de lecture et de reprise après sinistre entre régions.


Q : En quoi consiste l'exécution d'un nœud Redis en tant que réplica en lecture ?

Dans Redis, les réplicas en lecture sont utilisés de deux manières :

  • Gestion des pannes
  • Dimensionnement en lecture

Lorsque vous exécutez un nœud de cache avec un réplica en lecture, le « nœud principal » est utilisé à la fois pour la lecture et l'écriture. Le réplica en lecture sert de nœud de « secours », qui est « promu » dans le cas de scénarios de basculement. Après le basculement, le nœud de secours devient le nœud principal et accepte vos opérations de cache. Les réplicas en lecture facilitent également la mise à l'échelle flexible au-delà des contraintes de capacité d'un seul nœud de cache, afin d'exécuter les charges de travail du cache qui nécessitent de très nombreuses lectures.

Q : Quand envisager l'utilisation d'un réplica en lecture Redis ?

Il existe divers scénarios où le déploiement d'un ou plusieurs réplicas en lecture pour un nœud principal donné est recommandé. Les principales raisons d'un déploiement de réplica en lecture sont les suivantes :

  • Le dimensionnement au-delà de la capacité de calcul ou d'E/S d'un seul nœud principal pour des charges de travail à forte densité de lecture. Ce trafic en lecture excessif peut alors être dirigé vers un ou plusieurs réplicas en lecture.
  • La prise en charge du trafic en lecture en cas d'indisponibilité du nœud principal. Si votre nœud principal ne peut pas prendre en charge les demandes d'E/S (par ex. en raison de la suspension des E/S à des fins de sauvegarde ou de maintenance planifiée), vous pouvez diriger le trafic en lecture vers vos réplicas en lecture. Dans ce type de cas d'utilisation, gardez à l'esprit le fait que les données sur le réplica en lecture peuvent être « périmées », étant donné que le nœud principal est indisponible. Le réplica en lecture peut aussi servir à relancer un préchauffage du nœud principal en échec.
  • À des fins de protection des données et dans le cas peu probable d'une défaillance du nœud principal ou d'une indisponibilité de la zone de disponibilité dans laquelle réside votre nœud principal, vous pouvez promouvoir, en tant que nouveau nœud principal, un réplica en lecture figurant dans une autre zone de disponibilité.
Q : Comment déployer un nœud de réplica en lecture pour un nœud principal spécifique ?
 
Vous pouvez créer un réplica en lecture en quelques minutes au moyen de l'API CreateReplicationGroup ou en quelques clics sur la console de gestion Amazon ElastiCache. Lorsque vous créez un groupe de réplications, vous spécifiez la valeur MasterCacheClusterIdentifier. Cette valeur MasterCacheClusterIdentifier est l'identifiant du cluster de cache « principal » à partir duquel vous souhaitez effectuer la réplication. Vous pouvez ensuite créer le cluster des réplicas en lecture au sein du même groupe de réplications en appelant l'API CreateCacheCluster et en spécifiant les valeurs ReplicationGroupIdentifier et CacheClusterIdentifier du cluster principal. Comme pour un cluster de cache standard, vous pouvez également définir la zone de disponibilité. Lorsque vous lancez la création d'un réplica en lecture, Amazon ElastiCache prend un instantané de votre cluster de cache principal et commence la réplication. En conséquence, vous rencontrerez une brève suspension des E/S sur votre cluster de cache principal au moment où l'instantané est pris. Cette suspension des E/S ne dure généralement qu'une minute environ.

Les réplicas en lecture sont aussi faciles à supprimer qu'à créer : il vous suffit d'utiliser la console de gestion d'Amazon ElastiCache ou d'appeler l'API DeleteCacheCluster (en spécifiant la valeur CacheClusterIdentifier du réplica en lecture que vous souhaitez supprimer).

Q : Puis-je créer simultanément un nœud principal et des réplicas en lecture ?
 
Oui. Vous pouvez créer un cluster de cache et des réplicas en lecture en quelques minutes à l'aide de l'API CreateReplicationGroup ou de l'assistant « Create » et de l'option « multi-AZ Replication » sur la console de gestion Amazon ElastiCache. Lors de la création du cluster, indiquez un identifiant, le nombre total de partitions souhaité dans un cluster et de réplicas en lecture par partition, ainsi que les paramètres de création tels que le type de nœud, la version du moteur, etc. Vous pouvez également spécifier la zone de disponibilité de chaque partition du cluster.
 
Q : Comment me connecter à mon/mes réplica(s) en lecture ?
 
Vous pouvez vous connecter à un réplica en lecture de la même manière qu'à un nœud de cache principal, en utilisant l'API DescribeCacheClusters ou la console de gestion AWS pour récupérer le ou les points de terminaison de votre ou de vos réplicas en lecture. Si vous avez plusieurs réplicas en lecture, c'est votre application qui détermine comment le trafic en lecture sera distribué entre eux. Voici d’autres détails :
 
  • Les clusters Redis (mode cluster désactivé) utilisent les points de terminaison de nœuds individuels pour les opérations de lecture (dans l’API/la CLI, ils sont désignés sous le terme Points de terminaison en lecture).
  • Les clusters Redis (mode cluster activé) utilisent le point de terminaison de configuration pour toutes les opérations. Vous devez utiliser un client qui prend en charge Redis Cluster (Redis 3.2). Vous pouvez continuer à lire des points de terminaison de nœuds individuels (dans l'API/la CLI, ils sont désignés sous le terme Points de terminaison en lecture).
Q : Combien de réplicas en lecture puis-je créer pour un nœud principal donné ?
 
À l'heure actuelle, Amazon ElastiCache vous permet de créer jusqu'à cinq (5) réplicas en lecture pour un nœud de cache principal donné.
 
Q : Qu'advient-il des réplicas en lecture en cas de basculement ?
 
En cas de basculement, tout réplica en lecture associé et disponible doit reprendre la réplication automatique une fois le basculement terminé (avec acquisition des mises à jour depuis le réplica en lecture nouvellement promu).
 
Q : Puis-je créer un réplica en lecture d'un autre réplica en lecture ?
 
La création du réplica en lecture d'un autre réplica en lecture n'est pas prise en charge.
 
Q : Puis-je transformer mon réplica en lecture en nœud principal « autonome » ?
 
Non. Cette fonctionnalité n'est pas prise en charge. En revanche, vous pouvez prendre un instantané de votre nœud Amazon ElastiCache for Redis (vous pouvez sélectionner le nœud principal ou l'un de ses réplicas en lecture). Vous pouvez ensuite utiliser cet instantané pour créer un nouveau nœud principal Amazon ElastiCache for Redis.
 
Q : Mon réplica en lecture sera-t-il tenu à jour par rapport à son nœud principal ?
 
Les mises à jour appliquées au nœud de cache principal sont immédiatement répliquées sur les réplicas en lecture associés. Toutefois, avec la technologie de réplication asynchrone de Redis, un réplica en lecture peut prendre du retard par rapport à son nœud de cache principal pour diverses raisons. Les raisons typiques incluent :
 
  • Le volume des E/S en écriture sur le nœud de cache principal est supérieur au rythme auquel les modifications peuvent être appliquées sur le réplica en lecture
  • Des partitions ou des temps de latence réseau existent entre le nœud de cache principal et un réplica en lecture

Les réplicas en lecture sont sujets aux forces et aux faiblesses de la réplication Redis. Si vous utilisez des réplicas en lecture, vous devez être conscient du risque de retard entre un réplica en lecture et son nœud de cache principal ou d'une possible « incohérence ». Amazon ElastiCache émet une métrique pour vous aider à comprendre l'incohérence.

Q : Comment gagner en visibilité sur les réplicas en lecture actifs ?
 
Vous pouvez utiliser l'API DescribeCacheClusters standard pour renvoyer la liste de tous les clusters de cache que vous avez déployés (y compris les réplicas en lecture), ou cliquer simplement sur l'onglet « Cache Clusters » de l'Amazon ElastiCache Management Console.
 
Amazon ElastiCache surveille le statut de réplication de vos réplicas en lecture et met à jour le champ Replication State avec la valeur Error si la réplication est interrompue pour une raison quelconque. Vous pouvez consulter les détails de l'erreur en question, renvoyée par le moteur Redis, dans le champ Replication Error et, ainsi, effectuer l'opération de récupération appropriée. Pour en savoir plus sur la résolution des problèmes de réplication, consultez la section « Troubleshooting a Read Replica problem » dans le Guide de l'utilisateur Amazon ElastiCache. Lorsqu'une erreur de réplication est résolue, le champ Replication State présente la valeur Replicating.

Amazon ElastiCache vous permet de voir à quel point un réplica en lecture a pris du retard par rapport au nœud principal par le biais de la mesure Amazon CloudWatch (« Replica Lag ») accessible à partir de l'AWS Management Console ou des API Amazon CloudWatch.

Q : Mon réplica en lecture a pris beaucoup de retard par rapport à son nœud principal. Que dois-je faire ?
 
Comme évoqué dans les questions précédentes, une « incohérence » ou un retard entre un réplica en lecture et son nœud de cache principal est courant avec la réplication asynchrone Redis. Si un réplica en lecture a pris beaucoup trop de retard et ne satisfait plus à vos exigences, vous pouvez le redémarrer. Gardez également à l'esprit le fait que le retard du réplica peut augmenter et diminuer naturellement avec le temps, en fonction du modèle d'utilisation continue de votre nœud de cache principal.
 
Q : Comment supprimer un réplica en lecture ? Sera-t-il supprimé automatiquement si son nœud principal est supprimé ?
 
Vous pouvez facilement supprimer un réplica en lecture en quelques clics sur la console de gestion AWS ou en utilisant les API DeleteCacheCluster ou DecreaseReplicaCount. Si vous souhaitez supprimer le réplica en lecture en plus du nœud de cache principal, vous devez utiliser l'API DeleteReplicationGroup ou la console de gestion AWS.
 
Q : Combien coûtent les réplicas en lecture ? Quelles sont les dates de début et de fin de facturation ?
 
Un réplica en lecture est facturé comme un nœud de cache standard et aux mêmes tarifs. Comme pour un nœud de cache standard, le tarif par « heure de nœud de cache » pour un réplica en lecture est déterminé par sa classe de nœud de cache ; consultez la page de présentation d'Amazon ElastiCache pour connaître les derniers tarifs en vigueur. Les frais de transfert lors de la réplication des données entre votre nœud de cache principal et le réplica en lecture ne vous sont pas facturés. La facturation du réplica en lecture débute dès sa création (c.-à-d. lorsque le statut indiqué est « active »). Le réplica en lecture continuera de vous être facturé aux tarifs horaires d'un nœud de cache Amazon ElastiCache standard jusqu'à ce que vous exécutiez une commande pour le supprimer.
 
Q : Que se passe-t-il au cours du basculement et combien de temps cela dure-t-il ?
 
Le basculement initié est pris en charge par Amazon ElastiCache afin que vous puissiez reprendre les opérations de cache aussi rapidement que possible. Lors du basculement, Amazon ElastiCache modifie simplement l'enregistrement DNS de votre nœud de cache afin qu'il pointe vers le réplica en lecture, lequel est alors promu comme nouveau nœud principal. Nous vous encourageons à suivre les bonnes pratiques et à effectuer une nouvelle tentative de connexion au nœud de cache au niveau de la couche applicative. En règle générale, 6 minutes suffisent pour réaliser les étapes 1 à 5 ci-dessous.
 
Ce sont des événements de basculement automatique répertoriés dans l'ordre dans lequel ils se produisent  :
 
  1. Message de groupe de réplications : Test de l'API de basculement appelé pour un groupe de nœuds <node-group-id>
  2. Message de cluster de cache : Basculement accompli d'un nœud principal <primary-node-id> vers un réplica <node-id>
  3. Message de groupe de réplications : Basculement accompli d'un nœud principal <primary-node-id> vers un réplica <node-id>
  4. Message de cluster de cache : Récupération de nœuds de cache <node-id>
  5. Message de cluster de cache : Récupération de nœuds de cache terminée <node-id>
Q : Puis-je créer un réplica en lecture dans une région différente de celle de mon nœud principal ?
 
 
Non. Votre réplica en lecture peut uniquement être mis en service au sein d'une zone de disponibilité (identique ou non) appartenant à la même région que celle de votre nœud de cache principal.
 
Par contre, vous pouvez utiliser le Global Datastore for Redis pour exécuter une réplication entièrement gérée, rapide, fiable et sûre entre des régions AWS. Grâce à cette fonction, vous pouvez créer des clusters de réplicas en lecture entre régions pour ElastiCache for Redis afin de réduire la latence de lecture et de reprise après sinistre entre des régions AWS.
 
Q : Puis-je voir dans quelle zone de disponibilité mon instance principale est située actuellement ?
 
Oui. Vous pouvez avoir accès à l'emplacement du nœud principal actuel en utilisant l'AWS Management Console ou l'API DescribeCacheClusters.
 
Après un basculement, mon instance principale se trouve désormais dans une zone de disponibilité différente de mes autres ressources AWS (par ex. instances EC2).
 
Q : Dois-je m'inquiéter des temps de latence ?
 
Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région. En outre, vous pourriez envisager d'avoir une architecture avec redondance pour votre application et d'autres ressources AWS parmi des zones de disponibilité multiples, afin que votre application soit résiliente en cas de défaillance d'une zone de disponibilité.
 
Q : Puis-je ajouter et supprimer des nœuds de réplica en lecture pour mon environnement Redis Cluster ?
 
Oui. Vous pouvez ajouter et supprimer un réplica dans une ou plusieurs partitions dans un environnement Redis Cluster. Le cluster reste en ligne et traite les E/S entrantes pendant cette opération.

Q : En quoi consiste la fonction multi-AZ pour un groupe de réplications Amazon ElastiCache for Redis ?

Un groupe de réplications Amazon ElastiCache for Redis comprend un nœud principal et jusqu'à cinq réplicas en lecture seule. Si la fonction multi-AZ est activée, un seul réplica correspond à chaque nœud principal. Consulter la section Basculement automatique. Redis réplique de manière asynchrone les données du nœud principal vers les réplicas en lecture. Lors de l'exécution de certains types de maintenance planifiée ou dans le cas peu probable de la défaillance d'un nœud Amazon ElastiCache ou d'une zone de disponibilité, Amazon ElastiCache détecte automatiquement la défaillance d'un nœud principal, sélectionne un réplica en lecture et le définit comme nœud principal. Amazon ElastiCache propage également les modifications DNS du réplica en lecture promu. Si votre application effectue des opérations en écriture sur le point de terminaison du nœud principal, aucune modification du point de terminaison n'est donc nécessaire.

Q : Quels sont les avantages de l'utilisation de la fonction multi-AZ et quand doit-on l'utiliser ?

Les principaux avantages de l'exécution d'Amazon ElastiCache for Redis en mode multi-AZ résident dans l'amélioration de la disponibilité et la réduction des tâches d'administration. Si un nœud principal Amazon ElastiCache for Redis tombe en panne, l'impact sur les opérations en lecture/écriture sur le nœud principal est limité à la durée de mise en place du basculement automatique. Lorsque la fonction multi-AZ est activée, le basculement de nœud Amazon ElastiCache est automatique et ne nécessite pas d'administration. Vous n'avez plus besoin de surveiller vos nœuds Redis et de lancer une récupération manuelle en cas de défaillance de nœud principal.

Q : Comment la fonction multi-AZ fonctionne-t-elle ?

Vous pouvez avoir recours à la fonction multi-AZ si vous utilisez Amazon ElastiCache for Redis et disposez d'un groupe de réplications composé d'un nœud principal et d'un ou de plusieurs réplicas en lecture. En cas de défaillance du nœud principal, Amazon ElastiCache détecte automatiquement la panne, sélectionne un réplica en lecture parmi les nœuds disponibles et le promeut en tant que nouveau nœud principal. Amazon ElastiCache propage les modifications DNS du réplica promu pour que votre application puisse continuer à effectuer des opérations en écriture sur le point de terminaison du nœud principal. Amazon ElastiCache fait également tourner un nouveau nœud pour remplacer le réplica en lecture promu dans la même zone de disponibilité que le nœud principal défaillant. En cas de défaillance du nœud principal en raison d'une indisponibilité temporaire de la zone de disponibilité, le nouveau réplica est lancé une fois la zone de disponibilité remise en service.

Q : Des réplicas peuvent-ils se trouver dans la même zone de disponibilité que le nœud principal ?

Oui. Le placement du nœud principal et du ou des réplicas dans une même zone de disponibilité ne permet toutefois pas de rendre votre groupe de réplications Amazon ElastiCache for Redis résilient en cas d'indisponibilité d'une zone de disponibilité. En outre, cela n'est pas autorisé si la fonction multi-AZ est activée.

Q : À la suite de quels événements Amazon ElastiCache procède-t-il au basculement vers un réplica en lecture ?

Amazon ElastiCache procède au basculement vers un réplica en lecture dès lors qu'un des événements suivants se produit :

  • Perte de disponibilité dans la zone de disponibilité du nœud principal
  • Perte de connectivité réseau avec le serveur principal
  • Échec d'unité de calcul sur le serveur principal
Q : Dans quel cas dois-je utiliser la fonction multi-AZ ?
 
L'utilisation conjointe de la réplication Redis et de la fonction multi-AZ améliore la disponibilité et la tolérance aux pannes. Les déploiements de ce type constituent un choix naturel pour les environnements de production.
 
Q : Comment puis-je créer un groupe de réplications Amazon ElastiCache for Redis avec la fonction multi-AZ activée ?
 
Vous pouvez créer un nœud principal Amazon ElastiCache for Redis et des réplicas en lecture en cliquant sur Launch Cache Cluster dans la console de gestion ElastiCache. Vous pouvez également le faire en appelant l' API CreateReplicationGroup. Pour les groupes de réplications existants (Redis 2.8.24, 2.8.23, 2.8.22, 2.8.21, 2.8.19 et 2.8.6), vous pouvez activer la fonction multi-AZ en procédant comme suit : sélectionnez un groupe de réplications et cliquez sur « Modifier » dans la console de gestion d'Amazon ElastiCache, ou utilisez l' API ModifyReplicationGroup. Faire basculer un groupe de réplication vers multi-AZ ne perturbe pas vos données Redis et n'interfère pas avec la capacité de vos nœuds à répondre aux demandes.
 
Q : En cas de défaillance du nœud principal, quel réplica en lecture est promu ?

S'il existe plusieurs réplicas en lecture, c'est celui dont le retard de réplication asynchrone est le plus court sur le nœud principal qui est promu.

Q : Que coûte l'utilisation de la fonction multi-AZ ?

La fonction multi-AZ est gratuite. Vous payez uniquement pour les nœuds Amazon ElastiCache que vous utilisez.

Q : Quelles sont les répercussions de la fonction multi-AZ sur les performances ?

Amazon ElastiCache utilise actuellement la réplication asynchrone native du moteur Redis et profite de ses points forts, mais subit aussi ses limites. En particulier, lorsqu'un réplica en lecture se connecte à un nœud principal pour la première fois, ou si le nœud principal change, le réplica en lecture effectue une synchronisation complète des données du nœud principal, imposant ainsi la charge au nœud principal et à lui-même. Pour en savoir plus sur la réplication Redis, cliquez ici.

Q : Quels types de nœuds prennent en charge la fonction multi-AZ ?

Tous les types de nœuds de cache disponibles dans Amazon ElastiCache prennent en charge la fonction multi-AZ, à l'exception de la famille de nœuds T1.

Q : Serai-je averti en cas de basculement automatique ?

Oui. Amazon ElastiCache crée un événement pour vous informer qu'un basculement automatique a eu lieu. Vous pouvez utiliser l'API DescribeEvents pour renvoyer des informations sur des évènements en lien avec votre nœud Amazon ElastiCache, ou cliquer sur la section Events de la console de gestion Amazon ElastiCache.

Q : Après un basculement, mon instance principale se trouve désormais dans une zone de disponibilité différente de celle de mes autres ressources AWS (instances EC2, par exemple). Dois-je m'inquiéter des temps de latence ?

Les zones de disponibilité sont conçues pour fournir une connectivité réseau à faible latence vers les autres zones de disponibilité de la même région. Vous pourriez envisager d'adopter une architecture avec redondance sur plusieurs zones de disponibilité pour votre application et d'autres ressources AWS, afin que votre application soit résiliente en cas de défaillance sur une zone de disponibilité spécifique.

Q : Où puis-je trouver des informations supplémentaires sur la fonction multi-AZ ?

Pour plus d'informations sur la fonction multi-AZ, consultez la documentation Amazon ElastiCache.


Q : En quoi consiste la fonction de sauvegarde et de restauration ?

La fonction de sauvegarde et de restauration permet aux clients de créer des instantanés de leurs clusters Amazon ElastiCache for Redis. Amazon ElastiCache conserve ces instantanés et les utilisateurs peuvent les exploiter par la suite afin de restaurer leurs clusters Redis.

Q : Qu'est-ce qu'un instantané ?

Un instantané est une copie de l'ensemble de votre cluster Redis à un moment donné.

Q : Quelle est l'utilité des instantanés ?

Il peut être utile de créer des instantanés en prévision d'une perte de données consécutive à la défaillance d'un nœud ou d'une panne matérielle, bien que ce dernier cas soit peu probable. Les sauvegardes sont aussi souvent utilisées à des fins d'archivage. Les instantanés sont conservés dans Amazon S3, qui garantit un stockage durable. Cela signifie que, même en cas de panne d'alimentation, vos données ne sont pas perdues.

Q : Que puis-je faire avec un instantané ?

Vous pouvez utiliser des instantanés pour effectuer le démarrage à chaud d'un cluster Amazon ElastiCache for Redis incluant des données préchargées.

Q : Quel est le mode opératoire de la fonction de sauvegarde et de restauration ?

Lorsqu'une sauvegarde est lancée, Amazon ElastiCache prend un instantané du cluster Redis spécifié à des fins de restauration ou d'archivage. Vous pouvez lancer une sauvegarde quand vous le souhaitez ou définir une sauvegarde quotidienne récurrente, avec une période de conservation des données de 35 jours maximum.

Une fois que vous avez choisi l'instantané à partir duquel effectuer la restauration, un nouveau cluster Amazon ElastiCache for Redis est créé et alimenté à partir des données de l'instantané. Vous pouvez ainsi créer plusieurs clusters ElastiCache for Redis à partir d'un même instantané.

Q : Où sont stockés les instantanés ?

Les instantanés sont conservés dans Amazon S3.

Q : Comment lancer la fonction de sauvegarde et de restauration ?

Vous pouvez lancer la fonction de sauvegarde et de restauration via la console de gestion AWS, les API Amazon ElastiCache (CreateCacheCluster, ModifyCacheCluster, CreateReplicationGroup et ModifyReplicationGroup) ou l'interface de ligne de commande (CLI). Vous pouvez désactiver et réactiver cette fonction à tout moment.

Q : Comment spécifier le cluster ou le nœud Redis à sauvegarder ?

La fonction de sauvegarde et de restauration crée des instantanés sur la base d'un cluster. Il est possible de définir le cluster ElastiCache for Redis à sauvegarder à partir de l'AWS Management Console, ou en utilisant l'interface de ligne de commande ou l'API CreateSnapshot. Au sein d'un groupe de réplication, vous pouvez choisir de sauvegarder le cluster principal ou l'un des clusters de réplicas en lecture. Nous recommandons d'activer la fonction de sauvegarde sur l'un des réplicas en lecture, afin d'éviter tout impact négatif en termes de temps de latence sur le nœud principal Redis.

Q : Comment préciser quand la sauvegarde doit être lancée ?

Vous pouvez préciser quand lancer une sauvegarde ponctuelle ou une sauvegarde récurrente dans l'AWS Management Console, ou en utilisant l'interface de ligne de commande ou les API. Voici les différentes opérations possibles :

  • Vous pouvez prendre immédiatement un instantané (bouton « Backup » dans l'onglet « Redis » de la console ou API CreateSnapshot)
  • Vous pouvez configurer une sauvegarde quotidienne automatique. La sauvegarde s'effectuera durant la plage de sauvegarde préconisée. Cette option peut être paramétrée lors de la création/modification du cluster via la console ou à l'aide des API CreateCacheCluster, ModifyCacheCluster ou ModifyReplicationGroup.
Q : Qu'est-ce qu'une fenêtre de sauvegarde et pourquoi en ai-je besoin ?
 
La plage de sauvegarde préconisée est la période définie par l'utilisateur durant laquelle la sauvegarde de votre cluster Amazon ElastiCache for Redis se lance. Elle est utile si vous souhaitez que la sauvegarde intervienne à une heure précise ou qu'elle ne se lance pas lors de périodes d'utilisation particulièrement intensive.
 
Q : Quel est l'impact sur les performances lors de la capture d'un instantané ?
 
Lors de la capture d'un instantané, il est possible que vous observiez, au niveau du nœud, des temps de latence supérieurs durant un court laps de temps. Les instantanés exploitent la commande BGSAVE intégrée à Redis et profitent donc de ses atouts, mais sont aussi limités par ses faiblesses. Ainsi, le processus Redis se subdivise, le parent continuant à répondre aux requêtes, tandis que l'enfant sauvegarde les données sur le disque avant de se fermer. Cette subdivision augmente l'utilisation de la mémoire durant la génération de l'instantané. Lorsque l'utilisation de la mémoire dépasse la mémoire disponible du nœud de cache, une permutation peut être déclenchée, ralentissant encore davantage le nœud. C'est pourquoi nous vous recommandons de générer les instantanés à partir de l'un des réplicas en lecture (et non du nœud principal). De plus, nous vous suggérons de définir le paramètre relatif à la mémoire réservée afin de minimiser l'utilisation de la permutation. Cliquez ici pour obtenir plus d'informations.
 
Q : Puis-je créer un instantané à partir d'un réplica en lecture Amazon ElastiCache for Redis ?
 
Oui. Dans un groupe de réplications avec le mode cluster désactivé, la création d'un instantané à partir d'un réplica en lecture est le meilleur moyen de sauvegarder vos données tout en limitant l'impact sur les performances. Dans un groupe de réplications avec le mode cluster activé, vous pouvez choisir de sauvegarder le cluster principal ou l'un des clusters de réplicas en lecture.
 
Q : Dans quelles régions la fonction de sauvegarde et de restauration est-elle disponible ?
 
La fonction de sauvegarde et de restauration est disponible dans toutes les régions où le service ElastiCache est disponible.
 
Q : Puis-je exporter des instantanés Amazon ElastiCache for Redis vers un compartiment S3 que je possède ?
 
Oui. Vous pouvez exporter vos instantanés Amazon ElastiCache for Redis vers un compartiment S3 autorisé dans la même région que votre cluster. Pour plus d'informations sur l'exportation d'instantanés et la configuration des autorisations nécessaires, consultez cette page.
 
Q : Puis-je copier des instantanés d'une région vers une autre ?
 
Oui. Vous devez tout d'abord copier votre instantané (snapshot) vers un bucket (compartiment) S3 autorisé de votre choix dans la même région, puis utiliser l'API S3 PUT object- Copy pour le copier vers un bucket dans une autre région. Pour plus d'informations sur la copie d'objets S3, consultez cette page.
 
Q : Je possède plusieurs comptes AWS utilisant Amazon ElastiCache for Redis. Puis-je utiliser les instantanés Amazon ElastiCache d'un compte pour effectuer le démarrage à chaud d'un cluster Amazon ElastiCache for Redis dans un autre compte ?
 
Oui. Vous devez d'abord copier votre instantané (snapshot) dans un bucket (compartiment) S3 autorisé dans la même région, puis accorder des permissions de bucket inter-comptes à l'autre compte. Pour plus d'informations sur les autorisations S3 entre comptes, consultez cette page. Enfin, vous pouvez préciser l'emplacement S3 de votre fichier RDB lors de la création du cluster, via l'assistant Launch Cache Cluster de la console, ou par l'API CreateCacheCluster.
 
Q : Quel est le coût de la fonction de sauvegarde et de restauration ?
 
Amazon ElastiCache offre un espace de stockage gratuit pour un instantané de chacun de vos clusters Amazon ElastiCache for Redis actifs. Tout stockage supplémentaire vous est facturé selon l'espace utilisé par les instantanés sur la base de 0,085 USD/Go chaque mois (tarif identique dans toutes les régions). Le transfert des données est gratuit dans le cadre de l'utilisation d'instantanés.
 
Q : En quoi consiste la période de rétention ?
 
La période de rétention correspond à la durée pendant laquelle les instantanés automatiques sont conservés. Par exemple, si la période de rétention est définie sur 5, un instantané pris aujourd'hui est conservé durant 5 jours avant d'être supprimé. Vous pouvez choisir de copier un ou plusieurs instantanés automatiques afin de les stocker comme des instantanés manuels qui ne seront pas supprimés à l'issue de la période de rétention.
 
Q : Comment gérer la rétention de mes instantanés automatiques ?
 
Vous pouvez utiliser la console de gestion AWS ou l'API ModifyCreateCluster ou ModifyReplicationGroup pour gérer la durée pendant laquelle vos sauvegardes automatiques sont conservées via le paramètre RetentionPeriod. Si vous souhaitez désactiver complètement les sauvegardes automatiques, vous pouvez définir la période de rétention sur 0 (bien que cette option ne soit pas recommandée).
 
Q : Que deviennent mes instantanés si je supprime mon cluster Amazon ElastiCache for Redis ?
 
Lorsque vous supprimez un cluster Amazon ElastiCache for Redis, vos instantanés manuels sont conservés. Vous avez également la possibilité de créer un instantané final de votre cluster avant sa suppression. En revanche, les instantanés mis en cache automatiquement ne sont pas conservés.
 
Q : Quels types de nœud de cache prennent en charge la fonction de sauvegarde et de restauration ?
 
Hormis les nœuds de type t1.micro, tous les nœuds exécutant une instance Amazon ElastiCache for Redis prennent en charge la fonction de sauvegarde et de restauration :
 
Nœuds de cache de la génération actuelle :
 
  • cache.m4.large
  • cache.m4.xlarge
  • cache.m4.2xlarge
  • cache.m4.4xlarge
  • cache.m4.10xlarge
  • cache.m5.large
  • cache.m5.xlarge
  • cache.m5.2xlarge
  • cache.m5.4xlarge
  • cache.m5.12xlarge
  • cache.m5.24xlarge
  • cache.m6g.large
  • cache.m6g.xlarge
  • cache.m6g.2xlarge
  • cache.m6g.4xlarge
  • cache.m6g.8xlarge
  • cache.m6g.12xlarge
  • cache.m6g.16xlarge
  • cache.r4.large
  • cache.r4.xlarge
  • cache.r4.2xlarge
  • cache.r4.4xlarge
  • cache.r4.8xlarge
  • cache.r4.16xlarge
  • cache.r5.large
  • cache.r5.xlarge
  • cache.r5.2xlarge
  • cache.r5.4xlarge
  • cache.r5.12xlarge
  • cache.r5.24xlarge
  • cache.r6g.large
  • cache.r6g.xlarge
  • cache.r6g.2xlarge
  • cache.r6g.4xlarge
  • cache.r6g.8xlarge
  • cache.r6g.12xlarge
  • cache.r6g.16xlarge
  • cache.t2.medium
  • cache.t2.small
  • cache.t2.micro
  • cache.t3.medium
  • cache.t3.small
Nœuds de la génération précédente :
 
  • cache.m1.small
  • cache.m1.medium
  • cache.m1.large 
  • cache.m1.xlarge 
  • cache.m2.xlarge 
  • cache.m2.2xlarge 
  • cache.m2.4xlarge
  • cache.m3.medium
  • cache.m3.large 
  • cache.m3.xlarge
  • cache.m3.2xlarge 
  • cache.r3.large 
  • cache.r3.xlarge 
  • cache.r3.2xlarge
  • cache.r3.4xlarge
  • cache.r3.8xlarge
  • cache.c1.xlarge
Q : Puis-je utiliser mes propres instantanés RDB stockés dans S3 pour effectuer le démarrage à chaud d'un cluster Amazon ElastiCache for Redis ?
 
Oui. Vous pouvez préciser l'emplacement S3 de votre fichier RDB lors de la création du cluster, via l'assistant Create Cluster de la console ou à l'aide de l'API CreateCacheCluster ou CreateReplicationGroup.
 
Q : Puis-je utiliser la fonction de sauvegarde et de restauration si j'exécute Amazon ElastiCache dans un VPC ?
 
Oui.

Q : Qu'est-ce qu'ElastiCache for Redis Cluster ?

ElastiCache for Redis Cluster permet aux clients de créer et d'exécuter des clusters Redis gérés avec plusieurs partitions. Le service est compatible avec le système open source Redis 3.2.4 et versions ultérieures, et intègre un certain nombre d'améliorations pour offrir une expérience plus stable et plus fiable (consultez la section « Moteur amélioré » ci-dessous pour en savoir plus sur ces améliorations).

Q : Pourquoi devrais-je mettre à l'échelle l'environnement Redis ?

Trois principaux scénarios sont possibles pour exécuter un environnement Redis mis à l'échelle. Premièrement, si la taille totale de la mémoire de vos données Redis dépasse ou devrait dépasser la capacité de mémoire d'une machine virtuelle unique. Deuxièmement, si le débit d'écriture de votre application dans Redis dépasse la capacité d'une machine virtuelle unique. Troisièmement, si vous souhaitez répartir les données entre plusieurs partitions afin que tout problème potentiel rencontré avec un nœud ait un impact moindre sur l'environnement Redis global.

Q : Pourquoi exécuter ma charge de travail Redis Cluster sur Amazon ElastiCache ?

Amazon ElastiCache offre un environnement Redis en mémoire distribué et entièrement géré, de la mise en service des ressources de serveur à l'installation du logiciel du moteur et à l'application des paramètres de configuration que vous choisissez. Le service utilise les améliorations apportées au moteur Redis développé par Amazon pour offrir une expérience plus fiable et plus stable (consultez la section « Moteur amélioré » pour en savoir plus). Une fois que votre environnement est opérationnel, le service automatise les tâches administratives courantes telles que la détection des pannes, la restauration et l'application des patchs de logiciel. Il offre également une solution Multi-AZ fiable avec basculement automatique. En cas de défaillance d'un ou de plusieurs nœuds principaux de votre cluster, Amazon ElastiCache détecte automatiquement la défaillance et y répond en promouvant le réplica le plus à jour au poste de nœud principal. Ce processus est automatisé et n'exige aucune intervention manuelle de votre part. Amazon ElastiCache fournit également des métriques de surveillance détaillées associées à vos nœuds ElastiCache, ce qui vous permet de diagnostiquer et de réagir aux problèmes très rapidement.

Q : Le service ElastiCache pour Redis Cluster est-il compatible avec le système open source Redis ?

Oui. La version Amazon ElastiCache pour Redis Cluster est compatible avec les systèmes open source Redis 3.2.4 et versions ultérieures. Vous pouvez utiliser les clients du système open source Redis Cluster pour accéder à des clusters de dimensionnement sur ElastiCache pour Redis.

Q : Quelle est la marche à suivre pour passer de la version actuelle d'ElastiCache pour Redis (version 2.8.x) à ElastiCache pour Redis Cluster (version 3.2.4) ?

Si vous utilisez Redis 3.2 avec le paramètre cluster_mode désactivé, il vous suffit de choisir le nœud ou le cluster que vous souhaitez mettre à niveau et de modifier la version du moteur. ElastiCache met en service un cluster Redis 3.2.4 et migre vos données vers ce dernier, tout en conservant le point de terminaison.

Si vous utilisez Redis 3.2 avec le paramètre cluster_mode activé, vous pouvez migrer vers Redis Cluster en créant d'abord un instantané de vos données à l'aide de la fonction de sauvegarde ou de restauration. Sélectionnez ensuite l'instantané créé et cliquez sur « Restore Snapshot » pour créer un cluster Redis 3.2 à l'aide des données de l'instantané. Enfin, mettez à jour le nouveau point de terminaison sur votre client. Notez que pour utiliser Redis 3.2 en mode cluster, vous devrez passer à un client Redis Cluster.

Q : La tarification de la configuration en cluster est-elle différente de celle de la configuration sans cluster ?

Non. Amazon ElastiCache pour Redis donne la possibilité d'opter pour une configuration en cluster ou sans cluster au même prix. Les clients peuvent désormais profiter de la fonctionnalité du moteur amélioré dans Amazon ElastiCache pour Redis et utiliser la prise en charge complète de la fonctionnalité pour bénéficier d'une configuration en cluster et d'une excellente évolutivité au même prix. 

Q : Qu'est-ce que la fonction Multi-AZ pour ElastiCache pour Redis Cluster ?

Chaque partition d'un cluster ElastiCache pour Redis comprend un nœud principal et jusqu'à cinq réplicas en lecture. Redis réplique de manière asynchrone les données du nœud principal vers les réplicas en lecture. Lors de certains types de maintenance planifiée ou dans le cas peu probable d'une panne de nœud ElastiCache ou d'une défaillance de zone de disponibilité, Amazon ElastiCache détecte automatiquement la panne d'un nœud principal, sélectionne un réplica en lecture et le promeut en tant que nœud principal.

ElastiCache for Redis Cluster apporte des améliorations et assure la gestion des environnements Redis 3.x et versions suivantes. Lors de l'exécution d'un environnement Redis non géré, en cas de défaillance du nœud principal, le cluster s'appuie sur une majorité de nœuds maîtres pour déterminer et exécuter un basculement. En l'absence d'une telle majorité, le cluster se met en état d'échec et rejette toutes les lectures et écritures ultérieures. Cela peut avoir un impact important sur l'application en termes de disponibilité et exiger une intervention humaine pour récupérer manuellement le cluster. La fonction Multi-AZ d'ElastiCache pour Redis est conçue pour prendre en charge tous les cas de basculement pour Redis Cluster avec fiabilité et efficacité.

Q : En quoi la fonction Multi-AZ d'ElastiCache pour Redis Cluster est-elle différente de celle des versions 2.8.x d'ElastiCache pour Redis ?

Redis 3.x et versions ultérieures fonctionne avec des clients intelligents qui stockent une carte des nœuds avec tous les points de terminaison des nœuds de cluster. Au cours d'un basculement, le client met à jour la carte des nœuds avec le point de terminaison IP du nouveau nœud principal. Cela permet de profiter d'un temps de basculement jusqu'à 4 fois plus rapide par rapport à la version 2.8.x d'ElastiCache pour Redis.

Q : Comment l'option Multi-AZ pour Redis Cluster fonctionne-t-elle ?

Vous pouvez utiliser la fonction Multi-AZ si vous utilisez ElastiCache pour Redis Cluster avec chaque partition possédant un ou plusieurs réplicas en lecture. En cas de défaillance du nœud principal d'une partition, ElastiCache détecte automatiquement la panne, sélectionne un réplica en lecture parmi ceux disponibles et le promeut en tant que nouveau nœud principal. Le client Redis 3.x et versions ultérieures met à jour le réplica promu en tant que nœud principal. Aucune modification des applications n'est nécessaire. ElastiCache fait également tourner un nouveau nœud pour remplacer le réplica en lecture promu dans la même zone de disponibilité que le nœud principal défaillant. En cas de panne du nœud principal en raison d'une défaillance de la zone de disponibilité, le nouveau réplica est lancé une fois la zone de disponibilité remise en service.

Q : En quoi consiste une sauvegarde dans ElastiCache pour Redis Cluster ?

Une sauvegarde ElastiCache pour Redis Cluster est une série d'instantanés des partitions du cluster, stockés ensemble pour conserver une copie de toutes vos données Redis pendant une certaine période.

Q : En quoi la sauvegarde dans ElastiCache pour Redis Cluster est-elle différente d'un instantané dans ElastiCache pour Redis ?

Étant donné qu'un environnement ElastiCache pour Redis sans cluster possède un seul nœud principal, une sauvegarde est un fichier unique qui contient une copie des données Redis. ElastiCache pour Redis Cluster peut disposer d'une ou de plusieurs partitions. Ainsi, une sauvegarde peut contenir plusieurs fichiers.

Q : Comment spécifier les nœuds ElastiCache pour Redis qui doivent être sauvegardés dans chaque partition ?

Vous ne pouvez pas spécifier manuellement le nœud qui doit être sauvegardé dans chaque partition. Lors du lancement d'une sauvegarde, ElastiCache sélectionne automatiquement le réplica en lecture le plus à jour dans chaque partition et prend un instantané de ses données.

Q : Comment fonctionnent la sauvegarde et la restauration d'ElastiCache pour Redis Cluster ?

Lorsqu'une sauvegarde est lancée, ElastiCache prend un instantané du cluster spécifié à des fins de restauration ou d'archivage. La sauvegarde inclut une copie de chacune des partitions du cluster. Une sauvegarde complète contient donc une série de fichiers. Vous pouvez lancer une sauvegarde quand vous le souhaitez ou définir une sauvegarde quotidienne récurrente, avec une période de conservation des données de 35 jours maximum.

Une fois que vous avez choisi la sauvegarde à partir de laquelle effectuer la restauration, un nouveau cluster ElastiCache pour Redis est créé et alimenté à partir des données de la sauvegarde. Vous pouvez également utiliser cette fonction pour migrer aisément vers une expérience Redis Cluster gérée sur ElastiCache. Si vous exécutez une installation Redis autogérée sur EC2, vous pouvez prendre des instantanés RDB ou vos charges de travail existantes (aussi bien vos clusters Redis que des partitions Redis uniques) et les stocker dans S3. Il suffit alors de les configurer comme des entrées pour créer une expérience Redis Cluster partitionnée sur ElastiCache avec le nombre de partitions désiré. ElastiCache s'occupe du reste.

Actuellement, ElastiCache utilise le mécanisme natif de Redis pour créer et stocker un fichier RDB pour chaque partition en tant que sauvegarde.

Q : La sauvegarde dans ElastiCache pour Redis Cluster est-elle un instantané à un moment donné ?

Lorsque vous lancez une sauvegarde, ElastiCache déclenche des sauvegardes simultanées de toutes les partitions de votre cluster. Dans de rares cas, il peut être nécessaire de reprendre un instantané d'un ou de plusieurs nœuds qui n'ont pas abouti la première fois. ElastiCache le fait automatiquement et aucune intervention n'est requise de la part de l'utilisateur. Cependant, dans ce cas, bien que chaque instantané soit une représentation ponctuelle du nœud concerné, tous les instantanés du cluster ne sont pas pris au même moment.

Q : Comment préciser quand la sauvegarde doit être lancée ?

Vous pouvez préciser quand lancer une sauvegarde ponctuelle ou une sauvegarde récurrente dans l'AWS Management Console, ou en utilisant l'interface de ligne de commande ou les API. Voici les différentes opérations possibles :

  • Vous pouvez effectuer immédiatement une sauvegarde (bouton « Create Snapshot » de la console ou API CreateSnapshot)
  • Vous pouvez configurer une sauvegarde quotidienne automatique. La sauvegarde s'effectuera durant la plage de sauvegarde préconisée. Cette option peut être paramétrée lors de la création/modification du cluster via la console ou à l'aide des API CreateCacheCluster, ModifyCacheCluster, CreateReplicationGroup ou ModifyReplicationGroup.

Q : Puis-je utiliser mes propres instantanés RDB stockés dans S3 pour préamorcer le dimensionnement de l'environnement ElastiCache pour Redis Cluster ?

Oui. Vous pouvez préciser l'emplacement S3 de votre fichier RDB lors de la création du cluster, via l'assistant Create Cluster de la console, ou à l'aide de l'API CreateReplicationGroup. ElastiCache analyse automatiquement l'espace de clés Redis de l'instantané RDB et le redistribue entre les partitions du nouveau cluster.


Q : En quoi le moteur d'ElastiCache pour Redis est-il différent du système open source Redis ?

Le moteur d'ElastiCache pour Redis est entièrement compatible avec le système open source Redis, mais contient également des améliorations pour une solution plus robuste et plus stable. Voici certaines de ces améliorations :

  • Plus de mémoire disponible : vous pouvez désormais allouer en toute sécurité plus de mémoire pour votre application sans risquer d'augmenter l'utilisation de l'espace d'échange lors des synchronisations et des instantanés.
  • Amélioration de la synchronisation : une synchronisation plus robuste sous des charges élevées et lors des récupérations après des déconnexions réseau. De plus, les synchronisations sont plus rapides, car les nœuds principaux et les réplicas n'utilisent plus le disque pour effectuer cette opération.
  • Basculements plus fluides : en cas de basculement, votre partition récupère désormais plus rapidement, car les réplicas ne vident plus leurs données pour procéder à une resynchronisation complète avec le nœud principal.

Q : Comment utiliser le moteur amélioré ?

Pour utiliser le moteur amélioré à partir d'Amazon ElastiCache Management Console, il vous suffit de sélectionner un moteur compatible avec la version 2.8.22 ou une version ultérieure du moteur Redis lors de la création d'un cluster. Vous utiliserez alors le moteur amélioré. Vous pouvez également utiliser le moteur amélioré via l'API ElastiCache ou l'interface de ligne de commande AWS en spécifiant la version du moteur lors de l'exécution de l'API CreateCacheCluster.

Q : Dois-je modifier mon code d'application pour utiliser le moteur amélioré sur ElastiCache ?

Non. Le moteur amélioré est entièrement compatible avec le système open source Redis. Vous pouvez donc profiter de cette solution plus robuste et plus stable sans avoir à apporter de modifications à votre code d'application.

Q : Quel est le coût d'utilisation du moteur amélioré ?

L'utilisation du moteur amélioré n'implique aucun coût supplémentaire. Comme toujours, seuls les nœuds utilisés vous seront facturés.


Q : Qu'est-ce que le redimensionnement de cluster en ligne ?

Amazon ElastiCache for Redis permet d'ajouter et de supprimer des partitions depuis un cluster Redis activé en mode cluster en cours d'exécution. Vous pouvez dimensionner de manière dynamique vos charges de travail de clusters Redis pour les adapter aux fluctuations de la demande. Amazon ElastiCache redimensionne le cluster en ajoutant ou en supprimant des partitions et en redistribuant uniformément des emplacements de hachage sur la nouvelle configuration de partitions, le tout pendant que le cluster reste en ligne et continue de servir des requêtes.

Q : Quels sont les avantages du redimensionnement de cluster en ligne ?

La possibilité de redimensionner de manière dynamique un cluster peut vous aider à gérer la variabilité d'une application et à répondre aux demandes fluctuantes. Vous pouvez dimensionner correctement vos clusters en ajoutant ou en supprimant des partitions pour adapter les performances et la capacité en mémoire. Cette fonction supprime la nécessité de surapprovisionner des clusters en fonction des pics de demande, aide à améliorer l'efficacité et réduit les coûts.

Q : Comment utiliser le redimensionnement de cluster en ligne ?

Le redimensionnement de cluster en ligne est disponible pour les clusters Redis activés en mode cluster sur la version 3.2.10 ou ultérieure. Pour refragmenter votre cluster, sélectionnez-le et indiquez si vous souhaitez ajouter ou supprimer des partitions. Lorsque vous redimensionnez le cluster pour l'augmenter, Amazon ElastiCache ajoute des partitions et migre des emplacements depuis des partitions existantes vers de nouvelles partitions de sorte à répartir les emplacements uniformément (en nombre) entre les partitions. De la même manière, lorsque vous redimensionnez le cluster pour le réduire, Amazon ElastiCache migre des emplacements vers les partitions restantes afin de répartir les emplacements uniformément et supprime les partitions spécifiées.

Q : Combien de temps prend le redimensionnement de cluster en ligne ?

Le temps pris par le redimensionnement dépend de plusieurs facteurs, comme le nombre d'emplacements devant être migrés sur les partitions, la taille des données et le taux de demandes entrantes sur le cluster. Le flux de travail est optimisé afin de mettre en parallèle la migration d'emplacements et d'accélérer ainsi la mise à l'échelle horizontale.

Q : Est-ce que le cluster peut être utilisé pendant son redimensionnement ?

Oui. Le cluster continue de rester en ligne et d'exécuter les demandes entrantes pendant le repartitionnement. Il n'est toutefois pas possible de prendre un instantané d'un cluster lorsqu'un repartitionnement est en cours.

Q : Cette opération a-t-elle un impact sur les performances du cluster ?

Le redimensionnement de cluster en ligne permet une augmentation ou une diminution sans temps d'arrêt. Il s'agit toutefois d'une opération exigeante en matière de calcul qui peut augmenter la latence de la connexion de votre client. Pour réduire la charge sur le cluster pendant l'opération, nous vous recommandons de suivre les bonnes pratiques (décrites dans la documentation).

Q : Comment suivre la progression d'un repartitionnement en ligne ?

Il est possible de suivre l'avancement du repartitionnement en consultant l'état du cluster, des partitions et des nœuds. Pendant l'opération, le cluster, les partitions et les nœuds gardent le statut « en cours de modification ». De la même manière, lorsque les fragments sont créés, supprimés ou participent à la migration d'emplacements, les statuts individuels des fragments reflètent ces statuts pour indiquer la progression. De plus, le statut de l'opération bout en bout peut également être suivi grâce à l'indicateur de progression pour la refragmentation, qui montre le pourcentage d'achèvement et donne des informations sur le temps restant pour l'opération. Enfin, les messages d'événements indiquent la progression en décrivant les actions réalisées (création de partitions, migration d'emplacements, etc.).

Q : En quoi consiste l'opération de rééquilibrage pour le cluster Amazon ElastiCache for Redis ?

Le rééquilibrage peut être utilisé pour redistribuer les emplacements parmi les partitions existantes pour obtenir une distribution uniforme. Cette opération est utile lorsqu'un cluster est créé avec une distribution des emplacements manuelle inégale ou lorsqu'une opération de dimensionnement laisse le cluster avec une distribution inégale. À supposer que les emplacements sont identiques en mémoire et en exigences E/S, la distribution uniforme d'emplacements par nombre représente un moyen simple d'équilibrer la charge sur les fragments.

Q : Comment fonctionne le balisage lors de l'augmentation d'un cluster ?

Lorsque des nœuds sont ajoutés en vue d'une augmentation d'un cluster, ces derniers portent le même type de balises, commun à tous les nœuds existants. De plus, les utilisateurs peuvent modifier les balises sur tous les nœuds et continuer d'utiliser le même balisage.

Q : Des modifications du côté du client ou de l'application sont-elles nécessaires pour utiliser le redimensionnement de cluster en ligne ?

Non. La distribution d'emplacements améliorée utilisée pour un redimensionnement de cluster est cohérente avec le comportement du client de cluster de Redis et ne nécessite pas de modifier l'application. Amazon ElastiCache conserve les points de terminaison de cluster, ce qui vous permet de continuer d'utiliser les clients existants sans la moindre modification.


Q : Qu'apporte le chiffrement au repos d'Amazon ElastiCache for Redis ?

Le chiffrement au repos offre des mécanismes qui protègent vos données contre tout accès non autorisé sur le serveur. Lorsque cette fonction est activée sur un groupe de réplications, elle chiffre les aspects suivants : 

  • Le disque durant les opérations de synchronisation, de sauvegarde et de permutation ;
  • Les sauvegardes stockées dans Amazon S3.

Amazon ElastiCache for Redis offre par défaut le chiffrement au repos (service géré), ainsi que la possibilité d'utiliser vos propres clés principales client symétriques gérées par le client dans AWS Key Management Service (KMS). Le chiffrement au repos ne peut être activé sur un groupe de réplications qu'au moment de sa création. Pour en savoir plus, cliquez ici.

Q : Qu'apporte le chiffrement en transit d'Amazon ElastiCache for Redis ?

Le chiffrement en transit permet de chiffrer toutes les communications entre les clients et le serveur Redis ainsi qu'entre les serveurs Redis (nœuds principaux et réplicas en lecture). C'est une fonction en option qui ne peut être activée sur des groupes de réplications Redis qu'au moment de leur création. Pour en savoir plus, cliquez ici.

Q : Comment utiliser le chiffrement en transit, au repos et Redis AUTH ?

Le chiffrement en transit, le chiffrement au repos, la commande AUTH de Redis et le contrôle d'accès basé sur les rôles (RBAC) sont tous des fonctionnalités opt-in. Lors de la création du cluster Redis via la console ou l'interface de ligne de commande, vous pouvez préciser si vous souhaitez activer le chiffrement au repos ou en transit. Si vous avez choisi d'activer le chiffrement en transit, vous pouvez décider d'utiliser la commande AUTH de Redis ou le contrôle RBAC pour renforcer la sécurité et le contrôle d'accès. Une fois le cluster configuré et le chiffrement activé, Amazon ElastiCache gère en toute transparence l'expiration et le renouvellement des certificats sans nécessiter d'actions supplémentaires de la part de l'application. De plus, les clients Redis doivent prendre en charge TLS pour que le trafic chiffré en transit soit activé. Si vous choisissez d'utiliser la commande AUTH de Redis, vous aurez besoin de la version Redis 3.2.6 ou ultérieure, tandis que RBAC nécessite la version Redis 6.

Q : Existe-t-il un client Amazon ElastiCache for Redis que je dois utiliser lorsque j'utilise le chiffrement en transit ou au repos ?

Non. Le chiffrement en transit nécessite des clients prenant en charge TLS. La plupart des clients Redis populaires (Lettuce, Predis, go-Redis, par exemple) prennent en charge TLS avec certains paramètres de configuration. Vous devez vous assurer que le client Redis que vous choisissez est configuré pour prendre en charge TLS et continuer d'utiliser Amazon ElastiCache for Redis comme avant.

Q : Puis-je activer le chiffrement en transit et au repos sur mes clusters Amazon ElastiCache for Redis existants ?

Non. La prise en charge du chiffrement en transit et au repos n'est disponible que pour les nouveaux clusters. Elle n'est pas pris en charge sur les clusters Amazon ElastiCache for Redis existants. Les versions 6.0.5, 5.0.0, 4.0.10 et 3.2.6 d'Amazon ElastiCache for Redis prennent en charge ces fonctions.

Q : Dois-je faire quelque chose pour renouveler les certificats ?

Non. Amazon ElastiCache gère l'expiration et le renouvellement des certificats en arrière-plan. Aucune action de la part de l'utilisateur n'est requise pour la maintenance des certificats en cours.

Q : Puis-je utiliser mes certificats pour le chiffrement ?

Non. Actuellement, Amazon ElastiCache n'offre pas la possibilité d'utiliser vos certificats. Amazon ElastiCache gère en toute transparence vos certificats.

Q : Quels types d'instances sont pris en charge pour le chiffrement en transit et au repos ?

Toutes les générations d'instances actuelles sont prises en charge pour le chiffrement en transit et au repos. Pour une liste complète des conditions relatives au chiffrement en transit, cliquez ici, et pour les conditions relatives au chiffrement au repos, cliquez ici.

Q : L'utilisation du chiffrement entraîne-t-elle des frais supplémentaires ?

L'utilisation du chiffrement n'entraîne aucun frais supplémentaire.


Q : Quels programmes de conformité sont pris en charge par Amazon ElastiCache for Redis ?

Amazon ElastiCache for Redis prend en charge des programmes de conformité comme SOC 1, SOC 2, SOC 3, ISO, MTCS, C5, PCI, HIPAA et FedRAMP. Consultez la section Services AWS concernés par le programme de conformité pour obtenir la liste à jour des programmes de conformité pris en charge.

Q : Est-ce qu'Amazon ElastiCache for Redis est conforme PCI ?

Oui. Le programme de conformité PCI d'AWS inclut Amazon ElastiCache pour Redis comme service conforme PCI. Pour en savoir plus, consultez les ressources suivantes :

Pour consulter la liste à jour des programmes de conformité pris en charge par Amazon ElastiCache for Redis, consultez la section Services AWS concernés par le programme de conformité.

Q : Est-ce qu'Amazon ElastiCache for Redis est éligible pour HIPAA ?

Oui. Amazon ElastiCache for Redis est un service éligible HIPAA qui a été ajouté à l'AWS Business Associate Addendum (BAA). Cela signifie que vous pouvez utiliser Amazon ElastiCache for Redis pour traiter, conserver et stocker des données de santé protégées (PHI) et exploiter des applications de santé.

Q : Que dois-je faire pour utiliser Amazon ElastiCache for Redis éligible pour HIPAA ?

Si vous disposez d'un accord de partenariat (BAA) avec AWS, vous pouvez dès à présent utiliser ElastiCache for Redis pour concevoir des applications conformes HIPAA. Si vous n'avez pas de BAA ou si vous avez d'autres questions sur l'utilisation d'AWS avec des applications conformes HIPAA, contactez-nous pour obtenir plus d'informations. Reportez-vous au livre blanc Architecture de la sécurité et de la conformité HIPAA dans Amazon Web Services pour savoir comment configurer les services éligibles à HIPAA de façon à stocker, traiter et transmettre les PHI.

Q : Est-ce qu'Amazon ElastiCache for Redis est autorisé pour FedRAMP ?

Le programme de conformité FedRAMP d'AWS inclut Amazon ElastiCache for Redis comme service autorisé pour FedRAMP. Les clients de l'administration américaine et leurs partenaires peuvent désormais utiliser la dernière version d'Amazon ElastiCache for Redis pour traiter et stocker leurs systèmes, données et charges de travail essentielles et à fort impact FedRAMP dans la région AWS GovCloud (US), mais aussi à moyen impact dans les régions AWS USA Est/Ouest.

Pour en savoir plus, consultez les ressources suivantes :

Pour consulter la liste à jour des programmes de conformité pris en charge par Amazon ElastiCache for Redis, consultez la section Services AWS concernés par le programme de conformité.

Q : L'utilisation des fonctionnalités de conformité entraîne-t-elle des frais supplémentaires ?

Non. Aucun frais supplémentaire ne s'applique à l'utilisation des fonctionnalités de conformité.


Q : Qu'est-ce que Global Datastore for Redis ?

Global Datastore est une fonctionnalité d'Amazon ElastiCache for Redis qui permet une réplication entre régions entièrement gérée, rapide, fiable et sécurisée. Avec Global Datastore, vous pouvez écrire dans votre cluster Amazon ElastiCache for Redis dans une région, puis proposer ces données en lecture dans deux autres réplicas maximum entre régions, ce qui réduit la latence de lecture et de reprise après sinistre entre régions.

Conçu pour les applications en temps réel de niveau mondial, Global Datastore for Redis assure un temps de latence de réplication généralement inférieur à une seconde dans toutes les régions. Vos applications répondent donc plus rapidement, les lectures s'effectuant plus à proximité des utilisateurs finaux. En cas de dégradation, certes peu probable, des performances au niveau régional, l'un des clusters répliqués peut être désigné en tant que cluster principal, avec des fonctionnalités en lecture/écriture intégrales. Ce basculement s'effectue généralement en moins d'une minute, ce qui garantit la disponibilité continue de vos applications.

Q. Vers combien de régions AWS puis-je faire une réplication ?

Vous pouvez effectuer une réplication vers jusqu'à deux régions secondaires grâce à Global Datastore for Redis. Les clusters des régions secondaires peuvent être utilisés pour servir des lectures locales à faible latence et pour la reprise après sinistre, dans le cas improbable d'une dégradation régionale.

Q : Quelles versions du moteur prennent en charge Global Datastore for Redis ?

Global Datastore est pris en charge sur les versions 5.0.6 et supérieures d'Amazon ElastiCache for Redis. Les clients peuvent mettre à niveau la version du moteur sur 5.0.6 pour utiliser Global Datastore.

Q : Comment puis-je créer Global Datastore for Redis ?

Pour configurer Global Datastore, vous pouvez utiliser un cluster existant ou en créer un nouveau afin de l'employer en tant que cluster principal. Vous pouvez créer un Global Datastore for Redis en quelques clics dans la console de gestion Amazon ElastiCache ou en téléchargeant le dernier kit SDK ou CLI d'AWS. Global Datastore est pris en charge par AWS CloudFormation.

Q : Amazon ElastiCache bascule-t-il automatiquement un Global Datastore for Redis pour promouvoir un cluster secondaire dans le cas d'une dégradation du cluster principal (région) ?

Non. Amazon ElastiCache ne promeut pas automatiquement un cluster secondaire dans le cas d'une dégradation du cluster principal (région). Vous pouvez initier manuellement le basculement en transformant un cluster secondaire en cluster primaire. Le basculement et la promotion du cluster secondaire se termine généralement en moins d'une minute.

Q : Comment puis-je réaliser le basculement d'une application pour une reprise après sinistre si mon cluster principal rencontre une dégradation du service ?

Dans le cas où votre cluster principal dans un Global Datastore for Redis rencontre une dégradation du service, vous pouvez attribuer un cluster secondaire comme cluster principal, puis retirez l'ancien cluster principal de votre Global Datastore. Lorsqu'un cluster secondaire est promu au rang de cluster principal, Amazon ElastiCache reconfigure l'ancien cluster principal (s'il est possible de l'atteindre) en tant que cluster secondaire et configure la réplication de manière à synchroniser toutes les régions secondaires avec la nouvelle région principale. Si la pile entière de votre application est répliquée vers une autre région AWS, vous pouvez basculer la pile de l'application toute entière (y compris vos ressources de calcul) vers cette région AWS. Si le reste de votre pile d'application n'a pas besoin d'être basculé, assurez-vous que votre application a accès au point de terminaison du cluster secondaire.

Q : Comment mes données sont-elles sécurisées en utilisant Global Datastore for Redis ?

Global Datastore for Redis utilise le chiffrement en transit pour le trafic entre régions pour conserver vos données en toute sécurité. Vous pouvez également chiffrer vos clusters principaux et secondaires à l'aide du chiffrement au repos pour converser vos données sécurisées de bout en bout. Chaque cluster principal et secondaire peut disposer d'une clé principale client (CMK) distincte, gérée côté client, dans AWS Key Management Service (KMS) pour le chiffrement au repos.

Q : À quel objectif de point de récupération (RPO) et objectif de délais de récupération (RTO) puis-je m'attendre avec Global Datastore for Redis ?

Amazon ElastiCache ne fournit pas de SLA pour RPO et RTO. Le RPO varie selon la latence de réplication entre les régions et dépend de la latence du réseau entre les régions et de la congestion du trafic de réseau entre les régions. Le RPO de Global Datastore est généralement inférieur à une seconde de manière à ce que les données écrites dans la région principale sont disponibles dans les régions secondaires en une seconde. Le RTO de Global Datastore for Redis est généralement inférieur à une minute. Une fois qu'un basculement vers un cluster secondaire est lancé, Amazon ElastiCache confère généralement au cluster secondaire des capacités en lecture/écriture totales en moins d'une minute.

Q : Quelle est la tarification applicable à Global Datastore for Redis ?

Amazon ElastiCache ne facture pas de prime pour utiliser Global Datastore for Redis. Vous payez les clusters principaux et secondaires dans votre Global Datastore, ainsi que le trafic de transfert de données entre régions.