Diagramme d'architecture de reprise après sinistre : RPO, RTO et quatre stratégies

La haute disponibilité maintient un système en marche quand un serveur ou une zone de disponibilité tombe. La reprise après sinistre concerne les pannes plus graves : une région entière hors service, une base de données corrompue, un compte supprimé, un rançongiciel. Le plan pour ces cas doit exister avant qu'ils n'arrivent, et c'est l'architecture qui décide combien de données vous perdez et combien de temps vous restez hors service.

Cet article définit les deux chiffres dont part toute conception de reprise après sinistre (DR), passe en revue les quatre stratégies classiques avec leurs coûts et dessine un warm standby sur deux régions.

RPO et RTO

• Objectif de point de reprise (RPO) : la quantité de données que vous pouvez vous permettre de perdre, mesurée en temps. Un RPO de 5 minutes signifie que perdre les 5 dernières minutes d'écritures est acceptable.
• Objectif de temps de reprise (RTO) : combien de temps le service peut rester indisponible avant d'être rétabli.

Les deux viennent du métier, pas de l'ingénierie, et les deux coûtent de l'argent : chaque pas vers zéro perte de données et zéro interruption multiplie l'infrastructure et le travail d'exploitation. Demandez combien coûte une heure d'interruption et quelles données ne peuvent pas être recréées, puis choisissez la conception la moins chère qui respecte ces chiffres. Les différentes parties d'un même système ont souvent des objectifs différents : le paiement peut exiger quelques minutes, l'entrepôt de données de reporting une journée.

Quatre stratégies

Le livre blanc d'AWS sur la reprise après sinistre regroupe la DR en quatre stratégies, classées par coût et par vitesse de reprise. Les mêmes idées s'appliquent sur n'importe quel cloud ou dans vos propres datacenters.

Backup and restore reconstruit tout à partir des sauvegardes et du code d'infrastructure. C'est suffisant pour beaucoup de systèmes internes, à condition que la restauration ait été testée et que l'infrastructure puisse être recréée à partir du code.

Pilot light garde les données vivantes (bases répliquées, buckets répliqués) mais laisse le calcul éteint ou à zéro. Reprendre signifie démarrer les services et les mettre à l'échelle.

Warm standby fait tourner une copie réduite mais fonctionnelle. Elle peut servir du trafic immédiatement à capacité réduite, puis monter en charge pendant la bascule. Comme elle tourne en permanence, elle est aussi facile à tester.

Actif/actif sert les utilisateurs depuis les deux sites en permanence. La bascule se résume surtout à un changement de routage, mais les écritures dans deux régions imposent une gestion des conflits ou une conception à écrivain unique, et le coût est celui de deux environnements de production.

Choisir pour un système : un exemple

Une boutique en ligne qui reçoit 2 000 commandes par heure demande pour le paiement un RPO de 5 minutes et un RTO de 30 minutes. Backup and restore ne tient pas le RPO : des snapshots nocturnes peuvent faire perdre une journée de commandes, et reconstruire la pile prend des heures. Pilot light tient le RPO grâce à la réplication de la base, mais démarrer et préchauffer les services, les caches et l'index de recherche dans une autre région prend en général plus de 30 minutes la première fois que quelqu'un s'y essaie. Warm standby tient les deux : la réplique a quelques secondes de retard et les services réduits tournent déjà, donc la bascule se résume à une promotion, une montée en charge et un changement DNS. L'actif/actif réduirait encore le RTO mais doublerait le coût et ajouterait des conflits d'écriture que la boutique n'a aucun besoin de résoudre. La réponse : warm standby pour le paiement, backup and restore pour l'entrepôt de données de reporting.

Les sauvegardes restent indispensables

La réplication copie aussi les erreurs. Si quelqu'un supprime une table ou qu'un rançongiciel chiffre les données, la réplique suit en quelques secondes. Gardez des sauvegardes à un instant donné (point-in-time) que la réplication ne peut pas atteindre :

• Des snapshots et des journaux de transactions conservés des jours ou des semaines.
• Des copies dans un compte séparé, avec d'autres identifiants, pour qu'un seul compte compromis ne puisse pas tout supprimer.
• Des sauvegardes immuables ou verrouillées si votre plateforme le permet.
• Des tests de restauration réguliers. Une sauvegarde que personne n'a jamais restaurée est un espoir, pas une sauvegarde.

La séquence de bascule

Écrivez les étapes et gardez-les courtes :

1. Décider. Qui peut déclarer un sinistre, et sur quel signal. Une bascule automatique pour toute une région est risquée ; beaucoup d'équipes automatisent la détection et gardent une décision humaine.
2. Promouvoir la réplique de la base de la région de secours en base principale.
3. Monter en charge le calcul dans la région de secours jusqu'à pleine capacité.
4. Déplacer le trafic en basculant les enregistrements DNS de failover ou les poids du load balancer global. Tenez compte des TTL DNS et des clients qui mettent en cache.
5. Vérifier avec des contrôles synthétiques, puis annoncer.
6. Prévoir le retour. Revenir sur le site d'origine est une seconde migration et demande le même soin.

Le diagramme d'architecture

Comment le lire :

• En haut : les utilisateurs atteignent le routage DNS avec failover. Aujourd'hui, il envoie tout le trafic vers la région principale ; l'arête en pointillé montre où va le trafic après une bascule.
• À gauche, la région principale : un load balancer, six instances applicatives, du stockage objet et la base principale.
• À droite, la région de secours : la même forme en plus petit : deux instances applicatives, une réplique alimentée par réplication asynchrone et des objets répliqués. Les arêtes en pointillé marquent les chemins qui ne portent du trafic qu'après une bascule.
• En bas : des snapshots quotidiens partent vers un coffre de sauvegarde dans un autre compte, la protection contre la corruption et la suppression que la réplication ne peut pas offrir.
• Le bloc Markdown indique les objectifs que la conception doit tenir.

Tester

Les plans de reprise échouent sur des détails : un certificat expiré dans la région de secours, un endpoint codé en dur, un secret manquant, un TTL DNS d'une journée. Le seul remède est d'exécuter la bascule. Planifiez des exercices, commencez par un seul service et mesurez le RTO réel par rapport à l'objectif. Un warm standby rend cela peu coûteux, et c'est l'un de ses plus grands avantages sur le pilot light.

Ce qu'il faut mettre sur un diagramme de reprise après sinistre

• Les deux sites, avec ce qui tourne dans chacun et à quelle échelle.
• Les chemins de réplication et leur mode, synchrone ou asynchrone, car c'est ce qui fixe le RPO.
• L'aiguillage du trafic, et s'il est automatique.
• Des sauvegardes hors du rayon d'impact, y compris la frontière de compte.
• Les objectifs, écrits à côté de la conception.

Pour la partie réseau multirégion, voir le diagramme d'architecture AWS multirégion. Le diagramme de réplication de base de données explique plus en détail le retard de réplication et la bascule, et le logigramme de réponse aux incidents couvre la déclaration et la conduite de l'incident lui-même.

Le construire dans Archboard

1. Connectez-vous avec Google ou GitHub et créez un diagramme.
2. Ajoutez deux cadres Région du pack Cloud, un pour la région principale et un pour la région de secours.
3. Dans chacun, ajoutez un Répartiteur de charge cloud, un nœud Instance de calcul pour l'application, un nœud Stockage objet et une Base de données gérée. Indiquez le nombre d'instances dans les libellés.
4. Ajoutez une Personne du pack Modèle C4 et un nœud DNS du pack Réseau au-dessus des régions, et un autre nœud Stockage objet en dessous pour le coffre de sauvegarde.
5. Dessinez la réplication entre les régions, mettez en pointillé les chemins réservés à la bascule et ajoutez un bloc Markdown du pack Base avec le RPO et le RTO.

L'exemple utilise 14 nœuds de diagramme et reste dans les limites de l'offre Free.

FAQ

Quelle est la différence entre RPO et RTO ? Le RPO est la quantité de données que vous pouvez perdre, mesurée en temps avant la panne. Le RTO est le temps nécessaire pour être de nouveau en service après.

La haute disponibilité, est-ce la même chose que la reprise après sinistre ? Non. La haute disponibilité gère automatiquement et en continu les pannes de composants et de zones. La reprise après sinistre traite des événements plus graves, comme la panne d'une région ou la corruption de données, souvent par une bascule délibérée.

Ai-je encore besoin de sauvegardes si je réplique vers une autre région ? Oui. La réplication copie les suppressions et la corruption presque immédiatement. Des sauvegardes dans un compte séparé protègent contre cela.

Quelle stratégie de reprise après sinistre choisir ? La moins chère qui respecte le RPO et le RTO dont le métier a besoin pour ce système. Le warm standby est un compromis courant, car il est abordable et facile à tester.

À quelle fréquence tester la reprise après sinistre ? Assez souvent pour que le runbook reste juste, souvent chaque trimestre pour les systèmes critiques, et après tout changement important d'architecture.

Commencez gratuitement — un siège, sans carte bancaire.