Chapitre 15.5 — Haute disponibilité

⏱️ TL;DR — La haute disponibilité (HA), c’est viser un service qui reste en ligne même quand quelque chose casse. Le point de départ : traquer les SPOF (single points of failure, les points uniques de défaillance) et les réduire par la redondance — plusieurs instances, plusieurs zones, un load balancer qui fait des health checks et bascule (failover) sur les serveurs sains, une base répliquée (primaire/réplica). Mais tout ça a un coût et une complexité réels. La vérité honnête de ce chapitre : la plupart des projets n’ont pas besoin de vraie HA. Un bon backup + une restauration testée et rapide couvrent l’immense majorité des cas, bien moins cher. On mesure la disponibilité en « neuf » (99,9 %, 99,99 %…), on connaît les limites du VPS unique, et on sait quand passer au managé/cloud — mais on ne sur-ingénierie pas.

🎯 Objectifs

Identifier les SPOF d’une architecture et savoir comment les réduire.
Comprendre la redondance, les health checks et le failover d’un load balancer.
Saisir le principe de la réplication de base (primaire/réplica) — en survol.
Peser le compromis coût/complexité de la HA, et reconnaître quand elle est inutile.
Connaître les limites du VPS unique et quand envisager du managé/cloud.
Lire la disponibilité en « neuf » et fixer un objectif réaliste.

SPOF : les points uniques de défaillance

Un SPOF (Single Point Of Failure) est un composant dont la panne suffit à tout arrêter. Sur un VPS unique classique, il y en a partout, empilés sur la même machine :

La machine elle-même (une seule : elle tombe, tout tombe).
Le disque (un seul : il meurt, données et service partent).
L’app, la base, Nginx (un seul de chaque : l’un plante, la chaîne casse).
Le datacenter, le fournisseur (un incident régional t’emporte).

Viser la HA, c’est identifier ces SPOF et les doubler — remplacer « un seul » par « plusieurs, dont au moins un survit ». C’est la définition même de la redondance.

💡 Réflexe — Pour cartographier tes SPOF, pose-toi pour chaque composant : « si celui-ci tombe maintenant, le service continue-t-il ? ». Chaque « non » est un SPOF. Cet exercice, fait honnêtement, révèle vite que le VPS unique est un gros SPOF global — et te dit où la redondance apporterait le plus, si tu décides d’en faire.

Redondance, health checks et failover

La redondance répond au SPOF : mets plusieurs instances de ce qui peut tomber, sur plusieurs zones (datacenters/régions différents, pour survivre à une panne localisée). Mais la redondance seule ne suffit pas — il faut détecter la panne et rediriger le trafic. C’est le rôle du load balancer :

Health checks : le load balancer interroge en boucle chaque serveur (« es-tu vivant et sain ? », souvent une URL de santé qui répond OK). Un serveur qui ne répond plus est marqué hors-service.
Failover (bascule) : le load balancer cesse d’envoyer du trafic au serveur défaillant et le répartit sur les serveurs sains restants. Pour l’utilisateur, le service continue — la panne d’une instance est invisible.

C’est la mécanique de base de la HA : redondance (plusieurs serveurs) + détection (health checks) + bascule (failover). Tant que au moins un serveur sain répond, le service tient.

🔒 Sécurité — La redondance sert aussi la sécurité et la maintenance : avec plusieurs instances, tu peux mettre à jour ou patcher un serveur (le retirer du load balancer, le mettre à jour, le remettre) sans coupure de service. Un VPS unique impose une fenêtre de maintenance visible ; une architecture redondante permet des mises à jour sans downtime — un vrai bénéfice au-delà de la seule résistance aux pannes.

La réplication de base (survol)

La base de données est souvent le SPOF le plus délicat à rendre redondant, parce qu’elle a un état. La technique : la réplication primaire/réplica. Un serveur primaire accepte les écritures ; il réplique en continu ses changements vers un ou plusieurs réplicas qui en gardent une copie à jour. Si le primaire tombe, on promeut un réplica au rang de primaire (failover de base), et le service repart.

Deux nuances importantes, déjà vues au chapitre 15.1 :

La réplication protège de la panne matérielle d’un serveur de base, pas de l’erreur humaine ni de la corruption (qui se répliquent aussitôt). Ce n’est pas une sauvegarde — il faut en plus des backups datés.
La mettre en place et gérer le failover proprement (sans split-brain, sans perte de données) est non trivial. C’est souvent l’argument décisif pour prendre une base managée (voir plus bas), qui gère la réplication et la bascule pour toi.

📚 La doc — La réplication PostgreSQL (streaming, réplicas en lecture seule, pg_basebackup, bascule) est un sujet à part entière, documenté dans le manuel officiel PostgreSQL, section réplication. On la cite ici comme brique de HA ; sa mise en œuvre correcte se fait avec la doc versionnée sous les yeux, jamais de mémoire.

Le compromis coût/complexité

Voici le message que ce chapitre veut vraiment faire passer : la vraie HA coûte cher — en argent et en complexité — et la plupart des projets n’en ont pas besoin. Chaque « neuf » supplémentaire de disponibilité multiplie :

le coût : serveurs redondants (tu paies 2 à 3 fois l’infrastructure), load balancer, base répliquée ou managée, multi-zone ;
la complexité : plus de pièces à opérer, l’état partagé à gérer (15.4), le failover à tester, plus de surface de bug et d’attaque.

Face à ça, une alternative beaucoup moins chère couvre l’immense majorité des besoins réels : un bon backup + une restauration testée et rapide (15.3). Oui, un incident sur un VPS unique coupe le service — mais si tu peux remonter en 1 h depuis une sauvegarde saine, quelques heures d’indisponibilité par an, très rares, sont parfaitement acceptables pour la plupart des sites. Tu obtiens 99,9 % de dispo sans le coût de la HA.

⚠️ Piège — La sur-ingénierie de la HA. Monter un cluster multi-zone avec load balancer, réplicas et failover automatique pour un site qui reçoit quelques milliers de visites par jour, c’est brûler du budget et du temps pour un problème que tu n’as pas. Pire, la complexité ajoutée devient elle-même une source de pannes (une bascule mal réglée casse plus souvent que le serveur qu’elle protège). Ne construis de la HA que si le coût d’une indisponibilité le justifie vraiment.

💡 Réflexe — Chiffre le coût réel d’une heure d’indisponibilité pour ton projet, puis compare-le au coût mensuel de la HA. Pour un side-project, un blog, un SaaS naissant, le calcul penche presque toujours vers « backup + restauration rapide », pas vers la HA. La HA se justifie quand une coupure coûte très cher (paiements, service critique, SLA contractuel) — pas par principe ni par imitation.

Mesurer la disponibilité : les « neuf »

La disponibilité se mesure en pourcentage de temps en ligne sur une période, exprimé familièrement en « neuf ». Plus il y a de neuf, moins il y a d’indisponibilité tolérée — et plus c’est cher :

Disponibilité	Surnom	Indispo max / an	Réaliste avec…
99 %	« deux neuf »	~3,65 jours	Un VPS unique sans effort particulier
99,9 %	« trois neuf »	~8,8 heures	VPS unique + backup et restauration rapide
99,99 %	« quatre neuf »	~52 minutes	Redondance, load balancer, failover (vraie HA)
99,999 %	« cinq neuf »	~5 minutes	Multi-zone, tout redondé, très coûteux

L’enseignement du tableau : passer de « trois neuf » à « quatre neuf » fait basculer d’un VPS unique bien sauvegardé à une vraie architecture HA — un saut de coût et de complexité énorme pour grappiller quelques heures par an. Fixe ton objectif à ce dont tes utilisateurs ont réellement besoin, pas au maximum théorique.

💡 Réflexe — Vise 99,9 % par défaut, et atteins-le par la restauration rapide plutôt que par la HA. C’est le point d’équilibre pour l’écrasante majorité des projets : robuste, honnête, abordable. Ne cours après un neuf de plus que si un besoin métier chiffré l’exige.

Les limites du VPS unique, et quand passer au managé

Le VPS unique — le cœur de ce cours — a des limites assumées : c’est un SPOF, sa maintenance impose une coupure, et sa mise en HA demande un vrai travail d’ops. À un certain palier, il devient plus rentable (en temps d’équipe) de déléguer certaines briques à des services managés :

Base de données managée (Postgres managé chez un fournisseur) : réplication, sauvegardes, bascule et mises à jour gérées pour toi. Souvent le premier composant à externaliser, car le plus délicat à rendre HA soi-même.
Load balancer managé, stockage objet, cache managé : des briques HA « clé en main ».
Plateformes managées / cloud : quand l’échelle et les exigences dépassent ce qu’une petite équipe veut opérer, un cloud gère l’élasticité et la redondance — au prix d’un coût plus élevé et d’une dépendance au fournisseur (le compromis inverse de celui qui t’a fait choisir un VPS au départ).

Le VPS reste excellent et suffisant très longtemps. Passer au managé n’est pas un aveu d’échec : c’est un arbitrage — tu échanges de l’argent contre du temps d’ops et de la tranquillité, quand ce temps devient plus précieux que l’économie du VPS.

🧭 Sur FormaCampus — L’équipe a fait le calcul honnêtement. FormaCampus n’a pas de contrat qui impose 99,99 % : une coupure rare de deux heures, la nuit, est tolérable. Elle a donc choisi de ne pas faire de vraie HA — pas de cluster, pas de failover automatique. Son objectif est 99,9 %, atteint par le trio des chapitres précédents : sauvegardes restic chiffrées hors-site, runbook de reprise testé chaque mois, RTO mesuré sous 4 h. Le budget économisé sur la HA finance ce qui compte vraiment pour ses apprenants : le CDN devant les vidéos et de la marge sur le VPS. Une exception envisagée pour plus tard : externaliser PostgreSQL vers une base managée le jour où la base deviendra le SPOF le plus risqué — parce que la réplication et le failover de base sont précisément ce qu’on délègue le mieux. Résilience pragmatique, pas résilience par principe.

Conclusion : résiste, ne sur-ingénierie pas

Toute cette partie tient dans une posture d’ingénieur mûr. Sauvegarde sérieusement (3-2-1, chiffré, hors-site). Teste tes restaurations — religieusement. Optimise avant de scaler, scale vertical avant horizontal. Et pour la disponibilité, sois honnête : la vraie HA est un outil cher et complexe qui résout un problème que la plupart des projets n’ont pas. Un VPS unique, bien sauvegardé et vite restaurable, offre une résilience excellente pour un coût minime. Construis la robustesse dont ton projet a besoin — mesurée, chiffrée, testée — et pas un neuf de plus. C’est ça, opérer en professionnel.

✏️ Exercices

Exercice 1 — Chasse aux SPOF. Décris les SPOF d’une architecture « tout sur un seul VPS » (Nginx + app + Postgres + uploads sur le disque local). Puis dis, pour chacun, ce que la redondance changerait — et si le jeu en vaut la chandelle pour un petit site.

✅ Solution

SPOF : la machine (une seule → tout tombe si elle plante), le disque (un seul → perte de données et de service), et chaque service empilé (Nginx, app, Postgres : l’un plante, la chaîne casse), plus le datacenter/fournisseur (incident régional). Tout est empilé sur une seule machine = un gros SPOF global. Ce que la redondance changerait : plusieurs serveurs web derrière un load balancer (une instance tombe, les autres tiennent), une base répliquée (bascule sur un réplica), du multi-zone (survivre à une panne de datacenter). Le jeu en vaut-il la chandelle pour un petit site ? Généralement non : le coût et la complexité de tout redonder dépassent de loin le bénéfice. Pour un petit site, la bonne réponse est backup 3-2-1 + restauration testée et rapide (viser ~99,9 %), pas la HA. On ne dédie à la redondance que les SPOF dont la panne coûte vraiment cher.

Exercice 2 — HA ou pas HA ? Pour chaque projet, dis s’il faut viser la vraie HA ou se contenter de « backup + restauration rapide », et justifie : (A) une plateforme de paiement avec un SLA contractuel à 99,99 % ; (B) le blog technique d’une PME, quelques milliers de vues/jour.

✅ Solution

(A) → vraie HA. Un SLA contractuel à 99,99 % (≈ 52 min d’indispo/an max) et des paiements (une coupure coûte de l’argent et casse la confiance) imposent la redondance : plusieurs serveurs, load balancer avec failover, base répliquée/managée, multi-zone. Ici le coût de la HA est justifié par le coût d’une indisponibilité.

(B) → backup + restauration rapide. Quelques milliers de vues/jour, pas de SLA, pas de transaction critique : une coupure rare de quelques heures est tolérable. Viser 99,9 % via des sauvegardes 3-2-1 et un runbook testé (RTO de ~1–2 h) suffit largement, pour une fraction du coût. Monter une HA ici serait de la sur-ingénierie — budget et complexité gaspillés.

Exercice 3 — Traduis les neuf. Un client demande « 99,99 % de disponibilité ». Traduis en indisponibilité annuelle tolérée, dis quel type d’architecture c’est, et quelle question tu lui poses avant de t’engager.

✅ Solution

99,99 % (« quatre neuf ») ≈ 52 minutes d’indisponibilité par an maximum. C’est le seuil de la vraie HA : il faut de la redondance (plusieurs serveurs), un load balancer avec health checks et failover, une base répliquée ou managée, idéalement du multi-zone — donc un coût et une complexité nettement supérieurs à un VPS unique. La question à poser avant de s’engager : « quel est le coût réel d’une heure d’indisponibilité pour vous, et êtes-vous prêts à payer 2 à 3 fois l’infrastructure (plus l’exploitation) pour ce niveau ? ». Souvent, le client réalise que 99,9 % (VPS bien sauvegardé, ~9 h/an, bien moins cher) couvre son besoin réel, et que « quatre neuf » relevait du réflexe, pas d’une exigence chiffrée.

🧠 Quiz de révision

1. Qu’est-ce qu’un SPOF, et comment le réduit-on ?

Un SPOF (single point of failure) est un composant dont la panne suffit à arrêter tout le service (la machine, le disque, la base, sur un VPS unique). On le réduit par la redondance : mettre plusieurs instances de ce qui peut tomber, sur plusieurs zones, avec un load balancer qui détecte la panne (health checks) et bascule (failover) sur les instances saines.

2. Que sont les health checks et le failover d’un load balancer ?

Les health checks sont les vérifications régulières par lesquelles le load balancer teste si chaque serveur est vivant et sain (souvent une URL de santé). Le failover est la bascule : quand un serveur est déclaré défaillant, le load balancer cesse de lui envoyer du trafic et le répartit sur les serveurs sains restants — la panne d’une instance devient invisible pour l’utilisateur, tant qu’au moins un serveur sain répond.

3. Pourquoi la réplication de base n’est-elle pas une sauvegarde ?

Parce qu’elle copie les changements en continu vers le réplica : une erreur humaine ou une corruption (un DELETE malheureux, une migration ratée) se réplique aussitôt et détruit les données des deux côtés. La réplication protège de la panne matérielle d’un serveur de base (on promeut un réplica), pas de l’erreur ni de la corruption. Il faut en plus des sauvegardes datées et indépendantes.

4. Pour la plupart des projets, quelle alternative à la vraie HA est recommandée, et pourquoi ?

Un bon backup + une restauration testée et rapide (viser ~99,9 %). Parce que la vraie HA est chère (2 à 3 fois l’infrastructure, load balancer, base répliquée) et complexe (plus de pièces, failover à tester, la complexité devenant elle-même source de pannes), alors que la plupart des projets tolèrent quelques heures d’indisponibilité rare. Si on remonte en ~1 h depuis une sauvegarde saine, on obtient une résilience excellente à coût minime. On ne construit de la HA que si le coût d’une indisponibilité le justifie vraiment.

5. Que signifient les « neuf » et quel objectif viser par défaut ?

Les « neuf » désignent le pourcentage de disponibilité : 99 % (« deux neuf », ~3,65 j d’indispo/an), 99,9 % (« trois neuf », ~8,8 h/an), 99,99 % (« quatre neuf », ~52 min/an), etc. Chaque neuf supplémentaire coûte beaucoup plus cher. L’objectif par défaut raisonnable est 99,9 %, atteint par la restauration rapide (VPS unique bien sauvegardé) plutôt que par la HA — le meilleur compromis robustesse/coût pour l’immense majorité des projets.

Fin de la Partie 15. Ta prod résiste maintenant aux sinistres et sait grandir. La Partie 16 — Cookbook & Annexes rassemble les runbooks, aide-mémoire et procédures prêts à dégainer le jour où ça compte.