Une disponibilité de 99,9 % sans orchestrateur : la promesse tenue
FrozenSpam atteint un SLA de 99,9 % de disponibilité en s'appuyant sur deux adresses IP hébergées chez OVH, sans aucun cluster Kubernetes. L'architecture repose sur la redondance active-passive, un reverse proxy léger et des scripts de bascule automatisés, suffisants pour encaisser pannes réseau, redémarrages et montées en charge modérées.
Quand on pense haute disponibilité dans le monde du SaaS B2B, l'imaginaire collectif convoque immédiatement Kubernetes, Helm charts, auto-scaling horizontal et un DevOps senior à plein temps. Pourtant, 99,9 % de disponibilité représente environ 8,7 heures d'interruption tolérée par an — un objectif très raisonnable que l'on peut atteindre avec une infrastructure sobre, bien configurée et rigoureusement surveillée.
Cet article détaille comment FrozenSpam y parvient concrètement, pourquoi ce choix architectural est cohérent avec notre modèle SaaS anti-spam par défi-réponse, et ce que vous pouvez en retenir pour vos propres projets.
Pourquoi deux IPs OVH plutôt qu'un cloud hyperscaler ?
OVH est l'hébergeur européen le plus utilisé par les PME et ETI françaises. Choisir OVH, c'est s'inscrire dans l'écosystème de nos clients, bénéficier d'une latence réduite depuis la France et l'Europe, et respecter les exigences de souveraineté des données que nombre de nos clients B2B imposent contractuellement.
Deux serveurs dédiés suffisent pour notre charge actuelle. Le premier est le nœud actif, le second le nœud de secours. Les deux partagent une IP Failover OVH — une adresse IP flottante que l'on peut basculer d'un serveur à l'autre en moins de 60 secondes via l'API OVH, sans intervention manuelle.
L'IP Failover OVH : le pivot de l'architecture
L'IP Failover (ou Additional IP dans la nouvelle nomenclature OVH) est l'élément clé. Elle est annoncée par BGP par OVH et reste stable pour vos clients DNS : pas besoin de modifier un enregistrement A, pas de délai de propagation TTL. Lorsqu'un incident est détecté sur le nœud actif, le script de bascule appelle l'API OVH, transfère l'IP Failover sur le nœud passif, et le trafic reprend en moins d'une minute.
Ce mécanisme simple remplace, pour notre cas d'usage, des dizaines de composants Kubernetes : pas de kube-proxy, pas de controller manager, pas de etcd à maintenir en cluster de trois nœuds minimum.
Pourquoi pas AWS, GCP ou Azure ?
Les hyperscalers offrent des garanties de SLA supérieures (jusqu'à 99,99 % sur certains services managés), mais à un coût et une complexité sans commune mesure. Pour un SaaS anti-spam dont le cœur de métier est le filtrage de courriers indésirables par défi-réponse, un uptime de 99,9 % est largement suffisant. Dépenser 5× plus en infrastructure pour gagner 0,09 % de disponibilité supplémentaire n'est pas une décision rationnelle à notre stade.
L'architecture active-passive expliquée simplement
L'architecture active-passive signifie qu'un seul serveur traite le trafic à un instant T (le nœud actif), tandis que le second reste synchronisé et prêt à prendre le relais (le nœud passif). Ce modèle est moins performant qu'un actif-actif en termes de capacité brute, mais infiniment plus simple à opérer et à déboguer.
- Nœud actif : reçoit toutes les requêtes HTTPS entrantes, fait tourner l'application FrozenSpam et la base de données primaire.
- Nœud passif : réplique la base de données en temps quasi réel via réplication streaming PostgreSQL, exécute les mêmes services en mode veille.
- IP Failover OVH : bascule automatiquement vers le nœud passif si le nœud actif ne répond plus au healthcheck pendant 30 secondes consécutives.
La réplication PostgreSQL en streaming maintient un lag inférieur à 2 secondes en conditions normales. En cas de bascule, la perte de données maximale théorique est donc de 2 secondes — ce que l'on appelle le RPO (Recovery Point Objective). Le RTO (Recovery Time Objective), lui, est inférieur à 90 secondes.
La surveillance et le déclenchement automatique de la bascule
Un système de haute disponibilité n'est fiable que si la détection de panne est elle-même fiable. FrozenSpam utilise un healthcheck applicatif — une route HTTP interne qui valide non seulement que le serveur répond, mais aussi que la base de données est joignable et que la file de traitement des défis est active.
Le script de bascule : 40 lignes qui font le travail
Le cœur du mécanisme de failover est un script Bash de moins de 40 lignes, exécuté par un processus de supervision (Monit) sur le nœud passif. Toutes les 15 secondes, il interroge le nœud actif. Après trois échecs consécutifs, il appelle l'API OVH pour basculer l'IP Failover, promeut le réplica PostgreSQL en primaire, et redémarre les services applicatifs en mode actif.
Pas de Helm, pas de CRD, pas de kubeconfig. Juste des appels API REST et des commandes système standard. Cette sobriété est un choix assumé : moins de code, moins de surface d'attaque, moins de points de défaillance.
Les alertes et la supervision humaine
La bascule automatique est complétée par des alertes PagerDuty vers l'astreinte technique. Même si le système se répare seul, l'équipe est notifiée dans la minute pour investiguer la cause racine et éviter une deuxième panne sur le nœud désormais actif (qui était le nœud passif).
« La vraie haute disponibilité n'est pas une question d'outils sophistiqués, c'est une question de chemins de défaillance bien identifiés et de procédures de bascule testées régulièrement. Chez FrozenSpam, nous simulons une panne complète chaque trimestre. » — L'équipe technique FrozenSpam
Ce que cette architecture ne couvre pas (et pourquoi c'est acceptable)
L'honnêteté intellectuelle impose de mentionner les limites de cette approche. Un scénario de panne simultanée des deux serveurs OVH dans le même datacenter serait problématique. De même, une corruption de données due à un bug applicatif serait répliquée sur le nœud passif avant d'être détectée.
- Panne datacenter complète : probabilité très faible, mais non nulle. OVH dispose de SLA sur son infrastructure physique, et l'incident d'incendie de Strasbourg en 2021 reste dans les mémoires. Nous maintenons une sauvegarde froide quotidienne dans une région OVH distincte.
- Corruption logique des données : couverte par des sauvegardes PostgreSQL PITR (Point-In-Time Recovery) conservées 14 jours.
- Scalabilité horizontale : notre architecture ne scale pas automatiquement face à un pic de trafic × 10. Mais notre modèle de charge est prévisible et les pics sont gérés par du capacity planning trimestriel.
Ces limites sont documentées dans notre politique de continuité d'activité et communiquées aux clients entreprise qui en font la demande.
Comparatif : architecture FrozenSpam vs stack Kubernetes typique
| Critère | FrozenSpam (2 IPs OVH) | Stack Kubernetes typique |
|---|---|---|
| SLA cible | 99,9 % | 99,95 % à 99,99 % |
| Coût infrastructure mensuel | Faible (2 serveurs dédiés) | Élevé (3+ nœuds + services managés) |
| Complexité opérationnelle | Faible | Élevée |
| Temps de bascule (RTO) | < 90 secondes | < 30 secondes (si bien configuré) |
| Perte de données max (RPO) | ~2 secondes | Quasi nul (avec PVC répliqués) |
| Compétences requises | Linux, PostgreSQL, API REST | DevOps senior, certifications K8s |
| Surface d'attaque | Réduite | Large (CVE K8s, misconfiguration RBAC) |
Ce tableau illustre un point fondamental : Kubernetes est une réponse à des problèmes de scale et de déploiement continu que FrozenSpam n'a pas encore — et peut-être n'aura jamais — à résoudre à ce niveau de complexité.
Les bonnes pratiques que nous appliquons au quotidien
La disponibilité n'est pas un état, c'est une pratique continue. Voici ce qui structure notre routine opérationnelle :
- Tests de bascule trimestriels : nous déclenchons volontairement un failover en dehors des heures de bureau pour valider que le script fonctionne toujours et que l'équipe sait réagir.
- Mises à jour sans interruption : les déploiements applicatifs utilisent une séquence — mise à jour du nœud passif, bascule, mise à jour de l'ancien actif — pour éviter tout downtime visible.
- Monitoring externe : un service de monitoring tiers (hors infrastructure OVH) effectue des checks HTTP toutes les 60 secondes depuis plusieurs points de présence en Europe. C'est lui qui calcule notre uptime réel et alimente notre page de statut publique.
Conclusion : la sobriété technique est une stratégie, pas une contrainte
FrozenSpam tient son SLA de 99,9 % avec deux serveurs OVH, une IP Failover, PostgreSQL en streaming replication et un script de bascule minimaliste. Cette architecture volontairement sobre réduit les coûts, limite la surface d'attaque, et reste opérable par une équipe de taille raisonnable — sans sacrifier la fiabilité que nos clients B2B sont en droit d'attendre.
Kubernetes est un outil puissant, mais un outil doit répondre à un besoin réel. Notre besoin actuel est de délivrer un service anti-spam par défi-réponse stable, sécurisé et souverain. Deux IPs OVH bien configurées y répondent parfaitement.
Vous souhaitez tester FrozenSpam dans votre propre infrastructure ? Lancez votre pilote gratuit sur /pilote ou consultez nos formules sur /tarifs pour trouver l'offre adaptée à la taille de votre organisation.