Projet de fin d'études [E] 2012-2013 D1.2 Management (MGMT) Exploiting the Cloud to make sensor data collection scalable Participants : Robin Monjo, robinmonjo@gmail.com, SI5 / Architecture Logicielle Jeddi Kevin, jeddi.kevin@gmail.com, SI5 / Architecture Logicielle Olivia Florian, oliva.florian@gmail.com, SI5 / Architecture Logicielle Chabani Mohamed, chabani.mohamed.hadi@gmail.com, Master 2 IFI / AL Encadrants : Sébastien Mosser, mosser@polytech.unice.fr, (Université Nice-Sophia Antipolis, I3S UMR CNRS 7271 - Équipe MODALIS). Brice Morin, brice.morin@sintef.no, (SINTEF - Équipe MOD) François Fouquet, francois.fouquet@irisa.fr, (INIRIA Rennes - Équipe Triskell) Coût du livrable : 48 heures / étudiant. Budget total du projet : 304 heures / étudiant + 54 heures d encadrement.
Table des matières 1 - Description du projet...3 2 - Synthèse des résultats obtenus...4 3 - Implication des ressources...6 4 - Synthèse des livraisons...7 5 - Suivi budgétaire...9 5.1 - Consommation du budget...9 5.2 - Synthèse...9 6 - Suivi des lots...9 7 - Synthèse et retour d expérience...14 Exploiting the Cloud to make sensor data collection scalable Management - 2
1 - Description du projet Internet est devenu un outil du quotidien pour un grand nombre de personnes. Il permet d interconnecter et d accéder à un nombre infini de données numériques. Depuis quelques années, un nouvelle tendance émerge, l Internet of Things (IoT). Cette notion veut appliquer les concepts d internet aux objets du quotidien, c est-à-dire relier le monde concret au monde numérique. C est une évolution logique qui est rendu possible par l évolution des technologies de communication sans-fil et de la miniaturisation des composants permettant cette communication. L idée de l Internet of Things est donc d utiliser des capteurs 1 pour récolter des données sur les objets et de les utiliser comme n importe quelle ressource accessible en ligne. Un exemple concret aide à comprendre l intérêt et les enjeux de l IoT : Une entreprise de transport de marchandises veut à tout moment connaître la position de ses différents camions. Elle peut alors équiper chacun de ces camions avec une puce GPS. Les données de localisations produites par ces puces sont directement envoyées et gérées par le système d information de l entreprise. L IoT n en est actuellement qu à ses débuts. En janvier 2013, le consortium Iofthings 2 s est formé autour de ce concept, regroupant plusieurs grands acteurs tel que Logitech et d autres spécialistes de la domotique. Développé en collaboration avec le SINTEF d Oslo (norvégien pour Fondation pour la recherche scientifique et industrielle ), SensApp est une plateforme qui a pour but de fournir un système dédié à la récupération, la collecte et le traitement de données provenant de capteurs. Open-Source, cette plate-forme se base sur des standards afin de fournir la solution la plus flexible possible en terme d évolutivité. SensApp fournit différents services : 1 exemples de capteurs : GPS, accéléromètre, puces RFID, sismomètre, thermostat 2 http://www.iofthings.org/ Exploiting the Cloud to make sensor data collection scalable Management - 3
source: présentation SensApp Ce schéma représente les différents services offerts par SensApp : une interface pour collecter les données fournies par les capteurs, une base de données et un registre pour stocker et analyser les données et un service de notification qui envoie en temps réel les données envoyées par les capteurs aux systèmes concernés. L architecture technique de SensApp repose sur ces quatre services. L objectif du Projet de Fin d Études (PFE) était de vérifier et d améliorer la capacité de montée en charge de SensApp en termes à la fois du nombre de capteurs gérés et de leur fréquence d envoi, ainsi que du stockage des données. SensApp étant conçu pour le Cloud et basé sur des services, il est possible de déployer la plate-forme sur différentes machines. Le PFE impliquait donc plusieurs phases majeures : définir des scénarios de l utilisation ; tester la version actuelle de SensApp, où tous les services tournent sur une même machine ; mettre en place des topologies pour distribuer les différents services ; tester et valider ces topologies. Le projet a suivi une approche itérative impliquant ainsi différentes topologies et une liste de résultats obtenus. La finalité était d étudier différentes topologies et d exprimer pour chacune leur coût et leur performance. 2 - Synthèse des résultats obtenus # Nom de l objectif Statut 1 Assurer une qualité de service pour les utilisateurs de SensApp plus nombreux et un volume de capteurs plus important. non atteint 2 Rendre la plateforme capable de passer à l'échelle en non atteint Exploiting the Cloud to make sensor data collection scalable Management - 4
terme de montée en charge et d utilisations simultanées. 3 Rendre la plateforme capable de passer à l'échelle en terme d espace de stockage. atteint Objectif #1 : Assurer une qualité de service pour les utilisateurs de SensApp plus nombreux et un volume de capteurs plus important. Au cours du projet nous nous sommes heurté à un problème très gênant que nous n avions pas évoqué dans les risques possibles. Les technologies middleware utilisées dans SensApp (Spray et Akka) permettent techniquement une distribution sur plusieurs machines. Cependant, leur capacité à traiter un nombre important de requêtes simultanées est très limité. Ainsi, en voulant augmenter les capacités de SensApp en distribuant ses services sur différentes machines (afin d allouer plus de ressources pour chaque service) ne changeait rien à nos résultats, étant donné les difficultés rencontrées par le middleware en place. En revanche, nous avons clairement identifié les limites de SensApp et sommes donc en mesure de définir un contrat d utilisation qui assurera une qualité de service aux utilisateurs. De plus, nous avons également facilité les procédures de test et de déploiement en fournissant des scénarios utilisables par l outil de test Gatling, et des scripts réalisant des bancs de test. Enfin, nous avons créé des scripts permettant de provisionner des ressources pré-configurées avec nos nouveaux paramètres sur le Cloud et de les déployer automatiquement selon la topologie souhaitée par l organisation utilisant SensApp. Objectif #2 : Rendre la plate-forme capable de passer à l'échelle en terme de montée en charge et d utilisations simultanées. Comme évoqué précédemment, nous avons était limité par les technologies middleware en place qui nous ont empêché d atteindre cet objectif. Le projet nous imposait aussi l introduction d un middleware orienté Cloud issue de la thèse de François Fouquet, l une des personnes avec qui nous avons collaboré. La prise en main de ce middleware, Kevoree, s est avérée plus compliquée que prévu. En effet, son utilisation n est que très peu documentée et cette technologie reste encore au stade de beta et est très peu utilisée aujourd hui. Bien que les difficultés techniques étaient prises en comptes dans notre gestion du risque, Kevoree faisait partie du sujet et nous y avons donc consacré une grande partie de notre budget. Tout cela a créé un retard important dans le projet, nous avons donc manqué de temps pour intégrer Kevoree à SensApp bien que nous comptions sur ce nouveau middleware pour (entre autres) permettre le passage à l'échelle en terme de monté en charge. Cet objectif n est cependant pas un échec total, dans le sens où nos recherches nous ont permis de configurer finement les machines hôtes de SensApp, et nous avons augmenté les capacités initiales dans ce domaine. De plus, nous avons été en mesure de créer une preuve de concept à l aide de Kevoree, démontrant les possibilités de ce middleware et son utilisation potentielle au sein du projet SensApp. Objectif #3 : Rendre la plate-forme capable de passer à l'échelle en terme d espace de stockage. Exploiting the Cloud to make sensor data collection scalable Management - 5
Cet objectif a été atteint avec succès. Les critères de succès pour chaque objectif étaient : Critère 1 : Les topologies conçues gèrent bien les scénarios de cas d utilisation. Critère 2 : Livrables rendus en temps et en heure et approuvés. Critère 3 : Livrables utilisables et documentés (plan de déploiement, topologies). Nous avons fourni une topologie qui gère parfaitement l ajout d espace disque dynamique à SensApp (critère 1). La topologie est documenté et une procédure de déploiement est fournie. Étant donné que l introduction du passage à l'échelle en terme de stockage était prévue dans notre dernière itération, celle-ci a été rendue en respectant le planning initial. 3 - Implication des ressources Mohamed Chabani (étudiant, master IFI AL) A travaillé exclusivement sur Kevoree. Prise en main de la technologie (réalisation des tutoriaux) et a rédigé le rapport sur Kevoree. Livrables concernés : Rapport Kevoree, D1.3 Kévin Jeddi (étudiant, SI5 AL) A activement contribué aux tests de la version originale de SensApp. A dans un premier temps contribué à la définition des différents scénarios. Il a ensuite écrit les procédures et scripts de test pour la plateforme Gatling. A participé à la conception des architectures et à leur validation, et à l automatisation des procédures de déploiement des nouvelles topologies de SensApp. C est aussi beaucoup impliqué dans le suivi du projet. Livrables concernés : D1.3, D2.1, D3.1, D4.1, D5.1, D6.1, D1.2 Florian Oliva (étudiant, SI5 AL) A travaillé exclusivement sur Kevoree. Réalisation d une preuve de concept pour savoir si oui ou non l introduction de ce middleware serait bénéfique à SensApp. Livrables concernés : PoC Kevoree, D1.3, D6.1, D1.2 Robin Monjo (étudiant, SI5 AL) A contribué à la rédaction des scénarios puis au monitoring des machines lors des périodes de tests et validations. A participé à la conception des architectures et a leur validation, et il s est Exploiting the Cloud to make sensor data collection scalable Management - 6
notamment consacré sur la technologie MongoDB (base de donnée dans SensApp). Enfin, il s est aussi beaucoup impliqué dans le suivi du projet. Livrables concernés : D1.3, D2.1, D3.1, D4.1, D5.1, D6.1, D1.2 Sébastien Mosser (Université Nice-Sophia Antipolis, I3S (UMR CNRS 7271) - Équipe MODALIS) M. Mosser a été notre interlocuteur direct tout au long de ce projet, dont il a suivi de près le déroulement. Il a mis à notre disposition les outils à utiliser au début du projet, et nous a apporté une aide technique durant le projet. Il a été d une grande aide et s est beaucoup impliqué. François Fouquet (INRIA Rennes - Équipe Triskell - spécialiste Kevoree) M. Fouquet a été notre interlocuteur principal en ce qui concerne le middleware Kevoree, dont il est l un des développeurs principaux. Il nous a apporté une aide technique en répondant à nos questions, pour lesquelles la documentation actuelle n était pas suffisante. Brice Morin (SINTEF - Équipe MOD) M. Brice Morin est principalement intervenu au début du projet pour nous donner des conseils sur la réalisation des scénarios et la définition des cas d utilisation de SensApp. 4 - Synthèse des livraisons Livrable Nom du livrable Prévu Livré D1.1 Cahier des charges (DoW) D1.2 Rapport de management D1.3 Diaporama de présentation finale D2.1 Scénarios et résultats des tests sur la plateforme actuelle, et identification des problèmes (rédigé en anglais). Les versions en vertes S4 S20 S20 V1 : S6 V2 : S7 V3 : S16 V4 : S19 S4 S20 S20 V1 : S13 V2 : S14 V3 : S19 V4 : X Exploiting the Cloud to make sensor data collection scalable Management - 7
ont été livré dans un document à part: validation des architectures D3.1 Architectures adoptées (rédigé en anglais) D4.1 Implémentation de l architecture D5.1 Plan et script de déploiement (rédigé en anglais) D6.1 Démonstration de l architecture V1 : S7 V2 : S9 V3 : S18 V4 : S20 V1 : S7 V2 : S12 V3 : S19 V4 : S20 V1 : S7 V2 : S14 V3 : S19 V4 : S20 S20 V1 : S14 V2 : S19 V3 : X V4 : X V1 : S14 V2 : S20 V3 : X V4 : X V1 : S14 V2 : S20 V3 : X V4 : X S20 Nouveau livrable 1 rapport Kevoree - S20 Nouveau livrable 2 Preuve de concept Kevoree - S20 Comme nous pouvons le constater, nous avons eu du retard en général sur nos livrables. Avec du recul, nous pouvons l expliquer synthétiquement, sur le fait que, nous n avions pas prévu suffisamment de temps à la prise en main de l application existante (6 heures par personne n était pas suffisant). Nous n avions pas considéré le temps pris par la mise en place du monitoring (l activité de surveillance des machines). Les problèmes de middleware rencontrés nous ont aussi obligé à changer nos plans. Nous avons donc fait l impasse sur deux itérations afin de nous concentrer sur l identification de ces problèmes, et avons plus approfondi que prévu les activités de déploiement dans le Cloud. Exploiting the Cloud to make sensor data collection scalable Management - 8
5 - Suivi budgétaire 5.1 Consommation du budget figure 1 : consommation budget prévu / budget consommé 5.2 Synthèse De manière globale, le budget effectif correspond au budget prévu, en termes de temps de travail sur le projet. En revanche, le budget effectif sur les différents lots n est pas le même que celui prévu. Un exemple flagrant est le lot Étude de Kevoree qui s est avéré être une partie supplémentaire de l architecture, au même titre que la mise en place de topologie. Un grand écart de budget a donc pu être constaté pour cette tâche en particulier. 6 - Suivi des lots Lot 1 : Management du projet Les objectifs de ce lot sont : Exploiting the Cloud to make sensor data collection scalable Management - 9
Rédaction du cahier des charges : la rédaction de ce document permet à tous les participants et à tous les intervenants de connaître précisément chacune des tâches à effectuer pendant le projet et les ressources qui leur sont affectées. C est ce document qui sera utilisé pendant le projet pour déterminer la marche à suivre, et à la fin du projet pour en juger les résultats. Suivi du projet : le suivi du projet consiste notamment en des réunions régulières afin de suivre l avancement de chacun dans les tâches qui lui ont été attribuées, et ainsi pouvoir prendre les décisions adéquates en cas de problèmes. Tâche Description Budget Rapport budget T1.1 Planification du projet : la planification du projet est l étape initiale du projet, pendant laquelle l équipe et les intervenants vont s accorder sur les différentes tâches à effectuer pendant le projet, les outils à utiliser et les ressources à leur affecter. Cette planification aboutit à la rédaction du cahier des charges. T1.2 Suivi du projet : le suivi du projet consiste en des réunions régulières entre les participants au projet et les intervenants afin de tenir informées toutes les personnes impliquées de l avancement de chacune des tâches du projet. Le chef de projet peut alors prendre des décisions si des problèmes sont rencontrés pendant le déroulement du projet, qui seront consignées dans un rapport de management. 213 / 198 107% 45 / 117 38% Le suivi du projet a occupé moins de temps que ce que nous avions prévu. Cependant, nous nous sommes effectivement réunis régulièrement tout au long du projet, entre nous, et avec M. Mosser, afin de prendre des décisions sur la suite du projet. Lot 2 : Benchmarking, scénarios et tests Les objectifs de ce lot sont : Prise en main de l application : des tests seront menés par chaque participant afin de comprendre en détail comment l application fonctionne. Identifier les faiblesses de SensApp : une recherche d outils et de tests à effectuer sera menée, afin de déterminer les moyens à utiliser pour tester SensApp, et ainsi identifier ses limites. Exploiting the Cloud to make sensor data collection scalable Management - 10
Tâche Description Budget Rapport budget T2.1 Prise en main de l application : chacun des membres de l équipe doit avoir l occasion de tester l application afin d avoir une idée précise de son fonctionnement. T2.2 Benchmarking - Définition des outils : il faut définir quels sont les outils à utiliser pour les tests de SensApp, ainsi que les différents scénarios à mettre en place. T2.3 Définition des scénarios : définir des scénarios de cas d utilisation de la plateforme pour identifier les limites actuelles de l application. Les résultats de cette tâche seront consignés dans un document décrivant les scénarios choisis. T2.4 Tests de l application : il s agit ici d appliquer les scénarios identifiés durant la tâche précédente et de rapporter les résultats afin d identifier les scénarios problématiques. Les résultats sont consignés dans un document présentant les résultats, et les conclusions qui sont tirées à partir de ceux-ci. 54 / 24 225% 68 / 62 109% 103 / 61 168% 136 / 121 112% La phase de conception des tests et de création des scénarios était plus importante que ce que nous avions prévu, car c est une phase qui conditionne le déroulement de toute la suite du projet. Nous avons donc préféré y passer tout le temps nécessaire afin de s assurer de produire des analyses de qualité et de prendre les bonnes décisions pour la suite du projet. Lot 3 : Conception des architectures L objectif est de comprendre les technologies utilisées dans SensApp et d identifier leurs atouts dans la réalisation de l objectif d extensibilité de charge et d espace. Une topologie devra être retenue, documenté et justifiée. Tâche Description Budget Rapport budget T3.1 Étude de MongoDB : Comprendre le fonctionnement de MongoDB en mettant en avant les possibilités d extensibilité qu offre ce SGBD. 17 / 10 170% Exploiting the Cloud to make sensor data collection scalable Management - 11
T3.2 Étude de Kevoree : Comprendre Kevoree et identifier le rôle que cette technologie peut jouer au sein de SensApp, au niveau des échanges de messages. Cette partie comprend un dialogue avec M. François Fouquet en cas de questions sur Kevoree ou son utilisation. T3.3 Mise en œuvre de topologies : Concevoir plusieurs topologies basée sur les scénarios définis en tache T2.3, les documenter et les justifier. 326 / 35 931% 42 / 227 18% C est dans ce lot que se situent les plus grandes différences entre le budget prévisionnel et la consommation effective. L étude de Kevoree a finalement été un élément beaucoup plus important et critique que ce que nous pensions au début du projet. Il ne s agissait pas d un simple paramètre d architecture que nous aurions pu inclure aisément dans le projet après une brève phase d étude. Kevoree est un composant d architecture à part entière qui semble répondre aux besoins du projet, ainsi il a nécessité une étude particulièrement approfondie. En revanche, le manque de documentation nous a rendu dépendants de la communication avec M. Fouquet. Cela explique la différence colossale entre le budget prévisionnel et la consommation effective. De plus, la mise en œuvre des topologies dans le Cloud d Amazon a été plus simple que prévu, l utilisation des outils en ligne est accessible, et les ressources demandées sont mises à notre disposition très rapidement. Cette tâche a donc pris beaucoup moins de temps que nécessaire. Lot 4 : Implémentation des architectures cibles L objectif est de mettre en place les architectures retenues lors du lot 3, et de les déployer à l aide des technologies qui ont été étudiées et retenues dans les lots précédents. Tâche Description Budget Rapport budget T4.1 Mise en œuvre des nouvelles architectures pour SensApp : Cette tâche consiste à mettre en œuvre les topologies conçues durant le projet, sur un environnement de test, permettant de procéder plus tard à des tests. 20 / 145 14% Comme pour la tâche T3.3, lorsque les ressources dans le Cloud sont disponibles, les éventuels paramétrages qui doivent être faits ne prennent finalement pas beaucoup de temps, et le temps effectivement accordé à cette tâche est moins important que prévu. Exploiting the Cloud to make sensor data collection scalable Management - 12
Lot 5 : Déploiement et validation des architectures L objectif principal de ce lot est de mettre en place les nouvelles architectures qui ont été conçues auparavant, afin de vérifier leurs adéquations par rapport aux objectifs fixés en termes d extensibilité. Mettre en place les architectures Valider les architectures Tâche Description Budget Rapport budget T5.1 Déploiement des architectures cibles : A présent que des architectures solutions ont été conçues, il faut les déployer dans un environnement réel. T5.2 Validation de l architecture : Des tests similaires à ceux qui ont été effectués en début de projet doivent être conduits, afin de constater l évolution des résultats entre les tests de début de projet et ceux réalisés en fin de projet. 28 / 48 58% 55 / 138 40% L étape de validation s est avérée moins chère que prévu. En effet, une fois les bancs de tests réalisés, il n y a plus qu a les réutiliser. Aussi, étant donné que nous avons due réduire le nombre d itérations, nous avons eu moins de topologies à tester. Lot 6 : Préparation de la présentation des résultats L objectif est de présenter les résultats obtenus sur ce projet, de synthétiser le travail réalisé et soutenir les choix que nous avons faits durant le projet. Tâche Description Budget Rapport budget T6.1 Préparation de la démonstration : Préparation de la démonstration et des tests qui seront effectués lors de celle-ci. 60 / 84 71% Exploiting the Cloud to make sensor data collection scalable Management - 13
7 - Synthèse et retour d expérience Nous allons décrire les problèmes rencontrés durant le projet ainsi que les solutions qui ont été envisagées et apportées. De manière générale, nous avons été capables de réagir face à ces problèmes, même si ceux-ci ont retardé les différentes étapes de notre projet. Dans un premier temps, nous avions planifié une prise en main bien trop courte compte tenu du nombre de nouvelles technologies et ceci nous a un petit peu retardé dans notre avancée. Aussi, le lot benchmarking et scénarios était inclus dans les itérations alors qu il aurait dû s agir d une phase préalable et qu elle n aurait pas dû être séparée en plusieurs morceaux. Pour pallier à ces problèmes, nous avons pris la décision dans un premier temps de regrouper les différents morceaux du lot benchmarking et scénarios pour en faire une phase d étude complète. Et dans un second temps, nous avons pris la décision de réduire le nombre d itérations pour compenser le retard et le manque d une phase de prise en main. Par ailleurs, la prise en main de Kevoree et l implémentation des topologies (architecture hardware) auraient dû être des lots à part car ces deux points sont des éléments d architecture sans en être une solution globale qui répond à tous les problèmes. Ceci fut d autant plus problématique car la prise en main de Kevoree fut bien plus longue que prévue. En effet, l outil développé par M. François Fouquet n est malheureusement pas encore documenté et à chaque question ou étape dans le processus d implémentation du framework, nous devions directement contacté son auteur. Cela a donc retardé l avancée de cette activité et les ressources déployées pour celle-ci furent bien plus importantes que celles prévues. Un problème qui a considérablement ralenti le développement de nouvelles topologies est le résultat des tests de validation de la première topologie. Les performances n étaient pas à la hauteur des résultats attendus. Conformément à ce qui a été énoncé dans la gestion du risque, nous avons pris le temps d effectuer des tests supplémentaires pour déterminer l origine du problème. Nous avons finalement déterminé que le middleware Spray était la cause de ce problème de performance. Cela a rendu l intégration d un nouveau middleware, en l occurrence Kevoree, encore plus nécessaire et critique. Aussi, nous avons constaté que le monitoring, ou surveillance des machines durant les tests, est une activité qui demande des ressources pour le suivi en temps réel et la configuration des machines. Cela justifie le fait que le monitoring des tests aurait dû être une tâche à part entière dans le processus de notre projet. Le retard qui a été pris à cause des problèmes cités ci-dessus nous a empêchés de remplir complètement nos objectifs de passage à l échelle au niveau de la performance. En revanche, l analyse poussée que nous avons faite au niveau du middleware, des procédures de test et de déploiement constitue une base solide sur laquelle nous aurions pu nous appuyer pour remplir complètement ces objectifs si nous avions disposé d un budget supérieur. Exploiting the Cloud to make sensor data collection scalable Management - 14