Ceci est le point de vue dimensionnement du projet. Il permet de déterminer la taille de l’infrastructure nécessaire au projet.
|
Tip
|
Les contraintes sont les limites applicables aux exigences sur le projet. Il est intéressant de les expliciter pour obtenir des exigences réalistes. Par exemple, il ne serait pas valide d’exiger des temps de réponse d’un web service incompatibles avec le débit du réseau sous-jacent. |
|
Tip
|
Lister ici les éventuelles contraintes liées aux disques |
Exemple : L’espace disque maximal allouable à une VM est de 2 To.
|
Tip
|
Lister ici les éventuelles contraintes liées à la puissance de calcul |
Exemple 1 : Une VM sera dotée au maximum de 10 VCPU
Exemple 2 : L’ensemble des pods de l’application ne devra pas demander plus de 1 CPU par node.
|
Tip
|
Lister ici les éventuelles contraintes liées à la mémoire |
Exemple : un pod ou un job Kubernetes ne devra pas utiliser plus de 6 Go de RAM
|
Tip
|
Il est crucial de récupérer un maximum d’informations issues de la production plutôt que des estimations car ces dernières se révèlent souvent loin de la réalité. C’est d’autant plus difficile s’il s’agit d’un nouveau projet. Prévoir alors une marge importante. Les informations données ici serviront d’entrants au SLA de l’application. |
|
Tip
|
Il s’agit des métriques permettant de déterminer le volume de stockage cumulé du projet. Penser à bien préciser les hypothèses prises pour les métriques estimées. Il sera ainsi possible de les revoir si de nouveaux éléments métier apparaissent. |
|
Tip
|
ce sont les données métier mesurées ou estimées qui serviront d’entrants au calcul des besoins techniques de stockage. |
| Métrique | Description | Mesurée ou Estimée ? | Valeur | Augmentation annuelle prévisionnelle (%) | Source | Détail/hypothèses |
|---|---|---|---|---|---|---|
S1 |
Nombre d’entreprises éligibles |
Estimé |
4M |
+1% |
INSEE [2] |
On considère que MIEL ne concerne pas les auto-entrepreneurs |
S2 |
Taille moyenne d’un PDF |
Mesurée |
40Ko |
0% |
Exploitants |
|
Tip
|
Lister ici les besoins en stockage de chaque composant une fois l’application arrivée à pleine charge (volumétrie à deux ans par exemple). Prendre en compte :
Ne pas prendre en compte :
Fournir également une estimation de l’augmentation annuelle en % du volume pour permettre aux exploitants de commander ou réserver suffisamment de disque. Pour les calculs de volumétrie, penser à prendre en compte les spécificités de l’encodage (nombre d’octets par caractère, par date, par valeur numérique…). Pour une base de donnée, prévoir l’espace occupé par les index et qui est très spécifique à chaque application. Une (très piètre) estimation préliminaire est de doubler l’espace disque (à affiner ensuite). N’estimer que les données dont la taille est non négligeable (plusieurs centaines de Mo minimum). |
-
Exemple de volumétrie statique du composant C :
| Donnée | Description | Taille unitaire | Nombre d’éléments à 2 ans | Taille totale | Augmentation annuelle |
|---|---|---|---|---|---|
Table Article |
Les articles du catalogue |
2Ko |
100K |
200 Mo |
5 % |
Table Commande |
Les commandes clients |
10Ko |
3M |
26.6 Go |
10 % |
Logs |
Les logs applicatifs (niveau INFO) |
200 o |
300M |
56 Go |
0 % (archivage) |
|
Tip
|
il s’agit des métriques par durée (année, mois, heure,…) et permettant de déterminer la charge appliquée sur l’architecture, ce qui aidera à dimensionner les systèmes en terme de CPU, bande passante et performances des disques. |
|
Tip
|
ce sont les données métier mesurées ou estimées qui serviront d’entrants au calcul de la charge. |
| Métrique | Description | Mesurée ou Estimée ? | Valeur | Augmentation annuelle prévisionnelle (%) | Saisonnalité | Source | Détail/hypothèses |
|---|---|---|---|---|---|---|---|
D1 |
Proportion d’utilisateurs se connectant au service / J |
Estimée |
1% |
+5% |
|
Les utilisateurs sont des professionnels utilisant l’application depuis la France métropolitaine aux heures de bureau standards |
|
Tip
|
Il s’agit ici d’estimer le nombre d’appels aux composants et donc le débit cible (en TPS = Transactions par seconde) que devra absorber chacun d’entre eux. Un système bien dimensionné devra présenter des temps de réponse moyen du même ordre en charge nominale et en pic. Toujours estimer le "pic du pic", c’est à dire le moment où la charge sera maximale suite au cumul de tous les facteurs (par exemple pour un système de comptabilité : entre 14 et 15h un jour de semaine de fin décembre). Ne pas considérer que la charge est constante mais prendre en compte :
Si le calcul du pic pour un composant en bout de chaîne de liaison est complexe (par exemple, un service central du SI exposant des données référentiel et appelé par de nombreux composants qui ont chacun leur pic), on tronçonnera la journée en intervalles de temps suffisamment fins (une heure par exemple) et on calculera sur chaque intervalle la somme mesurée ou estimée des appels de chaque appelant (batch ou transactionnel) pour ainsi déterminer la sollicitation cumulée la plus élevée. Si l’application tourne sur un cloud de type PaaS, la charge sera absorbée dynamiquement mais veiller à estimer le surcoût et à fixer des limites de consommation cohérentes pour respecter le budget tout en assurant un bon niveau de service. |
GET Detail de l’application MIEL
Taux maximal d’utilisateurs connectés en même temps en pic annuel |
S1 x F1 x 0.2 = 8K /H |
Durée moyenne d’une session utilisateur |
15 mins |
Nombre d’appel moyen du service par session |
10 |
Charge (Transaction / seconde) |
8K / 4 x 10 / 3600 = 5.5 Tps |
|
Tip
|
Pour un composant technique (comme une instance de base de donnée) en bout de chaîne et sollicité par de nombreux services, il convient d’estimer le nombre de requêtes en pic en cumulant les appels de tous les clients et de préciser le ratio lecture /écriture quand cette information est pertinente (elle est très importante pour une base de donnée). Le niveau de détail de l’estimation dépend de l’avancement de la conception de l’application et de la fiabilité des hypothèses. Dans l’exemple plus bas, nous avons déjà une idée du nombre de requêtes pour chaque opération. Dans d’autres cas, on devra se contenter d’une estimation très large sur le nombre de requêtes total à la base de données et un ratio lecture /écriture basée sur des abaques d’applications similaires. Inutile de détailler plus à ce stade. Enfin, garder en tête qu’il s’agit simplement d’estimation à valider lors de campagnes de performances puis en production. Prévoir un ajustement du dimensionnement peu après la MEP (relativement aisé si les ressources matérielles sont virtualisées et/ou si l’architecture est scalable horizontalement). |
Exemple : la base de donnée Oracle BD01 est utilisée en lecture par les appels REST GET DetailArticle fait depuis l’application end-user et en mise à jour par les appels POST et PUT sur DetailArticle issus du batch d’alimentation B03 la nuit entre 01:00 et 02:00.
Taux maximal d’utilisateurs connectés en même temps |
0.5% |
Nombre maximal d’utilisateurs connectés concurrents |
5K |
Durée moyenne d’une session utilisateur |
15 mins |
Nombre d’appel moyen du service |
10 |
Charge usagers GET DetailArticle (Transaction / seconde) |
(10/15) x 5K / 60 = 55 Tps |
Nombre de requête en lecture et écriture par appel de service |
2 et 0 |
Nombre d’appel journalier du service |
4K |
Nombre de requêtes INSERT et SELECT par appel de service |
3 et 2 |
Nombre journalier d’articles modifiés par le batch B03 |
10K |
Nombre de requêtes SELECT et UPDATE |
1 et 3 |
Nombre de SELECT / sec |
55x2 + 2 x 4K/3600 + 1 x 10K/3600= 115 Tps |
Nombre de INSERT / sec |
0 + 3 x 4K/3600 = 3.4 Tps |
Nombre de UPDATE / sec |
0 + 3 x 10K/3600 = 8.3 Tps |
|
Tip
|
Si les clients accèdent au système en WAN (Internet, VPN, LS …), préciser que les exigences de TR sont données hors transit réseau car il est impossible de s’engager sur la latence et le débit de ce type de client. Dans le cas d’accès LAN, il est préférable d’intégrer le temps réseau, d’autant que les outils de test de charge vont déjà le prendre en compte. Les objectifs de TR sont toujours donnés avec une tolérance statistique (90éme centile par exemple) car la réalité montre que le TR est très fluctuant car affecté par un grand nombre de facteurs. Inutile de multiplier les types de sollicitations (en fonction de la complexité de l’écran par exemple) car ce type de critère n’a plus grand sens aujourd’hui, particulièrement pour une application SPA). |
| Type de sollicitation | Bon niveau | Niveau moyen | Niveau insuffisant |
|---|---|---|---|
Chargement d’une page |
< 0,5 s |
< 1 s |
> 2 s |
Opération métier |
< 2 s |
< 4 s |
> 6 s |
Édition, Export, Génération |
< 3 s |
< 6 s |
> 15 s |
Exemple d’acceptabilité des TR :
Le niveau de respect des exigences de temps de réponse est bon si :
-
Au moins 90 % des temps de réponse sont bons.
-
Au plus 2% des temps de réponse sont insuffisants.
Acceptable si :
-
Au moins 80 % des temps de réponse sont bons.
-
Au plus 5 % des temps de réponse sont insuffisants.
En dehors de ces valeurs, l’application devra être optimisée et repasser en recette puis être soumise à nouveau aux tests de charge.
|
Tip
|
Préciser ici dans quel intervalle de temps les traitements par lot doivent s’exécuter. |
Exemple 1 : La fin de l’exécution des batchs étant un pré-requis à l’ouverture du TP, ces premiers doivent impérativement se terminer avant la fin de la plage batch définie plus haut.
Exemple 2 : le batch mensuel B1 de consolidation des comptes doit s’exécuter en moins de 4 J.
Exemple 3 : les batchs et les IHM pouvant fonctionner en concurrence, il n’y a pas de contrainte stricte sur la durée d’exécution des batchs mais pour assurer une optimisation de l’infrastructure matérielle, on favorisera la nuit pendant laquelle les sollicitations IHM sont moins nombreuses.
|
Tip
|
Préciser l’impact maximal accepté sur les temps de réponse lors d’une panne. |
Exemple 1 (perte d’un nœud d’un cluster) : Les serveurs devront être dimensionnés pour être chacun en mesure d’assurer le fonctionnement de l’application tout en limitant l’augmentation des temps de réponse à 20 %.
|
Tip
|
Donner ici RAM, disque et CPU de chaque nœud. A affiner après campagne de performance ou MEP. Pour les VM, on considère le disque des partitions système comme internes même si elles sont physiquement sur un SAN. Le disque SAN concerne des partitions montées sur SAN depuis un serveur physique ou virtuel. |
Exemple :
Machines virtuelles lb1, host2 (Reverse proxy)
| CPU | Mémoire | Disque interne | Disque SAN |
|---|---|---|---|
2 VCPU |
4 GiO |
20 GiO |
Pas de SAN |
Machine physique bdd1 (BDD PostgreSQL)
| CPU | Mémoire | Disque interne | Disque SAN |
|---|---|---|---|
16 cœurs Xeon 3Ghz |
24 GiO |
20 GiO |
3 TiO |
|
Tip
|
Dans certains cas, des pics extrêmes et imprévisibles sont possibles (effet Slashdot). Si ce risque est identifié, prévoir un système de fusible avec déport de toute ou partie de la charge sur un site Web statique avec message d’erreur par exemple. Ce dispositif peut également servir en cas d’attaque de type DDOS et permet de gèrer le problème et non de le subir car on assure un bon fonctionnement acceptable aux utilisateurs déjà connectés. |
|
Tip
|
Il est également utile de prévoir des systèmes de régulation applicatifs dynamiques, par exemple :
|
Exemple 1 : Le nombre total de jetons d’appels aux opérations REST sur la ressource DetailArticle sera de 1000. Au delà de 1000 appels simultanés, les appelants obtiendront une erreur d’indisponibilité 429 qu’ils devront gérer (et faire éventuellement des rejeux à espacer progressivement dans le temps).
Opération sur DetailArticle |
Proportion des jetons |
|---|---|
GET |
80% |
POST |
5% |
PUT |
15% |
Exemple 2 : un throttling de 100 requêtes par source et par minute sera mis en place au niveau du reverse proxy.
|
Tip
|
Suit-on les performances de l’application en production ? Cela permet :
Il existe trois grandes familles de solutions :
|
Exemple : les performances du site seront supervisées en continu par pingdom.com. Des analyses de performances plus poussées seront mises en œuvre par Pinpoint en fonction des besoins.