Aller au contenu

AWS Mis à jour le 2026-07-04

WooCommerce sur AWS : la liste de contrôle d'exploitation pour les boutiques qui ne peuvent pas perdre de commandes

Faire tourner WooCommerce sur AWS sans perdre de commandes se résume à une liste de contrôle : écritures de commandes durables, sessions hors du disque local, règles de cache qui ne touchent jamais au paiement, et exercices de restauration qui comptent les commandes.

Une boutique WooCommerce diffère de tout autre site WordPress par un fait d’exploitation : elle prend de l’argent, donc chaque requête qui compte est une écriture. Les commandes, les décréments de stock, les webhooks de paiement et les paniers ne peuvent pas être servis depuis le cache, ne peuvent pas se perdre dans une bascule, et ne peuvent pas échouer en silence pendant que la page d’accueil reste verte. La liste de contrôle d’exploitation AWS pour une boutique qui ne peut pas perdre de commandes se bâtit donc d’abord autour de la durabilité des écritures et de la justesse des sessions, la vitesse ensuite — parce qu’une boutique rapide qui perd une commande sur cent est discrètement pire qu’une boutique plus lente qui n’en perd aucune.

Ce que vous décidez

La question derrière chaque ligne de la liste : quelles pannes acceptez-vous de survivre? Quatre mécanismes décident si une commande survit à cinq mauvaises minutes :

Où atterrit l’écriture de la commande. WooCommerce écrit la commande dans la base de données dans la même requête qui la confirme au client. Si la base est une instance mono-AZ, une bascule, un événement de maintenance ou une panne de stockage pendant le paiement échappe la commande en pleine écriture. Un RDS Multi-AZ ou Aurora transforme ça en quelques secondes d’erreurs réessayables. Le choix entre les deux est le sujet de RDS ou Aurora pour le palier de données WordPress.

Où vivent le panier et la session. Sur un serveur unique, les sessions PHP sur disque local fonctionnent par accident. Derrière un répartiteur de charge, un client dont les requêtes tombent sur deux instances obtient deux paniers — des articles disparaissent, des paiements restent à moitié faits. Les paniers appartiennent à la base de données ou à ElastiCache pour Redis, jamais au disque d’une instance.

Ce que le cache a le droit de toucher. Le cache pleine page est ce qui permet à WooCommerce d’encaisser une pointe marketing sur un calcul modeste, et c’est aussi la source classique du pire bogue du commerce : un client qui voit le panier, l’adresse ou la confirmation de commande d’un autre parce que /checkout/ ou /my-account/ s’est retrouvé en cache. Cachez agressivement, mais la liste d’exclusion porte la structure.

Si le travail asynchrone tourne vraiment. Les webhooks de paiement (Stripe, PayPal) et les tâches d’Action Scheduler (renouvellements d’abonnements, synchronisations de stock, courriels de suivi) échouent en silence. Une boutique peut paraître en parfaite santé pendant des jours pendant que les renouvellements s’arrêtent sans bruit.

Quoi vérifier en premier

  • Le comportement du cache sur les pages d’argent : est-ce que /cart/, /checkout/ ou /my-account/ retourne parfois un HIT?
  • MultiAZ sur l’instance de base de données, et la fenêtre de rétention contre votre volume de commandes — avec la récupération à un instant précis, l’exposition se compte en minutes; sans elle, jusqu’à une journée de commandes.
  • Où les sessions sont stockées — un gestionnaire de sessions WooCommerce adossé à Redis ou à la base de données, pas le défaut fichier de PHP.
  • L’arriéré d’Action Scheduler : WooCommerce > Status > Scheduled Actions, trié par tâches en retard.
  • Si un échec de webhook de paiement téléavertirait quelqu’un, ou s’accumulerait simplement dans un tableau de bord de passerelle que personne n’ouvre.

Comment vérifier

Confirmez que le cache ne touche jamais au paiement — de l’extérieur, comme un client :

# Ceux-ci ne doivent jamais être des HIT, et doivent poser des en-têtes no-cache
curl -sI https://store.example.com/checkout/ | grep -iE 'x-cache|cache-control'
curl -sI https://store.example.com/cart/ | grep -iE 'x-cache|cache-control'

# Une page produit DEVRAIT être en cache
curl -sI https://store.example.com/product/sample/ | grep -iE 'x-cache|age'

Confirmez que le palier de données peut perdre une AZ :

aws rds describe-db-instances \
  --db-instance-identifier prod-woo-db \
  --query 'DBInstances[0].[MultiAZ,BackupRetentionPeriod,LatestRestorableTime]'

Confirmez que le magasin de sessions est partagé :

aws elasticache describe-replication-groups \
  --query 'ReplicationGroups[].[ReplicationGroupId,Status,AutomaticFailover]' \
  --output table

Dans la console, RDS > Databases > Monitoring pendant une pointe de trafic montre si DatabaseConnections et la latence d’écriture ont de la marge — c’est là que les échecs de paiement apparaissent en premier.

Le plan d’exécution

  1. Rendre le palier de données survivable. RDS Multi-AZ ou Aurora, récupération à un instant précis activée, et marge de connexions validée à la pointe plus la moitié. Tout le reste de la liste suppose que l’écriture de la commande atterrit.
  2. Déplacer les sessions et les paniers vers Redis. Un magasin de sessions partagé rend les instances jetables et la répartition de charge sécuritaire. Le patron, y compris le comportement en bascule, est dans le patron de magasin de sessions Redis.
  3. Écrire la liste d’exclusion du cache et la tester de l’extérieur. Panier, paiement, mon-compte et tout ce qui porte un témoin de session WooCommerce contournent le cache de page. Relancez les vérifications curl après chaque changement de couche de cache, dans le pipeline de déploiement si possible.
  4. Alerter sur les symptômes commerciaux, pas seulement l’infrastructure. Des commandes à l’heure qui tombent à zéro pendant les heures d’affaires, c’est l’alarme qui compte; la détection d’anomalies CloudWatch sur une métrique personnalisée OrdersCreated attrape ce que les graphiques de CPU ne verront jamais.
  5. Surveiller la machinerie asynchrone. Une vérification planifiée du nombre de tâches en retard d’Action Scheduler, et des points de webhook journalisés et alarmés sur le taux d’échec. Lancez wp action-scheduler run via cron plutôt que de compter sur le trafic du site pour le déclencher.
  6. Tester en charge avant les événements de vente avec des utilisateurs connectés, panier en main. Les tests de navigation anonyme prouvent seulement que le CDN fonctionne. Le vrai plafond de la boutique, c’est le trafic de paiement non mis en cache, porteur de session, qui frappe PHP et la base de données.
  7. Exercer les restaurations en comptant les commandes. Restaurez la sauvegarde d’hier soir dans un environnement jetable et comparez le compte de commandes avec la production sur la même fenêtre. Une restauration qui perd des commandes est une découverte que vous voulez faire en exercice, pas en incident.

Quand c’est la mauvaise approche

Une boutique qui fait une poignée de commandes par jour n’a pas besoin de Multi-AZ, de Redis et d’un répartiteur de charge; une instance unique bien sauvegardée avec des tests de restauration honnêtes suffit, et les heures d’ingénierie sont mieux dépensées sur les produits. Cette liste mérite son coût quand une heure d’arrêt coûte visiblement des revenus, quand les événements de vente multiplient le trafic de base, ou quand les abonnements rendent l’échec asynchrone silencieux coûteux. Sous cette ligne, appliquez seulement les points 3, 5 et 7 — ils sont presque gratuits.

Erreurs fréquentes

  • Mettre /checkout/ en cache après un changement d’extension ou de configuration CDN — le bogue qui montre aux clients les données des autres et finit dans un rapport d’incident à votre processeur de paiement.
  • Les sessions collantes comme substitut à un magasin de sessions partagé : ça fonctionne jusqu’à ce que l’autoscaler remplace une instance en pleine séance de magasinage.
  • Tester la performance déconnecté et conclure que la boutique tient la charge, alors que le trafic de paiement contourne tous les caches testés.
  • Considérer les réessais de webhooks de la passerelle comme un filet de sécurité; les réessais expirent, et un point de webhook qui retourne des 500 pendant une journée perd de vrais renouvellements d’abonnements.

Garder le contrôle

  • Relancer les vérifications de cache externes après tout changement aux extensions de cache, aux comportements CloudFront ou aux en-têtes.
  • Réviser l’arriéré des Scheduled Actions chaque semaine; la croissance des tâches en retard est le premier signe de trouble asynchrone.
  • Suivre les commandes à l’heure comme métrique de premier ordre avec alarmes d’anomalie, et y annoter les déploiements.
  • Répéter le guide des grandes ventes (montée en capacité, réchauffement du cache, assignation de garde) avant la saison, pas pendant.
  • Exercice de restauration trimestriel avec vérification du compte de commandes, consigné avec dates.

Chaque élément ici est de la discipline ordinaire; ce qui manque aux boutiques, c’est quelqu’un d’imputable pour la liste entière à la fois. Faire tourner un WordPress ou un WooCommerce sur AWS qui rapporte vraiment mérite un opérateur, pas un montage de fin de semaine — Stack Harbor opère exactement cette pile sous infogérance WordPress ; réservez une consultation d’infrastructure.