Régions, zones et haute disponibilité
Résumé : le cloud est physiquement organisé en régions (zones géographiques), elles-mêmes découpées en zones de disponibilité (datacenters isolés), complétées par des points de présence pour la diffusion de contenu. Comprendre cette géographie est indispensable pour concevoir une application qui survit à une panne et pour choisir où placer ses données.
1. La hiérarchie géographique du cloud
Le détail qui compte : les zones de disponibilité d'une même région sont suffisamment proches pour une latence très faible entre elles (généralement moins de 2 millisecondes), mais suffisamment éloignées pour qu'un incendie, une inondation ou une coupure électrique n'en affecte qu'une seule. C'est un compromis d'ingénierie délibéré.
2. Pourquoi les zones de disponibilité existent
L'incendie d'OVH à Strasbourg en mars 2021 est le cas d'école le plus instructif en Europe. Un datacenter entier a été détruit. Les clients qui avaient réparti leur infrastructure sur plusieurs sites ont continué de fonctionner. Ceux qui avaient tout concentré, y compris leurs sauvegardes, ont perdu leurs données définitivement — plusieurs entreprises ne s'en sont jamais relevées.
La leçon opérationnelle : une sauvegarde stockée dans la même zone que la production n'est pas une sauvegarde. C'est une copie qui disparaîtra avec l'original.
3. Les niveaux de résilience
Recommandation claire : visez le niveau 2 — plusieurs zones de disponibilité dans une seule région. Il couvre l'immense majorité des incidents réels, et son surcoût est modeste (les transferts entre zones sont peu ou pas facturés, contrairement aux transferts entre régions).
Le niveau 4 est rarement justifié. Il apporte une complexité considérable, notamment sur la cohérence des données — que se passe-t-il si le même utilisateur écrit simultanément dans deux régions ? Réservez-le aux services où quelques minutes d'indisponibilité coûtent réellement très cher.
4. Comment choisir sa région
Le critère 5 est souvent oublié et cause de vrais problèmes. Beaucoup de systèmes distribués — etcd, Kafka, les bases de données répliquées — ont besoin d'un quorum, donc d'un nombre impair de nœuds. Avec seulement deux zones de disponibilité, vous ne pouvez pas construire un quorum résistant à la perte d'une zone. Trois zones est le minimum pratique.
5. Comprendre la latence géographique
Une limite physique incontournable : la lumière dans une fibre optique parcourt environ 200 000 kilomètres par seconde. Aucune optimisation logicielle ne contournera la vitesse de la lumière. Si vos utilisateurs sont en Australie et vos serveurs en France, la seule solution est de rapprocher les serveurs.
La conséquence pratique la plus utile : c'est la raison d'être des réseaux de diffusion de contenu (CDN). Vos images, fichiers JavaScript et pages statiques sont copiés dans des centaines de points de présence, servis depuis le plus proche de chaque utilisateur.
6. Les réseaux de diffusion de contenu
Principaux acteurs : Cloudflare (le plus utilisé, avec une offre gratuite très généreuse), AWS CloudFront, Azure Front Door, Google Cloud CDN, Fastly, Akamai (le pionnier historique).
Conseil pratique à fort impact : mettre Cloudflare devant un site web est souvent l'amélioration de performance la plus rentable qui existe — quelques minutes de configuration, gratuit dans son offre de base, et une réduction très nette du temps de chargement pour les visiteurs distants.
7. Comprendre les engagements de disponibilité
Voici ce que signifient concrètement les pourcentages :
| Disponibilité | Indisponibilité par an | Par mois | Appellation courante |
|---|---|---|---|
| 99 % | 3,65 jours | 7,2 heures | Deux neuf |
| 99,9 % | 8,76 heures | 43,8 minutes | Trois neuf |
| 99,95 % | 4,38 heures | 21,9 minutes | — |
| 99,99 % | 52,6 minutes | 4,38 minutes | Quatre neuf |
| 99,999 % | 5,26 minutes | 26 secondes | Cinq neuf |
Le piège de composition, essentiel à comprendre : les disponibilités se multiplient. Si votre application dépend de trois services affichant chacun 99,9 %, votre disponibilité théorique maximale est 0,999³ = 99,7 %, soit près de 26 heures d'indisponibilité par an. Chaque dépendance ajoutée dégrade votre disponibilité globale.
Conséquence de conception : la haute disponibilité ne s'obtient pas en empilant des services fiables, mais en concevant pour la défaillance — délais d'attente, réessais, disjoncteurs, dégradation gracieuse.
8. RTO et RPO — les deux objectifs de reprise
Ces deux sigles sont incontournables dès qu'on parle de plan de reprise, y compris en entretien.
Le bon ordre de raisonnement : définissez d'abord le RTO et le RPO avec les responsables métier, en euros de perte, puis concevez l'architecture correspondante. L'erreur classique est de construire une architecture sophistiquée puis de découvrir que le métier acceptait très bien quatre heures d'indisponibilité — et que la moitié du budget était superflue.
9. Les bonnes pratiques de résilience
La pratique 3 est celle que tout le monde néglige. Des entreprises découvrent le jour de l'incident que leurs sauvegardes étaient corrompues depuis huit mois, ou qu'il manquait un élément indispensable à la restauration. Testez une restauration complète au moins une fois par trimestre.
Retenir en 30 secondes
- Hiérarchie : région > zone de disponibilité > datacenter. Plus les points de présence pour la diffusion.
- Les zones d'une même région sont isolées physiquement mais reliées par une latence de 1 à 2 ms.
- Visez le niveau 2 : plusieurs zones dans une région. Excellent rapport résilience / coût.
- Trois zones minimum si vous utilisez un système à quorum (base r épliquée, etcd, Kafka).
- Une sauvegarde dans la même zone que la production n'est pas une sauvegarde — leçon de l'incendie OVH Strasbourg 2021.
- La latence est physique : Paris-Virginie coûte environ 85 ms, aucune optimisation ne l'annule. D'où les CDN.
- Les disponibilités se multiplient : trois services à 99,9 % donnent 99,7 % au total.
- Définissez RTO (durée d'indisponibilité tolérée) et RPO (perte de données tolérée) avec le métier, d'abord.
- Testez vos restaurations au moins chaque trimestre.
Suivant : AWS vs Azure vs Google Cloud : le comparatif honnête →