Infrastructure hybride : allier serveurs dédiés et cloud

Pourquoi le « pure cloud » ne convient pas aux charges de travail très exigeantes

Le modèle de facturation du cloud est un atout lorsque le trafic est imprévisible, mais un inconvénient lorsqu'il est constant. Une application SaaS qui dessert 50 000 utilisateurs par jour n'a pas besoin d'une évolutivité élastique : elle a besoin d'une capacité de base fiable à un coût prévisible. Exécuter cette charge de travail sur une infrastructure cloud implique de payer des tarifs à la demande ou réservés pour des ressources utilisées en continu, heure après heure, jour après jour.

Le calculateur de prix d'AWS montre que les charges de travail soutenues sur des instances réservées EC2 coûtent souvent 3 à 4 fois plus cher que le prix d'un serveur dédié équivalent avec des spécifications comparables. Pour la configuration du serveur dédié Extreme — AMD EPYC 4545P 16 cœurs, 192 Go de RAM DDR5, 2×3,84 To NVMe , il n’est pas évident de trouver une instance cloud avec des spécifications comparables, 500 Go de stockage de sauvegarde, une protection contre les logiciels malveillants et une assistance gérée 24 h/24 et 7 j/7, le tout pour 349,99 $ par mois.

Ce que le cloud fait vraiment mieux : gérer un trafic qui dépasse ton seuil de référence pendant de courtes périodes, stocker à moindre coût les données peu utilisées, et exécuter des charges de travail réparties géographiquement dans des régions où tu ne disposes pas de centres de données.

Le modèle d'architecture hybride

Une configuration hybride bien conçue attribue les types de charges de travail aux types d'infrastructure en fonction de leurs caractéristiques :

Le serveur dédié prend en charge :

• Logique métier et API
• Base de données principale (MySQL, PostgreSQL, Redis)
• Services de session et d'authentification
• Stockage de l'origine des ressources statiques
• Données utilisateur persistantes

Poignées en forme de nuage :

• Capacité de calcul en pics de trafic
• Mode de secours à chaud
• Stockage de sauvegarde à froid (stockage objet compatible S3)
• Redondance géographique des points d'origine du CDN
• Environnements hors production (développement, préproduction, assurance qualité)

Le point essentiel, c'est que la plupart des requêtes d'application sont traitées par le serveur dédié, où le coût par requête est le plus bas. L'infrastructure cloud reste inactive ou peu sollicitée la plupart du temps, ce qui signifie que tu ne paies pas les tarifs de pointe du cloud pour le trafic de base.

Capacité de pointe : aller au-delà du serveur dédié

Lorsque ton serveur dédié atteint ses limites en termes de CPU ou de mémoire lors d'un pic de trafic — qu'il s'agisse du lancement d'un produit, d'un phénomène viral ou d'une promotion programmée —, la capacité de pointe fournie par le cloud permet à l'application de rester réactive sans qu'il soit nécessaire de recourir à une configuration dédiée surdimensionnée en permanence.

La solution utilise un équilibreur de charge (HAProxy ou Nginx, fonctionnant sur un serveur dédié ou sous forme de service cloud) pour acheminer le trafic excédentaire vers des instances cloud qui se lancent à la demande.

Configuration de base de HAProxy pour le routage hybride :

frontend http_front

    bind *:80

    default_backend dedicated_pool

backend dedicated_pool

    balance leastconn

    server dedicated1 192.168.1.10:80 check weight 10

    serveur cloud_burst1 10.0.1.20:80 check weight 1 backup

    serveur cloud_burst2 10.0.1.21:80 check weight 1 backup

frontend http_front

    bind *:80

    default_backend dedicated_pool

backend dedicated_pool

    balance leastconn

    server dedicated1 192.168.1.10:80 check weight 10

    server cloud_burst1 10.0.1.20:80 check weight 1 backup

    server cloud_burst2 10.0.1.21:80 check weight 1 backup

La directive de secours maintient les serveurs cloud en veille jusqu'à ce que le serveur dédié principal soit inaccessible ou surchargé. La documentation d'HAProxy explique comment configurer le débordement via une file d'attente : les requêtes sont mises brièvement en file d'attente avant d'être acheminées vers la capacité de secours, plutôt que d'aboutir à un échec.

Les instances Cloud Burst fonctionnent mieux lorsque ton application est sans état au niveau de la couche de calcul : l'état de session est stocké dans Redis sur le serveur dédié, ce qui permet à n'importe quelle instance cloud de traiter n'importe quelle requête. Les applications avec état nécessitent une configuration d'affinité de session, ce qui complique considérablement le routage des pics de trafic.

Configuration des déclencheurs d'auto-scaling sur AWS :

# Créer une alarme CloudWatch pour déclencher la mise à l'échelle lorsque le serveur dédié est saturé

aws cloudwatch put-metric-alarm \

  --alarm-name "dedicated-cpu-high" \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 60 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --alarm-actions arn:aws:autoscaling:us-west-2:123456789:scalingPolicy:policy-arn

# Create a CloudWatch alarm to trigger scaling when dedicated is saturated

aws cloudwatch put-metric-alarm \

  --alarm-name "dedicated-cpu-high" \

  --metric-name CPUUtilization \

  --namespace AWS/EC2 \

  --statistic Average \

  --period 60 \

  --threshold 80 \

  --comparison-operator GreaterThanThreshold \

  --alarm-actions arn:aws:autoscaling:us-west-2:123456789:scalingPolicy:policy-arn

Reprise après sinistre avec le mode « warm standby » dans le cloud

Un serveur dédié sans plan de reprise après sinistre constitue un point de défaillance unique. La solution « warm standby » dans le cloud offre une capacité de reprise qui ne nécessite pas de maintenir un deuxième serveur dédié à plein tarif.

Le modèle DR repose sur trois principes :

La réplication des données est continue. La réplication via le journal binaire MySQL vers une réplique hébergée dans le cloud permet à la base de données de secours de rester à quelques secondes de la base principale. Configure la réplication dans le fichier my.cnf sur la base principale :

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin.log
binlog_do_db = production_db

Sur la réplique dans le cloud :

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1

[mysqld]
server-id = 2
relay-log = /var/log/mysql/mysql-relay-bin.log
log_bin = /var/log/mysql/mysql-bin.log
read_only = 1

Le code de l'application est stocké dans un système de stockage d'objets dans le cloud. Grâce à une copie de ton répertoire d'application synchronisée avec S3, l'instance de reprise après sinistre dans le cloud peut récupérer la base de code actuelle lors du basculement, sans avoir besoin que le serveur principal soit accessible.

La bascule DNS est préconfigurée. Les contrôles d'intégrité Cloudflarepeuvent basculer automatiquement le DNS de l'adresse IP de ton serveur dédié vers celle de ton instance cloud dans les 30 secondes suivant la détection d'une panne du serveur principal. Prépare ça avant d'en avoir besoin — pas pendant une panne.

La solution de secours à chaud DR fonctionne à un coût cloud minimal (une instance arrêtée ou une petite instance en cours d'exécution pour la réplication) jusqu'au basculement, moment auquel elle s'adapte pour gérer le trafic de production.

Architecture réseau : relier les deux environnements

Une infrastructure hybride nécessite une connexion privée entre les environnements dédiés et ceux du cloud. La connexion via l'Internet public fonctionne, mais entraîne une latence et des risques de sécurité. Deux options s'offrent à toi :

Tunnel VPN : un tunnel WireGuard ou OpenVPN entre le serveur dédié et le VPC cloud offre une connectivité privée à un coût négligeable. La configuration de WireGuard est nettement plus simple que celle d'OpenVPN et offre de meilleures performances à haut débit.

# /etc/wireguard/wg0.conf on dedicated server

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <cloud_instance_public_key>
AllowedIPs = 10.10.0.0/24
Endpoint = <cloud_instance_ip>:51820
PersistentKeepalive = 25

# /etc/wireguard/wg0.conf on dedicated server

[Interface]
PrivateKey = <server_private_key>
Address = 10.10.0.1/24
ListenPort = 51820

[Peer]
PublicKey = <cloud_instance_public_key>
AllowedIPs = 10.10.0.0/24
Endpoint = <cloud_instance_ip>:51820
PersistentKeepalive = 25

AWS Direct Connect / Azure ExpressRoute : pour les architectures hybrides à haut débit, une liaison réseau dédiée entre le centre de données InMotion Hostinget le fournisseur de cloud élimine complètement le recours à l'Internet public. Cela entraîne un surcoût (Direct Connect coûte à partir de 0,02 $/Go pour le transfert de données), mais élimine les fluctuations de latence et garantit un débit constant.

Pour la plupart des déploiements hybrides, WireGuard sur l'Internet public avec une bande passante suffisante suffit. Direct Connect devient pertinent lorsque le volume de réplication des bases de données ou le trafic entre les services dépasse régulièrement 1 Gbit/s.

Modèle de coûts : là où l'hybride s'impose

D'un point de vue économique, l'option hybride est préférable lorsque ta charge de travail de base correspond à celle d'un serveur dédié et que tes pics de trafic sont sporadiques. Réfléchis à ceci :

• Serveur dédié (formule EssentialInMotion Hostingà 99,99 $/mois) : gère 90 % du trafic en continu
• Capacité de pointe (2 instances EC2 t3.xlarge, à la demande à environ 0,17 $/heure chacune) : active 40 heures par mois lors des pics de trafic
• Restauration après sinistre dans le cloud en mode veille active (instance EC2 arrêtée) : 0 $/mois jusqu'à ce qu'un basculement soit nécessaire ; stockage de réplication S3 : environ 5 à 20 $/mois
• VPN WireGuard : sans frais supplémentaires

Total mensuel : environ 130 à 140 $ par mois, contre environ 400 à 600 $ par mois si tout était hébergé sur le cloud avec une capacité équivalente, pour des performances de base comparables et une capacité de pointe.

Les économies réalisées diminuent si tes pics de trafic sont fréquents et prolongés. À un certain stade, un serveur dédié plus puissant revient moins cher que le recours fréquent au cloud burst.

Le serveur dédié InMotion Hostingcomme cœur hybride

La gamme de serveurs dédiésInMotion Hosting est spécialement conçue pour répondre à ces besoins : haute performance, forfait illimité, bande passante extensible jusqu'à 10 Gbps pour gérer les pics de trafic sans frais de sortie par Go, et services gérés Premier Care pour que l'infrastructure de base ne mobilise pas les ressources techniques.

Les 192 Go de mémoire vive DDR5 du serveur Extreme offrent une marge de mémoire suffisante pour que de nombreuses applications puissent traiter l'intégralité de leur ensemble de données en mémoire sur le serveur dédié, en ne recourant au cloud que pour les véritables débordements, et non pour les lectures de base de données courantes qui pousseraient un serveur moins puissant à ses limites.