Le jeudi à Devoxx France 2012

Cet article a été écrit par Emmanuel Peru, Jeoffrey Haeyaert, Azize Elamrani, Emmanuel Diquas et François Descamps

Contrairement au premier jour on a le droit à des keynotes (qui auront lieu aussi le lendemain) dès 9h. Les organisateurs de Devoxx France nous font un petit bilan de leur aventure pour en arriver à cette réussite qu’est la première release de Devoxx France. La salle applaudit bien volontiers, tout le monde se rend compte du boulot accomplit, et l’assurance des Devoxx 2013,2014,2015… ravit tout le monde ! Pour cette deuxième journée, et contrairement aux estimations les plus optimistes nous sommes plus de 1300 !

Keynotes

Suite à cette présentation, Pierre Pezziardi au parcours professionnel impressionnant prend la parole. « Développeurs, soyez fiers d’être développeurs » : petites anecdotes et réflexions plus profondes viennent illustrer notre métier et chacun se reconnait dans le portrait dépeint par Pierre. Une prise de parole non technique, qui nous met en jambe dès le matin.

La keynote de Pierre Pezziardi qui a suivi nous a exposé l’enjeu de notre métier en 2012 et comment il avait évolué. Pierre s’est notamment attaché a bien mettre en valeurs les problématiques de notre métier.

La dernière keynote du matin était beaucoup plus orienté sur la plateforme java avec Ben Evans et Martijin Verburg qui nous ont présenté les évolutions possibles de la plateforme : “This could be Heaven or this could be Hell”.

Conférences

ElasticSearch : moteur de recherche NoSQL/REST/JSON taillé pour le cloud par David Pilato

Cette première conférence de la journée nous a présenté le moteur de recherche Elastic Search. Cette solution basée sur Apache 2 est Distribué et RESTful. Cet outil est vraiment puissant et simple d’utilisation. David nous a présenté les concepts fondamentaux et les cas d’utilisations. Tout est document et les recherches sont faits par index. Les accès http en REST avec la possibilité d’utilisation des facets Range et Term est vraiment top. Les données sont collectées automatiquement avec un système de Rivière. Plus d’informations sur : http://dev.david.pilato.fr

Nouveau look pour une nouvelle vie : Spring, JQuery et HTML5 par Julien Dubois

Cette conférence avait pour objectif de nous présenter comment mettre en place rapidement une application avec Spring MVC, le tout aidé par jQuery et l’architecture REST. Le HTML5 et le CSS3 étaient de la partie et étaient présentés avec twitter bootstrap. La base de données choisie dans le cas de Julien était Casandra avec une couche Hector. Le but de cette application est de créer un twitter version entreprise en Open Source (voir l’application tatami sur le github de Ippon et leur blog pour plus d’informations : https://github.com/ippontech/tatami, http://blog.ippon.fr/2012/03/19/bienvenue-sur-le-tatami-ippon-lance-un-grand-concours-de-code-pour-devoxx-france/ et http://blog.ippon.fr/2012/04/11/resultat-du-concours-tatami-pour-devoxx-france/).

Comment tester son idée et concevoir un prototype web en un minimum de temps par Camille Roux

Camille Roux nous pose un constat : Nous avons tous des bonnes idées qui répondent à des besoins. Mais comment en créer un prototype qui repose sur cette idée et l’éprouver ? C’est ainsi que Camille nous explique comment tester notre idées et comment structurer nos POCs (Lean Startup/Lean Canvas). L’objectif est de faire le minimum qui apporte de la valeur afin de vite éprouver notre idée sur le marché. Pour finir, Camille nous met en avant la facilité des nouveaux frameworks Web et le Cloud qui peuvent nous aider à tester notre application et à la développer plus rapidement.

Cloud et PaaS : les développeurs reprennent le pouvoir par Sacha Labourey

Après un très beau parcours chez JBoss puis Redhat, Sacha se lance dans le cloud et chez Cloudbees. Autant dire que le Cloud peut révolutionner le travail des développeurs. En effet, ce dernier leur permet de se concentrer uniquement sur le développement sans réfléchir aux problématiques d’infrastructures. Pour lui, il y a deux sorte de développeurs à Devoxx : les convaincus du cloud et ceux qui se disent « pourquoi pas ». Il met en avant les problématiques que rencontrent les développeurs lorsqu’ils doivent se préoccuper de la partie infra et explique en quoi le Cloud est là pour les aider. Selon lui, le Cloud annonce une révolution de nos métiers au même titre que le passage des développeurs Mainframe aux serveurs Unix/Wintel.

Big Data et Hadoop : Au secours de téraoctets de logs inexploitables chez l’un des plus grands sites marchands Européen.

Dans notre métier, nous avons rarement la possibilité de voir de nouvelles technologies et des nouveaux concepts s’appliquer chez un compte client. Cette présentation présentée par Pablo Lopez explique de manière concrète comment Hadoop a été mis en place pour parvenir à traiter un volumétrie importante de logs.

Une plateforme exigeante.

Pablo Lopez a débuté sa présentation en nous détaillant la plateforme de production :

• 1 million de visiteurs unique par jour.
• 200 000 ventes par jours avec des pointes à 300 000 selon les saisons (10 ventes / secondes!!).
• 500 serveurs de production, 80 applications hétéroclites, 5 JVM par serveur,
• 13 niveaux de load-balancing : concrètement, un visiteur fera 13 sauts de machine avant de voir sa page s’afficher sur son navigateur.

Le speaker nous a ensuite présenté quelques slides sur les logs :

• des logs de différents types sont générés dans différents fichiers : techniques, fonctionnel et analytiques (log indiquant par exemple qu’un visiteur a cliqué sur un encart publicitaire),
• 5 à 10 fichiers de logs par VM,
• 7 Go de logs par serveur et par jour !

Pour résumer, une plateforme comme on en voit rarement.

Le problème : trop de logs tue le log !

Plusieurs problèmes ont été remontés :

• Le volume de logs est colossal,
• La rotation des logs est trop rapide : la volumétrie étant énorme, la rotation des logs se fait toutes les 30 minutes en pic d’activité,
• Le transfert des fichiers de logs est laborieux et la collecte des logs des différents serveurs n’est pas totalement automatisée.

Lors d’un incident, celui-ci est remonté, le responsable du ticket doit alors effectuer la récupération de Go de logs sur sont poste et les analyser à base de commandes système => la réactivité est alors de 2 jours !

Les fonctionnalités recherchées.

La mise en place d’un système permettant de gérer les logs s’est avérée nécessaire. Plusieurs objectifs ont alors été identifiés :

• Centraliser les logs au même endroit (plutôt que sur les 500 serveurs),
• Être tolérant aux pannes : il n’est pas envisageable de perdre des lots,
• Permettre l’analyse des logs : trop de temps est perdue à rapatrier les logs et à analyser les centaines de Go de logs répartis dans des dizaines de fichiers,
• Faire de la remonter d’alerte,
• Archiver : permettre la comparaison des logs avec d’ancien logs (ex : comparer les logs de transaction bancaire d’un mois sur l’autre),
• Faire du temps réel.

La solution mise en œuvre.

Plusieurs technologies ont permis d’aboutir à une solution viable offrant les caractéristiques suivantes :

• transparence : les applications existantes ne sont pas impactées,
• tenue de charge : les 30 000 logs / seconde sont analysés sans problème,
• tolérance aux panne.

Syslog-ng

Chaque applicatif log est écrit via un appender log4J en UDP sur chaque serveur. Un processus Syslog-ng en local intercepte ces logs et les transmets en TCP à un serveur Flume centralisé. Syslog n’est pas capable de communiquer avec Hadoop.

Flume

Flume est capable de communiquer avec Hadoop. Il intercepte donc les logs transmis par les processus Syslog-ng de chaque serveur et les envoie à Hadoop.

Problème : tous les applicatifs ne sont pas développés en Java. Flume est capable d’effectuer un ‘tail’ sur un fichier de log.

Hadoop

Haddop est un système map / reduce capable de prendre un volume de données en entrée et de les regrouper en clé / valeur. Infine, chaque clé possède une liste de valeurs.

Ce processus de map / reduce se fait de manière distribuée sur un ensemble de nœud Hadoop. Le résultat est ensuite stocké dans un système de stockage Hadoop (HDFS). Pablo Lopez nous a expliqué que ce système de stockage n’était pas satisfaisant car le système de requêtage n’était pas assez simple et évolué pour permettre la génération de graphique en temps réel (Play).

MongoDB a ainsi été choisi pour stocker les résultats du map / reduce.

MongoDB

MongoDB est issu de la mouvance NoSQL et offre un système de stockage de type document. Cette solution a été retenue pour les raisons suivantes :

• offre un modèle élastique car la structure des données n’est pas figée,
• facile à interroger : une API de requêtage évoluée est fournie,
• les résultats sont en JSON,
• la solution est scallable.

Un excellent article de David Brassely expliquant précisément ce qu’est MongoDB est accessible ici.

Play

Play est un framework de présentation. Il propose une interface graphique permettant de générer des graphiques afin de, par exemple, de connaître le nombre de transactions bancaire dans une période données.

Conclusion

La solution est en production depuis fin 2011. Il se passe actuellement 2 minutes entre l’écriture d’un log et son arrivée dans MongoDB. Le log est ensuite exploitable pour être intégré à différent graphiques.

Les cas d’utilisation sont nombreux :

• Connaître le nombre de recherches d’un produit par rapport au nombre de ventes réalisées (pour l’ensemble des produits recherchés !) en quasi temps réel (2 minutes de latence).
• Tracer le robot Google pour comprendre sont comportement.
• Connaître le nombre de visiteurs « envoyés » par Google,
• Identifier un cas de fraude bancaire et lancer des actions en moins de 10 minutes (grâce à l’IP du visiteur qui est logée).