L'élasticité du Cloud Computing au service de la météo agricole de précision - Isep
←
→
Transcription du contenu de la page
Si votre navigateur ne rend pas la page correctement, lisez s'il vous plaît le contenu de la page ci-dessous
L’élasticité du Cloud Computing au service de la
météo agricole de précision
Renaud Pawlak, Sylvain Lefebvre, Zakia Kazi-Aoul, Raja Chiky
LISITE - ISEP
28 rue Notre-Dame des Champs, 75006, Paris, France
Résumé—Dans cet article, nous décrivons une application mé- afin de tirer profit de leurs bénéfices à savoir la maîtrise
téo de précision dédiée à l’agriculture appelée CAP2020, qui fait des coûts, la réduction des risques de déni de services et
appel à des opérations d’interpolation nécessitant l’accès à des l’élasticité. Cette dernière nous permet d’ajouter des ressources
données massives. Nous expliquons l’implémentation centralisée
de cette application et montrons les limites de cette architecture. à la demande et de redimensionner le système en fonction des
Nous présentons ensuite une solution décentralisée pouvant être besoins de l’application. Dans le but de déployer CAP2020
déployée sur un Cloud qui assure la répartition de charge et sur un Cloud tel que EC2 [1], nous avons tout d’abord
la réplication des données afin de tirer profit des avantages revu l’architecture de CAP2020 pour la rendre distribuée et
de l’élasticité offerte par ce type d’architecture. Ceci nous facilement implémentable sur plusieurs machines. Pour cela,
permet d’assurer une qualité de service de l’application et son
passage à l’échelle en prévision d’une augmentation du nombre nous avons développé une architecture à base de réplication
d’utilisateurs et/ou des données nécessaires aux traitements mais et de répartition de charge. Nous expérimentons une politique
aussi de s’adapter aux besoins ponctuels et saisonniers des simple de répartition basée sur le Round Robin et la comparons
agriculteurs. à une architecture centralisée où les données se trouvent et sont
Index Terms—Cloud Computing, Web Services, répartition de traitées sur une seule machine. Nos expérimentations montrent
charge
que l’architecture distribuée avec répartition de charge permet
de réduire considérablement le temps d’exécution et d’assurer
M OTIVATION
la qualité de service quand le nombre de requêtes augmente.
Ces dernières années ont vu l’essor d’applications néces- Les techniques conventionnelles de répartition de charge
sitant d’importantes ressources informatiques afin de faire sont divisées en deux classes : centralisée et distribuée. Dans
face à des volumes de données constamment en croissance. le cas centralisé [2], la répartition de charge est décidée
De plus, les niveaux d’utilisation deviennent de plus en plus par un contrôleur unique qui communique avec l’ensemble
difficiles à prévoir, et les exigences de temps de réponse sont du système. L’avantage principal de cette approche est la
de plus en plus pressantes. Nous considérons dans cet article connaissance de l’état du système dans sa globalité, ce qui
la plate-forme CAP2020, une application réelle d’observations permet de mieux maîtriser la répartition de charge. Cependant,
et de prévisions météorologiques de précision dans le domaine l’approche centralisée est intrinsèquement difficile à passer
agricole. Cette plate-forme fournit des services d’aide à la à l’échelle. En effet, le contrôleur peut rapidement devenir
décision pour des agriculteurs sur le territoire français sur de un goulot d’étranglement, puisqu’il doit collecter et stocker
petites parcelles pouvant aller jusqu’à 1km × 1km (que nous les données provenant des noeuds de calcul qui lui sont
appelons aussi une grille). Cette plate-forme manipule des connectées. Les approches distribuées [3][4] permettent de
données éparses et massives provenant de plusieurs sources résoudre ce problème de goulot d’étranglement mais trouvent
hétérogènes. CAP2020 implémente un algorithme d’interpola- leur limite dès que le système contient beaucoup de machines
tion qui prend en entrée différentes données météorologiques et que l’environnement est très évolutif (change régulièrement
telles que la température, l’humidité du sol et de l’air, et la d’état). Un nouveau type de répartition de charge hybride a
direction du vent. Ces opérations d’interpolation nécessitent fait son apparition récemment [5] : les stations sont regroupées
de multiples accès à la base de données et aux systèmes de en classes, et chaque classe a un représentant. Une politique
fichiers, ce qui peut provoquer des goulots d’étranglement. de répartition de charge est appliquée de façon centralisée au
De plus, étant donné le caractère saisonnier du métier de niveau de chaque classe et une approche globale distribuée est
l’agriculteur, les besoins de ce dernier peuvent varier selon appliquée au niveau de chaque représentant des classes. Toutes
que l’on soit en période hivernale ou en période estivale. les méthodes existantes de répartition de charge ne prennent
En effet, les cultures sont plus répandues pendant l’été et la pas en compte l’élasticité dans l’architecture de l’application
nécessité de consulter les conditions météorologiques se res- qui est considérée figée. Nous nous démarquons de l’existant
sent plus pendant cette période. Augmenter les ressources de par la possibilité d’ajouter et d’enlever des ressources dyna-
l’application devient indispensable pour résoudre ce problème. miquement sans remettre en cause la politique de répartition
Néanmoins, ces ressources peuvent être inexploitées pendant de charge. De plus, la réplication des données nous permet
les périodes creuses où l’application est très peu sollicitée. Ce de prendre en compte l’élasticité du cloud et d’assurer une
constat nous pousse à étudier les solutions Cloud Computing continuité du service même en cas d’indisponibilité d’une ouplusieurs machines. 4) calculer la valeur des données de cette SMV en réalisant
Cet article est organisé comme suit : la section I détaille une moyenne des valeurs des quatre points pondérée par
l’algorithme d’interpolation locale et son implémentation sur les distances avec cette SMV (plus le point est proche
une machine centralisée et montrons quelques résultats sur les de la SMV, plus la pondération est grande).
performances ; afin de contrer les limites d’une interpolation Une fois la grille sélectionnée pour un agriculteur, les quatre
centralisée, nous introduisons dans la section II une architec- points les plus proches de la SMV s sont respectivement
ture distribuée avec un contrôleur maître et les esclaves qui lui appelés p0 , p1 , p2 , et p3 correspondant aux directions nord-est,
sont connectés et présentons les performances de l’application sud-est, sud-ouest et nord-ouest. Leurs distances de s sont d0 ,
répartie en comparaison avec la version centralisée ; enfin, dans d1 , d2 , et d3 , où
la section III, nous évaluons la solution déployée sur le Cloud p
en termes de performance et de coûts avant de conclure en di = (s.lat − di .lat)2 + (s.lng − di .lng)2
donnant nos perspectives de recherche.
.
I. L’ ALGORITHME D ’ INTERPOLATION LOCALE La station s pourrait être placée légèrement en dehors de
La fonction d’interpolation locale permet aux agriculteurs la grille. Dans ce cas, quelques points peuvent manquer dans
utilisateurs de la plate-forme CAP2020 d’accéder aux don- certaines directions. Rajoutons à cela le fait qu’un fournisseur
nées météo au plus proche de leur parcelles agricoles, en de données peut ne pas fournir certaines valeurs en temps et en
fonction des données globales disponibles. Cette fonction est heure. Une convention fixe cependant ces valeurs à −9999.99.
donc l’une des fonctions centrale de la plate-forme et peut Ainsi, pour des raisons de robustesse, nous utilisons l’équation
être extrêmement sollicitée. Dans cette section, nous étudions suivante, qui retourne la valeur interpolée vs pour un type de
son algorithme, son implémentation centralisée, et nous en données de s en fonction des valeurs vi de ce même type de
discutons les limitations. données de chacun des quatre points les plus proches et de
leurs distances di de s.
A. Présentation
Grâce à CAP2020, les agriculteurs peuvent créer des Sta-
v0 d1 d2 d3 + v1 d0 d2 d3 + v2 d0 d1 d3 + v3 d0 d1 d2
tions Météo Virtuelles (SMV) dans leurs champs leur permet- vs =
tant de consulter les observations (historique) et les prévisions b0 d1 d2 d3 + b1 d0 d2 d3 + b2 d0 d1 d3 + b3 d0 d1 d2
météo de manière très précise. Une SMV se caractérise par bi = 0 si pi n’existe pas ou vi n’est pas valide (-9999.99)
où bi = 1 sinon
une latitude et une longitude, et peut renseigner l’agriculteur
sur 12 types de données que nous listons dans la Table I. Ce calcul ne nécessite pas beaucoup de ressources en
TABLE I soit. En effet, le résultat de cette interpolation comprend
L ES TYPES DE DONNÉES MÉTÉO DISPONIBLES DANS LE SERVICE MÉTÉO 6×4×2×4+4+3+3+1 = 203 opérations à virgule flottante. A
CAP2020 noter que l’interpolation est généralement réalisée pour un jour
Type Unité Description
(une valeur par heure pendant 24h) et 12 types de données,
P mm/h Précipitations en millimètres par heure ce qui ramène le nombre d’opérations à virgule flottante à
T1_5 degrés celsius Température de l’air à 1,5 mètres 58 464 pour une interpolation journalière, c’est-à-dire 1,7
T0_1 degrés celsius Température de l’air à 10 centimètres
TS degrés celsius Température au sol
millions d’opérations à virgule flottante pour une interpolation
VV1_5 km/h Vitesse du vent à 1,5 mètres mensuelle, ce qui demeure raisonnable. Néanmoins, derrière
DV1_5 degrés Direction du vent à 1,5 mètres ce calcul théorique apparaissent des problématiques à traiter.
VV10 km/h Vitesse du vent à 10 mètres
DV10 degrés Direction du vent à 10 mètres Premièrement, l’interpolation suppose qu’une grille doit être
HR % Humidité relative choisie pour chaque utilisateur, chaque SMV et chaque type
R W/m2 Rayonnement global de données. Il faut aussi que les points les plus proches de
E mm/h Evapotranspiration
PR degrés celsius Point de rosée chaque SMV soient trouvés. Ainsi, pour une SMV donnée,
il arrive souvent qu’il y ait une grille différente suivant les
droits de chaque type de données (par exemple résolution
La plate-forme calcule donc les valeurs d’un ensemble de haute pour la pluie et résolution standard pour la vitesse du
type de données pour chaque SMV en utilisant différentes vent à 1,5m). Rajoutons à cela qu’il est possible de basculer
grilles. Ce calcul se traduit par une interpolation locale qui vers une autre grille si les données ne sont pas disponibles
consiste à suivre les étapes suivantes : sur la grille sélectionnée. Ces contraintes nécessitent un accès
1) Sélectionner la grille correspondante en fonction de efficace aux données des points proches.
la position de la SMV, des précisions autorisées de Deuxièmement, le système récupère chaque jour des mil-
l’agriculteur et des types de données à interpoler ; lions de lignes de données appartenant à différentes grilles
2) sélectionner les quatre points les plus proches de la SMV et provenant de différents fournisseurs. L’importation de ces
dans la grille sélectionnée ; données dans une base de données est une opération très
3) récupérer les valeurs des données demandées de ces coûteuse en temps et peut surcharger le système et l’empêcher
quatre points ; d’effectuer une interpolation efficace.Troisièmement, il existe en France environ 200 000 champs 3) Avec ces quatre valeurs, appliquer la formule d’interpo-
agricoles qui ont potentiellement besoin de récupérer le ré- lation présentée précédemment.
sultat de l’interpolation pour les données d’observation et A noter que la relation SMV.pointsProches est créée
de prévision (c’est-à-dire environ une semaine de données lors du premier accès. Les requêtes HQL qui recherchent
interpolées tous les jours). Ce chiffre ne tient pas compte des la première fois les points les plus proches sont assez
requêtes d’interpolation des agriculteurs qu’ils effectuent via simples. Par exemple, pour accéder au point p0 qui se
l’interface utilisateur. Ce qui implique qu’uniquement pour la trouve au nord-est, nous récupérons le premier résultat de
France, le système peut, dans un avenir très proche, interpoler la requête suivante : "select from Point p where
quotidiennement, environ 1,4 millions de jours. p.grid=g and p.latitude>=s.point.latitude
Dernière problématique, l’historique de toutes les interpo- and p.longitude>=s.point.longitude order by
lations aura besoin d’être recalculé si : p.longitude+p.latitude". Nous répétons la même
– une SMV venait à être déplacée ; requête pour les autres points en inversant à chaque fois
– les droits d’accès d’un agriculteur changent ; les signes de p.longitude et p.latitude dans la clause
– les grilles ou les stations qui influent directement sur "order by".
l’interpolation sont ajoutées ou supprimées du système.
Compte tenu de toutes ces problématiques, l’interpolation C. Performances et besoins en élasticité
d’une SMV dépend de plusieurs paramètres, et il n’est pas Afin de tester les performances de la fonction d’interpola-
facile de stocker les résultats dans une base de données tion, nous l’avons développée et rendue accessible via un Web
standard. Il est donc plus raisonnable de refaire les calculs à la service REST. Nous avons déployé ce service sur un serveur
demande, solution pour laquelle nous avons finalement opté. virtuel possédant les caractéristiques suivantes :
Dans les sections qui suivent, nous présentons l’implémenta- – Processeur : Intel Xeon 1,2 GHZ
tion de notre algorithme d’interpolation, puis nous évaluons – Mémoire : 1.7 Gb
ses performances. – Disque dur : 100GO
– système d’exploitation : Debian Linux 5.0
B. Implémentation centralisée Le programme de test est écrit en Java et lance des requêtes
Nous avons choisi d’implémenter l’interpolation locale à concurrentes pour simuler une charge d’utilisation du service
l’aide de techniques et technologies Web très largement uti- (un thread par requête REST). Ce programme tourne sur
lisées. Par conséquent, notre système de gestion de base de une autre machine afin de n’utiliser aucune ressource de la
données est MySQL et notre framework de programmation machine serveur qui réalise l’interpolation. Les deux machines
est GRAILS [6] qui offre une simplicité d’accès à la base se trouvent sur le même hébergeur afin de ne pas subir la
de données grâce à une couche de mapping objet-relationnel latence du réseau Internet.
transparente.
Pour éviter une surcharge de la base de données pour la 350
mise en oeuvre de notre service d’interpolation, nous avons 300
décidé de ne pas importer les données de la grille dans la 250
Temps (sec)
base de données. Seuls les points des grilles (leurs latitudes 200 Temps moyen
d'éxécu6on
et longitudes) et leurs positions dans les fichiers des mesures 150
(pour un accès rapide) sont stockés dans la base de données 100
MySQL car ces informations ne varient pas avec le temps. 50
Chaque fichier est un fichier binair et contient un entier qui 0
1 5 10 15 20 25 30 35 40 45
correspond au nombre de points de la grille et une liste de Nombre de de requêtes concurrentes
valeurs flottantes : les valeurs du type de donnée à un jour et
une heure précise pour chaque point de la grille. F IGURE 1. Les performances de l’interpolation sur 20 jours en mode
Pour réaliser une interpolation pour une SMV s, un type de centralisé
données t à une date d, à une heure h et à partir d’une grille
g, nous devons suivre le processus suivant :
La Figure 1 illustre les performances de l’interpolation sur
1) Chercher les points les plus proches de s un seul serveur (mode centralisé). Nous avons envoyé, pour
avec la relation s.pointsProches, tels que cette première série de tests, un certain nombre de requêtes
PointsProches.grille=g ;
concurrentes pour une interpolation sur 20 jours, et mesuré le
2) Pour chaque point proche pi : temps moyen nécessaire au serveur pour traiter une requête.
a) Ouvrir le fichier "g.cheminDonnees/d/g.nom- Comme le montre cette figure, le temps de traitement moyen
d-h-t.dat" ; d’une requête de 20 jours augmente de façon linéaire en
b) Faire un saut de pi.indexDansGrille × fonction du nombre de requêtes concurrentes et peut atteindre
sizeof(float) octets et lire la valeur flottante plusieurs minutes. Ce chiffre peut être mal perçu par les
qui se trouve à cette position. agriculteurs qui s’attendent à une certaine qualité de service.Afin de cerner les besoins en termes de performance, nous traitements parallèles massifs avec des exigences en terme de
avons fait une étude permettant d’estimer la sollicitation glo- capacités de calcul, d’espace de stockage et de bande passante.
bale du service d’interpolation. La caractéristique de ce service En particulier, la réplication est une solution efficace quand
est que la charge d’utilisation, et donc le nombre de requêtes les données sont accessibles en lecture seule (pas de mises à
peut varier de manière très importante d’une période à une jour des données ou pas de besoin de cohérence forte), ce
autre dans l’année. Comme le montre la figure 2, le nombre qui est le cas de notre étude dans le cadre de cet article.
d’interpolation augmente pendant la campagne agricole qui De plus, avec l’apparition et la démocratisation du Cloud
s’étale de février à octobre avec deux pics significatifs corres- Computing, le déploiement de ces solutions devient accessible
pondant aux semis et aux récoltes, là où les activités agricoles à toute application à des prix très abordables [1], ce qui justifie
doivent être synchronisées au mieux avec la météo. Le nombre notre étude en prenant en compte les attentes et exigences de
d’interpolation est par contre quasiment inexistant en période CAP2020.
hivernale. Mettre en place des ressources supplémentaires pour
pallier les périodes de sur-demande des agriculteurs implique A. Cloud Computing et EC2
que ces ressources ne soient pas utilisées sur toute la période Bien que difficile à définir, le Cloud Computing fait réfé-
de l’année. Il est donc plus judicieux de définir une politique rence selon [8] aux applications fournies en tant que services
d’optimisation de l’utilisation des ressources (élasticité) en à travers Internet ainsi qu’aux machines et logiciels dans
fonction de la demande et des besoins. L’élasticité est la les datacenters qui permettent d’offrir ces applications. Nous
capacité d’un système à s’adapter aux dimensions du problème pouvons également définir le Cloud Computing comme un
qu’il a à traiter c’est-à-dire que la puissance de calcul, la mé- ensemble de nouvelles technologies reposant sur une plate-
moire ou le stockage utilisés par le système peuvent facilement forme de Grid Computing et offrant, suivant le type de Cloud,
être augmentés ou diminués en fonction des besoins. des fonctionnalités telles que la virtualisation, la tolérance aux
pannes, l’interopérabilité, le stockage ou encore la sécurité.
40 Dans le monde du Cloud Computing, tout peut être vu
35 comme un service (XAAS : X As A Service) : une plate-forme
30 (PAAS), un logiciel (SAAS) ou encore une infrastructure
25 (IAAS).
20 Les SAAS (Software As A Service) représentent le plus
15 Requêtes haut niveau de services offerts par un Cloud. Des services tels
d'interpolaAons
10
que Gmail [9] et GoogleDocs [10] de Google font partie de
5
cette famille de Cloud.
0
Les PAAS (Platform As A Service) offrent quant à eux la
possibilité aux utilisateurs de développer, tester, déployer et
s
ril
t
pt ût
oc re
ve re
ce re
e
in
r
fé r
ai
ille
ie
ar
ie
br
ju
av
b
no tob
Dé mb
se ao
m
vr
nv
m
em
m
ju
héberger leurs applications au sein du Cloud d’un fournis-
ja
seur donné. Ces plate-formes permettent la plupart du temps
de faire tourner des applications d’entreprises. Google APP
F IGURE 2. Nombre d’interpolation dans l’année mois par mois
Engine [11] ou Microsoft Azure [12] sont des exemples de
PAAS.
Dans les sections qui suivent, nous expliquons comment Les IAAS (Infrastructure As A Service) offrent un niveau
améliorer notre système en profitant de l’élasticité du Cloud d’abstraction qui permet aux utilisateurs d’accéder à des
Computing qui permet également de répartir la charge de ressources matérielles et d’y installer les images des systèmes
l’algorithme d’interpolation. d’exploitation de leur choix, ce qui leur permet de s’affranchir
des problématiques de maintenance matérielle (achat et instal-
II. I NTERPOLATION DISTRIBUÉE SUR EC2 lation de serveurs, maintenance des baies de stockage, équi-
L’objectif de cette section est de présenter la nouvelle archi- pements réseaux, climatisation des salles machines, etc.). EC2
tecture distribuée de l’application en utilisant des techniques (Elastic Cloud Computing) d’Amazon [1], Eucalyptus [13] et
de répartition de charge, de réplication des données avec une Nimbus ToolKit [14] font partie de cette catégorie de Cloud.
possibilité d’allouer et de libérer des ressources à la demande, La plate-forme EC2 d’Amazon [1] semble être la plate-
ce qui peut se faire plus simplement de nos jours grâce aux forme la plus mature à ce jour pour les services de type
plate-formes de type Cloud. La répartition de charge avec la IAAS. Cette plate-forme permet de louer dynamiquement
réplication des données sont des solutions éprouvées qui nous des machines virtuelles facturées à l’heure. Le coût horaire
permettent d’augmenter le CPU et la mémoire disponibles dépend à la fois de la puissance brute de la machine virtuelle
pour les traitements avec très peu d’efforts d’implémentation. sélectionnée ainsi que de la famille du système d’exploitation
Dans les architectures Web, cette solution a été utilisée pour choisi. A cela il faut ajouter des coûts supplémentaires par
améliorer l’évolutivité et le passage à l’échelle des appli- mois pour le nombre de giga-octets utilisés ainsi que le nombre
cations [7]. La réplication des données est aussi largement d’opérations d’entrées-sorties effectuées. Le tableau II montre
utilisée dans le Grid Computing permettant d’assurer des des exemples de configurations disponibles. L’instance parTABLE II
C ARACTÉRISTIQUES DES INSTANCES EC2
Quantité de Unités de cal- Espace Disque Performance
Type Plateforme
Mémoire (Go) cul EC2 (CPU) (Go) E/S
m1.small 1.7 1 160 32 bit Modérée
m1.large 7.5 4 850 64 bit Elevée
m1.xlarge 15 8 1 690 64 bit Elevée
t1.micro 613 Mo 2 10 32 ou 64 bits Basse
défaut est de type m1.small. Sa configuration est similaire à du portail (interface graphique WEB, gestion des données,
celle du serveur décrit en section I-C. Pour les coûts EC2 etc.) à l’exception de l’interpolation. Quand cette opération est
relevés début 2011, on pourra se référer au tableau III. requise soit par une requête client ou par une tâche récurrente,
elle est envoyée via un Service Web REST à un contrôleur qui
B. Architecture et mise en oeuvre a la charge de la répartir sur les différents noeuds qui lui sont
connectés. Les différents noeuds servant à l’interpolation sont
également appelés "esclaves" dans ce qui suit.
Poste client
agriculteur /
Chaque noeud esclave se connecte à la base de données
administrateur installée localement sur le serveur CAP2020 afin d’accéder
aux informations requises pour l’interpolation, qui concernent
les points et la grille. Chaque noeud accède également aux
fichiers de données, répliqués eux aussi. Comme les données
sont en lecture seule, la réplication des fichiers est simple à
réaliser manuellement grâce à rsync [15], ou en utilisant un
système de fichier partagé de type NFS [16], ou HDFS [17].
Portail CAP 2020 BDD (MySQL) A des fins de tests, nous avons développé un intergiciel
Java pour la couche de répartition de charge (load balancer).
Nous aurions pu utiliser le service de répartition intégré à EC2,
Répartiteur mais ce dernier est payant et propose en plus des fonctions
de charge de tolérance aux pannes inutiles pour notre phase de test.
équilibrage Pour nos premières expérimentations, nous avons donc préféré
de charge
HTTP mettre en oeuvre manuellement une politique simple de type
Round Robin pour une répartition de charge équitable entre
les noeuds. Ainsi chaque noeud traite le même nombre de
requêtes en moyenne.
Web service
Web service
d'interpolation
....... d'interpolation
répliqué répliqué C. Déploiement sur EC2
Nous avons mis au point notre propre image machine
Amazon (AMI) de machine virtuelle contenant les logiciels
CAP2020, le SGBD Mysql et notre service de répartition
de charge. Ces composants ont été installés sur un système
Données météo Données météo
répliquées répliquées Linux Debian 5.0 "Lenny". L’utilisation des images machine
(système de fichiers) (système de fichiers)
Amazon permet de déployer un système personnalisé sur les
EC2 différents types d’instances fournis par Amazon, pour peu que
l’architecture (32 ou 64 bit) soit la même. Nous pouvons donc
déployer une grappe de serveurs pour répartir la charge de
notre service d’interpolation.
F IGURE 3. Architecture de l’interpolation avec répartition de charge
Nous avons choisi de réaliser des tests sur 7 machines
virtuelles :
Pour pouvoir profiter des atouts du Cloud Computing et de – 1 machine faisant office de client, de type t1.micro, char-
la plate-forme EC2, il est nécessaire d’adapter le logiciel et gée de lancer les requêtes d’interpolation et de mesurer
son architecture pour permettre des changements d’échelle les les temps de réponse,
plus transparents possibles. Cela passe donc par la mise au – 1 machine "maître" de type m1.small, éxécutant MySQL,
point d’une architecture répartie. CAP2020 et le répartiteur de charge,
La figure 3 montre l’architecture décentralisée que nous – 5 machines "esclaves" de type m1.small éxécutant le
avons mise en oeuvre pour assurer la répartition de charge. service CAP2020
Le serveur CAP2020 s’occupe de toutes les tâches habituelles La configuration des services sur les machines esclaves se70 7000
fait de manière automatisée via le lancement par l’adminis-
60 6000
trateur de scripts permettant de répliquer la configuration sur
temps d'éxécu4on (sec)
50 5000
tous les noeuds.
Nombre d'E/S
40 4000
Temps d'éxécu7on
III. E VALUATION 30 3000
E/S par requête
Nous allons maintenant évaluer la plate-forme CAP2020, 20 2000
d’abord en termes de performances par rapport à une version 10 1000
centralisée, puis sur son rapport performance / coût pour une 0
1 2 3 4 5 6 7 8 9 10 11
0
qualité de service donnée. Nous avons effectué nos expérimen- Appels
tations avec les mêmes conditions que dans la section I-C afin
de comparer les performances du cas centralisé (maître seul) F IGURE 5. Relation entre nombre d’entrées/sorties et temps d’éxécution
et du cas décentralisé avec répartition de charge (un maître et
5 noeuds esclaves). TABLE III
TABLES DES COÛTS D ’A MAZON EC2 EN $
A. Performance
Type de coût Catégorie prix (en $)
La figure 4 montre l’évolution des performances en fonc- m1.small 0,095
tion du nombre de requêtes d’interpolation sur 20 jours qui m1.large 0,38
Heure d’instance
m1.xlarge 0,76
sont envoyées concurremment. Le graphique montre que la t1.micro 0,025
répartition de charge devient de plus en plus intéressante au Go de stockage / mois 0,11
Stockage de données
fur et à mesure que le nombre de requêtes augmente. Après Million de requêtes d’E/S 0,11
40 requêtes, le temps d’exécution dans le cas distribué est Go entrant 0,10
Transferts de données
Go sortant de 1 Go à 10 To 0,15
trois fois plus rapide que dans le cas centralisé. Ce résultat est
positif pour CAP2020, car il permet d’envisager une meilleure
montée en charge du système dans l’avenir. Toutefois, nous
n’avons pas pris en compte le coût économique de la mise en de serveurs, ainsi que les coûts de gestion des données. Nous
place d’une telle architecture distribuée. Il est donc intéressant allons évaluer le coût global mensuel de la plate-forme.
d’étudier ce coût afin de trouver un compromis entre le gain Nous définissons le coût mensuel de fonctionnement d’une
en temps d’exécution et le coût que cela engendre. instance de serveur Cf tel que le nombre d’heures par mois
multiplié par le coût horaire Ci du type de serveur sélectionné
350
(voir tableau III). En conséquence Cf (n) est défini comme
300
le coût de fonctionnement mensuel de la plate-forme pour n
machines équivalentes de coût horaire Ci .
Temps d'éxécu-on (sec)
250
Les coûts de gestion des données comprennent les coûts
200 Temps client sur 5 noeuds
Temps moyen d'éxécu:on
suivants :
150
– un coût de stockage Cs : $0,11 par giga-octet provisionné
100
et par mois,
50 – un coût d’utilisation des disques Cd : $0,11 par million
0 d’Entrées / Sorties disque,
1 5 10 15 20 25 30 35 40 45
Nombre de requêtes concurrentes – un coût de transfert descendant depuis Internet sur un
serveur EC2 Ct : $0,10 par giga-octet,
F IGURE 4. Interpolation sur 20 jours : centralisée (1 serveur) v.s. distribuée – un coût de transfert montant depuis un serveur EC2 vers
(5 esclaves)
Internet Ctm : $0,15 par giga-octet (nous ne prendrons
pas en compte ce coût pour la suite : il est de toute ma-
La performance est aussi influencée par le nombre d’en- nière le même en mode centralisé et en mode distribué).
trées/sorties nécessaires pour lire les fichiers de données cor- Dans son fonctionnement normal, le serveur CAP2020
respondant à la requête. La figure 5 montre une augmentation télécharge tous les matins 700 Mo de données par FTP, pour
importante du temps d’exécution lorsque des requêtes d’E/S mettre à jour ses grilles. Cet import de données génére des
sont effectuées. La politique de répartition de charge pourrait coûts : de stockage, d’Entrées / Sorties et de téléchargement.
prendre en compte l’influence des accès disques et du cache Le coût du téléchargement est constant, étant donné que la
ce qui permettrait d’améliorer les performances. Néanmoins, quantité de données importée ne varie pas. La somme des
cela dépasse le cadre de cet article et sera étudié dans nos imports par mois représente 700×301024 = 20, 5 Go que nous
futurs travaux. arrondissons à 21 Go, pour obtenir un coût mensuel de
téléchargement Ct = 21 × 0, 10 = $2, 1. Etant donné que
B. Evaluation des coûts sur EC2 les transferts entre machines EC2 ne sont pas facturés, dans
Dans le coût global de la plate-forme, nous prenons en le cas distribué nous préférons effectuer le téléchargement une
compte à la fois les coûts de fonctionnement des instances fois sur le serveur maître, puis répliquer les données sur lesmachines esclaves. semis et de récoltes, qui sont les plus importantes pour les
Pour évaluer Cd , nous estimons à travers différentes me- agriculteurs, bénéficient d’une qualité de service optimale. Les
sures effectuées avec l’outil Linux "vmstat" le nombre d’En- coûts sont bien entendu plus importants et sont calculés à partir
trées/Sorties nécessaires pour copier 700Mo de données à de la formule Cm (n, T ) du tableau IV.
40000, ce qui nous donne pour un mois d’utilisation :
40000 × 30 = 1200000. Les E/S disque sont facturées au 1000 600
million, ce qui nous donne un coût mensuel par machine 900
1200000 500
de : Cd = 1000000 × 0, 11 = $0, 132. Dans le cas distribué, 800
700
le coût mensuel d’utilisation des disques est donc défini par 400
600 Coût mensuel en $
Cd (n) = 0, 132 × n. 500 300
Le coût de stockage mensuel, sachant que la plate-forme 400
importe 21 Go par mois, est donné par Cs = 0, 11 × 21 = 200
300 Temps d'exécuFon
$2, 31. Ce coût se cumule tous les mois. Nous avons donc 200 moyen d'une requête
100
(sec)
Cs (T ) = $2, 31×T . Avec T le nombre de mois écoulés. Dans 100
0 0
le cas distribué, étant donné que les données sont répliquées
mars
avril
septembre
juin
octobre
Décembre
juillet
août
novembre
janvier
février
mai
sur tous les noeuds, nous avons : Cs (n, T ) = 2, 31n+2, 31nT .
L’ensemble des coûts est résumé par le tableau IV.
C. Compromis coût / performance
F IGURE 7. Performance et coût d’une solution hybride
En fonction des contraintes de coût et de performance nous
pouvons grâce à l’élasticité du Cloud dimensionner le système
quasiment au jour le jour, pour optimiser la qualité de service. C ONCLUSION
Pour ce faire, il suffit de calculer le temps de réponse voulu Cet article présente une étude comparative de deux ar-
en fonction du trafic estimé (voir figure 2) et des temps de chitectures pour une application réelle de météo agricole
réponses mesurés en fonction des nombre de noeuds (voir de précision. L’une est centralisée pour les données et les
figure 4). traitements d’interpolation. L’autre est distribuée et permet de
Par exemple, si la contrainte de coût est très forte, on répartir les traitements d’interpolation sur plusieurs machines
pourra choisir de n’utiliser qu’un seul noeud tout au long esclaves avec une réplication des données. Nous avons déployé
de l’année. Dans ce cas le coût sera égal à Cm (T ) comme notre architecture sur EC2, avec une réplication de charge
expliqué à la section précédente. Il s’agit donc d’un coût avec simple de type Round Robin, puis nous avons étudié les
une partie constante (2, 1 + 0, 132 + 68, 4 = $70, 632) et une performances et coûts associés. Notre étude montre qu’il est
partie variable augmentant tous les mois de $2, 31. Cette partie possible d’utiliser l’élasticité du Cloud EC2 pour ajuster la
variable correspond au stockage des données. Cette solution qualité de service en jouant sur le ratio coût / performance.
donne lieu à des performances moyennes indiquées figure 6. Bien que les résultats de cet article montrent clairement
que la répartition de charge avec réplication des données
2500 120 est une approche qui fonctionne bien pour notre application
météorologique, nous continuons à travailler pour améliorer
2000 100
son efficacité et la maîtrise des coûts pour le client final. Un
80 de nos efforts actuels est d’étudier l’impact du cache dans
1500 Temps d'exécuAon
60 moyen d'une requête les performances des architectures répliquées. En effet, nous
1000 (sec) avons remarqué lors de nos expérimentations que le temps
40
Coût mensuel en $ d’exécution de l’interpolation augmente largement quand les
500 20 entrées/sorties liées à la mise en cache des données augmentent
(figure 5). Nous commençons à étudier l’état de l’art autour
0 0
de la prise en compte du cache [18][19][20] pour la répartition
mars
avril
septembre
juin
juillet
août
octobre
novembre
Décembre
janvier
février
mai
de charge dans les grilles de calcul [21][22]. L’optimisation
du cache ayant un impact direct sur les entrées/sorties et le
temps d’exécution, elle aura donc un impact direct sur le coût
F IGURE 6. Performance et coût d’un seul serveur à l’année final facturé par EC2 à CAP2020.
Un autre axe de recherche concerne la réécriture du pro-
On peut cependant choisir de réduire le temps d’exécution gramme d’interpolation pour tirer profit du framework Map-
en période de charge afin d’améliorer la qualité de service. Un Reduce [23]. Map-Reduce est un cadre de développement
scénario possible consiste à utiliser 5 noeuds répliqués pour permettant de distribuer les traitements nécessitant l’accés à
les mois de mars, avril, septembre et octobre, comme illustré des données volumineuses sur plusieurs machines esclaves.
figure 7. Pour cette solution on voit que le temps moyen par L’utilisation de Map-Reduce nécessite de modifier l’implé-
requête n’excède jamais 800 secondes et que les périodes de mentation de l’interpolation selon deux étapes : 1/ Map quiTABLE IV
C OÛTS DE LA PLATE - FORME CAP2020 SUR EC2, EN $ PAR MOIS
Mode Catégorie Calcul du prix
Coût de fonctionnement Cf = 24 × 30 × Ci
Centralisé
Coût de transfert descendant Ct = 21 × 0, 10 = $2, 1
30×40000
Coût en E/S Cd = 1000000
× 0, 11 = $1, 2
Coût de stockage (fonction du temps) Cs (T ) = $2, 31 × T
Coût de fonctionnement mensuel Cm (T ) = Cs (T ) + Cd + Ct + Cf
Réparti, avec n Coût de fonctionnement Cf (n) = 24 × 30 × Ci × n
le nombre de
machines Coût de transfert descendant Ct
Coût en E/S Cd (n) = 0, 132 × n
Coût de stockage (fonction du temps) Cs (n, T ) = 2, 31n + 2, 31nT
Coût de fonctionnement mensuel Cm (n, T ) = n(Cd + 2, 31 + 2, 31T + Cf ) + Ct
découpe le problème en sous-problèmes afin de les déléguer [15] A. Tridgell, “Efficient algorithms for sorting and synchronization,” Ph.D.
aux esclaves, 2/ Reduce permettant d’agréger les résultats de dissertation, The Australian National University, February 1999.
[16] S. Shepler, B. Callaghan, D. Robinson, R. Thurlow, C. Beame, M. Eisler,
la première étape et retourne le résultat final. Z. Inc, and D. Noveck, “Nfs version 4 protocol,” 2000.
[17] K. Shvachko, H. Kuang, S. Radia, and R. Chansler, “The hadoop
R ÉFÉRENCES distributed file system,” Mass Storage Systems and Technologies, IEEE
/ NASA Goddard Conference on, pp. 1–10, 2010.
[1] Amazon, “Amazon elastic compute cloud (amazon ec2),” http://aws. [18] D. Dominguez-Sal, M. Perez-Casany, and J. Larriba-Pey, “Cache-aware
amazon.com/ec2/. load balancing vs. cooperative caching for distributed search engines,” in
[2] L. M. Ni and K. Hwang, “Optimal load balancing in a multiple High Performance Computing and Communications, 2009. HPCC ’09.
processor system with many job classes,” IEEE Trans. Softw. 11th IEEE International Conference on, 2009, pp. 415 –423.
Eng., vol. 11, pp. 491–496, May 1985. [Online]. Available : [19] U. Rohm, K. Bohm, and H.-J. Schek, “Cache-aware query routing in
http://portal.acm.org/citation.cfm?id=1313334.1313724 a cluster of databases,” in Data Engineering, 2001. Proceedings. 17th
[3] A. Corradi, L. Leonardi, and F. Zambonelli, “Diffusive load- International Conference on, 2001, pp. 641 –650.
balancing policies for dynamic applications,” IEEE Concurrency, [20] K. O’Gorman, D. Agrawal, and A. El Abbadi, “Multiple query opti-
vol. 7, pp. 22–31, January 1999. [Online]. Available : http: mization by cache-aware middleware using query teamwork,” in Data
//portal.acm.org/citation.cfm?id=614064.614137 Engineering, 2002. Proceedings. 18th International Conference on,
[4] L. V. Kalé, “Comparing the performance of two dynamic load distribu- 2002, p. 274.
tion methods,” in ICPP (1), 1988, pp. 8–12. [21] S. Jiang and X. Zhang, “Efficient distributed disk caching in data grid
[5] G. Zheng, “Achieving high performance on extremely large parallel ma- management,” Cluster Computing, IEEE International Conference on,
chines : performance prediction and load balancing,” Ph.D. dissertation, p. 446, 2003.
Champaign, IL, USA, 2005, aAI3202198. [22] E. Otoo, F. Olken, and A. Shoshani, “Disk cache replacement algorithm
[6] SpringSource, “Grails, the search is over,” http://www.grails.org/. for storage resource managers in data grids,” in Proceedings of the
[7] M. Baentsch, L. Baum, G. Molter, S. Rothkugel, and P. Sturm, “En- 2002 ACM/IEEE conference on Supercomputing, ser. Supercomputing
hancing the web’s infrastructure : from caching to replication,” Internet ’02. Los Alamitos, CA, USA : IEEE Computer Society Press, 2002,
Computing, IEEE, vol. 1, no. 2, pp. 18 –27, 1997. pp. 1–15. [Online]. Available : http://portal.acm.org/citation.cfm?id=
762761.762824
[8] M. Armbrust, A. Fox, R. Griffith, A. D. Joseph, R. H. Katz,
A. Konwinski, G. Lee, D. A. Patterson, A. Rabkin, I. Stoica, [23] J. Dean and S. Ghemawat, “Mapreduce : Simplified data
and M. Zaharia, “Above the clouds : A berkeley view of cloud processing on large clusters,” OSDI, p. 13, 2004. [Online]. Avai-
computing,” EECS Department, University of California, Berkeley, lable : http://static.googleusercontent.com/external_content/untrusted_
Tech. Rep. UCB/EECS-2009-28, Feb 2009. [Online]. Available : dlcp/labs.google.com/de//papers/mapreduce-osdi04.pdf
http://www.eecs.berkeley.edu/Pubs/TechRpts/2009/EECS-2009-28.html
[9] Google, “Gmail,” http://www.gmail.com/.
[10] ——, “Google docs,” http://www.googledocs.com/.
[11] ——, “Google app engine,” http://code.google.com/appengine.
[12] Microsoft, “Microsoft azure,” http://www.microsoft.com/azure/.
[13] D. Nurmi, R. Wolski, C. Grzegorczyk, G. Obertelli, S. Soman,
L. Youseff, and D. Zagorodnov, “The eucalyptus open-source cloud-
computing system,” in Proceedings of the 2009 9th IEEE/ACM
International Symposium on Cluster Computing and the Grid, ser.
CCGRID ’09. Washington, DC, USA : IEEE Computer Society, 2009,
pp. 124–131. [Online]. Available : http://dx.doi.org/10.1109/CCGRID.
2009.93
[14] P. Marshall, K. Keahey, and T. Freeman, “Elastic site : Using clouds
to elastically extend site resources,” Cluster Computing and the Grid,
IEEE International Symposium on, pp. 43–52, 2010.Vous pouvez aussi lire
