Multirégion, reprise après sinistre et edge computing

Pourquoi fonctionner sur plus d’une région

La section 0.7 (serveurs et cloud) a présenté les régions (des zones géographiques distinctes) et les zones de disponibilité (des groupes de centres de données indépendants au sein d’une région), et la section 10.1 a montré comment les fournisseurs les organisent. Fonctionner sur plusieurs zones de disponibilité d’une même région est la base normale de tout système de production : cela survit à la perte d’un centre de données pour un faible surcoût, parce que les zones sont assez proches pour une réplication synchrone. Fonctionner sur plusieurs régions est un pas beaucoup plus important, et il n’y a que trois bonnes raisons de le franchir.

La latence. La lumière dans la fibre optique se déplace à environ 200 000 km par seconde : un aller-retour entre Londres et Sydney (environ 17 000 km à vol d’oiseau) ne peut donc pas prendre moins d’environ 170 ms, et les itinéraires réels prennent nettement plus de temps. Une requête qui exige plusieurs allers-retours vers une région lointaine paraît lente, aussi rapides que soient les serveurs. Servir les utilisateurs depuis une région proche, ou depuis la périphérie, est la seule solution.

La reprise après sinistre. Des régions entières tombent bel et bien en panne, généralement à cause d’une dépendance partagée plutôt que d’une catastrophe physique. Les 19 et 20 octobre 2025, une condition de concurrence dans l’automatisation qui gère les enregistrements DNS d’Amazon DynamoDB a laissé son endpoint US-EAST-1 avec un enregistrement DNS vide ; les erreurs de DynamoDB ont duré environ trois heures, mais les défaillances en cascade dans le lancement de nouvelles machines virtuelles et dans les contrôles de santé des équilibreurs de charge ont duré jusqu’à l’après-midi suivant. Tous les grands fournisseurs ont connu des incidents régionaux comparables. La reprise après sinistre s’y prépare.

La résidence des données. Les exigences de résidence des données, issues de la loi, des régulateurs ou des contrats clients, peuvent imposer que certaines données soient stockées ou traitées dans des juridictions précises. Le RGPD lui-même restreint les transferts de données à caractère personnel hors de l’Espace économique européen plutôt qu’il n’exige un stockage local, mais les règles sectorielles, les lois nationales et les contrats d’entreprise vont souvent plus loin (voir protection de la vie privée dès la conception). La résidence impose souvent des conceptions multirégions dans lesquelles les données ne sont délibérément pas répliquées partout.

Le multirégion coûte cher : infrastructure dupliquée, frais de transfert de données entre régions, cohérence des données plus difficile, exploitation et tests plus complexes. Beaucoup d’équipes qui pensent en avoir besoin ont en réalité besoin d’une bonne conception multizone, de sauvegardes testées et d’un CDN.

Les objectifs de reprise et les quatre stratégies

La section 2.5 (disponibilité et fiabilité) a défini les deux chiffres qui pilotent toute conception de reprise après sinistre. L’objectif de temps de reprise (RTO) est la durée pendant laquelle le service peut être indisponible ; l’objectif de point de reprise (RPO) est la quantité de données récentes qui peut être perdue, exprimée en temps. Les deux viennent du métier, idéalement du coût d’une heure de panne et d’une commande perdue, et non des préférences des ingénieurs. Des valeurs plus basses coûtent plus cher, et le coût grimpe fortement à l’approche de zéro.

Le livre blanc AWS Well-Architected Disaster Recovery of Workloads on AWS: Recovery in the Cloud décrit quatre stratégies, par ordre croissant de coût et de complexité. Leurs noms sont largement utilisés au-delà d’AWS et s’appliquent tout autant à Azure, à Google Cloud ou à une paire de centres de données privés.

Le livre blanc lui-même donne un seul chiffre approximatif couvrant à la fois le RTO et le RPO pour chaque stratégie ; le tableau les sépare parce que, avec une réplication continue, le RPO du pilot light et du warm standby est fixé par le retard de réplication plutôt que par la part de l’application qui tourne. Deux mises en garde valent pour toutes les colonnes. La réplication n’est pas une sauvegarde : une suppression accidentelle, une mauvaise migration ou un rançongiciel sont répliqués fidèlement en quelques secondes ; des sauvegardes à un instant donné, idéalement immuables et dans un compte séparé, sont donc nécessaires même dans une conception actif-actif. Et une stratégie qui n’a pas été répétée est un espoir, pas un plan. Les équipes qui font un exercice de basculement régional au moins quelques fois par an découvrent des autorisations manquantes, des endpoints codés en dur, des certificats expirés et des quotas trop petits dans la région de reprise, pendant qu’il est encore peu coûteux de les trouver.

Répliquer les données entre régions

Les serveurs d’application sans état sont faciles à faire tourner à deux endroits ; les données sont la partie difficile, et les compromis sont ceux de la cohérence, du CAP et de PACELC à l’échelle des continents. La réplication synchrone entre régions signifie que chaque écriture attend au moins un long aller-retour, peut-être 70 à 150 ms ou plus, ce qui est acceptable pour quelques écritures critiques et ruineux pour des échanges bavards. La réplication asynchrone garde des écritures rapides, mais la réplique est en retard, et tout ce qui n’est pas arrivé quand la région primaire tombe en panne est perdu : le retard de réplication est le RPO effectif.

Il existe quatre conceptions de données courantes. Une seule région primaire : toutes les écritures vont vers une région, et des répliques ailleurs servent les lectures et la reprise ; c’est simple, mais les utilisateurs lointains paient la latence des écritures, et le basculement implique de promouvoir une réplique (avec les risques de split brain décrits dans réplication et partitionnement). Une région de rattachement par entité : chaque client, restaurant ou locataire a une région de rattachement où ses données sont écrites, ce qui garde les écritures locales et favorise la résidence, au prix du routage et de rares opérations interrégions. Plusieurs écrivains avec résolution des conflits : chaque région accepte des écritures et les conflits sont fusionnés, par exemple par last-writer-wins (la dernière écriture l’emporte, le comportement par défaut des tables globales DynamoDB) ou par des types de données répliqués sans conflit ; ce n’est sûr que pour les données dont la fusion a un sens, comme un panier, et c’est dangereux pour l’argent ou les stocks. Les bases de données à cohérence globale, comme Google Spanner ou CockroachDB, paient la latence du consensus sur les écritures pour offrir une cohérence forte entre régions ; Azure Cosmos DB laisse chaque application choisir parmi cinq niveaux de cohérence, de forte à à terme.

La plupart des systèmes réels combinent ces conceptions selon les jeux de données, exactement comme le recommande la section 6.6 : les paiements et l’état des commandes dans une seule région primaire ou une région de rattachement, les cartes et les informations sur les restaurants répliquées partout pour les lectures, et les données analytiques expédiées de façon asynchrone.

Basculement, DNS et stabilité statique

Le trafic est orienté entre les régions par le DNS ou par un équilibreur de charge global. Avec un basculement (failover) fondé sur le DNS, le service DNS contrôle la santé de chaque région et renvoie l’adresse d’une région saine ; sa faiblesse est la mise en cache, car les résolveurs et les clients peuvent conserver d’anciennes réponses plus longtemps que le TTL de l’enregistrement. Les équilibreurs de charge globaux (par exemple AWS Global Accelerator, Azure Front Door, l’équilibreur de charge externe global de Google Cloud, Cloudflare) utilisent des adresses anycast annoncées depuis de nombreux emplacements : les clients gardent une seule adresse et le fournisseur déplace le trafic en quelques secondes.

Décider quand basculer est plus difficile que le mécanisme. Le basculement automatique réagit le plus vite, mais il peut être déclenché par une faute de la supervision ou par une brève coupure réseau, et basculer une base de données risque de laisser deux primaires accepter des écritures. Beaucoup d’organisations automatisent donc la détection et les étapes du basculement, mais conservent une décision humaine pour lancer un basculement régional, avec un runbook et une limite de temps. Le retour à la région d’origine après l’incident, y compris la resynchronisation des données écrites dans la région de reprise, demande lui aussi un plan.

L’incident d’octobre 2025 illustre un principe que l’AWS Builders’ Library appelle la stabilité statique : un système devrait continuer à fonctionner pendant une défaillance sans avoir à faire de changements à ce moment-là. Les systèmes qui disposaient déjà d’assez de capacité en fonctionnement ont traversé le problème ; ceux qui devaient lancer de nouvelles instances, ou dont la reprise dépendait d’actions du plan de contrôle dans la région touchée, n’ont pas pu se rétablir avant la région elle-même. Pour la reprise après sinistre, cela plaide pour une capacité provisionnée à l’avance (warm standby plutôt que pilot light, pour les chemins critiques), pour un basculement qui ne dépend que du plan de données de la région saine, et pour un DNS, une gestion des identités et des secrets qui ne résident pas uniquement dans la région que vous quittez.

Les cellules : limiter le rayon d’impact

Les régions protègent contre les sinistres régionaux ; la plupart des pannes, cependant, sont causées par les propres changements du système, par des surcharges et par des entrées empoisonnées, qu’une seconde région exécutant le même code et la même configuration subira aussi. L’architecture cellulaire limite le rayon d’impact de ces défaillances en faisant tourner de nombreuses copies complètes et indépendantes du système, appelées cellules, chacune servant un sous-ensemble fixe de clients. Un routeur léger associe chaque requête à sa cellule, généralement selon l’identifiant du client ou du locataire. Les cellules ne partagent rien à l’exécution : chacune a ses propres instances d’application, ses files et ses bases de données.

Si une cellule subit un mauvais déploiement, un client très actif ou une corruption de données, seuls les clients de cette cellule sont touchés : avec 20 cellules, environ 5 % d’entre eux. Les déploiements se font cellule par cellule, par vagues, si bien qu’une mauvaise version est détectée dans la première cellule. Cette conception est décrite dans le livre blanc AWS Well-Architected Reducing the Scope of Impact with Cell-Based Architecture (2023) et est utilisée à grande échelle par les propres services d’AWS et par des entreprises comme Slack. Une technique apparentée, le shuffle sharding, attribue à chaque client une combinaison aléatoire de quelques workers parmi beaucoup (avec 8 workers et 2 par client, il y a 28 combinaisons) : un client dont les requêtes font planter des workers n’abat que sa propre combinaison, et la plupart des autres clients partagent au plus un worker avec lui.

Les cellules ont un coût : davantage d’instances et de bases de données à exploiter, des opérations transverses aux cellules (rapports sur l’ensemble des clients, déplacement d’un client d’une cellule à une autre) qui demandent des mécanismes distincts, et un routeur et un service de correspondance qui doivent être extrêmement simples et fiables. Elles conviennent aux grands systèmes multilocataires dotés de clés de partitionnement naturelles ; pour une application interne monolocataire, c’est de la surconception.

La périphérie : CDN et fonctions en périphérie

Entre les utilisateurs et les régions se trouve la périphérie (edge) : les centaines d’emplacements exploités par des réseaux de diffusion de contenu (CDN) comme Akamai, Cloudflare, Fastly, Amazon CloudFront et Azure Front Door. Un CDN met en cache le contenu statique et pouvant être mis en cache (images, scripts, pages de carte) près des utilisateurs, en suivant les règles de mise en cache HTTP décrites dans mise en cache, et absorbe les pics de trafic et de nombreuses attaques par déni de service avant qu’ils n’atteignent l’origine.

Les fonctions en périphérie (edge functions) vont plus loin en exécutant du code à ces emplacements : Cloudflare Workers, Fastly Compute, CloudFront Functions et Lambda@Edge, Akamai EdgeWorkers, et les edge functions de plateformes comme Vercel et Netlify. Cloudflare Workers exécute le code dans des isolats V8 légers, les bacs à sable que les moteurs JavaScript utilisent pour les onglets du navigateur, plutôt que dans un conteneur par fonction : le démarrage est donc très rapide et de nombreux locataires partagent un même processus en toute sécurité. Ce cours lui-même tourne sur Cloudflare Workers. Les bons usages sont le routage des requêtes et l’affectation A/B, les contrôles d’authentification et la validation des tokens, les règles d’en-têtes et de redirection, le redimensionnement d’images, la personnalisation simple, et les proxys d’API qui gardent les clés secrètes hors du navigateur.

Les limites sont architecturales. Les fonctions en périphérie ont des limites strictes de temps CPU et de mémoire ; le stockage en périphérie est généralement à cohérence à terme (Workers KV de Cloudflare peut mettre un certain temps à propager une écriture à l’échelle mondiale) ou n’offre une cohérence forte que pour un seul objet coordinateur, comme le font les Durable Objects ; et le système de référence reste normalement dans une région. Un modèle courant est donc lire en périphérie, écrire à l’origine : servir les cartes, les pages des restaurants et les vérifications de session depuis la périphérie, et envoyer les commandes et les paiements vers la région de rattachement.