Devoxx UK 2018 – Jour 2

 English version available

Cette année, j’ai assisté aux 2 jours de la conférence Devoxx UK à Londres les 10 et 11 mai. Cet article est un résumé des notes que j’ai prises pendant le deuxième jour. Vous pouvez lire l’article précédent à propos du premier jour. Et si vous souhaitez obtenir plus de détails sur un talk, vous pouvez regarder la vidéo associée.

Devoxx UK a eu lieu au Business Design Centre à Londres

Deep Learning: The Future of Artificial Intelligence, avec Matthew Renze

Par le passé, nous devions programmer un ordinateur de manière explicite, étape par étape, pour résoudre un problème (impliquant des instructions if-then, des boucles et d’autres opérations logiques). A l’avenir, les machines vont apprendre à résoudre un problème par elles-mêmes, nous devons juste leur fournir les données.

Qu’est ce que le Deep Learning?

Deep Learning (apprentissage en profondeur en bon français) est une forme d’Intelligence Artificielle (IA) qui utilise un type de Machine Learning (ML) appelé Réseau Neuronal Artificiel constitué de plusieurs couches cachées pour tenter d’apprendre les représentations hiérarchiques des données sous-jacentes afin de faire des prédictions sur des données nouvelles.

L’apprentissage automatique (ou Machine Learning) est essentiellement l’utilisation des statistiques appliquées aux problèmes de l’intelligence artificielle. Nous enseignons aux machines la résolution de problèmes en identifiant des modèles statistiques à partir des données.

Utilisation de Données (existantes) -> pour apprendre une Fonction -> afin d’effectuer une Prédiction (sur des nouvelles données)

Un réseau de neurones est un algorithme ML basé sur une approximation très grossière de la façon dont nous pensons que le cerveau et les neurones fonctionnent (le cerveau est toujours une boîte noire pour les scientifiques).

Un neurone artificiel prend un ensemble d’entrées, applique une fonction pour produire un ensemble de sorties. Nous représentons ce neurone mathématiquement (c’est-à-dire que les entrées et les sorties sont des nombres) dans le but de l’utiliser dans un modèle de calcul.

Un réseau de neurones est composé de plusieurs neurones organisés en différentes couches: la couche d’entrée (les données que nous fournissons), 1 ou plusieurs couches cachées et la couche de sortie (la prédiction). Un réseau neuronal profond (deep neural network) a plus d’une couche cachée. L’utilisation de plus d’une couche cachée permet principalement de modéliser une fonction beaucoup plus complexe qu’avec une simple couche.

Un exemple de Deep Learning

Un exemple de réseau neuronal profond est un modèle de reconnaissance de personne basé sur une image. Les couches cachées inférieures représentent des formes abstraites comme les primitives géométriques (par exemple, les lignes horizontales et verticales) tandis que les couches intermédiaires représentent des entités plus complexes comme des parties spécifiques du corps (bouche, nez, oeil, etc.), le visage est représenté dans les couches cachées les plus hautes, pour être en mesure d’identifier la personne. La précision augmente lorsque nous approchons de la dernière couche pour finalement être en mesure de faire une prédiction.

Pourquoi parlons-nous de Deep Learning seulement maintenant?

Après tout, le premier algorithme ML Perceptron a été créé en 1957, il y a plus de 60 ans!

• Nous vivons à l’ère du Big Data. Au cours des deux dernières années, nous avons créé plus de données que pendant toute l’histoire humaine. Nous n’avons jamais eu autant de données disponibles, ces données sont essentielles pour entraîner des modèles complexes.
• Les ordinateurs n’ont jamais été aussi puissants: des processeurs plus rapides, plus de mémoire, des disques SSD. Nous pouvons aussi tirer parti de la puissance de calcul des GPU, les opérations matricielles sont nécessaires pour les graphismes des jeux vidéo, mais aussi pour le ML. Nous avons également accès à des technologies de calcul distribué où nous pouvons partager le traitement de données entre plusieurs machines.

Que pouvons-nous faire avec le Machine Learning?

• Classification. Nous voulons prédire une variable discrète qui ne peut prendre qu’un certain nombre de valeurs. Est-ce un chat ou un chien? Cet email est-il un spam ou non? Est-ce que cette personne a un cancer ou pas? Quelle est la catégorie de cet article?
• Régression. Nous voulons prédire une variable continue qui a un nombre infini de valeurs possibles. A quel prix devrais-je vendre cette maison? Quel est le niveau de risque crédit pour ce demandeur?
• Génération de texte. Générer le titre d’un article, la description d’une image en fonction de son contenu, convertir la voix en texte pour du sous-titrage automatique.
• Génération d’image. Simuler le vieillissement du visage, peindre un nouveau Rembrandt que même un expert ne pourrait pas identifier comme un faux, créer des célébrités qui semblent familières, mais qui n’existent pas, créer une image basée sur une description textuelle.
• Génération audio. Mettre en relation un algorithme et un humain lors d’un appel téléphonique (Google Duplex), éditer votre voix en fonction d’un texte pour éviter de refaire un enregistrement dans le cas d’une erreur dans votre speech.
• Génération de vidéos. Basé sur des rushes de vidéos et d’audios de Barack Obama, créer une nouvelle vidéo avec une synchronisation labiale gérée par l’IA.

Si vous avez examiné plus en détail certains des exemples ci-dessus, vous avez probablement eu du mal à faire la différence entre un contenu réel et un contenu généré par ordinateur. C’est assez effrayant quand on y pense et on peut à peine imaginer comment ça sera dans 10 ans!

Comment puis-je commencer si je veux faire du ML dans mon entreprise?

Option 1 – Deep Learning as a Service (Google Cloud, AWS, Microsoft Cognitives, IBM Watson…)
Cela implique qu’une société tierce possède le modèle et les données. Vous pouvez interroger leur API avec vos nouvelles données afin de faire une prédiction.
Cette option est utile pour les cas d’utilisation restreints, si vous ne souhaitez pas réinventer la roue et utiliser un modèle déjà entrainé.
Pour: Simple, rapide, peu coûteux
Contre: Restriction sur les usages, éloigné (par exemple, vous n’êtes pas protégé contre les pannes de réseau ou la latence), paiement à l’usage (si votre utilisation augmente, le coût également)

Option 2 – Deep Learning platform (Microsoft Azure, Cognitive Services…)
Cette option est utile pour les cas d’utilisation personnalisés. Vous uploadez vos données pour entraîner le modèle (transfert d’apprentissage), puis vous pouvez interroger une API pour obtenir vos prévisions.
Pour: Simple, rapide, peu coûteux
Contre: Vous avez besoin de données d’entraînement pour entraîner votre modèle, éloigné, paiement à l’usage (par transaction pour la prédiction, mais aussi les transactions liées à l’entraînement)

Option 3 – Do it yourself (TensorFlow, Torch…)
A utiliser si les options 1 et 2 ne suffisent pas. Vous créez votre propre algorithme à partir de zéro, fournissez les données et vous l’hébergez vous-même.
Pour: Personnalisé (vous pouvez optimiser et tuner le modèle comme vous l’entendez), local, privé (au cas où vous avez affaire à des données sensibles)
Contre: Complexe, pas mal de travail, cher

Teaching kids about machine learning, avec Dale Lane

Dale a créé un site Web pour enseigner le Machine Learning aux enfants en utilisant la plate-forme de programmation visuelle Scratch. Scratch est un moyen d’aborder la programmation pour les enfants avec une interface simple où vous pouvez glisser/déposer des blocs représentant des opérations de programmation (boucles, déclarations if-then…) et les assembler pour créer une logique plus avancée. Dale utilise ScratchX (extensions expérimentales pour Scratch) et a créé de nouveaux blocs liés au Machine Learning (en utilisant IBM Watson sous le capot).

Il a imaginé de nombreux exercices pour que les enfants puissent appréhender les différents concepts de ML en utilisant des exemples concrets et amusants. Les exercices mélangent la reconnaissance de texte, de nombre et d’image. Chaque exercice est généralement composé d’une phase d’entraînement du modèle depuis l’application web et d’une phase d’évaluation avec la prédiction visualisable depuis Scratch. Vous pouvez également affiner les données d’entraînement et voir les effets sur le modèle et sa prédiction.

• Créer un chatbot, par ex. un animal capable de répondre à des questions sur son espèce.
• Prédire à partir de quel journal un article a été extrait en utilisant son titre.
• Faire en sorte que Pacman évite les fantômes en jouant plusieurs fois au jeu. Plus vous jouez et entraînez le modèle, plus Pacman sera bon.
• Catégoriser des images. Uploader des images de tasses et de voitures pour entraîner le modèle, de sorte qu’il puisse classer une nouvelle image encore inconnue dans une de ces 2 catégories. Uploader des images de couverture de livres pour différentes catégories (science-fiction, romance, thriller…), de sorte que le modèle puisse prédire la catégorie d’une nouvelle couverture. Pour rendre l’exercice plus interactif, vous pouvez également uploader des images à partir de la webcam, par exemple prendre des photos de votre main pour le jeu pierre / papier / ciseaux et jouer contre l’ordinateur. L’algorithme reconnaîtra la forme que vous faites avec vos mains si vous l’entraînez suffisamment.
• Reconnaître un code postal écrit à la main pour savoir dans quelle ville le courrier doit être livré, un bon exemple tiré de la vraie vie.
• Jouer au jeu « Où est Charlie? ». L’ordinateur détecte automatiquement où Scratch le chat est situé dans une image.
• Et beaucoup d’autres exercices.

Dale a également mentionné les problèmes liés à l’IA:

• Les problèmes avec l’arrière-plan ou les conditions météorologiques. Si c’est évident pour un humain, un ordinateur peut commettre des erreurs idiotes si le jeu de données d’entraînement est incomplet.
• L’histoire des chars russes où le modèle a été entraîné avec des images haute résolution pour les chars américains, mais avec des images basse résolution et floues pour les chars russes. Dans la réalité, le modèle s’est avéré être mauvais pour identifier les chars.
• Google photo peut ajouter automatiquement un texte pour décrire une image, certaines personnes noires se sont vu être qualifié de gorilles…
• Un modèle qui peut conseiller des médicaments, mais qui est sponsorisé par un géant pharmaceutique. Que se passe-t-il si l’entreprise demande d’ajouter plus de références de son produit phare dans le jeu d’entraînement, est-ce une bonne chose?

Il y a beaucoup de notions importantes autour de l’éthique, des préjugés, du surajustement (overfitting) des modèles et de la qualité du jeu d’entraînement. Il est important que les enfants comprennent cela par eux-mêmes, et habituellement c’est le cas!




A la fin, Dale nous a donné quelques liens pour aller plus loin:

• Machine Learning for Kids le site de Dale où vous pouvez trouver tous ses exercices.
• Teachable Machine from Google pour entraîner un modèle avec votre webcam.
• Quick, Draw! from Google pour reconnaître un dessin.
• Moral Machine from MIT pour juger différentes situations impliquant une voiture autonome.




Easy Microservices with JHipster, avec Sendil Kumar N

Cette présentation était une session de live-coding. J’ai entendu parler de JHipster depuis pas mal de temps, mais je n’ai jamais eu l’occasion de le voir en action et le fait que le projet ait été initié par un développeur français était une autre raison d’y aller.

JHipster accélère la création de nouvelles applications en générant le code boilerplate et en gérant la majeure partie de la configuration (par exemple la configuration des fichiers Kubernetes, des POM Maven, etc.). Il s’agit d’un outil en ligne de commande avec lequel vous pouvez choisir de créer une application de type monolithe, un microservice ou un UAA (User Accounting and Authorizing service pour sécuriser votre app avec OAuth2). Une fois que vous avez choisi votre type d’application, beaucoup d’options s’offrent à vous pour la stack technique: frontend, backend, source de données, build, logging, déploiement CI/CD, registre de service, documentation (par exemple Swagger) sans oublier les frameworks de tests.

Pour la démo, Sendil a créé une application Gateway qui interrogeait un microservice. Il a exécuté l’application localement et l’a ensuite déployé sur Google Cloud Platform (GCP) via Kubernetes, sans avoir à taper une seule ligne de code.

Choisir les frameworks et les technologies sera probablement la partie la plus difficile, car il y a tellement d’options. Vous devez également garder à l’esprit que vous devez affiner la configuration (par exemple, la configuration par défaut qu’ils fournissent pour Kubernetes peut ne pas convenir à vos besoins).




Troubleshooting & Debugging Production Microservices in Kubernetes, avec Ray Tsang

Ray nous montre une petite application de livre d’or où un utilisateur peut poster un message avec un nom (« Guestbook service ») et recevoir également des salutations après avoir posté son message (« Hello service »). Il s’agit d’une application Spring Boot déployée sur Kubernetes, composée d’une interface utilisateur et de 2 microservices (chacun a plusieurs instances). Une page d’erreur 500 apparaît quand il essaye d’y accéder en indiquant null et 404. Cette fois, ce n’était pas un effet démo où la loi de Murphy en action et cela faisait bien partie de la présentation. Il a donc continué pour débugger l’application et résoudre le problème étape par étape en utilisant différents outils fournis par Google Cloud Platform.




En consultant les logs, il a pu identifier 2 instances du service gérant l’interface utilisateur qui avaient beaucoup d’erreurs par rapport aux autres instances. Kill/restart n’est pas la solution, car elle n’empêchera pas l’erreur de se reproduire. Il a donc décidé de sortir l’une des instances défectueuses du load balancer avec une commande kubectl (une interface en ligne de commande pour exécuter des commandes sur les clusters Kubernetes) en changeant le flag serving à false. L’idée est d’isoler l’instance du trafic de production et d’être libre de la déboguer. Notez qu’en désactivant cette instance, Kubernetes crée automatiquement une autre instance du service. Ensuite, il a configuré la redirection de port sur ce pod pour pouvoir interroger cette instance spécifique depuis son environnement local. Avec Stackdriver Trace, il était capable de tracer les appels et identifier la pile d’appel. Filtrant sur les erreurs 5xx et cette instance particulière, il a alors réalisé qu’un problème survenait au niveau du service « Hello service » et plus précisément quand l’endpoint « hello » est appelé, dans certains cas, une réponse 404 est retournée. Cela semblait être le cas lorsque le nom était manquant. Pour confirmer le comportement, il a ajouté quelques lignes de logs à la volée pour afficher le nom et, en effet, celui-ci était vide et l’application affichait l’erreur. En fait, une validation manquait sur le formulaire pour rendre le nom obligatoire.




Pour récapituler, nous pouvons mentionner les 4 principaux outils de débogage fournis avec GCP:

• Interroger et consulter les logs avec Stackdriver Logging (un outil similaire à Splunk)
• Tracer la pile d’appels avec Stackdriver Trace (un outil similaire à Zipkin)
• Ajouter des logs et des breakpoints à la volée sur une instance en prod avec Stackdriver Debug
• Accéder à l’historique des erreurs http depuis les logs ainsi que diverses métriques sur les services (temps de réponse…) avec Stackdriver Monitoring




La présentation fut intéressante, mais je peux juste regretter que le titre ne mentionnait pas le fait que la démo se basait principalement les outils commerciaux de Google Cloud, je pensais qu’elle serait plus centrée sur Kubernetes. Mais cela vaut quand même la peine de savoir ce que Google fournit. Et je dois admettre qu’ajouter des breakpoints et des logs dans le code d’une instance en prod à partir d’une interface web était assez impressionnant.




Fully serverless, a case study, avec Stephen Colebourne & Chris Kent

A OpenGamma, ils ont créé une nouvelle plate-forme financière basée sur AWS et décidé d’utiliser les technologies serverless (AWS Lambda).




Qu’est-ce que l’informatique sans serveur et Lambda?

Serverless est essentiellement lorsque l’infrastructure est invisible, vous ne savez pas où le code s’exécute et vous n’avez pas le contrôle.
Une AWS Lambda est fondamentalement constituée de 2 classes: une interface simple et son implémentation, où vous implémentez la méthode handleRequest. La Lambda est détruite une fois la méthode terminée.
Vous packagez le code dans un JAR (qui inclut toutes les dépendances nécessaires) et l’uploadez dans AWS pour qu’elle soit exécutée.




Comment déclencher une Lambda?

• Vous pouvez utiliser CloudWatch (similaire à un CRON).
• Vous pouvez utiliser un événement. Il peut s’agir d’un appel d’API REST, un fichier est enregistré dans AWS S3, un message arrive dans une queue, une ligne est ajoutée à une table ou un appel directement à partir d’une autre Lambda…




Limites, des limites partout!

Lorsque vous travaillez avec des Lambdas, vous devez être très prudent avec les limites AWS Lambda.

• Un délai d’exécution par défaut: 5 minutes
• Une quantité maximale de mémoire que vous pouvez utiliser: 3Go
• Une taille maximale pour un fichier JAR que vous pouvez uploader: 50Mo
• Un maximum d’espace disque que vous pouvez utiliser: 512Mo




Pour certains traitements lourds spécifiques, ils ont atteint la plupart de ces limites et ils ont dû trouver des solutions de contournement ou même des alternatives:

• L’utilisation d’AWS Batch au lieu de Lambda. L’inconvénient est qu’ils ne peuvent pas déclencher le traitement instantanément, par exemple lorsque vous soumettez un job Batch, il sera traité à un moment donné, mais vous ne pouvez pas supposer que cela sera instantané (cela peut prendre 2 ou même 10 minutes avant l’exécution). Cette limitation n’était pas un problème pour eux, évidemment cela ne marchera pas pour tout le monde.
• Divisez et prétraitez autant que possible les données en entrée avant de les transmettre à la Lambda. La Lambda ne devrait pas avoir à faire de prétraitement lourd en CPU ou avec une empreinte mémoire forte. De plus, comme les données sont chargées à la demande, cela introduit un peu de latence, mais c’était acceptable pour eux.
• Au lieu de passer une copie des données entre les Lambdas qui peuvent être coûteuses en mémoire/réseau, ils sauvegardent les données dans S3 et ensuite utilisent une référence (métadonnées).

La plateforme est actuellement constituée de 4 services, formés d’un total de 23 Lambdas et 2 Batch.




Retour d’expérience

La scalabilité automatique (automatic scaling) avec Lambda est le principal avantage. C’est totalement transparent et géré par AWS. Quand il y a beaucoup de requêtes, des Lambdas sont créées et partagent la charge. Lorsque toutes les demandes ont été traitées, les Lambdas sont détruites (pour atteindre 0 lorsqu’elles sont inactives). Cependant, ce n’est pas une solution miracle, car vous pouvez avoir un goulot d’étranglement à un autre niveau de votre système (par exemple, votre base de données est trop lente) et vous ne pourrez pas exploiter pleinement l’élasticité des Lambdas.

Un inconvénient des Lambdas est le démarrage à froid (cold start), il leur faut du temps pour démarrer. En fait, une Lambda n’est pas vraiment détruite une fois le traitement terminé, car elle peut être réutilisée pour la prochaine requête, AWS dispose d’un mécanisme pour maintenir en vie, ce qui signifie que les Lambdas restent disponibles généralement quelques minutes après leur exécution. Ils ont donc décidé d’appeler la Lambda avec un volume de données négligeable toutes les minutes pour la garder disponible et « tiède ». Évidemment, c’est un hack et ce n’est pas garanti que cela marchera encore dans le futur, mais Chris nous a dit que c’était une pratique assez commune parmi les développeurs…

Pour le débogage, les choses ne sont pas faciles, vous devez déployer sur AWS pour tester votre code. De nos jours, il existe des bibliothèques et des frameworks pour vous aider.

Les logs des Lambdas sont indexées dans AWS CloudWatch Logs. D’après eux, l’expérience utilisateur de cet outil n’est pas génial, ils ont donc créé une Lambda pour copier les logs d’AWS vers un outil d’agrégation dédié: Sumo Logic, un outil de type Splunk. Pour les alertes et le monitoring, ils utilisent CloudWatch Metrics et ils ont également configuré des alertes dans Sumo Logic pour faciliter la recherche dans les logs.

Construire une architecture à partir de petites pièces simples pousse la complexité ailleurs au niveau de l’infrastructure (pendant la construction) et aussi vers les interactions entre les composants (pendant l’exécution). Le monitoring et la mise en place d’alertes sont également plus complexes à mesure que le système devient encore plus fragmenté. Il est important de garder à l’esprit qu’une Lambda a des limites très restrictives, aller au-dessus de l’une d’entre elles et votre Lambda sera tuée. Notez que les limites évoluent et sont levées au fil du temps. La technologie est encore jeune et l’outillage et les frameworks disponibles assez limités, mais vu le niveau d’excitation autour des Lambdas, il est clair que cela va s’améliorer.

D’un autre côté, vous n’avez pas besoin de penser aux serveurs et à leur maintenance. L’auto scaling est transparent et gère automatiquement la charge. Lambda vous permet de réaliser d’importantes économies, par exemple, si votre système est spécifique à un pays, vous savez que le trafic sera très limité pendant la nuit. Enfin, le modèle de programmation est très simple, juste un fichier JAR juste une fonction.




Ce deuxième jour à Devoxx était génial, surtout les talks du matin sur le Machine Learning. Je suis sorti de ces 2 jours avec beaucoup d’idées innovantes. Merci Devoxx UK et peut-être à l’année prochaine!



Keynote de clôture - Merci Devoxx UK!

Articles similaires

Attaques de robots: vous n’êtes pas seul… Devoxx UK 2018 – Jour 1 Panorama simplifié des métiers de l’informatique Architecture Microservices – Les bonnes pratiques