Régions et zones de disponibilité

Le centre de données infaillible n'existe pas

Imaginez une boutique en ligne dont tous les serveurs tournent dans un seul bâtiment. Ce bâtiment perd l'alimentation pendant le plus gros jour de soldes de l'année, et chaque serveur s'éteint au même instant. Peu importe la qualité du code ou la capacité que les serveurs auraient pu gérer autrement : la boutique reste hors ligne jusqu'à ce que quelqu'un rétablisse le courant à cet endroit précis. Les fournisseurs cloud font face à la même physique que ce bâtiment. Un centre de données peut toujours prendre feu, inonder, ou perdre l'alimentation, quel que soit le logo sur la porte. Ce que les fournisseurs ont construit à la place, c'est une structure qui empêche la mauvaise journée d'un site de devenir la mauvaise journée de tout le monde : les régions et les zones de disponibilité.

Régions : où vivent vos ressources

Une région est une zone géographique distincte, par exemple US East (Virginie du Nord) ou Europe (Irlande). Quand vous lancez une machine virtuelle ou créez un bucket de stockage, vous choisissez une région, et ce choix décide quel pays ou quel continent héberge physiquement vos données, et la distance que le trafic réseau doit parcourir pour atteindre vos utilisateurs. AWS opère à lui seul une quarantaine de régions dans le monde, chacune conçue pour être totalement isolée des autres, pour qu'une panne dans une région n'ait aucun moyen d'atteindre les autres.

Les régions existent pour 2 raisons pratiques : la latence et la loi. Un utilisateur à Singapour reçoit des réponses plus rapides depuis une région à Singapour que depuis une région en Virginie, et certaines industries et certains gouvernements exigent que certaines données ne quittent jamais les frontières d'un pays donné. Choisir une région est votre première décision d'infrastructure sur n'importe quelle plateforme cloud, et elle est presque toujours guidée par ces 2 contraintes.

Zones de disponibilité : l'isolation à l'intérieur de la région

Une région seule ne vous protège de rien, c'est juste un emplacement. La protection vient un niveau plus bas, à l'intérieur de la région, où les fournisseurs découpent plusieurs zones de disponibilité. Chaque zone regroupe 1 ou plusieurs centres de données distincts, chacun avec sa propre alimentation, son propre refroidissement et sa propre sécurité physique redondants, hébergés dans un site physiquement séparé des autres zones de la même région. AWS garantit un minimum de 3 zones par région. Les zones restent assez proches les unes des autres, en général à moins de 100 km, pour qu'une liaison fibre dédiée à faible latence et haut débit garde le trafic entre elles rapide.

AWS nomme ses zones d'après leur région : eu-west-3a, eu-west-3b et eu-west-3c sont les 3 zones de la région eu-west-3. Seule cette lettre finale change : tout ce qui précède identifie la région, et la lettre choisit la zone précise.

Exemple chiffré : 1 zone contre 3

Un commerçant fait tourner son service de paiement sur 6 machines virtuelles. Placez les 6 dans une seule zone, et une coupure d'alimentation dans ce centre de données met les 6 hors service au même instant, exactement comme le bâtiment de l'ouverture. Répartissez ces mêmes 6 machines entre 3 zones, 2 par zone, et le tableau change complètement : si 1 zone perd l'alimentation, les 4 machines restantes dans les 2 autres zones continuent de servir les paiements. La zone en panne est hors service, mais le service de paiement, dans son ensemble, ne l'est pas.

Rien n'a changé dans le code entre ces 2 scénarios. La seule différence est l'endroit où vivent physiquement les 6 machines, ce qui est exactement la raison d'être des zones de disponibilité : pas une fonctionnalité que vous codez, mais une décision que vous prenez au moment du déploiement.

Le piège : multi-AZ n'est pas multi-région

Il est tentant de traiter "réparti entre plusieurs zones de disponibilité" et "protégé contre toute panne" comme la même chose. Ce n'est pas le cas. Le multi-AZ vous protège d'une panne locale à 1 site, alimentation, refroidissement, incendie, inondation. Il ne fait rien contre un événement qui touche toute une zone géographique en même temps, une catastrophe naturelle de grande ampleur ou une panne réseau régionale. Survivre à cela demande de tourner dans plus d'1 région, en répliquant données et trafic sur une distance bien plus grande, un engagement plus lourd en coût et en complexité que le multi-AZ. La plupart des applications n'ont besoin que du multi-AZ. Le multi-région sert aux charges où perdre une zone géographique entière, même brièvement, n'est pas acceptable.

Comment les 3 grands fournisseurs se comparent

Le concept est universel, même si le vocabulaire change légèrement d'un fournisseur à l'autre.

Une différence structurelle mérite d'être connue : si une région Azure entière subit une panne, chaque zone de disponibilité à l'intérieur peut être affectée, parce qu'Azure construit une région à partir de ses zones. AWS et Google Cloud conçoivent leurs régions pour rester isolées les unes des autres, pour qu'une panne propre à 1 région ne se propage pas vers une autre région. C'est un détail de conception, qui ne change rien à votre usage quotidien du multi-AZ, mais qui explique pourquoi choisir ses régions est parfois lui-même une décision de disponibilité, pas seulement de latence.

Où cela vous mène

Une région choisit où vivent vos ressources, les zones de disponibilité à l'intérieur sont ce qui vous protège réellement de la mauvaise journée d'un seul centre de données. Déployez sur au moins 2, idéalement 3, zones dès qu'une application doit rester disponible, et réservez le multi-région aux cas où perdre une zone géographique entière est un risque que vous ne pouvez pas accepter. Maintenant que vous savez comment les fournisseurs organisent la carte physique sous le cloud, la prochaine leçon couvre ce que vous louez réellement à l'intérieur de cette carte : le calcul.