Estimateur de capacité

De combien de serveurs avez-vous réellement besoin ? Répondez par l’arithmétique plutôt que par l’intuition : donnez à l’estimateur votre taux de requêtes, le temps CPU que chaque requête brûle et le temps de réponse que voient les utilisateurs, et il renvoie les cœurs que le trafic maintient occupés, les serveurs entiers à provisionner — votre politique de redondance appliquée —, la concurrence que vos pools de connexions doivent survivre, et l’allure du même service à deux, cinq et dix fois le trafic.

Les formules, en langage simple

Cœurs. Multipliez le taux de requêtes par les secondes CPU que chaque requête consomme : c’est le nombre de cœurs que le trafic maintient occupés à 100 %. Divisez ensuite par votre utilisation cible — à 70 %, chaque cœur que vous provisionnez ne compte que pour 0,7 cœur de plan, et les 0,3 restants sont la marge qui garde les files courtes quand le trafic oscille. Cœurs nécessaires = requêtes/s × secondes CPU par requête ÷ utilisation cible.

Serveurs. Divisez les cœurs par les cœurs par serveur et arrondissez vers le haut — 0,4 serveur n’existe pas, et arrondir vers le bas est la façon dont un plan qui fonctionne en moyenne échoue au pic. La redondance s’applique après : N+1 ajoute un serveur de secours au nombre arrondi ; 2N double toute la flotte. La concurrence est un nombre distinct, venu de Little's law : requêtes en cours = requêtes/s × temps de réponse en secondes. Elle dimensionne les pools de threads, les connexions à la base de données et les descripteurs de fichiers — les limites que les services atteignent réellement pendant que leurs CPU se reposent encore. La sortie, quand vous donnez une taille de réponse, vaut requêtes/s × taille × 8, les bits dont est faite votre facture réseau. L’article compagnon, de combien de serveurs avez-vous réellement besoin, explique d’où vient chaque entrée et pourquoi les benchmarks des fournisseurs contredisent tout cela.

Compagnons de planification : le calculateur de budget d’erreur SLA convertit en minutes l’objectif de disponibilité que cette capacité défend, et le calculateur de rétention des sauvegardes dimensionne le côté stockage du même système.

Questions fréquentes

Pourquoi planifier pour 70 % d’utilisation plutôt que 100 % ?

Parce que les files explosent avant la saturation, pas à la saturation. Un CPU occupé à 95 % en moyenne est un CPU dont la file croît sans limite chaque fois que le trafic oscille — et le trafic oscille toujours. L’objectif d’utilisation est la marge qui absorbe les pics, les déploiements, les réessais et une dépendance lente. Soixante-dix pour cent est la valeur par défaut du secteur pour les services sensibles à la latence ; les travailleurs par lots qui tolèrent le délai peuvent tourner plus chaud, et tout ce qui fait face aux utilisateurs avec des pics devrait tourner plus froid.

Quelle est la différence entre les cœurs et les requêtes en cours ?

Ils répondent à des questions différentes. Les cœurs viennent du temps de service CPU : combien de processeur chaque requête consomme. Les requêtes en cours viennent de Little's law : le taux multiplié par le temps de réponse, et elles mesurent la concurrence — connexions, threads, mémoire maintenue ouverte —, pas la charge du processeur. Un service avec des appels en aval lents peut garder 500 requêtes en cours tout en utilisant deux cœurs, et il épuisera son pool de connexions bien avant d’épuiser le CPU. Dimensionnez les deux, ou celui que vous avez ignoré deviendra la panne.

Mon test de charge dit qu’un serveur traite 2 000 requêtes par seconde. Pourquoi cet estimateur n’est-il pas d’accord ?

Les tests de charge mesurent habituellement un service chaud, stable, au cache brûlant, répondant à une seule forme de requête depuis un client généreux. La production ajoute les démarrages à froid, les poignées de main TLS, les réessais, une longue traîne de requêtes lentes, les voisins bruyants et le déploiement qui divise la capacité par deux pendant dix minutes. L’estimateur est délibérément conservateur — temps CPU moyen, plafond d’utilisation, serveurs entiers, redondance ajoutée. Traitez le test de charge comme le plafond de ce qui est possible et ce chiffre comme le plancher de ce qu’il faut provisionner ; la vérité pour planifier, c’est le plancher.

Contre quoi N+1 protège-t-il réellement ?

Contre une panne : un hôte mort, un mauvais déploiement retiré de la rotation, un événement de zone de disponibilité qui emporte une seule instance. Avec N+1, les N serveurs restants atteignent toujours l’objectif — c’est le sens de dimensionner d’abord N à partir du trafic et d’ajouter le secours ensuite. 2N est une autre promesse : deux copies complètes, habituellement entre régions, pour les services qui doivent survivre à la perte d’une copie entière. Il double la facture, alors on l’achète pour les services dont l’absence se mesure en gros titres.

Comment obtenir mon temps de service CPU par requête ?

Mesurez-le, ne le devinez pas. Sur un service en marche : le total des secondes CPU consommées sur une fenêtre, divisé par les requêtes servies dans la même fenêtre. Les outils de surveillance de performance applicative le rapportent directement comme CPU par requête ; sous Linux, vous pouvez le dériver du temps CPU du processus dans /proc ou des métriques de vos conteneurs. Utilisez le chiffre de votre heure réaliste la plus chargée, pas la moyenne de la journée — une capacité planifiée sur des moyennes échoue précisément au pic pour lequel elle a été achetée.