Network Efficiency Monitoring - version 2

Transcription

1 École Polytechnique de l Université de Tours 64, Avenue Jean Portalis TOURS, FRANCE Tél. +33 (0) Département Informatique 5 e année Projet de fin d études Network Efficiency Monitoring - version 2 Encadrants Alexandre LISSY alexandre.lissy@etu.univ-tours.fr Université François-Rabelais, Tours Version du 30 avril 2013 Étudiants Albin POIGNOT albin.poignot@etu.univ-tours.fr DI

2 Remerciements Je souhaite remercier mon encadrant, Alexandre LISSY, pour son soutien et sa réactivité tout au long du projet. Il a su apporter un encadrement efficace et a toujours permis de s adapter aux imprévus. Je souhaiterais également remercier Martin pour sa bonne humeur et son entrain qui m ont aidé à continuer dans les moments les plus compliqués. Merci également à Abdelnor, notamment pour m avoir rappeler les raisons pour lesquelles je travaillais sur ce projet et celles qui font que j étudie à Polytech Tours. Je remercie aussi Matthieu ANCERET et Sébastien GUILLON pour le travail qu ils ont mené en parallèle de ce projet et qui m a aidé à me rendre compte de certains problèmes. Je remercie Patrick MARTINEAU, enseignant chercheur à Polytech Tours, et Matthieu BRETAUD pour m avoir permis de travailler sur leur cluster. Enfin, je remercie Florian, Julien, Matthieu, Damien, Abdelnor et Martin pour les réunions chaque midis. NetEffMon v2 II

3 Table des matières 1 Présentation du projet Le but général L existant Les problématiques existantes NoSQL : une solution possible PostgreSQL + PostGIS HBase Pourquoi un système NoSQL? Qu est-ce que HBase? HDFS Hadoop Pourquoi HBase? Fonctionnement global de HBase Stockage des données Conseils de modélisation Accès aux données Fonctionnement de Stargate Récupération de la liste des tables Ajout d une donnée dans la table Ajout de plusieurs données dans la table Récupérer une seule donnée Récupérer plusieurs données Filtrage des données Suppression d un point Problèmes de sécurité La migration Architecture du code NetEffMon Processing Module (NPM) Structure des données StargateHelper Méthode de parsing API privée Principe de récupération de points Regroupement des points Ajout d un fichier de mesure NetEffMon Client Module (NCM) API publique Front-end Résolution des problèmes Amélioration de la latence de la page d accueil NetEffMon v2 III

4 TABLE DES MATIÈRES TABLE DES MATIÈRES 3.4 NetEffMon Mobile Module (NMM) L application Android Le web-service Résultats obtenus Performances Ajout des points dans la base de données Montée en charge sur les requêtes en lecture Evolutions à venir Remarques et critiques Gestion de projet Outils et techniques utilisés Gestion des dépendances : Maven Gestion des sources et des versions : Git Utilisation de Git Gestion du temps Scrum Le déroulement du projet Construction d une application WebScale avec HBase Réflexion préalable La volumétrie Le schéma des données La disponibilité des ressources nécessaires Pourquoi HBase plutôt qu un autre? Utilisation de HBase Définition du schéma de données Architecture globale Conclusion 66 8 Liens et références 67 Glossaire 68 A Spécifications de l application Android 71 A.1 Android A.1.1 Objectifs A.1.2 Utilisation A.1.3 Fichier de sortie A Balises communes A Puissance du signal A PingGoogle A WifiSSIDs A.1.4 Description du code A NetEffMonActivity A MeasuresService A Geolocalisation A LocationData A MeasurePingGoogle NetEffMon v2 IV

5 TABLE DES MATIÈRES TABLE DES MATIÈRES A MeasureWifiSSIDs A NetworkManager A Kml A FileManager A ConnectWebService A Difficultés rencontrées A Enregistrement d une longue session A Taille du tas A Puissance du signal A Données NMEA A Tests B Code de sérialisation et désérialisation 88 C Filtres pour filtrage de points via Stargate 91 C.1 ColumnPrefixFilter C.2 ColumnRangeFilter C.3 ColumnPaginationFilter C.4 FamilyFilter C.5 FilterList with RowFilter and ColumnRangeFilter C.6 FirstKeyOnlyFilter C.7 InclusiveStopFilter C.8 MultipleColumnPrefixFilter C.9 PageFilter C.10 PrefixFilter C.11 QualifierFilter C.12 RowFilter C.13 SingleColumnValueFilter C.14 TimestampsFilter D Format des communications avec Stargate 96 D.1 Liste des tables D.2 Format des données E Format (KML) du fichier de sortie Android 99 F Optimisations et préconisations 102 F.1 Configuration matérielle F F.2 Passage d une architecture 32 bits à 64 bits F.3 Passage à un réseau en Ethernet Gigabit F.4 Suppression du swap F F.5 Optimisation de la JVM F.6 Utiliser la compression G Cahier de spécifications 107 NetEffMon v2 V

6 Table des figures 1.1 Architecture de NetEffMon v Interface utilisateur de NetEffMon v Utilisation de NetEffMon - nombre de points par jour Utilisation de NetEffMon - nombre total de points Graphique des estimations du nombre de points Schéma du fonctionnement de MapReduce Exemple d un cluster HBase Exemple d un schéma HBase Processus de récupération des données Architecture de la version Architecture de la version Diagramme de classes de NPM Processus d appel de l API public pour une récupération des données Coordonnées d un rectangle Définition d une aire Architecture de NCM Briques de NCM Graphique des performances sur la durée de la requête entre v1 et v Graphique des performances sur la durée de l affichage entre v1 et v Graphique des performances sur le traitements et l ajout de points Graphique des performances d ajout d un point dans HBase Architecture utilisée avec Git Processus suivi par Scrum Gantt prévisionnel Gantt final du projet Architecture d une application utilisant HBase A.1 Interface principale de l application Android A.2 Cycle de vie d une Activity F.1 Erreur obtenue lors d une requête sur la France (navigateur) F.2 Erreur obtenue lors d une requête sur la France (console) NetEffMon v2 VI

7 Liste des tableaux 2.1 Estimation de l évolution du nombre de données Mesure des performances après mise à jour de v1 vers v Durées de traitement (en millisecondes) d un point selon le nombre de points par instance Durées des opérations sur une petite base - en secondes Durées des opérations sur une base moyenne - en secondes Comparaison du matériel nécessaire pour PostgreSQL et HBase NetEffMon v2 VII

8 Liste des codes 1 Récupération de la liste des tables Ajout d une donnée dans une table Ajout de plusieurs données dans une table Récupération d une seule donnée Récupération de plusieurs données Création de filtre Suppression de données POM du projet principal POM de NPM POM de NCM Schéma de la row key pour HBase Schéma de la table pour HBase Demande de sérialisation en JSON Demande de désérialisation depuis JSON Requête sur l API privée pour récupérer les points dans une zone donnée Filtres utilisés pour les tests de performances Construction de NetEffMon v2 avec Maven Récupération de l ensemble de NetEffMon v Extinction d une machine du cluster HBase Exemple fichier de sortie application Android, API v NetEffMonActivity : Tâche asynchrone SendKmlTask réalisant l upload NetEffMonActivity : Démarrage du service MeasuresService NetEffMonActivity : Transfert d informations de l Activity au service MeasuresService : Timer gérant la prise de mesures MeasuresService : Méthodes performmeasures, registernewthreads, executethreads MeasuresService : Méthodes probethreads, getresults MeasuresService : Méthodes resultswritedown, checkdumpplacemarks, performwrite Geolocalisation : Récupération de la position MeasurePingGoogle : Méthode getresults de la classe MeasurePingGoogle MeasuresService : Listener récupérant la puissance du signal NetworkManager : Utilisation de TelephonyManager pour récupérer la puissance du signal Kml : Création de balises xml FileManager : création de répertoires et de fichiers FileManager : ecriture dans un fichier ConnectWebService : upload de fichiers Code simplifié de net.neteffmon.npm.api.data.cellset Code simplifié de net.neteffmon.npm.api.data.cell Code simplifié de net.neteffmon.npm.api.data.row Résultat recu de HBase ColumnPrefixFilter ColumnRangeFilter FamilyFilter FilterList with RowFilter and ColumnRangeFilter NetEffMon v2 VIII

9 LISTE DES CODES LISTE DES CODES 44 FirstKeyOnlyFilter InclusiveStopFilter MultipleColumnPrefixFilter PageFilter PrefixFilter QualifierFilter RowFilter SingleColumnValueFilter TimestampsFilter Liste des tables - Sans header "Accept" Liste des tables - XML Liste des tables - JSON Liste des tables - Protobuf Formats d échange de données - XML Formats d échange de données - JSON Formats d échange de données - Protobuf Format KML du fichier de sortie Android NetEffMon v2 IX

10 LISTE DES CODES LISTE DES CODES Avant toute chose, ce document comporte un certain nombre de termes techniques, d anglicismes et de termes anglais qu il ne nous a pas paru pertinent de traduire. De façon à s assurer que le lecteur comprenne chaque terme utilisé, un glossaire est disponible à la fin de ce document, avant les annexes. NetEffMon v2 10

11 Présentation du projet Cette partie vise à présenter le projet dans sa globalité ainsi que l existant sur lequel il se base. On s attachera à décrire les objectifs du projet sans chercher cependant à rentrer dans les détails techniques de ces derniers. 1.1 Le but général NetEffMon est un ensemble de solutions applicatives qui a pour but de permettre la mesure, le stockage et l analyse de la qualité du réseau mobile. Bien que le concept vise dans un premier temps à couvrir le territoire français, il est potentiellement utilisable dans le monde. Dans sa première version, NetEffMon a été créé en tant que proof of concept. Ce dernier s étant révélé positif, il a été décidé de poursuivre le développement. Après quelques réflexions, il est apparu que les technologies utilisées avec la première version n étaient pas adaptées sur le long terme. La version 2 a alors pour but de redéfinir une structure et une architecture plus stable dans le temps, mais également d effectuer une migration vers des technologies plus à même de gérer de fortes volumétries de données. Les choix technologiques, les implémentations et la définition de l architecture technique sont parties prenantes du projet NetEffMon v L existant Comme évoqué précédemment, NetEffMon v2 s appuie sur un existant. Ce dernier propose un ensemble de solutions permettant d effectuer la mesure, l analyse et l affichage de la qualité du réseau mobile en France. L architecture de NetEffMon v1 est visible sur la figure 1.1. On peut alors constater que NetEffMon v1 se base sur deux technologies principales : Python/Django et PostgreSQL. Le projet Django embarque plusieurs modules permettant d offrir toutes les fonctionnalités nécessaires. Le premier, le web service, est chargé de récupérer les analyses provenant des applications mobiles Android NetEffMon. Ces dernières transmettent un fichier KML au web service, qui les récupère et les insère dans une base de données sans y apporter aucune modification. Par la suite, c est le moteur d analyse qui prend le relais. Ce dernier se charge de plusieurs choses. Dans un premier temps, il parse les fichiers KML et produit en sortie un ensemble d enregistrements SQL. Ces derniers représentent chacun une mesure de la qualité du réseau, avec les informations de géo-localisation associées. Une fois cette phase de parsing effectuée, le moteur se charge de regrouper tous ces points par zones de 100 mètres, en effectuant les calculs de moyennes et d écart type nécessaires à ce type de regroupement. Enfin, l utilisateur peut demander à afficher les points précédemment mesurés. Cet affichage se fait sous la forme de points colorisés sur une carte OpenStreetMap. L utilisateur peut ainsi visualiser la qualité du réseau sur une zone donnée. Une exemple de l interface est visible sur la figure 1.2. NetEffMon v2 11

12 Chapitre 1. Présentation du projet Les problématiques existantes Figure 1.1 Architecture de NetEffMon v1 Figure 1.2 Interface utilisateur de NetEffMon v1 1.3 Les problématiques existantes Bien que totalement fonctionnel, le projet, dans sa première version, souffre de quelques problèmes non négligeables. En réalité, il apparait que, dans sa globalité, le projet n est pas viable dans le temps et que l ensemble des applications serveurs ne seront certainement pas capables de tenir la charge dans un environnement de production réel. Dans un premier temps, il convient de se focaliser sur les bases de données. Ces dernières reposent sur un système de gestion de bases de données relationnelles classiques, s appuyant sur le langage SQL. Cette technologie est éprouvée depuis de nombreuses années, et il en ressort que de fortes difficultés apparaissent lors du traitement de très grosses volumétries de données. Dans notre cas, pour mesurer cette volumétrie, NetEffMon v2 12

13 Chapitre 1. Présentation du projet Les problématiques existantes nous avons effectué un relevé des mesures effectuées une fois la solution proposée au public Points Nombre de points /05/13 01/04/13 01/03/13 01/02/13 01/01/13 01/12/ /11/12 01/10/12 01/09/12 01/08/12 01/07/12 01/06/12 01/05/12 01/04/12 Date Figure 1.3 Utilisation de NetEffMon - nombre de points par jour Points Nombre de points /11/12 01/10/12 01/09/12 01/08/12 01/07/12 01/06/12 01/05/12 01/04/12 Date 01/05/13 01/04/13 01/03/13 01/02/13 01/01/13 01/12/12 Figure 1.4 Utilisation de NetEffMon - nombre total de points Les figures 1.3 et 1.4 reprennent ces mesures. Il est donc clair qu avec une telle volumétrie, le système peut rapidement atteindre ses limites et apporter alors de lourdes contraintes. C est dans ce cadre que la première problématique prend place : il convient de ré-étudier le système de sauvegarde des données pour évoluer vers un système beaucoup plus stable dans le temps. On notera également que nous effectuons ici NetEffMon v2 13

14 Chapitre 1. Présentation du projet Les problématiques existantes une duplication des données, ce qui engendre un besoin de stockage encore plus important. Dans un second temps, nous pouvons noter un fort ralentissement de l interface utilisateur sur la version 1. Après quelques mesures, nous nous apercevons effectivement qu afficher la page d accueil prend un peu plus de 17 secondes. Évidemment, cette durée est beaucoup trop importante. C est ainsi que la deuxième problématique apparait : il faut absolument viser à accélérer l interface utilisateur pour que le rendu soit le plus rapide possible. NetEffMon v2 14

15 NoSQL : une solution possible Comme expliqué dans la partie précédente, il existe une problématique importante autour du stockage de données. Il a donc été primordial de se pencher sur ce problème et chercher une solution viable. Des recherches ont été effectuées et des tests ont été menés. Cette partie vise à présenter cette démarche et à justifier le choix finalement effectué. 2.1 PostgreSQL + PostGIS Dans un premier temps, nous avons cherché à limiter l impact des modifications. L existant utilisant déjà les bases de données PostgreSQL, nous avons choisi de poursuivre dans cette voie. Il apparait que les systèmes de base de données relationnelles, et notamment PostgreSQL, peuvent intégrer un plugin permettant de mieux gérer les traitements sur des données géolocalisées. Dans le cadre de PostgreSQL, ce plugin se nomme PostGIS. Ce dernier ajoute un grand nombre de fonctionnalités à PostgreSQL, permettant ainsi de simplifier la manipulation des données géolocalisées. Le site officiel 1 décrit le plugin PostGIS de la façon suivante : PostGIS ajoute le support d objets géographiques à la base de données PostgreSQL. En effet, PostGIS «spatialise» le serveur PostgreSQL, ce qui permet de l utiliser comme une base de données SIG. Après l installation de ce plugin, il est possible de simplifier plusieurs traitements. Désormais, il est possible de stocker des objets géométriques dans les tables. Ainsi, nous pouvons indiquer à PostgreSQL que nous stockons un point, un carré, un cercle,... Cela permet donc de simplifier la façon de stocker les points. Ensuite, il est également possible d effectuer des requêtes pour récupérer les points à l intérieur d un polygone. Cette dernière fonctionnalité est particulièrement adaptée à notre cas. Effectivement, nous cherchons régulièrement à récupérer les points contenus dans la zone affichée à l écran. C est principalement cette fonctionnalité qui nous intéresse, nous permettant ainsi d optimiser et de simplifier nos traitements. L ajout de ce plugin, et les différentes modifications nécessaires du code ont été effectuées. Cependant, après une rapide réflexion, nous nous sommes rendu compte du problème de pérennité du système de stockage. Ce dernier va amener un lourd problème dans le cadre d une réelle mise en production : le stockage de plusieurs milliers de millions de points, et leur parcours régulier, ne pourront certainement pas être menés avec une base relationnelle classique. 2.2 HBase Pourquoi un système NoSQL? Les systèmes relationnels classiques connaissent des difficultés à gérer de très gros volumes de données. Notamment, il est difficile de distribuer les données sur plusieurs serveurs obligeant alors à toujours posséder un serveur très puissant et très onéreux NetEffMon v2 15

16 Chapitre 2. HBase NoSQL : une solution possible Nous noterons également que ce type de système «impose» de connaître à l avance le schéma des tables. Effectivement, les systèmes relationnels assurent eux-mêmes la cohérence des données, et doivent, dans ce cadre, avoir conscience des différents schémas utilisés par les tables. Des difficultés à gérer facilement de très grosses volumétries de données, mais aussi l impossibilité de faire évoluer facilement les schémas des tables nous ont poussé à envisager d autres solutions. Plus complexes, ces dernières semblent cependant pouvoir répondre à notre besoin de stockage et de parcours rapide de volumétries importantes de données. Egalement, ce type de système permet de gérer des schémas non stricts, pouvant donc évoluer au cours du temps. Ces systèmes, appelés NoSQL, sont aujourd hui de plus en plus utilisés. De grands groupes se tournent vers ce type de solutions, dans des cas bien particuliers. Il ressort régulièrement qu il faut veiller à ce que ce type de systèmes soit réellement adapté à notre problématique. C est pourquoi nous avons tout d abord cherché à correctement la définir. Pour cela, nous avons cherché à estimer l évolution du nombre de données. Cette étude nous permet de déterminer si un système SQL classique risque effectivement d atteindre un jour ses limites. Pour mener cette analyse, nous avons effectué une série de calculs simples permettant d estimer grossièrement l évolution du nombre de points stockés dans la base de données. Nous considérons le cas où nous stockons chacun des points mesurés, avec l ensemble de ses données. Comme chiffres de base, nous avons utilisé ceux relevés durant une période de deux mois. Ces deux mois suivent le jour de la mise en production de NetEffMon v1. Durant cette période, nous avons constaté que l application mobile a été utilisée par environ 5 utilisateurs. Le tableau 2.1 montre ces différentes estimations. Nous voyons alors que sur une période d utilisation d un an, avec «seulement» 70 utilisateurs actifs, le nombre de points générés sera de plus de 20 millions. En sachant que chaque point ajouté dans la base doit être conservé, le nombre de données stockées ne va jamais cesser d augmenter, et ce de plus en plus rapidement. Nous noterons que ces estimations sont des estimations basses puisque les trajets moyens effectués par les utilisateurs duraient environ 30 minutes. RELEVÉS Nombre d utilisateurs 5 Période 60 jours Nombre de points ESTIMATIONS Estimation 1 Nombre d utilisateurs 60 Période 60 jours Nombre de points générés pendant la période Estimation 2 Nombre d utilisateurs 100 Période 365 jours Nombre de points générés pendant la période Table 2.1 Estimation de l évolution du nombre de données NetEffMon v2 16

17 Chapitre 2. HBase NoSQL : une solution possible /jour/utilisateur, 100 utilisateurs Evolution Nombre de points Nombre de jours Figure 2.1 Graphique des estimations du nombre de points Nous avons également clairement identifié que le fait d avoir des schémas pouvant évoluer facilement était très intéressant pour nous. Effectivement, par la suite, les mesures effectuées par le système pourront être de plus en plus nombreuses. Dans la version 1, nous devions effectuer des migrations des données, puis recalculer l ensemble des tables intermédiaires. L utilisation de système NoSQL nous permettrait de faire évoluer nos données comme nous le souhaitons, puis d adapter nos traitements, plutôt que le contraire Qu est-ce que HBase? HBase est un système de stockage de données, faisant partie de la famille des systèmes dits NoSQL. Ces produits, relativement jeunes, proposent d aborder le stockage sous un nouvel angle, pour poursuivre des buts particuliers. HBase se définit lui-même de la façon suivante (traduction de l anglais) : Apache HBase est la base de données de Hadoop, un stockage distribué, scalable et pour les gros volumes de données. Utilisez Apache HBase lorsque vous avez besoin d un accès aléatoire en lecture/écriture de vos gros volumes de données. Le but de ce projet est d héberger de très grosses tables des milliards de lignes X des millions de colonnes au sein d un cluster de matériel basique. Apache HBase est un stockage open-source, distribué, versionné et orienté colonnes inspiré du papier Bigtable : A Distributed Storage System for Structured Data rédigé par Chang et al, de Google. Tout comme Bigtable exploite le stockage de données distribué fourni par le Google File System, Apache HBase fourni des capacités similaires à celles de Bigtable via Hadoop et HDFS. HBase s intègre à l intérieur d un projet plus important : Hadoop. Hadoop est un framework qui se sert de HDFS, un système de fichiers particulier HDFS Pour pouvoir poursuivre, il est important de saisir ce qu est HDFS. En réalité, HDFS signifie Hadoop Distributed File System. C est donc un système de fichiers, amené à fonctionner sur un cluster de serveurs NetEffMon v2 17

18 Chapitre 2. HBase NoSQL : une solution possible «standards». Nous entendons par standard le fait que les serveurs n ont pas à être de gros mainframes. Une fois encore, la description officielle 2 est claire (traduction de l anglais) : Hadoop Distributed File System (HDFS) est un système de fichiers distribué destiné à fonctionner sur un matériel basique. Il possède plusieurs similarités avec les systèmes de fichiers distribués déjà existant. Cependant, les différences avec les autres systèmes de fichiers distribués sont significatives. HDFS est hautement tolérant aux erreurs et est destiné à être déployé sur du matériel bon marché. HDFS fourni un accès haut débit aux données des applications et est utilisable pour des applications qui ont de gros volumes de données. HDFS relâche quelques exigences de POSIX pour permettre un accès en continu aux données du système de fichiers. [...] De plus, HDFS poursuit un certain nombre de buts. Connaître ces derniers permettent de mieux appréhender les choix effectués et le but final du système. Premièrement, HDFS considère que les pannes sont une norme plus qu une exception. Considérant que le système de fichiers est utilisé en mode distribué, cela implique donc un grand nombre de machines utilisées pour stocker les données. Nous savons également que la probabilité qu au moins un des matériel utilisés dans le cluster soit en panne n est pas négligeable. HDFS s oriente alors vers un support des pannes matérielles en considérant en permanence qu une partie du système peut être défectueuse. La détection de panne et la récupération via les autres parties du cluster est donc une fonctionnalité importante de HDFS. Deuxièmement, HDFS considère que les applications ont besoin d un accès continu à leurs données. Dans ce sens, HDFS est créé plus pour un traitement par lots plutôt que pour un fonctionnement interactif. L accent est donc mis sur le haut débit de données plutôt que la rapidité à renvoyer des données. Troisièmement, HDFS est créé dans le but de gérer de très gros fichiers. Un fichier classique dans HDFS pèse entre plusieurs Giga-octets à plusieurs Tera-octets. Quatrièmement, HDFS s oriente vers un modèle de cohérence des données simple. Il considère que les applications qui vont l utiliser ont besoin d un modèle du type «write-once-read-many». En utilisant cette hypothèse, la cohérence des données est simplifiée et il est alors possible d assurer un débit plus important. Cinquièmement, une hypothèse importante est faite : "Bouger les traitements est moins cher que de bouger les données". Cette hypothèse relève du fait qu un traitement est bien plus efficace si il est effectué près des données, permettant ainsi, par exemple, de limiter les échanges réseau. Dans le cadre de gros volumes de données, les équipes de HDFS pensent qu il est plus facile de déplacer les traitements proches des données plutôt que de déplacer les données près des traitements. Dans ce cadre, HDFS propose des interfaces permettant aux applications de se placer elles-même plus proches des données. Et enfin, sixièmement, HDFS est créé dans le but d être facilement portable d une plateforme à une autre, facilitant ainsi l adoption de ce système Hadoop Après avoir défini le système de fichier HDFS, il faut se pencher sur Hadoop. Une fois encore, la description officielle est très claire et permet d appréhender globalement le produit (traduction de l anglais) : 2. NetEffMon v2 18

19 Chapitre 2. HBase NoSQL : une solution possible Le projet Apache Hadoop développe un programme open-source pour effectuer des traitements sûrs, scalable et distribués. La librairie de programmes Apache Hadoop est un framework qui permet d effectuer des traitements distribués sur de gros volumes de données au sein d un cluster de serveurs en utilisant des modèles de programmation simples. Il est conçu pour s adapter d un serveur unique à plusieurs milliers de machines, offrant chacune une puissance de calcul et de stockage locale. Plutôt que de compter sur les capacités du matériel à être hautement disponible, la librairie elle-même est pensée pour détecter et gérer les erreurs au niveau de l application, et donc fournir un service hautement disponible au-dessus d un cluster de machines, chacune pouvant être sujette à des erreurs. Hadoop propose un certain nombre de modules, chacun ayant son propre but. Hadoop Common fourni les utilitaires basiques pour supporter les autres modules. HDFS a été décrit dans la partie Le module Hadoop YARN est un framework permettant la gestion des ressources d un cluster et l ordonnancement des tâches. Enfin, Hadoop MapReduce permet de gérer des traitements parallèles sur de gros volumes de données, en se servant de Hadoop YARN. Hadoop est également rattaché à plusieurs autres projets permettant d allonger la liste des ses fonctionnalités. Nous pourrions noter notamment ZooKeeper qui permet de coordonner les configurations des machines au sein d un même cluster. Nous pouvons également noter Cassandra, une base de données hautes performances et principalement axée sur la disponibilité des données ; et Hive qui est un «entrepôt de données» permettant d accéder aux données via des requêtes pré-définies. Enfin, évidemment, nous allons nous attarder sur HBase, qui est un module de Hadoop, que nous utilisons dans notre projet. Figure 2.2 Schéma du fonctionnement de MapReduce Tous ces outils ont pour objectif de permettre un traitement rapide et efficace d un gros volume de données, en distribuant les traitements sur un cluster de données. Pour cela, ils utilisent un modèle de programmation appelé MapReduce. La figure 2.2, page 19, schématise ce concept. MapReduce comporte deux phases principales, chacune ayant un but bien précis. Phase «Map» Le noeud maître prend les données en entrée, les divise en sous-problèmes ayant alors une taille réduite et distribue ces sous-problèmes aux noeuds de calcul. Eventuellement, le noeud de calcul peut également effectuer une opération de MapReduce, sous-divisant encore le problème qui lui est attribué. Le traitement du problème est alors effectué, puis le résultat est renvoyé au noeud maître. NetEffMon v2 19

20 Chapitre 2. HBase NoSQL : une solution possible Phase «Reduce» Le noeud maître collecte alors les réponses de tous les sous-problèmes et les regroupe pour fournir la réponse finale. Ce modèle a été publié par Google. En utilisant Hadoop, le développeur a donc la possibilité de distribuer efficacement et facilement ses calculs sur l ensemble des machines disponibles dans son cluster Pourquoi HBase? En parallèle de la volumétrie de données et la possibilité de faire évoluer les schémas des tables, qui justifient le choix d un système NoSQL, il existe une autre problématique tout aussi complexe. Dans notre cas, ce qui importe le plus, c est d être capable de renvoyer à l utilisateur, sur une carte et dans son navigateur, les mesures effectuées grâce à NetEffMon. Cet affichage doit donc être très rapide pour que le site soit utilisable dans des conditions correctes. La problématique qui apparait est donc une contrainte temps réel. Effectivement, le système NoSQL que l on va choisir va devoir être capable de répondre très rapidement à nos requêtes. Il va donc devoir être capable de parcourir et de filtrer les données qui nous intéressent parmi un ensemble très important de points en prenant le moins de temps possible. Plusieurs solutions NoSQL sont proposées aujourd hui. Notre choix s est rapidement porté sur HBase. Pour s assurer que ce système est adapté à notre besoin, nous avons effectué quelques recherches à ce sujet. Après cette dernière, plusieurs points nous sont apparus comme particulièrement adaptés à notre projet. Dans un premier temps, nous noterons que HBase est intégré dans un autre projet : Hadoop (présenté dans la partie ). Ce type de librairie pourrait nous être utile plus tard dans le projet. Il est facilement possible d imaginer la façon dont un tel outil pourrait être utilisé dans le cadre de ce projet : analyse des données pour fournir un tableau récapitulatif, détermination des zones les moins bien couvertes, etc... En plus de son intégration dans un projet qui pourrait nous servir plus tard, le site officiel de HBase 3 nous indique que HBase est créé pour répondre aux types de problèmes que nous avons : Quand devrais-je utiliser Apache HBase? Utilisez Apache HBase lorsque vous avez besoin d un accès aléatoire, en temps réel et en lecture/écriture à vos gros volumes de données. Le but de ce projet est d héberger de très grosses tables milliards de lignes x millions de colonnes au sein d un cluster de machines. Avec un nombre de points potentiellement illimité et un besoin régulier d accéder à une portion très réduite de ces derniers, HBase semble parfaitement répondre à notre problématique. Après avoir vérifié ces quelques points, nous n avons pas trouvé de raisons de ne pas utiliser HBase. Cette technologie semble particulièrement adaptée à nos besoins, et provient indirectement de recherches effectuées par les équipes Google (voir citation de la partie 2.2.2), habituées à gérer de très gros volumes de données. De plus, ce projet est open-source, sous la licence Apache, ce qui correspond à la licence du projet NetEffMon NetEffMon v2 20

21 Chapitre 2. HBase NoSQL : une solution possible Fonctionnement global de HBase Cette partie a pour but d analyser le fonctionnement général de HBase. Dans ce cadre, nous ne chercherons pas à descendre trop bas niveau : nous ne chercherons pas à savoir la manière dont les données sont stockées sur le disque, ou comment sont réellement effectuées les requêtes. Le but de cette partie est plus de présenter comment utiliser HBase que réellement définir le fonctionnement bas niveau de HBase. HBase, comme Hadoop, vise à fonctionner sur un cluster de machines. Le schéma 2.3 montre un exemple de cluster HBase. Nous pouvons constater que c est le serveur Master qui reçoit la requête, et qui par la suite contacte les RegionServers. L ensemble des données sont réparties sur l ensemble des RegionServers pour éviter de charger une seule machine à chaque requête. Figure 2.3 Exemple d un cluster HBase Stockage des données La première chose à comprendre est la façon dont les données sont représentées dans HBase. Pour cela, il est indispensable de chercher au maximum à mettre de côté les principes des bases de données relationnelles classiques. Nous noterons également que HBase garde les différentes versions d un champ. De façon à appuyer et illustrer l explication, nous pouvons nous reporter à la figure 2.4. Cette dernière nous présente un exemple d un schéma HBase, avec deux lignes et deux familles de colonnes. Dans HBase, il y a deux concepts généraux à garder en tête : les lignes et les familles de colonnes. En réalité, la base de données s organise comme un tableau 4D. Les familles de colonnes ne sont présentes que pour «regrouper des valeurs qui ont une signification proche». A l intérieur de ces familles de colonnes, nous retrouverons des qualifier. Ces qualifiers nous amènent à l avant dernier niveau. Le dernier niveau est la version que nous souhaitons récupérer. C est la combinaison suivante qui permettra de retrouver une «cellule» : { numéro de ligne, famille de colonne, qualifier, version }. Avec toutes ces informations, nous avons la possibilité de récupérer une donnée précise dans la base de données. Une fois encore, la figure 2.4 aide beaucoup à comprendre ces principes. NetEffMon v2 21

22 Chapitre 2. HBase NoSQL : une solution possible Figure 2.4 Exemple d un schéma HBase Nous pouvons également voir que les qualifiers peuvent être librement définit entre les colonnes, mais également entre les lignes. Contrairement aux bases de données classiques, les colonnes présentent pour chacune des lignes ne sont pas forcément les mêmes. Il est important de garder ce concept en tête tout au long du développement : c est au développeur d assurer la cohérence des données et des traitements. Pour bien comprendre le rôle des qualifiers, nous pouvons nous pencher sur un exemple concret : celui de NetEffMon v2, simplifié. Notons aussi que cet exemple n est pas forcément le schéma final du projet, ni le plus optimisé et ne sert qu à des fins d exemple. Il faut alors définir ce que nous souhaitons stocker : Des informations de localisation Longitude Latitude Des données de mesures Temps de latence Nombre de satellites Qualité du signal NetEffMon v2 22

23 Chapitre 2. HBase NoSQL : une solution possible A la création de la table, nous indiquerons uniquement des familles de colonnes. Selon la réflexion précédente, nous en voyons deux qui ressortent clairement : les informations de localisation, les données de mesures. Ces familles de colonnes, une fois la table créée, ne pourront plus être modifiées. Nous dirons alors que nos familles de colonnes seront : localisation et mesures. Une fois ces familles de colonnes définies, il ne nous reste plus qu à définir les colonnes. Ce sont ces colonnes que nous appelons qualifiers. Dans notre cas, les colonnes (et donc les qualifiers) sont : longitude, latitude, latence, satellites, signal. En suivant cette réflexion, et en sachant que le caractère «:» permet de séparer le nom d une famille de colonnes et du qualifier, nous retrouvons avec les couples suivants : localisation : longitude localisation : latitude mesures : latence mesures : satellites mesures : signal Cet exemple permet de bien saisir l utilité des qualifiers dans le système et de mieux appréhender leur fonctionnement. Nous comprenons également que les qualifiers peuvent être identiques dans des familles de colonnes différentes, puisque c est le couple «famille : qualifier» qui permet d identifier une cellule. Nous notons également que les qualifiers peuvent évoluer dans le temps, et ne sont pas forcément les mêmes dans chacune des lignes de la table (d où la capacité d évolutivité du schéma) Conseils de modélisation La documentation de HBase 4 nous donne différentes orientations à suivre pour définir un modèle correct pour nos données. En respectant ces conseils, nous nous assurons de maximiser les performances de HBase. Dans la partie , nous avons bien vu que le concept est très différent de celui des bases de données classiques. En plus de cette manière de stocker et retrouver les données un peu particulière, HBase indique qu il est nécessaire de ne pas multiplier les familles de colonnes. Avec plus de deux ou trois familles, HBase a de grosses difficultés à renvoyer les résultats rapidement. Egalement, il faut noter qu il est important d avoir à peu près le même nombre d enregistrements dans les familles de colonnes. D après la documentation officielle, si une famille de colonnes A a 1 millions de lignes, tandis qu une famille de colonnes B (dans la même table) a 1 milliard de lignes, les données de la famille A seront distribuées sur tous les serveurs, rendant alors le parcours inutilement plus lent (un seul serveur pourrait être suffisant pour stocker la famille A). Nous avons également vu que HBase stockait les données en utilisant le principe de lignes. Evidemment, chacune des lignes est identifiée par une clé. Il est nécessaire de correctement générer cette clé pour éviter de ralentir les traitements inutilement. Le principe global est d éviter à tout prix d utiliser des clés «séquentielles». Ainsi, il convient donc d éviter d utiliser un timestamp ou une suite de chiffres séquentielle telle que (1, 2, 3,...). Pour justifier cette nécessité, la documentation officielle nous renvoie vers un article de blog 5 qui explique que l utilisation des clés séquentielles va amener une mauvaise distribution des données sur les machines du cluster. Cette mauvaise distribution ne fera que limiter les performances. Il est important de bien réfléchir au format de la clé dès le départ de façon à optimiser les traitements futurs en anglais : NetEffMon v2 23

24 Chapitre 2. HBase NoSQL : une solution possible Accès aux données Nous avons expliqué jusque là comment HBase stockait ses données. Il convient maintenant de se pencher sur la manière d y accéder. Pour accéder à ses données, HBase propose plusieurs méthodes. La première est une API en Java. Cette dernière permet un accès complet aux données par l intermédiaire d un ensemble de classes. Cette approche implique un certain nombre de librairies à importer et la connaissance des fichiers de configuration du cluster HBase pour permettre son utilisation. Par la suite, toutes les opérations sont gérées par des classes définies dans une documentation classique 6. On peut noter qu un projet parallèle est né et fournit une API en C++ pur 7. Une deuxième approche consiste à utiliser des outils permettant d accéder aux données quelques soient les langages utilisés. Pour cela, il est possible de passer par des web-services RESTful fournissant un accès normalisé aux données. Dans cette approche, deux outils différents sont proposés au sein de HBase. Le premier se nomme Thrift et est un autre projet Apache. C est un framework permettant de créer «automatiquement» des services en décrivant les fonctionnalités que nous souhaitons avoir, avec un format normalisé. Une description de ce framework est disponible à cette adresse : Elle permet de mieux comprendre l utilité et la façon dont fonctionne ce service. HBase fournit ensuite une documentation 8 qui permet de savoir comment utiliser cet outil. L autre outil proposé est un web-service REST plus classique nommé Stargate. Ce dernier est pré-intégré à HBase et propose un accès aux données via des requêtes HTTP classiques. Une documentation 9 est fournie pour prendre connaissance des requêtes à utiliser et le format des réponses renvoyées. Ce service permet un accès complet aux données : ajout, lecture, mise à jour, suppression. La rapidité d installation et la facilité d utilisation de ce web-service nous a fait adopter pour cette solution. De plus, toutes les opérations dont nous avons besoin peuvent être effectuées avec ce dernier et il n y a donc aucune difficulté à prévoir à ce sujet Fonctionnement de Stargate Nous avons précédemment parlé du web-service permettant d accéder aux données stockées dans HBase. Ce dernier permet d effectuer la majorité des opérations possibles sur les données. Cependant, le fonctionnement de certaines requêtes peut être un peu déroutant et pas forcément intuitif. Cette partie vise à les présenter et les expliquer pour mieux comprendre le fonctionnement de Stargate. La plupart des exemples présentés ci-dessous sont directement tirés de la documentation officielle disponible à cette adresse : Récupération de la liste des tables Stargate permet de récupérer la liste des tables présentes sur un serveur. Selon la valeur du Header HTTP "Accept" de la requête envoyée, le résultat sera formaté différemment. 1 GET / Code 1 Récupération de la liste des tables NetEffMon v2 24

25 Chapitre 2. HBase NoSQL : une solution possible Il existe ainsi plusieurs formats de réponse possibles. Le listing 53, en annexe D présente ces différents formats de réponse possibles Ajout d une donnée dans la table Stargate permet d ajouter un point dans la base de données. Pour cela, et selon les principes de fonctionnement des web-services REST, il faut utiliser les méthodes HTTP POST ou PUT. La requête présentée dans le code 2 est simplifiée et une version plus complète peut être trouvée ici : 1 PUT /<table>/<row>/<column>:<qualifier> 2 3 POST /<table>/<row>/<column>:<qualifier> Code 2 Ajout d une donnée dans une table Nous pouvons voir que plusieurs choses sont spécifiées dans l URL de la requête. Ainsi, nous indiquons directement à HBase dans quelle table doit se dérouler l ajout, mais également à quelle ligne, puis à quelle colonne. Les données précises à ajouter sont passées en paramètres de la requête (le champ data d une requête HTTP). Effectivement, en utilisant ce type de requêtes (POST ou PUT), il est possible d envoyer des données. Dans notre cas, ces données doivent représenter ce que nous souhaitons ajouter dans la base de données. Une fois encore, il est possible d utiliser plusieurs formats différents. Les codes 57, 58 et 59, en annexe D les présentent tous. Plusieurs points très importants sont à noter : Toutes les valeurs doivent être encodées en Base64 Dans le cas de l utilisation du format JSON, la documentation officielle indique que certains champs sont précédés du caractère «@». Avec la version de HBase utilisée pour ce projet (HBase ), ce caractère n est jamais présent dans les échanges. Dans le cas de l utilisation du format JSON, la valeur de la cellule est présente dans le champ «$» Ajout de plusieurs données dans la table Cette requête est très semblable à celle pour ajouter un seul point (cf ). Cependant pour ajouter plusieurs points, il n est plus nécessaire de préciser la cellule précise que nous souhaitons ajouter. Il faut alors utiliser une clé fictive, et préciser les détails de l ajout dans les données transférées dans le contenu de la requête. 1 PUT /<table>/<false-row-key> 2 3 POST /<table>/<false-row-key> Code 3 Ajout de plusieurs données dans une table Pour savoir quels formats utiliser pour transférer les données, il est possible de se reporter une fois encore aux codes 57, 58 et 59, en annexe D. NetEffMon v2 25

26 Chapitre 2. HBase NoSQL : une solution possible Il est important de savoir que si nous demandons l ajout d une cellule qui existe déjà (donc que l identifiant de la ligne, la famille de colonne, le qualifier et le timestamp sont exactement identiques), la valeur précédente sera écrasée Récupérer une seule donnée Stargate propose de récupérer une cellule précise. Pour cela, il faut connaitre toutes les informations permettant d identifier précisément cette cellule (reportez vous à la figure 2.4 pour savoir comment est organisée une table HBase) : La table L identifiant de la ligne Le nom de la famille de colonne Le qualifier Le timestamp Dans le cas où tous les paramètres précédents sont précisés, une unique cellule sera renvoyée. Le format de la réponse est toujours le même et est présenté dans les codes 57, 58 et 59, en annexe D. Le code 4 montre la requête à effectuer pour récupérer une donnée. 1 GET /<table>/<row>/<column>:<qualifier>/<timestamp> Code 4 Récupération d une seule donnée Récupérer plusieurs données Stargate propose également de récupérer plusieurs cellules appartenant à une même ligne. La requête est relativement semblable à celle de récupération d une cellule précise. Une fois encore, plusieurs informations sont nécessaires, mais beaucoup deviennent optionnelles. Plus le nombre de paramètres précisés est petit, plus le nombre de résultats renvoyés sera important. Les paramètres possibles sont les suivants : La table (obligatoire) L identifiant de la ligne (obligatoire) Une seule ou une liste de famille(s) de colonnes (optionnel) Les qualifiers associés aux familles de colonnes (optionnel) Un intervalle de timestamp (optionnel) Le numéro de version de la cellule (optionnel) Le format de la requête finale est présentée par le code 5. 1 GET /<table>/<row> 2 ( / ( <column> ( : <qualifier> )? 3 (, <column> ( : <qualifier> )? )+ )? 4 ( / ( <start-timestamp>, )? <end-timestamp> )? )? 5 (?v= <num-versions> )? Code 5 Récupération de plusieurs données NetEffMon v2 26

27 Chapitre 2. HBase NoSQL : une solution possible Le format de réponse est toujours le même et est présenté par les codes 57, 58 et 59, en annexe D Filtrage des données En plus de permettre la récupération d une cellule précise, Stargate offre la possibilité de créer des filtres (appelés «Scanner» par HBase). De cette façon, il est possible d obtenir uniquement les points répondant à un certain nombre de critères. Cette récupération suit un processus particulier et plus complexe que celui suivi par les systèmes classiques. Figure 2.5 Processus de récupération des données En réalité, la récupération de données filtrées suit le processus présenté par la figure 2.5. Nous voyons alors qu il est d abord nécessaire de créer un filtre sur le système. Par la suite, il faudra effectuer plusieurs fois de suite la même requête. Cette dernière nous renverra un code différent lorsque le système aura terminé de nous renvoyer toutes les données correspondant au filtre. Nous récupérerons donc les données par «paquets» et non pas d un seul coup. Ce mode de fonctionnement a plusieurs avantages, mais nous noterons notamment que l on évite une charge trop importante pour le système (récupérer points d un coup peut représenter un gros fichier), mais également la possibilité de commencer à traiter une partie des données pendant que les autres parties continues à être reçues. Dans un premier temps, il faut donc créer un scanner. La requête pour les créer est assez simple, comme le montre le code 6. Les différents filtres utilisables sont disponibles en annexe C, cependant aucune documentation officielle n existe réellement. Une fois le scanner créé, le système nous renvoie l URL à utiliser pour récupérer les données filtrées. C est cette URL, unique, qu il faudra «appeler» plusieurs fois : tant que le code HTTP de la réponse est 200, c est que tout va bien et que nous pouvons continuer à récupérer des données ; lorsqu il n y a plus de données à recevoir, le code HTTP est égal à 204 (HTTP 204 = No content). Pour récupérer nos données, il nous faut alors requêter l adresse renvoyée par l opération précédente, via la méthode GET. Des résultats seront renvoyés, une fois encore en suivant le format demandé par les headers, et répondant aux spécifications des codes 57, 58 et 59, en annexe D. Le nombre de résultats renvoyés à chaque appel dépend de la propriété batch précisée lors de la création du scanner. NetEffMon v2 27

28 Chapitre 2. HBase NoSQL : une solution possible 1 // // Creation du Scanner 3 // Utiliser : "Content-Type: text/xml" 4 // PUT /<table>/scanner 6 7 POST /<table>/scanner 8 9 // // Donnees a envoyer 11 // <Scanner batch="1"/>... </Scanner> // // Reponse du serveur 16 // HTTP/ Created 18 Location: du serveur>/content/scanner/<id unique> 19 Content-Length: 0 Code 6 Création de filtre Suppression d un point Enfin, Stargate propose de supprimer les données présentes dans la base. Pour cela, une unique requête HTTP permet de supprimer une ligne, une colonne ou une cellule, selon les paramètres fournis. Le format est très simple et est présenté par le code 7. Nous pouvons alors considérer que HBase supprimera toutes les cellules répondant aux critères fournis : au plus la requête est précise, plus le nombre de cellules supprimées sera réduit. 1 DELETE /<table>/<row> 2 ( / ( <column> ( : <qualifier> )? 3 ( / <timestamp> )? )? Code 7 Suppression de données Problèmes de sécurité Il y a un point à ne surtout pas négliger avec HBase : la gestion du contrôle d accès. Contrairement à un système classique tel que PostgreSQL, la gestion de la sécurité n est pas directement intégré à HBase. Les bases de données classiques proposent en général une gestion de ses utilisateurs, avec des groupes et une granularité assez fine des droits de chacun. Cependant, HBase ne gère pas cette problématique nativement, et il est nécessaire de greffer des contrôles d accès «au-dessus» du service HBase. NetEffMon v2 28

29 Chapitre 2. HBase NoSQL : une solution possible La documentation nous indique que l utilisation de Kerberos est nécessaire pour réussir à sécuriser HBase. Kerberos est un protocole de communication réseau permettant de permettre un échange sécurisé 10 entre deux noeuds d un réseau non sécurisé. Le déploiement et l utilisation de Kerberos n est pas une chose qui se fait en quelques heures. Une configuration lourde, tant côté serveur que côté client, peut être nécessaire et le déploiement d un serveur d authentification est obligatoire. Cette opération ne doit donc pas être prise à légère, et il est également nécessaire de bien se souvenir que les données ne sont pas sécurisées nativement. Après un déploiement basique de HBase, tout le monde peut ajouter, lire, mettre à jour et supprimer les données de la base de données sans aucune limitation. 10. Par échange sécurisé, nous entendons identification des acteurs (par exemple, pas de cryptage) NetEffMon v2 29

30 La migration Figure 3.1 Architecture de la version 2 La figure 3.1 expose l architecture générale du projet. On y voit alors plusieurs modules qui communiquent entre eux. Cette partie vise à présenter comment, techniquement, cette architecture a été implémentée, mais également le rôle de chacun des modules. Avant de commencer, il est important de noter quelle technologie a été choisie. Initialement codé uniquement en Python, NetEffMon v2 sera désormais codé en Java 1.7. Ce langage, en plus d être mieux adapté au traitement de gros volumes de données que Python, est également celui utilisé par les API natives de HBase. C est deux arguments ont suffit à orienter notre choix vers Java pour éviter de rencontrer des NetEffMon v2 30

31 Chapitre 3. La migration Architecture du code problèmes de compatibilité dans le futur, ou d être bloqué par le fait d une limitation due au langage. 3.1 Architecture du code Ce projet possède une architecture complexe, comme le montre la figure 3.1. Dans ce cadre, il nous a semblé très important d utiliser des technologies permettant de simplifier au maximum la gestion des dépendances de chacun des modules. C est dans ce cadre que nous nous sommes tourné vers Maven. Cet outil permet de gérer les dépendances d une façon automatisée et extrêmement efficace. Le site officiel le décrit de la façon suivante (traduction de l anglais) : Apache Maven est un logiciel de gestion de projet et un outil de compréhension. Basé sur le concept de «project object model» (POM), Maven peut gérer la construction d un projet, ses rapports et sa documentation depuis une pièce centrale. La configuration de Maven s organise autour de fichiers.pom. Ces derniers possèdent l ensemble des informations nécessaires à la construction, à la compilation et au packaging des projets concernés. Ainsi, il est possible de définir dans ces fichiers l ensemble des dépendances du projet. Dans notre cas, la difficulté était de permettre à certains modules de dépendre d un autre. En réalité, nous avons besoin que les modules NettEffMon Mobile Module et NetEffMon Client Module dépendent de NetEffMon Processing Module. Effectivement, les deux premiers vont chacun utiliser l API privée. Nous avons donc décider de déployer NPM dans un fichier JAR qui sera ensuite importé par les deux autres modules. Enfin, NMM et NCM seront chacun déployés dans des fichiers WAR, créant ainsi des applications J2EE facilement importables dans un serveur web J2EE. Figure 3.2 Architecture de la version 2 La figure 3.2 expose l architecture définit avec maven. Comme nous pouvons le constater, chacun des modules va chercher ses dépendances lui-même. Ainsi, nous pouvons voir qu il est bien indiqué que NMM et NCM ont besoin de NPM comme dépendance. Cela se gère très facilement avec maven. NetEffMon v2 31

32 Chapitre 3. La migration Architecture du code Les fichiers.pom sont présentés ci-dessous. Ils ne présentent pas de complexité particulière et expriment simplement notre configuration. Ils sont également fortement épurés pour simplifier la lecture et l explication. 1 <project> 2 <groupid>net.neteffmon</groupid> 3 <artifactid>neteffmon</artifactid> 4 <version>0.0.1-snapshot</version> 5 <packaging>pom</packaging> 6 7 <name>neteffmon</name> 8 9 <modules> 10 <module>nmm</module> 11 <module>npm</module> 12 <module>ncm</module> 13 </modules> 14 </project> Code 8 POM du projet principal Le code 8 est celui utilisé pour décrire le projet principal. Ce projet ne contient pas de code source, mais permet de définir les sous-projets contenus par NetEffMon. Il permet également de définir des propriétés communes, comme le groupid et l artifactid qui permettent de nommer le projet. La balise packaging permet de spécifier comment nous souhaitons déployer le projet. Dans notre cas, ce projet principal ne doit pas être déployé et permet «uniquement» de définir une architecture. C est pourquoi nous utilisons la propriété pom. Enfin, nous pouvons apercevoir dans la balise modules l ensemble des modules du projet. Le code 9 présente la configuration du module NPM. On peut voir une balise parent qui précise, comme son nom l indique, quel est le projet parent. Ainsi, la propriété groupid (entre autres) est automatiquement récupérée depuis le fichier de configuration du projet parent. On voit également que ce projet définit son propre artifactid et son nom. Enfin, nous pouvons voir que le projet définit également ses dépendances. Nous n en avons précisé qu une seule ici, par soucis de clarté. Cette dernière sera automatiquement téléchargée par maven, si nécessaire, sous la forme d un fichier JAR. Ce fichier ne sera ensuite importé que dans ce module, évitant d avoir à charger ce dernier dans les autres modules lorsque cela n est pas nécessaire. Les configurations des modules NCM et NMM sont très proches. Nous n en présenterons donc qu une : celle de NCM (code 10). On peut voir certaines balises particulièrement importantes. La première est la balise build. Cette dernière permet de préciser la façon dont nous voulons déployer le projet. Ici, nous indiquons que le déploiement va nécessiter un plugin : celui permettant le packaging en fichier WAR. Ensuite, nous paramétrons ce plugin de façon à maitriser le déploiement : nous indiquons également à quel emplacement nous souhaitons placer le fichier créé. Enfin, la balise packaging indique que nous souhaitons un fichier WAR. La configuration précisée précédemment sera alors utilisée. NetEffMon v2 32

33 Chapitre 3. La migration Architecture du code 1 <project> 2 <parent> 3 <groupid>net.neteffmon</groupid> 4 <artifactid>neteffmon</artifactid> 5 <version>0.0.1-snapshot</version> 6 </parent> 7 8 <artifactid>npm</artifactid> 9 10 <name>npm</name> <dependencies> 13 <dependency> 14 <groupid>org.apache.httpcomponents</groupid> 15 <artifactid>httpclient</artifactid> 16 <version>4.2.3</version> 17 </dependency> 18 </dependencies> 19 </project> Code 9 POM de NPM NetEffMon v2 33

34 Chapitre 3. La migration Architecture du code 1 <project> 2 3 <parent> 4 <groupid>net.neteffmon</groupid> 5 <artifactid>neteffmon</artifactid> 6 <version>0.0.1-snapshot</version> 7 </parent> 8 9 <artifactid>ncm</artifactid> 10 <name>ncm</name> <dependencies> 13 <dependency> 14 <groupid>com.sun.jersey</groupid> 15 <artifactid>jersey-server</artifactid> 16 <version>1.17</version> 17 </dependency> 18 </dependencies> <build> 21 <plugins> 22 <plugin> 23 <groupid>org.apache.maven.plugins</groupid> 24 <artifactid>maven-war-plugin</artifactid> 25 <version>2.3</version> 26 <configuration> 27 <warname>neteffmon.ncm</warname> 28 <outputdirectory>/home/albin</outputdirectory> 29 </configuration> 30 </plugin> 31 </plugins> 32 </build> <packaging>war</packaging> </project> Code 10 POM de NCM NetEffMon v2 34

35 Chapitre 3. La migration NetEffMon Processing Module (NPM) 3.2 NetEffMon Processing Module (NPM) Figure 3.3 Diagramme de classes de NPM Ce module est le coeur du projet NetEffMon v2. Il se charge d effectuer la majorité des traitements lourds, et se charge également de communiquer directement avec le serveur de stockage des données. Pour cela, plusieurs modules «fonctionnels» sont prévus de façon à bien pouvoir architecturer le code. Plus concrètement, ce module est fourni sous la forme d une librairie, dans un fichier JAR. Il peut donc être inclus dans n importe quel autre projet qui en a besoin Structure des données Sachant que nous allons utiliser HBase, le schéma utilisé pour stocker les données dans la version 1 n est plus directement utilisable dans la version 2. Nous avons donc cherché à définir un nouveau schéma, respectant les différentes recommandations de HBase. La partie se penche sur ces différents conseils. Nous avons notamment chercher à correctement définir les deux points suivants : la forme de la clé de ligne (row key), et les différentes familles de colonnes (ColumnFamily). Nous avons alors défini le format présenté dans le code 11 pour la clé de ligne. La partie geohash est un hash de la longitude et de la latitude d un point. Le timestamp est exprimé en nanosecondes. 1 abcdefghijklmnopqrstuvwxy \ 1 /\ 2 / 3 1 : geohash 4 2 : timestamp Code 11 Schéma de la row key pour HBase NetEffMon v2 35

36 Chapitre 3. La migration NetEffMon Processing Module (NPM) Les conseils de HBase sont correctement respectés : le geohash n est pas une valeur qui s incrémente de façon «monotone». Sa valeur dépend de la longitude et de la latitude, nous assurant ainsi que les données seront réparties sur toutes les machines du cluster, en fonction de leur geohash. Le timestamp, quand à lui, s incrémente de façon «monotone» mais n est pas la partie significative de la clé. Ainsi, il n est pas génant qu il prenne place à la fin de cette dernière. Le schéma des familles de colonnes doit également être défini dès le départ et influera sur la capacité à pouvoir évoluer facilement dans le futur. Toujours en suivant les conseils présentés dans la partie , nous avons défini le schéma présenté dans le code row_key 2 i: 3 geohash 4 lat 5 lon 6 d: 7 googleping 8 signalstrength 9 googlelatency 10 provider (EDGE, HSDPA, Wi-Fi) 11 carriername (SPN, SIM SPN?) Code 12 Schéma de la table pour HBase Nous pouvons alors constater qu il y a deux familles de colonnes : i (pour informations) et d (pour data). Cette organisation cherche à regrouper les informations permettant de définir un point géolocalisé dans la famille informations, puis les données sur les mesures dans la partie data. Si aujourd hui cette dernière ne contient que peu de champs, ces derniers pourront facilement évoluer dans le temps puisque nous avons déjà vu que les qualifiers sont définis librement et «à chaud» par le développeur StargateHelper Stargate est le web service REST proposé par HBase pour accéder en lecture/écriture aux données contenues dans les bases de données. Au travers de plusieurs appels à ce web-service, il est possible d exploiter l ensemble des données présentes dans les bases HBase. La classe StargateHelper a pour objectif d encapsuler les appels à ces méthodes. Cette architecture a plusieurs avantages. Premièrement, elle permet de centraliser le code, améliorant ainsi la maintenabilité. Deuxièmement, elle donne la possibilité d évoluer rapidement vers un autre type de connexion au serveur. Enfin, elle évite aux autres classes d avoir à connaitre les détails de la configuration réseau Méthode de parsing Plusieurs fois dans la suite de ce document, nous parlons de parsing de fichiers. Plus concrètement, dans de nombreux processus suivis par le projet, les modules échangent des données sérialisées. Ainsi, nous avons régulièrement à effectuer des opérations de sérialisation/desérialisation. NetEffMon v2 36

37 Chapitre 3. La migration NetEffMon Processing Module (NPM) Pour effectuer ces tâches, nous avons décidé d utiliser une librairie externe. De cette façon, nous nous assurons au maximum d utiliser les méthodes les plus optimisées, mais nous simplifions également grandement le développement du projet. Deux librairies ont été choisies : une permettant le parsing en XML, et une autre permettant le parsing en JSON. Bien que les deux librairies soient différentes, elles fonctionnent sur le même principe : les annotations. Ce principe consiste à «annoter» les classes, leurs propriétés et leurs méthodes, pour indiquer de quelle manière une instance doit être sérialisée/désérialisée. En consultant les portions de codes 36, 37 et 38 de l annexe B, il apparait évident qu utiliser ce type de mécanismes permet de simplifier énormément le code, mais également de le rendre facilement compréhensible (les annotations ont des noms plutôt significatifs). Pour illustrer cette explication, nous pouvons nous pencher un peu plus sur le code permettant le traitement des données échangées avec HBase (codes 13 et 14). Nous avons volontairement simplifié le code pour éviter de surcharger ce document (suppression de méthodes non pertinentes pour l explication, suppression des accesseurs, suppression des ligne d imports, suppression de la javadoc...). L ensemble des codes sont disponibles en annexe B pour éviter de surcharger le document. Nous constatons alors plusieurs groupes d annotations. Le premier correspond aux opérations avec le format XML, et l autre se charge de régir les opérations avec le format JSON. A la demande de sérialisation, ou de désérialisation, la librairie concernée lira les annotations qui la concerne, puis effectuera les opérations nécessaires. Il faut également noter la simplicité du code «demandant» la sérialisation/désérialisation. Les codes 13 et 14 exposent le code nécessaire à ces opérations. Nous pouvons constater que ces codes sont extrêmement simples et qu il suffit de définir un ObjectMapper qui se chargera à lui tout seul de sérialiser ou désérialiser les objets passés en paramètres. 1 ObjectMapper mapper = new ObjectMapper(); 2 ByteArrayOutputStream stream = new ByteArrayOutputStream(); 3 mapper.writevalue(stream, objecttoserialize); Code 13 Demande de sérialisation en JSON 1 ObjectMapper mapper = new ObjectMapper(); 2 CellSet cellset = mapper.readvalue(stringtodeserialize, CellSet.class); Code 14 Demande de désérialisation depuis JSON API privée Cette API a pour objectif de permettre l encapsulation d un grand nombre de traitements. Ainsi, l ensemble des modules actuels et futurs ont la possibilité d utiliser simplement et d une façon homogène les différentes ressources mises à leur disposition. Cette API se caractérise par trois classes, elles-même appuyées par un Helper. NetEffMon v2 37

38 Chapitre 3. La migration NetEffMon Processing Module (NPM) La figure 3.3 (page 35) expose le diagramme des classes du module NPM. L API est constituée par toutes les classes du package npm.api. Ces dernières exposent un ensemble de méthodes permettant d accéder aux fonctionnalités. Les classes du package npm.utils ne devrait pas être utilisées par le développeur. Ces dernières offrent les méthodes de connexion au serveur HBase et permet d effectuer les conversions de types de données. Ces conversions sont effectuées avec les classes des packages npm.api.data et npm.api.json. Les conversions de type de données permettent de sérialiser et désérialiser les résultats des requêtes. Elles permettent, par exemple, de passer d un format JSON à un format GeoJSON en ne manipulant que des objets : nous n avons donc pas géré le traitement des chaines de caractères. Pour pouvoir utiliser un tel processus, nous nous appuyons sur les annotations proposées par la librairie FasterXML Jackson. Figure 3.4 Processus d appel de l API public pour une récupération des données La figure 3.4 décrit le processus suivit pour récupérer des données de la base de données. On rappelle que NCM est le module client, qui sera présenté dans la partie 3.3. Ce dernier offre une API publique et le front-end, et a donc régulièrement besoin de récupérer des données du serveur, sur demande de l utilisateur. Plusieurs points sont à noter. Premièrement, nous pouvons voir qu aux étapes 6 et 7, le format d échange entre StargateHelper et HBase est le format JSON. Ce dernier est définit dans la documentation officielle de HBase 1. Cette documentation indique également que l on peut demander à HBase de nous renvoyer du XML. C est pour cette raison que les annotations ajoutées aux classes du package npm.api.data sont doubles, pour permettre la désérialisation depuis du JSON mais aussi depuis du XML. Deuxièmement, nous pouvons observer que ces objets déserialisés sont ensuite passés à la classe DataAccess. Cette dernière se charge alors d effectuer un regroupement de ces points par zone de 100 mètres. Cette opération est effectuée dans un but unique : éviter que le client ai trop de points à afficher. Effectivement, le nombre de points récupérés pour une zone donnée peut être très important. Tous ces points ne pourront pas être correctement traités et affichés visiblement sur le front-end. Nous noterons que la taille de la zone de regroupement est «facilement» éditable directement dans le code NetEffMon v2 38

39 Chapitre 3. La migration NetEffMon Processing Module (NPM) Enfin, il est possible de voir que DataAccess sérialie les objets regroupés en GeoJSON 2. Ce format est utilisé par OpenLayers pour représenter les points affichés à l écran. Ce dernier permet de définir directement les informations nécessaires à OpenLayers. Il permet également d obtenir une représentation standard de données géolocalisées. Ainsi, même si l utilisateur ne souhaite pas effectuer un affichage via OpenLayers, les données restent exploitables et standardisées. Pour terminer sur le processus de récupération de données, il nous faut aborder la signification de la flèche de couleur rouge. Pour bien comprendre ce fonctionnement, il faut d abord avoir lu la partie décrivant le fonctionnement de Stargate 3. En réalité, HBase renvoi les données par «paquets». Pour obtenir l ensemble des données, il est donc nécessaire d interroger HBase plusieurs fois de suite, jusqu à ce que celui-ci nous indique explicitement qu il n a plus de données à nous renvoyer. La figure 2.5 (page 27) nous montre bien ce processus Principe de récupération de points Comme décrit dans la partie 3.2.4, l API privée permet d encapsuler plusieurs traitements. Il est intéressant de se pencher sur la récupération et le tri de points. Effectivement, nous avons décrit dans la partie la façon dont les requêtes étaient transmises au serveur HBase, mais pas réellement comment elles sont construites. Pour implémenter cette récupération de points, nous avons décidé d implémenter une requête récupérant tous les points contenus dans une zone donnée. Pour cela, nous avons décidé de limiter la forme de la zone à un rectangle. Il est également communément admis qu un rectangle peut être représenté par uniquement deux points, comme le montre la figure 3.5. Ainsi, nous avons décidé de n utiliser que les points «supérieur gauche» et «inférieur droit» pour définir notre carré. Plus précisément, par convention, notre rectangle sera représenté (par rapport à la figure 3.5) par les coordonnées (x2, y2); (x4, y4). Figure 3.5 Coordonnées d un rectangle Le web service REST d accès à HBase NetEffMon v2 39

40 Chapitre 3. La migration NetEffMon Processing Module (NPM) Il est donc nécessaire d indiquer ces deux points à l API privée. En ayant connaissance de ces valeurs, nous pouvons alors générer un ensemble de filtres pour que HBase nous renvoi les points désirés. Pour ce faire, un pré-traitement est nécessaire. Effectivement, nous recevons bien deux extrémités opposées d un triangle, mais nous ne savons pas «dans quel sens» a été positionné le repère au moment du relevé des coordonnées. La première action à effectuer est donc de déterminer la plus grande valeur entre les deux ordonnées, puis entre les deux abscisses. En gros, nous cherchons à définir des axes tels que représentés dans la figure 3.6. Haut : max Y Zone souhaitée Bas : min Y Gauche : min X Droite : max X Figure 3.6 Définition d une aire Une fois ces axes représentés, il est facile de se rendre compte que nous cherchons tous les points (x; y) dont x min < x < x max et y min < y < y max. Le filtre sera donc facilement généré par la suite : on retranscrira dans le format demandé les contraintes précisées précédemment Regroupement des points La partie présente la manière dont les points sont récupérés, puis restitués à l utilisateur. Cependant, lors de l utilisation de cette méthode par le front-end, pour afficher tous les points reçus, nous sommes confrontés à trois problèmes : la taille des données reçues est très importante, le nombre de données à traiter et à afficher est trop importante, l affichage n est pas clair car le nombre de points est trop élevé. De façon à contourner ce problème, nous avons décidé de regrouper les points, de la même manière que dans la version 1. Ainsi, le front-end préfèrera utiliser la classe AnalysisAccess qui effectuera la même requête que la classe DataAccess mais se chargera de regrouper les points par zone de 100 mètres carré Ajout d un fichier de mesure Le module propose d ajouter des mesures d une manière simplifiée. La classe MeasureAccess encapsule l ensemble des traitements nécessaires à l ajout des mesures effectuées par l intermédiaire du module NMM (partie 3.4). NetEffMon v2 40

41 Chapitre 3. La migration NetEffMon Client Module (NCM) Cette classe consiste principalement en la lecture d un fichier au format KML. Le principe de fonctionnement de la lecture de ce document est le même pour le traitement des données échangées avec HBase : tout se base sur un processus de sérialisation/désérialisation. L ensemble des classes utilisées pour effectuer ces traitements sont dans le package npm.api.measures. La partie présente comment les opérations de parsing sont effectuées dans ce projet. Le principe reste le même dans le cadre de l ajout de données, seules les annotations sont évidemment modifiées, pour correspondre au format de nos fichiers KML. 3.3 NetEffMon Client Module (NCM) Ce module a pour but de donner un accès public aux données de la base de données. Pour ce faire, il inclut deux parties distinctes : l API publique et le front-end. Finalement, l architecture de ce module est plutôt simple, comme le montre la figure 3.7. Figure 3.7 Architecture de NCM API publique Dans un cadre open-data, il est indispensable d offrir aux utilisateurs un accès aux données. Pour remplir cet objectif, nous avons décidé d implémenter un web-service RESTful. Ce dernier offre un accès en lecture aux données disponibles dans la base de données au travers d un ensemble d URLs. Pour définir ces accès, nous avons cherché à définir les différentes données auxquelles l utilisateur pourrait souhaiter avoir accès. Après cette phase de réflexion, une liste de requêtes types a été définie. Par la suite, nous avons définit une série d URL permettant de représenter ces requêtes. En partant de ce principe, nous avons souhaité donner un accès simple à la méthode de l API privée permettant de récupérer des points contenus dans une zone. La requête est alors : NetEffMon v2 41

42 Chapitre 3. La migration NetEffMon Client Module (NCM) 1 GET <url de l api>/<longitude 1>/<latitude 1>/<longitude 2>/<latitude 2> Code 15 Requête sur l API privée pour récupérer les points dans une zone donnée Comme nous pouvons le constater, l utilisateur a la possibilité, directement via l URL, de définir les paramètres de sa requête : les deux points permettant de définir une zone, comme expliqué dans la partie Il récupère alors l ensemble des points contenus dans cette zone, en respectant les formats énoncés dans la partie Front-end Une fois l API publique créée, nous avons décidé de permettre à l utilisateur de consulter ses données d une façon plus ergonomique. Effectivement, nous avons pensé utile de fournir à l utilisateur une visualisation de ces données moins brutes. Ainsi, nous avons cherché à migrer le front-end de la v1 avec le moins de modifications possibles. Pour ce faire, nous avons réutiliser le code de la version 1 se chargeant du front-end, en mettant cependant à jour la version du framework Django. Le fonctionnement du front-end est donc le plus léger et le plus sécurisé possible. L objectif principal est d avoir à faire le moins de traitements possible côté client. De cette façon, le front-end communique directement avec l API publique, et interprète les données reçues. Comme la version précédente, nous utilisons donc un mélange de Python/Django et de Javascript. Alors que Django se charge de renvoyer les bonnes pages et de déclencher les bons traitements, en fournissant une plateforme complète et évolutive, le Javascript est utilisé pour pouvoir afficher des cartes OpenStreetMap. Enfin, il est important de noter que nous utilisons la librairie OpenLayers pour afficher les cartes. Pour mieux comprendre les différentes briques de ce projet, la figure 3.8 schématise les différents composants du module. Figure 3.8 Briques de NCM La partie Django est aujourd hui très légère. Elle ne se charge que d afficher la bonne page (selon le modèle MVC). Dans la suite, elle aura notamment la possibilité de gérer facilement les utilisateurs du NetEffMon v2 42

43 Chapitre 3. La migration NetEffMon Client Module (NCM) système. Le coeur du front-end se trouve alors pour l instant dans le code Javascript. Ce dernier permet de charger la librairie OpenLayers et d interagir avec cette dernière. C est uniquement ce code qui se charge de charger et de dessiner les points sur le fond de carte. Dans la partie 1.3, nous avons évoqué le fait qu il existait un important ralentissement sur le front-end. Durant la migration du front-end, nous avons donc mis l accent sur l amélioration du temps d affichage de la page d accueil. Cependant, nous verrons que les résultats sont relativement mitigés Résolution des problèmes Amélioration de la latence de la page d accueil Nous avons précédemment indiqué que la page d accueil présentait un fort ralentissement. Après avoir effectué quelques relevés des temps d exécution, nous avons pu rapidement noter une cause de ce ralentissement : une erreur dans le code existant effectuait une double requête. Cette requête permettait de récupérer les points dans la base de données et prenait plusieurs secondes, ralentissant ainsi beaucoup le système. Nous avons donc supprimé cette double requête et avons gagné beaucoup de temps. Une seconde cause de problème s est rapidement présentée : le nombre de points à afficher. Effectivement, le code Javascript initial récupérait l ensemble des points contenus dans la base de données, les chargeait tous, puis n affichait que ceux qui étaient visibles à l écran. Il est évident que charger la totalité des points pour n en afficher qu une partie ne peut qu amener un ralentissement inutile. Nous avons donc implémenté côté serveur la possibilité de récupérer une partie des points puis avons ensuite adapté le code pour faire la requête correcte. Cette requête est en réalité définit par l API publique (cf. partie 3.3.1), et par les principes évoqués dans la partie Après avoir apporté les deux modifications précédentes, nous avons décidé d en ajouter une dernière pour parfaire le tout. En réalité, l utilisateur avait la possibilité d afficher les points visibles sur la portion de carte affichée à l écran quelque soit le niveau de zoom. Cela impliquait alors que l utilisateur pouvait alors afficher la totalité des points du monde en dé-zoomant au maximum. Nous nous retrouverions donc la situation évoquée précédemment : un nombre de points trop important à traiter puis à afficher. Nous avons alors décidé de fortement limiter le niveau de zoom autorisé, réduisant alors l affichage à un quartier au maximum. De ce fait, nous nous assurons que le nombre de points à afficher est relativement correct. Nous avons arrêté nos améliorations à ce niveau. Nous avons effectués des relevés pour nous assurer que les modifications ont été utiles. Pour comprendre les relevés, il faut savoir qu ils ont été effectués sur la version que l on pourrait appeler la version v1.1. Effectivement, ces modifications ont été menées sur la toute première part du projet. A ce moment, l architecture conservait donc la présence de PostgreSQL, avec l ajout du plugin PostGIS (cf. partie 2.1). Cette architecture possède un nombre de contraintes très réduit, et il est donc nécessaire de comprendre que les résultats relevés à ce moment ne correspondent pas du tout aux résultats finaux du projet. Avant de commenter le tableau 3.1 et les graphiques 3.9 et 3.10, il faut noter que dans le cas de la v1, sur les deux requêtes effectuées, nous avons gardé ici celle qui a pris le plus de temps. Sachant cela, ces éléments nous démontrent bien l utilité des modifications évoquées. Effectivement, avec un facteur d amélioration de sur la durée de récupération des points, et un facteur d amélioration de 6.65 sur le temps d affichage total de la page d accueil, il est évident que ces modifications améliorent de façon considérable les performances du système. Egalement, nous notons une nette amélioration de la stabilité du système avec une suppression totale des pics de courbes présents sur la v1. NetEffMon v2 43

44 Chapitre 3. La migration NetEffMon Client Module (NCM) Récup. points Temps d aff Moy. Ec. Ty v v v v Table 3.1 Mesure des performances après mise à jour de v1 vers v Améliorations de la durée de la requête v1 v1.1 Durée de la requête Numéro de la mesure Figure 3.9 Graphique des performances sur la durée de la requête entre v1 et v1.1 NetEffMon v2 44

45 Chapitre 3. La migration NetEffMon Client Module (NCM) Améliorations de la durée d affichage v1 v1.1 Durée du traitement Numéro de la mesure Figure 3.10 Graphique des performances sur la durée de l affichage entre v1 et v1.1 NetEffMon v2 45

46 Chapitre 3. La migration NetEffMon Mobile Module (NMM) 3.4 NetEffMon Mobile Module (NMM) Ce module est chargé de toutes les interactions avec les périphériques mobiles. Il contient donc deux sousparties : l application Android permettant d effectuer les mesures et un web-service permettant d ajouter les mesures dans la base de données L application Android Durant ce projet, aucune modification n a été apportée à l application Android. De façon à ne pas surcharger inutilement ce document, la description de cette dernière, rédigée dans le rapport présentant NetEffMon v1, est liée dans l annexe A Le web-service De façon à pouvoir récupérer les données mesurées par l application Android, nous avons migré le webservice déjà présent dans NetEffMon v1. Dans un esprit de rétro-compatibilité, nous avons décidé de ne pas modifier l URL à utiliser pour accéder au web-service. Cette adresse répondant déjà aux standards RESTful, cette contrainte n a pas réellement posé de problème. Ce web-service utilise le module NPM, présenté en partie 3.2. NPM propose l accès à une API privée offrant un accès simplifié à la base de données. Pour rappel, on peut se reporter à la figure 3.1 (page 30) pour mieux comprendre l architecture globale du projet. Le web-service attend en entrée un fichier KML. Ce format est basé sur le XML et permet de représenter des données géolocalisées. Il permet de représenter des points, des polygones, des modèles 3D... Dans notre cas, nous avons respecté à la lettre ce format, et avons stocké nos données dans la partie ExtendedData qui a pour but de permettre aux utilisateurs de stocker des données «non-standard». Le format final, un peu lourd pour être présenté ici, est disponible en annexe E. NetEffMon v2 46

47 Résultats obtenus 4.1 Performances L objectif premier du projet est de permettre une utilisation du système pérenne. La première version permettait une utilisation stable du système, mais nous avions identifié une période critique pouvant arriver assez rapidement lors d une utilisation à une échelle réelle. Le problème était le nombre de données à stocker, puis à traiter. Ayant déployé un système NoSQL (HBase), la pérennité est désormais théoriquement assurée : HBase est prévu pour être capable de gérer de très grosses volumétries de données, nous permettant de garder notre système stable pendant une période importante. Cependant, il est important de garder à l esprit que nous cherchons également à répondre à une problématique temps réel pour permettre un affichage au travers du front-end. Cette problématique est très difficile à respecter dans notre projet. Effectivement, après la phase de développement et de tests sur des petites volumétries de données, nous avons tenté d effectuer les requêtes, testées précédemment sur des petits volumes de données, sur des volumétries plus importantes. Un projet parallèle à celui-ci, mené par Matthieu ANCERET et Sébastien GUILLON, a permis d effectuer ces tests. Les résultats qui suivent sont le résultat de leur travail Ajout des points dans la base de données Nb de points Parsing Ajout ND ND Table 4.1 Durées de traitement (en millisecondes) d un point selon le nombre de points par instance Le tableau 4.1 et les graphiques 4.1 et 4.2 regroupent l ensemble des résultats obtenus lors des tests d ajout de points dans la base de données. Les deux graphiques représentent la durée nécessaire pour un seul point en fonction du nombre de points par instance. Comme vu dans la partie , on ajoute les points par «paquets», ce sont ces paquets que nous appelons ici «instances». Un ajout comporte deux phases : la génération du fichier contenant les points (Parsing) et l ajout à proprement parler dans la base de données (Ajout). NetEffMon v2 47

48 Chapitre 4. Résultats obtenus Performances 1000 Génération Ajout Durée pour un point (ms) Nombre de points par instance Figure 4.1 Graphique des performances sur le traitements et l ajout de points 1000 Génération + ajout Durée pour un point (ms) Nombre de points par instance Figure 4.2 Graphique des performances d ajout d un point dans HBase En regardant de plus près les graphiques, nous pouvons nous apercevoir que les meilleures performances sont atteintes lorsque le nombre de points total est d environ 80. Effectivement, même si nous pourrions obtenir des meilleures durées sur la phase de parsing avec des instances plus importantes, la phase d ajout devient nettement plus longue sur ces dernières. En définitive, nous pourrions conclure sur une durée optimale de génération + ajout de 1,054s pour 80 points. Cette durée n est pas négligeable lorsque l on sait qu un utilisateur ayant effectué une grosse session NetEffMon v2 48

49 Chapitre 4. Résultats obtenus Performances de mesures pourrait envoyer plusieurs dizaines de milliers de points. Cette problématique est connue, et est discutée dans les parties 4.2 et Montée en charge sur les requêtes en lecture Pour rappel, les résultats qui suivent sont le résultat du travail mené avec le binôme Matthieu ANCERET et Sébastien GUILLON. Après avoir effectué des tests sur les durées d insertion de points, nous nous sommes penchés sur les performances lors de la lecture des données. Cette étude a été très intéressante puisqu elle a permis de soulever de lourds problèmes. La procédure de test s est déroulée en deux temps : des tests sur une base de petite taille ( points) et des tests sur une base d une taille un peu plus importante (environ 100 millions de points). Nous noterons que cette deuxième base, bien que plus importante, reste très petite pour les volumétries généralement gérées par HBase (plusieurs milliards de lignes). Sur ces bases, nous avons cherché à récupérer tous les points contenus dans la ville de Tours. Les filtres utilisés pour effectuer ces requêtes sont présentés dans le code 16. Il est également possible de se rapporter aux aux parties et pour comprendre comment les points sont récupérés depuis HBase. Création Scanner Première récupération Récupérations Génération XML TOTAL Table 4.2 Durées des opérations sur une petite base - en secondes Création Scanner Première récupération Récupérations Génération XML TOTAL Table 4.3 Durées des opérations sur une base moyenne - en secondes Les tableaux et 4.3 présentent les résultats des différents tests. Comme nous pouvons le constater, il y a déjà un fort problème de performances sur une petite base de données. Effectivement, la récupération des points de toute la ville de Tours prend en moyenne 310 secondes, soit 5 minutes. Même si nous souhaitons, sur notre interface utilisateur, ne récupérer qu une plus petite portion de points, les résultats resteraient mauvais. Effectivement, sur des tests bien moins rigoureux, nous avons obtenus une durée moyenne de récupération des points d environ 15 secondes pour une zone se limitant à un quartier de la ville de Tours. Cette durée reste mauvaise pour une interface utilisateur. Pour mesurer l ampleur du problème de performances, nous pouvons également nous pencher sur le tableau 4.3. Ce tableau résume les résultats de requêtes effectuées sur une base de 100 millions de points. Dans ce cas, nous avons observé une durée totale de 7101,63 secondes, soit environ 2 heures. Nous pouvons voir que deux durées ne sont pas renseignées, cela est dû au fait qu aucun point, dans cette base générée aléatoirement, ne répondait aux critères donnés. Nous ne pouvons donc que nous alarmer : 2 heures est la valeur la plus petite possible. 1. Première récupération = première demande de récupération de points - Récupérations = durée de toutes les demandes suivantes jusqu à récupération de la totalité des points. Il est possible de se reporter à la partie pour connaître le processus complet. NetEffMon v2 49

50 Chapitre 4. Résultats obtenus Performances 1 <Scanner batch="10000"> 2 <filter> 3 { 4 "type": "FilterList", 5 "op": "MUST_PASS_ALL", 6 "filters": [ 7 { 8 "type": "SingleColumnValueFilter", 9 "op": "GREATER_OR_EQUAL", 10 "family": "i", 11 "qualifier": "lon", 12 "latestversion": true, 13 "comparator": {"type": "BinaryComparator", "value": " "} 14 }, 15 { 16 "type": "SingleColumnValueFilter", 17 "op": "LESS_OR_EQUAL", 18 "family": "i", 19 "qualifier": "lon", 20 "latestversion": true, 21 "comparator": {"type": "BinaryComparator", "value": " "} 22 }, 23 { 24 "type": "SingleColumnValueFilter", 25 "op": "GREATER_OR_EQUAL", 26 "family": "i", 27 "qualifier": "lat", 28 "latestversion": true, 29 "comparator": {"type": "BinaryComparator", "value": " "} 30 }, 31 { 32 "type": "SingleColumnValueFilter", 33 "op": "LESS_OR_EQUAL", 34 "family": "i", 35 "qualifier": "lat", 36 "latestversion": true, 37 "comparator": {"type": "BinaryComparator", "value": " "} 38 } 39 ] 40 } 41 </filter> 42 </Scanner> Code 16 Filtres utilisés pour les tests de performances D autres tests devaient être menés, mais ont été abandonnés dû à ce gros problème de performances. Nous nous sommes donc attardés à essayer de rétablir des performances plus correctes, en nous penchant NetEffMon v2 50

51 Chapitre 4. Résultats obtenus Evolutions à venir sur différentes configurations matérielles. Effectivement, les durées où le code de NetEffMon est impliqué donne des résultats plutôt corrects, et les phases les plus longues se déroulent toutes sur le cluster (nous n avons donc pas la main sur ces traitements). 4.2 Evolutions à venir Comme évoqué dans la partie 4.1, quelques problèmes de performances continuent à exister. Bien que nous n ayons pas eu le temps de faire les modifications nécessaires pour améliorer cette situation, nous avons identifier les points sur lesquels il serait intéressant de travailler. Dans un premier temps, nous sommes rendu compte qu effectuer sur une requête sur un très grand nombre de points était excessivement long. Si nous nous penchons sur la requête effectuée, nous nous rendons compte que nous travaillons sur le couple (longitude, latitude). Ce dernier ne constitue pas un index, et nous supposons que cela peut fortement influer sur la rapidité de la requête. La documentation officielle de HBase 2 se penche sur les index secondaires. Dans notre cas, l index des points dans la table est constitué de la façon suivante : <geohash><timestamp>. De cette façon, nous pouvons stocker plusieurs points ayant été mesurés au même endroit. Egalement, les données sont «idéalement» répartis sur les machines du cluster puisqu un geohash ne s incrémente pas d une façon «monotone». Nous noterons que travailler avec un geohash uniquement en tant que clé de ligne n est pas possible. Effectivement, deux problèmes se poseraient : Il serait impossible de garder en mémoire deux mesures effectuées au même endroit : les geohashs seraient identiques et la dernière version écraserait la première La recherche de points géolocalisés en utilisant un geohash a une faille non négligeable : les points de part et d autre de l équateur sont très proches «physiquement» mais très éloignés par leur geohash. Ainsi, une recherche sur la «proximité» des geohash de ce type de points indiquerait qu ils sont très éloignés alors qu en réalité ils sont très proches. Nos résultats, pour ce cas particulier, seraient faussés, et nous pensons qu il n est pas correct de garder un système qui possède un tel risque de retourner des données fausses. Nous pensons alors que générer une table annexe, permettant de définir des index secondaires nous permettrait éventuellement de résoudre ce problème. En générant ces index secondaires directement lors de l ajout de chaque point, nous pensons que la durée nécessaire à l ajout d un fichier de mesure ne serait pas beaucoup plus important, mais que la durée nécessaire à la récupération des données pourrait être fortement réduite. Nous pensons également que deux index secondaires seraient nécessaires : le premier sur la longitude et le second sur la latitude. 4.3 Remarques et critiques Pour palier aux problèmes de performances évoqués précédemment, nous avons cherché longuement à en trouver la cause. Dans un premier temps, nous avons pensé que le problème pouvait venir du réseau. Après avoir changé le routeur par un Gigabits et avoir branché directement le client sur ce dernier, aucun réel changement n a été observé NetEffMon v2 51

52 Chapitre 4. Résultats obtenus Remarques et critiques Après avoir observé les trames échangées sur le réseau, nous nous sommes aperçu que ces dernières ne prenaient que peu de temps à être transmises. Nous avons donc conclu que le problème principal ne venait pas des performances du réseau. En parallèle de ce projet, un binôme d étudiants (Matthieu ANCERET et Sébastien GUILLON) s est penché sur l exécution de différentes requêtes sur des volumétries bien plus importantes que celles utilisées dans notre phase de tests. En collaboration avec ce binôme, nous avons alors constaté qu il existait un gros problème de configuration du cluster. Effectivement, ce dernier, configuré et déployé par un autre étudiant de cinquième année, utilise uniquement des versions 32 bits : kernels, JVM... Le rapport de ce binôme nous indique les points suivants : Pour rappel, un système d exploitation en 32 bits est limité au niveau de la mémoire qu il peut utiliser : 32 bits : Normalement, limité à 4 Go de RAM, mais la carte mère s en réserve une partie et la mémoire réellement utilisable tombe entre 2,9 et 3,5 Go. L espace perdu est en fait utilisé pour l adressage des périphériques. 32 bits avec PAE : Implémentée au niveau du processeur, cette extension permet de repousser la limite mémoire à 64 Go sur les systèmes 32 bits. Malgré tout, il existe toujours la limitation mémoire par processus qui est fixée à 4 Go (pour un processus 32 bits). Il est donc totalement bénéfique de passer à un système 64 bits, qui permettra d utiliser la totalité de la mémoire vive disponible et d allouer plus de 4 Go de RAM pour un processus (si celui-ci est en 64 bits bien évidemment). Un système d exploitation 64 bits permet aussi une amélioration globale des performances, grâce à une meilleure gestion du multiprocesseur/multi thread. Hadoop/HBase et la machine virtuelle Java existent tous les deux en 64 bits, il serait donc dommage de s en priver. Encore une fois, si l on se réfère à la documentation officielle d HBase, celle-ci nous indique d utiliser un système d exploitation et une JVM en 64 bits. Actuellement, ce n est pas le cas, et cela explique probablement (ou en partie du moins) les faibles performances rencontrées. Malheureusement, même après avoir changé l architecture et mis à jour les différents composants nécessaires, les résultats sont restés les mêmes : les requêtes prennent toujours autant de temps. Par la suite, nous nous sommes alors interrogé sur la quantité de mémoire disponible. La documentation de HBase nous dit ceci mot pour mot : RAM, RAM, RAM. Don t starve HBase. Notre cluster a une configuration limitée en RAM, n embarquant que 8Go de RAM par machine. Cloudera 3, un acteur important spécialisé dans l exploitation de Hadoop/HBase et le big-data, indique dans un article sur son blog 4 la configuration qu il recommande pour chaque machine d un cluster Hadoop (traduction de l anglais) : NetEffMon v2 52

53 Chapitre 4. Résultats obtenus Remarques et critiques 4 disques durs de 1To dans une configuration JBOD (Just a Bunch Of Disks) 2 CPU quad core, cadencés au moins à 2-2.5GHz 16-24Go de RAM (24-32Go si vous considérez HBase) Gigabit Ethernet La configuration des machines de notre cluster - 1 CPU Intel Xeon quad core 3.07Ghz, 8Go de RAM, 1 disque dur de 500Go - est très loin de la configuration recommandée. Nous notons que le manque d au moins 16Go de RAM pose très certainement de gros problèmes. Une analyse plus avancée des différentes améliorations a été menée par le binôme cité précédemment. Cette analyse est disponible dans l annexe F et peut être consultée pour obtenir plus d informations à ce sujet. NetEffMon v2 53

54 Gestion de projet Dans ce projet, sa bonne gestion a été un objectif du début jusqu à la fin. Le but était de fournir un résultat directement utilisable à la fin du projet. Ainsi, nous n avons pas forcément visé une liste de fonctionnalités la plus avancée, mais plutôt l assurance d une architecture propre et facilement évolutive. De longues phases d analyse et de réflexion ont donc pris place tout au long du projet pour nous assurer que les choix technologiques étaient les plus efficaces, et, surtout, permettent d assurer une reprise aisée du projet. Cette partie a deux buts : présenter les différents outils et techniques utilisés pour assurer un déploiement facile, tant côté développeur que côté utilisateur, et présenter la façon dont le temps a été géré tout au long du projet. 5.1 Outils et techniques utilisés Dans le cadre de notre projet, plusieurs points devaient être surveillés. Le premier est une problématique qui existe dans chaque projet de développement informatique : la gestion des sources et des versions. De façon à éviter de perdre les évolutions, mais également à pouvoir facilement revenir sur des versions antérieures plus fonctionnelles, il est important de ne jamais négliger ce point. La seconde problématique concerne la gestion des dépendances. Effectivement, ce projet utilise un certain nombre de librairies externes. La reprise de ce projet implique la configuration de ce dernier, et donc l importation de chacune des librairies. De plus, il faut bien veiller à utiliser la bonne version de chacune des librairies. L architecture de ce projet est assez complexe, et peut prendre beaucoup de temps à déployer correctement. Dans ce cadre, nous avons cherché à simplifier ce déploiement sur les machines des développeurs et éventuellement des utilisateurs via l utilisation d un outil dédié : Maven Gestion des dépendances : Maven Maven est un outil de gestion de projets Java. Il se décrit lui-même 1 de la façon suivante(traduction de l anglais) : Maven, un mot d origine Yiddish signifiant «accumulateur de savoir», était à la base une tentative de simplifier les processus de construction du projet Jakarta Turbine. Il y avait différents projets, chacun avec leur propre fichier de construction Ant qui étaient tous légèrement différents et les JARs étaient concentrés dans un dépôt CVS. Nous avons voulu une manière standardisée de construire les projets, avec une définition claire de ce en quoi le projet consiste, une manière simple de publier les informations du projet et une açon de partager les JARs au travers de plusieurs projets. Le résultat est un outil qui peut maintenant être utilisé pour construire et gérer tous les projets basés sur Java. [...] Cet outil suit également un ensemble d objectifs principaux, énoncés sur le site officiel 2 : Rendre le processus de construction facile Voir note 1 NetEffMon v2 54

55 Chapitre 5. Gestion de projet Outils et techniques utilisés Fournir un système de construction uniforme Fournir des informations de qualité sur le projet Fournir des orientations sur les bonnes pratiques de développement Autoriser les migrations transparentes vers de nouvelles fonctionnalités Maven permet notamment de supprimer la nécessité de comprendre les détails du processus de construction. Sans encapsuler ni automatiser la totalité des opérations, il permet d éviter de passer beaucoup de temps à comprendre l ensemble des détails tout en permettant d obtenir une construction qui correspond à nos besoins. En utilisant un POM (Project Object Model) et un ensemble de plugins communs à tous les projets Maven, la construction d un projet est tout le temps la même quelque soit le projet. Ainsi, il est nécessaire de comprendre qu une seule fois comment un projet Maven est construit, et permet donc de naviguer rapidement au sein d un grand nombre de projets. En parcourant les fichiers sources, et en effectuant automatiquement les tests, Maven permet de fournir un grand nombre d informations utiles : changelog, liste des dépendances, rapports de tests unitaires... Enfin, Maven propose une façon simple de mettre à jour les installations des utilisateurs, que ce soit pour des plugins externes ou pour Maven lui-même. De façon à clarifier un peu les choses, Maven permet de définir l ensemble de l architecture d un projet dans un fichier. Ainsi, un simple fichier permet de connaitre : les modules du projet, les librairies (et leur version) utilisées, la manière dont nous souhaitons construire le projet (sources incluses,... ), la façon dont nous souhaitons publier le projet (fichier WAR, fichier JAR,... ),... L ensemble des opérations de construction sont ensuite automatisées grâce à la lecture de ce fichier. Ainsi, un développeur n a pas besoin de reconstruire à la main chaque dépendance du projet lorsqu il a effectué une modification : Maven va se charger de trouver les différences qui nécessitent une reconstruction, puis effectue les opérations nécessaires, telles que décrites dans le fichier de configuration. Ces fichiers de configurations s appellent tous pom.xml. Il existe un pom par projet, puis par sous-module : avec un projet contenant 2 sous-modules, il y aura donc au total 3 pom - 1 pour le projet principal, puis 2 pour les sous-modules. L ensemble des informations nécessaires à la construction du projet est contenu dans le fichier pom du projet. Dans le cas de ce projet, Maven a été utilisé pour permettre un déploiement simplifié. La partie 3.1 décrit la façon dont le projet est architecturé. Ainsi, la construction de l ensemble du projet est extrêmement simple et peut être effectuée en une seule ligne. Il faut se placer dans le dossier du projet principal (/neteffmon) et saisir la commande suivante : NetEffMon v2 55

56 Chapitre 5. Gestion de projet Outils et techniques utilisés 1 mvn package Code 17 Construction de NetEffMon v2 avec Maven L ensemble du projet sera alors construit, et deux WARs seront générés, comme expliqué dans la partie 3.1 et décrit dans les différents pom Gestion des sources et des versions : Git Dans tout projet de développement informatique, une question qui peut rapidement devenir compliquée se pose : la gestion des codes sources et de leur version. Cette problématique apparait encore plus critique lors d une collaboration de plusieurs développeurs. Dans ce cas, il faut gérer les différentes versions, mais surtout gérer les modifications concurrentes (plusieurs modifications «au même endroit» par plusieurs développeurs). Pour répondre à ces problématiques, nous pouvons utiliser un système de gestion de versions. Ces derniers permettent d automatiser un grand nombre d opérations et d assurer une cohérence des fichiers. Beaucoup d articles de blog ou de discussions sur des forums spécialisés expliquent les bénéfices que nous pouvons tirer de ce type de système. Nous pourrons notamment noter les possibilités suivantes : La possibilité de revenir sur une version antérieure si nous avons fait une erreur La possibilité de récupérer son code si nous l avons perdu ou que nous avons une version trop ancienne Nous pouvons gérer plusieurs versions d un même projet Nous pouvons voir les différences entre plusieurs versions de notre code Nous pouvons prouver qu un changement a corriger un problème ou en a créé un nouveau Nous pouvons envoyé des patchs pour le code de quelqu un d autre Nous pouvons expérimenter des modifications sans pour autant modifier le projet qui fonctionne actuellement Nous avons ici évoqué les idées et les fonctionnalités principales. Ce type d outil permet d effectuer et de simplifier un grand nombre d opérations, que nous n allons pas chercher à présenter ici. Nous allons plutôt nous pencher sur la façon dont nous l avons utiliser pour notre projet Utilisation de Git Dans la partie 5.1.1, nous nous sommes penché sur la façon dont nous avons utilisé Maven. Ce dernier nous a permis de définir une structure claire et précise pour l ensemble des modules du projet. Il nous ait alors apparu évident qu il fallait reporter cette architecture au sein de notre système de gestion de versions. Effectivement, si nous avions utilisé Git sans chercher à organiser l architecture, nous nous serions retrouvé avec un seul dépôt, contenant l ensemble des modules. Ainsi, une modification dans un seul des modules aurait entrainé la mise à jour de l ensemble du dépôt. Egalement, ne pas reproduire l architecture proposée par notre configuration de Maven n aurait pas permis d obtenir des modules bien dissociés les uns des autres : si nous souhaitons récupérer un seul module, il faut forcément télécharger l ensemble du dépôt et ensuite récupérer la partie qui nous intéresse. NetEffMon v2 56

57 Chapitre 5. Gestion de projet Outils et techniques utilisés Pour répondre à cette contrainte, nous avons utilisé une des fonctionnalités de Git qui n est pas très bien connue : submodules. Le site officiel 3 propose un exemple d utilisation qui correspond parfaitement à notre besoin : Il arrive souvent que lorsque vous travaillez sur un projet, vous avez besoin d utiliser un autre projet à l intérieur de celui-ci. Peut-être que c est une librairie qu un développeur tiers développe ou que vous développez à part et que vous utilisez dans plusieurs projets parents. Un problème commun se pose dans ces scénarios : vous voulez être capable de traiter les deux projets séparément tout en étant capable d utiliser l un à l intérieur de l autre. Nous pouvons alors nous assurer que ce cas correspond au notre : nous avons développé un module, NPM, qui doit être utilisé au sein de deux autres modules, NCM et NMM. Les Submodules de Git semblent donc parfaitement répondre à notre besoin. L utilisation de cette fonctionnalité est assez simple. Au sein de notre projet, nous avons décidé de la mettre en place dès le départ, nous simplifiant ainsi grandement la tâche. Pour faire cela, nous avons donc créé quatre dépôts Git distincts : NetEffMon, NPM, NCM et NMM. Ces dépôts correspondent exactement à l architecture et aux pom définis via Maven. Ainsi, les dépôts contiennent les pom et les codes sources des différents projets Maven dont ils portent le nom. Ce sont ces trois dépôts qui seront les submodules. Le dépôt NetEffMon, quant à lui, ne contient rien d autre que le pom du projet Maven principal, et les informations des submodules. La figure 5.1 schématise l architecture des différents dépôts Git. Figure 5.1 Architecture utilisée avec Git 3. NetEffMon v2 57

58 Chapitre 5. Gestion de projet Gestion du temps Finalement, la récupération de l ensemble du projet reste extrêmement simple et s effectue via la suite des commandes présentées dans le code $ git clone <neteffmon.v2 url> 2 $ git submodule init 3 $ git submodule sync 4 $ git submodule update Code 18 Récupération de l ensemble de NetEffMon v2 Après avoir exécuté ces commandes, l architecture des dossiers nécessaires au fonctionnement de Maven est correctement reproduite. Par la suite, le développeur peut effectuer ses modifications dans un seul des dépôts sans influer sur les autres. Enfin, la personne en charge d effectuer la livraison aurait la possibilité de récupérer les versions correctes au sein du dépôt principal (NetEffMon). Effectivement, les commits de ce dernier recensent se base uniquement sur les commits de ses submodules : si aucun commit n est effectué dans les submodules, le dépôt principal n aura rien à enregistrer. 5.2 Gestion du temps Scrum Il existe un grand nombre de méthodes de gestion de projet. Dans notre cas, nous avons choisi de gérer le projet en suivant une méthode Agile : Scrum. Cette méthode évite la rédaction de multiples lourds cahiers sans pour autant négliger la notion de spécifications. Scrum fonctionne sur la base d itérations régulières, toutes les semaines dans notre cas. A chaque itération, l équipe (développeur, encadrant, client...) se concerte, de façon à adapter les prochaines tâches à effectuer. Cela permet de prendre en compte les différents imprévus dans notre processus de développement. Cette méthode prévoit notamment une forte interaction avec le «client». Ce dernier est appelé régulièrement à rencontrer l équipe pour constater l avancement du projet (à chaque fin d itération). Figure 5.2 Processus suivi par Scrum La figure 5.2 schématise le processus classique d une itération Scrum. Le processus que nous avons suivi est donc celui-ci : Product Backlog Le client et l équipe définissent le livrable à fournir avant le début du sprint NetEffMon v2 58

59 Chapitre 5. Gestion de projet Gestion du temps Sprint Backlog Le client et l équipe définissent les tâches à effectuer durant le sprint Sprint L équipe effectue les tâches prévues Delivery L équipe livre une version incrémentée et fonctionnelle du produit. On peut noter que les backlogs pouvaient être définis à l avance, mais pouvaient aussi être révisés juste avant le début du sprint concerné. Le Sprint Backlog consiste à créer des User Stories et des tâches. Une User Story est une fonctionnalité que le client ou l équipe souhaite intégrer. Elle prend la forme suivante : En tant que <client ou équipe ou scrum master> Je souhaite que <exemple : l application affiche l heure> Afin de <description de l utilité de la tâche> Alors qu une User Story s attache surtout aux détails fonctionnels, les tâches sont souvent bien plus techniques. Effectivement, une User Story regroupe plusieurs tâches. Ces tâches doivent être «atomiques», c est-à-dire qu il ne devrait pas être possible de les rediviser en plusieurs sous-tâches. Une tâche est également affectée à un seul membre de l équipe à la fois. Lorsque toutes les tâches d une User Story sont terminées, on peut considérer que la fonctionnalité à été ajoutée. On peut passer à la phase de tests et, en cas de succès des tests, ajouter la fonctionnalité au livrable de fin de sprint (Delivery) Le déroulement du projet Dès le début du projet, nous savions déjà que nous ne savions pas réellement quelle en serait l issue. Nous partions surtout dans un objectif de recherche, de façon à fournir à la fin du projet une version la plus fonctionnelle et pérenne possible. Dans ce cadre, il a été difficile de définir une suite de tâches au départ du projet. C est pourquoi nous avons pensé que Scrum, présenté dans la partie précédente, était particulièrement adapté. Effectivement, sur un projet comportant des technologies que nous ne maîtrisons pas forcément complètement dès le commencement, il nous a paru important de choisir une méthode nous permettant d adapter notre planification en fonction des éventuels imprévus que nous allions pouvoir rencontrer. Malgré le fait que les tâches n ont pas été toutes définies dès le départ, nous pouvons facilement faire ressortir les phases importantes du projet. La figure 5.4 présente le diagramme de Gantt qui a été suivi durant le projet, tandis que la figure 5.3 permet de visualiser le Gantt prévu initialement. Il est important de noter que la période précédant Janvier ne proposait qu une seule journée bloquée pour le PFE, expliquant des durées un peu longues pour certaines tâches (notamment le développement de la version 1.1). Les différences entre les deux Gantt sont importantes puisque des tâches ont disparu pour être remplacées par d autres. La gestion du projet a été prévue dès le départ pour pouvoir s adapter à tout changement, en respectant notamment les principes Scrum. Il a donc été facile de changer les tâches en cours de projet, en repensant et replanifiant les nouvelles tâches à chaque itération. NetEffMon v2 59

60 Chapitre 5. Gestion de projet Gestion du temps Observations Optimisation du front-end Optimisation du SGBD Optimisation de la BDD Création d une API Affichage des mesures Gestion des utilisateurs Mois Novembre Decembre Janvier Février Mars Avril Figure 5.3 Gantt prévisionnel Prise en main Rédaction CdS Développement v1.1 Définition spécif. v2 Choix technologiques v2 Développement v2 Tests et corrections v2 Rédaction rapport Mois Novembre Decembre Janvier Février Mars Avril Figure 5.4 Gantt final du projet Nous pourrions nous interroger sur l utilité du développement de la version 1.1. En réalité, cette version a permis de prouver plusieurs choses. Dans un premier temps, elle nous permis de nous assurer que la lenteur du front-end était due à une erreur de développement de la version 1. Dans un deuxième temps, en permettant de réfléchir à une amélioration du requêtage du web-service, elle a également permis d améliorer le processus de communication, et donc indirectement d avancer les spécifications de la version 2. Enfin, c est durant ce développement que les interrogations sur la pérennité des choix déjà effectués sont arrivées. Nous pouvons également voir que la tâche Choix technologiques v2 est relativement longue. Cela est dû aux spécifications précédemment définies. Le but principal était de rendre le système pérenne. De ce fait, les choix technologiques importent beaucoup. De plus, nous nous sommes penchés sur des systèmes peu déployés aujourd hui et pas étudiés au sein du cursus du Département Informatique. La compréhension globale de ces derniers, puis la justification du choix effectué ont donc nécessité un certain temps. Enfin, cette tâche contient également la définition de l architecture du projet et donc une phase de réflexion sur le diagramme de classe utilisé. Finalement, nous pouvons voir que cette phase de choix a été plutôt un bon investissement puisque la phase de développement est assez courte. La tâche Tests et corrections a pris également un peu de temps. Cette dernière porte sur la constatation de certains problèmes imprévus, tels que les requêtes prenant un temps trop long, nous forçant alors à essayer de trouver une solution pour limiter cet impact. NetEffMon v2 60

61 Construction d une application WebScale avec HBase Cette partie vise à proposer une sorte de guide pour construire une application avec HBase. Après avoir effectué le travail nécessaire pour NetEffMon, nous avons appris quelques principes nécessaires à la construction d une telle application. Il nous a semblé intéressant de faire part de ces connaissances acquises au sein de ce rapport. 6.1 Réflexion préalable Avant de se lancer dans ce type de projet, il convient de bien réfléchir à nos problématiques et à ce que nous allons chercher à faire dans le futur. Utiliser une architecture telle que HBase (ou un système NoSQL d ailleurs), apporte des fortes contraintes, et va forcer le développeur à gérer lui-même des problématiques qui pourraient être gérées «automatiquement» par un système de gestion de base de données relationnelles. De plus, la configuration matérielle demandée est nettement plus importante, même dès le début du projet (il faut une configuration importante même avec «peu» de données). Aussi, la configuration et le déploiement sont des tâches nettement plus complexes à réaliser pour HBase que pour des systèmes plus classiques tels que PostgreSQL, pour ne citer que lui La volumétrie Le premier point sur lequel il faudrait se pencher avant d effectuer son choix est la volumétrie des données que l application va être amenée à gérer. Dans un contexte «big-data», il est très important de s assurer que la volumétrie est vraiment difficile à gérer. Effectivement, il ne faut pas se laisser impressionner par un volume inhabituellement important. Dans la majorité des cas, une table avec quelques dizaines de millions de lignes est considérée comme une table importante par des développeurs n ayant jamais eu à se confronter à des problèmes de big-data. Mais en réalité, cette volumétrie n est finalement pas aussi importante qu elle n y parait. La plupart des systèmes relationnels classiques sont largement capables de gérer ce type de volumétries. HBase a été créé pour répondre à des contraintes bien plus fortes. Effectivement, ce système a été créé pour gérer des volumétries de plusieurs milliards de lignes, avec chacune plusieurs millions de colonnes. Il est donc évident que ce type de volumétries n apparait pas dans la totalité des projets. Cependant, il ne faut pas non plus tomber dans la facilité : il ne faut pas chercher à utiliser HBase et sa capacité à gérer de grosses volumétries pour éviter d avoir à mieux penser le modèle des tables. Certains développeurs pourraient être tenter d utiliser ce type de systèmes pour éviter d avoir à réfléchir à quelles données ils ont besoin, et stocker la moindre information, même si ils n en auront jamais l utilité. Nous sommes persuadés que cette approche est mauvaise et ne permet pas de produire une application de qualité, malgré les capacités offertes par HBase. NetEffMon v2 61

62 Chapitre 6. Construction d une application WebScale avec HBase Réflexion préalable Le schéma des données Un deuxième point sur lequel il faut se pencher, c est sur le schéma des données qui vont être stockées. HBase n est pas un système relationnel, il est donc impossible de lui indiquer la moindre relation entre deux données stockées. Il est évidemment possible de gérer ce type de problématique «manuellement», en effectuant des requêtes «croisées». Cependant, ce sera au développeur de gérer l ensemble de la logique, pouvant allonger grandement le temps de développement, peut amener des bugs et éventuellement ralentir le système. Il nous semble important de se pencher sur ce problème : si nos données et l ensemble des requêtes que nous allons effectuer reposent principalement sur les relations entre ces dernières, HBase n est pas forcément le plus adapté. Ensuite, il convient de bien concevoir le schéma de la base de données et de ne pas tomber dans un piège : les schémas des tables HBase sont «évolutifs». Ces derniers ont la possibilité d être modifiés «à chaud», c est à dire que deux lignes d une même table n ont pas forcément les mêmes colonnes. Une fois encore, et comme évoqué dans la partie précédente, choisir HBase juste pour la possibilité de faire évoluer le schéma à chaud nous semble être une extrêmement mauvaise idée et amène plus un développement de mauvaise qualité et peu stable plutôt qu un système «qui peut s adapter à tout». Bien que les schémas soient évolutifs, il nous semble important de correctement les définir La disponibilité des ressources nécessaires HBase fonctionne sur un cluster de machines, sur lequel Hadoop doit également être déployé. La phase de déploiement et de configuration est une phase complexe qui nécessite des compétences dans ce domaine. Mais en dehors de la phase initiale de déploiement, il est nécessaire de permettre à HBase de fonctionner correctement. Après avoir effectuer quelques recherches à des fins de comparaisons, nous n avons pas réellement trouvé de configuration minimum requise pour un système de gestion de base de données classique tel que PostgreSQL. Nous ferons donc la comparaison sur la configuration requise pour déployer une distribution Linux : Debian, sans bureau graphique. PostgreSQL Hbase Processeur Pentium 4 1Ghz 2 * Quad Core 2-2,25Ghz Stockage 1 Go 4 * 1 To dans JBOD Mémoire vive 256 Mo Go Table 6.1 Comparaison du matériel nécessaire pour PostgreSQL et HBase La comparaison effectuée dans le tableau 6.1 n est pas vraiment «équitable» : la configuration renseignée pour HBase est celle nécessaire pour obtenir des performances correctes sur des grosses volumétries de données, alors que celle proposée pour PostgreSQL est celle recommandée pour faire fonctionner Debian. Il est facile de penser que PostgreSQL aura certainement besoin de bien plus pour pouvoir répondre assez rapidement à de grosses requêtes. Cependant, nous pouvons noter que la différence entre les deux configurations est importante. HBase demande de lourdes configurations, et d après les tests effectués durant ce projet, stocker 100 millions de points pourrait occuper jusqu à 120 Go sur le disque dur. Egalement, avec une configuration plus faible («seulement» 8Go de RAM), le cluster met plusieurs heures à répondre à certaines requêtes. NetEffMon v2 62

63 Chapitre 6. Construction d une application WebScale avec HBase Utilisation de HBase Il est donc très important d avoir conscience de ces contraintes matérielles dès le départ du projet pour pouvoir s assurer que nous pourrons y répondre dès le début des développements Pourquoi HBase plutôt qu un autre? Il existe un certain nombre de systèmes NoSQL sur le marché, permettant de gérer des gros volumes de données. Chacun d entre eux est créé pour répondre à certaines problématiques. Ce serait une erreur de penser que chacun d entre eux cherche à répondre aux mêmes problématiques. Chaque système a ses points forts et ses points faibles et en choisir un en particulier n est pas un choix anodin. HBase se présente lui-même d une manière claire et précise nous permettant de bien comprendre les problématiques qu il souhaite résoudre (traduction de l anglais) : Utilisez Apache HBase lorsque vous avez besoin d un accès aléatoire et en temps réel et en lecture/écriture à vos grosses volumétries de données. Le but de ce projet est d héberger des très larges tables des milliards de lignes X des millions de colonnes [...]. Si nos besoins sont bien ceux évoqués ci-dessus, HBase est un candidat potentiel. Quoi qu il arrive, il convient de vérifier plusieurs autres solutions pour s assurer que HBase est le système qui répond le mieux à nos besoins. 6.2 Utilisation de HBase Au début du projet, nous avons été un peu perdu dans le fonctionnement de HBase. Quelques points importants sont à noter, notamment l utilisation de Zookeeper. Ce module Hadoop permet de répliquer les configurations depuis le MasterServer vers les RegionServers. Grâce à l utilisation de ce module, il est imporant de se souvenir que les principales actions d administration doivent être effectuées depuis le MasterServer. Par exemple, l arrêt de HBase sur les RegionServers doit être demandé depuis le MasterServer. Celui-ci se chargera d effectuer les bonnes actions sur les autres machines du cluster. Nous pouvons également noter qu il vaut veiller à bien éteindre les machines du cluster. Effectivement, chacune d entre elles possède une partie des données. Ces données vont devoir être copiées sur les machines encore en fonctionnement du cluster avant d éteindre le serveur concerné. Une commande, présentée dans le code 19, permet de s assurer que ces migrations sont correctement effectuées. 1./<HBASE_HOME>/bin/gracefull_stop.sh <nom de la machine> Code 19 Extinction d une machine du cluster HBase 6.3 Définition du schéma de données Dans une application qui va s organiser autour d une base de données, il est nécessaire de définir de quelle manière les données vont être stockées. Bien que les schémas de HBase soient évolutifs (cf. partie 6.1.2), il reste nécessaire de le définir et de noter la façon dont les données sont représentées dans les différentes tables. Sans cette information, le développeur ne saura pas comment requêter la base de données. NetEffMon v2 63

64 Chapitre 6. Construction d une application WebScale avec HBase Architecture globale Ce document comporte déjà les informations nécessaires pour correctement définir le schéma de données. Il est donc possible de se reporter tout d abord à la partie pour bien comprendre comment les données sont stockées dans HBase, puis à la partie pour obtenir des conseils sur la définition du schéma de données. 6.4 Architecture globale Après avoir vérifier que HBase est bien le système dont nous avons besoin, puis après avoir défini la façon dont nous allons stocker nos données, nous pouvons commencer à développer notre application. Il est nécessaire de comprendre que dans notre cas, il est mal venu de ne pas passer du temps à définir l architecture du système. Effectivement, dans un cadre temps réel et gros volumes de données, le moindre manque d optimisation peut amener de très fortes pertes de performances. Nous pensons également qu il est nécessaire de garder une plateforme la plus évolutive possible. Dans un premier temps, cela permettra d évoluer rapidement avec HBase si celui-ci change radicalement d orientation, mais également de pouvoir corriger une erreur d optimisation sans avoir à changer l ensemble de la plateforme. Figure 6.1 Architecture d une application utilisant HBase La figure 6.1 semble permettre de répondre à ces différentes problématiques. Nous considérons ici que nous utilisons le web service de HBase pour accéder aux données stockées. Comme il est possible de le NetEffMon v2 64

65 Chapitre 6. Construction d une application WebScale avec HBase Architecture globale voir, nous n accédons en permanence qu au serveur master du cluster. Cependant, nous empêchons les utilisateurs d y accéder eux-mêmes, en mettant un serveur web (Apache HTTP server, nginx,... ) face à ce dernier. Ce serveur web n est pas le web service de HBase et constitue bien une surcouche à ce dernier, de façon à pouvoir gérer le flux entrant. Egalement, et pour répondre à la problématique d évolutivité évoquée plus haut, nous pensons qu il est nécessaire de créer un ensemble de classe d accès aux données. Ces dernières ont connaissance de toute la logique nécessaire pour accéder, tant en lecture qu en écriture, aux données présentes dans la base de données. Ce sont aussi ces classes qui devraient être chargées de correctement s identifier auprès du serveur web, si nécessaire. Un autre module devrait se charger des données reçues par les classes d accès aux données. Ce module devrait utiliser les threads intelligemment pour assurer la possibilité de monter en charge. C est également ce module qui devrait chercher à interagir avec Hadoop pour permettre l utilisation du principe Map/Reduce. Enfin, rappelons que l ensemble des liaisons réseau présentées ici doivent être en Gigabites, de façon à nous assurer que le réseau ne sera pas un goulot d étranglement. NetEffMon v2 65

66 Conclusion A l heure actuelle, le projet comporte un ensemble de solutions fiables et fonctionnelles, à l exception du front-end qui souffre de légères lacunes. L ensemble du projet a été conçu et pensé pour permettre une évolutivité maximum et une maintenabilité la plus aisée possible. Se reposant sur des outils standards et largement utilisés dans le domaine du développement informatique - tels que Maven, Git et Django - ce dernier peut facilement être pris en main par d autres personnes. Malgré une architecture saine, le projet souffre aujourd hui de gros problèmes de performances. Ces problèmes portent principalement sur la gestion du stockage des données, qui ne faisait pas partie du périmètre initial. Considérant que cette partie devrait être gérée par un administrateur système, nous avons choisi de ne pas nous y attarder avant la toute fin du projet pour pouvoir fournir avant tout les fonctionnalités prévues. Le problème vient du temps nécessaire pour la récupération d une partie des points stockés dans la base de données. Le réseau ayant été «optimisé», nous avons réfuté l hypothèse qui impliquait que c est la lenteur du réseau qui générait un temps de récupération très long. De plus, en nous penchant sur les trames échangées, nous nous sommes aperçus que la perte de temps la plus importante avait lieu avant le début des transferts de données. Avec des durées d exécution des requêtes côté serveur beaucoup trop longues, nous nous sommes aujourd hui focalisés sur des hypothèses incriminant à chaque fois la configuration du cluster. Certains de ces points sont discutés dans la partie 4. Finalement, nous pouvons affirmer aujourd hui que les objectifs fixés après le déploiement de la version 1.1 sont respectés. Le système actuel dialogue correctement avec un système HBase. L architecture mise en place pourrait permettre une évolution «rapide» vers un autre système de stockage des données - il ne sera pas nécessaire de redévelopper l ensemble des algorithmes pour pouvoir changer de système. Cette évolutivité est importante, surtout dans notre cas, où de graves problèmes sont notés et pourraient aisément justifier un changement radical de solution. NetEffMon v2 66

67 Liens et références Documentation officielle de HBase (EN) Configuration recommandée pour HBase - par Cloudera (EN) Forge de NetEffMon Documentation pour HBase Shell (EN) Documentation pour Stargate (EN) Bigtable : A Distributed Storage System for Structured Data (EN) NetEffMon v2 67

68 Glossaire API Acronyme de Application Programming Interface. C est une interface offerte par un programme pour communiquer avec ce dernier depuis un autre programme extérieur. 24, 37, 41, 42, 68, 70 cluster Ensemble d ordinateurs connectés entre eux, et travaillant ensemble. Vus de l extérieur, ces machines peuvent ainsi être considéré comme un seul «gros ordinateur». 17, 19, 21, 24, 36, 51, 52, 62, 63, 65, 66, 68 commit Dans un système de gestion de version, désigne l action d enregistrer un ensemble de modification et de les regrouper ensemble. Cet ensemble de modification est associé à un identifiant unique puis à un message. Nous appellerons cet ensemble un commit car la commande Git permettant d effectuer cette action est git commit. 58, 68 curl Programme proposant une ligne de commande sous Linux permettant de transférer des données en utilisant plusieurs protocoles. Dans notre cas, ce programme fut utilisé pour tester les requêtes en ayant la possibilité de visualiser la totalité des Header HTTP. 68 deserialization Consiste à «transformer» une série de bytes, ou une chaine de caractères, en un objet. L opération inverse est la serialization. 38, 41, 68, 70 Django Framework web en Python visant à permettre un développement rapide, propre et «pragmatique».. 42, 66, 68 framework Ensemble de composants logiciels permettant de créer les bases de l architecture d un système. Il se distingue d une bibliothèque par le fait qu il est générique et qu il n a pas pour but d effectuer des traitements particuliers (il est non spécialisé). Egalement, il guide l architecture logicielle en forçant le développeur à respecter certaines normes alors qu une bibliothèques laisserait ce choix au développeur. 19, 68 front-end Partie d un projet en charge de récupérer les interactions de l utilisateur avec le système. Il englobe l interface utilisateur, mais également la gestion des traitements des entrées avant l envoi vers le back-end et la réception des résultats à afficher à l utilisateur. 38, 40 42, 47, 60, 68 geohash Geocode d un couple latitude/longitude. Ce dernier a été inventé par Gustavo Niemeyer, développeur du web-service Un geocode consiste à représenter des informations géolocalisées sous une forme normalisée en permettant ensuite de retrouver les coordonnées géographiques. Nous pourrons noter que le Geohash produit des erreurs sur la recherche des voisins sur les points de part et d autre de l équateur. 35, 51, 68 GET Méthode HTTP particulière. Elle est définit principalement pour récupérer des données.. 27, 68 Git desc. 56, 66, 68 hash Résultat provenant d une «fonction de hashage». Cette dernier vise à réduire la taille d une variable en effectuant un certain nombre d opération sur la variable initiale pour retourner une valeur plus petite (le hash). Lorsque deux variables différentes donnent le même hash, il est dit «qu il y a collision». 35, 68 HBase Système NoSQL non relationnel et distribué, écrit en Java. Une description plus précise est lisible dans la partie 2.2 (page 15). 17, 35, 47, 68 NetEffMon v2 68

69 Glossaire Glossaire HDFS HDFS est l acronyme de Hadoop Distributed Filesystem. C est un système de fichiers destinés à être utilisé dans un environnement distribué.. 17, 68 Header HTTP Information transmise entre les acteurs d un échange via le protocole HTTP. Beaucoup d informations utiles peuvent être transmises via les headers, notamment : le type de contenu envoyé, le type de contenu accepté en réception, la taille du contenu, le status de la requête... Une liste de ces headers peut être consultée ici : 24, 68 HTTP Acronyme de HyperText Transfer Protocol. C est un protocole utilisé pour le transfert d informations entre les applications, mais égalemen le protocole le plus utilisée sur le World Wide Web. Il définit un certain nombre de méthodes permettant de transférer ou de demander le transfert de données. GET, POST, PUT, DELETE sont les plus connues et les plus utilisées. Des informations plus précises peuvent être trouvées ici : 24, 25, 68, 69 KML Acronyme de Keyhole Markup Language. C est une notation XML particulière permettant de représenter des données géographiques dans applications de cartes en 2D ou de représentation de la Terre en 3D. Il a été initialement créé par Keyhole, Inc, qui fut racheter par Google en Ce format est aujourd hui un standard du Open Geospatial Consortium. 41, 46, 68 Maven Outil permettant de gérer des projets basés sur le langage Java. Une description plus précise est faite dans la partie (page 54). 31, 54, 56, 66, 68 MVC Acronyme de Modèle-Vue-Contrôleur. C est une architecture de code (un patron) particulier permettant de séparer chacun des différents modules d un programme. Les modèles se chargent de gérer l accès et la représentation des données. Les vues sont chargées d afficher le contenu sur l écran des utilisateurs (interface utilisateur). Enfin, les contrôleurs se chargent de gérer les évènements, la synchronisation, les différents traitements NoSQL Désigne une catégorie de systèmes de gestion de base de données. Ces derniers sont principalement amenés à gérer des gros volumes de données. Chacun utilise des techniques particulières pour réussir à répondre à ce type de problématique. 47, 68 parsing Opération consistant à analyser une chaîne de caractères selon des règles de grammaire prédéfinies. 11, 36, 41, 68 POST Méthode HTTP particulière. Elle est définit principalement pour permettre le transfert de données entre l émetteur et le destinataire.. 25, 68 PUT Méthode HTTP particulière. Elle est définit principalement pour indiquer au destinataire que les données envoyées devraient être stockées.. 25, 68 REST REST est un acronyme pour Representational State Transfer. Ce n est pas un protocole mais une architecture. Il permet de régire les communications entre différents acteurs. Il particulièrement bien adapté aux utilisations au travers du World Wide Web, surtout via le protocole HTTP mais n y est pas limité. Cette architecture définit notamment plusieurs buts principaux : Scalability des interactions Généralisation des interfaces Déploiement indépendant des différents composants Composants intermédiaires permettant de réduire la latence et augmenter la sécurité Enfin, elle définit également six contraintes : Client-server Une interface sépare les clients des serveurs. Par exemple, les clients ne se soucient pas du stockage des données. NetEffMon v2 69

70 Glossaire Glossaire Stateless La communication client-serveur n amène pas de stockage de contexte côté serveur : à chaque requête, le serveur considère que c est le premier dialogue qu il effectue avec le client. Cacheable Le serveur doit gérer la mise en cache de certaines des réponses pour s assurer que le client utilise toujours la bonne version des données tout en supprimant certaines interactions inutiles. Layered system Le client ne devrait pas pouvoir définir si il est connecté au serveur principal ou à un serveur intermédiaire. Les serveurs intermédiaires ont pour but de distribuer la charge et d améliorer la sécurité. Code on demand (optionnel) Les serveurs peuvent avoir la possibilité de personnalisé le fonctionnement du client en envoyant des portions de code. Uniform interface Utiliser une interface de communication uniforme permet à chacun des composants d évoluer sans avoir à modifier l ensemble des autres composants. (Source : en.wikipedia.org/ wiki/ Representational_state_transfer). 68, 70 RESTful Un web service RESTful est une API utilisant le protocole HTTP et les principes REST. 24, 41, 46, 68 scalability Mot anglais qui n a pas de traduction français. Ce terme désigne la capacité d un produit à s adapter à une montée en charge (forte augmentation de la demande). Cette capacité induit que le système de connaitra pas de pertes de fonctionnalités ni une trop grande augmentation du temps de traitement lorsque les demandes seront plus nombreuses scalable Se dit de ce qui a une grande scalability. Il n existe pas de traduction correcte en français. 17, 19, 68 serialization Consiste à «transformer» un objet en une série de bytes, ou une chaine de caractères. L opération inverse est la deserialization. 36, 38, 41, 68 timestamp Mot anglais pouvant être traduit par «horodatage». C est une séquence de caractère permettant de désigner une heure/date. Le timestamp le plus connu est le «Unix time» qui est le nombre de secondes (et par extension de milli ou nano-secondes) écoulées depuis le 1 er janvier 1970 à 00h00m00s UTC. 23, 35, 68 web-service Programme permettant la communication entre différents acteurs d un système distribué. 68 XML Acronyme de EXtensible Markup Language. C est un langage de balisage permettant de définir un ensemble de règles pour encoder des documents pouvant à la fois être lu par un humain et par une machine.. 46, 68, 69 NetEffMon v2 70

71 Spécifications de l application Android A.1 Android A.1.1 Objectifs Une application permettant d obtenir des mesures géolocalisées de la qualité du réseau data et de les transmettre à un serveur distant. A.1.2 Utilisation L application démarre avec l interface présentée sur la figure A.1. Avant de pouvoir démarrer les captures, il faut définir un nom de session, qui correspondra plus tard au nom du dossier où les fichiers de captures seront enregistrés, ainsi que le type de transport utilisé lors des captures. Le choix du type de transport permet d en déduire une distance minimale à partir de laquelle un nouvel enregistrement est effectué. Pour simplifier le processus, un nom de session par défaut, composé de la date et l heure courante, est proposé à l utilisateur, celui-ci pouvant le modifier. Une fois cette étape franchie, l utilisateur peut démarrer une session de capture. Cela nécessite qu une connexion permettant le transfert de données soit effective. L utilisateur peut, durant la prise de mesures, sortir à tout moment de l application : celle-ci tournera en tâche de fond. Il peut également mettre l application en pause puis la redémarrer. Lorsque les mesures sont lancées, une checkbox indique lorsque le fix GPS est obtenu. Les mesures étant géolocalisées, ce fix correspond au moment où le téléphone reçoit les coordonnées GPS grâce à sa puce GPS. Un chronomètre indique la durée de la session et un compteur précise le nombre de points ayant été enregistrés. Lorsque l enregistrement est terminé, après appui sur le bouton stop, l utilisateur peut envoyer ses mesures sur le serveur. Pour cela il lui suffit de choisir le nom de la session qu il veut envoyer. NetEffMon v2 71

72 Annexe A. Android Spécifications de l application Android Figure A.1 Interface principale de l application Android NetEffMon v2 72

73 Annexe A. Android Spécifications de l application Android A.1.3 Fichier de sortie Les fichiers obtenus sont au format KML et se présente de la manière suivante : 1 <?xml version= 1.0 encoding= UTF-8?> 2 <kml xmlns=" 3 <Document> 4 <Placemark> 5 <ExtendedData> 6 <time>092208</time> 7 <speed>0.0</speed> 8 <fixquality>44.0</fixquality> 9 <satellites>0</satellites> 10 <roaming>false</roaming> 11 <signalstrength>-87</signalstrength> 12 <networktype>umts</networktype> 13 <operateur>orange F</operateur> 14 </ExtendedData> 15 <Point> 16 <coordinates> , , </coordinates> 17 </Point> 18 </Placemark> 19 <Placemark> 20 <ExtendedData> 21 <time>092208</time> 22 <speed>0.0</speed> 23 <fixquality>44.0</fixquality> 24 <satellites>0</satellites> 25 <WifiSSIDs></WifiSSIDs> 26 </ExtendedData> 27 <Point> 28 <coordinates> , , </coordinates> 29 </Point> 30 </Placemark> 31 <Placemark> 32 <ExtendedData> 33 <time>092208</time> 34 <speed>0.0</speed> 35 <fixquality>44.0</fixquality> 36 <satellites>0</satellites> 37 <pinggoogle>407.0</pinggoogle> 38 </ExtendedData> 39 <Point> 40 <coordinates> , , </coordinates> 41 </Point> 42 </Placemark> 43 <TimeSpan> 44 <begin> :21:53</begin> 45 <end> :22:17</end> 46 </TimeSpan> NetEffMon v2 73

74 Annexe A. Android Spécifications de l application Android 47 </Document> 48 </kml> Code 20 Exemple fichier de sortie application Android, API v3 Pour chaque point, il y a 3 Placemark associées. Celles-ci possèdent tous une balise Point avec les coordonnées géographiques du point ainsi qu une balise ExtendedData qui contient les informations relatives à la mesure réalisée. A Balises communes Les balises communes sont celles liées à la géolocalisation. Ces balises ne sont pas forcément toutes utilisées par le serveur mais nous préférions fournir le plus d informations possibles en émettant l hypothèse qu elles pourraient êtres exploitées plus tard. Nous trouvons donc comme informations : - time : l heure de l enregistrement de la mesure au format hhmmss - speed : la vitesse de déplacement en m/s - fixquality : La précision en mètre - satellites : Le nombre de satellites utilisé - coordinates : correspondant dans l ordre à : longitude, latitude (en degré décimal) et altitude en mètre. A Puissance du signal La balise ExtendedData de la première placemark contient les informations relatives à la connexion data : - roaming : True si l application est en roaming (itinérance), false sinon. - signalstrength : la puissance du signal en dbm - networktype : le type de réseau (EDGE/UMTS/HSPA... correspondant à 2G/3G/3G+... ) - operateur : l opérateur mobile A PingGoogle La seconde placemark contient la valeur de retour d un ping vers : - pinggoogle : temps de réponse en millisecondes. A WifiSSIDs Enfin, la dernière placemark contient des informations wifi, à savoir les points d accès détectés. Cette information n est pas utilisé par le serveur mais encore une fois, nous préférions obtenir le plus d informations possibles. A la fin de ces enregistrements, une balise TimeSpan indique le jour et l heure du début et de l arrêt de l enregistrement. NetEffMon v2 74

75 Annexe A. Android Spécifications de l application Android L avantage de l utilisation du KML est que le fichier produit peut-être interprété par d autres applications, comme par exemple Google Earth, nous permettant déjà de visualiser l ensemble des points enregistrés sur une carte. A.1.4 Description du code Voyons maintenant comment nous avons obtenus ces résultats. Pour cela, commençons par la liste des classes définies : - ConnectWebService : gère l upload de fichiers sur le serveur - CountingMultipartEntity : permet de structurer les données à uploader et de suivre la progression de leur envoi - DateUtils : fournit des méthodes statiques pour obtenir la date et l heure - FileManager : offre différentes méthodes aidant à la gestion des fichiers - Geolocalisation : récupère les coordonnées GPS et autres informations de géolocalisation - GeolocalisationBinder : permet d accéder au service géolocalisation de l extérieur - GeolocalisationListener : permet d écouter les mises à jour du service - GeolocalisationService : interface facilitant l utilisation du service - IMeasure : interface facilitant la gestion des mesures - Kml : gère la création d un fichier au format KML - LocationData : structure les données de géolocalisation - MeasureBaseMeasure : classe abstraite facilitant la gestion des mesures - MeasurePingGoogle : permet d effectuer la mesure du ping vers - MeasuresService : Le service gérant les mesures, la géolocalisation et les enregistrements - MeasuresServiceBinder : permet d accéder au service MeasuresService depuis l extérieur - MeasuresServiceListener : permet d écouter les mises à jour du service - MeasureWifiSSIDs : permet d effectuer la capture des SSIDs wifi - NetEffMonActivity : classe principale gérant l affichage et le démarrage du service - NetworkManager : permet d effectuer les mesures de la puissance du signal - ResultMeasure : permet de structurer les résultats des mesures effectuées Nous allons maintenant décrire le fonctionnement des classes les plus importantes et leurs interactions. A NetEffMonActivity NetEffMonActivity est la classe principale de l application. C est elle qui crée les autres éléments et gère l affichage et les interactions avec l utilisateur. Son premier rôle est donc de récupérer les éléments graphiques définit dans le fichier res/layout/main.xml, puis de définir les actions liées à l appui sur les différents boutons fournis. A savoir, saisir le nom de session, le type de transport grâce à des dialogues, démarrer/arrêter le service, uploader une session. Elle fournit également des statistiques sur les captures : indique si le GPS est synchronisé, pour cela un listener est utilisé pour écouter le service de Géolocalisation ; la durée d exécution du service grâce à un objet Chronometer ; le nombre de points enregistrés encore une fois grâce au listener écoutant le service géolocalisation. NetEffMon v2 75

76 Annexe A. Android Spécifications de l application Android L upload des fichiers est lancé à partir de cette classe. Afin de réaliser l upload sans bloquer l application, il est nécessaire d utiliser un thread. Cependant, voulant obtenir le suivi de l upload, il est nécessaire de rester dans la classe Activity. Pour gérer cela facilement, le SDK d Android fournit un outil parfaitement adapté : AsyncTask. Celle-ci possède la structure suivante : 1 private class SendKmlTask extends AsyncTask<File, Integer, Boolean> { 2 protected Boolean doinbackground(file... files) { } 5 protected void onprogressupdate(integer... progress) { } 8 protected void onpostexecute(boolean result) { } 11 } Code 21 NetEffMonActivity : Tâche asynchrone SendKmlTask réalisant l upload En héritant de AsyncTask, la classe SendKmlTask (membre de la classe NetEffMonActivity) exécute un thread en fond dans la méthode doinbackground, suit la progression dans la méthode onprogressupdate qui a la particularité de pouvoir gérer l interface alors que nous nous ne trouvons pas directement dans l UI Thread (la classe Activity). Puis lorsque le traitement réalisé dans la méthode doinbackground est terminé, le résultat renvoyé est réceptionné par la méthode onpostexecute. C est donc dans la méthode doinbackground, que la classe ConnectWebService est utilisée grâce à la méthode statique connexionserveur qu elle fournit. Chaque fichier présent dans la session sélectionnée est stocké dans une instance de la classe CountingMultipartEntity. Cette classe, en plus de fournir une structure balise-valeur, permet de suivre la progression de l upload octet-par-octet grâce au listener ProgressListener qu elle gère. A partir de là nous pouvons signaler la progression de l upload grâce à la méthode publishprogress qui appelle la méthode onprogressupdate pour qu elle puisse mettre à jour les barres de progressions suivant l avancement du nombre de fichiers envoyés et le nombre d octets envoyés par fichier. Lorsque les traitements sont terminés la méthode onpostexecute vérifie que l upload s est bien déroulé en s assurant que le nombre d octets transmis est le même que le nombre d octets constituant la taille totale de l enregistrement. A MeasuresService Le service MeasuresService est démarré depuis la classe NetEffMonActivity de la manière suivante : 1 Intent intentmeasures = new Intent(context, MeasuresService.class); 2 bindservice(intentmeasures, connectionmeasures, Context.BIND_AUTO_CREATE); Code 22 NetEffMonActivity : Démarrage du service MeasuresService NetEffMon v2 76

77 Annexe A. Android Spécifications de l application Android L objet de type Intent permet de transférer certaines informations nécessaires à l exécution de la classe MeasuresService. Pour cela, la méthode putextra est utilisée : 1 intentmeasures.putextra("session", session); 2 intentmeasures.putextra("transport", distances[item]); Code 23 NetEffMonActivity : Transfert d informations de l Activity au service session est le nom de la session, il est nécessaire pour enregistrer les mesures au sein du répertoire du même nom. distances[item] est la distance minimale entre deux points, sélectionnée à partir du choix du mode de transport ou définit directement par l utilisateur. Le service démarre par la méthode _onbind() qui permet de récupérer les informations transmises précédemment. Ensuite la méthode _onstart() est exécutée, démarrant réellement le service. L appel à la méthode héritée de la classe Service startforeground est réalisé ici. Cet appel est très important puisqu il définit le service comme étant un service de haute priorité. Nous reviendrons plus tard sur l importance de ce point. Pour terminer la méthode _onstart démarre un autre service : celui de géolocalisation. Lorsque le service de géolocalisation est démarré, deux timer sont activés. Le premier permet de lancer des mesures toutes les secondes. Tandis que le second ajoute, toutes les 10 secondes, les résultats obtenus dans un fichier KML. 1 private class timerupdate extends TimerTask 2 { 3 public void run() 4 { 5 performmeasures(); 6 } 7 } 8 private class timerwritedown extends TimerTask 9 { 10 public void run() 11 { 12 resultswritedown(); 13 checkdumpplacemarks(); 14 } 15 } 16 this.kaboom.scheduleatfixedrate(new timerupdate(), 5000, 1000); 17 this.writedown.scheduleatfixedrate(new timerwritedown(), 10000, 10000); Code 24 MeasuresService : Timer gérant la prise de mesures La méthode performmeasures récupère la position GPS actuelle fournie par le service de géolocalisation puis, si celle-ci est connue et si sa distance par rapport au dernier point enregistré est supérieure à la distance minimale, lance les différents threads réalisant les mesures voulues : NetEffMon v2 77

78 Annexe A. Android Spécifications de l application Android 1 public void performmeasures() 2 { 3 // Si le service de geolocalisation est demarre 4 if (this.allowedbythename) { 5 this.lastgeoloc = this.getlastgeoloc(); 6 // Si la position a bien ete recue et si la distance 7 // est superieure a la distance minimale 8 if (this.lastgeoloc.hasfix && this.distanceisokay()) { 9 this.registernewthreads(); 10 this.executethreads(); 11 } else { 12 Log.e("MeasuresService", "Not starting threads: no location."); 13 } 14 this.probethreads(); 15 this.getresults(); 16 } 17 } public void registernewthreads() 20 { 21 this.networkmanager = new NetworkManager(this.context, psl); 22 this.measures.add(networkmanager); 23 this.measures.add(new MeasurePingGoogle()); 24 this.measures.add(new MeasureWifiSSIDs(this.context)); 25 } 26 public void executethreads() 27 { 28 Iterator itthread = this.measures.iterator(); 29 while(itthread.hasnext()) { 30 Object o = itthread.next(); 31 IMeasure m = (IMeasure)o; 32 m.setgps(this.lastgeoloc); 33 Thread t = (Thread)o; 34 t.start(); 35 this.measuresrunning.add(t); 36 itthread.remove(); 37 } 38 } Code 25 MeasuresService : Méthodes performmeasures, registernewthreads, executethreads Chaque mesure est donc associée à son lancement à un point géographique dans la méthode executethreads grâce à setgps. probethreads() parcours la liste des threads lancés, si le thread a terminé sa mesure, le résultat est ajouté à la liste des résultats à traiter. getresults() parcours cette liste pour récupérer les résultats et les ajouter dans la liste des résultats à enregistrer dans le fichier KML. 1 public void probethreads() 2 { NetEffMon v2 78

79 Annexe A. Android Spécifications de l application Android 3 Iterator itthread = this.measuresrunning.iterator(); 4 while(itthread.hasnext()) { 5 Object o = itthread.next(); 6 IMeasure m = (IMeasure)o; 7 if (m.finished()) { 8 this.measuresfinished.add(m); 9 itthread.remove(); 10 } 11 } 12 } 13 public void getresults() 14 { 15 Iterator itthread = this.measuresfinished.iterator(); 16 while(itthread.hasnext()) { 17 Object o = itthread.next(); 18 IMeasure m = (IMeasure)o; 19 this.results.add(m.getresults()); 20 itthread.remove(); 21 } 22 } Code 26 MeasuresService : Méthodes probethreads, getresults Le deuxième timer exécute alors la méthode resultswritedown qui vide la liste des résultats dans le fichier KML. La méthode checkdumpplacemarks permet de compter le nombre de points déjà présents dans le fichier KML. Si celui-ci est supérieur à la limite fixée, les nouveaux points sont enregistrés dans un nouveau fichier KML grâce à la méthode performwrite utilisant la classe FileManager. Nous reviendrons plus tard sur la nécessité de limiter le nombre de points par fichier. 1 public void resultswritedown() 2 { 3 Iterator itresult = this.results.iterator(); 4 int nbnode; 5 while(itresult.hasnext()) { 6 Object o = itresult.next(); 7 ResultMeasure r = (ResultMeasure)o; 8 this.nbrecordedpointsinc(); 9 nbnode = this.kmlwriter.addnode(r); 10 this.setnbplacemark(nbnode); 11 this.results.remove(o); 12 } 13 } 14 public void checkdumpplacemarks() 15 { 16 if (this.getnbplacemark() >= this.nbmaxplacemark) { 17 Log.e("Placemarks", "Too many, dumping..."); 18 this.performwrite(); 19 this.nbrecord += 1; 20 this.setfirststart(); NetEffMon v2 79

80 Annexe A. Android Spécifications de l application Android 21 this.setnbplacemark(0); 22 } 23 } private String performwrite() 26 { 27 String filename = "sortie_neteffmon_n" + String.valueOf(this.nbRecord) + ".kml"; 28 this.datestop = DateUtils.now(); 29 String data = this.kmlwriter.enddoc(this.datestart, this.datestop); 30 FileManager FM = new FileManager(); 31 FM.ouvrirFichier(filename,session); 32 FM.ecrireDansFichier(data); 33 FM.fermerFichier(); 34 return filename; 35 } Code 27 MeasuresService : Méthodes resultswritedown, checkdumpplacemarks, performwrite Cette méthode de fonctionnement permet d effectuer différentes mesures indépendamment du temps qu elles prennent. Le lancement d une nouvelle mesure peut être réalisé même si le résultat de la mesure précédente se fait attendre. De plus, associer la position GPS au lancement de la mesure permet de ne pas biaiser les résultats. En effet, les mesures étant réalisées dans des transports et à de grandes vitesses, le temps que la mesure soit effectuée, la position au moment où l on reçoit le résultat peut être bien différente de celle où on l a lancée. Enfin, cette méthode permet d ajouter de nouvelles mesures facilement sans avoir à modifier la structure actuelle. A Geolocalisation La classe Geolocalisation est également un service. Cela est nécessaire pour pouvoir récupérer la position indépendamment du fonctionnement du reste de l application. On y retrouve les mêmes méthodes que précédemment : _onstart, _onbind. La localisation est obtenue grâce à une instance de la classe LocationManager. Celle-ci étant liée à un listener réagissant à l évènement onlocationchanged. 1 LocationManager LM = (LocationManager) context.getsystemservice(context.location_service); 2 LM.requestLocationUpdates(LocationManager.GPS_PROVIDER, 1000, 0, locationlistener); 3 private LocationListener locationlistener = new LocationListener() { 4 public void onlocationchanged(location location) { 5 firedatachanged(location); 6 } } 9 10 private void firedatachanged(location location){ 11 if(listeners!= null){ 12 lastdata = new LocationData(location); 13 for(geolocalisationlistener listener: listeners){ 14 listener.datachanged(lastdata); NetEffMon v2 80

81 Annexe A. Android Spécifications de l application Android 15 } 16 } 17 } Code 28 Geolocalisation : Récupération de la position Lorsqu une nouvelle position est connue, celle-ci est transmise aux classes écoutant le service géolocalisation via les listeners. A LocationData La classe LocationData, utilisée par le service Géolocalisation, permet de structurer les données de géolocalisation afin de ne garder que ce qui nous intéresse. Intéressons nous maintenant aux mesures réalisées par le service MeasuresService. A MeasurePingGoogle La classe MeasurePingGoogle réalise un ping vers l adresse grâce à la méthode run- PingGoogle. Le résultat est stocké dans une HashMap de clé pinggoogle et de valeur le temps de réponse en ms. Cette HashMap est ensuite associée à la position GPS dans une instance de la classe ResultMeasure. Ce fonctionnement sera le même pour les autres mesures. Cela permet à la classe MeasuresService de récupérer tous les résultats de la même manière sans avoir à se préoccuper du type de mesure réalisée. 1 public ResultMeasure getresults() 2 { 3 HashMap<String, String> values = new HashMap<String, String>(); 4 values.put("pinggoogle", String.valueOf(this.pingGoogle)); 5 return new ResultMeasure(gps, values); 6 } Code 29 MeasurePingGoogle : Méthode getresults de la classe MeasurePingGoogle A MeasureWifiSSIDs Même principe que pour MeasurePingGoogle, en exécutant la méthode runwifissids qui scanne les réseaux Wifi disponibles. A NetworkManager Enfin, la dernière mesure implémentée est celle récupérant la puissance du signal. Son fonctionnement est légèrement différent des deux précédentes mesures car la mesure récupérée est obtenue lorsque l évènement onsignalstrenghschanged() est reçu. Cet évènement est géré par un listener : NetEffMon v2 81

82 Annexe A. Android Spécifications de l application Android 1 PhoneStateListener psl = new PhoneStateListener() { 2 public void onsignalstrengthschanged(signalstrength signalstrength) 3 { 4 lastsignalstrength = 2 * signalstrength.getgsmsignalstrength() ; 5 if(networkmanager!= null) 6 { 7 networkmanager.setlastsignalstrength(lastsignalstrength); 8 } 9 } 10 }; Code 30 MeasuresService : Listener récupérant la puissance du signal La puissance du signal est reçue dans une certaine unité à savoir l asu. Cette mesure peut aller de 0 à 31. La documentation du SDK de Google nous indique que cette mesure peut être convertit dans une unité plus conventionnelle : le dbm (décibels au dessus d un milliwatt). Cette conversion se fait par la formule suivante : dbm = asu Les mesures prises en dbm s étalonneront donc entre -113 et -51. (-51 étant la meilleure mesure). Lorsqu aucun signal n est trouvé, la valeur renvoyée sera 99. L utilisation d un listener ne pouvant se faire dans une simple classe, celui-ci est déclaré dans la classe MeasuresService. A chaque changement de puissance du signal, la valeur est mise à jour au sein de la classe NetworkManager. Ce listener est ensuite lié à une instance de la classe TelephonyManager sur laquelle on écoute les variations de la puissance du signal : 1 TelephonyManager TM = (TelephonyManager) context 2.getSystemService(Context.TELEPHONY_SERVICE); 3 TM.listen(psl, PhoneStateListener.LISTEN_SIGNAL_STRENGTHS); Code 31 NetworkManager : Utilisation de TelephonyManager pour récupérer la puissance du signal A Kml La classe Kml permet de créer un document en suivant la norme XML. Nous l utilisons pour créer un document KML en utilisant la structure correspondant. Pour cela nous utilisons la classe XmlSerializer utilisant une instance de StringWriter comme buffer. Avec ces outils, l ajout de balises se fait par simple appel aux méthodes suivantes : 1 serializer.starttag("", tagname); 2 serializer.text(tagvalue); 3 serializer.endtag("", tagname); Code 32 Kml : Création de balises xml NetEffMon v2 82

83 Annexe A. Android Spécifications de l application Android A FileManager Le document KML ayant été créé, il nous reste plus qu à l écrire dans un fichier. La classe FileManager est en partie utilisée pour cette tâche. Pour cela, il nous faut tout d abord ouvrir un fichier. Ce fichier se trouvera dans un répertoire NetEffMon puis dans un répertoire du nom de la session en cours : 1 // Creation du repertoire NetEffMon s il n existe pas encore 2 File chemin = new File(Environment.getExternalStorageDirectory(), this.appdir); 3 if (!chemin.exists()) { 4 if (!chemin.mkdirs()) { 5 Log.e("FileManager", "Cannot create directory: " + 6 chemin.tostring()); 7 } 8 } 9 // Creation du repertoire du nom de la session s il n existe pas encore 10 File cheminsession = new File(chemin, session); 11 if (!cheminsession.exists()) { 12 if (!cheminsession.mkdirs()) { 13 Log.e("FileManager", "Cannot create directory: " + 14 cheminsession.tostring()); 15 } 16 } 17 // Creation et ouverture du fichier 18 fos = new FileOutputStream(new File(cheminSession, filename)); 19 osw = new OutputStreamWriter(fos); Code 33 FileManager : création de répertoires et de fichiers A partir de là, l écriture se fait grâce à la méthode ecriredansfichier : 1 public void ecriredansfichier(string text) 2 { 3 // Si la memoire externe est disponible et si le fichier est ouvert 4 if(mexternalstoragewriteable && osw!= null) 5 { 6 try { 7 osw.write(text); 8 osw.flush(); 9 } catch (IOException e) { 10 Log.e("SaveFileFailed",e.getMessage()); 11 e.printstacktrace(); 12 } 13 } 14 } Code 34 FileManager : ecriture dans un fichier NetEffMon v2 83

84 Annexe A. Android Spécifications de l application Android A ConnectWebService L application communique, à sens unique, avec le web service. Pour cela, elle envoi une requête POST avec pour en-tête un balise Android et comme valeur le contenu du fichier KML produit. Nous avons déjà vu que le message était créé grâce à la classe CountingMultipartEntity. Il est envoyé vers le webservice de la manière suivante : 1 public static boolean connexionserveur(countingmultipartentity cme) 2 { 3 String url = " 4 HttpClient httpclient = new DefaultHttpClient(); 5 6 // Requete POST 7 HttpPost httppost = new HttpPost(url); 8 9 try 10 { 11 httppost.setentity(cme); 12 HttpResponse response = httpclient.execute(httppost); } 15 } A Difficultés rencontrées Code 35 ConnectWebService : upload de fichiers Au cours de réalisation de cette application, différents problèmes ont été rencontré, des problèmes liés au développement sur mobile : A Enregistrement d une longue session La figure A.2 présente le cycle de vie d une Activity. On peut voir qu à tout moment une autre application peut prendre la main sur la notre, la mettant dans l état OnPause ou OnStop. Jusqu ici cela ne pose pas de problème, l application pouvant toujours tourner en tâche de fond. Le problème est le lien allant de OnPause et OnStop vers App process killed. En effet lorsque l application n a plus la main, celle-ci est considérée comme non critique. Le système se réserve alors le droit de pouvoir la fermer à tout moment s il désire libérer de la mémoire et ce sans laisser le temps à l application de sauver son état, puisqu elle se trouve déjà dans l état OnPause ou OnStop où il est recommandé de sauver son état. Or nos mesures étant encore effectuées, nous ne pouvions pas sauvegardé notre état. La solution pour ce genre d application tournant très longtemps et souvent en tâche de fond est d utiliser un Service. Les services sont faits pour tourner en tâche de fond et pour de longues durées. De ce fait, le système leur donne une très haute priorité, ce qui leur permet d être en dernière position dans la liste des applications à fermer lorsque plus de mémoire est nécessaire. NetEffMon v2 84

85 Annexe A. Android Spécifications de l application Android Figure A.2 Cycle de vie d une Activity NetEffMon v2 85

86 Annexe A. Android Spécifications de l application Android A Taille du tas L autre problème lié aux longues sessions d enregistrement est la taille allouée du tas. En effet, comme vu dans la partie A.1.4 Descritpion du code, afin de créer le fichier KML, nous utilisons un objet XmlSerializer écrivant dans un objet StringWriter. Ce dernier objet grossit donc au fur et à mesure que l on ajoute des mesures. Nous sommes alors rapidement confrontés à des exceptions de type java.lang.outofmemoryerror. La taille allouée est différente selon les appareils et selon le nombre d application tournant au même instant. De plus ce sérialiser ne permet pas de vider régulièrement le buffer afin d écrire au fur et à mesure dans le fichier. Pour remédier à cela, la seule solution fut alors de séparer un enregistrement à l intérieur de plusieurs fichiers. C est de là donc qu a été placée la limite de 2000 Placemarks par fichier et de ce fait l apparition des sessions permettant de regrouper les enregistrements sous un même répertoire. A Puissance du signal Après avoir choisi comme mesure la puissance du signal reçu il nous fallait trouver la bonne méthode dans le SDK pour obtenir l information. Dans un premier temps nous avions trouvé la méthode getneighboringcellinfo. Cette méthode nous semblait convenable au vu des premiers tests et nous l avons utilisée durant une longue période. Cependant, lorsque les données ont pu être affichées sur une carte, nous avons réalisé qu il y avait beaucoup trop de points pour lesquels la puissance du signal avait été indisponible. Après plusieurs recherches approfondies sur le sujet nous n avons pas trouvé d explications précises, cependant d après d autres retours sur le même problème et d après nos propres observations, il semblerait que cette méthode ne soit utilisable que pour les réseaux 2G. En effet, ce sont principalement les points situés en zone urbaine qui n ont pas eu accès à la puissance du signal alors qu en zone rurale cela s améliore. A partir de là, nous avons cherché une autre solution pour arriver à celle présentée dans la partie A.1.4 Descritpion du code. A Données NMEA La norme NMEA est une spécification que l on a utilisée au départ pour les informations de géolocalisation. Cette norme utilise des trames (sentences) pour envoyer différentes informations identifiables par une balise de tête. Par exemple : GP RMC, , A, , N, , W, 0.820, , ,,, A 74 Il existe différentes sentences selon les puces GPS utilisées et ces trames donnant différentes informations. Celles-ci permettent d obtenir de nombreuses informations en plus des informations déjà obtenues par la méthode présentée dans la partie A.1.4 Descritpion du code. Nous avions choisis de ne garder que deux types de trame : GPGGA et GPRMC, fournissant latitude, longitude, altitude, vitesse, dilution horizontale, nombre de satellites trackés, angle, variation magnétique, la hauteur du géoïde... et d autres informations si on utilisait d autres types de trame. Ces informations étaient satisfaisantes et ont donc été longuement utilisées durant la vie du projet jusqu à ce que l on élargisse les tests sur d autres appareils. C est ici que nous nous sommes rendus compte que certains appareils ne pouvaient pas recevoir ces trames NMEA dû à certaines version d Android utilisant un driver non compatible. A partir de là nous avons priorisé la compatibilité avec le plus grand nombre d appareils plutôt que toutes ces informations qui ne seront pas forcement utilisées. A Tests NetEffMon v2 86

87 Annexe A. Android Spécifications de l application Android Pour terminer, l une des difficultés rencontrée tout au long du développement de l application Android a été de mettre en place des tests qui recouvrent complètement l utilisation de l application. Les problèmes sont les suivants : L application utilise le GPS, or celui-ci ne peut être obtenu à l intérieur d un bâtiment. L application a pour but d être utilisée en déplacement, en restant sur place, comme vu précédemment, aucun nouveau point n est enregistré. Enfin, l application est utilisée dans la plupart des cas sur de longues distances et donc sur une longue durée. Cela provoque des dysfonctionnements (comme ceux évoqués précédemment) que l on n obtient pas lors de tests courts. NetEffMon v2 87

88 Code de sérialisation et désérialisation = "CellSet") = true) = Visibility.DEFAULT, 5 gettervisibility = Visibility.NONE, 6 settervisibility = Visibility.NONE) 7 public class CellSet { 8 = "Row") 11 private ArrayList<Row> rows; } Code 36 Code simplifié de net.neteffmon.npm.api.data.cellset NetEffMon v2 88

89 Annexe B. Code de sérialisation et désérialisation = "Cell") = true) = Visibility.DEFAULT, 6 gettervisibility = Visibility.NONE, 7 settervisibility = Visibility.NONE) 8 public class Cell { 9 = "timestamp") 12 private String timestamp; 13 = "column") 16 private String b64_column; private String b64_value; } 23 Code 37 Code simplifié de net.neteffmon.npm.api.data.cell = "Row") = true) = Visibility.DEFAULT, 5 gettervisibility = Visibility.NONE, 6 settervisibility = Visibility.NONE) 7 public class Row { 8 = "Cell") 11 private ArrayList<Cell> cells; 12 = "key") 15 private String b64_key; } Code 38 Code simplifié de net.neteffmon.npm.api.data.row NetEffMon v2 89

90 Annexe B. Code de sérialisation et désérialisation 1 { 2 "Row":{ 3 "@key":"mdawmti2mtrmn2q0m2rmnjqxoduymzq0nwe2nzg3zdy=", 4 "Cell":[ 5 { 6 "@timestamp":" ", 7 "@column":"base64_column_name", 8 "$":"base64_value" 9 }, 10 { 11 "@timestamp":" ", 12 "@column":"base64_column_name2", 13 "$":"base64_value2" 14 } 15 ] 16 }, 17 "Row":{ 18 "@key":"mdawmti2mtrmn2q0m2rmnjqxoduymzq0nwe2nzg3zdy=", 19 "Cell":[ 20 { 21 "@timestamp":" ", 22 "@column":"base64_column_name", 23 "$":"base64_value" 24 } 25 ] 26 } 27 } Code 39 Résultat recu de HBase NetEffMon v2 90

91 Filtres pour filtrage de points via Stargate Ces données sont directement tirées d un article disponible ici (à la date de rédaction de ce document) : Cette annexe a pour but de s assurer que ces données seront toujours disponibles. Les références citées par cet article sont : HBase REST Filter (SingleColumnValueFilter) HBase Intra-row scanning HBase Book / Chapter on Client Filter C.1 ColumnPrefixFilter 1 { 2 "type": "ColumnPrefixFilter", 3 "value": "chjlzml4" 4 } Code 40 ColumnPrefixFilter C.2 ColumnRangeFilter 1 { 2 "type": "ColumnRangeFilter", 3 "mincolumn": "Zmx1ZmZ5", 4 "mincolumninclusive": true, 5 "maxcolumn": "Zmx1ZmZ6", 6 "maxcolumninclusive": false 7 } Code 41 ColumnRangeFilter C.3 ColumnPaginationFilter Could not generate an example, but I guess it should be pretty simple to test if it works just by intuitively plugging variables a certain way... NetEffMon v2 91

92 C.4 FamilyFilter Annexe C. Filtres pour filtrage de points via Stargate FamilyFilter 1 { 2 "type": "FamilyFilter", 3 "op": "EQUAL", 4 "comparator": { 5 "type": "BinaryComparator", 6 "value": "dgvzdhjvdw\u003d\u003d" 7 } 8 } Code 42 FamilyFilter C.5 FilterList with RowFilter and ColumnRangeFilter 1 { 2 "type": "FilterList", 3 "op": "MUST_PASS_ALL", 4 "filters": [ 5 { 6 "type": "RowFilter", 7 "op": "EQUAL", 8 "comparator": { 9 "type": "BinaryComparator", 10 "value": "dgvzdhjvdw\u003d\u003d" 11 } 12 }, 13 { 14 "type": "ColumnRangeFilter", 15 "mincolumn": "Zmx1ZmZ5", 16 "mincolumninclusive": true, 17 "maxcolumn": "Zmx1ZmZ6", 18 "maxcolumninclusive": false 19 } 20 ] 21 } C.6 FirstKeyOnlyFilter Code 43 FilterList with RowFilter and ColumnRangeFilter (Can be used for more efficiently perform row count operation) 1 { 2 "type": "FirstKeyOnlyFilter" 3 } NetEffMon v2 92

93 Annexe C. Filtres pour filtrage de points via Stargate InclusiveStopFilter C.7 InclusiveStopFilter Code 44 FirstKeyOnlyFilter 1 { 2 "type": "InclusiveStopFilter", 3 "value": "cm93a2v5" 4 } C.8 MultipleColumnPrefixFilter Code 45 InclusiveStopFilter 1 { 2 "type": "MultipleColumnPrefixFilter", 3 "prefixes": [ 4 "YWxwaGE\u003d", 5 "YnJhdm8\u003d", 6 "Y2hhcmxpZQ\u003d\u003d" 7 ] 8 } C.9 PageFilter Code 46 MultipleColumnPrefixFilter 1 { 2 "type": "PageFilter", 3 "value": "10" 4 } C.10 PrefixFilter Code 47 PageFilter 1 { 2 "type": "PrefixFilter", 3 "value": "cm93chjlzml4" 4 } Code 48 PrefixFilter NetEffMon v2 93

94 C.11 QualifierFilter Annexe C. Filtres pour filtrage de points via Stargate QualifierFilter 1 { 2 "type": "QualifierFilter", 3 "op": "GREATER", 4 "comparator": { 5 "type": "BinaryComparator", 6 "value": "cxvhbglmawvychjlzml4" 7 } 8 } Code 49 QualifierFilter C.12 RowFilter 1 { 2 "type": "RowFilter", 3 "op": "EQUAL", 4 "comparator": { 5 "type": "BinaryComparator", 6 "value": "dgvzdhjvdw\u003d\u003d" 7 } 8 } Code 50 RowFilter C.13 SingleColumnValueFilter 1 { 2 "type": "SingleColumnValueFilter", 3 "op": "EQUAL", 4 "family": "ZmFtaWx5", 5 "qualifier": "Y29sMQ\u003d\u003d", 6 "latestversion": true, 7 "comparator": { 8 "type": "BinaryComparator", 9 "value": "MQ\u003d\u003d" 10 } 11 } Code 51 SingleColumnValueFilter NetEffMon v2 94

95 Annexe C. Filtres pour filtrage de points via Stargate TimestampsFilter C.14 TimestampsFilter 1 { 2 "type": "TimestampsFilter", 3 "timestamps": [ 4 " " 5 ] 6 } Code 52 TimestampsFilter NetEffMon v2 95

96 Format des communications avec Stargate D.1 Liste des tables Aucun header "Accept" spécifié - code 53 "Accept: text/xml" - code 54 "Accept: application/json" - code 55 "Accept: application/protobuf" - code 56 D.2 Format des données "Content-Type: text/xml" - code 57 "Content-Type: application/json" - code 58 "Content-Type: application/x-protobuf" - code 59 1 tablename1 2 tablename2 Code 53 Liste des tables - Sans header "Accept" 1 <?xml version="1.0" encoding="utf-8" standalone="yes"?> 2 <TableList> 3 <Table name="tablename1"/> 4 <Table name="tablename2"/> 5 </TableList> Code 54 Liste des tables - XML NetEffMon v2 96

97 Annexe D. Format des communications avec Stargate Format des données 1 { 2 "Table": [ 3 {"name":"tablename1"}, 4 {"name":"tablename2"} 5 ] 6 } Code 55 Liste des tables - JSON a f 6e e 74 0a c 73 Code 56 Liste des tables - Protobuf 1 // // "Content-Type: text/xml" 3 // <?xml version="1.0" encoding="utf-8" standalone="yes"?> 5 <CellSet> 6 <Row key="base64_key"> 7 <Cell timestamp=" " column="base64_columnname"> 8 base64_value 9 </Cell> 10 <Cell timestamp=" " column="base64_columnname"> 11 base64_value 12 </Cell> 13 </Row> 14 <Row>...</Row> 15 </CellSet> Code 57 Formats d échange de données - XML NetEffMon v2 97

98 Annexe D. Format des communications avec Stargate Format des données 1 { 2 "Row":{ 3 "key":"base64_key", 4 "Cell":[ 5 { 6 "timestamp":" ", 7 "column":"base64_columnname", 8 "$":"base64_value" 9 }, 10 { 11 "timestamp":" ", 12 "column":"base64_columnname", 13 "$":"base64_value" 14 } 15 ] 16 }, 17 "Row": { "..." } 18 } "NOTE: The cell value is given in JSON encoding as the value associated with the key $." Code 58 Formats d échange de données - JSON 1 // // "Content-Type: application/x-protobuf" 3 // a b1 05 0a b 63 6f 6e e a a e3 8c c5 9d ee 01 3c 8 [...] b0 69 6c Code 59 Formats d échange de données - Protobuf NetEffMon v2 98

99 Format (KML) du fichier de sortie Android 1 <?xml version= 1.0 encoding= UTF-8?> 2 <kml xmlns=" 3 4 <Document> 5 <ExtendedData> 6 <session>8ff8bcc2-f67b-41b3-964d-be4e37b89a6d</session> 7 <component>21</component> 8 </ExtendedData> 9 10 <Placemark> <ExtendedData> 13 <time>181510</time> 14 <speed> </speed> 15 <fixquality>6.0</fixquality> 16 <satellites>9</satellites> 17 <signalstrength>-73</signalstrength> 18 <networktype>hsdpa</networktype> 19 <simid>20815</simid> 20 <netid>20801</netid> 21 <roaming>false</roaming> 22 <simop>free</simop> 23 <operateur>free</operateur> 24 </ExtendedData> <Point> 27 <coordinates> , , 125.0</coordinates> 28 </Point> 29 </Placemark> <Placemark> 32 <ExtendedData> 33 <time>181510</time> 34 <speed> </speed> 35 <fixquality>6.0</fixquality> 36 <satellites>9</satellites> 37 <networkprovider>mobile</networkprovider> 38 <pinggoogle>179.0</pinggoogle> 39 </ExtendedData> <Point> 42 <coordinates> , , 125.0</coordinates> NetEffMon v2 99

100 Annexe E. Format (KML) du fichier de sortie Android 43 </Point> 44 </Placemark> <Placemark> 47 <ExtendedData> 48 <time>181510</time> 49 <speed> </speed> 50 <fixquality>6.0</fixquality> 51 <satellites>9</satellites> 52 <networkprovider>mobile</networkprovider> 53 <httplatencygoogle> </httplatencygoogle> 54 </ExtendedData> <Point> 57 <coordinates> , , 125.0</coordinates> 58 </Point> 59 </Placemark> <Placemark> 62 <ExtendedData> 63 <time>181510</time> 64 <speed> </speed> 65 <fixquality>6.0</fixquality> 66 <satellites>9</satellites> 67 <WifiRssi>-200</WifiRssi> 68 <WifiSSID>MDRV</WifiSSID> 69 <WifiBSSID>00:90:4c:91:00:01</WifiBSSID> 70 <WifiSSIDs> 71 {SSID: Domino-fb, BSSID: 24:db:ac:fc:34:fb, 72 capabilities: [WPA-PSK-TKIP][ESS], level: -95, frequency: 2412} 73 {SSID: FreeWifi_secure, BSSID: de:26:56:8a:e8:f3, 74 capabilities: [WPA-EAP-CCMP][ESS], level: -69, frequency: 2462} 75 {SSID: Bbox-AA13AB68, BSSID: e8:f1:b0:e2:fe:90, 76 capabilities: [WPA-PSK-CCMP][WPA2-PSK-CCMP][WPS][ESS], 77 level: -79, frequency: 2412} 78 </WifiSSIDs> 79 </ExtendedData> <Point> 82 <coordinates> , , 125.0</coordinates> 83 </Point> 84 </Placemark> <TimeSpan> 87 <begin> :49:19</begin> 88 <end> :51:19</end> 89 </TimeSpan> 90 </Document> 91 </kml> NetEffMon v2 100

101 Annexe E. Format (KML) du fichier de sortie Android Code 60 Format KML du fichier de sortie Android NetEffMon v2 101

102 Optimisations et préconisations Cette annexe est une copie d une partie du rapport de Matthieu ANCERET et Sébastien GUILLON nommé «Neteffmon - Tests de performances et de montée en charge». Certaines références ne sont pas disponibles et ne doivent pas être prises en compte. Le rapport complet n a pas été inclut pour éviter d alourdir ce document. Ce chapitre devait être dédié à la montée en charge sur des requêtes complexes. Une requête complexe est une requête qui récupère les points situés dans une zone [...] répondant à un critère bien particulier (vitesse, force du signal, opérateur, type de réseau...). Ce critère est en fait l un des attributs de l objet Placemark. Suite aux résultats obtenus dans le chapitre [...] sur les requêtes simples, nous avons décidé, en accord avec notre encadrant, d aborder les aspects liés à l optimisation du cluster Hadoop/HBase. Suite à nos divers tests et mesures, on remarque que le goulot d étranglement ne provient pas de Jetty mais du cluster Hadoop/HBase. Nous avons en effet noté que les temps d exécution anormalement longs étaient dus à l attente de la réponse du cluster. L envoi et la réception des données ne prennent qu un temps minime par rapport au calcul des données sur le cluster. Il existe, sur la toile, beaucoup de littérature sur ce sujet. Notre objectif n est pas de réaliser un guide exhaustif des techniques d optimisation d HBase, ce serait beaucoup trop long, mais plutôt d expliquer les principales. Dans la mesure du possible, nous essaierons de mettre en place ses solutions et de voir leurs implications au niveau des performances. F.1 Configuration matérielle Actuellement, le cluster Hadoop/HBase utilise 5 machines composées chacune de la configuration suivante : 1 processeur Intel Xeon W coeurs à 3,07 Ghz, 8 Go de mémoire vive, 1 disque dur de 500 Go. F Si l on se réfère à la documentation officielle d HBase [?], on peut trouver un cas d utilisation utilisant la configuration suivante : 2 processeurs à 12 coeurs, 24 Go de mémoire vive, 6 disques dur, 2 ports Gigabit agrégés en un seul. La configuration utilisée est clairement supérieure à la nôtre (le nombre de machines utilisées n est pas précisé), et il est possible qu un juste milieu existe entre ces 2 extrêmes. Malgré tout, notre configuration est tout de même en dessous au niveau des prérequis en mémoire vive recommandés par HBase (16 Go). Si l on se réfère à la documentation d HBase, il est noté : "RAM, RAM, RAM. Don t starve HBase" (ce NetEffMon v2 102

103 Annexe F. Optimisations et préconisations Passage d une architecture 32 bits à 64 bits que l on peut traduire par : "HBase est très gourmand en mémoire vive, donnez-lui-en suffisamment!"). N oubliez pas qu HBase fonctionne avec la JVM et que cette dernière est réputée pour être très demandeuse de mémoire vive. Pour appuyer encore sur le manque de mémoire, nous allons parler d une erreur que nous avons rencontrée lors de la récupération de points. Cette erreur s est présentée dans les conditions suivantes : utilisation de notre base de données de 100 millions de points avec une zone englobant la France (point haut gauche : , ; point bas droit : , ). Après plusieurs dizaines de minutes de travail, HBase a retourné une erreur du type "OutOfMemory", autrement dit, manque de mémoire vive. L erreur exacte, détaillée sur les figures F.1 page 103 et F.2 page 104, mentionne le fait que la limite du "Garbage Collector" serait dépassée. Ce type d erreur est la preuve irrévocable que notre configuration matérielle manque clairement de mémoire vive. Figure F.1 Erreur obtenue lors d une requête sur la France (navigateur) F.2 Passage d une architecture 32 bits à 64 bits Ce point rejoint en partie le point précédent sur la configuration matérielle. Étant donné que le besoin en mémoire vive est très important (minimum 16 Go de RAM), l utilisation d un système d exploitation 64 bits est évidente, notamment pour pouvoir utiliser correctement la mémoire à disposition. NetEffMon v2 103

104 Annexe F. Optimisations et préconisations Passage d une architecture 32 bits à 64 bits Figure F.2 Erreur obtenue lors d une requête sur la France (console) Pour rappel, un système d exploitation en 32 bits est limité au niveau de la mémoire qu il peut utiliser : 32 bits : Normalement, limité à 4 Go de RAM, mais la carte mère s en réserve une partie et la mémoire réellement utilisable tombe entre 2,9 et 3,5 Go. L espace perdu est en fait utilisé pour l adressage des périphériques. 32 bits avec PAE : Implémentée au niveau du processeur, cette extension permet de repousser la limite mémoire à 64 Go sur les systèmes 32 bits. Malgré tout, il existe toujours la limitation mémoire par processus qui est fixée à 4 Go (pour un processus 32 bits). Il est donc totalement bénéfique de passer à un système 64 bits, qui permettra d utiliser la totalité de la mémoire vive disponible et d allouer plus de 4 Go de RAM pour un processus (si celui-ci est en 64 bits bien évidemment). Un système d exploitation 64 bits permet aussi une amélioration globale des performances, grâce à une meilleure gestion du multiprocesseur/multi thread. Hadoop/HBase et la machine virtuelle Java existent tous les deux en 64 bits, il serait donc dommage de s en priver. Encore une fois, si l on se réfère à la documentation officielle d HBase, celle-ci nous indique d utiliser un système d exploitation et une JVM en 64 bits. Actuellement, ce n est pas le cas, et cela explique probablement (ou en partie du moins) les faibles performances rencontrées. NetEffMon v2 104

105 Annexe F. Optimisations et préconisations Passage à un réseau en Ethernet Gigabit Nous avons donc réalisé, avec l aide de notre encadrant, une manipulation pour que le système utilise un noyau 64 bits. Nous avons appliqué cette méthode sur les 5 machines du cluster. Nous en avons profité pour installer la JVM 64 bits. Après avoir effectué ces manipulations, nous avons recommencé certains tests (notamment celui permettant de récupérer les points d une zone). En terme de performance, les résultats obtenus sont identiques : nous n avons pas gagné de temps à l exécution. Ce point vient encore renforcer le fait que notre cluster n est pas correctement dimensionné du point de vue mémoire. F.3 Passage à un réseau en Ethernet Gigabit Selon plusieurs références [...], le réseau n est en général pas un goulot d étranglement. Il intervient principalement lors des backups des bases. En utilisant courante, ce dernier n est que peu sollicité. Actuellement, les machines de notre cluster sont reliées via un switch Ethernet 100 Mega. Notre encadrant a changé ce switch pour en installer un en Gigabit. Après avoir fait le changement, nous avons recommencé certains tests (insertion de points et requête sur zone) et les résultats sont identiques. Le réseau n est donc pas un facteur limitant. Suite à un problème inconnu au niveau du cluster Hadoop/HBase, nous n avons pas pu tester les résultats des sections suivantes. Malgré tout, elles peuvent tout de même servir de préconisation pour optimiser le cluster et améliorer les performances. F.4 Suppression du swap Toujours en suivant la documentation officielle d HBase, celle-ci conseille de désactiver le swap sur le système. Le swap est un mécanisme, contrôlé par le noyau, qui a pour rôle de déplacer un processus en mémoire vive vers le disque dur. En général, ce mécanisme est utilisé pour pallier au manque de mémoire vive sur le système. Étant donné qu un disque dur est beaucoup moins rapide que la mémoire vive, cela grève les performances du système (augmentation du temps de réponse). Heureusement, il est possible de contrôle la façon dont le noyau va gérer le swap. La JMV et HBase peuvent rencontrer des comportements bizarres en cas de swap, comme par exemple, l expiration de la session ZooKeeper. Nous avons décidé de complètement désactiver le swap, comme recommandé dans la documentation. Pour cela, nous avons modifié le fichier /etc/sysctl.conf pour y ajouter la ligne suivante : 1 vm.swappiness = 0 F La modification sera prise en compte au prochain redémarrage. Pour vérifier que celle-ci a bien été prise en compte, il est possible d utiliser la commande suivante qui est sensé retourner la valeur 0. 1 cat /proc/sys/vm/swappiness Dans ce cas, le noyau essaye autant que possible (tant que de la mémoire vive est disponible) de conserver tous les processus en mémoire vive. Ce comportement est bénéfique pour HBase, car cela va limiter l appel et l usage du Garbage Collector Java ainsi que l expiration de la session ZooKeeper. NetEffMon v2 105

106 Annexe F. Optimisations et préconisations Optimisation de la JVM F.5 Optimisation de la JVM HBase fonctionne en utilisant la JVM. Les paramètres de cette dernière sont donc très importants et peuvent largement influer les performances d HBase. Nous allons donc proposer quelques astuces permettant d optimiser les ressources matérielles à disposition. Ces modifications sont à réaliser dans le fichier /usr/local/hadoop/hbase/conf/hbase-env.sh. Modification du «Heap Size» Par défaut, le "Heap Size" d HBase est de 1 Go. Nous avons modifié celui-ci pour qu il atteigne 4 Go. Normalement, la valeur recommandée est 8 Go (16 Go maximum), mais étant donné que notre machine ne dispose que de 8 Go de RAM, nous ne pouvons raisonnablement pas aller plus loin. Activation des logs de la JVM Cela permet d avoir une connaissance précise de la façon dont la JVM alloue la mémoire et de la façon dont le Garbage Collector est appelé. L article suivant [?] explique très précisément comment analyser et interpréter les logs obtenus. Paramètre Xss de la JVM Ce paramètre permet de régler la taille de la pile pour chaque thread. Par défaut, il est de 1024k avec la JVM 64 bits. Dans le cas où nous avons de très nombreux processus, il peut être judicieux de diminuer cette taille pour pouvoir faire cohabiter de nombreux processus sans obtenir une consommation mémoire trop élevé. Nous n avons malheureusement pas pu tester les effets de ce paramètre sur les performances du cluster. Il est aussi possible de jouer avec les paramètres Xms (taille initiale de la pile)/xmx (taille maximale de la pile)/xmn (taille de la pile pour les objets "Young Generation") qui permettent de configurer la taille de la pile pour la JVM complète. L augmentation des valeurs de ces 3 paramètres peut permettre à la JVM de pouvoir exploiter plus de mémoire vive et d éviter les erreurs du type "OutOfMemory". F.6 Utiliser la compression HBase propose une fonctionnalité très importante : la compression des données. Cela permet de réduire la quantité de données lues/écrites sur les disques, d économiser de l espace disque et de diminuer l utilisation du réseau. HBase supporte les algorithmes GZip et LZO. LZO est à privilégier si l on a besoin d une bonne vitesse de décompression tout en conservant un usage CPU modéré. GZip est à privilégier dans le cas où le ratio de compression est le plus important (économie d espace disque). L implémentation de cette technique est un peu complexe et nous n avons pas pu la mettre en place, à cause d un manque de temps et de la panne du serveur Hadoop/HBase. NetEffMon v2 106

107 Cahier de spécifications NetEffMon v2 107

108 École Polytechnique de l Université de Tours 64, Avenue Jean Portalis TOURS, FRANCE Tél. +33 (0) Département Informatique Cahier de spécification système & plan de développement Projet : Cahier de spécification de NetEffMon v2 Emetteur : Albin POIGNOT Coordonnées : DI Date d émission : 16 janvier 2013 Validation Nom Date Valide (O/N) Commentaires A Lissy : 31/10/2012 ; N ; Diverses fautes de frappes et quelques ajouts A Lissy : 25/11/2012 ; N ; Plusieurs points à revoir A Lissy : 03/01/2012 ; N ; Plusieurs points à revoir A Lissy : 16/01/2012 ; O ; Validation Version Date Description de la modification Historique des modifications 00 : 25/10/2012 ; Version initiale : partie Conditions de fonctionnement incomplète, Planning non renseigné, Estimations de charge non renseignées 01 : 08/11/2012 ; Correction fautes de frappe, liens morts corrigés, ajout de détails pour la correction du front-end. Ajout de Perf, Controlabilité et Intégrité. Manque Planning, Capacités et Sécurité. 02 : 26/12/2012 ; Revue du plan : ajout de la partie Description des fonctionnalités futures, pour bien séparer les nouvelles fonctionnalités. Ajout du Gantt. Ajout de la tâche : 07/01/2013 ; Reformulation de quelques phrases. 04 : 16/01/2013 ; Version finale.

109

110 Table des matières Cahier de spécification système Introduction Contexte de la réalisation Contexte Objectifs Hypothèses Bases méthodologiques Description générale Environnement du projet Caractéristiques des utilisateurs Fonctionnalités et structure générale du système Contraintes de développement, d exploitation et de maintenance Description des interfaces externes du logiciel Interfaces matériel/logiciel Interfaces homme/machine Interfaces logiciel/logiciel Architecture générale du système Description des fonctionnalités actuelles Mesure des données Récupération des données Analyse des données Affichage des données sur la qualité du réseau 3G Description des fonctionnalités futures Application Android Web service Moteur d analyse Site web Système de stockage des données Conditions de fonctionnement Performances Capacités Contrôlabilité Intégrité Plan de développement Découpage du projet en tâches Tâche 1 - Observation Tâche 2 - Optimisation du front-end Tâche 3 - Optimisation du système de base de données Tâche 4 - Optimisation de la structure des données Tâche 5 - Création d une API publique Tâche 6 - Affichage des mesures par colorisation des zones NetEffMon v2 CDS III

111 TABLE DES MATIÈRES Tâche 7 - Gestion des utilisateurs Planning A Glossaire 24 B Références 25 C Index 26 IV NetEffMon v2 CDS

112 Cahier de spécification système NetEffMon v2 CDS 5

113 1.1 Introduction Cahier de spécification système Ce cahier de spécification système permet de définir les objectifs du projet. Il permet à toutes les personnes prenant part à ce dernier d avoir une vision commune. Chacun pourra alors se reporter à ce document tout au long du projet pour répondre à certaines interrogations ou s assurer que les actions menées restent bien dans le cadre du projet. Ce document doit être rédigé par la MOE (Albin POIGNOT), puis relu par la MOA (Alexandre LISSY) de façon à s assurer que les deux entités se sont correctement comprises. 1.2 Contexte de la réalisation Contexte Ce projet s inscrit dans la suite d un projet collectif mené au sein de Polytech Tours l année passée. Ce dernier fut mené par une équipe de 8 étudiants dont Albin POIGNOT était le chef de projet. Durant le projet collectif, l équipe avait pour mission de développer un système permettant de cartographier la qualité du réseau 3G dans le monde. Pour cela, il était nécessaire de créer plusieurs applications différentes : une application mobile pour effectuer les mesures, un web service pour récupérer et stocker ces données, un moteur d analyse pour les traiter, puis enfin une partie front-end pour visualiser l ensemble des mesures. A cette époque, l équipe avait choisi de créer une application Android pour effectuer les mesures, puis de mélanger le web service, le moteur d analyse et le front-end dans une application Python/Django. Dans toute la suite du document, ce projet sera appelé NetEffMon v Objectifs Le projet actuel, que nous appellerons NetEffMon v2 consiste à continuer le travail effectué l année passée en y apportant des modifications et des améliorations. On pourrait en réalité considérer NetEffMon v1 comme une base saine et simpliste, que le projet actuel va devoir améliorer. L idée globale de ce projet est d effectuer des analyses sur des mesures qualitatives du réseau mobile mondial. Il faut donc chercher à fournir des analyses les plus pertinentes possibles, tout en gardant à l esprit que toutes les opérations sont effectuées dans un contexte de big-data. Egalement, nous sommes ici dans le cadre d open-data Hypothèses Dans le cadre de ce projet, un hypothèse importante doit être posée. Elle porte sur le système de base de données choisi. Actuellement, NetEffMon s appuie sur une base de données PostgreSQL. Dans un cadre big-data, il convient de bien faire attention aux méthodes que nous allons choisir. Par exemple, les mesures récupérées via le web service sont parsées et insérées en base de données. Ainsi, potentiellement, le système sera amené à gérer une infinité de points. Effectivement, une mesure effectuée par l application Android correspond à un point terrestre. On a déjà une infinité de points à la surface de la Terre, il faut en plus de cela rajouter la variable de l altitude. Il pourrait, dans ce cas, être intéressant de s appuyer sur un système NoSQL, plus à même de gérer des données en très grand nombre. 6 NetEffMon v2 CDS

114 Description générale Cependant, dans le cadre d un PFE, le déploiement NoSQL peut prendre énormément de temps. On peut aussi considérer qu avant d arriver à la limite d un système PostgreSQL, il faudra déjà un grand nombre de points. Ainsi, il est prévu d étudier les courbes d évolution du nombre de données et de prendre alors la décision d utiliser, ou non, un système NoSQL. Il est également prévu de déterminer à quel(s) moment(s) ou dans quel(s) cas il est nécessaire d utiliser ce type de système Bases méthodologiques Ce projet devra s appuyer sur les technologies déjà utilisées par NetEffMon v1. Il pourra en être ajouter si nécessaire, comme par exemple un système NoSQL. Il devrait également être ajouté le plugin PostGIS au système PostgreSQL déjà déployé (si ce dernier est conservé). 1.3 Description générale Environnement du projet NetEffMon v2 ne possède pas réellement d environnement. Cependant, il s inscrit dans un projet existant déjà opérationnel. Une équipe de huit développeurs ont déjà mené le développement d une plateforme basique remplissant globalement les fonctionnalités que l on souhaite obtenir. Cette plateforme sera cependant rapidement limitée en terme de scalabilité : elle n a pas été pensée pour être utilisée sur le long terme sans être améliorée. Le but de NetEffMon v2 est d intégrer la totalité des fonctionnalités existantes de NetEffMon v1 en améliorant la scalabilité, dans un premier temps. Dans un deuxième temps, il est prévu d améliorer les analyses menées par le système. Actuellement, elles sont basiques et il serait possible d effectuer des analyses plus précises et surtout fournir des résultats selon certains filtres : classer les mesures par opérateur 3G par exemple Caractéristiques des utilisateurs Les utilisateurs amenés à utiliser le système ne sont pas forcément des personnes ayant une grande connaissance de l informatique. Certaines personnes nous ont déjà contacté au sujet de la version 1 de NetEffMon. Ces personnes étaient des spécialistes dans le domaine du réseau mobile. Il est donc nécessaire que les informations disponibles correspondent également à des utilisateurs plus aguerris. Des utilisateurs plus néophytes pourront également utiliser le système par simple curiosité. L interface utilisateur doit donc rester la plus accessible possible pour ce type de profils. Il conviendra donc, tout au long du projet, de fournir des interfaces très complètes mais également très accessibles pour permettre à tous les utilisateurs de s y retrouver. Les utilisateurs auront accès à une API publique pour récupérer les données et pourront accéder sans limitations au front-end. Par contre, ils n auront pas accès aux méthodes d analyses et de récupération des données. En résumé, ils n auront accès aux données (anonymisées) qu en lecture. Le seul moment où l écriture sera autorisée sera lors de la réception des mesures par le web service. Il est a noté que la licence sous laquelle les données seront diffusées reste à fixer. On sait cependant qu elle doit permettre deux choses : Permettre la réutilisation des données Permettre l intégration avec OpenStreetMap NetEffMon v2 CDS 7

115 Cahier de spécification système Fonctionnalités et structure générale du système L architecture générale du système est présentée par le schéma 1.1. Comme on peut le constater, le système se compose de plusieurs parties distinctes. La première partie est ce que nous appellerons le back-end. Cette partie englobe tous les traitements logiques cachés à l utilisateur final. En réalité, elle contient le web-service qui communique avec le téléphone Android de l utilisateur, ainsi que le moteur d analyse. Ce dernier effectue des calculs pour obtenir de l information à partir des données reçues par le web-service. Ces deux modules communiquent avec le serveur de base de données. Ce serveur est conceptuellement composé de deux sous-serveurs. Actuellement, il y a deux base de données PostgreSQL déployées indépendamment l une de l autre. Une d elles se charge de stocker les données brutes, reçues du web service. D un autre côté, une autre base se charge de stocker toutes les données qui ont été traitées : d une part les données parsées (reçues du web-service puis converties pour insertion en base), d autre part les données analysées et regroupées par zones géographiques. Ce sont ces données analysées qui seront enfin affichées dans la dernière partie. Le front-end est la partie qui permet à l utilisateur d accéder aux données qu il a précédemment envoyées. Il affiche les données traitées sur un fond de carte OpenStreetMap et doit permettre un tri des données à afficher. Quelques modifications techniques devraient apparaitre. L architecture ne devrait pas changer durant le projet, cependant, on sait qu il est possible que la base des données brutes pourraient éventuellement passer sur un système NoSQL. Ces modifications sont soumises à des hypothèses que nous ne maitrisons pas encore. Pour terminer, on peut noter qu actuellement, il n existe qu un seul serveur physique, que nous avons nommé Ocean Contraintes de développement, d exploitation et de maintenance Contraintes de développement Le projet est soumis à différentes contraintes de développement. En voici la liste : OS du serveur : Debian Wheezy/Sid Langage Back-End : Python/Django Langage Front-End : Python/Django + Javascript Base de données : PostgreSQL (+ PostGIS), NoSQL si nécessaire Application Android : Android SDK Licence du code source : Apache 2 Contraintes d exploitation Il existe une contrainte d exécution : les analyses des points parsés ne sont pas lancés automatiquement. Actuellement, une tâche CRON lance les analyses toutes les heures. Cette contrainte pourrait éventuellement être supprimée. Ce choix fait partie du projet en lui-même. 8 NetEffMon v2 CDS

116 Description des interfaces externes du logiciel Fig. 1.1 Architecture générale du système 1.4 Description des interfaces externes du logiciel Interfaces matériel/logiciel Pour répondre aux besoins du projet, nous avons besoin de mettre en place l architecture matérielle schématiser dans la figure 1.1. On notera que les moteurs de bases de données peuvent éventuellement évoluer durant le projet. Les différentes entités communiquent entre elles de la manière suivante : Le mobile sous Android, où est implémentée l application permettant de recueillir les données, communique avec le web service présent sur le serveur grâce au protocole HTTP. La transmission des messages se fait en utilisant l architecture REST. Les données sont au format KML. Il est possible d envisager une compression quelconque (gzip par exemple) pour limiter la taille des transmissions. NetEffMon v2 CDS 9

117 Cahier de spécification système Concernant le Back End, le web service et le moteur d analyse sont présents sur le serveur et peuvent donc directement communiquer entre eux et avec la base de données. Le Front End est également sur le serveur et donc la communication avec le back end est directe également. Il est alors accessible par les utilisateurs par le protocole HTTP Interfaces homme/machine Application Android L application Android est déjà existante et l interface homme/machine est donc déjà fonctionnelle. Cependant, elle n est pas particulièrement ergonomique (un exemple est visible sur la figure 1.2). Dans ce cadre, il est envisageable d y apporter des modifications. Cependant, cela n étant pas une priorité pour le projet, nous ne le détaillerons pas ici. Egalement, on peut noter que ces améliorations sont principalement ergonomiques plus que fonctionnelles. Site web L interface web est principalement composée d un composant fourni par OpenLayers. Cette interface permet de consulter les différentes données et doit donc fournir un code couleur permettant d identifier rapidement les types et qualités des informations affichées. Afin d obtenir plus de détails concernant les informations affichées, l utilisateur peut sélectionner graphiquement une zone qui l intéresse. L utilisateur doit également pouvoir utiliser un certains nombre de filtres sur les données affichées. Sur la figure 1.3, on peut apercevoir sur la droite un encart permettant de filtrer les informations. Cet encart devrait s agrandir pour permettre d afficher plusieurs autres filtres Interfaces logiciel/logiciel Entre l application Android et le webservice Le dialogue s articule autour de la norme KML. L application Android construit ce fichier lors de la mesure, puis la transmets au web service qui se charge de la réception Entre le web service et la base de données brutes Le web service se charge alors d effectuer une requête SQL classique contenant le fichier KML. Aucun autre traitement n est effectué par le web service, qui peut ainsi renvoyer une réponse plus rapidement à l application (pour valider la réception par exemple). Dialogues entre les bases de données et le moteur d analyse Comme pour le web service et la base de données brutes, le dialogue se passe avec des requêtes SQL classiques. Le moteur d analyse récupère les données de la base de données brutes, effectue ses analyses, puis transmets les ajouts et les mises à jour à la base de données analysées. 1.5 Architecture générale du système Le système est basé sur une architecture faisant intervenir deux bases de données PostgreSQL, un web service, un site web ainsi qu une application mobile Android. 10 NetEffMon v2 CDS

118 Architecture générale du système Fig. 1.2 Screenshot de l application Android L application Android est un outil permettant d effectuer différentes mesures qu elle envoi au web service qui analyse et traite alors ces données afin de les intégrer à la base de données. Le moteur d analyse intervient alors sur ces données parsées pour en ressortir l information. Pour éviter d avoir un trop grand nombre de points à afficher, et permettre d avoir un front-end accessible, l analyse consiste à regrouper chaque point par zones géographiques carrées de 100 mètres. Il effectue également les calculs pour définir, par exemple, la qualité moyenne de la zone géographique considérée. Enfin, le site web permet de consulter les résultats des différentes mesures établies. Pour cela il interroge directement la base de données qui lui renvoi les données nécessaires. L affichage des résultats se fait côté client. NetEffMon v2 CDS 11

119 Cahier de spécification système Fig. 1.3 Structure générale 1.6 Description des fonctionnalités actuelles En détails, l application dispose de nombreuses fonctionnalités, que ce soit du côté serveur uniquement ou en interaction entre le serveur et les utilisateurs. Nous pouvons décrire 3 grandes fonctionnalités de notre application et ses composants liés : 1. La récupération et le transfert des données depuis l application Android vers la base de données du serveur par le biais du web service 2. Le traitement de ces données par un moteur d analyse qui sera inclut dans le serveur 3. L affichage des données traitées sur le site web Le projet actuel est d améliorer certaines des fonctionnalités en prenant notamment en compte la scalabilité du système. On cherche également à améliorer les analyses effectuées sur les mesures Mesure des données Pour que tout le système fonctionne, il faut d abord que les utilisateurs effectuent des mesures de la qualité du réseau. Pour leur permettre de le faire simplement, mais également pour nous assurer de recevoir les résultats dans un format que nous maitrisons, une application Android leur est fournie. Cette dernière, dotée d une interface basique et simple d utilisation, permet aux utilisateurs de préciser le nom de leur session de mesures, le moyen de transport qu ils vont utiliser, puis enfin de lancer la mesure. A la fin de la mesure, cette dernière est transmise au web service présenté dans la partie Application Android Fonction : mesure de la qualité du réseau Rôle : mesurer la qualité du réseau puis transmettre le résultat au serveur. 12 NetEffMon v2 CDS