IoT et Big Data au programme du dernier AWS Summit

A l’occasion de l’AWS Summit qui s’est déroulé le 27 octobre à Paris, OCTO sortait officiellement la version papier de son livre blanc Cloud Ready Apps. C’était l’occasion d’assister à quelques conférences, parmi lesquelles Créez votre première application Big Data sur AWS et Construisez votre projet IoT avec une architecture Serverless. Voici notre compte-rendu pour chacune d’elles.

Les informations se veulent transcrites telles que présentées par les conférenciers, auxquelles s’ajoutent nos commentaires en italique.

Créez votre première application Big Data sur AWS

par Xavier Delacour, Solutions Architect

Une présentation des principes, des outils de l’éco-système AWS (propres à AWS ou non) puis une démonstration que nous avons rejouée à la suite de la conférence.

Présentation théorique

Selon le conférencier, toutes les sociétés font du Big Data en reproduisant le même pattern, seuls les outils changent. De notre point de vue, l’homogénéité de patterns remarquée par AWS se vérifie pour les traitements d’analytique classique et de preprocessing pour le Machine Learning. Sur ces aspects, on peut même dire que la stack technique proposée par AWS est courante. Par contre, concernant l’entraînement de modèles de Machine Learning, il n’existe pas encore de véritable consensus en termes d’outils, et les frameworks de calcul distribué proposés par AWS ne sont pas adaptés car les algorithmes actuels requièrent la totalité des données. Si l’on souhaite effectuer ces traitements dans le cloud, on s’appuiera plutôt sur des machines virtuelles. Un studio de Data Science serait néanmoins souhaitable de la part d’un acteur tel qu’AWS pour enchaîner plus facilement l’utilisation des différents éléments de son offre qui contribuent au processus de Machine Learning.

Revenons-en maintenant à la présentation. Voici les différentes activités du pattern évoqué par le conférencier, et pour chacune les outils proposés par AWS et utilisés dans la démonstration :

1 : collecter la data => AWS Kinesis Firehose, outil d’ingestion de données.

2 : stocker => dans AWS S3 (avec une durabilité de 99.99999999999%, soit onze 9 après la virgule).

3 : processer => AWS EMR (Elastic Map Reduce), un Hadoop managé qui accède nativement à S3 pour y puiser les données à traiter. Il est de plus possible d’utiliser des outils et frameworks tels que Spark, Hive ou Zeppelin. Les données issues des traitements peuvent être (re)déposées sur S3.

4 : analyser & visualiser => AWS Redshift qui est un data warehouse managé (basé sur PostgreSQL, avec des modifications conséquentes pour l’adapter aux gros volumes de données). On peut y stocker 1To / an pour 1000 dollars. AWS Quicksight est utilisé pour la visualisation.

 

stack-big-data

Démonstration

En partant d’un fichier de logs Apache, l’idée est d’identifier les requêtes HTTP qui causent le plus d’erreurs, sur la base des codes HTTP (200,404,…).

Préparation des outils

  • création d’un bucket S3 (espace de stockage)
  • dans AWS IAM (prononcez « I am »), l’autorisation est donnée à Firehose d’écrire dans S3 grâce à une policy (porteuse des droits) associée à un rôle que « prend » Firehose. Le rôle permet à l’application d’être considérée comme un utilisateur et ainsi d’hériter de ses droits.
  • création d’un stream Firehose dans lequel il est possible de charger des données et qui, toutes les X minutes (paramétrable), agrège les données reçues dans l’intervalle de temps et constitue un zip qu’il dépose dans S3.
  • création d’un cluster EMR. On paramètre le cluster pour démarrer pendant l’installation des applications de traitement des données : Hive, Spark, Zeppelin. La création du cluster EMR prend 20 minutes côté AWS (il s’agit surtout du provisionning des instances EC2 sur lesquelles tourne EMR).
  • création dans IAM de la policy et du rôle adéquats pour que Redshift puisse accéder à S3.
  • création d’un data warehouse Redshift

Assez peu de lignes de commande AWS suffisent à instancier tout ça, ce qui est mis en avant par le conférencier.

Une bonne partie du temps nécessaire à la configuration est consacrée à la sécurité, en particulier si vous utilisez pour la première fois les services (ce qui est probable au moins pour une partie des services, au vu du titre de la conférence) :

  • gestion des autorisations entre les briques AWS
  • gestion des autorisations nécessaires pour passer des commandes aux briques AWS via l’interface en ligne de commande AWS
  • création et récupération des diverses clés (clés SSH de EC2 pour EMR, access key/secret key pour l’interface en ligne de commande AWS)
  • ajout de votre IP publique à la liste autorisée pour accéder aux instances EC2 et VPC sur lesquelles tournent respectivement EMR et Redshift

Tout ceci est un peu touffu, et pas toujours documenté par AWS de manière immédiatement accessible. Par exemple, l’accès à Redshift depuis un requêteur SQL implique d’inclure l’IP de l’ordinateur à la liste blanche de la VPC, ce qui n’est pas mis en avant dans les indications de connexion pointées depuis la console Web Redshift.

Le point fort de l’offre d’AWS réside dans l’intégration des différentes briques (souvent des outils tiers) qui se montre aboutie, leur instanciation est facile, mais la configuration de la sécurité est moins ergonomique.

Exploitation des données

  • Le format des logs est Common Log Format (CLF), le format par défaut Apache.
  • Un script Python 2 avec le SDK AWS Boto 3 sert à importer les logs dans Firehose.

Cela prend du temps : 2 heures pour charger le fichier de 8.8 Mo. La raison nous semble être que le script effectue séquentiellement, pour chaque ligne du fichier de logs, un appel à Firehose via la fonction PutRecord de l’API : lecture de la ligne dans le fichier texte, appel à Firehose, attente du retour, lecture de la ligne suivante, etc… Il existe alternativement la fonction PutRecordBatch qui permet d’envoyer jusqu’à 4 Mo en un seul appel. Nous ignorons pourquoi elle n’a pas été choisie pour cette démonstration, peut-être est-ce pour que le script soit aussi simple que possible.

  • Au bout d’1 minute (correspondant à la fréquence paramétrée), la première archive zip arrive dans S3.
  • Un tunnel SSH est créé pour accéder à Zeppelin comme si ce dernier était sur le SI « local ». Les analystes peuvent alors, au travers de sa console web, interagir avec le cluster Spark, pour lancer des commandes Python par exemple, afficher des graphiques, et exécuter des commandes Spark SQL et Hive :
    • Spark est présenté comme une version moderne et rapide de Map Reduce. Tous les traitements sont faits en mémoire, Spark n’écrit sur le disque que lorsque le traitement est terminé. Il dispose d’API pour Java, Scala, Python et R. Spark est dans notre cas utilisé pour parser les données et les injecter dans un modèle de données SQL.
    • Après le traitement avec Spark, Hive permet d’exporter vers S3 les données de manière partitionnée (dynamic partitioning, avec des sous-répertoires) et compressée.
  • En se connectant à Redshift avec un requêteur SQL (à noter qu’AWS préconise désormais d’utiliser un driver Redshift plutôt qu’un driver PostgreSQL), nous faisons apparaître la requête la plus génératrice d’erreurs 404. Résultat : un favicon.
  • Quicksight permet de créer des représentations telles des histogrammes à partir des données se trouvant dans Redshift. Il ne fait pas encore l’objet d’une release officielle par AWS. L’effet démo a eu lieu, cette dernière partie n’a pas pu être montrée.

Le support de présentation d’AWS contient des informations pour rejouer la démonstration, notamment en slide 7 un lien vers l’ensemble des commandes, à personnaliser. Il est disponible ici.

Construisez votre projet IoT avec une architecture Serverless

par Philippe Desmaison, Partner Solutions Architect

Le conférencier commence par mettre en avant les avantages de l’architecture Serverless promue par AWS, suivant laquelle on s’appuie sur des « fonctions as a service », en regard des contraintes qui existent lorsqu’on gère soi-même des serveurs :

  • provisionning et scaling transparents
  • la haute-disponibilité est gérée
  • aucune instance n’est visible au niveau programmatique, on travaille sur la fonction elle-même

Ainsi, le terme équivoque Serverless est à comprendre comme « architecture s’appuyant sur des services managés (ou PaaS) ». Littéralement, il suggère plutôt une architecture P2P, mais cela eut été surprenant de la part d’AWS, au vu de son modèle économique. Au passage, on remarque que la présentation des concepts est un peu biaisée, en mélangeant type d’hébergement (on premise, cloud) et niveau de mutualisation/abstraction (PaaS, machines virtuelles, serveurs physiques classiques). Comme alternatives à la gestion classique de ses propres serveurs par une organisation, on peut théoriquement trouver des machines virtuelles dans le cloud, ou bien du PaaS hébergé on premise. Ceci vise certainement à présenter le PaaS AWS comme solution naturelle et novatrice aux douleurs éprouvées en matière de gestion de serveurs.

L’architecture Serverless s’appuie sur une myriade de briques AWS. La pierre angulaire de cette architecture est AWS Lambda qui permet d’exécuter du code Node.js, Java ou Python. On voit dans l’exemple ci-dessous qu’on retrouve Lambda un peu partout dans l’architecture :

 

serverless

source : https://s3-eu-west-1.amazonaws.com/contenuenfr/2016+AWS+Enterprise+Summit+Paris/Track+4+Session+3+-+Construisez+votre+projet+IoT+avec+une+architecture+Serverless.pdf

 

  • L’architecture est orientée événements donc le code est exécuté seulement quand un traitement est nécessaire, et seuls ces moments font l’objet d’une facturation. La facturation de Lambda se fait par tranche de 100ms d’exécution de code. Ainsi, mieux l’application est codée, moins le service revient cher. Le mauvais côté est la pression qui pourrait être mise sur les développeurs pour réduire les coûts. Le bon côté est que cela pourrait encourager chez les développeurs une compréhension fine des mécanismes techniques ayant une incidence sur la performance.
  • Concernant le dimensionnement de Lambda, le choix se fait sur la taille de la capsule de mémoire vive, de 128 Mo à 1.5 Go. Les quantités de CPU et de réseau sont alors allouées en proportion de la mémoire vive. Lambda est intégrée nativement avec d’autres services AWS, qui peuvent jouer le rôle de triggers (S3, API Gateway, Kinesis, DynamoDB..) ou de destination après le traitement effectué par une fonction Lambda (DynamoDB, SNS pour envoyer des notifications vers des applications,..)

L’IoT par AWS a ensuite été présenté (certains points visant à montrer les raisons pour lesquelles l’architecture Serverless d’AWS est adaptée à l’IoT et plus particulièrement à AWS IoT):

  • les objets interagissent avec le monde réel : ils sont par nature orientés événements.
  • une authentification TLS mutuelle est réalisée entre les objets et AWS IoT : l’objet doit montrer patte blanche (l’authentification existe aussi entre AWS IoT et les autres services AWS)
  • la plate-forme AWS IoT supporte les protocoles MQTT, MQTT over WebSockets et HTTP
  • le paradigme d’intégration est celui de messages échangés via des topics MQTT (dans le cas où l’on utile HTTP dont le paradigme n’est pas basé sur des messages et des topics, seul le publish est possible via des POST, et des GET permettent de récupérer les données).
  • le concept de device shadow permet aux applications d’échanger avec les objets même si ceux-ci sont connectés de manière intermittente. Le device shadow, sous forme d’un JSON véhiculé par les messages et mémorisé par la plate-forme, comprend :
    • le dernier état connu de l’objet (reported) que les applications peuvent lire même lorsque l’objet est déconnecté
    • le dernier état demandé par une application (desired), que l’objet peut lire lorsque sa connexion avec AWS IoT est rétablie.

En MQTT, le dernier état connu est géré au travers du retained message. De notre compréhension, AWS IoT devant être accessible aussi bien aux objets via MQTT qu’aux applications via HTTP, la problématique est gérée en maintenant un document JSON, accessible au travers des topics MQTT et de l’API REST.

  • du fait du parc d’objets, il peut y avoir beaucoup de connexions à maintenir, en quantité qui augmente ou diminue. La scalabilité d’AWS IoT est mise en avant à ce sujet.
  • un moteur de règles se basant sur le payload des messages permet différents comportements, par exemple : déclenchement d’une fonction AWS Lambda, alimentation d’une base de machine learning pour prédire une tendance, déplacement vers d’autres topics ou d’autres systèmes, filtrage, transformation.

Une démonstration (sous forme de vidéo enregistrée, pour éviter l’effet démo, dixit le conférencier) a été faite. L’architecture de celle-ci comportait un bouton IoT AWS, le service AWS IoT, AWS Lambda et AWS SNS pour l’envoi d’un e-mail lors de l’appui sur le bouton.

Enfin, l’exemple a été donné d’un robot aspirateur iRobot Roomba qui repose exclusivement sur une architecture Serverless. Pour illustrer la valeur des données générées par les objets connectés, le conférencier a expliqué que le robot, au fil de ses balades, constitue une carte de l’intérieur où il officie. Ceci peut permettre l’utilisations des données à des fins autres que la navigation utile à la fonction première du robot-aspirateur. A la suite de la conférence, nous avons tenté d’en savoir plus sur ce point, mais le conférencier nous a dit ne pas savoir ce qui est fait en la matière par le fabricant.

aspirateur

source : https://www.technologyreview.com/s/541326/the-roomba-now-sees-and-maps-a-home/

 

Le support de présentation d’AWS est disponible ici.

Ensuite

La date du prochain AWS Summit parisien a été annoncée lors des conférences : ce sera le 8 juin 2017.

Dans un prochain article, nous mettrons en application IoT et Big Data au travers du prototypage d’un objet connecté.