Le capacity planning pour les nuls

Définition

Faire un capacity planning c’est se projeter dans le futur et s’assurer qu’on aura la capacité de répondre à la demande.

Pour n’importe quelle ressource informatique, cela revient basiquement à multiplier 3 nombres ensembles : l’utilisation, un facteur d’échelle et une marge d’erreur et de comparer le résultat avec l’utilisation maximum de notre ressource

Voyons un peu plus précisément comment définir ces différents éléments.

Taux d’utilisation

La première étape dans la réalisation, c’est de choisir une valeur pour le taux d’utilisation.

L’idéal est de prendre un créneau horaire où on a une charge stable et normale et où les utilisateurs sont contents de leur temps de réponse. Le pic journalier est ainsi, souvent, un bon point de départ de cette recherche.

Si vous ne savez pas quoi prendre comme indicateur, le premier et le plus simple, c’est évidemment l’utilisation CPU, car la plupart des transactions en utilisent. Il faut aussi faire attention à ne pas avoir de trop grande moyenne, car elles pourraient cacher des pics significatifs. Une fois le choix fait, il est important de définir pourquoi on a choisi ce point, quelles en sont les conditions (quelles en sont les limites). Au bout du compte, vous devez arriver avec une plage horaire et une valeur de CPU pour votre système. N’oubliez pas de regarder sur les systèmes autour pour être sûr que le comportement est homogène et que ce n’est pas un cas isolé.

Facteur d’échelle

Le facteur d’échelle représente ce que sera l’évolution future. Dans l’idéal, ce facteur doit être fournit par le demandeur qui est le mieux à même de savoir quelle doit être l’évolution de l’usage des clients.

Il faut noter, qu’en général, hélas, on obtient un nombre aléatoire plutôt suspect !

Il est à noter qu’un capacity planning assume que la demande en ressources sera majoritairement linéaire. Toutefois, il existe quelques exceptions comme :

• lorsque les applications démarrent
• quand il y a un bottleneck applicatif
• il y a des erreurs qui arrivent (souvent cause de réessaie par exemple)

Tous ces cas là ne seront évidemment pas à prendre en compte dans le calcul, car on ne fait, bien évidemment, pas un capacity planning d’une application qui redémarre ! Toutefois, dans certaines conditions, il peut être judicieux de faire un capacity planning prenant en compte les systèmes qui tombent en erreur, pour, par exemple, savoir si nous serions toujours en mesure de tenir la charge dans ce cas.

La marge d’erreur

La marge d’erreur va être là pour compenser tout ce que vous ne pouvez pas prédire, les choses qui arrivent et que vous ne savez pas expliquer, voire les évolutions logiciels, les changements réseaux, etc. Il faut noter qu’un capacity planning répond à la question :

est-ce qu'on a les resources suffisantes ?
et non pas 
est-ce que le temps de réponse sera bon ?

La marge d’erreur représente ainsi la qualité de votre estimation. Ou encore la confiance que vous avez dans cette estimation.

On l’exprime souvent en pourcentage et généralement, elle varie entre 10 et 50 % avec une valeur très courante de 20%.

Usage maximum

L’usage maximum est le seuil à partir du quel on va considérer qu’une ressource qui fournit un service va devenir trop utilisée pour le fournir correctement. C’est cette valeur qui va nous servir de référence pour notre capacity planning.

Quand est-ce que trop c’est trop ?

Dans le cas de ressources qui fournissent un service, on comprend facilement qu’il y a une limite au delà de laquelle le résultat sera inacceptable causant souvent de l’empilement. Si on s’en réfère à la théorie des queues, on apprend qu’un équipement chargé à 50% aura un temps de réponse deux fois plus élevé que si il y avait un seul travail en cours !

Il faudra aussi faire attention à l’exclusivité d’une ressource. Par exemple, un disque ou une connexion. Si un processus a besoin de CPU, on peut dire que n’importe lequel fera l’affaire, par contre si le même processus à besoin d’accéder à une BDD, seule la connexion ou la lecture disque marchera et de facto limitera votre linéarité. En effet, si vous avez le choix pour obtenir votre donnée, il y a toutes les chances qu’elle soit disponible et ne limite pas le temps de réponse. Au contraire, si l’accès à votre donnée est limitée, il est probable que votre temps de réponse se dégrade malgré une utilisation faible de votre ressource.

Dans le choix de la valeur, il faudra aussi se concentrer sur la transaction principale et non pas sur toutes les transactions possibles et imaginables.

Un moyen expérimental d’estimer cette valeur maximum pour une ressource peut aussi venir de test en charge où l’on augmente celle-ci jusqu’à obtenir un temps de réponse inacceptable, ce qui nous donne notre valeur maximum admissible.

note : logiquement vous devriez obtenir une valeur supérieure à 50% et de l’ordre de 80%-90% dans le meilleur des cas

On peut aussi remarquer que la consommation CPU n’est pas le seul indicateur, ni le seul critère à regarder dans la recherche de l’utilisation maximale, beaucoup d’autres éléments peuvent interférer dans son usage.

Les calculs ?

Une fois ces élément réunis, le calcul est facile à faire, on l’a vu :

projection = utilisation x facteur d'échelle x marge

L’idéal est alors de présenter ces chiffres sous forme d’un joli graphe avec l’utilisation maximale et éventuellement l’utilisation actuelle, et bien évidemment de faire cela pour chacune des ressources utiles. De même on le fera sur la periode que l’on étudie : 1 mois, 1 trimestre, 1 an, en fonction des informations futures que l’on aura.

Et bien évidemment de faire cela pour chacune des ressources utiles. (ici une prevision du CPU)

Dans l’idéal, si les données d’usage futures sont suffisament complètes, on peut même envisager plusieurs scénarios.

Quelques exemples

Prenons quelques cas pratiques, afin de voir comment cela s’applique et quelles sont les limites de ce modèle simplifié.

Un exemple basique

Supposons que l’on ait un service qui fasse un million de transactions, et que je voudrais passer à 4 millions. Soit une augmentation de 400 %. Mon facteur d’échelle sera donc 4 et je vais me prendre une marge d’erreur de 20 %.

1M -> 4M : 400% (soit 4 ) 
CPU : 10% (soit 0.1 )
marge : 20% (soit 1.2 )
projection = 0.1 * 1.2 * 4 = 0.48 ( soit 48 % ) 
si notre "max usage" est à 70% on à de la marge.

Comme évoqué, il faudra toutefois faire attention à ce qui se passe au niveau des informations lorsque l’on détermine le cas d’utilisation maximale. Dans notre cas, si on imagine que notre serveur est un Apache, il faudrait faire attention à la partie AJP qui est, comme on l’a évoqué dans la notion d’usage maximal, une ressource unique et dont le remplissage impliquera un blocage !

si mon AJP pool est remplis à 80%, le passage à 400% donnerais un remplissage à 384% ! Le sens commun nous fait comprendre facilement que mon CPU sera bloqué bien avant cela et qu'il ne sera pas la vraie ressource importante.

Exemple avec une panne

On l’a évoqué précédemment, certains cas d’erreurs peuvent (et doivent) être intégrés dans une étude de capacity planning. Imaginons pour cela un cas où on aurait plusieurs serveurs et que l’on veuille savoir ce qui se passe si l’un d’eux tombe en panne. Partons du principe que l’on a 3 serveurs, chacun utilisé à 10%. Que se passe-t-il si l’un d’eux tombe ?

3 serveur à 10% CPU, 1 panne -> 3 * 10 = 30  
soit 15 % CPU par serveur restant, on est bon 

mais appliquons notre capa planning :

notre estimation est de 48 % par serveur, soit 144 % 
ce qui donnerait 72% par serveur en cas de panne

On se retrouverait au dessus de notre maximum, il y aura donc une réflexion à avoir :

• prend-on le risque ?
• ajoute-t-on un serveur ?

Ce sera là, toute la difficulté de l’interprétation de ce capacity planning.

Conclusion

En procédant par étape, on peut facilement mettre en place un capacity planning simple, qui pourra être enrichi par la suite avec d’autres informations et devenir un élément de référence pour la production et le suivi.