Guide

Basculement multi-région avec un maillage WireGuard

AvancéLecture de 40 minMis à jour 8 juillet 2026
Réponse courte

Trois instances dans trois pays, maillées via WireGuard, avec l'application liée uniquement au maillage et un enregistrement DNS vérifié par santé devant, offre une véritable tolérance aux pannes pour moins de 110 $ par mois. La contrainte de conception est la réplication de base de données : synchrone dans une région, asynchrone entre elles.

01 Choisissez trois domaines de défaillance indépendants

Different countries, ideally different transit mixes. Amsterdam, Ashburn and Singapore is the classic triangle. Three is the minimum for quorum — two gives you a split-brain problem rather than redundancy.

02 Construire le maillage

Each node gets a stable private address. Every node peers with every other node; with three nodes that is three tunnels.

# node A — /etc/wireguard/mesh.conf
[Interface]
Address = 10.10.0.1/24
ListenPort = 51821
PrivateKey = <A private>

[Peer]                       # node B
PublicKey = <B public>
Endpoint = b.example.net:51821
AllowedIPs = 10.10.0.2/32
PersistentKeepalive = 25

[Peer]                       # node C
PublicKey = <C public>
Endpoint = c.example.net:51821
AllowedIPs = 10.10.0.3/32
PersistentKeepalive = 25

03 Lier les services uniquement au maillage

The database, the cache and the internal API should listen on 10.10.0.x, never on the public address. This removes an entire class of exposure without a single firewall rule.

04 Répliquez la base de données de manière appropriée

Synchronous replication across regions is impractical — a 160 ms round trip becomes the floor for every write. Use asynchronous replication across regions and know your recovery point objective.

05 Vérifiez la santé au niveau du DNS

Short TTLs plus health-checked failover records, or anycast if your regions support it. Then run a failure drill: kill a region deliberately, on a weekday, while you are watching.

Questions fréquemment posées

Pourquoi ne pas simplement acheter un serveur plus puissant ?

Un serveur plus puissant a le même nombre de domaines de défaillance qu'un petit : un. La disponibilité vient de l'indépendance, pas de la capacité.

À quelle distance peuvent se trouver les répliques synchrones etcd ou Postgres ?

Gardez les répliques synchrones à moins de 100 ms l'une de l'autre. Au-delà, la latence d'écriture devient le coût dominant de chaque transaction.