Choisir la disponibilité entre zones et régions

Partir de l’opération utilisateur

La haute disponibilité (HA) vise à garder un service utilisable malgré les défaillances de composants. Définissez ce que signifie « utilisable » avant de choisir l’architecture. Une page de réservation qui se charge alors que toutes les réservations échouent n’est pas un service de réservation disponible.

Fixez un objectif de niveau de service (SLO) pour l’opération importante. Définissez quelles requêtes comptent, ce que signifie la réussite et la période de mesure. Le SLA d’un service cloud décrit l’engagement du fournisseur. Il n’établit pas la disponibilité mesurée de votre application.

À titre d’exemple, une disponibilité temporelle de 99,9 % permet 43,2 minutes d’indisponibilité sur un mois de 30 jours. Un SLO fondé sur les requêtes utilise un autre dénominateur. Aucune de ces mesures n’indique la quantité de données que vous pouvez perdre ni ne garantit une durée maximale pour une interruption particulière.

Comprendre les domaines de défaillance

Une zone de disponibilité AWS (AZ) est un emplacement d’infrastructure isolé au sein d’une région. Une région contient plusieurs AZ. Une conception multirégion répartit les composants du workload entre plusieurs régions. Les autres fournisseurs ont leurs propres limites et comportements de service ; examinez le service choisi.

Ce sont des possibilités de conception, pas des garanties de disponibilité. Une étiquette ne prouve pas que chaque composant nécessaire utilise le domaine prévu.

Suivre le parcours complet de la requête

Prenons un service de réservation fictif. Les réplicas web fonctionnent dans deux AZ. Tous deux utilisent une base de données et une passerelle sortante dans l’AZ A. La passerelle est nécessaire pour appeler le prestataire de paiement.

Si l’AZ A tombe en panne, le réplica web de l’AZ B peut rester sain alors que les réservations échouent. L’équipe doit évaluer la base de données, le chemin réseau, le fournisseur d’identité, la dépendance de paiement et le routage. Examinez le mode réel de la base managée : réplication, basculement et comportement des réplicas de lecture varient selon le produit et la configuration.

Vérifiez aussi la capacité. Les ressources restantes doivent traiter la charge requise. Une conception qui prévoit de créer de la capacité pendant un incident dépend des quotas, des ressources disponibles et des opérations du plan de contrôle.

Réalisez un exercice contrôlé avec un périmètre défini, des conditions d’arrêt et un responsable. Vérifiez une réservation complète, y compris le rapprochement du paiement. Consignez les requêtes échouées et le temps nécessaire pour retrouver un fonctionnement utile.

Décider si une autre région résout le problème

L’exploitation multirégion ajoute du transfert de données, des ressources dupliquées, de la coordination des déploiements et du travail d’exploitation. Le mode actif/passif garde un environnement prêt à recevoir du trafic. Le mode actif/actif sert le trafic dans plusieurs environnements. Le niveau de préparation requis et le comportement des données diffèrent.

Pour le service de réservation, les écritures concurrentes posent une question : deux régions peuvent-elles vendre la même place ? Définissez quelle autorité attribue une réservation et le comportement pendant une interruption de réplication. « Répliquer la base » n’est pas une réponse complète.

Vérifiez les emplacements autorisés des données, les clés de chiffrement, les certificats, le DNS, les secrets et les services externes. Une panne d’identité commune ou une mauvaise version peut toucher plusieurs régions. Multiplier les emplacements ne supprime pas toutes les causes communes.

Relier disponibilité et reprise

La HA traite des défaillances définies pendant l’exploitation. La reprise après sinistre restaure un service utilisable et ses données après un événement perturbateur. Un service multirégion a encore besoin d’un plan de reprise en cas de suppression ou de corruption des données.

Documentez les scénarios de défaillance choisis et ceux que le métier accepte. Gardez les tests et les définitions d’infrastructure cohérents lorsque l’application change. Poursuivez avec les RTO, RPO et la reprise après sinistre.