Quand on parle d’architecture cloud robuste, on entend souvent : “il faut déployer l’application dans plusieurs régions”.
L’idée est bonne, mais elle est souvent sous-estimée.
Une architecture multi-région ne consiste pas simplement à copier une application dans deux datacenters différents. La vraie difficulté n’est généralement pas le code applicatif. Ce sont les données, la cohérence, le routage et la reprise après incident.
Région, Availability Zone et région principale
Dans le cloud, une région correspond à une zone géographique, par exemple l’Europe, les États-Unis ou l’Afrique du Sud.
Chaque région contient généralement plusieurs Availability Zones, c’est-à-dire plusieurs datacenters séparés physiquement.
Une architecture multi-AZ permet de résister à la panne d’un datacenter dans une même région.
Une architecture multi-région va plus loin : elle permet de continuer à fonctionner même si toute une région cloud devient indisponible.
Dans ce type d’architecture, on définit souvent une région principale.
C’est la région qui joue le rôle de référence pour l’application, notamment pour les écritures en base de données.
Par exemple :
Région principale : Europe
Région secondaire : Afrique du Sud
Les utilisateurs peuvent éventuellement lire depuis la région la plus proche, mais les écritures critiques sont souvent envoyées vers la région principale.
Le compute se duplique assez facilement
Les composants applicatifs sont souvent les plus simples à répliquer :
- serveurs web ;
- API ;
- conteneurs Docker ;
- workers ;
- fonctions serverless ;
- frontends statiques.
Si l’application est bien conçue, ces composants sont stateless. Cela signifie qu’ils ne stockent pas eux-mêmes l’état critique de l’application.
On peut donc les redéployer assez facilement dans plusieurs régions.
Mais le vrai problème commence avec les données.
Les données sont la partie difficile
Les données doivent rester cohérentes entre les régions :
- base de données ;
- sessions utilisateurs ;
- fichiers ;
- caches ;
- files de messages ;
- transactions ;
- droits d’accès.
Imaginons qu’un utilisateur modifie son adresse dans la région A.
Si un autre service lit l’information depuis la région B, il faut savoir si l’on accepte d’afficher une ancienne valeur pendant quelques secondes ou si l’on doit absolument lire la dernière version.
C’est ici que l’architecture devient stratégique.
Toutes les données n’ont pas le même niveau de criticité.
Une ancienne valeur temporaire peut être acceptable pour un compteur de vues ou des statistiques.
Elle l’est beaucoup moins pour un paiement, un solde bancaire, une réservation ou une facture.
Réplication synchrone ou asynchrone
Il existe deux grands modèles de réplication.
Réplication synchrone
Avec une réplication synchrone, la région principale écrit la donnée, puis attend que la région secondaire confirme la réplication avant de répondre au client.
Avantage : les données sont très cohérentes.
Inconvénient : les écritures sont plus lentes, car elles dépendent de la latence entre les régions.
Ce modèle est adapté aux cas où la cohérence est critique :
- paiements ;
- soldes bancaires ;
- réservations ;
- facturation ;
- droits d’accès sensibles.
Réplication asynchrone
Avec une réplication asynchrone, la région principale écrit la donnée et répond immédiatement au client. La copie vers l’autre région se fait ensuite avec un léger délai.
Avantage : l’application reste rapide.
Inconvénient : pendant un court moment, la région secondaire peut avoir une ancienne version de la donnée.
Ce modèle est souvent acceptable pour :
- statistiques ;
- logs ;
- reporting ;
- notifications ;
- catalogues peu critiques ;
- compteurs de vues ou de likes.
Strong consistency vs eventual consistency
Avec une strong consistency, chaque lecture retourne la dernière valeur écrite.
C’est plus sûr, mais souvent plus coûteux en performance.
Avec une eventual consistency, certaines lectures peuvent temporairement retourner une ancienne valeur. Après un certain délai, toutes les régions finissent par avoir la même donnée.
La vraie question n’est donc pas seulement technique.
C’est une question métier :
Est-ce grave si l’utilisateur voit une ancienne donnée pendant quelques secondes ?
Pour un solde bancaire, oui.
Pour un compteur de vues, probablement non.
Geo-routing : rapprocher l’application des utilisateurs
Le geo-routing permet de diriger les utilisateurs vers la région la plus proche.
Exemple :
Utilisateurs européens → région Europe
Utilisateurs américains → région US
Cela réduit la latence et améliore l’expérience utilisateur.
Mais il faut rester prudent : si chaque région peut accepter des écritures, il faut ensuite gérer les conflits entre régions.
Par exemple :
- deux utilisateurs modifient la même donnée en même temps ;
- une région tombe avant d’avoir répliqué les dernières écritures ;
- deux versions différentes existent temporairement ;
- le système doit décider quelle version garder.
Pour éviter cette complexité, beaucoup d’architectures choisissent un modèle plus simple :
Lectures proches des utilisateurs
Écritures centralisées dans une région principale
Ce compromis est souvent suffisant pour de nombreuses applications SaaS, plateformes métier ou applications internes critiques.
Active-passive : un modèle souvent raisonnable
Dans une architecture active-passive :
- la région A est active ;
- la région B est prête à prendre le relais ;
- les données sont répliquées de A vers B ;
- si A tombe, B est promue.
C’est ce qu’on appelle un failover.
La région secondaire devient alors la nouvelle région principale.
Mais le retour à la normale, appelé failback, demande de la rigueur.
Avant de renvoyer le trafic vers la région initiale, il faut :
- vérifier les données ;
- réconcilier les changements ;
- résoudre les conflits éventuels ;
- remettre la région initiale à jour ;
- tester que tout fonctionne correctement.
Le failover est souvent plus simple que le failback.
Les deux indicateurs à définir : RPO et RTO
Avant de construire une architecture multi-région, il faut définir deux indicateurs.
RPO — Recovery Point Objective
Le RPO répond à la question :
Combien de données peut-on perdre au maximum ?
Exemple :
RPO = 5 minutes
Cela signifie que l’entreprise accepte de perdre jusqu’à 5 minutes de données en cas de panne majeure.
RTO — Recovery Time Objective
Le RTO répond à la question :
Combien de temps l’application peut-elle rester indisponible ?
Exemple :
RTO = 30 minutes
Cela signifie que le service doit être rétabli en moins de 30 minutes.
Ces deux chiffres ont un impact direct sur le coût et la complexité.
Plus le RPO et le RTO sont faibles, plus l’architecture devient exigeante.
Conclusion
Une architecture multi-région est puissante, mais elle doit être conçue avec pragmatisme.
Le plus important n’est pas de tout rendre actif partout.
Le plus important est de répondre clairement à ces questions :
- où sont les utilisateurs ?
- quelle région accepte les écritures ?
- quelles données doivent être fortement cohérentes ?
- quelles données peuvent être éventuellement cohérentes ?
- combien de données peut-on perdre ?
- combien de temps peut-on rester indisponible ?
- comment se passe le failover ?
- comment se passe le failback ?
Pour beaucoup d’entreprises, le bon point de départ est une architecture simple :
Une région principale
Une région secondaire
Des composants applicatifs réplicables
Une base répliquée
Un plan de failover documenté et testé
La résilience ne vient pas seulement de l’infrastructure.
Elle vient surtout de choix clairs, testés et alignés avec les risques réels du business.
Besoin d’aide pour concevoir une architecture cloud plus résiliente ?
Mettre en place une architecture multi-région ne consiste pas seulement à dupliquer des serveurs. Il faut définir les bons compromis entre disponibilité, performance, cohérence des données, coûts, complexité et risques métier.
Une architecture très résiliente peut devenir coûteuse si elle n’est pas alignée avec les vrais besoins de l’entreprise. L’objectif n’est donc pas forcément de construire l’architecture la plus complexe, mais celle qui offre le bon niveau de protection au bon budget.
Chez iFox Code, nous aidons les entreprises à concevoir, moderniser et sécuriser leurs architectures applicatives, cloud et data.
Si vous souhaitez évaluer la résilience de votre plateforme, identifier les points de faiblesse ou définir une architecture adaptée à vos enjeux et à votre budget, contactez-nous pour en discuter.
