Skip to content
← Tous les guides

Devora Cloud · Blog

Scalabilité, load balancing et failover : comment votre site tient les pics

La différence entre failover, réplicas de répartition de charge et autoscaling sur Devora Cloud, leur coût et ce qu’il faut adapter dans le code pour encaisser les pics de trafic.

RépartiteurHTTPSPrincipaleAMD EPYCRéplica 1AMD EPYCRéplica 2AMD EPYCFailover arrêtésur un autre serveurfailover : démarre si la principale tombeCPUseuil CPU → +1 réplicaPostgreSQLmême baseRedissessionsS3fichiers
Illustration technique. Fonctionnalités et régions selon le forfait, la disponibilité et la compatibilité.

Une campagne qui devient virale, le Black Friday, la mention d’un influenceur : les pics de trafic préviennent rarement. Si votre site dépend d’un seul serveur, deux choses peuvent mal tourner en même temps : la machine ne suit plus, ou elle s’arrête tout simplement.

La scalabilité, c’est la capacité à servir plus de monde sans tomber. Sur Devora Cloud, elle repose sur trois briques distinctes — failover, réplicas de répartition de charge et autoscaling — et mieux vaut comprendre le rôle de chacune avant de payer quoi que ce soit.

Failover : le plan B déjà inclus dans chaque projet

Chaque projet sur Devora Cloud, y compris sur le forfait Hobby, dispose d’un réplica de failover. Il reste arrêté sur un autre serveur, prêt à prendre le relais. Si l’instance principale tombe, le réplica de failover démarre et prend la suite. Quand la principale revient, le réplica de failover est de nouveau arrêté.

Comme il est arrêté en temps normal, ce réplica ne partage pas le trafic et n’ajoute pas de capacité. Son rôle est ailleurs : réduire la durée d’indisponibilité quand un serveur a un problème.

  • Inclus dans tous les forfaits, sans surcoût.
  • Hébergé sur un autre serveur, pas sur la machine de la principale.
  • Démarre uniquement si la principale tombe et s’arrête à son retour.

Load balancing : plusieurs copies se partagent le trafic

Sur tous les forfaits, vous pouvez ajouter des réplicas de mise à l’échelle, facturés à l’heure. Chaque réplica est une copie active de votre application, de la même taille que le forfait, et le répartiteur distribue les requêtes entre les copies saines. Si l’une d’elles a un souci, les autres continuent de répondre.

Tous les réplicas utilisent la même base de données et le même S3 du projet. Vous gagnez donc de la puissance de traitement, pas une nouvelle base.

  • Hobby : jusqu’à 2 copies allumées en même temps.
  • Pro : jusqu’à 3 copies allumées en même temps.
  • Enterprise : jusqu’à 5 copies allumées en même temps.
  • Premier réplica supplémentaire : plein tarif du forfait, à l’heure.
  • Load balance : plein tarif horaire pour chaque copie ; en autoscaling, 10 % de remise dès la copie supplémentaire suivante.
  • Facturation à l’heure, uniquement quand le réplica tourne.

Exemple avec le forfait Pro (20 US$ par mois) : le premier réplica revient à l’équivalent de 17 US$ s’il tourne tout le mois, et chaque réplica suivant à 15 US$. Si vous l’activez seulement pendant une campagne de trois jours, vous ne payez que ces heures-là.

Autoscaling : des réplicas qui démarrent quand le CPU grimpe

L’autoscaling est disponible sur tous les forfaits et facturé à l’heure pendant que les copies supplémentaires tournent. Vous définissez un seuil d’utilisation CPU ; quand l’application le dépasse, la plateforme démarre un réplica de plus, jusqu’au maximum autorisé par votre forfait. Quand la demande baisse, les copies supplémentaires ne sont plus utiles et sont arrêtées.

C’est le bon choix pour un trafic irrégulier : vous ne laissez pas tourner des copies la nuit, et vous n’avez pas à vous précipiter pour ajouter de la capacité quand le pic arrive.

Failover, load balancing ou autoscaling ?

FailoverRéplicas de répartitionAutoscaling
À quoi ça sertRester en ligne si la principale tombeRépartir le trafic entre copiesDémarrer des copies quand le CPU monte
ForfaitsTousTousTous
Au quotidienArrêté, sur un autre serveurActifs, reçoivent du traficDémarre et s’arrête selon le CPU
CoûtInclusPlein tarif horaire, sans remiseÀ l’heure, uniquement pendant que le clone tourne : le 1er au plein tarif, -10 % dès le suivant

En pratique, les trois se complètent : le failover protège contre la panne d’un serveur, les réplicas donnent une marge constante et l’autoscaling absorbe les pics.

Ce qu’il faut adapter dans votre code

Les réplicas ne fonctionnent bien que si l’application ne garde pas d’état sur sa propre machine. Chaque requête peut arriver sur une copie différente, donc :

  • Stockez les sessions de connexion dans Redis (ou dans la base), pas dans la mémoire du processus, pour que l’utilisateur reste connecté quel que soit le réplica.
  • Envoyez les fichiers des utilisateurs vers S3, jamais sur le disque du conteneur. Le disque n’est pas partagé entre réplicas.
  • Coordonnez les tâches planifiées (cron, files) pour qu’elles ne s’exécutent pas une fois par copie.
  • Gardez la configuration dans des variables d’environnement, identiques pour tous les réplicas.

PostgreSQL ou Redis est inclus dans tous les forfaits (Hobby 1 base, Pro 2, Enterprise 4), et le S3 privé de chaque projet est prêt à recevoir les fichiers.

Serveurs AMD EPYC : la taille de chaque copie compte

Les applications tournent sur des serveurs équipés de processeurs AMD EPYC, aux États-Unis. Chaque réplica a les mêmes limites CPU et mémoire que le forfait : ajouter des réplicas augmente la capacité totale, mais ne rend pas une copie individuelle plus puissante.

L’ordre habituel est donc : vérifier d’abord que le code est efficace, choisir ensuite le forfait avec la bonne taille par copie, et seulement alors multiplier les copies. Si l’application consomme beaucoup de mémoire par requête, monter en gamme aide davantage que d’ajouter de petits réplicas.

Pour les visiteurs au Brésil, le cache CDN propre à Devora accélère la diffusion du contenu, mais n’exécute pas l’application : le traitement reste sur les serveurs américains.

Questions fréquentes

Le forfait Hobby inclut-il le load balancing ?

Oui. Hobby inclut le failover et aussi le load balancing et l’autoscaling, facturés à l’heure, avec jusqu’à 2 copies allumées de 0.5 vCPU et 512 Mo.

Chaque réplica a-t-il sa propre base de données ?

Non. Tous les réplicas utilisent la même base et le même S3 du projet. Les réplicas de l’application ne copient pas la base.

Le réplica de failover est-il payant ?

Non. Il est inclus dans tous les forfaits, de Hobby à Enterprise.

Comment savoir s’il me faut des réplicas ou un forfait supérieur ?

Regardez les métriques. Un CPU élevé pendant longtemps appelle plus de copies ou plus de vCPU ; une mémoire saturée avec des redémarrages appelle un forfait avec plus de RAM. Notre guide sur les sites lents explique comment lire ces signaux.

Scalabilité, load balancing et failover : comment votre site tient les pics · Devora Cloud