FAQ sur Amazon ElastiCache

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

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.

Les nœuds réservés offrent une réduction qui s’applique à l’utilisation à la demande d’ElastiCache. ElastiCache Serverless 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 Amazon 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.

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.

Non, vous ne pouvez pas annuler votre réservation de nœud, et le paiement initial (le cas échéant) n'est pas remboursable. Vous continuerez à payer pour chaque heure pendant la durée de votre nœud réservé, quelle que soit votre utilisation.

Lorsque vous achetez un nœud réservé avec l'option de paiement Tous les frais initiaux, 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.

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 du 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é avec ElastiCache
• Page relative à la 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 AWS Business Associate Addendum (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é.

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

Si vous avez signé un Business Associate Agreement (BAA) avec AWS, vous pouvez utiliser ElastiCache pour créer des applications qui stockent et traitent l’IH 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. 

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

ElastiCache fournit des threads d’E/S améliorés qui améliorent 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. La version 7.2 d’ElastiCache for Valkey a introduit un multiplexage d’E/S amélioré, qui combine de nombreuses demandes des clients sur un seul canal et améliore l’efficacité du thread Redis principal.

Dans ElastiCache for Valkey version 7.2 et versions ultérieures, nous avons étendu la fonctionnalité améliorée des threads d’E/S afin de gérer également la logique de la couche de présentation. Les threads d’E/S améliorés non seulement lisent les entrées du client, mais analysent également les entrées dans un format de commande binaire, qui est ensuite transmis au thread principal pour exécution, afin de générer des gains de performances. Avec ElastiCache for Valkey version 7.2, vous pouvez obtenir jusqu’à 100 % de débit en plus et 50 % de latence P99 en moins, comparé à la version précédente. Sur r7g.4xlarge ou supérieur, vous pouvez réaliser plus d’un million de requêtes par seconde (RPS) par nœud.

ElastiCache fournit deux ensembles de métriques différents pour mesurer l’utilisation du processeur 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ées 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 processeurs requis 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 processeur 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 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. 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 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.

Les réplicas 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. Le réplica sert exclusivement au trafic de lecture et est également disponible en mode veille au cas où le primaire deviendrait défectueux.

Avec ElastiCache sans serveur, les répliques en 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 un réplica en lecture dans une zone de disponibilité différente pour qu’il 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éplicas en lecture pour un nœud de cache primaire donné.

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

Les mises à jour appliquées au nœud de cache primaire sont immédiatement répliquées sur les réplicas en lecture associés. 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 un réplica en lecture.

Les réplicas en lecture sont sujets aux forces et aux faiblesses de la réplication Valkey ou Redis OSS. 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 ». ElastiCache émet une métrique pour vous aider à comprendre l’incohérence.

Un réplica en lecture est facturé 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 un réplica en lecture est déterminé par la classe de nœud de cache du réplica en 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). Le réplica en lecture continuera de vous être facturé aux tarifs horaires d'un nœud de cache ElastiCache standard jusqu'à ce que vous exécutiez une commande pour le supprimer.

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. 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 de groupe de réplications : Test d'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 primaire <primary-node-id> vers un réplica <node-id>
3. Message de groupe de réplications : Basculement accompli d'un nœud primaire <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>

Non, votre réplica en lecture ne peut être provisionné 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éplicas en 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 un réplica en 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.

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

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’un ou plusieurs réplicas en 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é, le nouveau réplica est lancé une fois la zone de disponibilité remise en service.

Oui. Le placement du nœud primaire et des réplicas 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é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 primaire
• Perte de connectivité réseau avec le serveur principal
• Échec d'unité de calcul sur le serveur principal

En cas de défaillance de plusieurs réplicas en lecture, le réplica de lecture ayant le plus petit retard de réplication asynchrone par rapport au nœud primaire sera promu.

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

La fonctionnalité de sauvegarde et de 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.

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

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éplicas ne vident plus leurs données pour procéder à une resynchronisation complète avec le nœud primaire.
• Déchargement TLS et multiplexage des E/S : ElastiCache est conçu pour mieux utiliser les ressources CPU disponibles en gérant certains processus liés au réseau sur des threads dédiés.

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.

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

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 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 ( réplicas primaires et réplicas en 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.

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.

Vous pouvez effectuer une réplication vers jusqu'à deux régions secondaires grâce à Global Datastore. 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 improbable d'une dégradation de la région.

Global Datastore est pris en charge sur ElastiCache version 7.2 pour Valkey et ElastiCache version 5.0.6 et versions ultérieures pour Redis OSS.

Pour configurer Global Datastore, 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. Global Datastore 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 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.

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.

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 votre hit-rate du 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 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 « Add Node » dans l'onglet « Nodes » de votre cluster de cache dans la console ou à l'aide de l'API ModifyCacheCluster.

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

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 celui-ci (par exemple, PHP, Perl, Python), SpyMemcached (Java) et fauna (Ruby).

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 « Download ElastiCache Cluster Client » à 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/travail vers ce cluster, la 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 for 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 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. Voir les conditions préalables de mise à niveau.

ElastiCache fournit des threads d’E/S améliorés qui améliorent 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. La version 7.0 d’ElastiCache (Redis OSS) a introduit un multiplexage d’E/S amélioré, qui combine de nombreuses demandes des clients sur un seul canal et améliore l’efficacité du thread.

Dans ElastiCache version 7.1 et versions ultérieures pour Redis OSS , nous avons étendu la fonctionnalité améliorée des threads d’E/S afin de gérer également la logique de la couche de présentation. Les threads d’E/S améliorés non seulement lisent les entrées du client, mais analysent également les entrées dans un format de commande binaire, qui est ensuite transmis au thread principal pour exécution, afin de générer des gains de performances. Avec ElastiCache version 7.1 pour Redis OSS, vous pouvez obtenir jusqu’à 100 % de débit en plus et 50 % de latence P99 en moins, comparé à la version précédente. Sur r7g.4xlarge ou supérieur, vous pouvez réaliser plus d’un million de requêtes par seconde (RPS) par nœud.

ElastiCache fournit deux ensembles de métriques différents pour mesurer l’utilisation du processeur 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ées 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 Redis OSS 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 Redis OSS qui fonctionnent sur des structures de données en mémoire peuvent consommer plus de temps de 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 processeurs requis 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 processeur 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 Redis OSS primaire n’a qu’un seul fil 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 du moteur. 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 OSS.

Les deux jeux 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.

Les répliques de lecture servent deux objectifs dans Redis OSS :

• 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. Le réplica sert exclusivement au trafic de lecture et est également disponible en mode veille au cas où le primaire deviendrait défectueux.

Avec ElastiCache sans serveur, les répliques en 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 un réplica en lecture dans une zone de disponibilité différente pour qu’il 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 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 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éplicas en lecture pour un nœud de cache primaire donné.

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

Les mises à jour appliquées au nœud de cache primaire sont immédiatement répliquées sur les réplicas en lecture associés. Toutefois, avec la technologie de réplication asynchrone de 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 un réplica en lecture.

Les réplicas en lecture sont sujets aux forces et aux faiblesses de la réplication Redis OSS. 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 ». ElastiCache émet une métrique pour vous aider à comprendre l’incohérence.

Un réplica en lecture est facturé 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 un réplica en lecture est déterminé par la classe de nœud de cache du réplica en 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). Le réplica en lecture continuera de vous être facturé aux tarifs horaires d'un nœud de cache ElastiCache standard jusqu'à ce que vous exécutiez une commande pour le supprimer.

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. 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 de groupe de réplications : Test d'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 primaire <primary-node-id> vers un réplica <node-id>
3. Message de groupe de réplications : Basculement accompli d'un nœud primaire <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>

Non, votre réplica en lecture ne peut être provisionné 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 l’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éplicas en 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 connaître l’emplacement du nœud primaire actuel en utilisant la console ou l’API DescribeCacheClusters.

Oui. Vous pouvez ajouter ou supprimer un réplica en 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.

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

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’un ou plusieurs réplicas en 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é, le nouveau réplica est lancé une fois la zone de disponibilité remise en service.

Oui. Le placement du nœud primaire et des réplicas 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é. En outre, les réplicas situés dans la même zone de disponibilité que le nœud primaire ne seront pas autorisés si le mode Multi-AZ est activé.

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 primaire
• Perte de connectivité réseau avec le serveur principal
• Échec d'unité de calcul sur le serveur principal

En cas de défaillance de plusieurs réplicas en lecture, le réplica de lecture ayant le plus petit retard de réplication asynchrone par rapport au nœud primaire sera promu.

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.

La fonctionnalité de sauvegarde et de 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. 

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 stockés dans Amazon S3.

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.

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

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éplicas en lecture.

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.

Le moteur d’ElastiCache est entièrement compatible avec le système open source 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éplicas ne vident plus leurs données pour procéder à une resynchronisation complète avec le nœud primaire.
• Déchargement TLS et multiplexage des E/S : ElastiCache est conçu pour mieux utiliser les ressources CPU disponibles en gérant certains processus liés au réseau sur des threads dédiés.

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

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

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 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 ( réplicas primaires et réplicas en lecture). En savoir plus sur le chiffrement en transit d’ElastiCache.

Le chiffrement en transit, le chiffrement au repos, Redis OSS 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 Redis OSS AUTH ou RBAC pour une sécurité et un contrôle d’accès supplémentaires.

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.

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.

Vous pouvez effectuer une réplication vers jusqu'à deux régions secondaires grâce à Global Datastore. 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 improbable d'une dégradation de la région.

Global Datastore est pris en charge sur les versions 5.0.6 et supérieures d'ElastiCache for Redis.

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.

Global Datastore 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.

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

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