Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
# Amazon ElastiCache (Valkey) pour les applications de commerce électronique
Une application de commerce électronique bénéficie d'une couche de cache en mémoire entre les serveurs d'applications et la base de données. Amazon ElastiCache exécutant Valkey fournit une latence de lecture inférieure à la milliseconde pour les données fréquemment consultées (entrées du catalogue de produits, inventaires, résultats de recherche et sessions utilisateur), ce qui réduit la charge de la base de données et améliore les temps de réponse lors des pics de trafic.
## Configuration du cluster
Choisissez un type de cluster en fonction de votre volume de données, de vos exigences en matière de débit et de vos préférences opérationnelles.
**Comparaison des types de clusters pour le commerce électronique**
| Type de cluster | Idéal pour | Mise à l’échelle | Considérations |
| --- | --- | --- | --- |
| sans serveur | Modèles de trafic variables, nouvelles applications, équipes sans expertise en matière d'opérations de cache | Automatique : adapte le calcul et la mémoire en fonction de la demande | Aucune planification des capacités n'est nécessaire. Modèle de coûts variables : vous payez pour ce que vous consommez. |
| Node-based (mode cluster activé) | Charges de travail prévisibles à haut débit, nécessité d'un contrôle précis du partitionnement et des types de nœuds | Dimensionnement manuel ou automatique des fragments et des répliques | Nécessite une planification des capacités. Modèle à coût fixe : vous payez pour la capacité provisionnée, quelle que soit son utilisation. Supporte jusqu'à 500 nœuds par cluster. |
Pour la plupart des applications de commerce électronique qui démarrent, Serverless constitue la voie la plus simple vers la production. Migrez vers des clusters basés sur des nœuds lorsque vous disposez de lignes de base de trafic prévisibles et que vous avez besoin d'un meilleur contrôle sur la topologie des clusters, les types de nœuds et le comportement de dimensionnement.
**Paramètres de cluster recommandés**
| Paramètre | Value | Justification |
| --- | --- | --- |
| Engine | Dernière version stable | Utilisez la dernière version stable de Valkey disponible dans ElastiCache. Entièrement compatible avec les commandes Redis OSS. Améliore les performances par rapport aux versions précédentes. |
| Multi-AZ | Activé | Basculement automatique vers un réplica situé dans une autre zone de disponibilité en cas de défaillance du nœud principal. Nécessaire pour les charges de travail de production en ligne. |
| In-transit chiffrement | Activé (TLS) | Chiffre les données entre votre application et le cluster de cache. Nécessaire pour les charges de travail gérant les sessions utilisateur ou toute autre information d'identification personnelle. |
| At-rest chiffrement | Activé | Chiffre les données sur disque (sauvegardes, échanges). Nécessaire pour les charges de travail de conformité. |
| Groupe de sous-réseaux | Sous-réseaux isolés privés (2\+ AZ) | Pas d'accès à Internet. Accessible uniquement depuis le groupe de sécurité de votre application. |
## Conception clé pour les données sur les produits
Concevez les clés de cache de manière à ce qu'elles soient prévisibles, déboguables et limitées afin d'éviter les collisions entre les types de données.
**Principales conventions de dénomination**
| Type de données | Schéma clé | Type de la valeur | Exemple |
| --- | --- | --- | --- |
| Détails du produit | `product:{id}` | Hachage | `product:12345`→ {nom, prix, description, imageURL} |
| Nombre d'inventaire | `inventory:{sku}` | Chaîne (entier) | `inventory:SKU-A100`→ 42 |
| Session utilisateur | `session:{sessionId}` | Hachage | `session:abc123`→ {ID utilisateur, panier, LastAccess} |
| Résultats de la recherche | `search:{queryHash}` | Chaîne (JSON) | `search:sha256(q=shoes&page=1)`→ [ID du produit] |
| Liste des catégories | `category:{slug}:page:{n}` | List | `category:electronics:page:1`→ [ID du produit] |
Meilleures pratiques clés en matière de conception :
+ Utilisez des deux-points comme séparateurs pour des raisons de lisibilité et de support d'outillage.
+ Utilisez des touches courtes : les touches longues consomment de la mémoire et de la bande passante réseau.
+ Incluez le préfixe du type de données pour éviter les collisions entre les produits, les sessions et d'autres entités susceptibles de partager des identifiants numériques.
+ Utilisez des hachages pour les objets multichamps (produits, sessions) afin de permettre des lectures et des mises à jour partielles sans récupérer la valeur complète.
## Stratégie TTL par type de données
Définissez des valeurs TTL (durée de vie) en fonction de la fréquence à laquelle les données changent et de leur caractère obsolète sans affecter l'expérience client.
**TTL recommandés pour les données de commerce électronique**
| Type de données | TTL | Déclencheur d'invalidation | Justification |
| --- | --- | --- | --- |
| Détails du produit | 5 minutes | Le vendeur modifie le produit | Les descriptions et les images des produits changent rarement. Suffisamment court pour récupérer les modifications assez rapidement sans invalidation explicite pour chaque modification. |
| Nombre d'inventaire | 30 secondes | Acheter ou réapprovisionner | Un inventaire périmé peut entraîner une survente. Un TTL très court garantit une actualisation fréquente des comptes. Annulation explicite lors de l'achat pour une précision immédiate. |
| Résultats de la recherche | 60 secondes | Aucun (TTL-based uniquement) | Les index de recherche sont mis à jour régulièrement. La mise en cache réduit la charge du moteur de recherche. Les nouveaux produits apparaissent dans les 60 secondes sans invalidation explicite. |
| Session utilisateur | 24 heures | Déconnexion ou expiration de session | Les sessions persistent tout au long de la navigation. Actualisez le TTL à chaque accès pour maintenir les sessions actives en vie. Supprimer explicitement lors de la déconnexion. |
| Liste des catégories | 2 minutes | Produit added/removed de la catégorie | Les pages de catégories sont très fréquentées. La mise en cache brève réduit considérablement les requêtes de base de données lors de la navigation. |
## Cache-aside motif
Le modèle de mise en cache (également appelé lazy loading) est la stratégie de mise en cache la plus courante pour les applications de commerce électronique. Votre application vérifie d'abord le cache et n'interroge la base de données qu'en cas d'échec du cache.
**Chemin de lecture (pseudocode)**
```
FUNCTION getProduct(productId):
cacheKey = "product:" + productId
// Step 1: Check the cache
cachedValue = cache.GET(cacheKey)
IF cachedValue exists:
RETURN deserialize(cachedValue) // Cache hit — sub-millisecond
// Step 2: Cache miss — query database
product = database.query("SELECT * FROM products WHERE id = ?", productId)
IF product not found:
RETURN null
// Step 3: Write to cache with TTL
cache.SET(cacheKey, serialize(product), EXPIRE = 300) // 5 minutes
RETURN product
```
**Chemin d'écriture (pseudocode)**
```
FUNCTION updateProduct(productId, updatedFields):
// Step 1: Update the database (source of truth)
database.update("UPDATE products SET ... WHERE id = ?", updatedFields, productId)
// Step 2: Invalidate the cache (don't update it)
cache.DELETE("product:" + productId)
// Next read will trigger a cache miss and repopulate from database
```
**Important**
Invalidez (supprimez) toujours plutôt que de mettre à jour le cache lors des écritures. Cela réduit la fenêtre pour les conditions de course où une lecture périmée remplace une valeur plus récente. La lecture suivante reremplit le cache de la base de données, qui est la source de vérité. Notez qu'une condition de concurrence restreinte existe toujours : si une lecture simultanée extrait des données de la base de données avant l'écriture, elle peut reremplir le cache avec des données périmées une fois que la clé de cache a déjà été supprimée. Pour la plupart des charges de travail de commerce électronique, le TTL court rend cela acceptable. Si vous avez besoin d'une cohérence stricte, utilisez un verrou distribué ou des écritures versionnées.
**Gestion des défaillances du cache**
```
FUNCTION getProductWithFallback(productId):
TRY:
RETURN getProduct(productId) // Normal cache-aside path
CATCH cacheConnectionError:
// Cache is unavailable — fall back to database directly
RETURN database.query("SELECT * FROM products WHERE id = ?", productId)
// Log the error, trigger an alarm, but don't fail the request
```
Concevez votre application de manière à ce que les défaillances du cache dégradent les performances (réponses plus lentes) mais n'interrompent pas les fonctionnalités. La base de données sert de solution de repli.
## Stratégies d'invalidation du cache
L'invalidation garantit que les utilisateurs voient les données actuelles après les mises à jour. Choisissez une stratégie en fonction de la rapidité avec laquelle les changements doivent être visibles.
**Approches d'invalidation**
| Approche | Comment ça marche | Quand l’utiliser |
| --- | --- | --- |
| Supprimer lors de l'écriture | L'application supprime la clé de cache immédiatement après la mise à jour de la base de données. | La plupart des écrits (modifications de produits, modifications de stocks). Simple, fiable, évite les données périmées. |
| Expiration TTL uniquement | N'invalidez pas : laissez le TTL expirer naturellement. | Données pour lesquelles une brève obsolescence est acceptable (résultats de recherche, listes de catégories, analyses). |
| Event-driven invalidation | Un processus d'arrière-plan écoute les événements de modification de la base de données et invalide les clés concernées. | Systèmes dans lesquels le chemin d'écriture et le cache se trouvent dans des services différents, ou lorsqu'une seule modification de base de données affecte de nombreuses clés de cache. |
Pour les applications de la place de marché qui utilisent également Amazon CloudFront comme couche CDN, coordonnez l'invalidation entre les deux niveaux : supprimez la ElastiCache clé * et * envoyez une invalidation du CloudFront cache (ou invalidation du cache-tag) afin que les utilisateurs puissent voir le contenu mis à jour à la fois au niveau de l'application et de la couche périphérique.
## Gestion des connexions
+ **Utiliser le pool de connexions ** : la création d'une nouvelle connexion TLS pour chaque opération de cache ajoute de la latence. Conservez un pool de connexions persistantes et réutilisez-les pour toutes les demandes.
+ **Définissez les délais de connexion ** : utilisez un délai de connexion court (1 à 2 secondes) et un délai d'expiration des commandes plus court (100 à 500 ms). Si le cache ne répond pas rapidement, revenez à la base de données plutôt que de bloquer la demande.
+ **Gérez le basculement avec élégance ** : en cas de Multi-AZ basculement, les connexions à l'ancien serveur principal sont interrompues. Votre pool de connexions doit détecter les connexions interrompues et se reconnecter automatiquement. La plupart des bibliothèques clientes gèrent cela, mais vérifiez le comportement testé.
+ **Utilisez le point de terminaison de configuration du cluster ** — Lorsque le mode cluster est activé, connectez-vous au point de terminaison de configuration plutôt qu'aux points de terminaison des nœuds individuels. Le point de terminaison de configuration achemine automatiquement les demandes vers la partition appropriée.
## Indicateurs clés à surveiller
**CloudWatch Alarmes Amazon recommandées pour le cache du commerce électronique**
| Métrique | Threshold | Period | Action |
| --- | --- | --- | --- |
| CacheHitRate | < 80 % | 5 min | Enquêtez : un faible taux de réussite signifie que vos TTL sont peut-être trop courts, que les touches sont mal conçues ou que la configuration de travail dépasse la mémoire. |
| EngineCPUUtilization | > 70 % | 5 min | Augmentez l'échelle (nœuds plus grands) ou réduisez l'échelle (plus de fragments). Un processeur élevé indique que le cache traite plus de commandes qu'il ne peut en gérer efficacement. |
| DatabaseMemoryUsagePercentage | > 80 % | 5 min | Risque d'expulsions. Augmentez la mémoire (augmentez l'échelle) ou réduisez les données stockées (TTL plus courts, moins de types de données mis en cache). |
| Evictions | > 0 soutenu | 1 min | Le cache est plein et les données sont supprimées pour libérer de la place. Augmente les erreurs de cache. Augmentez la mémoire ou réduisez les TTL pour les données moins critiques. |
| CurrConnections | > 80 % de la taille de votre pool de clients | 5 min | Piscine de connexion proche de l'épuisement. Augmentez la taille du pool, réduisez le temps d'attente des connexions ou examinez les fuites de connexion dans le code de l'application. Basez le seuil sur la taille du pool configurée pour votre application, et non sur la taille maximale du serveur (65 000). |
## Questions fréquentes (FAQ)
### Quand dois-je utiliser Serverless ou Node-Based ?
Utilisez Serverless lorsque votre trafic est imprévisible (nouvelle place de marché, pics saisonniers), lorsque vous souhaitez éviter la planification des capacités ou lorsque votre équipe n'a pas d'expertise en matière d'opérations de mise en cache. Passez à une approche basée sur les nœuds lorsque vos modèles de trafic sont stables, que vous avez besoin d'un contrôle précis du partitionnement ou que votre débit soutenu rend la gestion basée sur les nœuds plus rentable.
### Dois-je utiliser Valkey ou Redis OSS ?
Utilisez Valkey pour les nouveaux déploiements. Valkey est le moteur par défaut pour les nouveaux ElastiCache clusters. Il est entièrement compatible avec les commandes et les structures de données Redis OSS et fait l'objet d'un développement continu. Les clusters Redis OSS existants continuent de fonctionner : migrez vers Valkey lorsque cela vous convient grâce à la mise à niveau du moteur sur place.
### Que se passe-t-il lorsque le cache n'est pas disponible ?
Votre application doit traiter le cache comme une optimisation et non comme une dépendance. Si le cache n'est pas disponible, recommencez à interroger directement la base de données. Les temps de réponse seront plus longs, mais l'application reste fonctionnelle. Lorsque cette option est Multi-AZ activée, l'indisponibilité complète du cache est rare : le basculement vers une réplique s'effectue généralement en moins de 30 secondes.
### Comment puis-je estimer la mémoire dont j'ai besoin ?
Calculez : (nombre d'éléments uniques à mettre en cache) × (taille moyenne par élément) × (facteur de surcharge de 1,2 pour les structures de données Valkey). La surcharge varie en fonction de la taille de l'objet et du type de données ; les objets plus petits sont proportionnellement plus élevés. Par exemple, 100 000 produits de 2 Ko chacun avec une surcharge de 1,2 fois = environ 240 Mo. Ajoutez des données de session, des résultats de recherche et des inventaires. Commencez par la marge (utilisez 60 % de la mémoire disponible comme objectif) et surveillez la DatabaseMemoryUsagePercentage métrique pour l'ajuster.