Haute disponibilité, reprise après sinistre et Chaos Engineering

Extrait du mémoire de Master 2 Cybersécurité et Cloud de Holali David GAVI — Partie 5/6.

5.1 Architectures multi-zones et multi-régions

La haute disponibilité (HA) d’un système se mesure en pourcentage de temps de fonctionnement (uptime). Les « nines » de disponibilité sont devenues un standard industriel : 99,9% (« three nines ») autorise 8,76 heures d’indisponibilité par an, tandis que 99,99% (« four nines ») n’en autorise que 52,6 minutes. Atteindre les « five nines » (99,999%, soit 5,26 minutes/an) nécessite une architecture fondamentalement différente (Beyer et al., 2016).

Les fournisseurs cloud structurent leur infrastructure en régions (zones géographiques indépendantes) et zones de disponibilité (Availability Zones — datacenters physiquement séparés au sein d’une même région). AWS propose 34 régions avec 108 AZ, Azure 60+ régions, et GCP 40 régions avec 121 zones (données 2024).

Architecture multi-AZ — Le niveau minimal pour la production. Les composants critiques (control plane Kubernetes, bases de données, caches) sont répartis sur au moins 3 AZ. En Kubernetes, les topology spread constraints et les règles d’anti-affinité garantissent la distribution des Pods entre zones (Burns, 2018) :

Les managed Kubernetes (EKS, AKS, GKE) distribuent automatiquement les nœuds du control plane sur 3 AZ, offrant une résilience transparente. Pour les bases de données, les services managés (RDS Multi-AZ, Cloud SQL HA) gèrent la réplication synchrone et le failover automatique entre zones.

Architecture multi-régions — Nécessaire pour la résilience face aux pannes régionales (événements rares mais catastrophiques), la conformité réglementaire (données résidant dans une juridiction spécifique) et la réduction de la latence pour les utilisateurs géographiquement distribués. Verma et al. (2015) chez Google décrivent l’architecture Spanner, conçue pour maintenir la cohérence forte à l’échelle mondiale — un exploit technique qui repose sur des horloges atomiques (TrueTime API).

Le multi-régions introduit le défi de la réplication de données. Trois modèles coexistent :

• Active-Passive — Une région primaire traite les écritures, les régions secondaires reçoivent les répliques en lecture seule. Failover manuel ou semi-automatique. RPO dépendant du lag de réplication.
• Active-Active — Toutes les régions traitent lectures et écritures. Nécessite la résolution de conflits (last-write-wins, CRDTs, merge custom). Complexité élevée mais RTO quasi nul.
• Active-Active avec partitionnement — Chaque région « possède » un sous-ensemble des données (sharding géographique). Les utilisateurs européens sont routés vers la région EU, les américains vers US. Pas de conflit d’écriture mais migration complexe des utilisateurs entre régions.

5.2 Stratégies de backup et restauration

La règle 3-2-1, établie par le photographe Peter Krogh et adoptée par l’industrie IT, prescrit : 3 copies des données, sur 2 types de supports différents, dont 1 copie hors site. Dans le cloud, cette règle se traduit par : données primaires + réplique dans une autre AZ + backup dans une autre région (ou un autre fournisseur cloud).

Dans Kubernetes, Velero (VMware, anciennement Heptio Ark) est l’outil de référence pour le backup et la restauration. Velero sauvegarde les ressources Kubernetes (manifests YAML) et les données des PersistentVolumes via les Volume Snapshots CSI. Les backups sont stockés sur object storage (S3, GCS, Azure Blob) et peuvent être restaurés dans un cluster différent — facilitant la migration et le disaster recovery (Velero Documentation, 2024).

Pour les bases de données, les stratégies de backup incluent :

• Snapshots de volume — Backup au niveau bloc, rapide mais nécessitant un quiesce de la base pour garantir la cohérence. Les Volume Snapshots Kubernetes (CSI) automatisent ce processus.
• Backup logique — Export SQL (pg_dump, mysqldump). Plus lent mais portable entre versions et plateformes. Permet la restauration granulaire (table par table).
• Backup continu (Point-in-Time Recovery) — Archivage des WAL (Write-Ahead Log) pour PostgreSQL, des binlogs pour MySQL. Permet la restauration à n’importe quel instant dans le passé. Outils spécialisés : pgBackRest, Barman (PostgreSQL), Percona XtraBackup (MySQL).

Preston de Guise (2020) insiste sur un point souvent négligé : un backup non testé n’est pas un backup. Les exercices de restauration doivent être réguliers (mensuels ou trimestriels), automatisés si possible, et les résultats documentés. Le temps de restauration mesuré (RTO réel) doit être comparé au RTO contractuel.

5.3 RPO, RTO et plans de continuité

Deux métriques fondamentales gouvernent la conception des systèmes de reprise après sinistre :

RPO (Recovery Point Objective) — La quantité maximale de données que l’organisation accepte de perdre, exprimée en durée. Un RPO de 1 heure signifie que les backups doivent être effectués au moins toutes les heures. Un RPO de 0 exige une réplication synchrone — aucune transaction ne doit être perdue (Schmidt, 2006).

RTO (Recovery Time Objective) — Le temps maximum acceptable entre la survenue de l’incident et la restauration du service. Un RTO de 4 heures signifie que le système doit être fonctionnel dans les 4 heures suivant la panne.

Le Plan de Continuité d’Activité (PCA / BCP) et le Plan de Reprise d’Activité (PRA / DRP) formalisent les procédures de réponse aux sinistres. Le PCA couvre la continuité opérationnelle globale (y compris les processus humains), tandis que le PRA se concentre sur la restauration technique des systèmes IT. La norme ISO 22301:2019 fournit un cadre de référence pour leur élaboration.

Les plans doivent définir pour chaque composant critique :

• Le RPO et RTO cibles, alignés avec l’impact métier (BIA — Business Impact Analysis)
• La procédure de basculement (failover) — automatique ou manuelle, avec les critères de déclenchement
• La procédure de retour à la normale (failback) — comment revenir à l’infrastructure primaire
• Les rôles et responsabilités — qui déclenche, qui communique, qui valide
• Les canaux de communication hors-bande — que se passe-t-il si Slack/Teams est aussi en panne ?

5.4 Chaos Engineering

Le Chaos Engineering, formalisé par Casey Rosenthal et Nora Jones (2020) chez Netflix, est « la discipline de l’expérimentation sur un système distribué afin de renforcer la confiance dans la capacité du système à résister à des conditions turbulentes en production ». L’idée fondatrice : plutôt que d’attendre qu’une panne survienne, on la provoque délibérément dans un environnement contrôlé.

Le processus suit une méthodologie scientifique rigoureuse :

• Hypothèse — « Si le service de paiement tombe, le service de commande doit basculer vers le mode dégradé en moins de 5 secondes »
• Expérimentation — Injection de la panne (kill du Pod, latence réseau, corruption de données)
• Observation — Mesure de l’impact réel via les métriques et les logs
• Analyse — Comparaison entre le comportement attendu et le comportement observé
• Amélioration — Correction des faiblesses identifiées

Chaos Monkey (Netflix) — L’outil original, qui termine aléatoirement des instances en production. Fait partie du Simian Army (Chaos Gorilla pour les pannes de zone, Chaos Kong pour les pannes de région, Latency Monkey pour l’injection de latence).

Litmus (CNCF) — Framework de chaos engineering natif Kubernetes. Les expériences sont définies comme des ChaosExperiments (CRD) et orchestrées via des ChaosEngines. Le catalogue inclut : pod-delete, pod-network-loss, pod-cpu-hog, node-drain, disk-fill, etc. L’intégration avec les pipelines CI/CD permet d’exécuter automatiquement des tests de chaos avant chaque release (LitmusChaos Documentation, 2024).

Chaos Mesh (PingCAP, CNCF) — Alternative à Litmus avec un dashboard web intégré et un support avancé de l’injection de pannes réseau (partition, duplication de paquets, corruption DNS). Utilise les namespaces Linux et eBPF pour une injection précise sans agent dans les conteneurs.

5.5 Auto-scaling et élasticité

L’élasticité — la capacité d’adapter automatiquement les ressources à la demande — est un avantage fondamental du cloud, identifié par le NIST (Mell & Grance, 2011) comme l’une des cinq caractéristiques essentielles du cloud computing.

Kubernetes propose trois niveaux d’auto-scaling :

HPA (Horizontal Pod Autoscaler) — Ajuste le nombre de réplicas d’un Deployment en fonction de métriques. Par défaut, le HPA utilise l’utilisation CPU, mais les custom metrics (via Prometheus Adapter) et les external metrics (queue depth de SQS, nombre de messages Kafka) permettent un scaling basé sur la charge métier réelle plutôt que sur les ressources infrastructure (Kubernetes Documentation, 2024).

VPA (Vertical Pod Autoscaler) — Ajuste les requests/limits CPU et mémoire des Pods. Le VPA observe la consommation réelle et recommande (ou applique automatiquement) des valeurs optimales. Il est particulièrement utile pour les workloads dont la consommation est difficile à prédire. Note : HPA et VPA sur la même métrique (CPU) sont incompatibles — ils entrent en conflit.

Cluster Autoscaler / Karpenter — Ajuste le nombre de nœuds du cluster. Quand des Pods sont en état Pending (pas assez de ressources), le Cluster Autoscaler ajoute des nœuds. Quand des nœuds sont sous-utilisés, il les draine et les supprime. Karpenter (AWS, devenu projet CNCF) améliore ce modèle en sélectionnant dynamiquement le type d’instance optimal pour chaque workload — plutôt que d’utiliser des node groups prédéfinis (Karpenter Documentation, 2024).

KEDA (Kubernetes Event-Driven Autoscaling) — Étend le HPA avec 60+ scalers pour les sources d’événements : Azure Service Bus, AWS SQS, Kafka, RabbitMQ, Prometheus, cron schedules, etc. KEDA peut même scaler à zéro (scale-to-zero), éliminant les coûts quand aucun événement n’est à traiter — un avantage clé pour les workloads événementiels et batch.

5.6 Tests de charge et capacity planning

Le capacity planning vise à dimensionner l’infrastructure pour supporter la charge actuelle et anticipée, avec une marge de sécurité adéquate. Gregg (2020) recommande de maintenir l’utilisation des ressources critiques sous 70% en régime nominal, laissant 30% de marge pour les pics et les incidents.

Les tests de charge valident les hypothèses de capacity planning et identifient les goulots d’étranglement avant qu’ils n’impactent les utilisateurs. Trois types de tests se distinguent :

• Load testing — Simulation de la charge attendue en production. Vérifie que les SLOs (latence P99, taux d’erreur) sont respectés sous charge normale.
• Stress testing — Augmentation progressive de la charge au-delà des limites prévues. Identifie le point de rupture et le comportement du système en surcharge (dégradation gracieuse vs. crash).
• Soak testing (endurance) — Charge soutenue sur une longue durée (heures, jours). Détecte les fuites mémoire, l’accumulation de connexions, la fragmentation de la base de données.

k6 (Grafana Labs) — Outil de test de charge moderne, scriptable en JavaScript, avec un modèle d’exécution performant en Go. k6 produit des métriques au format Prometheus et s’intègre nativement avec Grafana Cloud pour l’analyse des résultats. L’opérateur Kubernetes k6 permet d’exécuter des tests distribués directement dans le cluster (Grafana Labs, 2024).

Locust (open source, Python) — Framework de test de charge distribué où les scénarios sont définis en Python. La distribution des workers sur Kubernetes permet de générer des millions de requêtes par seconde. L’interface web intégrée affiche les résultats en temps réel.

La corrélation entre les métriques de test de charge et les métriques d’infrastructure (CPU, mémoire, I/O, réseau) permet d’identifier précisément les composants limitants et de dimensionner l’auto-scaling en conséquence.

Références

• Beyer, B., Jones, C., Petoff, J. & Murphy, N. R. (2016). Site Reliability Engineering. O’Reilly Media / Google.
• Burns, B. (2018). Designing Distributed Systems. O’Reilly Media.
• Grafana Labs (2024). « k6 Documentation ». k6.io.
• Gregg, B. (2020). Systems Performance, 2nd Edition. Addison-Wesley.
• Karpenter Documentation (2024). « Just-in-time Nodes for Any Kubernetes Cluster ». karpenter.sh.
• Kubernetes Documentation (2024). « Horizontal Pod Autoscaler » et « Vertical Pod Autoscaler ». kubernetes.io.
• LitmusChaos Documentation (2024). « Introduction to Litmus ». litmuschaos.io.
• Mell, P. & Grance, T. (2011). « The NIST Definition of Cloud Computing ». NIST SP 800-145.
• Preston de Guise, W. (2020). Data Protection: Ensuring Data Availability. CRC Press.
• Rosenthal, C. & Jones, N. (2020). Chaos Engineering: System Resiliency in Practice. O’Reilly Media.
• Schmidt, K. (2006). High Availability and Disaster Recovery. Springer.
• Velero Documentation (2024). « Backup and Restore ». velero.io.
• Verma, A. et al. (2015). « Large-scale Cluster Management at Google with Borg ». EuroSys ’15.