BT

Diffuser les Connaissances et l'Innovation dans le Développement Logiciel d'Entreprise

Contribuez

Sujets

Sélectionner votre région

Accueil InfoQ Articles Lambda-Architecture sur Microsoft Azure, entretien avec Benjamin Guinebertière

Lambda-Architecture sur Microsoft Azure, entretien avec Benjamin Guinebertière

Favoris

A quelques jours des TechDays 2015, InfoQ FR a pu rencontrer Benjamin Guinebertière pour lui poser quelques questions sur les sessions qu'il animera pendant ces 3 jours de conférences, les 10, 11 et 12 février prochains.

InfoQ FR : Bonjour Benjamin, pouvez-vous vous présenter et nous parler de votre rôle chez Microsoft ?

Benjamin Guinebertière : Bonjour Nicolas, je travaille pour Microsoft France dans la division DX (developer experience) en tant que Technical Evangelist. Mon rôle consiste à faire connaître la techno, et récupérer des feedbacks ; cela se fait en parlant dans des événements comme les TechDays ou bientôt noSQLMatters par exemple, mais aussi en aidant des clients ou partenaires de tailles différentes (startups, éditeurs de logiciels, SSII, PME, grands comptes) à démarrer des projets. Au niveau techno, je travaille sur Azure et plus particulièrement tout ce qui est autour de la données (big data, machine learning).

InfoQ FR : On parle beaucoup aujourd'hui des objets connectés. Quelles sont les architectures mises en oeuvre pour ces nouveaux systèmes ?

Benjamin Guinebertière : Oui, ces objets connectés représentent une masse de données qui arrivent et qu'il faut traiter. C'est tout naturellement que les scénarios Big Data qu'on a vu apparaître il y a quelques années et qui sont maintenant à maturité facilitent les nouveaux scénarios d'objets connectés. Si on compare une personne qui tweete 10 fois par jour (ce qui est déjà beaucoup) à une sonde qui envoie un signal toutes les minutes et qu'on considère en plus qu'il y aura beaucoup plus d'objets connectés que de personnes en ligne, on comprend que les mégadonnées n'ont pas fini d'arriver. De mon côté je parle du traitement de cette donnée, dans Azure, en allant de l'ingestion depuis les passerelles (gateways) ou les objets eux-mêmes, à l'utilisation des données agrégées et pré-machées par des algorithmes de Machine Learning. Comme je n'ai pas de spécialité verticale (santé, automobile, manufacturing, logistique, hôtellerie, ...), j'adopte un plan technique pour organiser les différents sujets et différentes briques d'Azure. Je m'appuie sur une architecture classique du big data : la lambda architecture.

InfoQ FR : Pouvez-vous nous définir le terme de Lambda-Architecture ?

Benjamin Guinebertière : La lambda architecture tire son nom de la forme de cette lettre. On aurait pu appeler cela l'y architecture, mais cela aurait été moins beau. Cette architecture consiste à considérer deux branches de traitement complémentaires de la donnée :

  • le traitement batch sur les données accumulées depuis un certain temps (par exemple les 3 dernières années)
  • le traitement au fil de l'eau des données pour une vue en quasi temps réel de ce qui arrive

On trouve de nombreux articles sur cette architecture dont un sur Dr Dobb's et un sur InfoQ EN. Ce qu'il est intéressant de noter est que ces deux branches (batch et quasi temps réel) se complètent. Si on prend l'exemple de la maintenance prédictive où on mesure des vitesses de rotation et des températures par exemple, ces deux indicateurs sont intéressants à regarder sur le long terme et dans l'instant. C'est d'ailleurs en faisant des requêtes sur le long terme qu'on pourra en déduire les bons indicateurs et seuils associés à surveiller. A l'inverse, les indicateurs instantanés peuvent inciter à vérifier des tendances à long terme. On peut aussi noter que la branche batch utilise des requêtes variées sur des données assez figées, alors que la branche quasi temps réel fait passer des flux de données dans des requêtes assez figées (ex : moyenne de la température par zone dans les 3 dernières minutes glissantes).

InfoQ FR : Aujourd'hui, quelles sont les différentes briques disponibles pour mettre en place une Lambda-Architecture sur Azure ?

Benjamin Guinebertière : Je vais évoquer cela sous la forme de ce qui est instanciable dans notre cloud public, mais une partie de ces briques est indépendante. D'ailleurs, un des critères de choix entre les différentes briques peut être le niveau de réversibilité que l'on souhaite vs la simplicité de mise en oeuvre ou de gestion de l'infrastructure dans le temps (je devrais aborder ce sujet dans le Keynote Azure). Pour l'ingestion des événements, on utilise classiquement Apache Kafka. Azure propose aussi un service clefs en mains appelé Event Hubs. On a diverses façons d'héberger Hadoop dans Azure que ce soit dans des VMs ou en tant que service. On a également tout un ensemble de bases de données SQL ou noSQL. Pour le traitement quasi temps réel, il y a Storm avec Hadoop, et Azure propose aussi Stream Analytics qui permet de faire de simples requêtes SQL sur les flux de données. Pour la dataviz, il y a tout ce qui est HTML5, mais également PowerBI. Parallèlement à tout cela, on peut utiliser le machine learning et nous avons une offre en tant que service depuis l'été dernier avec Azure Machine Learning que je montrerai en quelques minutes dans la session d'ouverture le mardi matin.

InfoQ FR : Pouvez-vous nous détailler les différentes options pour gérer la partie Batch de l'architecture ?

Benjamin Guinebertière : Bon, évidemment cela tourne autour d'Hadoop, voire Spark, qui lui-même peut s'installer au dessus d'Hadoop. En termes d'Hadoop, Azure propose plusieurs options. La plus simple est de créer, depuis le portail ou en script un cluster HDInsight, qui est de l'Hadoop en tant que service. Même s'il s'agit d'Hadoop as a service, il existe des personnalisations possibles comme le fait d'y installer du Spark pour ne prendre qu'un exemple. Vous pouvez voir une démo de cela dans cette vidéo à partir de la minute 01h08m06s. Si on veut un cluster Hadoop plus personnalisable, Hortonworks a mis à disposition dans la marketplace d'Azure un assistant qui crée le réseau, le stockage, les VMs constituant le cluster HDP. Et Cloudera aussi a un assistant de création d'un cluster CDH. Si on souhaite prendre les sources Hadoop et installer soi-même un cluster Hortonworks, Cloudera, MapR ou pur Apache, on peut scripter tout cela en PowerShell ou en bash avec Azure CLI.

InfoQ FR : Quels sont les avantages de ces trois solutions ?

Benjamin Guinebertière : Si on est à la fois un expert d'Azure et d'Hadoop, et que l'on souhaite personnaliser complètement son cluster, la troisième option est la meilleure. Si on ne souhaite pas forcément partir de zéro pour l'installation du cluster, l'assistant Hortonworks ou Cloudera fait gagner du temps tout en fournissant une infrastructure qu'on peut ensuite tout autant personnaliser. Enfin, pour se concentrer sur les requêtes plus que sur l'infrastructure, on peut juste demander un cluster HDInsight. Dans cette dernière option, il est également à noter que le support technique d'Azure pourra répondre à des questions de plus haut niveau comme des incidents qui impliqueraient des requêtes Hive par exemple.

InfoQ FR : Pour la partie stockage des données, quelles sont les solutions que vous recommandez aujourd'hui ?

Benjamin Guinebertière : Dans les différentes déclinaisons Hadoop dont je parlais avant, on peut bien sûr utiliser le système de fichiers HDFS standard d'Hadoop. En revanche, dans le cloud, on peut avoir des clusters seulement quelques heures par jour. Dans ce cas, il peut être utile de séparer la puissance de calcul et le stockage. Cela permet d'optimiser fortement les coûts. Pour tout cela, on peut utiliser les blobs du stockage Azure. On y accède comme à HDFS avec wasb:// au lieu d'hdfs://. C'est d'ailleurs le système de fichiers distribué par défaut dans HDInsight.

InfoQ FR : Si on s'intéresse maintenant à la partie captation des données, que propose Azure en standard ?

Benjamin Guinebertière : Les données des objets connectés peuvent arriver dans des fermes Web par exemple qui pourront les mettre en queue pour traitement. Mais on propose un système de queue pensé pour ce scénario, avec de la réception suivant les protocoles AMQP (en mode connecté) ou HTTPS (en mode déconnecté) ; il s'agit d'Event Hubs. On l'a testé avec 1 million de requêtes par seconde sur un seul endpoint. Des problématiques de partitionnement, de révocations des droits à envoyer de la donnée sont pris en compte dans Event Hubs.

InfoQ FR : Quel est le positionnement d'Event-Hubs vis-à-vis d'une solution comme Apache Kafka ?

Benjamin Guinebertière : Event Hubs et Apache Kafka jouent le même rôle dans l'architecture lambda. Dans le cadre d'Azure, Event Hubs présente l'avantage d'être disponible en tant que service prêt à l'emploi. Il y a bien sûr des différences techniques comme le support d'AMQP dans Event Hubs, mais je pense que le choix se fait plutôt en fonction de critères d'environnement. Si on est dans un monde très Hadoop déployé sur différents clouds privés et publics, capitaliser sur Kafka sera logique. Si à l'inverse on cherche à avoir quelque chose de rapidement opérationnel et simple à maintenir en conditions opérationnelles sur Azure, Event Hubs est logique.

InfoQ FR : Et pour le traitement en quasi temps réel, quelles solutions dans Azure ?

Benjamin Guinebertière : Là encore, plusieurs possibilités. Dans l'univers Hadoop, c'est Storm, et on peut instancier par exemple HDInsight avec Storm. C'est cette option qui est à privilégier pour des développeurs Java, ou des projets qui ont des besoins assez complexes. Du côté service, Azure Stream Analytics est très simple à mettre en oeuvre. On va définir l'entrée, la sortie, et la ou les requêtes SQL sur des fenêtres de temps. C'est l'option à privilégier pour des développeurs plus familiers d'SQL que de Java.

InfoQ FR : Les données sont ensuite stockées, pouvez-vous nous faire un petit panorama des technologies disponibles sur Azure ?

Benjamin Guinebertière : L'output d'un traitement batch peut-être en format brut (HDFS/Blobs), ou en base de données SQL ou NoSQL pour des use cases d'interactivité avec l'utilisateur. Pour les traitements en quasi temps réel, outre le stockage brut (par exemple, en Storm, un bolt va aussi copier la donnée pour stockage), la sortie va principalement être en base de données SQL ou noSQL. Côté bases relationnelles, Azure dispose du service SQL Database qui est une déclinaison du moteur de SQL Server adapté aux problématiques de cloud (disponible rapidement à la demande, multi locataires, scale out, ...). On peut aussi instancier divers moteurs dans des VMs Azure. Bien sûr, SQL Server est particulièrement bien intégré (voir par exemple cet article très récent), mais on peut aussi installer Oracle Database, SAP Hana, MySQL, MariaDB, PostGreSQL et d'autres. Côté bases noSQL, Vincent Heuschling, Victor Coustenoble et moi passerons en revue un certain nombre d'options dans la session Panorama des offres NoSQL disponibles dans Azure. Le stockage Azure a un service Azure Tables de type clefs/valeurs permettant typiquement de stocker des To de logs. On peut aussi instancier Cassandra ou Datastax Enterprise dans le IaaS d'Azure et tirer parti de la fonctionnalité multi-datacenter de cette base orientée colonnes. Toujours dans les bases orientées colonnes, HBase s'instancie au dessus d'Hadoop et HDInsight a une déclinaison HBase dont la particularité est de stocker ses données dans les blobs Azure pour que le contenu de la base reste quand on détruit le cluster et soit repris quand on recrée un cluster pointant sur le même conteneur de blobs. La base de données orientée documents la plus connue est sûrement MongoDB qui peut s'instancier sous différentes formes dans Azure ; cela peut aller jusqu'à demander à MongoDB ou MongoLabs d'héberger et opérer eux-mêmes la base dans Azure. Microsoft a également développé sa propre base DocumentDB disponible en tant que service uniquement dans Azure. Pour les bases de données orientées graphes, au delà de NEO4J, Titan est intéressante car elle peut s'appuyer sur HBase ou Cassandra, deux bases dont nous venons de parler.

InfoQ FR : Comment se présente la partie Dataviz ?

Benjamin Guinebertière : Azure Web sites permet bien sûr d'héberger des tableaux de bord en pur HTML5 avec des frameworks tels que d3js. SignalR peut aussi jouer un rôle très intéressant ici car il simplifie grandement l'envoi de données de Storm vers d3js par exemple. Au niveau protocole, SignalR utilise Web Sockets si c'est possible, mais s'occupe aussi de remplacer cela par une alternative comme le long polling si nécessaire. Si on va vers des solutions plus intégrées à la Tableau ou QlikView, Microsoft a Power BI. Cette offre inclut un outil de mashup/ETL (Power Query) aussi simple à utiliser qu'une importation de fichiers dans Excel, mais avec des possibilités bien plus importantes comme la transformation de données JSON venant de Facebook en un tableau classique lignes/colonnes. Il y a également PowerPivot qui implémente un cube en mémoire. On arrive à la DataViz à proprement parler avec Power View et Power Map (données sur des cartes en 3D). On peut ensuite exposer cela en Web avec SharePoint Online. Une nouvelle version de Power BI est actuellement en version préliminaire aux US qui est encore plus Web.

InfoQ FR : La dernière brique de l'architecture est la partie Machine Learning, Quelle est aujourd'hui la stratégie de Microsoft ?

Benjamin Guinebertière : Cette stratégie est décrite dans un billet du 2 décembre dernier pour l'intégration de Python dans Azure Machine Learning que ce soit au niveau du langage, des modules, mais aussi de l'interaction avec IPython. L'intégration de R dans Azure Machine Learning va bien sûr continuer également avec l'annonce récente de rachat de Revolution Analytics. Un des buts d'Azure Machine Learning est de permettre l'intégration de différentes librairies de machine learning de façon simple.

InfoQ FR : Avez-vous des cas clients en production sur de telles architectures ?

Benjamin Guinebertière : J'aime bien l'histoire de Thyssen Group car elle englobe bon nombre des concepts évoqués plus haut. On a la fois des objets connectés (les ascenseurs) et une application intéressante du machine learning : la maintenance prédictive.

InfoQ FR : Merci beaucoup Benjamin pour vos réponses, avez-vous quelque chose à ajouter ?

Benjamin Guinebertière : Oui, rendez-vous aux TechDays. Si vous ne savez pas quelles sessions Azure aller voir, ce billet peut vous aider. Si vous n'avez pas d'affinité particulière avec Microsoft, venez quand même, pour voir des sessions telles que celle d'Olivier Grisel sur SciKit-Learn.

Vous pouvez vous inscrire aux TechDays sur la page suivante : Inscription.

Evaluer cet article

Pertinence
Style

Contenu Éducatif

BT