Composition et expression qualitative de politiques d'adaptation pour les composants Fractal

(1)

HAL Id: inria-00542773

https://hal.inria.fr/inria-00542773

Submitted on 3 Dec 2010

HAL is a multi-disciplinary open access archive for the deposit and dissemination of sci- entific research documents, whether they are pub- lished or not. The documents may come from teaching and research institutions in France or abroad, or from public or private research centers.

L’archive ouverte pluridisciplinaire HAL, est destinée au dépôt et à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d’enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Composition et expression qualitative de politiques d’adaptation pour les composants Fractal

Franck Chauvel, Olivier Barais, Noël Plouzeau, Isabelle Borne, Jean-Marc Jézéquel

To cite this version:

Franck Chauvel, Olivier Barais, Noël Plouzeau, Isabelle Borne, Jean-Marc Jézéquel. Composition et

expression qualitative de politiques d’adaptation pour les composants Fractal. Actes des Journées

nationales du GDR GPL 2009, 2009, Toulouse, France, France. �inria-00542773�

(2)

d'adaptation pour les composants Fractal

FranckChauvel

3

,OlivierBarais

1

,NoëlPlouzeau

1

,IsabelleBorne

2

,andJean-MarcJézéquel

1

IRISA(INRIA&UniversitédeRennes1)

CampusdeBeaulieu

F-35042RENNES(FRANCE)

prenom.nom@irisa.fr

2

LaboratoireVALORIA(UniversitédeBretagneSud)

CentredeRechercheYvesCoppens

CampusdeTohannic

56017VANNESCEDEX

prenom.nom@univ-ubs.fr

3

NationalLaboratoryofHighCondenceSoftwareTechnologies

SchoolofElectronicsEngineering andComputerScience,

PekingUniversity,Beijing,100871,China

franck.chauvel@sei.pku.edu.cn

Abstract. Les plates-formesd'exécutionrécentestellesque Fractal ouOpenCOMorent

de nombreusesfacilités pourassurer la prise encomptede propriétésextra-fonctionnelles

(introspection,sondes,chargementdynamique,etc).Cependant,l'intégrationdepolitiques

d'adaptation reste délicate car ellenécessite decorréler la conguration du systèmeavec

l'évolution desonenvironnement.Letravail présentédanscetarticle étendlaplate-forme

Fractal avec les mécanismes nécessaires à l'exécution de politiques d'adaptation de haut

niveau.L'approcheestillustréeàl'aided'unserveurHTTPquidoitmodiersaconguration

(architecturaleetlocale)enfonctiondeplusieursparamètresextra-fonctionels.

1 Introduction

Lorsdudéveloppementdenouveauxsystèmeslogiciels,l'aspectfonctionnelestdemoinsenmoins

l'unique critère de satisfaction de l'utilisateur : les problématiques extra-fonctionnelles sont au

c÷urdeseortsde rechercheactuels.Il est, parexemple,nécessaire d'être capablede maintenir

unniveaucorrectpourdespropriétésliéesàlaqualitédeservice(QoS pourQualityofService)

tellesquelaabilité,ladisponibilité, letemps deréponse,l'ergonomie,etc.

Pour maintenir la qualité de service d'un système, deux approches sont possibles. On peut

d'unepart,vérieràpriori,(lorsdelaconception)quelescontraintessurlespropriétésdequalité

deservicenesontpasvioléesàl'exécution.L'utilisationderéseauxdePetripermet parexemple

d'obtenir des prévisions sur les consommations de ressources (mémoire, batterie, CPU, bande

passante, etc). On peut d'autre part, s'assurer, à posteriori, de la qualité de service fournie (à

l'exécution) endotant lessystèmes d'unecapacité d'auto-adaptation àleur environnementpour

assureraumieuxlaQoSdemandée.

Ainsi,lesplates-formes àcomposantrécentespermettantde construiredesapplicationsmod-

ulaireset recongurablestelles Fractal([3]), OpenCOM([4]) ou Spring ([10]) orent lesmécan-

ismesnécessairesausupportdesadaptations(introspection,chargementdynamique).Cependant,

ellesn'intègrentpasdirectementlanotiondepolitiqued'adaptation.Deuxraisonsprincipalesex-

pliquent cela. D'unepartle nombrede propriétés extra-fonctionnellesest potentiellementinni.

Il est alors impératifde pouvoirsegmenter cet espace pour pouvoir en maîtriser la complexité.

D'autrepart,ilnécessaire deconserverunniveaud'abstractionsusantpourgarderdesspéci-

cationsexploitables.

Lacontributiondestravauxprésentésdanscetarticleestdeproposeruncadrepourladénition

(3)

du modèle de composants Fractal et de son implémentation de référence Julia. Les politiques

d'adaptationsutilisées sontqualitativesmaisleur sémantique,basée surlalogique oue,permet

d'inférerdes valeurs quantitativeslors de l'exécution pouradapter l'architecture en fonction de

soncontexted'exécution. La sémantiquedumoteur d'inférenceprésentéedansce papierpermet

depréserverlacapacitédecomposercespolitiquesindépendanmmentdel'ordredanslequelelles

ontétédénies.

Lasuitedecetarticleestorganiséedelafaçonsuivante.Lasection2présentelesmotivations

surl'exempled'unserveurHTTPetlasection3introduitleformalismeutilisépourmodéliserles

politiquesd'adaptations.Lasection4démontrelasémantiqueassociéeauxpolitiquesd'adaptation

permettantleurcomposition.L'intégrationdanslaplate-formeFractalestprésentéedanslasection

5qui présenteàlafoisl'algorithmed'adaptationet sonimplémentationsousformedecontrôleur

Fractal. Unevalidation de l'approche,basée sur l'exempledu serveurHTTP,est présentée dans

la section 6. Une sélection des travauxconnexes est commentée dans lasection 7. La section 8

conclueet présentelesperspectivesouvertesparcestravaux.

2 Motivations

Pour démontrer la nécessité des politiques d'adaptation, cette section présente brièvement un

serveurHTTPetainsiquelesexigencesentermesdequalitéetd'adaptationquiluisontassociées.

La gure1 présente l'architecture proposéepour le serveur HTTP Cherokee. Il s'agit d'une

variationdel'exempleComanche 4

utilisédansplusieurscommunications([6]) autourdelaplate-

formeFractal.LesrequêtesHTTPsontluessurleréseauparlecomposantRequestReceiverquiles

transmet aucomposantRequestHandler. Pourtraiter unerequête, cedernier peut soitconsulter

le cache (composant CacheHandler), soit la transmettre au composant RequestDispatcher qui

interrogealorsunfermedeserveursdechierspourrésoudrelarequête.

requestHandler

CacheHandler FileServer1

RequestDispacther cache

cache

dispatcher dispatcher

Cherokee WebServer ^AC

AC

server

server1

RequestReceiver CC

BC

BC BC

handler handler server_ctrl

server_ctrl

FileServer2

server BC

server2

Fig.1.ArchitectureduserveurHTTPCherokeeprésentéeàl'aidedelanotationFractal

Cette architecture est dotée d'un cache (CacheHandler) et d'un contrôleur de charge (com-

posantRequestDispatcher pourpouvoirmaîtriserletempsderéponseetlegarderaussicourtque

possible.Pourpouvoirsupporterd'éventuellesmontéesencharge,lesexigences suivantesontété

dénies:

1. LecomposantCacheHandler nedoitêtredéployéquesilenombrederequêtesHTTPsimilaires

(l'indice dedispersion)estélevé.

2. LaquantitémémoireallouéepourlefonctionnementducomposantCacheHandler doitévoluer

enfonctiondelachargeglobaleduserveur.

4

(4)

globaleduserveur(nombrederequêtesparunitédetemps).

4. Lenombredeserveursdedonnéesdéployésdoitêtrecorréléaveclachargeglobaleduserveur

Plusieurs caractéristiquesde ces exigences doivent être soulignées. D'une part,ces exigences

peuventêtreclassiéesendeuxcatégories:lesrègleslocales,etlesrèglesarchitecturales.Lesrègles

locales concernent la conguration d'un composant particulier. C'est le cas de l'exigence 2 qui

neconcerneque lacongurationducache. Lesrèglesarchitecturales,paropposition,concernent

la conguration de lacollaboration entre les composants. Les exigences 1et 4en sont de bons

exemples,puisquequ'ellesnécessitentdemodierl'agencementdescomposantsetdesconnecteurs

(appelés bindings danslaterminologieFractal).

D'autrepart,cesexigencessontdécritesdemanièrequalitative,c'est-à-direàl'aided'unvocab-

ulairespéciqueàchaquetype propriété.Dans lapremièreexigenceparexemple, ilest question

d'un indice de dispersion élevé,ce qui est purement qualitatif car aucune valeurprécise n'est

fourniepourquantierletermeélevé.

3 Modélisation des politiques d'adaptation

Pour prendre en compte les exigences que nous avonsprésentés dans la section précédente, les

politiquesd'adaptationssontdécritesàl'aidedequatreélements:

unensemblederecongurationsarchitecturales

unensembledepropriétéset lesdomainesdevaleurquileurssontassociés

unensemblederèglespourlescongurationslocales

unensemblederèglespourlesrecongurationsarchitecturales

Reconguration architecurales Les diérentes recongurations architecturales qui sont util-

isées dans une politiqued'adaptation sont décrites sousla forme d'actions FScript. Chaque

reconguration est nomméeet pointe versunchierqui contient ladescriptionprécisede la

recongurationsousformed'actionsFScript.

policy withCache

is

reconfiguration addCache is 'addCache.fscript'

reconfiguration removeCache is 'removeCache.fscript'

Propriétés L'environnement du système est capturé par un ensemble de propriétés, chacune

reliéàundomainespécique.Chaquedomaineinclutladescriptionduvocabulairespécique

à utiliser pour qualier les propriétés qui lui sont associées. L'exemple suivant présente les

domaineset lespropriétésutiliséspourdécrirel'adaptationducache. Lachargemoyennedu

serveurestdécriteparunepropriétéload associéeaudomaineAverageLoad etpeutdoncêtre

qualiée enutilisant lestermes low, medium et high. Pourplusde concision, lasyntaxe que

nous proposons ore égalementla possibilité de décrire une propriété et le domaine qui lui

correspondd'uneseuletraite.

domain AverageLoad : Real

evolves in [0..100] as low medium high

property load : Real

sensor is getLoad on requestHandler

property requestDeviation : Real

evolves in [0..100] as low medium large

sensor is getRequestDeviation on requestHandler

property size : MemorySize

evolves in [0..2000] as small medium large

sensor is getMemoryUsed on cache

actuator is setMemoryUsed on cache

property validityDuration : Duration

evolves in [0..100] as short normal long

sensor is getValidityDuration on cache

(5)

nombredetermeset dudomainededénition.Parexemple,lachargeduserveur,qui évolue

entre0et 100sera'low'sielleestinférieurà50,'medium' sielleestcompriseentre 25et 75

et 'high'sielleestsupérieureà50.(Voirlasection 5.1.)

Deplus,àchaquepropriétésontassociésunsensor etunactuatorquiindiquentrespectivement

comment mesurer et/ou modier cette propriété dans l'architecture. Pour une architecture

Fractal, ces deux élements pointe vers des attributs de conguration d'un des composants

impliqués(FractalAttribute-Controller).

Règles de reconguration architecturale Lesdiérentesrecongurationsarchitecturalespos-

sibles auseind'unearchitecturesontcapturéesàl'aided'actions architecturales.Ces actions

peuventêtreutiliséesdansdesrèglesderecongurationarchitecturale.Chacunedecesrègles

met en relation le contexte d'exécution du système et l'utilité de déclencher une action ar-

chitecturale.Dansl'exemplesuivant,l'utilitédedéployerlecomposantCache estfaible siles

requêtessonttoutesdiérentes (propriétérequestDeviation).

when requestDeviation is 'low'

if count($context::child/*::interface/CacheHandler[server(.)]/component) = 0

then utility of addCache is very 'high'

when load is 'high'

if count($context::child/*::interface/CacheHandler[server(.)]/component) = 0

then utility of addCache is 'medium' or 'high'

when load is 'low' and requestDeviation is 'high'

if count($context::child/*::interface/CacheHandler[server(.)]/component) > 0

then utility of removeCache is 'high'

Règles de conguration locale Les recongurations locales, c'est-à-dire les recongurations

qui n'impactent que les propriétés locales d'un composant, sont décrites à l'aide règles qui

spécient l'évolution vouluede la congurationlocale. L'exemple suivant présente les règles

nécessaires pour corréler la quantité de mémoire allouée pour le composants Cache avec la

chargemoyenneduserveur.

when proxy.load is 'low'

then cache.size is 'small'

when proxy.load is 'medium'

then cache.size is 'medium'

when proxy.load is 'high'

then cache.size is 'large'

end policy

Touteslesrègles,qu'ellessoientlocalesouarchitecturalessontgardées.Lacontrainteassociée

estexpriméeàl'aidedulangageFPathquipermetdenaviguerlesarchitecturesFractalcomme

XPathpermetdenaviguerlesdocumentsXML([5]).Lecontexted'exécutiondelagarde,c'est-

à-direlecomposantcompositeenglobantlacollaboration,estdénotépar$context.

4 Composition de politiques d'adaptation

Commenousl'avonsexpliquéprécédemment,ladescriptiond'unepolitiqued'adaptationgénérale

à un système est délicate àcause de la complexité de l'environnementet des diérentes varia-

tionspossiblesde l'architecture. Pourpouvoirbriser cette complexité, il faut pouvoirtraiter les

problèmesséparément,àl'aidedepolitiquesd'adaptationsdistinctes.Toutefois,ilfaut alorsêtre

capabledecomposerfacilementlespolitiquesd'adaptation.Sil'onconsidèrelacompositioncomme

l'uniondesrèglesetdespropriétésquiconstituentlespolitiquesd'adaptation,l'ordred'unication,

danslesrèglesnotamment,nedoitpasavoird'impactsurl'interprétationdelapolitiquerésultante.

Lasuitedecettesectionmontrecela.

SoitΣ ^une^structure^telle^queΣ=hP, V, T, Ki^où^l'on^considère^les^éléments^suivants^:

(6)

P êstûnênsemble^de^propriétés

V êst ûne^fonction^partielle^quiâssocie ûne^valeur^à^chaque^propriété^telle^que^: V ={v:P 9R}

T ^est^l'ensemble^des^topologies^possibles

K ^est^l'ensemble^desintro-actionsarchitecturalesquiconserventlavaleurdespropriétésasso- ciéesàchaquecomposant.Plusformellementonobtient:

K={k:P, V, T, K →P, V, T, K|

∀(t, v)∈T ×V,∀p∈dom(v),

let(t⁰, v⁰) =k(t, v)

inv(p) =v⁰(p)

Pourpouvoirdénirplusformellementl'algorithme,considéronslesélémentssuivants:

A ^comme^l'ensemble^des^politiquesd'adaptationoùchaquepolitiqued'adaptationest unen- semblederèglesd'adaptationtelque:

A={ hRP, RAi }

oùRP ^est^l'ensemble^des^règlescongurativesRA^est^l'ensemble^des^règlesarchitecturales.On peut doncdénir l'opérateurde composition entre deux politiquesd'adaptation commeune

uniondesensemblesdepropriétés(enadmettantunrenommage)et uneuniondesensembles

derègles.Formellement,onobtient:

∀(f, g)∈A²

f⊗g=hRPF ∪RPG, RAF ∪RAGi

U êst ûne^fonction^qui âssocieûne ûtilitéâuxintro-actionsarchitecturales

U ={u:K→R}

control^est ^une^fonction^qui^représentel'algorithmedecontrôleou.Ellecalculeunenouvelle valeurpourchaquepropriétédel'architecturequ'elleareçueenparamètreetcalculeégalement

l'utilité dechaqueintro-actionarchitecturale.

control:P, V, T, K, A→V, U

select^est^une ^fonction^quisélectionnel'intro-actionarchitecturalelaplusutile.Elle retourne l'intro-action la plus utile s'il existe un maximum unique parmi les utilités associées aux

intro-actions. Si plusieurs intro-actions ont la même utilité, alors elle utilise une fonction σ

(commutative)poursélectionnerl'une desintro-actionsayantunevaleurd'utilitémaximale.

select : U →K select(u) =







k∈ max

ki∈dom(u) u(ki) max

ki∈dom(u) u(ki) = 1 σ

ki∈maxdom(u) u(ki) max

ki∈dom(u) u(ki) >1

où σ êst ûne ^fonction commutative qui sélectionne un élément parmi n^. Êlle ^rend âlors ^la

fonctionselectcommutativeégalement.

(7)

apply : P, V, T, K, A→P, V, T, K apply(p, v, t, k, a) =^let(v⁰, u)^becontrol(p, v, t, k, a)

in

letk0 ^beselect(u)

in k0(p, v⁰, t, k)

Onpeutalors démontrer quel'ordreparmilesrèglesn'apasd'importance etquel'opérateur

decomposition estbiencommutatif.Formellement,celasetraduitparl'équation suivante:

∀(p, v, t, k)∈(P×V ×T×K),∀(f, g)∈A² apply(p, v, t, k,hf, gi) =apply(p, v, t, k,hg, fi)

Considéronslestroiscassuivants:

Si (f, g)∈(RA)² ^alors,

apply(p, v, t, k,hf, gi) =^let(v⁰,{uf, ug})^becontrol(p, v, t, k, a)

in

letk0 ^beselect({uf, ug})

ink0(p, v⁰, t, k)

apply(p, v, t, k,hg, fi) =^let(v⁰,{ug, u_f})^becontrol(p, v, t, k, a)

in

letk0 ^beselect({ug, uf})

ink0(p, v⁰, t, k)

Danscesdeuxcasprécis,k0^prend^la^même^valeur^puisquel'opérationselect^estcommutative.

Si (f, g)∈(RP ×RA)^alors,

apply(p, v, t, k,hf, gi) =^let(vf, u_g)^becontrol(p, v, t, k, a)

in

letk0^beselect(ug)

in k0(p, vf, t, k)

apply(p, v, t, k,hg, fi) =^let(vf, ug)^becontrol(p, v, t, k, a)

in

letk0 ^beselect(ug)

in k0(p, vf, t, k)

Dans ces deux cas, l'opération select êst ûtilisée ^sur ^des ênsembles ^àûn ^seul ^élément êt k0

(8)

Si (f, g)∈(RP)² ^alors,

apply(p, v, t, k,hf, gi) =^let({vf, vg},∅)^becontrol(p, v, t, k, a)

in

letk0^beselect(∅)

in k0(p, v⁰, t, k)

apply(p, v, t, k,hg, fi) =^let({vf, vg},∅)^becontrol(p, v, t, k, a)

in

letk0 ^beselect(∅)

ink0(p, v⁰, t, k)

Nousconsidéronsiciquef^etg^ne^portent^pas^sur^les^mêmespropriétés.Danscecasparticulier, lafonction control ^produirait^une ^seule^valeur^pour^cette ^propriété ^(une^tendance ^moyenne)

et l'ordren'adoncpasnonplusd'inuenceici.

5 Implémentationpour la plate-forme Fractal

5.1 Du qualitatifvers lequantitatif

Pourpouvoirinterpréterlespolitiquesd'adaptationstellesquenouslesavonsmodélisées dansla

sectionprécédente,ilfautpouvoirlesinterpréteravecl'imprécisionqu'ellescomportent.Pourcela,

nousproposonsd'utiliserlathéoriedesensemblesouset sesapplications enthéorieducontrôle

pourinférerdesvaleursréellesàpartirdedescriptionsqualitatives.

En logiqueoue ([17]),les variablesappartiennentàdes ensembles ous. Laparticularité de

ces derniers,est que l'appartenanced'unevariable àunensemble n'estpas stricte(comme pour

lesensemblesclassiques) maisgraduelle. Un ensembleou est doncprincipalement déniparsa

fonction d'appartenance (généralement dénommé µ(x)⁾ êt ûne ^variable ^peut ^donc âppartenir ^à

unensemble à76%parexemple.Lagure2proposeune modélisationduterme low utilisépour

décrirelachargeduserveur.Dans notreapproche,chaquetermedénit danslevocabulaire d'un

domaineparticulierestassociéàunensembleou.

low

Req/s µ(x)

1

00 500

low (x<500)

Req/s µ(x)

1

00 500

A crisp set A fuzzy set

Fig.2.Déntiond'unensembleouetdel'ensembleclassiqueéquivalent

En plus des opérateurs de base que sont l'union et l'intersection, la logique oue introduit

égalementdesopérateursunaires(appelésmodicateurs)quipermettentdeconstruiredesexpres-

sionsplusprécises,telles queload ishigh orslightly medium.Lesprincipaux opérateurssontnot,

(9)

permettrededécriredesrèglesdecontrôledelafaçonlaplusintuitivepossible.Lesrèglespeuvent

être évaluées en trois étapes distinctes, respectivement: la fuzzication, l'inférence oue, et la

défuzzication.

Considéronsparexemplelesdeuxrèglessuivantespourillustrerl'évaluationderèglesqualita-

tives.Cesdeuxrèglessontégalementutiliséesdanslagure3.

1. loadismedium⇒^cacheSize^ismedium

2. loadislow⇒^cacheSize^islow

rule 1 : load is "medium" => cacheSize is "medium"

500

low medium

Req/s µ(x)

1

00

load = 300 µ(x) = 0.7

initial crisp value

high

MB µ(x)

1

00 5000

µ(x) = 0,7

rule 2 : load is "low" => cacheSize is "small"

T°

µ(x) 1

00 500

µ(x) = 0.35

MB µ(x)

1

00 5000

µ(x) = 0.35

MB µ(x)

1

00 5000

new crisp value DEFUZZIFICATION

FUZZIFICATION

small medium large

low medium high

load = 300 initial crisp value

small medium large

large

small medium

INFERENCE

Fig.3.Procédéd'évaluationdesrèglesoues

Lafuzzication Danslecasdesrèglesoues,ils'agitdemesurerledegréd'appartenanced'une

variable àun ensemble ou. Ons'intéresseà lapartie gauchedes règles:pourlarègle 1par

exemple, onvacalculer ledegré d'appartenancede lapropriété load àl'ensemblereprésenté

parletermemedium.Lagure3expliqueceladefaçongraphique:lachargeréelleestmesurée

à300req/setlafonctiond'appartenanceindiquequecettechargeest doncmedium à70%.

L'inférenceoue Cette notionconsiste àconsidérer quele degréd'appartenance mesuré dans

la partie gauche d'une règle peut être réutilisé tel quel dans sa partie droite. Par exemple,

puisque la fuzzication de la règle 1 aétabli que la charge est médium à 70%, le principe

d'inférenceouepermetdoncdedéduirequelatailleducacheseramedium à70%également.

Ladéfuzzication Unefoisquelafuzzicationetl'inférenceoueontétéappliquéessurtoutes

les règles,chaquepropriété peut prendreplusieurs valeursoues(oudegré d'appartenance).

Pour les deux règles utilisées dans la gure 3, la taille du cache est donc medium à 70%

(règle1)etlow à35%(règle2).Pourcalculerlavaleurréellecorrespondante(unequantitéde

mémoire), onagrègelesdeux aires correspondantes,et on calcule laprojectiondu centre de