FAQ sur Amazon ElastiCache

Amazon ElastiCache est un service web qui rationalise le déploiement et l’exécution de caches conformes au protocole Valkey, Memcached ou Redis OSS dans le cloud. ElastiCache améliore les performances des applications en vous permettant de récupérer des informations depuis un système en mémoire rapide et entièrement géré, au lieu de vous en remettre entièrement à des systèmes lents basés 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 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.

ElastiCache automatise les tâches administratives courantes nécessaires à l'exploitation d'un environnement clé-valeur distribué en mémoire. Grâce à 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 la console de gestion AWS. ElastiCache est conçu pour maintenir automatiquement une haute disponibilité et fournit un contrat de niveau de service (SLA) de disponibilité de 99,99 %. ElastiCache est conforme aux protocoles Valkey, Memcached et Redis OSS. Le code, les applications et les outils que vous utilisez couramment avec vos environnements Valkey, Memcached ou Redis OSS fonctionnent donc de manière transparente avec ce service. Il n’y a pas d’investissement initial à réaliser et vous ne payez que les ressources que vous utilisez.

La mise en cache en mémoire fournie par ElastiCache peut être utilisée pour améliorer de manière significative la latence et le débit de nombreuses charges de travail d’applications à lecture intensive (telles que les réseaux sociaux, les jeux, le partage de médias et les portails de questions-réponses) ou de charges de travail à calcul intensif (telles que les moteurs de recommandation). 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.

Oui, vous pouvez souscrire des Savings Plans de base de données pour votre utilisation d’Amazon ElastiCache et réduire vos coûts jusqu’à 30 % si vous vous engagez à utiliser un volume d’utilisation constant sur une période d’un an. Des informations supplémentaires sur l’utilisation éligible sont disponibles sur la page de tarification des Savings Plans de base de données.

ElastiCache gère les tâches liées à la configuration d’un environnement en mémoire distribué, de la mise en service des ressources demandées à l’installation du logiciel. Lorsque vous utilisez Amazon ElastiCache Serverless, vous n’avez aucune infrastructure à configurer et à gérer. Lors de la conception de votre propre cluster ElastiCache, le service automatise les tâches administratives courantes telles que l’application de correctifs logiciels, la détection des défaillances et la restauration. ElastiCache fournit des métriques de surveillance détaillées associées à vos ressources, 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.

ElastiCache propose Valkey, Memcached et Redis OSS entièrement gérés pour la plupart des applications exigeantes nécessitant des temps de réponse de moins d’une milliseconde.

Si vous n’êtes pas encore inscrit à ElastiCache, vous pouvez sélectionner Commencer sur la page ElastiCache et terminer le processus d’inscription. Vous devez posséder un compte AWS. Dans le cas contraire, il vous sera demandé d’en créer un au début de la procédure d’inscription à ElastiCache. Après vous être inscrit à ElastiCache, consultez la documentation ElastiCache, qui inclut notre manuel de démarrage pour Amazon ElastiCache.

Une fois familiarisé avec ElastiCache, vous pouvez créer un cache en quelques minutes à l’aide de la console ou des API ElastiCache.

Pour créer des caches, il suffit d’utiliser la console, les API Amazon ElastiCache ou les outils de ligne de commande. Lorsque vous utilisez ElastiCache sans serveur, vous pouvez créer un cache en utilisant les paramètres recommandés par défaut et commencer à l’utiliser en moins d’une minute.

ElastiCache est parfaitement adapté en tant qu’interface frontale pour les services AWS tels qu’Amazon RDS et DynamoDB, offrant une latence extrêmement faible pour les applications à hautes performances et déchargeant une partie du volume de requêtes tandis que ces services assurent la durabilité des données à long terme. Le service peut aussi être utilisé pour améliorer les performances des applications en association avec Amazon EC2 et Amazon EMR.

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’ElastiCache, veuillez nous en informer à travers le forum de la communauté ElastiCache.

Oui. Vous pouvez créer des répliques dans plusieurs régions grâce à la fonctionnalité d’entrepôt de données mondial dans ElastiCache. La fonctionnalité de l’entrepôt de données mondial assure une réplication entre régions entièrement gérée, rapide, fiable et axée sur la sécurité. Elle vous permet d’écrire sur votre cluster ElastiCache dans une région et d’avoir les données disponibles pour être lues à partir de deux autres clusters de répliques entre régions, permettant ainsi des lectures à faible latence et une reprise après sinistre entre régions.

Il existe plusieurs avantages en termes de performances.

ElastiCache fournit des threads d’E/S améliorés qui augmentent considérablement le débit et la latence à grande échelle grâce au multiplexage, au déchargement de la couche de présentation, etc. Les threads d’E/S améliorés améliorent les performances en utilisant davantage de cœurs pour le traitement des E/S et en s’adaptant dynamiquement à la charge de travail. ElastiCache améliore le débit des clusters compatibles TLS en transférant le chiffrement vers les mêmes threads d’E/S améliorés. Cela permet à ElastiCache pour Valkey de fournir jusqu’à 100 % de débit en plus et une latence P99 50 % inférieure à celle la version 7.0 d’ElastiCache pour Redis OSS. Vous pouvez réaliser plus d’un million de requêtes par seconde et par nœud, soit 500 millions de requêtes par seconde et par cluster, sur des nœuds r7g.4xlarge ou plus.

En outre, ElastiCache version 8.1 pour Valkey fournit une nouvelle table de hachage qui réduit jusqu’à 40 % la consommation de mémoire pour les clusters basés sur des nœuds avec le mode cluster par rapport à ElastiCache version 7.2 pour Valkey et version 7.1 pour Redis OSS. La configuration sans serveur offre des performances améliorées, pouvant atteindre 5 millions de requêtes par seconde et par cache en quelques minutes, soit jusqu’à 5 fois plus vite que Valkey 7.2, avec une latence de lecture d’une microseconde.

ElastiCache fournit deux ensembles de métriques différents pour mesurer l’utilisation du CPU de votre cache en fonction de votre choix de déploiement de cache. Lorsque vous utilisez ElastiCache Serverless, vous pouvez surveiller l’utilisation du processeur à l’aide de la métrique ElastiCache Processing Units (ECPU). Le nombre d’ECPU consommés par vos requêtes dépend du temps nécessaire au vCPU et de la quantité de données transférées. Chaque lecture et écriture, comme les commandes Valkey GET et SET ou les commandes Memcached get et set, nécessite 1 ECPU pour chaque kilo-octet (Ko) de données transférées. Certaines commandes qui fonctionnent sur des structures de données en mémoire peuvent consommer plus de temps vCPU qu’une commande GET ou SET. ElastiCache calcule le nombre d’ECPU consommés en fonction du temps de vCPU nécessaire à la commande par rapport à une référence du temps de vCPU utilisé par une commande SET ou GET. Si votre commande nécessite plus de temps sur le vCPU et transfère plus de données que la valeur de référence de 1 ECPU, ElastiCache calcule les ECPU nécessaires en fonction de la plus élevée des deux dimensions.

Lorsque vous concevez votre propre cluster, vous pouvez surveiller EngineCPUUtilization et CPUUtilization. La métrique CPUUtilization mesure l’utilisation du CPU pour l’instance (nœud) et la métrique EngineCPUUtilization mesure l’utilisation au niveau du processus du moteur. Vous aurez besoin de la métrique EngineCPUUtilization en plus de la métrique CPUUtilization, car le processus du moteur primaire n’a qu’un seul fil et n’utilise qu’un seul processeur parmi les multiples cœurs de CPU disponibles sur une instance. Par conséquent, la métrique CPUUtilization ne fournit pas une visibilité précise sur les taux d’utilisation du CPU au niveau du processus. 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 CPU pour vos clusters Valkey.

Les deux ensembles de métriques sont disponibles dans toutes les régions AWS et vous pouvez y accéder au moyen d’Amazon CloudWatch ou de la console. De plus, nous vous conseillons également de vous reporter à la documentation pour en savoir plus sur les métriques utiles pour le contrôle des performances.

ElastiCache sans serveur est une option sans serveur qui vous permet de démarrer avec un cache en moins d’une minute sans mise en service d’infrastructure ni planification de la capacité. ElastiCache Serverless élimine la nécessité d’une planification fastidieuse des capacités en surveillant en permanence l’utilisation du calcul, de la mémoire et du réseau d’un cache, afin que celui-ci puisse mettre à l’échelle instantanément pour répondre à la demande sans interruption ni dégradation des performances. ElastiCache Serverless réplique automatiquement les données dans plusieurs zones de disponibilité (AZ) et fournit aux clients un contrat de niveau de service (SLA) de disponibilité de 99,99 % pour chaque cache. Avec ElastiCache sans serveur, vous ne payez que pour les données que vous stockez et les ressources de calcul utilisées par votre application. Pour commencer, créez un cache ElastiCache sans serveur en quelques étapes en spécifiant un nom de cache à l’aide de la console, du kit de développement logiciel (SDK) ElastiCache ou de l’interface de la ligne de commande AWS (AWS CLI).

Vous pouvez déplacer une charge de travail ElastiCache existante en remplaçant le point de terminaison Valkey, Memcached ou Redis OSS par votre nouveau point de terminaison de cache ElastiCache sans serveur dans votre application. Vous pouvez migrer les données ElastiCache existantes vers ElastiCache sans serveur en spécifiant l’emplacement Amazon Simple Storage Service (Amazon S3) d’un fichier de sauvegarde. Consultez notre documentation ElastiCache sans serveur pour en savoir plus sur la migration de vos charges de travail.

ElastiCache sans serveur prend en charge Valkey 7.2, Memcached version 1.6.21 et Redis OSS version 7.0 et versions ultérieures.

ElastiCache sans serveur surveille en permanence la mémoire, le calcul et l’utilisation du réseau de votre cache pour une mise à l’échelle instantanée. ElastiCache Serverless évolue sans interruption ni dégradation des performances de l’application en permettant au cache d’augmenter et en initiant l’augmentation en parallèle, afin de répondre aux exigences de l’application juste à temps. Consultez notre documentation ElastiCache sans serveur pour en savoir plus sur la mise à l’échelle.

ElastiCache sans serveur stocke automatiquement les données de manière redondante dans plusieurs AZ et propose un contrat de niveau de service (SLA) à 99,99 % de disponibilité pour toutes les charges de travail.

Avec ElastiCache sans serveur, vous ne payez que pour les données que vous stockez et les calculs utilisés par votre application. Pour en savoir plus, consultez la page de tarification d’ElastiCache.

Le moteur d’ElastiCache est entièrement compatible avec le système open source Valkey et Redis OSS, mais contient également des améliorations pour une solution plus robuste et plus stable. Certaines de ces améliorations sont les suivantes :

• 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épliques ne vident plus leurs données pour procéder à une resynchronisation complète avec le nœud primaire.

Le moteur amélioré est entièrement compatible avec le système open source Valkey ou Redis OSS. Vous pouvez donc profiter de cette solution plus robuste et plus stable sans avoir à apporter de modifications à votre code d’application. ElastiCache pour Memcached ne propose pas de fonctionnalité de moteur amélioré.

L’utilisation du moteur amélioré n’implique aucun coût supplémentaire.

Les nœuds réservés ou les instances réservées (RI) vous permettent de bénéficier d’une réduction significative par rapport à l’utilisation à la 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 créer une réservation d’un an ou de trois ans afin d’exécuter votre cache dans une région spécifique et bénéficier d’une réduction significative sur les frais d’utilisation horaires. Il existe trois types de nœuds réservés : vous avez la possibilité de ne rien payer au départ, de payer uniquement une partie des frais initiaux ou de faire un paiement total anticipé. Ce choix vous permet de trouver le juste équilibre entre le montant initial payé et le tarif horaire effectif.

Vos réservations Redis OSS s’appliquent automatiquement aux nœuds Valkey de la même famille d’instances et de la même région. Le prix de Valkey étant inférieur de 20 % à celui de Redis OSS, si vous possédez déjà un nœud réservé Redis OSS, vous pouvez mettre à niveau votre cache vers le moteur Valkey et continuer à bénéficier de vos avantages de réservation avec 20 % de valeur en plus. Par exemple, si vous avez acheté une réservation pour 5 nœuds cache.r7g.2xlarge pour le moteur Redis OSS, lorsque vous mettez à niveau vos nœuds vers le moteur Valkey, vous pouvez créer un sixième nœud cache.r7g2xlarge (20 % de plus que 5 nœuds) dans la même région sans frais supplémentaires. »

Les nœuds réservés offrent une réduction qui s’applique à l’utilisation à la demande d’ElastiCache. ElastiCache sans serveur n’est pas compatible avec les nœuds réservés.

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 ElastiCache.

Il suffit d’acheter une réservation de nœud avec la même classe de nœud, dans la même région que le nœud que vous utilisez actuellement et que vous souhaitez réserver. Si l’achat de la réservation est réussi, ElastiCache appliquera automatiquement votre nouveau tarif horaire d’utilisation à votre nœud existant.

Les changements de tarification associés à un nœud réservé sont activés dès que votre demande est reçue et que 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.

Les API ElastiCache pour créer, modifier et supprimer des nœuds ne font pas de distinction entre les nœuds à la demande et les nœuds réservés, de sorte que vous pouvez utiliser les deux de manière transparente. Lors du calcul de votre facture, notre système appliquera automatiquement vos réservations, de sorte que tous les nœuds éligibles soient facturés au tarif horaire le plus bas pour les nœuds de cache réservés.

Non, vous ne pouvez pas annuler votre réservation de nœud réservé et le paiement initial (le cas échéant) n’est pas remboursable. Lorsque vous achetez un nœud réservé, vous vous engagez pour une durée complète d'un ou trois ans. Vous ne pouvez donc pas annuler, obtenir un remboursement, modifier le type d'instance, vendre ou transférer la réservation à un autre compte AWS. Vous continuerez à payer pour chaque heure pendant la durée de votre nœud réservé, quelle que soit votre utilisation.

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.

Lorsque vous achetez un nœud réservé avec l’option de paiement Tous les frais à l’avance, vous réglez la totalité de votre durée de réservation en un seul paiement. Vous avez aussi la possibilité de ne pas payer de frais initiaux, en choisissant l'option Aucuns frais initiaux. La valeur totale du nœud réservé 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.

Oui, les nœuds réservés ElastiCache offrent une certaine flexibilité en termes de taille au sein d’une famille d’instances (ou d’une famille de nœuds) et d’une Région AWS. Cela signifie que le tarif réduit pour vos nœuds réservés sera appliqué automatiquement à l’utilisation de toutes les tailles dans la même famille de nœuds.

Multi-AZ est une fonctionnalité qui vous permet d’exécuter une configuration plus hautement disponible lors de la conception de votre propre cache ElastiCache. Tous les caches ElastiCache sans serveur sont automatiquement exécutés dans une configuration multi-AZ. Un groupe de réplications ElastiCache est composé d’un nœud primaire et d’un maximum de cinq réplicas en lecture. Si la fonction multi-AZ est activée, au moins un réplica est requis par nœud primaire. Au cours de certains types de maintenance planifiée, ou dans le cas improbable d’une défaillance d’un nœud ElastiCache ou d’une zone de disponibilité, ElastiCache détectera automatiquement la défaillance d’un serveur primaire, sélectionnera un réplica en lecture et le promouvra pour qu’il devienne le nouveau nœud primaire. ElastiCache propage également les modifications DNS de la réplique en lecture promue. Si votre application effectue des opérations en écriture sur le point de terminaison du nœud primaire, aucune modification du point de terminaison n’est donc nécessaire.

Les principaux avantages de l’exécution d’ElastiCache en mode multi-AZ résident dans l’amélioration de la disponibilité et des tâches d’administration moins nombreuses. Lorsque vous exécutez ElastiCache dans une configuration Multi-AZ, vos caches sont éligibles au SLA de disponibilité de 99,99 %. Si un nœud primaire ElastiCache tombe en panne, l’impact sur les opérations en lecture/écriture sur le nœud primaire 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 ElastiCache est automatique et ne nécessite pas d’administration.

Vous pouvez avoir recours à la fonction multi-AZ si vous utilisez ElastiCache et disposez d’un groupe de réplications composé d’un nœud primaire et d’une ou plusieurs répliques de lecture. En cas de défaillance du nœud primaire, 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 primaire. 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 primaire. 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 primaire défaillant. En cas de défaillance du nœud primaire en raison d’une indisponibilité temporaire de la zone de disponibilité, la nouvelle réplique est lancée une fois la zone de disponibilité remise en service.

Oui. Le placement du nœud primaire et des répliques dans une même zone de disponibilité ne permet toutefois pas de rendre votre groupe de réplications ElastiCache résilient en cas de défaillance d’une zone de disponibilité.

ElastiCache procède au basculement vers un réplique de lecture dès lors qu’un des événements suivants se produit :

• Perte de disponibilité dans la zone de disponibilité du nœud primaire
• Perte de connectivité réseau avec le nœud primaire
• Panne de l’unité de calcul sur le serveur principal

S’il existe plusieurs répliques de lecture, la réplique de lecture présentant le plus petit décalage de réplication asynchrone vers le nœud primaire sera promue.

Oui. 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 rapport à votre nœud ElastiCache, ou cliquer sur la section Événements de la console de gestion ElastiCache.

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 devriez envisager d’architecturer votre application et d’autres ressources AWS avec une redondance sur plusieurs zones de disponibilité afin que votre application soit résiliente en cas d’interruption d’une zone de disponibilité.

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

ElastiCache vous permet de configurer le chiffrement des données au repos à l’aide d’AWS Key Management Service (AWS KMS), le chiffrement des données en transit à l’aide du protocole TLS (Transport Layer Security), l’authentification à l’aide d’AWS Identity and Access Management (IAM) et le contrôle d’accès au réseau avec les groupes de sécurité Amazon Elastic Compute Cloud (Amazon EC2).

Lorsque vous n’utilisez pas Amazon Virtual Private Cloud (Amazon VPC), ElastiCache vous permet de contrôler l’accès à vos caches par le biais de groupes de sécurité réseau. Un groupe de sécurité fonctionne comme un pare-feu contrôlant l’accès réseau à votre cache. Par défaut, l’accès réseau est désactivé pour vos caches. Si vous souhaitez que vos applications accèdent à votre cluster de cache, vous devez explicitement activer l’accès depuis les hôtes dans des groupes de sécurité Amazon EC2 spécifiques.

Vous pouvez également contrôler l’accès à vos ressources ElastiCache à l’aide de l'authentification IAM. Pour plus d’informations, consultez la documentation relative à l’authentification avec IAM.

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

Oui. Le programme de conformité PCI d’AWS inclut ElastiCache comme service conforme à la norme PCI. Pour en savoir plus, consultez les ressources suivantes :

• Conformité d’ElastiCache
• Page de conformité PCI d’AWS

Pour connaître la liste actuelle des programmes de conformité couverts par ElastiCache, reportez-vous à la section Services AWS concernés par le programme de conformité.

Oui, ElastiCache est un service éligible HIPAA et couvert par le Addendum relatif aux partenaires commerciaux AWS (BAA). Cela signifie que vous pouvez utiliser ElastiCache pour vous aider à traiter, entretenir et stocker des données de santé protégées (PHI) et exploiter des applications de santé.

Si vous avez signé un Accord de partenariat commercial (BAA) avec AWS, vous pouvez utiliser ElastiCache pour créer des applications qui stockent et traitent des informations médicales protégées conformément à la loi HIPAA. Si vous n’avez pas de BAA ou si vous avez d’autres questions sur l’utilisation d’AWS pour vos applications, contactez-nous pour obtenir plus d’informations. 

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

Le programme de conformité FedRAMP d’AWS inclut ElastiCache comme service autorisé pour FedRAMP. Les clients du gouvernement américain et leurs partenaires peuvent désormais utiliser la dernière version d’ElastiCache pour traiter et stocker leurs systèmes FedRAMP, leurs données et leurs charges de travail critiques à fort impact dans les régions AWS GovCloud (US, côte est) et AWS GovCloud (US, côte ouest), et à un impact modéré dans les régions USA Est (Ohio), USA Est (Virginie du Nord), USA Ouest (Californie du Nord) et USA Ouest (Oregon).

Pour en savoir plus, consultez les ressources suivantes :

• Conformité avec ElastiCache
• Conformité d’AWS au programme FedRAMP

Pour connaître la liste actuelle des programmes de conformité couverts par ElastiCache, reportez-vous à la section Services AWS concernés par le programme de conformité.

Le chiffrement en transit, le chiffrement au repos, Valkey AUTH et le contrôle d’accès basé sur les rôles (RBAC) sont des fonctionnalités que vous pouvez sélectionner lors de la création de votre cache ElastiCache. Si vous avez activé le chiffrement en transit, vous pouvez choisir d’utiliser AUTH ou RBAC pour une sécurité et un contrôle d’accès supplémentaires.

Le chiffrement au repos fournit des mécanismes de protection contre l’accès non autorisé à vos données. Lorsqu'il est activé, il chiffre les aspects suivants :

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

ElastiCache offre par défaut le chiffrement au repos (service géré), ainsi que la possibilité d’utiliser vos propres clés AWS KMS symétriques gérées par le client dans AWS KMS. Consultez le chiffrement au repos pour en savoir plus.

La fonctionnalité de chiffrement en transit facilite le chiffrement des communications entre les clients et ElastiCache, ainsi qu’entre les serveurs (primaires et répliques de lecture). En savoir plus sur le chiffrement en transit d’ElastiCache.

Non. 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.

Non, l’utilisation du chiffrement n’entraîne aucun frais supplémentaire.

Les répliques en lecture servent deux objectifs :

• Gestion des défaillances
• Dimensionnement en lecture

Lorsque vous exécutez un cache avec un réplica de lecture, le primaire sert à la fois les écritures et les lectures. La réplique sert exclusivement au trafic de lecture et est également disponible en secours semi-automatique au cas où le primaire deviendrait défectueux.

Avec ElastiCache sans serveur, les répliques de lecture sont automatiquement gérées par le service. Lors de la conception de votre propre cache, il existe plusieurs scénarios dans lesquels le déploiement d'une ou plusieurs répliques de lecture pour un nœud primaire donné peut s'avérer judicieux. Les principales raisons d’un déploiement de réplica en lecture sont les suivantes :

• Évolutivité au-delà de la capacité de calcul ou d’E/S d’un seul nœud primaire pour les charges de travail gourmandes en lecture : ce trafic de lecture excessif peut être dirigé vers une ou plusieurs réplicas en lecture.
• La prise en charge du trafic en lecture en cas d’indisponibilité du nœud primaire. Si votre nœud primaire ne peut pas accepter de demandes d’E/S (par exemple, en raison d’une suspension des E/S pour des sauvegardes ou une maintenance programmée), vous pouvez diriger le trafic de lecture vers vos réplicas en lecture. Dans ce cas d’utilisation, il faut garder à l’esprit que les données du réplica en lecture peuvent être périmées, puisque l’instance primaire n’est pas disponible. Le réplica en lecture peut également être utilisé à chaud pour redémarrer un nœud primaire défaillant.

Scénarios de protection des données. Dans le cas improbable d’une défaillance du nœud primaire ou d’une indisponibilité de la zone de disponibilité dans laquelle réside votre nœud primaire, vous pouvez promouvoir une réplique de lecture dans une zone de disponibilité différente pour qu’elle devienne le nouveau nœud primaire.

Vous pouvez vous connecter à une réplique en lecture comme vous le feriez à un nœud de cache primaire. 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 Valkey ou Redis OSS (mode cluster désactivé) utilisent les points de terminaison des nœuds individuels pour les opérations de lecture. (Dans l’API/CLI, ils sont appelés points de terminaison de lecture.)
• Les clusters Valkey ou Redis OSS (mode cluster activé) utilisent le point de terminaison de configuration pour toutes les opérations. Vous pouvez toujours lire à partir des points de terminaison des nœuds individuels. (Dans l'API et la CLI, ils sont appelés points de terminaison de lecture.)

ElastiCache vous permet de créer jusqu’à cinq (5) répliques de lecture pour un nœud de cache primaire donné.

En cas de basculement, toute réplique en lecture associée et disponible doit reprendre la réplication automatique une fois le basculement terminé (avec acquisition des mises à jour depuis la réplique en lecture nouvellement promue).

Les mises à jour appliquées au nœud de cache primaire sont immédiatement répliquées sur les répliques en lecture associées. Toutefois, avec la technologie de réplication asynchrone de Valkey ou Redis OSS, une réplique de lecture peut prendre du retard par rapport à son nœud de cache primaire pour diverses raisons. Les raisons typiques incluent :

• Le volume des E/S en écriture sur le nœud de cache primaire 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 primaire et une réplique en lecture.

Les répliques en lecture sont sujettes aux forces et aux faiblesses de la réplication Valkey ou Redis OSS. Si vous utilisez des répliques en lecture, vous devez être conscient du risque de retard entre une réplique en lecture et son nœud de cache primaire ou d’une possible « incohérence ». ElastiCache émet une métrique pour vous aider à comprendre l’incohérence.

Une réplique de lecture est facturée comme un nœud de cache standard et aux mêmes tarifs. Tout comme pour un nœud de cache standard, le tarif par heure de nœud de cache pour une réplique de lecture est déterminé par la classe de nœud de cache de la réplique de lecture, reportez-vous à la page de tarification d’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 primaire et le réplica en lecture ne vous sont pas facturés. La facturation du réplica débute dès sa création, c'est-à-dire lorsque le statut indiqué est « active » (lorsque le statut indiqué est Actif). La réplique de lecture continuera de vous être facturée aux tarifs horaires d’un nœud de cache ElastiCache standard jusqu’à ce que vous exécutiez une commande pour la supprimer.

Le basculement initié ou celui de test est pris en charge par ElastiCache afin que vous puissiez reprendre les opérations de cache aussi rapidement que possible. Lors du basculement, 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 primaire. 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. Généralement, du début à la fin, les étapes 1 à 5 ci-dessous sont effectuées en six minutes.

Les événements de basculement automatique sont énumérés dans l’ordre d’apparition ci-après :

1. Message du groupe de réplication : API test basculement appelée pour le groupe de nœuds
2. Message du cluster de cache : basculement du nœud primaire au nœud de réplication terminé
3. Message du groupe de réplication : basculement du nœud primaire au nœud de réplication terminé
4. Message du cluster de cache : restauration des nœuds de cache
5. Message du cluster de cache : restauration terminée pour les nœuds de cache

Non, votre réplique de lecture ne peut être provisionnée que dans la même zone de disponibilité ou dans une zone différente de la même région que votre nœud de cache primaire. Vous pouvez toutefois utiliser la fonction Entrepôt de données mondial dans le cadre d’une réplication entièrement gérée, rapide, fiable et sécurisée entre Régions AWS. Grâce à cette fonctionnalité, vous pouvez créer des clusters de répliques de lecture entre régions pour ElastiCache afin de réduire la latence de lecture et de reprise après sinistre dans les régions AWS.

Oui. Vous pouvez ajouter ou supprimer une réplique de lecture sur une ou plusieurs partitions dans un environnement de cluster. Le cluster reste en ligne et traite les E/S entrantes pendant cette opération.

Le basculement initié est pris en charge par ElastiCache afin que vous puissiez reprendre les opérations de cache aussi rapidement que possible. Lors du basculement, 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 primaire. 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, un nouveau nœud sain rejoint le cluster dans les six minutes. Le temps de synchronisation des nœuds varie en fonction de la charge de travail et de la taille du cluster, ce qui a un impact sur le temps d’exécution des étapes 1 à 5 ci-dessous. Les événements de basculement automatique sont énumérés dans l’ordre d’apparition ci-après :

• Message de groupe de réplications : Test d'API de basculement appelé pour un groupe de nœuds <node-group-id>
• Message de cluster de cache : Basculement accompli d'un nœud primaire <primary-node-id> vers un réplica <node-id>
• Message de groupe de réplications : Basculement accompli d'un nœud primaire <primary-node-id> vers un réplica <node-id>
• Message de cluster de cache : Récupération de nœuds de cache <node-id>
• Message de cluster de cache : récupération de nœuds de cache terminée <node-id>

La sauvegarde et restauration permet de créer des instantanés de caches ElastiCache. ElastiCache conserve ces instantanés et les utilisateurs peuvent les exploiter par la suite afin de restaurer leurs caches. Cela est actuellement pris en charge par ElastiCache pour Valkey et ElastiCache pour Redis OSS et sans serveur.

Lorsqu’une sauvegarde est lancée, ElastiCache prend un instantané d’un cache spécifique à 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 cache ElastiCache est créé et alimenté à partir des données de l’instantané. Les instantanés ElastiCache sont compatibles avec le format de fichier Redis OSS RDB.

La fonctionnalité de sauvegarde et de restauration crée des instantanés sur la base d’un cache. Les utilisateurs peuvent spécifier le cache ElastiCache à sauvegarder via la console, l’interface de ligne de commande AWS ou l’API ElastiCache. Nous recommandons aux utilisateurs d’activer la sauvegarde sur l’une des réplicas en lecture du cache, afin de minimiser tout impact potentiel sur le nœud primaire. Lorsque vous utilisez ElastiCache sans serveur, les sauvegardes sont automatiquement effectuées par rapport aux répliques en lecture.

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. Une autre raison courante d'utiliser des sauvegardes est le besoin d'archivage. Les instantanés sont stockés dans Amazon S3.

Vous pouvez exporter vos instantanés ElastiCache vers un compartiment S3 autorisé dans la même région que votre cache.

Oui. Vous devez d’abord copier votre instantané dans un compartiment S3 autorisé de votre choix dans la même région, puis accorder des autorisations de compartiment entre comptes à l’autre compte.

ElastiCache offre un espace de stockage gratuit pour un instantané de chacun de vos caches ElastiCache 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.

Lorsque vous supprimez un cache ElastiCache, vos instantanés manuels sont conservés. Vous avez également la possibilité de créer un instantané final de votre cache avant sa suppression. En revanche, les instantanés mis en cache automatiquement ne sont pas conservés.

Oui, une sauvegarde effectuée depuis n’importe quelle version d’ElastiCache pour Redis OSS peut être restaurée vers n’importe quelle version d’ElastiCache pour Valkey. Pour plus d’informations sur la restauration des sauvegardes, consultez la documentation ElastiCache.

Vous pouvez utiliser la fonctionnalité de sauvegarde et de restauration via la console, les API ElastiCache et l’interface de ligne de commande AWS. Vous pouvez désactiver et réactiver cette fonctionnalité à tout moment.

L’entrepôt de données mondial est une fonctionnalité d’ElastiCache qui permet une réplication entre régions entièrement gérée, rapide, fiable et sécurisée. Avec l’entrepôt de données mondial, vous pouvez écrire dans votre cache dans une région et disposer des données en lecture dans deux autres clusters de réplicas entre régions, ce qui permet des lectures à faible latence et une reprise après sinistre entre les régions.

Conçu pour les applications en temps réel avec une empreinte mondiale, l’entrepôt de données mondial réplique généralement les données entre les régions en moins d’une seconde, augmentant ainsi la réactivité de vos applications en fournissant des lectures géolocales plus proches des utilisateurs finaux. Dans le cas improbable d'une dégradation régionale, l'un des caches de réplique inter-régions sains peut être promu au rang de cache primaire avec des capacités de lecture et d'écriture complètes. Ce basculement s’effectue généralement en moins d’une minute, ce qui garantit la disponibilité continue de vos applications.

L’entrepôt de données mondial est pris en charge sur ElastiCache version 7.2 pour Valkey et ElastiCache version 5.0.6 et ultérieures pour Redis OSS.

Vous pouvez effectuer une réplication vers deux régions secondaires au maximum grâce à l’entrepôt de données mondial. Les caches des régions secondaires peuvent être utilisés pour les lectures locales à faible latence et pour la reprise après sinistre dans le cas peu probable d’une dégradation de la région.

Pour configurer un entrepôt de données mondial, vous pouvez utiliser un cache existant ou en créer un nouveau afin de l’utiliser en tant que nœud primaire. Vous pouvez créer un Global Datastore en quelques étapes dans la console de gestion ElastiCache ou en téléchargeant la dernière version du kit SDK AWS ou CLI AWS. L’entrepôt de données mondial est pris en charge par AWS CloudFormation.

Non, ElastiCache ne promeut pas automatiquement un cluster secondaire dans le cas où un cluster primaire (région) est dégradé. Vous pouvez initier manuellement le basculement en transformant un cluster secondaire en cluster primaire. Le basculement et la promotion du cluster secondaire se terminent généralement en moins d’une minute.

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 inter-régions et de la congestion du trafic de réseau inter-régions. Le RPO de l’entrepôt de données mondial est généralement inférieur à une seconde, de sorte que les données écrites dans une région primaire sont disponibles dans les régions secondaires en l’espace d’une seconde. Le RTO de l’entrepôt de données mondial est généralement inférieur à une minute. Une fois qu’un basculement vers un cluster secondaire est initié, ElastiCache fait généralement passer le cluster secondaire à des capacités de lecture et d’écriture complètes en moins d’une minute.

ElastiCache ne facture pas de prime pour utiliser l’entrepôt de données mondial. Vous payez les clusters primaires et secondaires dans votre entrepôt de données mondial, ainsi que le trafic de transfert de données inter-régions.

L’entrepôt de données mondial utilise le chiffrement en transit pour le trafic inter-régions pour conserver vos données en toute sécurité. En outre, vous pouvez également chiffrer vos caches primaires et secondaires à l'aide du chiffrement au repos afin de mieux sécuriser vos données. Chaque cache primaire et secondaire peut disposer d’une clé AWS KMS distincte gérée par le client pour le chiffrement au repos.

La hiérarchisation des données offre une nouvelle option économique et performante en utilisant des disques durs à état solide (SSD) moins coûteux dans chaque nœud de cluster, en plus du stockage des données en mémoire. Cette solution est idéale pour les charges de travail qui accèdent régulièrement à 20 % de leur jeu de données et pour les applications qui peuvent tolérer une latence supplémentaire lors de l’accès aux données sur SSD. Les nœuds ElastiCache R6gd avec mémoire et disques SSD ont une capacité de stockage totale près de 5 fois supérieure et peuvent vous aider à réaliser plus de 60 % d’économies sur le prix lors d’une utilisation maximale par rapport aux nœuds ElastiCache R6g avec mémoire uniquement.

La hiérarchisation des données fonctionne en transférant automatiquement et de manière fluide les éléments les moins récemment utilisés de la mémoire vers les disques SSD NVMe connectés localement lorsque la capacité de mémoire disponible est entièrement consommée. Lorsqu’un élément transféré vers un SSD est utilisé ultérieurement, ElastiCache le replace en mémoire de manière asynchrone avant de répondre à la demande.

La hiérarchisation des données est conçue pour avoir un impact minimal sur les performances des applications. En supposant des valeurs de chaîne de 500 octets, la latence supplémentaire sera de 300 µs en moyenne pour les demandes de données stockées sur SSD par rapport aux demandes de données en mémoire.

ElastiCache prend en charge la hiérarchisation des données pour les versions 6.2 et supérieures d’ElastiCache pour Redis OSS.

ElastiCache prend en charge la hiérarchisation des données sur les clusters à l’aide de nœuds R6gd.

Toutes les commandes Valkey et Redis OSS et la plupart des fonctionnalités ElastiCache sont prises en charge lors de l’utilisation de la hiérarchisation des données. Pour obtenir la liste des fonctionnalités qui ne sont pas prises en charge sur les clusters utilisant la hiérarchisation des données, consultez la documentation.

L’utilisation de la hiérarchisation des données n’entraîne pas de coûts supplémentaires en dehors du coût horaire du nœud. Les nœuds utilisant la hiérarchisation des données sont disponibles avec une tarification à la demande et comme nœuds réservés. Pour la tarification, reportez-vous à la page de tarification d’ElastiCache.

Valkey est une évolution open source de Redis OSS dirigée par la Linux Foundation qui prend en charge une variété de cas d’utilisation, comme la mise en cache, les classements et les magasins de sessions. Elle est créée par des contributeurs et mainteneurs de longue date de Redis OSS. Valkey est soutenu par plus de 40 entreprises et a été rapidement adopté depuis la création du projet en mars 2024.

Avec ElastiCache pour Valkey, vous pouvez bénéficier d’une expérience entièrement gérée basée sur une technologie open source tout en tirant parti de la sécurité, de l’excellence opérationnelle, du SLA pour une disponibilité de 99,99 % et de la fiabilité d’AWS. Vous pouvez optimiser les coûts d’ElastiCache sans serveur for Valkey encore davantage en bénéficiant d’une réduction de 33 % et d’une capacité de stockage de données minimale de 100 Mo, soit 90 % de moins qu’ElastiCache pour Redis OSS. Avec ElastiCache pour Valkey basé sur des nœuds, vous pouvez bénéficier d’une réduction du coût par nœud allant jusqu’à 20 %. 

Oui. Avec ElastiCache, vous pouvez créer un réplica en lecture dans une autre AZ AWS. Lorsque vous utilisez ElastiCache sans serveur, les données sont automatiquement stockées de manière redondante dans plusieurs AZ pour garantir une haute disponibilité. Lors de la conception de votre propre cache ElastiCache, en cas de défaillance d’un nœud, nous en fournirons un nouveau. Dans les scénarios où le nœud primaire tombe en panne, ElastiCache promeut automatiquement un réplica en lecture existant dans le rôle primaire. Pour plus d’informations sur la manière de gérer les défaillances de nœuds, consultez la page Comprendre la réplication.

Vous pouvez rapidement passer à une version de moteur plus récente en utilisant les API ElastiCache et en spécifiant votre version de moteur préférée. Dans la console ElastiCache, vous pouvez sélectionner un cache et sélectionner Modifier. Le processus de mise à niveau du moteur est conçu pour retenir vos données existantes. Pour plus de détails, consultez stratégies de mise en cache et bonnes pratiques.

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

Oui, vous bénéficierez des mêmes caractéristiques, contrats de niveau de service et fonctionnalités si vous passez d’ElastiCache pour Redis OSS à ElastiCache pour Valkey.

ElastiCache pour Valkey diffère d’ElastiCache pour Redis OSS de trois manières. Tout d’abord, avec ElastiCache Valkey, vous pouvez bénéficier d’une évolutivité plus rapide et d’une efficacité de mémoire 20 % supérieure à celle d’ElastiCache pour Redis OSS. Ensuite, le prix d’ElastiCache pour Valkey est inférieur de 33 % à celui d’ElastiCache pour Redis OSS. Enfin, ElastiCache pour Valkey utilise Valkey, le projet open source, qui évite toute dépendance à l’égard d’un fournisseur.

Vous pouvez mettre à niveau la version existante de votre moteur Redis OSS vers la version la plus récente de Valkey sur place, sans durée d’indisponibilité et en quelques clics. Pour obtenir un guide étape par étape sur la mise à niveau de votre moteur, consultez la documentation relative à la mise à niveau du moteur ElastiCache. Vous pouvez effectuer une mise à niveau depuis n’importe quelle version de Redis OSS prise en charge sur ElastiCache vers n’importe quelle version d’ElastiCache pour Valkey. Si vous effectuez une mise à niveau à partir de versions de Redis OSS antérieures à la version 5.0.6, cela nécessite une propagation DNS qui peut connaître un temps de basculement de 30 à 60 secondes. Pour obtenir la liste complète des modifications entre toutes les versions majeures et mineures, consultez la documentation des versions d’ElastiCache. 

Vous pouvez migrer vos données depuis Valkey ou Redis OSS autogérés s’exécutant sur Amazon EC2 vers Amazon ElastiCache grâce à la fonctionnalité de migration en ligne. Vous pouvez également créer un instantané de votre cluster Redis OSS s’exécutant sur EC2, puis le restaurer dans ElastiCache pour Valkey.

Oui, vous pouvez mettre à niveau vos clusters ElastiCache pour Redis OSS existants vers ElastiCache pour Valkey via CloudFormation en modifiant les propriétés Moteur et Version de moteur.

Tous les clients Redis OSS qui prennent en charge Redis OSS 7.2 sont entièrement compatibles avec toutes les versions de Valkey. Vous trouverez une liste des bibliothèques clientes officielles de Valkey sur la page client valkey.io. 

Oui, les tarifs réduits pour les nœuds réservés s’appliqueront à vos RI existants lorsque vous passerez d’ElastiCache pour Redis à ElastiCache Valkey. Le scénario 5 de ce blog fournit des informations supplémentaires.

Avec les nœuds réservés Redis OSS, en plus de pouvoir appliquer vos avantages au sein de la famille de nœuds de cache et du moteur, vous pouvez également choisir de passer au moteur Valkey et de bénéficier d’une valeur incrémentielle accrue. Valkey bénéficie d’une réduction de 20 % par rapport à Redis OSS, et grâce à la flexibilité des nœuds réservés, vous pouvez appliquer vos nœuds réservés Redis OSS à 20 % de nœuds réservés Valkey supplémentaires. Pour plus d’informations sur la flexibilité des nœuds réservés, consultez ce blog.

Vous pouvez mettre en cache divers objets à l’aide d’ElastiCache pour Memcached. Ces objets comprennent le contenu des magasins de données persistants (tels que Amazon Relational Database Service (Amazon RDS), Amazon DynamoDB ou les bases de données autogérées hébergées sur Amazon EC2), les pages web générées dynamiquement (avec Nginx, par exemple), ainsi que les données de session transitoires qui peuvent ne pas nécessiter de magasin 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é.

Oui. ElastiCache est une interface frontale idéale pour les magasins de données comme Amazon RDS ou DynamoDB, fournissant un niveau intermédiaire de haute performance pour les applications avec des taux de requêtes extrêmement élevés ou des exigences de faible latence.

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. ElastiCache prend en charge à la fois les protocoles texte et binaire. Il prend aussi en charge 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'ElastiCache sans recompiler ou relier vos applications ; les bibliothèques que vous utilisez continuent de fonctionner. Pour configurer les serveurs de cache 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 la 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 ElastiCache avant de mettre fin à votre solution actuelle.

Vous pouvez accéder aux clusters ElastiCache dans un Amazon VPC depuis le réseau Amazon EC2 ou depuis votre propre centre de données. Reportez-vous aux modèles d'accès Amazon VPC pour plus de détails. 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 cette FAQ pour obtenir des recommandations sur la gestion des échecs des nœuds.

ElastiCache ne nécessite pas de bibliothèques clientes spécifiques et fonctionne avec les bibliothèques clientes Memcached existantes sans recompilation ni reconnexion des applications (Memcached 1.4.5 et versions ultérieures). Les exemples incluent LibMemcached (C) et les bibliothèques basées sur celle-ci (par exemple, PHP, Perl, Python), spyMemcached (Java) et fauna (Ruby).

Bien qu’il n’y ait pas de réponse précise à cette question, avec 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. Vous pouvez également utiliser ElastiCache Serverless pour simplifier l'exécution d'un cache Memcached à haute disponibilité. Les deux aspects interdépendants suivants peuvent être pris en considération 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 nécessaires pour maintenir une performance acceptable de l'application sans surcharger le backend de la base de données en cas de défaillance d'un nœud.

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, voir le guide de l’utilisateur ElastiCache.

Oui. Lorsque vous créez un cluster ou que vous ajoutez des nœuds à un cluster existant, vous pouvez sélectionner les AZ des nouveaux nœuds. Vous pouvez soit spécifier le nombre de nœuds nécessaire pour chaque AZ, soit sélectionner Répartir les nœuds entre différentes zones. Si le cluster se trouve dans Amazon VPC, les nœuds peuvent uniquement être placés dans les AZ du groupe de sous-réseaux du cache sélectionné. Pour plus d’informations, voir la documentation sur les VPC ElastiCache.

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.

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

• 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 Amazon 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 Amazon 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é, 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 cessent d’utiliser un serveur (nœud) indéfiniment si elles rencontrent des erreurs de communication ou des dépassements de délai avec ce serveur.

Vous pouvez ajouter plus de nœuds à votre cluster Memcached existant en utilisant l’option Ajouter des nœuds dans l’onglet Nœuds de votre Cluster de cache dans la console ou à l’aide de l’API ModifyCacheCluster.

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. La détection automatique permet aux clients de repérer automatiquement les nœuds de cache qui sont ajoutés ou retirés d’un cluster 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 à Auto Discovery, ElastiCache élimine cette complexité. Outre une rétrocompatibilité avec le protocole Memcached, la fonctionnalité de détection automatique associée à ElastiCache fournit aux clients des informations concernant l'appartenance au cluster de cache. Tout client capable de traiter les informations supplémentaires se reconfigure, sans aucune initialisation, pour utiliser les nœuds les plus récents d’un cluster ElastiCache.

Un cluster ElastiCache peut être créé avec des nœuds auxquels il est possible de s’adresser à travers des points de terminaison nommés. Grâce à la détection automatique, le cluster 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. 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 tel que « get », « set », « incr » et « decr ». Pour en savoir plus, reportez-vous à la documentation. Afin d'exploiter la détection automatique, vous aurez besoin d'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 ElastiCache. Lors de son initialisation, le client détermine automatiquement les membres actuels du cluster 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 la détection automatique repère automatiquement ces changements, sans que vous deviez initialiser vos clients manuellement.

Pour commencer, téléchargez le client de cluster ElastiCache en cliquant sur le lien Télécharger le client de cluster ElastiCache à partir de la console ElastiCache. Afin d'effectuer ce téléchargement, vous devez posséder un compte ElastiCache ; si ce n'est pas déjà le cas, inscrivez-vous sur la page de présentation d'ElastiCache. Une fois le client téléchargé, vous pouvez commencer à configurer et à activer votre cluster ElastiCache à partir de la console ElastiCache. Vous trouverez plus d’informations dans notre documentation.

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 ElastiCache. Par ailleurs, ElastiCache prenant toujours totalement en charge Memcached, vous pouvez utiliser tout client compatible avec le protocole Memcached comme auparavant.

Afin d’exploiter la fonctionnalité de détection automatique, un client prenant en charge cette fonctionnalité doit être utilisé pour se connecter au cluster ElastiCache. 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 ElastiCache. Sachez que vous pouvez créer des clients pour d’autres langages à partir des clients Memcached les plus courants.

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.

Oui. ElastiCache reste compatible avec le protocole Memcached et ne nécessite pas que vous modifiiez vos clients. Toutefois, pour tirer parti de la fonctionnalité Auto Discovery, nous avons amélioré les fonctionnalités du client Memcached. Si vous décidez de ne pas utiliser le client de cluster 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.
 

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

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 ElastiCache. Par ailleurs, ElastiCache prenant toujours totalement en charge Memcached, vous pouvez utiliser tout client compatible avec le protocole Memcached comme auparavant.

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 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 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 ElastiCache. Bien que la fonctionnalité de gestion des versions du moteur soit destinée à vous donner autant de contrôle que possible sur la façon dont les correctifs sont appliqués, nous pouvons corriger votre cluster en votre nom si nous déterminons qu’il y a une vulnérabilité de sécurité dans le système ou le logiciel de cache.

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 « Modifier » pour votre cluster. Spécifiez simplement la version que vous souhaitez mettre à niveau via le champ « Cache Engine Version ». La mise à niveau sera alors appliquée en votre nom, soit immédiatement (si l'option « Appliquée immédiatement » est cochée), soit lors de la prochaine fenêtre de maintenance programmée pour votre cluster.

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

Nous prévoyons de prendre en charge d’autres versions de Memcached pour Amazon ElastiCache, qu’elles soient majeures ou mineures. 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.

Vous pouvez mettre à niveau votre cluster Memcached existant à l’aide du processus de modification. 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. Voir les conditions préalables de mise à niveau.

Veuillez consulter notre tarification pour obtenir des informations sur les prix actuels.

Vous pouvez rapidement passer à une version de moteur plus récente en utilisant les API ElastiCache et en spécifiant votre version de moteur préférée. Dans la console ElastiCache, vous pouvez sélectionner un cache et sélectionner Modifier. Le processus de mise à niveau du moteur est conçu pour retenir vos données existantes. Pour en savoir plus, reportez-vous à la documentation.

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

ElastiCache continuera à prendre en charge les versions précédentes de Redis OSS, y compris Redis OSS 7.1. Au fil du temps, nous mettrons fin à la durée de vie des anciennes versions de tous les moteurs (y compris Valkey, Memcached et Redis OSS) et laisserons un certain temps aux utilisateurs pour mettre à niveau leurs moteurs avant qu’une version donnée du moteur ne soit obsolète.