B.2 Règles à base des seuils niveau SaaS
4.16 Cycle de vie CSLA
24 </csla:guarantees>
Les pénalités sont liées à chaque objectif. Si l’objectif de temps de réponse est violé une pénalité de type fonction est exécutée. Alors que la violation des autres objectifs déclenche une pénalité constante 0,1 euro/requête.
Billing
1 <csla:billing>
2 <csla:payasYouGo>
3 <csla:description>Pay as You Go</csla:description>
4 </csla:payasYouGo>
5 </csla:billing>
La facturation est basé sur le modèle Pay as You Go. Le prix de service est 1e/requête.
Il sera ajusté en fonction des pénalités.
Terminaison
1 <csla:terminations>
2 <csla:termination id="ter1"notificationMethod="e−mail"fees="20 euros"
3 notificationPeriod="15 days"terminationInitiator="consumer"
4 terminationType="Voluntary Termination">
5 <csla:terminationDescription/>
6 </csla:termination>
7 </csla:terminations>
8 </csla:template>
9 </csla:CSLA>
Le client a le droit de résilier le contrat avec des frais de résiliation. Il suffit juste de notifier le fournisseur avec un mail.
Le but des expérimentations est d’illustrer la gestion fine des violations via des études de cas. D’abord, nous illustrons les apports offerts par la dégradation de QdS (via les propriétés fuzziness et confidence). Ensuite, nous étudions la dégradation de fonction-nalités (les modes de fonctionnement). A la fin de la section, nous introduisons les éditeurs CSLA qui facilite la génération des SLAs conformément à la grammaire CSLA.
i) Étude de cas 1
Nous restons dans le cadre de notre exemple fil conducteur, où le service considéré est un service de type SaaS accessible en ligne par plusieurs clients. Nous distinguons deux niveaux de SLA : i)SLASentre le client final et le fournisseur de SaaS, et ii)SLAR entre le fournisseur SaaS et le fournisseur IaaS.
Cette étude de cas est dédiée à l’illustration des apports de la dégradation de QdS pour affiner les stratégies du fournisseur SaaS par exemple. Nous développons notamment les stratégies de contrôle d’admission et d’ordonnancement.
a) Protocole d’expérimentation
Nous présentons dans ce qui suit l’environnement et le scénario d’évaluation.
Injecteur de charge : Apache JMeter 2 est un outil open source de test de perfor-mance et de charge. Il permet d’imiter les actions des utilisateurs réels en simulant la charge. Il est entièrement écrit en Java, ce qui lui permet d’être utilisé sur tout système
2http ://jmeter.apache.org/
d’exploitation supportant une machine virtuelle Java (JVM). Il supporte plusieurs pro-tocoles en particulier HTTP.
Application synthétique : Les expérimentations réalisées ont été conduites avec des bancs d’essai synthétiques simulant un service d’informatique décisionnelle (BI -Business Intelligence). Ce service fournit 3 classes de services. Le Tableau4.1formalise les SLAs associés à chacune des classes. Nous énumérons deux lignes par classe (avec et sans propriétés CSLA). Le temps de réponse est évalué selon le conceptper-interval.
Il désigne le minimum des temps de réponse sur un intervalle de 10 minutes. Il est évalué sur une fenêtre de 30mn. Les prix et les pénalités sont déterminés suite à des statistiques sur des simulations.
Table4.1 – SLA niveau SaaS (SLAS)
service métrique oper. valeur fuzz. % of fuzz. conf. prix pénalité
gold
Rt ≤
0,4s 0 0 100 0,21e/rqt 0,09e/rqt
0,1 10 97 0,19e/rqt 0,08e/rqt
silver 0,6s 0 0 100 0,17e/rqt 0,07e/rqt
0,1 10 97 0,15e/rqt 0,06e/rqt
bronze 0,8s 0 0 100 0,14e/rqt 0,05e/rqt
0,1 10 97 0,12e/rqt 0,04e/rqt
Infrastructure: Les expérimentations présentées dans cette section ont été conduites par simulation des instances d’Amazon EC2. Le Tableau4.2illustre le SLA associé à ces ressources. La disponibilité est calculée en fonction du pourcentage de temps utilisable mensuel sur des intervalles de 5 minutes. La pénalité (crédit de service) est égale à un pourcentage de la facture du client.
Table4.2 – SLA niveau IaaS (SLAR)
service métrique oper. valeur fuzz. % of fuzz. conf. prix pénalité
Small Av ≥ 99,95% 0 0 100 0,046e/h 10% si 99,95<Av≤99%
30% si Av<99%
Scénario d’évaluation L’expérimentation se déroule en deux phases : i) constater l’utilité des propriétés CSLA (fuzziness et confidence) sans modifier la stratégie (algo-rithme) du fournisseur SaaS et ii) intégrer des propriétés CSLA dans la stratégie du fournisseur.
Nous avons évaluéMinAvailCapacity[WKGB12] avec les SLAs proposés dans le Tableau 4.1. Le principe de l’algorithme MinAvailCapacityest le suivant : affecter la requête acceptée à l’instance dont la capacité disponible est le minimum. Nous définissons la capacité d’une instance via le niveau de multiprogrammation maximal (MPL -MultiProgramming Level). Ce MPL limite le nombre des requêtes concurrentes. En ap-pliquant l’algorithmeMinAvailCapacity, une requête acceptée sera affectée à l’instance dont la différence entre son MPL et les requêtes en cours qu’elle traite est le minimum.
Ensuite, nous avons développé une extension deMinAvailCapacitypour prendre en compte les propriétés CSLA. En se basant sur la confiance (confidence), nous déve-loppons une heuristique qui calibre l’admission des requêtes. Au cas où l’admission
d’une requête nécessite l’ajout d’une instance, cette heuristique ralentit la décision d’admission en utilisant la fuzzinesset vérifie la confiance. Si l’ajout d’une VM est en-core indispensable, l’heuristique prend la décision en fonction de la confiance. Si cette dernière est vérifiée (temporairement) la requête est rejetée. Sinon la requête est admise et une VM est créée.
Nous avons testé le service avec 1000 clients. Nous avons fait varier le taux d’arrivée de 100 à 1000 requêtes par seconde. Nous classifions ces taux en 5 classes de charge : very small(de 100 à 300),small(de 300 à 500),medium(de 500 à 600),large(de 600 à 800) etvery large(de 800 à 1000).
b) Résultats
Expérience 1 : Les Figures 4.17(a) et 4.17(b) illustrent la première phase d’expéri-mentation. Nous avons examiné l’algorithmeMinAvailCapacityavecconfidence=100%
et fuzziness =0 puis confidence=97%, fuzziness =0,1 et pourcentage de fuzziness =10%
(cf Tableau4.1). La Figure4.17(a)montre que lafuzzinesset laconfidenceabsorbent un nombre important des violations. Sans toucher les algorithmes définis par le fournis-seur, nous constatons que notre modèle économique permet d’améliorer le profit du fournisseur (4.17(b)). Alors que la différence est très négligeable pour les taux d’arrivée very small et small, le gain devient important à partir du taux meduim.
Le profit de fournisseur reste fortement lié à la gestion de prix d’une requête en fonction des propriétésconfidenceetfuzziness. Un tel prix doit permettre au fournisseur de gagner sans importuner le client. Dans notre cas d’étude, le prix a été ajusté suite à des statistiques sur les simulations. Nous analysons ces statistiques afin de définir un rapport qualité-prix à la fois attrayant pour le client final et rentable pour le fournisseur SaaS. Des modèles économiques plus aboutis comme le Yield management permet-traient d’affiner ces tarifs.
(a) nombre des violations (b) profit du fournisseur SaaS