Deux serveurs ne constituent pas nécessairement deux infrastructures. S’ils dépendent du même datacenter, du même fournisseur cloud, de la même image système, du même client blockchain et du même réseau d’administration, une seule panne peut les rendre indisponibles simultanément.
La diversification utile ne consiste donc pas à compter le nombre de machines. Elle consiste à réduire les causes de défaillance communes.
Commencer par identifier les domaines de défaillance
Une infrastructure Web3 dépend de plusieurs couches :
- matériel ou hyperviseur ;
- datacenter et alimentation ;
- fournisseur cloud ;
- région géographique ;
- réseau et transit ;
- DNS ;
- système d’exploitation ;
- client blockchain ;
- stockage ;
- monitoring ;
- accès administrateur ;
- dépôt ou source des binaires.
La redondance doit être pensée par rapport au scénario que l’on souhaite absorber.
Deux VM dans deux zones d’une même région peuvent protéger contre la perte d’un hôte physique, mais pas nécessairement contre une panne régionale, un problème de compte cloud ou une erreur de configuration déployée partout.
Multi-région n’est pas la même chose que multi-provider
Une seconde région chez le même fournisseur réduit certains risques physiques et réseau. Elle conserve cependant une dépendance au même fournisseur, au même compte, au même plan de contrôle et souvent aux mêmes outils d’automatisation.
Ajouter un second provider réduit davantage la corrélation, mais augmente la complexité : réseaux différents, images différentes, facturation, IAM, observabilité et procédures d’exploitation.
Il n’existe donc pas une réponse universelle « multi-cloud = mieux ». La diversification doit protéger un risque identifié sans rendre l’infrastructure impossible à maintenir.
Diversifier les clients blockchain peut réduire un risque logiciel
Sur certains réseaux, plusieurs implémentations du client existent.
Si toute l’infrastructure dépend du même client et de la même version, une vulnérabilité ou un bug de consensus peut affecter toutes les instances simultanément. La diversité de clients peut réduire ce risque systémique lorsque le protocole et les pratiques du réseau la permettent.
Cette diversité impose cependant davantage de compétences, de tests et de monitoring. Deux clients n’exposent pas forcément les mêmes métriques, fichiers ou procédures d’upgrade.
La diversification logicielle doit donc être volontaire, pas accidentelle.
Les RPC sont aussi un domaine de dépendance
Une application Web3 peut fonctionner avec plusieurs nodes tout en dépendant d’un seul fournisseur RPC pour lire l’état de la chaîne.
Une panne ou une donnée retardée peut alors provoquer des erreurs applicatives, des transactions construites à partir d’un état obsolète ou une impossibilité de confirmer ce qui se passe réellement sur le réseau.
Pour les fonctions critiques, il peut être utile de disposer de plusieurs références : node interne, fournisseur externe secondaire ou endpoint public de contrôle.
Le but n’est pas d’envoyer chaque requête à trois fournisseurs. Il est de pouvoir détecter et contourner une dépendance défaillante.
Le monitoring doit être partiellement indépendant de ce qu’il surveille
Un monitoring hébergé sur la même machine ou le même cluster que le service principal peut disparaître exactement au moment où il devient nécessaire.
Une partie de l’observabilité doit donc se trouver en dehors du domaine surveillé : sonde externe, alerte indépendante, référence réseau externe ou canal de notification séparé.
Cela permet de distinguer « le node est tombé » de « tout notre système de monitoring a disparu ».
Attention à l’active-active pour les validateurs
Pour un service web, deux instances actives peuvent améliorer la disponibilité. Pour un validateur, cette logique peut devenir dangereuse.
Sur les réseaux qui sanctionnent les signatures contradictoires, deux machines actives partageant la même clé de consensus peuvent produire un comportement slashable.
La diversification du compute doit donc être séparée de la duplication du droit de signer.
Une architecture de secours peut utiliser un standby, un signer distant, un mécanisme d’exclusion explicite ou une procédure de bascule contrôlée. Le principe est simple : plusieurs chemins de reprise, une seule autorité de signature active.
Diversifier les sauvegardes sans multiplier les copies incontrôlées
La même logique s’applique aux sauvegardes.
Une copie locale protège contre certaines erreurs logiques mais pas contre la perte du serveur. Une copie dans le même compte cloud reste exposée à une erreur de permissions ou à une suppression globale. Une copie indépendante peut renforcer la continuité.
Mais chaque copie augmente aussi la surface d’accès. Pour les éléments sensibles, notamment les clés, l’objectif n’est pas de multiplier les fichiers : il est de définir une stratégie de récupération contrôlée et testée.
Les dépendances humaines sont également corrélées
Une infrastructure peut être techniquement répartie et rester dépendante d’une seule personne.
Si une seule personne détient les accès administrateur, connaît la procédure de failover et comprend le signer, son indisponibilité devient un point de défaillance.
La documentation, la séparation des rôles et les exercices de reprise font donc partie de la diversification autant que les fournisseurs cloud.
Mesurer la diversification par les scénarios qu’elle absorbe
Une architecture résiliente doit pouvoir répondre à des questions concrètes :
- que se passe-t-il si une VM disparaît ?
- si une région entière tombe ?
- si le provider bloque le compte ?
- si le client blockchain contient un bug critique ?
- si le DNS devient indisponible ?
- si le monitoring principal tombe ?
- si l’administrateur principal est absent ?
Une « redondance » qui ne change la réponse à aucun de ces scénarios ajoute surtout du coût.
Diversifier sans perdre la maîtrise
La résilience n’est pas le nombre de fournisseurs affichés dans un diagramme. C’est la capacité du service à continuer ou à être restauré lorsqu’une dépendance précise disparaît.
Snow-Fall conçoit et exploite des infrastructures de nodes et validateurs dans une approche non-custodial. Selon les contraintes du réseau et du projet, l’architecture peut intégrer plusieurs domaines de reprise sans dupliquer dangereusement l’autorité de signature.
Pour les projets qui souhaitent définir leur stratégie de dépendances, de fournisseurs, de RPC et de continuité avant le déploiement, GLOV Consulting peut intervenir sur le cadrage de l’architecture.