Cet article fait partie d'une série visant à accompagner les entreprises dans leur migration d'un SI Big Data existant vers les offres cloud d'AWS.

Le but de cette série n'est pas de faire un comparatif détaillé sur l'intérêt d'une migration vers le Cloud ! Nous supposons que le choix est déjà fait et qu'il faut donc choisir parmi les solutions natives proposées par AWS la plus adaptée.

Les solutions cibles favorisées sont les solutions natives équivalentes lorsqu'elles existent (Kinesis, DynamoDB, ...) et non les offres managées (solutions externes hébergées).

Nous avons donc privilégié le replatforming et non le lift and shift (Cf. stratégies de migration vers le cloud, les "6 R").

En effet, les solutions natives offertes par AWS présentent les avantages suivants :

1. Administration simplifiée et entièrement prise en charge par AWS
2. Facturation plus avantageuse
3. Solution parfaitement intégrée dans l'écosystème AWS

Chacun des articles de la série va s'intéresser à une solution source très répandue dans le monde du Big Data et permettre :

• De comprendre les différences fondamentales entre les solutions,
• D'identifier les cas d'usage propices à la migration vers les solutions natives,
• D'identifier les cas d'usage propices à la migration vers une solution managée.

Introduction

On va retrouver les solutions Kafka et Kinesis dans des architectures orientées événements et temps réel afin de stocker des messages correspondants à des événements au sein du SI :

• nouvelles données,
• modification de données existantes,
• événements métiers nécessitant le recalcul de données,
• ...

Ce sont des solutions d'ingestion de données avec les notions communes suivantes :

• durabilité des messages,
• scalabilité grâce au partitionnement et à la notion de réplication,
• résilience des données grâce à la notion de réplication,
• notion de consommateur et de producteur.

Le cœur des deux systèmes est une log immutable de messages ordonnés.

Les nouveaux messages sont ajoutés à la fin et référencés par un identifiant unique (sa position dans la log).

Genèse des projets

Kafka

L'histoire d'Apache Kafka commence en 2010 chez LinkedIn pour des besoins internes, en voici les dates clés :

• 2011 : le projet devient open source
• 2012 : Le projet intègre l'incubateur Apache
• 2014 : Les créateurs du projet fondent la société Confluent
• 2018 : AWS annonce une offre Kafka entièrement managée lors du salon Re:Invent (https://aws.amazon.com/fr/msk/)

Kinesis

• 2013 : Amazon Web Services annonce le lancement de Kinesis lors de re:Invent:2013, fortement inspiré par Kafka. Le service est réellement disponible en décembre 2013.
• 2015 : Kinesis Data Firehose
• 2016 : Kinesis Data Analytics

Architecture et écosystème

Bien que d'architecture et de concepts assez similaire, il est important de connaître l'équivalence des notions entre Kafka et Kinesis.

Comparaison des notions

Écosystème Kafka

Zookeeper :
 • stocke la composition du cluster
 • gère indirectement les signaux de vie des brokers
 • liste les consommateurs

Kafka Stream :
 • Framework de streaming

Kafka Connect :
 • Framework gérant l'alimentation et l'export des messages

Schema Registry :
 • Permet le contrôle et le versioning des schémas des messages

Confluent Control Center :
 • Monitoring et administration d'un cluster Kafka (Confluent)

Kafka Rest proxy :
 • Expose les API Kafka en REST

Écosystème Kinesis

Amazon Kinesis Streams
 • Stockage et streaming des messages

Amazon Kinesis Firehose
 • Transfert des message vers/depuis S3/Redshift/Splunk/Amazon Elasticsearch Service

Amazon Kinesis Analytics
 • Requêtage SQL des données contenues dans les messages

Cloudwatch
 • Monitoring

DynamoDB
 • Stockage de la position des consommateurs (sequence)

Kinesis Agent
 • Alimentation Kinesis Stream depuis des fichiers (https://github.com/awslabs/amazon-kinesis-agent)

Kinesis Firehose permet d'alimenter la solution Kinesis. Il peut aussi transformer les données et alimenter d'autres systèmes tels que S3, Redshift ou ElasticSearch.

La création d'un flux peut se faire simplement depuis la console AWS, la scalabilité est automatisée ainsi que certaines optimisations (compressions, regroupement par lots).

Kinesis Analytics permet d'interroger les données stockées dans Kinesis avec des ordres SQL. Toute la partie technique (scalabilité, déploiement, …) est automatiquement gérée par le framework.

Différences entre les solutions

Nous allons détailler les critères différenciant et pertinant dans le choix d'une solution cible.

Architecturales

Kafka ne propose pas nativement de solution pour gérer le multi-datacenter, un cluster déployé sur deux datacenters sera vu comme un seul cluster et les latences entre les deux peuvent poser problème pour le bon fonctionnement.

La solution est donc de déployer un cluster dans chacun des datacenters et de les synchroniser avec une des solutions suivantes :

• MirrorMaker (open source)
• Confluent Replicator (étend MirrorMaker mais solution propriétaire)

Kinesis est par nature multi-datacenter puisque les services et les messages sont distribués automatiquement dans 3 datacenters (Availability Zone).

Il n'est par contre pas possible de déployer un même cluster dans plusieurs régions.

Performances et accès concurrents

Avec Kafka, il n'y a pas de limite sur le nombre d'accès à une partition mais en pratique les constats suivants ont été faits :

1. On augmente les performances en augmentant le nombre de partitions d'un Topic.
2. En augmentant le nombre de partitions on augmente la taille mémoire utilisée par les clients (buffer).

Si en théorie, il n'y a pas de limite globale avec Kinesis, la facturation est proportionnelle au nombre de shards utilisés. Il est donc important de connaître les seuils imposés sur les shards.

Kinesis impose des limitations sur les capacités des shards :

1. Écriture : 1000 insertions par seconde ou 1Mo/s
2. Lecture : 5 transactions par seconde ou 2 Mo/s

Si les besoins sont supérieurs alors il faut augmenter le nombre de shards (et donc la facturation).

Une autre possibilité consiste à utiliser la diffusion améliorée qui autorise 2 Mo/s par partition (utilisé en général pour les cas d'utilisation à plusieurs consommateurs). Là encore c'est une option payante.

Par défaut, chaque compte peut mettre en service jusqu'à 10 partitions par région. Au-delà il faut remplir un formulaire.

Latences

Du fait des différences d'architecture, les latences ne sont pas comparables entre une offre Kafka hébergée et Kinesis :

• Pas de colocalisation entre les données et les traitements
• Les limitations liées à la facturation présentées ci-dessus qui vont favoriser un faible nombre de shards
• Le déploiement systématique sur 3 datacenters

Kafka :

• Ecriture 10 ms
• Lecture 50 ms

Kinesis :

• Ecriture 35 ms
• Lecture 150 ms (mais plutôt une seconde avec les paramètres par défaut)

Il est à noter que Kinesis étant écrit en C++, il n'est pas soumis de la même façon que Kafka aux latences du Garbage Collector. Les latences sont donc plus stables.

Delivery semantics

Kafka peut proposer pour les producteurs une sémantique de type "Exactly once" avec une notion de transaction.

Kinesis propose une sémantique de type "at least once". Cela veut dire qu'il ne peut garantir qu'un message ne sera délivré qu'une seule fois.

Rétention

La rétention dans Kafka et Kinesis va déterminer la durée de conservation des messages dans leur système de stockage respectif.

Elle va définir :

1. le temps imparti pour le traitement des messages
2. le temps imparti pour la remise en état du système en cas de défaillance
3. le temps imparti pour l'analyse d'éventuels problèmes (perte de message par exemple)

Valeurs par défaut :

• 24 heures pour Kinesis
• 168 heures (7 jours) pour Kafka

Ce délai de rétention est configurable dans les deux cas mais ne peut excéder 7 jours pour Kinesis.

Une solution habituelle afin d'augmenter ce délai, est de stocker les messages dans S3.

Il existe un projet nommé Kinesis VCR qui permet de rejouer les messages stockés dans S3 en utilisant l'API Kinesis.

NB : l'augmentation de la période de rétention au-delà d'un jour, est facturée pour Kinesis

Compaction log

La fonctionnalité de compaction d'une Log permet de conserver indéfiniment la dernière valeur du message pour chaque identifiant.

Cela permet d'être en mesure de reconstituer les données en cas de crash.

Cette fonctionnalité est aussi utilisée pour implémenter le GDPR dans Kafka (on insère une valeur nulle qui écrase l'ancienne valeur et permet donc de supprimer une donnée)

Taille maximale d'un message

Dans les deux systèmes les tailles des messages sont limitées :

• 1 Mo dans Kinesis
• 10 Mo dans Kafka (modifiable)

Toutefois les deux systèmes n'ont pas été conçus pour le traitement de messages de taille importante et privilégient les messages de 100 Ko maximum.

C'est d'autant plus vrai avec Kinesis où la taille des messages influe sur le débit et donc sur la facturation.

Tolérance à la panne (acquittement des messages)

Afin d'assurer la résilience des messages, les producteurs doivent être assurés du bon déroulement de l'insertion.

Kafka : un paramètre nommé ack permet de définir le nombre de brokers devant acquitter la bonne réception des messages. Ce paramètre est configurable et une bonne pratique est de le définir tel qu'une majorité de brokers soient impliqués.

Kinesis : lors de l'insertion d'un message, il est répliqué de manière synchrone dans les 3 zones de disponibilité d'une région.

Contrairement à Kafka on ne peut donc pas privilégier les performances au détriment de la disponibilité.

Compression

La compression des messages permet d'améliorer les performances et d'éviter la saturation du réseau.

Dans les deux systèmes, il existe un système natif de buffers afin d'optimiser les échanges réseau.

L'envoi vers le serveur ne se fait que lorsque le buffer à atteint sa capacité maximale ou qu'un temps d'attente est dépassé.

Kafka : Si un Topic peut être défini comme compressé, il est conseillé de le faire coté client, trois options sont alors possibles : None, GZip et Snappy.

Kinesis : Il n'existe pas d'équivalent et une compression doit être gérée de manière applicative.

Toutefois une optimisation permet d'en réduire le besoin.

Les enregistrements sont groupés et sérialisés en utilisant le format Protocol Buffers (Amazon Kinesis Producer Library).

Registre de schéma

Le registre de Schema (Schema Registry) est une solution open source de Confluent et permet de définir un schéma pour les messages des Topics et ainsi contrôler le formalisme des données et leur évolution.

Il permet de s'assurer de la compatibilité des schémas des producteurs et des consommateurs Kafka avec une vérification automatisée. Il fournit au consommateur des sérialiseurs compatibles avec les messages consommés.

Il n'existe pas d'offre similaire dans Kinesis mais il est toutefois possible de valider de manière applicative le format des messages publiés ou récupérés depuis la plateforme.

Maintenabilité

C'est bien sûr le point fort de l'offre d'AWS (et de toute offre de type SAAS), la maintenance du cluster est portée par AWS.

Cela permet de libérer les équipes de cette charge et donc de diminuer les coûts de maintenance.

À l'opposé on ne maîtrise pas les versions utilisées et les migrations sont donc plus fréquentes.

Header de messages

Cette fonctionnalité existe depuis la version 0.11 de Kafka et n'est pas présente dans Kinesis.

Elle permet d'ajouter des informations liées à un message sans en polluer le contenu.

Le plus souvent il s'agira d'informations techniques sur la provenance des messages ou leur format.

Monitoring

Kafka, comme beaucoup de programmes écrits en Java, expose de nombreux MBeans et permet d'être assez précis sur la santé d'un cluster et sur ses performances.

Les métriques exposées par Kinesis sont plus simples mais permettent tout de même de suivre l'état de santé du cluster et ses performances.

En termes d'outils de supervision et d'administration, les deux solutions principales sont les suivantes :

• Cloudwatch pour Kinesis.
• Confluent Control Center pour Kafka (outil payant).

Cloudwatch n'est bien sûr pas limité à Kinesis et offre donc l'avantage d'une interface de monitoring unifiée au détriment du nombre de métriques disponibles.

Outre la latence, le débit et le pourcentage OK (lecture et écriture) on trouve le retard entre le consommateur et le stream (âge de l'itérateur) et deux métriques dédiées à la facturation (dépassement limite en lecture/écriture).

Les métriques peuvent être customisées et pour accéder à des métriques plus fines (au niveau shard), il faut payer un supplément.

Gestion des exceptions

Il existe deux façons d'interagir avec un service Kinesis :

• Au travers des librairies clientes, Kinesis Producer Library et Kinesis Client Library disponibles en Java et C++.
• En utilisant le SDK AWS et les API Kinesis.

L'utilisation des API Kinesis offre un meilleur contrôle des opérations et de meilleures performances au prix d'une complexité d'utilisation plus grande.

Par exemple seules les librairies KPL et KCL proposent un mécanisme de retry automatique.

Même en utilisant KPL et KCL, la gestion des codes d'erreurs est plus fine avec Kafka au travers du driver client.

En effet Kinesis est un service web et retourne donc un code HTTP qui n'offre pas la finesse du client Kafka.

Scalabilité (Partitionnement automatique)

Kinesis permet de mieux gérer la répartition de charge en proposant de :

• Scinder une partition (shard) afin de répartir la charge
• Réunir deux shards afin de limiter les coûts

Récemment (Re:Invent 2018) a d'ailleurs annoncé un nouveau service entièrement automatisé de dimensionnement du nombre de shards d'un cluster : AWS Application Auto Scaling.

Avec Kafka la modification du partitionnement se fait essentiellement avec l'ajout/suppression de brokers puis avec la création d'une nouvelle partition des données qui est une opération manuelle à moins de disposer de Confluent Control Center.

Atomicité inter-partitions

Dans Kafka cette fonctionnalité permet de grouper l'insertion de messages destinés à des partitions différentes et donc de garantir qu'un ensemble de messages liés seront tous correctement insérés.

Dans Kinesis, cette fonctionnalité n'est pas présente, l'insertion en batch étant limitée à un shard.

Gestion des offset

On appelle Offset dans Kafka et Séquence dans Kinesis la position unique d'un message dans les logs et par conséquent la position courante d'un consommateur dans sa lecture des messages d'un Topic/Stream.

Sauvegarder la position courante d'un consommateur permet de garantir qu'un message ne sera traité qu'une seule fois même en cas de reprise.

Kafka permet une gestion automatique ce cette sauvegarde (un thread asynchrone la sauvegarde automatiquement au bout de x secondes après la récupération d'un message) mais aussi une gestion manuelle.

Kinesis ne propose qu'une gestion manuelle appelée checkpoint.

Enfin, avec Kafka les Offset sont généralement stockés dans un topic spécial alors que Kinesis utilise DynamoDB pour le stockage des Séquences.

Horodatage automatique des messages

Les messages sont automatiquement horodatés par le serveur Kafka ou Kinesis.

Cette fonctionnalité est utile dans les cas suivants :

• permet de faire des filtres sur l'âge des messages,
• permet de faire des regroupements sur l'âge des messages, tout en évitant l'ajout d'un champ dans le corps du message.

La principale différence entre Kafka et Kinesis est l'impossibilité de définir (et donc surcharger) ce timestamp côté client lorsque l'on utilise le service Kinesis.

Tests unitaires et d'intégration

Pour Kafka il existe des frameworks qui vont faciliter les tests unitaires et d'intégration en simulant le comportement d'un cluster sans avoir à en déployer.

Il n'existe pas d'équivalent pour Kinesis (que seul AWS pourrait fournir).

Toutefois il existe des possibilités de simuler les services AWS avec le projet localstack : https://github.com/localstack/localstack

Streaming

De nombreux frameworks de Streaming sont compatibles avec Kafka :

• Kafka Streams
• Spark
• Flink
• Storm
• …

Avec Kinesis :

• Amazon Kinesis Firehose
• Amazon Kinesis Analytics
• Apache Spark, Flink, Storm, …

Langage d'interrogation SQL

KSQL est un projet Confluent qui permet d'instancier un serveur REST ou une API permettant d'utiliser le langage SQL afin de requêter les messages des Topics (les ordres SQL sont traduits en programme Kafka Stream).

KSQL est assez complet mais reste limité par rapport aux possibilités offertes par Kafka Stream.

Kinesis Analytics poursuit le même but avec les différences suivantes :

• Autre source qu'un topic (Stream) Kinesis : par ex S3
• Les ordres SQL sont traduits en fonctions Lambda ou en programme Java (Flink)
• Auto-découverte du schéma
• Template SQL avec les principaux cas d'utilisations
• Destination (Kinesis Streams, Redshift, S3, …)

Plus d'informations Amazon Kinesis Analytics

Configuration des solutions

Kinesis, en tant que solution managée est beaucoup plus simple à configurer qu'un cluster Kafka. En conséquence il est beaucoup plus difficile de l'adapter au cas d'usage.

C'est donc côté client que la majorité des ajustements peuvent intervenir (27 paramètres tout de même pour la Kinesis Producer Library).

Sécurité

Kinesis permet les options suivantes :

• Mise en place de stratégies AWS IAM pour la gestion des autorisations
• SSL pour le chiffrement des flux
• Chiffrement/déchiffrement côté serveur avec AWS KMS des données stockées (chiffrement de bout en bout)
• Chiffrement/déchiffrement côté client.
• Audit avec AWS CloudTrail

Kafka permet les options suivantes :

• Authentification des connexions internes et externes : SSL ou SASL (Kerberos)
• Authentification entre brokers et ZooKeeper
• Client : Gestion des rôles (écriture et lecture)
• Chiffrement sur disque : pas géré par Kafka mais par l'OS.

Certains types de données (médicale, bancaire) exigent des garanties supplémentaires et peuvent être un frein à l'adoption du cloud grand public.

Certifications AWS Kinesis

1. Conformité stockage et traitement de données médicales (loi HIPAA et programme FedRAMP)
2. Certification HDS (Hébergeur de Données de Santé)
3. Données bancaires (PCI DSS)

Automatisation du déploiement

Il n'y a pas de solution préférentielle pour Kafka, les solutions suivantes sont possibles :

1. Kubernetes (à venir Cf. https://www.confluent.io/confluent-operator/)
2. Chef https://www.chef.io/chef/
3. Ansible https://github.com/confluentinc/cp-ansible

Pour Kinesis la solution privilégiée est bien évidemment AWS CloudFormation.

AWS CloudFormation est le framework de déploiement des solutions AWS.

Synthèse

Critères de choix solutions cibles

Il est important de connaître les cas d'usages et les besoins qui vont amener à choisir l'offre Kinesis plutôt que l'offre Kafka managé.

Kinesis

Pour un nouveau projet ou pour une migration on va privilégier Kinesis par rapport à Kafka dans les cas suivants :

1. Réduire les coûts de maintenance
2. Réduire les coûts d'utilisation (l'avantage dépendra du dimensionnement)
3. Améliorer la scalabilité en réduisant les délais de mise à disposition d'un nouveau serveur.
4. Charge très variable au cours du temps

Kafka

Pour un nouveau projet ou pour une migration on va privilégier Kafka par rapport à Kinesis dans les cas suivants :

• Utilisation de fonctionnalités non supportée par Kinesis :
  • Utilisation des headers,
  • Latence et performances très importante,
  • Transaction (only once delivery).
• Coût (cluster important) :
  • Kinesis n'est pas obligatoirement avantageux (nombre de shards très important)
• Coût (nombre important de clients) :
  • Avec Kinesis, le nombre de clients simultanés est limité (lecture et écriture).
  • Coût (volumétrie importante) :
    • Avec Kinesis, le débit d'écriture est limité par shard.
• Coût (délai de rétention) :
  • Au-delà d'un jour de rétention, Kinesis facture des coûts supplémentaires.

Migration

Migration des données

Il faut tout d'abord décider de la stratégie à adopter :

• Dual Run : Kafka et Kinesis vont être déployés en parallèle, le temps des validations
• Big Bang : Kinesis remplace Kafka à une date prédéfinie

Afin de faciliter la migration des données, il existe un connecteur capable d'exporter les données de Kafka vers Kinesis et développé par AWS : https://github.com/awslabs/kinesis-kafka-connector

C'est un jar à déployer sur la plateforme Kafka source et qui s'appuie sur kafka connect pour la récupération des messages.

Une autre solution consiste à développer du code Spark/Flink spécifique pour l'alimentation de Kinesis. Cette solution permet un meilleur contrôle (transformation des données, performances, ...)

Points d'attention :

• Rétention et donc volumétrie différente entre les deux systèmes,
• L'horodatage des messages est modifié.

Migration du code

Si les principes et la structuration du code sont identiques, la migration exige une réécriture complète du code.

Les clients Kinesis Producer Library (KPL) et Kinesis Consumer Library (KCL) sont écrits en C++ et utilisent des wrappers pour Java.

On peut aussi utiliser le SDK AWS mais qui est vu comme une offre dégradée d'utilisation de l'API Kinesis (pour les langages non encore supportés).

Migration du contrôle d'accès

Il n'y a pas de différence majeure dans les possibilités de sécurisation offertes par les deux plateformes.

La migration du contrôle d'accès sera toutefois une opération longue nécessitant un inventaire de l'existant.

Estimation du coût AWS

Le service Kinesis Data Analytics n'est pas (encore) disponible dans la région Paris, c'est pourquoi nous nous baserons sur la région "Dublin".

Kinesis Data Stream

La facturation de l'offre d'AWS va se faire selon plusieurs axes :

1. un coût récurrent
2. un coût d'utilisation

Exemple de tarification (Dublin) :

• Coûts fixes : 0,017 USD par heure et par shard
• Coûts d'insertions : 0,0165 USD pour 1 million d'ordres d'insertion (put)

Kinesis Data Firehose

Exemple de tarification (Dublin)

• Coûts d'insertions : 0,031 USD par Go par mois (500 premiers To)
• Conversions de format des données 0,019 USD par Go

Kinesis Data Analytics

Exemple de tarification (Dublin)

• Coûts fixes : 0,120 USD de l'heure (4 Go de mémoire, 1 vCPU)

Conclusion

Dans une architecture, ces deux solutions vont remplir le même rôle mais même si Kinesis est inspiré par Kafka, l'offre d'AWS présente des différences importantes en termes d'implémentation.

Certaines fonctionnalités étant totalement absentes, il convient de bien étudier les cas d'utilisations car Kafka ne pourra pas être remplacé purement et simplement par Kinesis.

Kinesis est toutefois la solution idéale pour harmoniser un SI, favoriser le Time To Market et s'adapter à une sollicitation variable ou en constante augmentation.

Aller plus loin

AWS Kinesis https://aws.amazon.com/fr/kinesis/

Disponibilité des services par régions https://aws.amazon.com/fr/about-aws/global-infrastructure/regional-product-services/

Monitoring Kinesis : https://docs.aws.amazon.com/fr_fr/streams/latest/dev/monitoring.html

Application Migration Strategies: "The 6 R's"
https://aws.amazon.com/fr/blogs/enterprise-strategy/6-strategies-for-migrating-applications-to-the-cloud/

AWS - en Route vers la Production https://blog.ippon.fr/2019/02/07/aws-et-si-on-faisait-de-la-production/

Is Public Cloud Cheaper Than Running Your Own Data Center ?
https://blogs.gartner.com/marco-meinardi/2018/11/30/public-cloud-cheaper-than-running-your-data-center/

Pour rappel, la JHipster Conf en 2018 c'était ça :

• 200 passionés réunis pendant une journée à Paris !
• Des speakers prestigieux (Julien Dubois, Deepu K Sasidharan, Joe Kutner, Matt Raible, Pierre Besson, Antonio Goncalves, William Marques, Mathieu Abou-Aichi, Pascal Grimaud, Christophe Bornet, Ray Tsang, Ludovic Champenois et Josh Long)
• Un after mémorable sur notre rooftop ;)

Le 27 juin 2019 nous serons 350 passionés de JHipster pour cette seconde édition !
Au programme :

• Un track anglais et un track français
• Un line-up de folie
• Des sponsors incroyables (Okta, Microsoft...)
• La mémorable tarte au citron meringuée au basilic ;)

Cette conférence réunira les principaux développeurs de JHipster, qui présenteront des sessions techniques sur les parties qu'ils ont eux même développées.

Veuillez noter que nous ne visons pas à gagner de l'argent de la conférence, et que les avantages seront reversés à JHipster Open Collective.

Réservez dès maintenant vos places sur : https://jhipster-conf.github.io/

Personnes concernées

Le public

Sur 50 inscrits, nous nous sommes retrouvés à environ 40 spectateurs pour cette journée. Heureusement d’ailleurs, puisque c’était exactement le nombre de chaises disponibles…!

Nous avons eu l’occasion de nous présenter brièvement, ce qui nous a permis de prendre un peu la température des profils de nos camarades de classe : la grande majorité venaient d’entreprises de services IT, telles que Sopra Steria, Xebia, Cap Gemini, ou Thales Service. Il y avait quelques profils en freelance, et un chez Orange.

On a pu distinguer deux tendances :

• Ceux qui avaient de l'expérience en ML/IA, et qui voulaient plutôt voir comment l’utiliser dans l’environnement AWS,
• Et ceux qui connaissaient de près ou de loin AWS, mais pas ou peu leurs services ML/IA.
• Personne n’avait de réelle expérience dans les deux domaines, comme on pouvait s’y attendre.
• Autre point clairement entendu : tout le monde venait d’un environnement data engineering ou data science.

Notons que sur 40 participants, nous étions 4 Ippon : Théo Castel, Vincent Heng, Saifallah Ketbi, et moi-même.

L’équipe d’animation de la journée

Au fil de la journée, nous avons eu 2 interlocuteurs :

• Carlos Escapa, AI/ML Practice Leader Monde chez AWS. Il a animé la plus grande partie de la matinée, et était clairement leader de l’équipe d’animation.
• Bogdan Vrusias, Spécialiste Architecte de Solutions ML/AI chez AWS, qui s’est occupé de l’après-midi, donc la partie pratique de la journée.

Nous avons aussi assisté à une brève présentation du projet AWS DeepRacer, animée par Olivier Bergeret, en tant que directeur du projet chez AWS Los Angeles.

Vue d’ensemble

Traduction de la description officielle

“Le AWS Machine Learning Solution Day est destiné aux membres du AWS Partner Network (APN) qui veulent mettre en place, ou qui ont déjà mis en place une practice Machine Learning, comme une partie essentielle de leur entreprise.

Cet évènement consiste en un jour complet de formation technique. Seront abordés les sujets du stack de service de Machine Learning sur AWS, comment utiliser les services en production, et une présentation de Amazon SageMaker. La seconde partie de la formation technique sera une session lab pratique dans laquelle les participants construiront un moteur de recommandation à partir de rien.

Nous sommes pressés de vous voir parmi nous pour une immersion d’un jour dans l’apprentissage du ML sur AWS avec nos experts.

Le portfolio AWS Management Tools est un groupe de briques de construction qui aident les clients à répondre à leur besoin en AWS management, compliance, sécurité, et optimisation. Nos partenaires jouent un rôle clé dans l'exploitation de ces éléments de base pour développer des solutions qui répondent aux besoins individuels de nos clients. Les partenaires représentent une relation étroite avec nos clients, c'est pourquoi nous encourageons fortement la rétroaction collaborative afin d'élaborer des feuilles de route qui répondent aux besoins de nos clients.”

Ressources

Avant de commencer cette journée, on nous a conseillé de regarder ces 3 courtes vidéos, servant d’introduction aux concepts de ML/IA survolés pendant la journée :
What is AI (10 minutes)
https://www.aws.training/learningobject/video?id=27394
What is Machine Learning (10 minutes)
https://www.aws.training/learningobject/video?id=27404
What is Deep Learning (10 minutes)
https://www.aws.training/learningobject/video?id=27405

Ces vidéos sont clairement à l’attention des plus débutants d’entre nous en terme de Machine Learning et d’Intelligence Artificielle. Elles survolent assez efficacement les bases nécessaires à la compréhension de la journée. C’est une très bonne introduction, ou, à défaut, une piqûre de rappel potentiellement utile. Pour 30 min de vidéo, la qualité est au rendez-vous.

Contenu de la présentation magistrale

Du besoin en ML/IA

Le ML est un outil très puissant. C’est aussi un objet de fascination pour bon nombre de membre de la communauté IT, voire même pour un public bien plus large. Cependant, comme vous le savez sûrement, les outils que nous utilisons ne sont légitimes qu’à la lumière du problème, du but et du résultat que l’on recherche.

Cela étant dit, il nous faut alors considérer le ML/IA comme une nouvelle manière de résoudre des problèmes, plutôt que comme nos outils habituels, mis sous stéroïdes.

Carlos Escapa a commencé sa présentation en établissant qu’Amazon utilise déjà le ML depuis maintenant 20 ans, principalement pour leur produit phare, Amazon.com. En effet, le système de recommandation de produit lié au moteur de recherche est l’exemple parfait, mais c’est bien loin d’être la seule implémentation de ML/IA sur le site : le tri des produits, l’auto-complétion, … La plateforme regorge d’applications de ML/IA.

Evidemment, de nos jours, le nombre de projets portés par Amazon utilisant ce genre de technologie a augmenté de manière exponentielle, et il serait vain de tenter de les lister. Néanmoins, nous avons eu droit à une petite présentation d’un de leurs produits les plus récents : Amazon Go. C’est un super-marché autonome, c’est à dire qu’il n’y a pas de caisse. Le client peut simplement mettre les produits qu’il veut acheter dans son sac, et une batterie de capteurs s’occupe de mettre à jour son panier, qui se verra automatiquement payé à la sortie du magasin, via leur compte Amazon.

Selon Carlos Escapa, le ML/IA permet de résoudre 4 grandes catégories de problèmes :

• Les problèmes liés à des datasets imposants,
• Les tâches cognitives répétitives,
• La personnalisation de produits et services,
• Les prédictions en temps réel.
  Il est évident que cela ne se limite pas à cela, néanmoins c’est la vision qu’il (donc AWS) désire donner de la solution ML/IA.

Pour illustrer, il nous a donné les exemples suivants :

• Royal Flora Holland, qui utilisent le ML dans leur quality-check hybride (la plupart des critères étant traités par le modèle ML, et le reste par des humains),
• Le pilotage à distance de camions Caterpillar dans les régions minières d’Australie, pour remédier à l’hostilité de l’environnement (et donc à l’impossibilité de garder du personnel sur place),
• Automatisaion de l’agriculture, via des engins agricoles connectés qui traquent chaque graine plantée pour monitorer et ajuster les conditions de leur pousse,
• Mutual Omaha, qui utilise le ML pour améliorer la satisfaction client,
  La valve connectée HAM-LET, qui adapte son comportement et son fonctionnement selon de multiples facteurs.

La bonne pratique du ML/IA selon AWS

Après avoir parlé des use-cases du ML/IA, la présentation s’est orientée vers les “Facteurs de Réussite du ML” selon AWS. Ces facteurs sont les suivants :

• Le senior management doit se sentir concerné par les problèmes de data. Il est essentiel que la donnée soit gérée efficacement, du début de sa vie jusqu’à sa fin, alors il devient nécessaire que les Data Engineers/Scientists ne soient pas les seuls à s’en soucier.
• La donnée doit être perçue comme un asset de valeur au sein de l’entreprise. On doit alors s’en occuper de manière adéquate, en termes de qualité et de sécurité.
• La donnée doit être centralisée dans un/plusieurs data lakes. L’entreprise doit savoir exactement où trouver ses données.
• La donnée doit impérativement être accessible au multiples organismes de l’entreprise. Dans le but de l’utiliser efficacement, chaque groupe métier doit pouvoir créer de nouveaux outils ou réutiliser des modèles importants grâce à ces données.
• La donnée doit être suffisamment utilisée. Les use-cases ne manquent pas, il faut simplement les identifier, afin de créer de la valeur ajoutée. Il serait malencontreux de laisser pourrir sa donnée dans un coin sans en tirer profit.

D’après l’animateur, en suivant ces quelques règles simples de manière assidue, on garanti une utilisation efficace du ML/IA pour une entreprise.

Les solutions ML/IA sur AWS

Après cette introduction au ML/IA en tant que solution, il était temps de passer à la vue d’ensemble qu’AWS offre de ses solutions dans le cloud.

Ils ont fait la distinction entre 3 catégories de services englobées dans le groupe des outils ML/IA.

Services IA

La première catégorie regroupe les “Services IA” : ce sont des modèles pré-entraînés, directement intégrés dans la AWS Management Console. Ils remplissent tous une fonctionnalité bien spécifique répondant à un type de problème, et on ne peut que très peu les ajuster (ce travail étant réservé à AWS). Ils sont très simples à prendre en main, et sont prêts à l’utilisation instantanément.

Grâce à ceux-ci, on peut aisément construire un système de recommandation (Amazon Personalize), une application d’analyse de sentiments (Amazon Comprehend), ou implémenter une fonctionnalité Text-to-Speech dans un site (Amazon Polly).

On voit rapidement les deux côtés de la balance de ces services : ils sont extrêmement simples d’utilisation au sein de l’environnement AWS, et ils sont suffisamment performants pour justifier leur utilisation, mais ils sont quasi-complètement statiques, on ne peut pas les ajuster nous-même pour mieux répondre à notre problématique, puisque l’on a pas la main directement sur le modèle.

Services ML

C’est là que la catégorie des “Services ML” entre en jeu. Elle n’est finalement, pour l’instant, que constituée de Amazon SageMaker, leur “produit ML phare” pour citer Bogdan Vrusias.

Le but de SageMaker est de fournir un environnement de développement d’application de ML du début jusqu’à la fin du process (nous allons voir ce que ça encapsule un peu plus loin). Il faut comprendre néanmoins que SageMaker n’est pas seulement un notebook, même si à première vue, il propose en effet d’utiliser Jupyter Notebook ou JupyterLab.

SageMaker permet donc de :

• Sélectionner un algorithme : dans une liste déjà disponible et codée,
  dans sa propre collection, ou même en écrire un from-scratch,
• Optimiser son modèle pour son use-case,
• Mettre en place un environnement d’entraînement avec des machines puissantes et optimisées (en CPU et GPU),
• Entraîner le modèle,
• Ajuster le modèle selon ses résultats,
• Déployer le modèle en production dans un système distribué et optimisé pour du ML,
• Ajuster le scaling de l’environnement de production selon le workload.

Il est intéressant de noter qu’une grande quantité de modèles et d’algorithmes sont aussi disponibles gratuitement ou moyennant paiement sur le AWS Marketplace. Cela peut être une idée efficace de récupérer un modèle/algorithme proche de notre use-case et de l’adapter, sachant par exemple que les modèles des services IA que l’on a vu précédemment sont disponibles sur cette plateforme.

SageMaker est aussi lié à la troisième catégorie de solutions offerte par AWS.

Frameworks de ML

Cette troisième brique, c’est l’intégration dans SageMaker d’une tripotée de frameworks classiques de ML/IA, avec une promesse de la part de l’équipe AWS : AWS est “framework agnostic”. Globalement, ils promettent de mettre à disposition un maximum de framework sans en privilégier plus certains que d’autres, afin d’avoir un environnement de développement optimal.

Ils ont cité quelques noms, en précisant que les frameworks concernés étaient d’ores et déjà disponibles sur les Amazon Machine Images (AMIs) orientées ML.

Le but de la démarche est de créer ce qu’ils ont appelé un “Neo Open Source Model Compiler”. C’est assez clair : ils veulent que l’on puisse entraîner notre modèle sur n’importe quel framework, et assurer que l’on puisse le faire tourner sur n’importe quelle puce.

De plus, ils ont vanté les mérites de leur optimisation de l'exécution de tous ces frameworks, citant comme exemple Tensorflow, pour lequel ils assurent avoir augmenté l’efficacité du GPU de 40% en général à 90% sur leurs machines, ce qui est une bonne nouvelle pour le porte monnaie de ceux qui veulent entraîner et ajuster leurs modèles.

Programme AWS ML Navigate : “Vers la spécialisation en ML sur AWS pour les partenaires APN”

Bogdan Vrusias nous a alors brièvement présenté Navigate. Pour les citer : “Le programme AWS Machine Learning Navigate permet aux partenaires APN de se construire une expertise autour du Machine Learning sur AWS. Que vous soyez Data Scientist, chercheur en Machine Learning, ou développeur, AWS offre des services et des outils de ML taillés pour vos besoins et votre niveau d’expertise.”

C’est une solution de e-learning pour les entreprises partenaires, afin de les aider à former une practice ML en 5 phases :

1. AWS Training:
   Bonnes pratiques et entraînement technique en “Well Architected” : vise à entraîner (au moins) 2 employés techniques au Well-Architected Framework. Cela inclut des modules de sécurité, fiabilité, performance, et optimisation du coût.
   “AWS ML E-Learning” : 5 employés orientés business doivent suivre le module d’entraînement (bénéfices business du ML, identifier les opportunités ML, savoir fournir une vue d’ensemble des solutions ML sur AWS, ...), et 5 orientés technique doivent suivre le module technique (articuler le solutions ML sur AWS, AWS pour la Computer Vision, AWS pour le Natural Language Processing, ...).
2. “Approfondissez vos connaissances” :
   Accédez aux ressources avancées préparées par des experts AWS,
   Prenez connaissances des certifications utiles,
   Apprenez de revues des bonnes pratiques, ...
3. Deep-dive dans le Well-Architected Framework: montrez vos connaissances et passez votre certifications sur le Well-Architected Framework.
4. Solution ou Practice Review:
   Profitez du coaching d’architectes de solution AWS,
   Participez à des activités de mise sur le marché,
   Débriefez sur vos projets et sur les études de cas de clients.
5. Faire la différence sur AWS:
   Développez un microsite,
   Postulez au AWS Solution Provider Program,
   Augmentez le nombre de collaborateurs certifiés AWS, …

Retour sur la présentation pratique

Dans ce lab pratique, nous avons été amenés à récupérer un modèle, l'entraîner, l’ajuster, et le déployer pour un système de recommandation.

Le lab et les instructions à suivre sont disponibles à cette adresse :
https://github.com/skrinak/recommendationEngine

N’hésitez pas à aller le voir, même rapidement, pour mieux comprendre ce que nous avons été amenés à faire.

Précisions à propos de AWS SageMaker

“SageMaker n’est pas un notebook” est une phrase que l’on a pu entendre plusieurs fois au fil de la journée, et, aussi clickbait que ça puisse paraître, c’est vrai. Ce n’est pas seulement un notebook, c’est bel et bien un outil de developpement end-to-end pour le ML.

Il donne aussi accès à un nombre considérable de notebook tutoriels donnant des exemples de use-cases ou de fonctionnalités disponibles pour l’utilisateur. On peut les importer dans un nouveau notebook pour se les approprier et le modifier, ou simplement le consulter pour apprendre ce qui s’y déroule.

Petite note : dans les notebooks SageMaker, on a la possibilité d’activer l’Elastic Inference : on paye pour une instance additionnelle de calcul, uniquement lorsqu'on en a besoin. D’un point de vue pricing, c’est quand même très pratique de ne pas avoir à payer une machine de guerre quand on écrit du MarkDown après avoir fait son modèle.

Critique

D’une manière générale, le lab était de très bonne qualité. La présentation était très propre, très claire, et on comprenait facilement où on allait et comment. On s’est vu administrer une petite dose rappel sur les aspects fonctionnels du ML sur AWS avant de plonger dans plus de détails, et ce n’était pas de refus.

Les animateurs étaient très pédagogues, et étaient très ouverts aux questions. On sentait qu’ils n’étaient pas là pour un atelier couture : les deux présentateurs savaient parfaitement de quoi ils parlaient, et en tant que spectateur, c’est un très bon point.

Côté ressources, les slides faisaient une très bonne revue de la partie pratique, et étaient agrémentés de moult détails, précisions, et exemples concernant les notions que l’on explorait. Le contenu de la partie hands-on est très bien fourni, très précis, et peut même se suivre en autonomie (ce qui est une très bonne nouvelle pour tout ceux qui auraient voulu y participer).

La journée étant gratuite, je ne vais pas cracher dans la soupe. On aurait simplement préféré une petite présentation des intervenants, afin d’avoir un poil plus idée des personnes à qui nous avions à faire.

On reste un peu sur notre faim : on en redemanderait bien, ce qui est une bonne chose en soi. La journée souffre, eh bien, du fait qu'elle ne se fasse que sur une seule journée. Ca passe vite, on est un peu pressé par le temps, mais ce ne sont que des conséquences du temps alloué à cette expérience.

Conclusion

Finalement, c’était une bonne expérience pour débutants en ML/IA dans le cloud. L’équipe de présentation était très bonne, et avaient clairement une crédibilité qui attire le respect et l’attention dans le domaine, en leur qualité de Global AI/ML Practice Leader, et de AI/ML Specialist.

Si cette journée revient un jour, on ne saurait que la recommander à quiconque voudrait s’informer sur le sujet du ML/IA dans le cloud !

Pourquoi Prometheus ?

Prometheus est un logiciel de supervision open-source créé par SoundCloud. En 2013, SoundCloud a décidé d'utiliser Prometheus pour ses infrastructures de Production et a publié la version 1.0 en Juillet 2016.

Prometheus, écrit en GO, s'impose depuis comme la solution de référence pour superviser une infrastructure de type Cloud, SaaS/Openstack, OKD, K8S.

Plusieurs autres solutions de supervision sont disponibles sur le marché :

• Zabbix ;
• Nagios ;
• Centreon ;
• Sensu ;
• InfluxData.

Chaque solution offre ses avantages et ses inconvénients. Prometheus est fourni par défaut comme outil de supervision pour OKD et K8S.

Architecture de Prometheus

Comment fonctionne-t-il ?

Prometheus collecte les données en provenance des clients nommés Exporters installés sur les instances distantes. Il interroge à intervalle régulier ces agents pour récupérer les données.

Le back-end de Prometheus intègre sa propre base de données de type Time Series similaire à OpenTSDB.

Par défaut, le stockage des métriques s'effectue sur les disques locaux du serveur ce qui rend la scalabilité et la durabilité du stockage complexes et ne le rend pas résilient à la panne puisque le stockage n'est pas distribué. Pour un environnement de production, il sera donc nécessaire d'utiliser un système de fichier distribué et résilient comme du glusterFS ou un système de stockage distant. En fonction du type de stockage distant choisi, seule l'écriture ou lecture / écriture est possible.

La durée de rétention est de 15 jours lors de l'installation du serveur Prometheus. Il est possible d'augmenter la rétention en fonction de la taille de stockage disponible.

Comment récupérer les données enregistrées ?

Il embarque un puissant langage de requêtage nommé PromQL qui permet :

• Filtrage des indicateurs par labels (inclusion, exclusion, expressions rationnelles);
• Génération de vecteurs (plusieurs valeurs d'un indicateur sur une fenêtre temporelle par exemple) sur lesquels il est possible d'appliquer des fonctions et opérateurs d'agrégation (min, max, moyenne glissante, somme …).

Le résultat de chaque requête peut être visualisé sous forme de graphe, tableau ou être mis à disposition de systèmes externes via l'API HTTP.

Chaque résultat est généré sous forme d'un des 4 types suivants :

• String : Chaîne de caractères ;
• Numérique : Un nombre décimal ;
• Un vecteur instantané : un ensemble de séries temporelles contenant un seul échantillon pour chaque série, toutes partageant le même horodatage ;
• Un ensemble de vecteurs : un ensemble de séries temporelles contenant une plage de points pour chaque série.

Voici quelques exemples de requêtes :

http_requests_total
http_requests_total{job="apiserver", handler="/api/comments"}
http_requests_total{status!~"4.."}
sum(rate(http_requests_total[5m])) by (job)
topk(3, sum(rate(instance_cpu_time_ns[5m])) by (app, proc))</pre>

A quoi servent les Exporters ?

Prometheus utilise le protocole HTTP et nécessite l'instrumentation des applications en utilisant les librairies clientes disponibles pour différents langages.

Il existe différents Exporter :

• Des Third-party Exporters, permettant de récupérer des métriques de tout type. L'un des Exporters important est le System Exporter permettant de récupérer toutes les métriques systèmes ;
• Des Blackbox Exporters qui permettent de récupérer des métriques à travers différents protocoles ;
• D'autres outils comme Telegraf permettant d'exposer des données à Prometheus ;
• Créer ses propres Exporters si ceux fournis par défaut ne correspondent pas aux besoins.

Fonctionnement mode Pull / Push

Par défaut, Prometheus fonctionne en mode Pull, c'est à dire que le serveur interroge à intervalle régulier les instances clientes sur lesquelles les Exporters sont installés.

Il est possible, quand cela s'avère nécessaire de fonctionner en mode Push en utilisant le projet Prometheus Push Gateway. Le seul cas où ce module aurait un intérêt serait pour la supervision de jobs asynchrones. Ces jobs pourraient envoyer des données au Prometheus Server.

Utilisation de Prometheus derrière un ou plusieurs Firewalls

Pour superviser une infrastructure complexe qui comporte plusieurs niveaux d'isolations, le mode Pull devient problématique. Au lieu d'utiliser le mode Push qui vient à l'esprit naturellement, Prometheus fourni un proxy permettant de conserver le modèle Pull, et de superviser tous les systèmes derrières le(s) Firewall(s).

Le Proxy est décomposé en deux parties :

• Le proxy qui s'exécute sur la même zone que le serveur ;
• L'agent qui s'exécute derrière le firewall et gère les requêtes en provenance du Proxy.

L'agent peut s'exécuter :

• Comme standalone serveur ;
• Embarqué dans un autre serveur ;
• Comme simple Agent Java.

Un proxy peut gérer un ou plusieurs agents.

Alerting dans Prometheus

Prometheus peut se connecter à un module nommé Alertmanager qui est capable de transmettre les alarmes à différents types de média (Mail, Pager Duty, etc…). Le module Alertmanager possède les fonctionnalités suivantes :

• Grouper les alertes : une seule notification, regroupant toutes les alertes des N dernières secondes / minutes, est envoyée ;
• Suppression des notifications : les alertes relatives à une conséquence ne sont pas envoyées si l'alerte concernant la cause racine a déjà été envoyée ;
• Rendre muettes les alertes : ne pas envoyer la même alerte pendant une période déterminée ;
• Haute disponibilité : Alertmanager supporte la configuration en mode Cluster permettant la haute disponibilité.

L'ensemble de l'alerting est configurable par les fichiers de configuration.

Scalabilité et haute disponibilité

Scalabilité de Prometheus Server

Par défaut, une instance de Prometheus server est capable de gérer des millions de séries de données (https://www.robustperception.io/scaling-and-federating-prometheus) :

• La solution la plus simple consiste à déployer un deuxième serveur Prometheus avec du stockage local, chacun récupérant les mêmes données. Le module d'alerting s'occupe de dédupliquer les alertes ;
• La deuxième solution est la fédération : plusieurs Prometheus sont déployés, chacun s'occupant de récupérer une partie des systèmes à superviser. Une instance Master s'occupe de récupérer les données en provenance des Slaves ;
• La troisième solution, dans le cas ultime, serait d'utiliser un projet comme Thanos qui permet d'avoir une solution de haute disponibilité ainsi qu'une solution résiliente en terme de stockage.

Scalabilité de l'Alertmanager

Alertmanager peut fonctionner en cluster pour garantir la disponibilité du service. Par défaut, il est conseillé d'avoir la configuration suivante pour garantir une disponibilité du service.

Pour ce faire il faut :

• Avoir deux instances de Prometheus Server ;
• Avoir deux instances du modules Alertmanager et de les configurer en mode réseau ;

# On a machine named "am-1":
wget https://github.com/prometheus/alertmanager/releases/download/v0.15.3/alertmanager-0.15.3.linux-amd64.tar.gz
tar -xzf alertmanager-*.linux-amd64.tar.gz
cd alertmanager-*
./alertmanager --cluster.peer=am-2:9094
# On a machine named "am-2":
wget https://github.com/prometheus/alertmanager/releases/download/v0.15.3/alertmanager-0.15.3.linux-amd64.tar.gz
tar -xzf alertmanager-*.linux-amd64.tar.gz
cd alertmanager-*
./alertmanager --cluster.peer=am-1:9094

• Configurer les serveurs Prometheus pour s'interfacer à l'Alertmanager.

# On a machine named "prom-1":
alerting:
  alert_relabel_configs:
    - source_labels: [dc]
      regex: (.+)\d+
      target_label: dc
  alertmanagers:
    - static_configs:
      - targets: ['am-1:9093', 'am-2:9093']

# On a machine named "prom-2":
alerting:
 alert_relabel_configs:
 - source_labels: [dc]
   regex: (.+)\d+
   target_label: dc
 alertmanagers:
 - static_configs:
   - targets: ['am-1:9093', 'am-2:9093']</pre>

Intégration avec Grafana

Prometheus fournit par défaut une interface Web qui permet d'effectuer des requêtes pour voir les données présentes en base, mais cette interface n'est absolument pas pratique pour exploiter et superviser l'infrastructure.

Grafana est un logiciel Open Source pour la visualisation et la supervision d'une infrastructure. Ce logiciel propose une connexion native à Prometheus et propose une liste de dashboards pré-générés pour récupérer les informations en provenance de Prometheus.

Gestion des utilisateurs

La gestion des utilisateurs se fait au niveau de Grafana. Grafana peut se connecter facilement à un LDAP ou Active Directory externe. Il est donc très facile de gérer les accès à la supervision avec cette méthode.

Le LDAP est activé dans Grafana en modifiant les fichiers de configuration suivants :

Dans le fichier /etc/grafana/grafana.ini

[auth.ldap]
enabled = true
config_file = /etc/grafana/ldap.toml
allow_sign_up = true

Dans le fichier /etc/grafana/ldap.toml

# To troubleshoot and get more log info enable ldap debug logging in grafana.ini
# [log]
# filters = ldap:debug

[[servers]]
# Ldap server host (specify multiple hosts space separated)
host = "<ldap host>"
# Default port is 389 or 636 if use_ssl = true
port = 636
# Set to true if ldap server supports TLS
use_ssl = true
# Set to true if connect ldap server with STARTTLS pattern (create connection in insecure, then upgrade to secure connection with TLS)
start_tls = false
# set to true if you want to skip ssl cert validation
ssl_skip_verify = false
# set to the path to your root CA certificate or leave unset to use system defaults
# root_ca_cert = "/path/to/certificate.crt"
# Authentication against LDAP servers requiring client certificates
# client_cert = "/path/to/client.crt"
# client_key = "/path/to/client.key"

# Search user bind dn
bind_dn = "bind_dn"
# Search user bind password
# If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;"""
bind_password = '<ldap user password>'

# User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)"
search_filter = "(uid=%s)"

# An array of base dns to search through
search_base_dns = ["ou=people,dc=ldap,dc=cloud,dc=dune"]

## For Posix or LDAP setups that does not support member_of attribute you can define the below settings
## Please check grafana LDAP docs for examples
#group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))"
#group_search_base_dns = ["ou=groups,dc=grafana,dc=org"]


# Specify names of the ldap attributes your ldap uses
[servers.attributes]
name = "cn"
surname = ""
username = "uid"
member_of = "gidNumber"
email =  "Email"

# Map ldap groups to grafana org roles
[[servers.group_mappings]]
group_dn = "cn=admins,dc=grafana,dc=org"
org_role = "Admin"
# To make user an instance admin  (Grafana Admin) uncomment line below
# grafana_admin = true
# The Grafana organization database id, optional, if left out the default org (id 1) will be used
# org_id = 1

[[servers.group_mappings]]
group_dn = "cn=users,dc=grafana,dc=org"
org_role = "Editor"

[[servers.group_mappings]]
# If you want to match all (or no ldap groups) then you can use wildcard
group_dn = "*"
org_role = "Viewer"

Et la sécurité ?

Prometheus et tous ses composants ne fournissent pas d'authentification, d'identification, ni le chiffrement des données. C'est pourquoi il est vivement conseillé d'utiliser un serveur nginx comme reverse Proxy.

Toutefois, le TLS est parfaitement et nativement supporté entre la ou les instance(s) serveur(s) Prometheus et les instances à superviser.

Conclusion

Ce premier article présente Prometheus, qui est un système de supervision complet. Bien qu'il soit récent sur le marché, comparé à Nagios, Centreon ou Zabbix, il se développe rapidement avec une communauté dynamique qui ne cesse de croître.

Il correspond aux besoins modernes de supervision d'une infrastructure de type Cloud avec pour principales qualités :

• Robustesse ;
• Intégration complète dans des systèmes comme OKD, K8S, Openstack ;
• Un système d'alerting configurable.

Un second article présentera un comparatif des autres solutions de supervision du marché avec Prometheus.

Jenkinsfile pourquoi faire ?

Le jenkinsfile est le fichier présent dans le SCM de votre projet qui permet de décrire la pipeline attendu dans votre jenkins : terminé les jobs traditionnels configurés sur IHM, bonjour les pipeline jobs ! Écrits en Groovy, vous décrivez l'enchaînement et le parallélisme des instructions. Toutes les étapes CI/CD peuvent être présentes : un git pull, un mvn package, une analyse qualité du projet ...

Il existe deux façons d’écrire un Jenkinsfile : Declarative ou Scripted. Comme expliqué sur la page https://jenkins.io/doc/book/pipeline/syntax/#compare, le mode Declarative est préférable pour le débutant car il offre une série de mots-clés prédéfinis et est idéal pour des pipelines simples. Le mode Scripted est bien plus puissant et possède beaucoup moins de limites : vous codez directement le pipeline en Groovy.

La liberté offerte par le mode Scripted crée un risque de glisser quelques maladresses pouvant nuire au projet et même mettre à mal votre instance Jenkins : éléments de configuration mal initialisés, des instructions au mauvais endroit qui bloquent un nœud inutilement … Cloudbees récapitule quelques bonnes règles :
https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin

Il existe déjà des linter pour Jenkinsfile ( https://jenkins.io/doc/book/pipeline/development/ ), mais ils relèvent plus de l’analyse de syntaxe que du détecteur de mauvaises pratiques.
En prenant comme exemple le point 7 dans le top 10 de Cloudbees (ne pas utiliser d’instruction ‘input’ au sein d’un ‘node()’) nous pouvons écrire la règle correspondante pour Sonarqube.

SonarQuoi ?

Sonarqube ( https://www.sonarqube.org/ ) est un outil permettant de mesurer la qualité de votre projet : évaluer sa dette technique, mettre en lumière les mauvaises pratiques et les bugs potentiels. Avec son interface vous avez une synthèse précise quant à la qualité de votre projet. Vous pouvez parcourir les anomalies, les trier par sévérité (bloquante, critique, … ), et même fixer un seuil de qualité ( le quality gate ) à partir duquel votre build ( maven ou autre ) sera terminé en erreur.
Supportant 15 langages dans sa version open-source il est possible d’étendre les jeux de règles par son système de plugins. Les jenkinsfile étant écrits en Groovy, nous allons ainsi enrichir d’une nouvelle règle le plugin dédié à ce même langage ...

CodeNarc

Pour analyser du Groovy, le plugin Sonarqube se base sur le projet CodeNarc https://github.com/CodeNarc/CodeNarc bien connu par la communauté des développeurs. Il peut fonctionner de manière ‘stand-alone’, en ligne de commande et il contient un nombre conséquents de règles qualités. Dans le cadre du plugin sonarqube-groovy il agit en tant qu’élement moteur : Sonarqube invoque CodeNarc puis met en forme les résultats d’analyse pour les mettre à disposition dans son IHM.

Le plugin Sonarqube travaille avec CodeNarc v0.25.2, nous nous baserons donc sur cette version pour enrichir CodeNarc avec notre nouvelle règle : https://github.com/CodeNarc/CodeNarc/releases/tag/v0.25.2

Comment il marche ?

Pour chaque classe, CodeNarc transforme le code source en un arbre ou arborescence, appelée Abstract Syntax Tree (AST). Chaque feuille représentant un élément du code : import, declaration, boucle…

Dans une règle CodeNarc il est possible de réagir lors de la présence d’une feuille précise, laissant la main pour contrôler ce qui la compose. Par exemple on s'abonne à un noeud de type import et on peut vérifier la valeur de l’import. Les ‘abonnements’ suivants sont disponibles :
http://docs.groovy-lang.org/docs/groovy-2.1.8/html/api/org/codehaus/groovy/ast/CodeVisitorSupport.html

Mise en place du futur rulesset ( optionnel )

Un rulesset est en fait un dossier de règles : pour la bonne organisation du projet, il est possible de créer une règle dans un ruleset déjà existant comme ‘basic’ ou bien dans un nouveau que l’on appellerait au hasard ‘Jenkinsfile’. :)

mkdir CodeNarc-0.25.2\src\main\groovy\org\codenarc\rule\jenkinsfile

mkdir CodeNarc-0.25.2\src\test\groovy\org\codenarc\rule\jenkinsfile

Il faut également initier le ruleset dans le répertoire CodeNarc-0.25.2\src\main\resources\rulesets pour cela on y crée un nouveau fichier jenkinsfile.xml avec le contenu minimaliste suivant :

<ruleset xmlns="http://codenarc.org/ruleset/1.0"
    	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    	xsi:schemaLocation="http://codenarc.org/ruleset/1.0  http://codenarc.org/ruleset-schema.xsd"
    	xsi:noNamespaceSchemaLocation="http://codenarc.org/ruleset-schema.xsd">
	<description>Jenkinsfile rule set.</description>
</ruleset>

Création d’une règle à partir du templating

Les auteurs de CodeNarc ont ajouté une classe utilitaire pour simplifier la création d’une règle : (à exécuter à la racine du projet)

groovy codenarc.groovy create-rule

Enter your name:Jon Snow

Enter the rule name:CheckUserInputInNode

Enter the rule category. Valid categories are:
  basic
  braces
  comments
  concurrency
  convention
  design
  dry
  enhanced
  exceptions
  formatting
  generic
  grails
  groovyism
  imports
  jdbc
  jenkinsfile
  junit
  logging
  naming
  security
  serialization
  size
  unnecessary
  unused
( choisissez le rulesset de votre choix jenkinsfile, basic, … )

Enter the rule description: ( apparaîtra dans les commentaires d’en tête de la future classe ) “Check that there is no ‘input’ statement in a ‘node’ block.”

Si une erreur Git survient, ce n’est pas grave, il s’agit juste de l’action create-rule qui essaye de déclarer dans le projet Git les nouveaux ajouts.

Voilà, deux classes, implémentation et test viennent d’être générées :

CheckUserInputInNodeRule.groovy dans CodeNarc-0.25.2\src\main\groovy\org\codenarc\rule[rulesset]

CheckUserInputInNodeRuleTest.groovy dans CodeNarc-0.25.2\src\test\groovy\org\codenarc\rule[rulesset]

Édition du ‘build.gradle’

Nous ne réaliserons pas de release dans cet article, de ce fait nous commenterons :

• la ligne id 'net.researchgate.release' version '2.0.2',
• la partie release à la fin du fichier.

Implémentation de la règle

Notre règle doit répondre à la question suivante : existe-t-il un élément ‘node’ qui contient une instruction ‘input’ ?

Pour le savoir, il faut s’abonner au type de nœud qui voit passer la déclaration de ‘node’ et de ’input’ : comme le montre le catalogue http://docs.groovy-lang.org/docs/groovy-2.1.8/html/api/org/codehaus/groovy/ast/CodeVisitorSupport.html il existe une méthode visitMethodCallExpression fort intérressante que nous allons surcharger : en effet elle réagit à une instruction appel de méthode du genre foo(param1,..), ce qui match avec input(id: 'userInput', … ) ainsi qu’à node('DOCKER'){ ..} .

import org.codehaus.groovy.ast.expr.ConstantExpression
import org.codehaus.groovy.ast.expr.MethodCallExpression

…

class CheckUserInputInNodeAstVisitor extends AbstractAstVisitor {

int startBlockNode
int endBlockNode
	 
@Override
void visitMethodCallExpression(MethodCallExpression mce){

	ConstantExpression ce =  (ConstantExpression)mce.getMethod()
	
	if ("node".equals(ce.getText())){
          // un élément ‘node’ !
          // le node s'étend de quelle ligne à quelle ligne ?
          startBlockNode=mce.lineNumber
          endBlockNode=mce.lastLineNumber
	}

	if ( "input".equals(ce.getText())){
          // un élément ‘input’ !
          // l'élément ‘input’ est il compris dans l'élément ‘node’ ?
		  if (ce.lineNumber >= startBlockNode && ce.lineNumber<=endBlockNode){
			// création d’une violation
			addViolation(ce, 'User input detected in node !')
		  }
	}
	super.visitMethodCallExpression(mce)
}

Test

Pour la classe de test, nous complétons les deux méthodes de tests pré-initialisées, avec du code source pour tester l’implémentation de la règle.

Pour la partie // todo: replace with source for passing edge case(s) nous plaçons un code source qui passe avec succès le test :

stage('test'){
    userInput = input(id: 'userInput',
    message: 'Do you want to release this build?',
    parameters: [[$class: 'PasswordParameterDefinition',
        defaultValue: "",
        name: 'password',
        description: 'Password']])

    sh "echo User Input is" + userInput	
}

Pour la partie // todo: replace with source that triggers a violation avec un code source qui lèvera une violation :

node('DOCKER'){
    stage('test'){
        userInput = input(id: 'userInput',
        message: 'Do you want to release this build?',
        parameters: [[$class: 'PasswordParameterDefinition',
            defaultValue: "",
            name: 'password',
            description: 'Password']])

        sh "echo User Input is" + userInput
    }
}

La condition assertSingleViolation(SOURCE, 1, '...') juste en dessous peut être remplacée par assertSingleViolation(SOURCE, 4 ). En effet, en accord avec la logique du test nous nous attendons à une erreur unique située à la ligne 4 du code source.

La partie testMultipleViolations peut être supprimée, les deux tests précédents étant suffisants.

Exécution de la classe de test :

gradlew test --tests org.codenarc.rule.jenkinsfile.CheckUserInputInNodeRuleTest

ajoutez --info pour avoir une sortie plus verbeuse.

Il est ainsi facile d’œuvrer en TDD jusqu'à obtenir des tests en succès : org.codenarc.rule.jenkinsfile.CheckUserInputInNodeRuleTest > testSingleViolation PASSED

Construction et mise au chaud dans le repository d’artefacts

Dans le fichier build.gradle, remplaçons la version que nous construisons par "0.25.2-custom".

Construction de notre archive CodeNarc custom:

gradlew install -x test -x signArchives

Le goal 'install' va, comme avec Maven, placer notre nouvelle archive dans le repo local .m2

Plugin Sonarqube pour le langage Groovy

Nous déploierons notre plugin maison sur un sonarqube 6.7.6 LTS disponible au moment de la rédaction de cet article. ( https://www.sonarqube.org/downloads/ )

Dans le plugin ‘sonar-groovy’ https://github.com/pmayweg/sonar-groovy (branche master) il nous reste à indiquer l'existence de notre nouvelle règle pour faire le lien avec le moteur CodeNarc, ainsi qu’à faire prendre en compte les fichiers sans extension, cas particulier des ‘Jenkinsfile’.

Important:
Si vous préférez utiliser la version 7 de Sonarqube utilisez le fork de Adam Bertrand, qui prend en charge les modifications des API de plugins Sonarqube pas encore passées en LTS : https://github.com/Hydragyrum/sonar-groovy/tree/replace-rules-profile-7.5

CodeNarc intégré dans le plugin Sonarqube

Le plugin Sonarqube intègre les règles de CodeNarc à l’aide de 3 fichiers présents dans le répertoire sonar-groovy-master\sonar-groovy-plugin\src\main\resources\org\sonar\plugins\groovy :

rules.xml

Dans ce fichier xml la règle est déclarée dans le plugin et sera opérationnelle sur l’instance Sonarqube.

<rule>
    <key>org.codenarc.rule.jenkinsfile.CheckUserInputInNodeRule</key>
    <severity>BLOCKER</severity>
    <name><![CDATA[User input in node]]></name>
    <internalKey><![CDATA[CheckUserInputInNode]]></internalKey>
    <description><![CDATA[<p>Checks for user input in Jenkinsfile. </p>
<p>The input element pauses pipeline execution to wait for an approval - either automated or manual. Naturally these approvals could take some time. The node element, on the other hand, acquires and holds a lock on a workspace and heavy weight Jenkins executor - an expensive resource to hold onto while pausing for input.</p>
<p>Here is an example of code that produces a violation: </p>
<pre>
node('DOCKER'){
		stage('test'){
			userInput = input(id: 'userInput',			// violation
			message: 'Do you want to release this build?',
</pre>
<p>This example is nice: </p>
<pre>

		stage('test'){
			userInput = input(id: 'userInput',			
			message: 'Do you want to release this build?'
			node('DOCKER'){
			...
			}
		}

</pre>
]]></description>
    <tag>bug</tag>
  </rule>

Pour la balise ‘key’ indiquez bien le nom de la classe de la règle.
‘severity’ est le niveau de sévérité par défaut. Il peut être redéfini dans un “profil qualité” ( https://docs.sonarqube.org/latest/instance-administration/quality-profiles/ ).
La ‘description’ de la règle est écrite en HTML, pour l’exemple je me suis permis de reprendre la description du point 7 sur le site de Cloudbees ( https://www.cloudbees.com/blog/top-10-best-practices-jenkins-pipeline-plugin
)

cost.csv

Ce fichier .csv contient le poids de chaque règle en terme de remédiation (le coût de l’effort) pour corriger la mauvaise pratique :

org.codenarc.rule.jenkinsfile.CheckUserInputInNodeRule;linear;10min

profile-sonar-way.xml

Par défaut c’est ce profil du même nom qui est utilisé dans sonarqube pour analyser les fichiers groovy. Grâce à ce fichier la règle y est associée, et se voit attribuer un niveau de gravité éventuellement différent de celui défini dans rules.xml.

 <rule>
      <repositoryKey>grvy</repositoryKey>
      <key>org.codenarc.rule.jenkinsfile.CheckUserInputInNodeRule</key>
      <priority>BLOCKER</priority>
 </rule>

Extension du fichier

Cette partie est optionnelle si vous travaillez uniquement avec des fichiers pipeline qui conservent leurs extensions en ‘*.groovy’, par exemple ‘ci.groovy’.

Sonarqube a l’habitude de travailler avec les extensions des fichiers pour y détecter le langage associé et ignore les fichiers sans extensions. Selons les organisations, il peut arriver que les Jenkinsfile soient des fichiers sans extension. Voici comment les faire analyser :

Dans la classe org.sonar.plugins.groovy.foundation.GroovyFileSystem on modifie la déclaration du prédicat isGroovyLanguage, en créant un nouveau prédicat isJenkinsFile:

    this.isJenkinsfile = predicates.and(predicates.matchesPathPattern("**/*enkinsfile*"), predicates.doesNotMatchPathPattern("**.**"));

    this.isGroovyLanguage = predicates.or(predicates.hasLanguage(Groovy.KEY), isJenkinsfile);

Le scanner sonarqube va associer à l’analyse des fichiers .groovy tout ce qui comporte ‘enkinsfile’ sans extension. Dès lors un fichier ‘Jenkinsfile’ ou ‘JenkinsfileV2’ sera bien analysé. Par contre un Jenkinsfile.java ne sera pas scanné en Groovy mais restera bien au scanner du langage Java.

Dans la classe org.sonar.plugins.groovy.codenarc.CodeNarcSensor méthode public void describe, commentez la ligne

    // .onlyOnLanguage(Groovy.KEY)

Même chose dans la classe org.sonar.plugins.groovy.GroovySensor méthode public void describe, commentez la ligne

    // .onlyOnLanguage(Groovy.KEY)

En effet ces lignes restreignent les analyses uniquement au langage Groovy, c’est-à-dire aux fichiers avec extensions “.groovy”.

Construction du plugin

Dans le fichier sonar-groovy-master\sonar-groovy-plugin\pom.xml indiquons la bonne version pour exploiter notre librairie CodeNarc custom fabriquée auparavant :

<dependency>
  	<groupId>org.codeNarc</groupId>
  	<artifactId>CodeNarc</artifactId>
  	<version>0.25.2-custom</version>
</dependency>

Il ne reste plus qu’à construire le plugin pour Sonarqube (instruction à exécuter à la racine du projet) :

mvn clean package -DskipTests

Oui je sais les tests sont ‘skip’, car en l’état le build échouerait. Pour être propre il faut faire évoluer 3 méthodes de tests.
==>Le code avec les tests à jour est disponible sur le repo GitHub de cet article.

Le plugin est prêt à être placé dans le répertoire \extensions\plugins, après un arrêt/relance, la règle doit être visible :

Analyse d’un projet avec Maven

En principe le Jenkinsfile se situe à la racine du projet.
Dans le cas où vous êtes sûr du nommage du fichier Jenkinsfile vous pouvez le citer expressément :

mvn -U clean package sonar:sonar -Dsonar.sources=Jenkinsfile,pom.xml,src/main

sinon dans le cas où votre ligne de commande est commune à différents projets et que le nommage du Jenkinsfile risque de varier, vous pouvez jouer avec le paramètre -Dsonar.inclusions=*enkins*
afin de couvrir toutes sortes de nommage des fichiers "Jenkinsfile", "JenkinsfileV2", etc

mvn -U clean package sonar:sonar -Dsonar.sources=. -Dsonar.inclusions=*enkins*,src/main/** -Dsonar.exclusions=/target/**

Améliorations

On pourrait imager :

• une phase de build 100% gradle tout en un,
• un import automatique des règles CodeNarc dans les fichiers de configuration du plugin Sonarqube car dans le cas présent nous avons déclaré la règle une fois côté CodeNarc puis une nouvelle fois côté plugin Sonarqube,
• profiter de la dernière version de CodeNarc v1.3 plus moderne.

Conclusion

En prenant l’exemple d’une mauvaise pratique avérée nous avons vu comment concrètement la détecter dans Sonarqube : à votre tour d’enrichir le jeu de règles pour permettre à vos pipelines de gagner en qualité.

De manière générale, pour écrire une nouvelle règle, et quel que soit le langage, vous aurez souvent à manipuler les arbres syntaxiques. C’est dans l’identification des types de nœuds que réside la principale difficulté. Sonarqube propose une documentation pour bien démarrer ( https://docs.sonarqube.org/display/DEV/Adding+Coding+Rules+using+Java ).

Particularité de cet article où nous avons écrit du Groovy pour enrichir le moteur CodeNarc, les autres plugins Sonarqube embarquent leurs propres parseurs d’AST et sont écrits en Java, rendant la tâche plus simple et moins exotique.

L’autre particularité de cet article est que nous nous sommes permis de modifier le plugin pour étendre l’analyse à des fichiers sans extension, ce qui reste peu commun, mais intéressant à connaître.

Au final essayez d’associer Sonarqube à toutes les facettes de votre projet : Java, technos front, Jenkinsfile, ... et exploitez la fonctionnalité du ‘water leak’ pour éviter l’effet ‘mur des bugs’ !

Le code source est disponible sur: https://github.com/maxospiquante/blog_ippon_sonarqube_jenkinsfile

Cluster permanent VS Cluster éphémère à la demande

La démocratisation des services Cloud type “Hadoop As A service” a constitué une évolution majeure dans le monde du Big Data et du calcul distribué. Cette accessibilité simplifiée (10 min pour AWS) à une ressource jusqu’alors complexe a permis l’émergence d’un nouveau paradigme d’architecture : l’éphémérité.

Avant cette démocratisation, la grande majorité des datalakes étaient on-premises, monde où les clusters étaient par nature permanents ce qui a répandu cette pratique d’utiliser un cluster unique (par environnement) pour soumettre tous les jobs d’un développeur, d’une équipe, d’une DSI comme la norme de cette époque.

Ce mode de fonctionnement présente plusieurs inconvénients :

• Les clusters ont tendance à fonctionner 24/7, même la nuit et quand il n’y a pas besoin de ressources de calcul. Même s’il est possible d’éteindre le cluster cela ne fera économiser que de l’électricité et ne diminuera pas l'investissement matériel ni les coûts opérationnels.
• Le cluster possède une capacité déterminée (nombre de nœuds, mémoire et CPU par nœuds…) et commune à tous les jobs quand bien même les besoins en ressources seraient différents pour ces derniers.
• Pour partager un cluster Hadoop il faut mettre en place du multi-tenant entre les différents utilisateurs (par exemple une queue Yarn par projet), ce qui augmente la complexité opérationnelle.
• Un cluster permanent implique de faire les mises à jour des services du cluster ce qui induit une complexité opérationnelle loin d’être négligeable.
• Enfin bien qu’il soit possible maintenant d’utiliser des systèmes de fichiers externes comme CEPH ou un stockage objet, pour découpler la scalabilité en compute de celle du storage (qui n’est pas présente avec HDFS), il est toujours compliqué en terme d’opérations d’avoir à gérer du scale up & down.

Avec les services Cloud, l’approche est complètement différente puisque je peux bénéficier à la demande d’un cluster Hadoop en moins de 10 minutes. L’intérêt de faire tourner le cluster en 24/7 est finalement assez rare. On passe à un paradigme de cluster transient : chaque job de calcul (Spark, Flink etc..) est associé à un code d’infrastructure propre aux besoins en ressources (CPU, RAM) du job. Pour réaliser un quelconque traitement, on va donc instancier un cluster spécifiquement pour ce traitement. Une fois le cluster créé, le job de calcul se lance puis, son exécution terminée, le cluster sera automatiquement détruit.

Cette approche impose d’utiliser un système de fichier externe comme EMRFS (système de fichiers AWS compatible Hadoop basé sur S3) au lieu de HDFS car les données ne peuvent pas être persistées au sein du cluster. Nos données seront donc stockées sur S3 (capacité de stockage illimitée) et on configurera le cluster Hadoop avec les ressources de calcul nécessaires pour faire tourner le job. Les avantages de cette approche sont les suivants :

• Le storage et le compute sont découplés et peuvent scaler indépendamment.
• La configuration du cluster est parfaitement adaptée au besoin Job.
• La tarification est pay-as-you-go ; on ne paye que pour ce que l’on consomme car lorsque le job est terminé le cluster est détruit.
• Pas de risque de conflit de ressources entre les différents jobs.
• On peut profiter de l’utilisation des instances préemptibles (instance dont le prix varie en fonction de l’offre et de la demande). Par exemple si un batch doit tourner entre 22h et 6h du matin on va pouvoir lancer la création du cluster et le lancement du job au moment où le marché de l’instance sera le plus bas.

L’utilisation des clusters éphémères présente de nombreux avantages mais impose un changement de paradigme dans la façon de penser le traitement de la donnée.
Cela implique également de penser en terme d’infrastructure as code automatisée plutôt que de créer manuellement les ressources sur l’interface du Cloud provider ou d’utiliser la console shell. On doit également être en mesure de variabiliser notre code d’infrastructure en fonction de l’environnement et des ressources en compute nécessaires pour chaque job (qui varieront selon les environnements).

Contexte de l’article et Use case

Le but de cet article est de présenter cette implémentation réalisée dans un contexte client réel. En effet dans le cadre d’une ré-implémentation fonctionnelle d’un système legacy vers un nouveau système bâti entièrement sur des services managés AWS, j’ai travaillé sur la migration d’un jeu de données conséquent depuis l’ancien système vers le nouveau. Ces données nous ont été mises à disposition par une autre équipe dans un bucket S3 pour les enregistrer dans notre base de données de référence DynamoDB ainsi que dans notre moteur de recherche : ElasticSearch Service. Il s’avère que l’on doit appliquer des transformations sur ces données pendant leur transit (nettoyages, jointures et agrégations principalement) ainsi que de valider que le format des données respecte la spécification Swagger définie entre nos deux équipes.
C’est cette non trivialité en terme de transformations et le volume qui nous ont fait opter pour Spark exécuté depuis AWS EMR plutôt que d’autres solutions envisagés initialement (Athéna et AWS Glue notamment).

Vous l’aurez compris, cet exemple sera fortement lié à AWS mais les mêmes principes sont applicables chez les autres Cloud providers.

Lorsque j’ai commencé ce projet, j’ai été surpris du peu de ressources disponibles sur le sujet surtout sur la partie implémentation de cluster éphémère sur AWS, c’est une des raisons qui m’ont poussé à écrire cet article.

Pour le code d’infrastructure la technologies utilisée est Terraform pour une raison très simple liée à mon contexte client, c’est l’unique moyen autorisé pour déployer de l’infrastructure au niveau de la DSI (console AWS en read-only à partir de l’environnement d'intégration, ce qui est plutôt une bonne chose quand on y pense).
Ceci dit, ce choix n’est pas surprenant, Terraform étant une des technologies d’infrastructure les plus matures sur le marché et plus simple à utiliser que CloudFormation qui est basé sur du YAML et bien plus difficile à modulariser. À noter quand même qu’AWS a sorti récemment Cloud development Kit qui permet de faire de la “vraie” infra as code en JavaScript (et donc simplifier la gestion des tests pour l’infrastructure), prometteur donc.

On distinguera, dès le début de l’article, 2 repositories de code séparés :

• Le répertoire de code Spark Scala qui contient le code ETL applicatif et le pipeline d’intégration continue,
• Le répertoire de code Terraform qui contient le code d’infrastructure et le pipeline de déploiement continu.

La Continuous Integration du code applicatif a pour objectif de lancer les tests, packager un binaire avec les dépendances, pousser ce binaire sur un bucket S3 (qui fera office de gestionnaire d’artifacts) et enfin de déclencher l’exécution du code d’infrastructure pour lancer un pipeline de Continuous Deployment où sera effectuée la commande qui va déployer l’infrastructure.

terraform apply 

Nous nous intéresserons dans cet article uniquement à la partie code d’infrastructure en partant du postulat que l’on a à disposition dans un bucket S3 un JAR contenant le code Spark et les dépendances. On fera également abstraction de toute la partie IAM en partant du principe que l’on a :

• Les droits en lecture sur le bucket d’artifact où est stocké le JAR,
• Les droits en lecture sur le bucket contenant les données,
• Les droits en écriture dans une table DynamoDB existante,
• Le Security Group lié à ElasticSearch Service qui autorise le trafic venant d’EMR
• Les Security Groups du master et des slaves correctement configurés.

Néanmoins, dans la vraie vie ces problématiques liées à la sécurité et l’Identity Access Management sont centrales et souvent les plus difficiles à comprendre et à mettre en place, mais c’est un autre sujet :)

Implémentation d’un cluster Spark à la demande avec Terraform et EMR

EMR est un service de cluster Hadoop managé sur AWS qui utilise un cluster d’instances EC2 avec Hadoop pré-installé et configuré.

Terraform met à disposition une ressource nommée aws_emr_cluster qui permet de créer un cluster Hadoop sur AWS. Ainsi, cette ressource attend un certain nombre de paramètres en entrée :

Tout d’abord il faut spécifier la version d’EMR souhaitée via l'option release_label (les versions d’EMR sont référencées dans la documentation AWS). Comme EMR est composé d’une constellation de services, chaque version d’EMR correspond à un ensemble de versions pour chacun des services qui le composent. AWS garantit la cohérence des versions des services et le bon fonctionnement entre les différentes versions.
On peut se rendre compte de cet aspect “composition de services” sur l’image ci dessous.

release_label = "emr-5.20.0"

Ensuite on va indiquer à EMR les services que l’on veut utiliser sur le cluster (dans notre cas, Hadoop, Spark et Ganglia pour le monitoring) :

applications  =  ["Hadoop","Ganglia","Spark"]

On peut également transmettre un fichier JSON de configuration à la ressource. C’est ce fichier de configuration qui permet de spécifier les options propres à Spark (nombre de partitions, mémoire par exécuteur, cœurs par exécuteur etc..) :

[
    {
      "Classification": "spark-defaults",
      "Properties": {
        "spark.executor.memory": "4G"
      }
    }
]

Il faut indiquer que le cluster doit être supprimé automatiquement une fois le job terminé grâce au paramètre keep_job_flow_alive à false. C’est cette option qui permet de déployer un cluster éphémère, qui se détruira une fois le job terminé. Par défaut la valeur est à true et correspond donc à un cluster permanent

keep_job_flow_alive_when_no_steps = false

Une autre option importante est log_uri qui permet d’indiquer à EMR le bucket S3 où il devra enregistrer les logs :

log_uri = "s3n://aws-logs-<account_id>-<region>/elasticmapreduce/"

Cette option est très importante et permet de collecter les logs Spark et surtout les logs YARN, indispensables pour le debug, dans un bucket S3 et également directement visualisables depuis la console graphique.
À noter que les logs sont disponibles sur S3 avec une latence de 5 à 10 minutes, rendant compliqué le suivi en temps réel du job.
On pourrait imaginer une bootstrap_action qui installerait un agent quelconque sur les instances pour envoyer les logs et métriques dans un outil externe pour un suivi en temps réel.

Enfin il faut associer un rôle IAM à notre cluster EMR via l’option service_role. Rôle qui servira à ajouter des IAM policy à notre cluster (comme les droits d’écriture dans DynamoDB) :

service_role = "<your_service_role_arn>"

Un des paramètres importants est la définition des EC2 attributes. En effet, il faut définir les types d’instance, la puissance, etc., des machines EC2 utilisées.
C’est donc naturellement ici que l’on associerait les instances à une key pair et à un security group autorisant le port 22 pour le SSH, mais ce ne sera pas notre cas vu que l’on n’aura pas besoin de se connecter à un cluster éphémère :)
Les options pour les EC2 sont les suivantes :

• subnet_id afin de savoir dans quel VPC créer le cluster,
• emr_managed_master_security_group, le master étant une instance, il vient forcément avec un security group dédié où l’on autorise le trafic sortant.
• emr_managed_slave_security_group, les slaves étant un ensemble d’instances, ils viennent forcément avec un security group dédié où l’on autorise le trafic sortant.
• instance_profile qui permet de configurer un profil pour nos instances. On utilise un statement très simple qui permet à nos instances d’assumer le rôle ec2.amazonaws.com.

On doit également fournir la composition du cluster via l’option instance_group. On passe un tableau d’instances (pour la master et les slaves) avec des informations sur le nombre souhaité d’instance master, le rôle de l’instance, le type d’instance et enfin le nombre d’instances slave :
La bonne pratique est de redonder les instances master en passant le nombre à 3 (un par zone de disponibilité). Cela permet de garantir que le cluster pourra continuer de fonctionner même si un des datacenters subit une coupure de service.

À noter que dans les instances slaves il est possible d’utiliser des instances Spot et de préciser une enchère maximale via l’option bid_price.
Dans notre cas les instances seront créées uniquement si le bid_price est inférieur ou égal à 0.30$.

La définition du nombre d’instances slaves, du rôle d’instance (core ou task- et du type d’instance dépend entièrement des spécificités et du besoin en ressources du job mais aussi de l’environnement (cluster plus léger en développement qu’en production par exemple).
C’est ici qu’on se rend compte de toute la souplesse que nous offre cette approche en permettant d’associer la meilleur configuration de cluster possible en fonction des besoins d’un unique job.

instance_groups = [
    {
      name           = "MasterInstanceGroup"
      instance_role  = "MASTER"
      instance_type  = "m4.large"
      instance_count = "3"
    },
    {
      name           = "CoreInstanceGroup"
      instance_role  = "CORE"
      instance_type  = "m4.xlarge"
      instance_count = "3"
      bid_price      = "0.30"
    }
  ]

Une fois tout ceci correctement configuré, notre cluster est prêt à lancer des jobs Spark à la demande. Il nous reste à ajouter des étapes via l’option bien nommée step.
Les steps correspondent aux actions à effectuer sur le cluster. On peut soumettre de multiples steps mais dans notre cas d’exemple on en aura une seule pour notre job Spark d’ETL.

Une step attend plusieurs options :
action_on_failure : si la step part en erreur faut il détruire le cluster ou non,
name : chaque step est identifiée par un nom,
hadoop_jar_step: c’est ici que l’on va définir le lancement de notre job.

Lors de la création d’un cluster EMR, un binaire d’AWS est automatiquement présent sur le cluster command_runner.jar. C’est à partir de ce binaire qu’on est capable d’exécuter une commande (Spark ou autre).

On va ensuite passer un certain nombre d’arguments à ce command_runner :

• spark-submit : pour indiquer que l’on va lancer un job Spark,
• deploy-mode cluster : pour lancer le job en mode cluster (indispensable pour un cluster transient),
• class <la_main_class_applicative>,
• master yarn : pour indiquer le type de déploiement,
• <chemin vers le jar sur S3>.

Plus d’éventuels arguments à passer en paramètre au job Spark (tel que l’environnement par exemple, pour savoir quel fichier de configuration utiliser au niveau applicatif).

  step {
    action_on_failure = "TERMINATE_CLUSTER"
    name   = "Launch Spark Job"

    hadoop_jar_step {
      jar  = "command-runner.jar"
      args = ["spark-submit","--deploy-mode","cluster","--class","${var.spark_main_class}","--master","yarn","s3://${var.artifact_bucket}/${var.spark_artifact_name}", "${var.environment}"]
    }
  }

On peut (doit !) également bien évidemment rajouter des tags sur la ressource EMR que l’on est en train de créer, notamment pour la gestion des coûts sur la plateforme AWS.

Conclusion

Comme on l’a vu cette approche permet de lancer des clusters Spark à la demande pour exécuter un traitement distribué. Néanmoins le combo Terraform + EMR n’est pas la seule solution possible pour résoudre ce problème.
En restant dans le monde AWS, Glue est un service qui permet d’exécuter des jobs Spark à la volée. Néanmoins Glue vient avec certaines limitations et une couche d’abstraction à Spark (utilisation des DynamicFrame) rendant le produit intéressant mais trop limité et pas suffisamment mature pour être envisagé en production. Glue est à ce jour prévu pour fonctionner avec un script Python ou Scala ce qui est préjudiciable pour la séparation du code Spark en package distinct. Glue est également limité en terme de métriques et logs et l’accès aux logs YARN est déterminant pour développer avec Spark.

Un autre outil venant du monde open source est Flintrock qui permet d’instancier des clusters Spark à la volée sur des EC2 via une CLI. Néanmoins il s’intègre mal avec Terraform qui ne pourra pas gérer les security groups propres au cluster instancié. De plus pour une implémentation qui sera déployée en production il peut être risqué de dépendre d’un outil externe. Mais cela peut être une bonne alternative pour les phases de développement.

À noter qu’OVH propose depuis peu un service de cluster Spark à la demande nommé Analytics Data Compute qui aurait pu être intéressant si le choix du provider n’avait pas été une des conditions initiales !

Cet article vous donne une bonne base pour instancier vos propres clusters EMR éphémères avec Terraform. Néanmoins avant d’utiliser cette implémentation en production il faut porter une attention toute particulière à la sécurité d’une part via l’Identity Access Management, les Bucket Policy et les Security Groups mais d’autre part en s’assurant que les données sur S3 sont chiffrées (chiffrement at rest) mais surtout s’assurer du chiffrement des données entre les nœuds du cluster (chiffrement in transit).

J’espère que cet article vous aura convaincu des avantages des clusters Hadoop éphémères par rapport aux clusters permanents et qu’il vous permettra d’implémenter rapidement cette approche sur vos projets :)

Petit rappel

Suite à mon précédent article présentant Prometheus et son fonctionnement, voici un deuxième article comparant Prometheus et les autres solutions de supervision du marché comme :

• Nagios ;
• Zabbix ;
• Sensu ;
• InfluxData.

Prometheus est un logiciel de supervision open-source créé par SoundCloud. En 2013, SoundCloud a décidé d’utiliser Prometheus pour ses infrastructures de Production et a publié la version 1.0 en Juillet 2016.

Prometheus, écrit en GO, s’impose depuis comme la solution de référence pour superviser une infrastructure de type Cloud, SaaS/Openstack, OpenShift (OKD), Kubernetes (K8S).

Par rapport aux autres solutions ?

Il existe de nombreuses autres solutions de supervision sur le marché, chacune ayant ses avantages et ses inconvénients. La suite de l’article présente un comparatif avec les solutions les plus connues du marché.

Nagios

Nagios est le plus ancien système de supervision et fonctionne uniquement par l’exécution de scripts renvoyant une valeur (0,1, 2 ou 3). Il n’y a aucune gestion avancée des alertes comme le regroupement, le routage en fonction du type ou bien la déduplication qui permet de ne recevoir qu’une seule fois l’évènement même si celui-ci se reproduit plusieurs fois.

Architecture

Le(s) serveur(s) Nagios sont indépendants. Toutes les configurations se font au travers de fichiers. Nagios est un système basique pour la supervision de petits systèmes qui n’évoluent pas mais n’est pas adapté à la supervision d’une infrastructure de type Cloud. La supervision de containers ou la récupération des statistiques kubernetes est assez compliquée car il faut écrire ses propres checks.

Modèle de données

Nagios possède uniquement un stockage local et n’a aucune notion de requêtage de données. Il requiert des plugins pour permettre l’historisation des données et par conséquent le stockage. Par défaut, il ne stocke que la dernière valeur d’un check.

Zabbix

Zabbix est un système de supervision créé il y a 20 ans. Avec sa version 4.0, il a su se réinventer mais il reste tout de même dans la lignée de Nagios et de son fork Centreon. Il est développé en C et le front web est en PHP.

Architecture

Zabbix utilise par défaut le mode pull en se connectant aux agents locaux qui sont à déployer sur chaque système à superviser, ou à un agent local au serveur pour effectuer les checks sur les équipements de type réseaux.

Le serveur Zabbix récupère les données depuis les agents et calcule les alertes. La communication entre les agents et le serveur est un protocole maison basé sur du TCP.

Il est possible de trouver un nombre important de templates et de checks sur Internet mais il n’y a pas d’intégration complète avec des systèmes récents de type Cloud comme Openstack, K8S, OKD. Cependant, il est possible de créer ses propres checks mais cela reste compliqué lorsque l’on veut superviser des systèmes modernes.

Son ancienneté est un gage de robustesse et convient particulièrement bien pour la supervision de hardware et les services type NTP, serveurs WEB, Nexus, etc... Cependant, il ne convient pas s’il est nécessaire de superviser plus de 10 000 instances et il est très difficile de scaler la partie serveur (acquisition des données), si ce n’est en augmentant la taille du serveur pour avoir de meilleurs performances.

Modèle de données

Zabbix utilise une base de données relationnelle (MySQL, PostgreSQL, Oracle, sqlite) pour stocker les données, la configuration et les évènements. La nouvelle version 4.x permet de stocker des métriques dans un cluster Elasticsearch. Cette fonctionnalité est encore expérimentale et complexifie la maintenance du système de par la gestion d’un cluster Elasticsearch.

Dans le cas où les données sont stockées dans une base de données SQL, il est vivement conseillé de partitionner les tables. Dans le cas de PostgreSQL version 10.x et supérieure, il existe des scripts bash permettant de partitionner les tables stockant les valeurs pour atteindre des performances élevées.

Sensu

Sensu est un framework de monitoring plutôt qu’un système complet de supervision. Sensu se décompose en plusieurs briques :

• Sensu Client ;
• Sensu Server ;
• Sensu API ;
• Uchiwa ;
• Rabbit MQ et/ou Redis.

Architecture

Redis est utilisé pour le stockage tandis que RabbitMQ permet de faire converger toutes les données en provenance des Sensu clients. Uchiwa est l’interface de gestion de Sensu.

Les clients sont déployés sur les différents hôtes à superviser et ils effectuent les checks qui sont identiques à Nagios. Chaque check doit renvoyer un exit code définissant l’état du service (0 : OK, 1 : Warning, 2 : Critical, 3 : Unknown)

Modèle de données

Le modèle de données est identique à Nagios, sauf que par défaut, la gestion du stockage est intégrée et portée par Redis.

Sensu est une bonne solution dans le cas où il existe déjà une supervision Nagios et qu’il y a une volonté de changer de système et/ou de bénéficier de l’enregistrement automatique fourni par Sensu. Dans tous les autres cas, il vaudrait mieux privilégier une autre solution.

InfluxData

InfluxData est une stack de supervision comprenant Telegraf, Kapacitor, InfluxDB et Chronograf. Chaque système à superviser doit avoir un agent local nommé Telegraf qui remonte les données vers le système de collecte Kapacitor.

Architecture

Prometheus et InfluxDB ont des stockages locaux. Cependant, la version commerciale de InfluxDB offre une solution de clustering et scaling native permettant une intégration simplifiée du scaling horizontal mais cela oblige quand même à gérer le stockage distribué.

Prometheus et Alertmanager offrent une solution native de distribution / redondance tandis que Kapacitor n’a pas cette fonctionnalité.

InfluxDB est une base de données “Time series” open-source avec une option commerciale pour la partie cluster et scaling.

Chronograf est l’interface de gestion du système de supervision et permet aussi la visualisation. Cependant, il est recommandé d’utiliser Grafana qui a un connecteur vers la base InfluxDB.

Modèle de données

Le modèle de données est sensiblement le même que Prometheus mais supporte un plus grand nombre de types (int64, bool, timestamps avec une résolution à la nano seconde).

Conclusion

Chaque système de supervision possède son cas d’usage mais Prometheus correspond parfaitement à un besoin de supervision de type Cloud, Docker, Kubernetes (K8S) ou OpenShift (OKD). Prometheus a l’avantage d’être directement déployé dans des projets comme Kubernetes (K8S), OpenShift (OKD). Il répond parfaitement aux exigences de supervision temps réel mais n’est pas conçu pour stocker les données des métriques sur une longue période de rétention. Dans ce cas, il conviendrait de coupler Prometheus à un stockage distant comme InfluxDB ou autre.

Il n’est plus nécessaire de présenter Kafka de nos jours, cette technologie de stream processing connaît une popularité de plus en plus grande au fil des derniers mois, sa grande communauté, sa constante évolution et sa simplicité d'utilisation en font une référence dans la pléthore de technologies big data sur le marché, ci dessous se trouve un graphique montrant le pourcentage d'apparition des technologies de stream processing "connues" dans les questions de StackOverflow

Malheureusement, la popularité d’un projet open-source n’est pas proportionnelle à sa bonne utilisation, il arrive fréquemment qu’un projet utilisant du Kafka acquiert une dette technique dès le premier commit à cause d’une mauvaise architecture et d’une mauvaise identification du use-case métier.

Ceci entraîne sur le long terme un projet difficile à maintenir, difficile à faire évoluer, des microservices ressemblant à des monolithes distribués entraînant des développeurs frustrés d’y toucher car ils considèrent le projet comme une espèce de zone radioactive …

Je vais donc expliquer dans cet article, au moyen d’un use case simple, comment passer d’un consommateur Kafka “monolithique”, à des microservices orientés sur les technologies Kafka Streams et Kafka Connect.

1 - Use case :

L’application décrite dans cet article est une API permettant d’envoyer des e-mails et des SMS.

Pour chaque message envoyé, l’API doit être capable d’identifier si le message est d’abord passé par l’api (événement REQUEST), qu’il a été remis au destinataire (événement SENT), il doit aussi être possible de déterminer si le destinataire a ouvert son message et de détecter s’il a cliqué sur les liens présents dans le message.

De plus, l’API doit savoir si le message n’a pas pu être remis au destinataire et d’en connaître la raison.

Pour ce faire, une architecture construite autour de Kafka a été mise en place.

Chaque message envoyé dans l’API, et ensuite envoyé dans Kafka pour être consommé et envoyé vers un serveur SMTP si c’est un email ou SMPP si c’est un SMS.

Après le retour du serveur, le message et tous ses événements sont sauvegardés dans Couchbase, puis chaque événement associé au message est envoyé dans un topic de retour.

{
	"messageType" :  "EMAIL"
	"id" : "xxx-yyy-zzz"
	"events" : [
		{
			"eventType" : "REQUEST" // Le message à été pris en compte par l'api
			"date" : "2019-01-01 00:00:00"
		},
		{
			"eventType" : "SENT" // Le message à été envoyé au destinataire
			"date" : "2019-01-01 00:00:01"
		}
	]
}

Exemple de message envoyé et remis au destinataire.

Par la suite, nous allons nous pencher sur la partie d’envoi de message, nous ne discuterons pas du tracking de ces messages.

2 - Premiers développements

L’API a été développée à l’origine avec des Producers et des Consumers Kafka, au bout de quelques mois de développement, celle-ci a été mise en production avec les éléments d’architecture suivants :

Cette architecture bien que naïve, présente une grande simplicité.

Le consommateur se charge de distinguer les messages entre e-mail et SMS, puis les envoie au serveur associé au type de message. Si le message n’a pas été envoyé alors celui-ci est immédiatement sauvegardé dans Couchbase avec l’erreur associée, ensuite tous les événements associés au message sont envoyés dans le topic retour.

Cependant, des problèmes sont rapidement survenus après la première mise en production :

• En cas de problème dans Couchbase, impossible de sauvegarder le message, celui-ci est perdu dans la file Kafka
• En cas de problème d’envoi, impossible de pouvoir rejouer le message automatiquement
• À cause des appels synchrones, lorsque le serveur SMTP a des latences d’envoi, cela impacte les envois des SMS et inversement
• La maintenance de code est difficile car les code pour envoyer un e-mail et un SMS est différent, mais tout est mutualisé dans une seule classe
• Les événements sont sauvegardés uniquement à la fin du traitement, ce qui engendre un risque de perte de message au milieu de l’application

C’est ainsi que le travail vers l’architecture V2 commença. Par soucis de simplicité, je vais vous présenter les évolutions étape par étape pour ensuite arriver à l’architecture finale.

Étape 1 : Séparation email / sms

Il s’agit ici de la première étape, la plus évidente, séparer chaque type de message en leur créant un topic dédié. Ceci permet de ne plus impacter les envois des emails lorsque le serveur SMPP a de la latence, mais aussi de simplifier le code en séparant toutes les classes traitant les SMS et les e-mails dans des classes spécifiques.

Afin que le client puisse s’adapter au changement d’appel pour l’api, l’ancien microservice d’exposition était encore disponible temporairement.

Étape 2 : Simplification des consommateurs

Maintenant que la séparation est faite, on peut encore simplifier le code du consommateur.

Pour rappel, chaque fois que le message à été envoyé par le consommateur, celui-ci sauvegarde tous les événements associés à l’id du message dans Couchbase, puis dans le topic de retour.

Afin de simplifier notre code, il suffit donc de séparer l’envoi des événements au topic retour dans une instance Kafka Streams, puis de déplacer la partie sauvegarde dans Couchbase en la remplaçant par du Kafka Connect.

Afin de pouvoir mettre en place du Kafka Streams et du Kafka Connect, nous devons implémenter un nouveau topic en sortie des consommateurs d’envoi sur lesquels nos nouveaux composants pourront se brancher, nous allons donc créer un topic par type de message et les appeler SendMailOk et SendSmsOk

Par la suite, afin de simplifier le schéma d’architecture, je vais parler uniquement de la partie d’envoi d’email.

Étape 3 : Gérer les erreurs et le rejeu automatique des messages en erreur

Afin de pouvoir gérer les messages en échec nous avons dû réfléchir à un moyen de renvoyer les messages automatiquement tout en sauvegardant les messages dans un endroit de secours en attendant que Couchbase se rétablisse.

Pour cela, nous avons décidé d’envoyer tous les messages en échec dans un topic dédié afin de pouvoir les rejouer instantanément. Nous avons donc créé un topic SendMailRetry.

Pour traiter les messages de ce topic, nous avons démarré une nouvelle instance du consommateur d’envoi déjà implémenté que l’on a baptisé comme son topic parent : SendMailRetry.

Nous avons en plus ajouté une nouvelle fonctionnalité permettant au consommateur de récupérer les informations du topic toutes les minutes afin de ne pas rejouer les messages en erreur instantanément. Cela laisse le temps au serveur d’envoi (SMTP ou SMPP) de se remettre en place pour augmenter les chances de réussite d’envoi du message.

Dans le cas où le deuxième envoi ne fonctionne pas, nous renvoyons le message dans le topic SendMailRetry avec un nouvel événement “RETRY”, si le troisième envoi ne fonctionne pas, nous ajoutons un nouvel événement puis nous renvoyons le message dans le topic et ainsi de suite ...

{
    "messageType" :  "EMAIL"
    "id" : "xxx-yyy-zzz"
    "events" : [
        {
            "eventType" : "REQUEST" // Le message à été pris en compte par l'api
            "date" : "2019-01-01 00:00:00"
        },
        {
            "eventType" : "RETRY" // Le message n’a pas été remis, on rejoue
            "date" : "2019-01-01 00:00:01"
        },
        {
            "eventType" : "RETRY" // Le message n’a pas été remis, on rejoue
            "date" : "2019-01-01 00:00:01"
        },
        {
            "eventType" : "SENT" // Le message à été remis au bout de 3 tentatives
            "date" : "2019-01-01 00:00:01"
        }
    ]
}

Exemple de message lors de rejeu

Si au bout de la cinquième fois le serveur d’envoi ne répond toujours pas, alors nous considérons que le message est définitivement perdu. On ajoute un événement “DEAD” au message, puis nous le mettons dans un topic “ Dead letter queue” appellée SendMailDlq.

{
    "messageType" :  "EMAIL"
    "id" : "xxx-yyy-zzz"
    "events" : [
        {
            "eventType" : "REQUEST" // Le message à été pris en compte par l'api
            "date" : "2019-01-01 00:00:00"
        },
        {
            "eventType" : "RETRY" // Le message n’a pas été remis, on rejoue
            "date" : "2019-01-01 00:00:01"
        },
        {
            "eventType" : "RETRY" // Le message n’a pas été remis, on rejoue 2 fois
            "date" : "2019-01-01 00:00:01"
        },
    …….
    …….
        {
            "eventType" : "RETRY" // Le message n’a pas été remis, on rejoue 5 fois
            "date" : "2019-01-01 00:00:01"
        },
        {
            "eventType" : "DEAD" //Le message n’est pas envoyé il termine dans la DLQ
            "date" : "2019-01-01 00:00:01"
        }
    ]
}

Exemple de message non envoyé

Voici maintenant à quoi ressemble notre architecture en appliquant ces évolutions :

Étape 4 : La sauvegarde des événements au fil de l’eau

Avant de valider la dernière architecture, il restait encore un dernier problème à adresser : Notre projet sauvegarde tous les événements lors de l’arrivée dans le topic SendMailOk ou SendMailDlq, mais comment gérer la sauvegarde de tous les événements dans la base et dans le topic de retour sans avoir à attendre que tous les événements arrivent jusqu’au bout ?

Pour cela, il faut se pencher sur la vie d’un message dans notre application. Prenons l’exemple d’un e-mail, à chaque fois qu’un message s’apprête à passer dans un service, nous lui ajoutons un événement, puis nous l’envoyons dans le topic associé à cet événement.

Ainsi, chaque message passant par un topic aura son dernier événement associé à celui-ci.

Étant donné que notre topic Retour contient un message par type d'événement, il nous suffit de brancher l’instance Streams existante sur nos nouveaux topics puis de regarder à chaque fois le dernier événement pour chaque message et de l’envoyer dans le topic Retour.

Pour la sauvegarde dans la base de donnée, nous faisons une écriture du message dans Couchbase en utilisant l’id comme clé. Le client Couchbase va se charger de faire un upsert afin de ne pas faire de prélecture et gagner en performances.

Voici donc le schéma final pour la partie e-mail :

Dans ce schéma, chaque case Kafka Connect et Streams représente une seule instance du même service.

Étape 5 - Future work : Gérer les messages en erreur dans les instances Streams et Connect.

Et comment faire dans le cas où notre instance Streams rencontre un mauvais format ?

Même si nous ne sommes pas censés récupérer des messages au mauvais format, nous ne sommes pas à l’abri qu’à cause d’un changement de format de message non rétro compatible suite à une mauvaise mise en prod notre instance Streams n’arrive plus à désérialiser un message et se mette en erreur.

Pour régler ce problème Il existe le paramètre default.deserialization.exception.handler  qui permet de définir la stratégie à adopter en cas d’erreur de désérialisation. Par défaut celui-ci est mis à FAIL. C’est à dire que l’instance va se stopper lorsqu’elle ne va pas réussir à désérialiser un message, entraînant ainsi une rupture de service.

Pour éviter ça, nous avons mis ce paramètre à CONTINUE car notre use-case nous permet d’avoir une perte de message lorsque celui-ci à déjà été envoyé par le SMPP/SMTP.

Au niveau des erreurs dans Kafka Streams, il existe deux paramètres permettant de dire à l’instance d’envoyer le message dans une DLQ en cas d’erreur :

errors.tolerance
errors.deadletterqueue.topic.name

Ainsi, en cas d'échec de l’envoi dans Couchbase d’un message, celui-ci est identifié et sauvegardé dans une file Kafka dédiée afin d’être rejoué par une autre instance Kafka Streams lancée à la demande.

Avantages et retour d’expérience :

Après plusieurs mois d’utilisations de cette architecture, voici les avantages que nous avons rencontrés :

• Maintenance aisée :

Nous avons remarqué une maintenance du code bien plus simple, chaque modification pour un type message est facilement réalisable en modifiant le consommateur Kafka d’envoi associé.

• Configurabilité :

Cette architecture nous permet de gérer le multi-client ou la priorisation de messages en paramétrant chaque microservice vers un Topic dédié. Tout se fait via un fichier de configuration.

• Scale on demand :

Nous avons aussi pu vérifier la scalabilité horizontale de nos microservices lors des périodes de fortes activités en augmentant le nombre d’instances de consommateurs d’envoi.

• Monitoring détaillé :

Cette architecture permet aussi d’avoir un monitoring bien plus détaillé de notre API, nous sommes capables d’analyser finement les logs de chaque microservice afin de déterminer si celui-ci est en bonne santé. Kafka Connect est monitoré grâce à son API REST et Kafka Streams par l’envoi des logs dans un ELK.

Cependant, cette architecture demande une bonne connaissance de Kafka et de son  écosystème car elle nécessite un cluster en bonne santé et bien maintenu.

De même, pendant toute notre expérience, nous n’avons fait qu'enlever du code à notre consommateur d’envoi principal, un travail à faire serait de convertir ce consommateur en Kafka Streams.

Ionic 4 est sorti en janvier 2019, il amène avec lui quelques nouveautés que je vais vous présenter.

• Rappel : qu’est-ce c’est que Ionic ?

Ionic est un framework gratuit et Open Source créé en 2013, permettant de développer rapidement des applications mobiles multi-plateforme notamment pour Android, iOS et le web, à partir d’une seule base de code. Vous connaissez le HTML, CSS et Angular, vous pouvez y aller !

• Ionic for Everyone

“Ionic for Everyone” est le slogan de Ionic 4, car l’un de ses points forts est de permettre son utilisation partout, d’être plus accessible à tous les développeurs, pour les applications mobiles, desktop et les PWA (Progressive Web App). Le but de cette version est aussi d’améliorer ses performances tout en étant plus complet.

Ionic 4 s’appuie énormément sur Angular 7+, bien plus que Ionic 3. Le but est d’allier la performance et la polyvalence. C’est pour celà que Ionic 4 utilise maintenant Angular Router pour la navigation. Il est également utilisé pour le cycle de vie des pages et dans la structure du projet. C’est avec l'emploi grandissant d’Angular que le framework est utilisable de manière de plus en plus large. Il est maintenant possible d’utiliser Vue.JS et React par exemple.

Chaque composant graphique est désormais un Web Component, ce qui est rendu possible par l’intégration de Stencil, que je détaille un peu plus loin.
Quelques exemples d’utilisation des composants suite aux changements lors du passage de Ionic 3 à Ionic 4 : https://github.com/ionic-team/ionic/blob/master/angular/BREAKING.md

• IDE

Ionic a développé son propre IDE nommé Ionic Studio afin d'exploiter au mieux tout ce que propose Ionic et ainsi faciliter la vie des développeurs. Il intègre une librairie de composants UI et permet leur modification directement via l’interface. Il facilite également la gestion des plugins Cordova et l’intégration CI/CD avec Appflow.

Malheureusement, l’IDE est uniquement disponible en version entreprise, donc payant (le prix est adapté en fonction de la demande). À sa place, vous pouvez par exemple utiliser l’IDE Visual Studio Code qui dispose d'extensions pour Ionic ou IntelliJ IDEA pour ceux qui ont la version Ultimate (payante).

Avant la création de cet IDE, Ionic a développé l’outil en ligne Ionic Creator. Il permet de construire des interfaces pour les applications Ionic de manière simple et rapide, juste avec le drag & drop. Concernant le prix, il existe 3 formules allant de 0 à 29$ par mois. La version gratuite reste évidemment très limitée.

• La navigation

Ionic 4 dit au revoir à la navigation gérée par NavController. Il utilise maintenant le système de navigation d’Angular (Angular Router). C’est l’une des librairies les plus importantes d’Angular. Utilisée avec Ionic, elle va permettre d’avoir une navigation plus élaborée et de nombreuses animations.

Ionic 3 utilisait une navigation basée sur une simple pile. Les nouvelles pages sont placées en haut de la pile, puis lorsque l’on voulait revenir en arrière, il suffisait de faire un saut à la page précédente.

Avec Ionic, certaines applications peuvent avoir plusieurs navigations en parallèle et donc besoin de plusieurs piles, c’est ce qu’apporte Angular Router.
Une situation souvent rencontrée est l’utilisation des tabs, où l’on peut avoir une navigation différente pour chacune des pages.

Pour plus de détails, c’est par ici : https://ionicframework.com/docs/navigation/angular

• La structure de l’application

Comme souvent lors d’une nouvelle version, il y a des changements dans la structure du projet. Ionic 4 s’appuie beaucoup sur Angular. Pour commencer, nous allons donc créer un projet standard typé Angular avec la commande : ionic start myApp blank --type=angular

Le paramètre --type va permettre au développeur de choisir le type de sa structure. Le type de l'application peut changer, ce qui va modifier la structure du projet pour coller au mieux à ce qui a été choisie.

Dans les exemples ci-dessous, on peut voir la différence de structure pour la même commande avec un type différent.

ionic start myApp --type=ionic-angular ionic start myApp --type=ionic1

• Cycle de vie d’une page

Le cycle de vie d’une page a également évolué. Comme pour la navigation, Ionic 4 se base sur Angular, il est donc maintenant possible d’utiliser ses éléments (ngOnInit, ngOnDestroy ...).

Seuls ces 4 événements sont conservés :

• ionViewWillEnter
• ionViewDidEnter
• ionViewWillLeave
• ionViewDidLeave

Certains événements ont été supprimé. Les voicis avec une alternative Angular :

• ionViewDidLoad > ngOnInit
• ionViewCanEnter > canActivate
• ionViewCanLeave > canDeactivate

Informations supplémentaires : https://medium.com/@paulstelzer/ionic-4-and-the-lifecycle-hooks-4fe9eabb2864

• Web Component & Stencil

Afin d'améliorer la performance de ses composants, Ionic 4 utilise désormais Stencil. C’est un compilateur permettant de générer des Web Components et des PWA. Il a été créé par l’équipe de Ionic. Les composants utilisent Typescript avec un mélange d’Angular et React. Le but est d’ainsi supporter toutes les technologies web front-end.

Stencil et Ionic sont indépendants l’un de l’autre. Il n’est pas obligatoire d’utiliser Stencil avec Ionic. Il est utilisé par défaut, mais il est possible d’employer d’autres alternatives.

Chaque composant est devenu un Web Component afin qu’il soit autonome, réutilisable, personnalisable, et encapsulé dans un tag HTML. En utilisant le Lazy Loading, seuls les composants modifiés se mettent à jour et non toute la page. Ils peuvent ainsi être générés par Stencil ou une toute autre solution.

• Migration

La migration peut être une étape compliquée, mais elle est relativement simple et bien expliquée pour passer de Ionic 3 à Ionic 4.

Si vous avez une application en Ionic 1, il n’y a pas de secret, il faut tout refaire pour obtenir une application en Ionic 4. Comme tout n’a pas radicalement changé depuis Ionic 3 (comme le passage de Ionic 2 à 3), il est possible de migrer l’application sans repartir de zéro.

• Il y a eu un petit changement sur la structure du projet, le déplacement des fichiers au bon endroit suffit.
• La navigation et le Lazy Loading sont à reprendre car ils sont maintenant gérés par système de navigation d’Angular.
• Quelques fonctions du cycle de vie d’une page sont à modifier car 3 d’entre elles ont été supprimées.
• Une montée de version pour RxJS est nécessaire.
• Modifier certains composants (Loading, Toast, ou Alert) car ils sont devenus asynchrones.

Si vous souhaitez migrer votre application, rendez-vous par ici !

• Capacitor

Capacitor est une alternative à Cordova, mais il est encore en version Bêta. Cordova est développé par Apache. Ionic a souhaité créer son propre framework afin de pouvoir proposer une alternative et ainsi répondre à d’autres besoins.

Capacitor permet aux développeurs, comme son équivalent Cordova, de créer une application hybride afin de générer des applications pour Android et iOS (Electron et web également) avec une seule base de code.

Avec Cordova, il est compliqué de mettre les mains dans le code natif de chacune des plateformes car il va justement modifier ce code natif. Capacitor a pris le pari de faciliter l’accès et la modification du code natif pour ne pas être limité aux plugins Ionic existants. Le but est également d’exploiter au mieux les fonctionnalités natives de chacunes des plateformes.  Le code natif des plateformes est indépendant du code “hybride” (HTML, CSS, TypeScript ...) contrairement à Cordova.

Comme l'écosystème Cordova est relativement fourni en plugins (plus de 3 000), Capacitor a donc décidé de supporter une partie de ces plugins. L’installation est juste un peu différente car Capacitor ne modifie normalement pas les fichiers des projets natifs.

Capacitor permet également de choisir le langage utilisé pour le code natif. Swift est employé par défaut pour iOS, mais l’on peut y intégrer de l’Objective-C. Le projet Android est écrit en Java mais supporte Kotlin.

Il est possible de choisir d’utiliser Capacitor lors de la création de l’application ou même de l’installer plus tard.

Pour les curieux, vous pouvez aller jeter un coup d’œil par ici pour Capacitor : https://capacitor.ionicframework.com
Et par là pour la comparaison Cordova/Capacitor : https://ionic.zone/capacitor/overview#comparison-between-cordova-and-capacitor

• AppFlow

AppFlow est une plateforme d’intégration continue (CI) et déploiement continu (CD) pour les développeurs Ionic. AppFlow aide les équipes de développement à créer et soumettre leurs applications Android, iOS et Web bien plus rapidement.

Malheureusement, dans sa version gratuite, il n’est pas possible de générer automatiquement des builds après un push, il faut le faire manuellement. De plus, on ne peut pas non plus générer de packages. Cette fonctionnalité fait partie des formules payantes. Son utilisation est donc très limitée en version gratuite...

Site officiel : https://ionicframework.com/appflow
Documentation : https://ionicframework.com/docs/appflow

• Conclusion

Ionic 4 gagne en performance et en polyvalence. Il est également plus ouvert avec la possibilité d’utiliser Cordova et/ou Capacitor, Stencil, React, Vue.JS… En plus de cette nouvelle version du framework, viennent s’ajouter de nouveaux outils comme un IDE dédié, AppFlow…
Ionic ne cesse de se développer et de faciliter la vie de ses développeurs.

• Sources

https://blog.ionicframework.com/introducing-ionic-4-ionic-for-everyone/
https://ionicframework.com/docs/building/migration/
https://blog.ionicframework.com/let-framework-do-its-job/
https://ionicthemes.com/tutorials/about/ionic-4-vs-ionic-3

Contexte

Aujourd’hui, de nouveaux services font parler d’eux dans le monde de l’IT et principalement lorsque l’on parle de fournisseur de services Cloud, c’est le Serverless.

Vous retrouverez de nombreux articles qui parlent de ce sujet dans sa globalité, comme celui sur “Les Architectures Serverless”.

Aujourd’hui nous nous attaquerons à un sujet bien précis : l’observabilité ; nous verrons ensemble les impacts sur votre conception lorsque l’on applique ces principes aux architectures Serverless.

Petit rappel avant de commencer

Histoire que tout le monde parte avec le même niveau d’information, il me semble important de faire un rappel sur ce qu’est l’observabilité.

L’observabilité est un terme qui possède de nombreuses définitions selon les personnes et les profils. Pour faire simple, cela permet au travers de ses 3 piliers (Traces, Métriques, Journaux d’événements), d’avoir une meilleure visibilité de l’état interne de votre système.

Partons des vérités suivantes:

• votre système n’est jamais totalement sain,
• un système distribué est imprévisible,
• l’échec doit être pris en compte dans chacune de nos phases de développements, de la conception à l’exploitation en passant par les phases de tests et de déploiement,
• votre capacité d’identifier un problème (debug) est un facteur clé de réussite pour la maintenance et l’évolution de votre système.
  

Ceci donne une vision assez représentative de ce que l’observabilité doit apporter et des problématiques qu’elle doit permettre de résoudre.

Étudions plus en détail ces 3 piliers :

Si vous voulez en savoir plus sur la définition de l’observabilité, je vous invite à regarder le talk de Charity Majors ou de lire l’article de Cindy Sridharan sur le sujet.

Les journaux d’événements (logs)

Un journal d’événements est un enregistrement immuable et horodaté d'événements qui se sont produits au fil du temps au sein de votre application. ces événements se présentent généralement sous différents formats (texte en clair, JSON, binaire).

Les données des journaux d’événements ne sont pas utilisées exclusivement pour de l’évaluation de performance ou dans le cadre d’un débogage. Elles peuvent aussi faire l’objet d’une source d’informations pour vos analyses business comme de la veille stratégique ou pour connaître l’utilisation de votre application.

Les métriques

Les métriques sont une représentation numérique des données mesurées sur des intervalles de temps. Elles peuvent exploiter la puissance de la modélisation mathématique et de la prédiction pour obtenir des informations sur le comportement d'un système au fil du temps, dans le présent et le futur.

Puisque les nombres sont optimisés pour le stockage, le traitement, la compression et la récupération, ces données peuvent être conservées plus longtemps et exploitées par des requêtes spécialisées (eg. médianes, moyennes, quantiles, dérivées).  Cela les rend aussi parfaitement adaptées à la création de tableaux de bord reflétant les tendances historiques et peuvent être stockées dans des bases de données dédiées de type Time series. Nous voyons même l’émergence d’algorithmes de type prédictif pour prédire leur comportement.

Avantage des métriques par rapport aux journaux d’événements

Globalement, le principal avantage de la surveillance basée sur des métriques par rapport aux journaux est que, contrairement à la génération et au stockage de journaux, le transfert et le stockage de métriques entraînent une charge constante. Contrairement aux journaux, le coût des métriques n'augmente pas selon le trafic utilisateur ou à toute autre activité du système susceptible d'entraîner une nette augmentation des données.

Ainsi, avec les métriques, même si votre système supporte une charge croissante, cela n'entraînera pas d’augmentation de la complexité du traitement, de la vitesse de visualisation et des coûts opérationnels (license, stockage, …), contrairement aux journaux.

Les métriques sont également mieux adaptées pour déclencher des alertes, car exécuter des requêtes sur une base de données Time series en mémoire est beaucoup plus efficace et plus fiable, que d'exécuter une requête sur un système distribué comme Elasticsearch, puis d'agréger les résultats avant de décider si une alerte doit être déclenchée ou non. D’autant plus que si l’on se base sur les journaux d’événements comme source de métriques systèmes, nous pourrions avoir des erreurs d’interprétations, du simple fait que les valeurs sont agrégées sous forme de moyenne et peuvent ainsi masquer des événements.

Les traces

Une trace est définie comme la représentation d'une série d'événements distribués, liés de manière causale, qui permet de suivre le flux de requêtes de bout en bout sur un système.

Une seule trace peut fournir une visibilité à la fois sur le chemin parcouru par une requête ainsi que sur la structure d'une requête. Ce chemin permet aux développeurs et aux opérationnels de comprendre les différents services impliqués et d’identifier les éventuels points de blocage.

Lorsqu'une requête commence, un ID unique global lui est attribué que l’on nomme souvent ID de corrélation. Celui-ci est ensuite propagé dans tout le chemin de la requête afin que chaque instrumentation puisse insérer ou enrichir les informations avant de transmettre l'ID au saut suivant. Chacun des sauts enregistrera son événement et permettra par la suite de reconstituer le chemin global de la requête à partir de l’identifiant fourni sur l’ensemble des messages.

Nos nouveaux challenges avec le Serverless

Avec les technologies Serverless comme AWS Lambda, nous sommes confrontés à un certain nombre de nouveaux défis pour appliquer ces principes, vu la jeunesse de la technologie et l’inadéquation de certains de nos outils historiques.

Le principal impact de ces services “sans serveur” est justement l’impossibilité d’accès à notre infrastructure sous-jacente et ainsi notre incapacité à déployer notre agent de supervision. Nous ne pourrons plus utiliser nos briques standard pour récupérer, compresser et envoyer nos informations sur notre système d'observabilité. Dorénavant ces fonctionnalités seront incluses directement au sein de chacune de nos fonctions et ne pourront être exploitées qu’au travers des services dédiés fournis par le fournisseur de services Cloud.

Un autre aspect à prendre en compte est justement cet aspect d’exécution unitaire. Sur un système traditionnel, nous devions gérer une quantité d’événements en lien avec le volume de requêtes que ce système (instance) pouvait traiter. Aujourd’hui, vu que nous avons une exécution par requête, cette gestion de la concurrence sera nativement embarquée et gérée par le service lui-même. Nous n’aurons plus à nous soucier de ce type de problématique et c’est une bonne nouvelle. En revanche, vous devrez garder en tête que cela risque d’impacter votre système d’observabilité. Au lieu d’avoir un ensemble d’événements envoyé par paquets, nous aurons des événements unitaires envoyés par chacune de nos fonctions et cette nouvelle charge devra être traitée par votre système et engendrera de nouveaux coûts ou du moins une réévaluation de votre infrastructure.

La transmission d’informations de bout en bout

De nos jours les architectures deviennent de plus en plus complexes. L’une des conséquences de cette complexité est le nombre grandissant d'interactions entre les services.

Voici 2 parfaits exemples d’architecture contenant plus de 500 micro services avec Netflix et Amazon :

Lorsque l’on réalise ce type d’architecture, on se heurte forcément à la problématique de la gestion des journaux d’événements et de notre capacité à garantir un suivi de bout en bout lors de l’exécution d’une requête sur plusieurs services. Ce cas est d’autant plus vrai lorsque l’on parle d’architecture Serverless où chacune de nos fonctions correspond à une entité indépendante. Une autre problématique se trouve aussi sur notre capacité à garantir ce lien au travers des briques d’infrastructures managées parfois méconnues.

Certains services proposent nativement ce genre de fonctionnalité à un certain niveau. Nous prendrons l’exemple ici d’AWS X-Ray qui permet simplement d’avoir une représentation des interactions entre nos services :

Toutefois, ce service n’apporte pas encore toutes les fonctionnalités nécessaires surtout lorsque l’on souhaite investiguer et identifier un problème spécifique dans notre chaîne de traitement. Prenons en exemple un cas réel d’utilisation. Pour ce faire nous utiliserons l’architecture suivante comme modèle :

Cette architecture illustre un cas typique de communication entre plusieurs services métiers composés de différentes briques Serverless. Lorsqu’un développeur va vouloir identifier la cause d’une erreur survenue en production il devra :

• Récupérer les derniers journaux d’événements avec le contexte d’exécution pour analyser les différents entrants et sortants,
• Connaître la chaîne d’exécution de sa requête et possiblement identifier les points de blocages.
  

Dans un contexte Serverless, si vous avez prévu de positionner le flag DEBUG au travers des variables d’environnements, vous arriverez rapidement au problème de la prise en compte de ce changement. Rappelons-le, une fonction bénéficiera de cette mise à jour uniquement lors de la création d’une nouvelle instance ce qui induira un Cold start et donc une latence pour vos utilisateurs finaux. L’autre problème est de devoir pousser cette modification sur l’intégralité de votre chaîne, ce qui selon sa complexité, peut être un travail fastidieux.

Si vous souhaitez mettre en place une solution plus pérenne, la meilleure solution est de passer directement un paramètre au sein de votre requête et de le transmettre sur les différentes briques technologiques. Vous serez alors capable de positionner plusieurs flags comme celui du DEBUG lors de l’envoi de votre requête ou de générer un ID de corrélation lors du premier traitement afin d’avoir un suivi sur l’ensemble de votre chaîne d’exécution. Dans le cas de notre architecture, nous aurions le traitement suivant :

Nous observons que la valeur “debug-enabled” initialisée lors du premier appel API du Service A est transmise au travers de l’ensemble du système à l’identique de notre ID de corrélation “x-correlation-id” généré au sein de la Lambda A.

Maintenant, si nous détaillons un peu plus cette transmission par service, nous avons :

• ApiGateway : comme toute requête HTTP, nous pouvons transmettre ce style de données via les headers de la requête,
• Lambda : les informations sont récupérées directement depuis l’événement source,
• Kinesis : malheureusement, ce service ne permet pas d’ajouter des informations de contexte à nos enregistrements. Pour ce faire, il nous faudra surcharger le contenu des données transmises dans l’élément “Data”,
• SNS : sur ce service, nous pouvons utiliser le champ “MessageAttributes” pour envoyer nos informations.
  

Il vous suffira désormais de récupérer et de fournir le traitement adéquat pour ce type d’information. Vous aurez ainsi la capacité de déclencher le mode DEBUG sur l’ensemble de votre chaîne uniquement via le positionnement du header “debug-enabled” par le développeur. Attention toutefois à ajouter une couche d'autorisation pour éviter tous les abus possibles et générer des coûts non désirés sur votre système d’observabilité.

L’envoi de métriques personnalisées

Il est important de pouvoir récupérer des informations non standard sur l’exécution de nos fonctions, nous prendrons l’exemple de la consommation mémoire et du temps de facturation de notre fonction.

Ces deux valeurs mises en corrélation vont vous permettre d’optimiser votre fonction en trouvant le meilleur ratio mémoire / performance. Prenons l’exemple d’une fonction de 512Mb qui s’exécute en 42ms. Sachant qu’AWS Lambda fonctionne par bloc de 100ms, vous avez une perte de 58ms. Vous pourrez alors réévaluer votre configuration et descendre la mémoire utilisée à 256Mb ce qui aura un impact direct sur votre facture. Un autre avantage d’avoir ce temps de facturation sous forme d’une métrique, est votre capacité à l’intégrer directement dans votre processus de développement voire même dans votre pipeline d’intégration afin d’identifier les augmentations soudaines de complexité de votre code ou un mauvais algorithme. Rappelons-le, l’optimisation de votre code a un impact direct sur votre facture (exemple d’une fonction qui s’exécute en 300ms au lieu de 500ms vous fera réduire votre coût en fin de mois de 40%).

Pour l’extraction, nous nous baserons sur l'approche de Datadog concernant l'envoi de métriques personnalisées vu sa simplicité de mise en place.

Le format

Si nous reprenons l’explication fournie par Datadog au sein de sa documentation, pour envoyer des métriques personnalisées, il faut envoyer un message avec le format DogStatsD.

MONITORING|unix_epoch_timestamp|metric_value|metric_type|my.metric.name|#tag1:value,tag2

où metric_type est soit count, gauge, histogram, ou check.

Vous pouvez également utiliser l'API HTTP de Datadog pour les soumettre à partir de votre fonction Lambda directement.

Extraction des informations

Revenons à nos données. Pour extraire les 2 métriques souhaitées qui sont la mémoire consommée et le temps de facturation, nous allons devoir traiter les journaux d’événements de notre fonction.

Pour rappel, lors de l’exécution d’une fonction AWS Lambda, nous pouvons récupérer la trace suivante :

À la fin de chaque invocation, AWS Lambda publie un message REPORT détaillant la mémoire consommée par votre fonction pendant cette invocation, et votre temps facturé.

Concernant l’extraction, AWS nous permet de créer directement un flux de nos événements et de les traiter par le biais d’une fonction AWS Lambda. Cette fonctionnalité est faite pour agréger nos messages, les traiter et les envoyer à un système d’observabilité.

Et une lambda, une !

Intéressons-nous au code de notre fonction d’extraction. Vous trouverez ci-joint un exemple du code Python pour le traitement de ce rapport, l’extraction des informations et l’envoi sur votre serveur Datadog.

from __future__ import print_function

import base64
import gzip
import json
import os
import re
import boto3

# Imported through Lambda Layer
from datadog import datadog_lambda_wrapper, lambda_metric

# Pass custom tags as environment variable, ensure comma separated, no trailing comma in envvar!
DD_TAGS = os.environ.get("DD_TAGS", "")

class metric:
    def __init__(self):
        self.name = ""
        self.value = 0

@datadog_lambda_wrapper
def lambda_handler(event, context):
    try:
        metrics = awslogs_handler(event, context)
        for metric in metrics:
            for key in metric:
                lambda_metric(convert_snake_case(key.replace('-', '_')), metric[key], tags=[DD_TAGS])
    except Exception as e:
        print("Unexpected exception: {} for event {}".format(str(e), event))

# Handle CloudWatch logs
def awslogs_handler(event, context):
    # Get logs
    logs = json.loads(gzip.decompress(base64.b64decode(event["awslogs"]["data"])))

    # For Lambda logs we want to extract the function name,
    # then use it to generate custom metric name.
    # Start by splitting the log group to get the function name
    log_group_parts = logs["logGroup"].split("/lambda/")
    if len(log_group_parts) > 0:
        function_name = log_group_parts[1].lower()

    # Extract structured custom metric
    for log in logs["logEvents"]:
        if log['message'] and log['message'].startswith('REPORT RequestId:'):
            # Split message based on tabultations
            parts = log['message'].split('\t',5)
            metric = {
                function_name + "_billed_duration": re.findall("Billed Duration: (.*) ms", parts[2])[0],
                function_name + "_memory_used": re.findall("Max Memory Used: (.*) MB", parts[4])[0],
                function_name + "_memory_size": re.findall("Memory Size: (.*) MB", parts[3])[0]
            }
            yield metric

# Convert a name to snake case
def convert_snake_case(name):
    s1 = re.sub('(.)([A-Z][a-z]+)', r'\1_\2', name)
    return re.sub('([a-z0-9])([A-Z])', r'\1_\2', s1).lower()

Vous retrouverez le code ainsi que les scripts pour le déploiement de cette fonction sur mon répertoire Github (https://github.com/stevehouel/datadog-serverless-functions-metrics).

Attention toutefois à vos limites

Je dois vous mettre en garde sur un point : la limite d’exécutions concurrentes. Comme vous devez sûrement le savoir, AWS Lambda est soumis à une soft limit (https://docs.aws.amazon.com/fr_fr/lambda/latest/dg/concurrent-executions.html) qui est de 1000 exécutions simultanées pour l’ensemble de vos fonctions. Selon votre volume de messages et de fonctions, vous pourrez être amené à rapidement l’atteindre. Cependant, l’une des fonctionnalités de ce service vous permet de fixer cette limite par fonction :

Vous pourrez alors maîtriser vos exécutions et ne pas vous retrouver dans le cas d’une panne en cascade de votre système.

Conclusion

Nous l’avons vu, l’observabilité ne peut pas être comparée au simple fait d’ajouter une couche de monitoring à son système. Cela va au-delà, elle doit donner la capacité, au travers de différents types d’informations, d’avoir la connaissance nécessaire à la compréhension de son système ainsi que d’identifier et résoudre les problèmes qui peuvent survenir. Les systèmes basés sur les services Serverless ne dérogent pas à ces règles, la complexité en revanche se trouve dans la jeunesse de son écosystème et de l’intégration des différents outils spécialisés comme Datadog, Espagon, Thundra ou Dashbird avec les fournisseurs de services Cloud.

Toutefois, il y a une réelle mobilisation de la communauté et des entreprises pour rapidement remédier à ces problématiques et apporter toutes les fonctionnalités avancées existantes (Machine Learning, Prédiction de panne, …) et les appliquer aux cas d'utilisations spécifiques du Serverless.

Deux mois avant le départ du Tour de France à Bruxelles, notre consultant Steve Houël se lance dans un fabuleux Tour de France Serverless avec six étapes :

9 mai : Bordeaux à l'Héméra avec Pierre Baillet (DataDog) et l'AWS User Group Bordeaux

14 mai : Nantes à La Cantine avec l'AWS User Group Nantes

21 mai : Toulouse chez Epitech avec Toulouse DevOps

23 mai : Lille chez Décathlon avec le Ch'ti JUG

29 mai : Paris chez DataDog

13 juin : Lyon chez AWS avec l'AWS User Group Lyon

Speaker : Steve Houël
Architecte Cloud chez Ippon, évangéliste Serverless et contributeur sur des projets Open Source comme JHipster et daSWAG. Il est fier d’être un #GeekEnthusiast.

Introduction

Les méthodes agiles offrent aux équipes de développement une grande capacité d’adaptation aux changements et imprévus qui ne manquent pas d’arriver sur un projet. Il peut être question d’opportunités à saisir pour apporter plus de valeur ou d’obstacles ralentissant le projet à surmonter.

L’objectif de cet article est de présenter différents problèmes qui peuvent ralentir la marche d’un projet vers l’objectif fixé et les solutions mises en place pour accélérer cette progression. L’article ne prétend pas être exhaustif. Il met néanmoins le doigt sur des problématiques courantes dans le monde du développement agile.

Cette réflexion est largement inspirée d’une situation réelle. Un projet mené dans un contexte assez tendu. Sans rentrer dans les détails, le projet était en difficulté en matière de budget et de délai.

Contexte

Il s’agit de la refonte d’une application existante qui constitue le cœur même de la stratégie du client. Le besoin de départ a été esquissé en epics qui reprennent globalement les fonctionnalités existantes auxquelles viennent s’ajouter de nouveaux besoins. L’objectif du projet étant de livrer un MVP (Minimum Viable Product) dans un laps de temps relativement court et avec un budget très limité.

En apparence, le projet est mené en mode agile : une équipe Scrum, un backlog du MVP, un développement itératif, une démo à chaque fin de sprint et j’en passe. Sauf que les contraintes imposées au projet à elles seules, à savoir un périmètre, un budget et un délai fixés d’avance, vont à l’encontre de l’agilité. Ce schéma s'apparente en fait à un forfait classique. Sans parler bien sûr des grosses lacunes, pour ne pas dire absences, au niveau du mindset agile chez le client.

Ralentisseurs et accélérateurs

1- Maturité agile

#Ralentisseur

Le client n’est clairement pas agile et cela se voit à travers ses méthodes, ses réactions et ses pratiques au quotidien. Connaître et utiliser quelques termes du référentiel agile ne rend pas une organisation agile !  Du coup, concernant le déroulement du projet, le client n’arrive pas à se détacher ou du moins relativiser des notions comme l’estimation en jours/hommes d’un périmètre ou l’engagement sur un délai et un budget de réalisation fixés d’avance alors que le besoin n’est pas encore complètement défini et détaillé. On se retrouve au final à faire une sorte de forfait déguisé en agile. En fait pas complètement car le périmètre est amené à évoluer forcément lors des échanges sur les User Stories (US) mais sans pouvoir remettre en cause les engagements de départ sur le délai et les charges. Agilité oblige selon ledit client !

#Accélérateur

L’agilité ne se décrète pas. C’est un état d’esprit et une culture qui nécessitent un long processus d’acculturation agile pour pouvoir s’installer au sein d’une organisation et se manifester dans les pratiques quotidiennes. C’est pourquoi, prétendre amener une organisation vers l’agilité le temps de réalisation d’un projet est pure utopie. Par contre, ce qui reste à portée de main, c’est l’injection de petites doses d’agilité dans le projet en question. Mais malgré cela, le projet reste soumis aux fortes contraintes provenant de l’environnement du projet : délai, budget, non alignement des objectifs entre le métier et les sponsors, absence de réactivité et feedback, etc.

Dans ces cas-là, les marges de manœuvres sont très étroites mais restent envisageables. Sensibiliser le client à l’agilité et multiplier les échanges face à face, montrer les gains et les succès durant le projet, cibler les parties prenantes et introduire la vision produit sont de bons exemples d’accélérateurs pour diffuser la culture agile et encourager son adoption. Mais, l’accompagnement de l’organisation par un coach agile reste la démarche la mieux conseillée pour une transition douce et progressive.

2- Rôle du Product Owner (PO)

#Ralentisseur

Le PO est le détenteur de la vision produit au sein de l’équipe. Par conséquent, c’est lui qui fixe le cap des développements. Son rôle est de gérer le backlog produit donc de définir les US et les prioriser pour embarquer le maximum de valeur métier. Il doit s’impliquer entièrement dans le projet, transmettre la vision produit et s'assurer qu'elle est bien comprise par les développeurs, accepter (ou pas) les incréments livrés selon les critères d’acceptation fixés et surtout collecter un feedback rapide pour ajuster le produit.

Si ce rôle n’est pas correctement tenu, il y a fort à parier que le projet dérive. Le cas classique, c’est quand le client désigne comme PO une personne qui n’a rien à voir avec le produit à développer. Le fait d’être un responsable hiérarchique ne changera pas la donne. Quand le PO nommé n’a pas la légitimité au sein de l’organisation ou les compétences et outils requis pour assurer son rôle ou encore manque de temps pour le faire, le produit sera fortement impacté tant sur la définition des besoins métiers et la valeur apportée que sur les délais et charges de développement.

#Accélérateur

Dans ce cas de figure, la réponse la plus objective, c’est d’affecter le rôle de PO à une personne qui a les compétences requises. Si ce besoin est identifié assez tôt en amont, un PO expérimenté pourra rejoindre l'équipe afin de prendre en charge le rôle et sécuriser le développement du produit. Une autre alternative serait de former et coacher le PO pressenti pour lui permettre de monter en compétence tout en sécurisant le projet. Sinon, une solution intermédiaire consistera à faire intervenir ponctuellement un PO expérimenté chez le client pour mener des ateliers de définition du produit et de découpage en US ainsi que la priorisation des développements. Enfin et dans tous les cas, le Scrum Master (SM) doit accompagner le PO en place et l’assister dans sa gestion du backlog produit.

3- Définition du besoin

#Ralentisseur

Face à des contraintes de délai et de budget très fortes, une vision du produit floue ou du moins incomplète, un rôle de PO mal assuré, il est très difficile de travailler dans des conditions sereines et de tenir les engagements sur la livraison. Le problème réside dans le fait que le besoin n’est jamais clair au début. Le PO commence par identifier les grandes lignes du besoin puis les affine au fur et à mesure des ateliers, des échanges et de l'évaluation du produit au cours de sa construction. Le travail de préparation des US par le PO doit être fait en continu et surtout en cohérence avec la cadence des sprints. Il faut alimenter l’équipe de développement avec des US bien définies pour bien avancer et être réactif face à leurs potentielles interrogations. La collaboration entre le PO et l’équipe de développement doit être active et permanente. Un manque de fluidité dans ces échanges aura un impact négatif sur l’avancement du projet.

#Accélérateur

Pour être efficace, il faut dès le début du projet s’investir pour définir les besoins, les prioriser pour apporter plus de valeur et délimiter ainsi le périmètre du MVP à développer. Pour accélérer le processus, il faut mobiliser le client pour faire avec lui des ateliers de définition des US du MVP et les détailler. Un PO expérimenté peut faire la différence lors de cette étape cruciale. Dans ces ateliers, il est indispensable de faire participer des opérationnels métier, des développeurs et un designer UX/UI. Cela permettra d’aligner tous les acteurs sur une vision commune et centrée sur la valeur apportée du MVP à développer, de réduire la perte d’informations en passant par des intermédiaires, de confronter la vision métier à la vision technique et d’avoir un feedback réaliste sur l’utilisation de l’application existante pour mieux comprendre les demandes. Si des besoins nécessitent plus de réflexion et de recul, d’autres ateliers peuvent être envisagés par la suite en cours de développement pour plus de clarification. Dans tous les cas, il faut favoriser le face à face pendant les échanges.

4- Notion de MVP

#Ralentisseur

Un MVP, comme son nom l’indique, signifie un produit couvrant de façon cohérente les besoins minimaux des utilisateurs cibles. L’objectif étant de mettre rapidement à disposition de ces utilisateurs, avec un effort réduit, un produit répondant à leurs principales attentes. Les feedbacks recueillis suite à l'utilisation du MVP permettront de valider (ou non) les hypothèses posées, d'affiner les besoins déjà identifiés ou encore de faire émerger de nouveaux besoins.

Mais dans un contexte de refonte d’une application existante, la question de l’opportunité d’un MVP se pose inéluctablement. Parler d’un MVP pour une application déjà utilisée a-t-il un sens ? En effet, les utilisateurs connaissant et utilisant le produit précédent n'accepteront pas un nouveau produit dégradant le service déjà rendu. Ils ne céderont pas sur le confort déjà acquis. Ce qui conforte le client dans le sens qu’il donne au MVP i.e. au minimum une nouvelle application iso-fonctionnelle à l’application existante. Cette situation pose une contrainte énorme sur le périmètre à réaliser ainsi que sur les délais et charges et réduit considérablement la marge de manœuvre concernant l'implémentation des US.

#Accélérateur

Quand il s’agit de la refonte d’une application existante, il faut bien faire valider l'adéquation entre le périmètre couvert par le MVP proposé et les besoins incontournables des utilisateurs. Une piste à explorer porte sur la possibilité de se délester temporairement de certaines fonctionnalités existantes ou du moins les alléger le temps de réaliser une première version du produit. C’est aussi une bonne opportunité pour revisiter l’application et décider des fonctionnalités à garder ou à supprimer en fonction des besoins à date. Car l’effort et le délai nécessaires pour développer un MVP n’ont rien à voir avec la refonte de toute l’application. Dans ce cas précis, tout l’enjeu est de sortir de ce piège où le client s’attend à avoir dans son MVP toutes les fonctionnalités déjà existantes et dans les délais fixés. Le premier levier à utiliser est la sensibilisation à la définition du concept de MVP. Le deuxième c’est la définition du contenu de ce MVP en tenant compte des contraintes de budget et de délai et en insistant sur les US ayant plus de valeur pour l’utilisateur. Il faut être vigilant quant à la tentation de glisser des fonctionnalités, certes bénéfiques, mais sans réelle valeur ajoutée pour le MVP. Et vu les contraintes de délai, Il ne faut pas hésiter à envisager dans la réalisation des approches simples voire simplistes à partir du moment où elles permettent de répondre aux besoins et ce, conformément au principe KISS (Keep It Simple, Stupid). Par exemple, au niveau de l’interface utilisateur, une stratégie possible pourrait être de recourir à des traitements manuels ou semi manuels pour certaines opérations en back office. Cela réduira énormément l’effort de développement.

5- Travail à distance

#Ralentisseur

L’écriture d’une US n’est pas une fin en soi. C’est plutôt le début d’un échange entre l’équipe de développement et le PO pour comprendre le besoin, identifier les règles de gestion à respecter et documenter les critères d'acceptation qui serviront à valider les développements réalisés. Cela nécessite une communication fluide, qui sera facilitée par la proximité des personnes et un haut niveau d'interactivité. Les acteurs ont besoin d’utiliser des moyens et outils divers et variés pour exprimer leurs idées et les mettre à l’épreuve d’autres idées (montrer une photo ou un schéma, faire un dessin ou un diagramme, reprioriser facilement des sujets en déplaçant quelques post-it, etc.). Toute dynamique de travail se trouve pénalisée lorsque le PO et l’équipe de développement ne sont pas co-localisés. Les échanges à distance perdent en interactivité et donc en qualité d’informations. La communication par téléphone ne se prête pas bien à un travail de co-construction actif et apaisé d’un produit dans un contexte déjà tendu.

#Accélérateur

La communication ne se limite pas à la parole mais s’étend au langage corporel et aux émotions dégagées lors d’un échange. Au téléphone, l’interlocuteur ne perçoit que la parole et la tonalité de la voix. Ce qui peut biaiser la communication et induire en erreur les acteurs au point où certains propos peuvent être mal interprétés et provoquer des crispations. Pour assurer un minimum de proximité et de convivialité, il faut privilégier des outils de communication visuelle comme la visioconférence. Sinon, le face à face reste la meilleure solution pour se parler et travailler ensemble. Par expérience, les échanges entre les personnes sont plus fluides et le risque d’incompréhensions mieux maîtrisé. De plus, les acteurs qui partagent le même espace physique peuvent utiliser plus de moyens et d’outils pour exprimer leurs pensées.

6- Pilotage par les risques

#Ralentisseur

Le client avec de fortes contraintes de délai et de budget a besoin d’être rassuré sur la capacité de l'équipe à livrer le périmètre attendu à la date convenue, ce qui passe  traditionnellement par la fourniture d'une estimation de l'effort à réaliser. Mais avec l’influence de son mindset “cycle en V”, ce chiffrage est accueilli comme un engagement ferme sur un périmètre, un budget et un délai fixes. Or l’équipe de développement ne peut pas s’engager sur un backlog produit dont les items ne sont pas bien définis et qui est amené à bouger au fil des sprints. Si on ajoute à cela tous les ralentisseurs déjà cités, la probabilité de dérive du projet atteint son maximum. Cette situation est potentiellement source d’altération de la confiance client, de stress de l’équipe de développement et d’installation d’un climat de tension et de crispation qui peut facilement dégénérer en conflit.

#Accélérateur

Dans pareil cas, il faut anticiper les difficultés en s’appuyant sur le pilotage par les risques. Il s’agit en somme d’identifier les risques pouvant affecter le bon déroulement du projet, d’évaluer leur impact et de chercher des solutions pour les maîtriser. Plus tôt les risques sont identifiés, mieux c’est pour la prévention des dérives. Ces facteurs de risque doivent être ensuite suivis durant les sprints pour les circonscrire définitivement ou du moins atténuer leurs effets. Il va sans dire que le client doit être impliqué dans la prévention des risques qui le touchent directement.

La roadmap produit peut, à cet effet, révéler certains jalons à haut risque qu’il faudrait suivre de plus près et revoir régulièrement pour les affiner. Et si la durée du projet est courte, alors il est conseillé de partir sur des sprints courts de l’ordre d’une semaine, au maximum deux, pour avoir rapidement des retours utilisateurs permettant de valider ou d’ajuster les développements réalisés.

Conclusion

Chaque projet est unique mais les différents ralentisseurs évoqués dans cet article se retrouvent sur beaucoup de projets. Les accélérateurs proposés ici sont des pistes d’amélioration issues d’un contexte projet bien particulier et ne sont donc pas forcément généralisables. L’essentiel, c’est d’identifier assez tôt ces ralentisseurs pour pouvoir réagir à temps et ajuster le plan d’attaque selon le champ des possibilités offertes, toujours dans une démarche d’amélioration continue.

Mais mieux que cela, le client aura tout à gagner en changeant de posture, i.e. en passant d’une vision projet où on doit livrer un périmètre donné dans un délai convenu à une vision produit où le souci principal est la satisfaction de l’utilisateur final à travers des livraisons fréquentes de valeur, tenant ainsi compte du fait que le produit est appelé à vivre et à évoluer en fonction des besoins de l’utilisateur.

Désolé pour ceux qui pensaient que cet article parlerait de LeBron James, je vais aborder un sujet qui me tient à cœur professionnellement et, malheureusement pour mon compte en banque, je ne suis pas joueur de basket, mais Product Owner.

Je travaille pour une société de conseil (Ippon Technologies) et nous développons des produits numériques pour différentes entreprises. Beaucoup d’entre elles viennent nous consulter avec des idées de produit et en demandant le développement d’un MVP parce qu’elles s’attendent à un produit rapidement en production. Hélas, le périmètre du MVP n’est pas toujours à la hauteur de leurs attentes initiales (la plupart ne sachant pas exactement ce qui se cache derrière le terme MVP) et cela amène à des situations de frustration.

À travers cet article, je souhaite partager avec vous, en quelques minutes, ma vision de ce qu’est un MVP pour clarifier ce concept et éviter les futures incompréhensions.

Le MVP “by the book”

Pour commencer, d’où vient le terme “MVP” ? “MVP” signifie “Minimum Viable Product”. Il a été popularisé par la méthodologie Lean Startup qui le définit comme quelque chose qui “permet à une équipe de récolter un maximum d’apprentissages validés à propos de ses clients en un minimum d’effort.”

Derrière le MVP se cache l’idée de mettre en place une solution, la plus minimale possible (donc pas toujours codée) et mesurer son impact sur les utilisateurs dans le but d’apprendre à propos de sa proposition de valeur, soit en validant l’impact (et donc en continuant à investir), soit en ajustant, soit en pivotant (en revoyant la proposition de valeur). Cette décision, basée sur des données, aide à réduire le risque (et donc le coût) de développer un produit qui ne sera pas utilisé.

Un MVP = une fonctionnalité

“M” comme “Minimum”. La tâche la plus difficile concernant la conception d’un MVP est de définir jusqu’où il est possible d’aller dans la réduction du produit à son minimum. À chaque réduction, si le produit continue à résoudre la problématique pour un type d’utilisateur, alors on peut continuer à essayer de réduire.

Le choix de la fonctionnalité à développer en priorité doit être basé sur des critères d’importance (par rapport à la proposition de valeur) et d’incertitude.

Potentiellement, un MVP peut être abandonné, il faut donc le développer le plus rapidement possible et bien adapter le périmètre et la qualité associée au niveau minimal requis.

Pour comprendre jusqu’où il est possible d’aller, prenons le fameux exemple de Dropbox.

Avant de commencer le développement de la plateforme, Dropbox a publié une vidéo sur Youtube expliquant leur produit, tout en ajoutant un lien en dessous de la vidéo pour ceux intéressés par le service. Pas une ligne de code, juste une vidéo : le moyen le plus simple pour eux de vérifier que des personnes étaient intéressées par ce service, en étant prêt à payer pour cela.
C’est seulement quand ils ont pu confirmer qu’il y avait un attrait du public, qu’ils commencèrent à coder leur service. Quel bénéfice tirer de cette approche ? S’ils avaient commencé à coder et qu’ils s’étaient rendus compte que personne n’était intéressé, alors ils auraient perdu beaucoup plus d’argent et de temps qu’en créant une courte vidéo expliquant leur concept.

L’exemple de Dropbox divise car certains n’y voient pas la notion de version initiale du produit (le “P” de “MVP”). On parle de MVP dans le cas de Dropbox puisqu’on met à disposition de potentiels prospects une présentation (vidéo) du produit et un moyen de valider qu’il y a une attente forte de ces prospects (landing page).

Contrairement à Dropbox, la plupart des MVPs sont bien plus qu’une simple landing page d’un site et une vidéo : ils sont la première pièce du produit final, mais cette première version doit être développée facilement et rapidement. Une technique pour accélérer le développement est celle du “Magicien d’Oz”, consistant à effectuer manuellement des actions qui seront à terme automatisées. Je vous renvoie à l’exemple de Zappos pour avoir plus d’informations sur ce sujet.

Quelques fonctionnalités obligatoires pour une version finale peuvent être absentes (ou réduites) pour un MVP. Avez-vous réellement besoin d’une fonctionnalité de connexion pour valider votre proposition de valeur ? Avez-vous réellement besoin d’automatiser des tâches qui peuvent être faites manuellement ? Avez-vous besoin d’être compatible avec tous les types d’appareils/écrans ? Ce qui est nécessaire pour un MVP (conçu pour adresser des “early adopters”) n’est pas le même que celui pour une première version complète adressant une audience plus large. Souvenez-vous, le premier iPhone n’avait pas de fonction copier-coller. Est-ce que cela a empêché l’iPhone de devenir un succès ?

Procéder à cette réduction de périmètre n’est pas évidente pour le client et s’avère compliquée à comprendre pour ceux ne maîtrisant pas le concept de “Test and Learn” et de développement itératif et incrémental.

Valider l’impact

“V” comme “Viable”. Un MVP est utile pour valider la pertinence d’un produit, donc il est important de savoir quel est le retour sur investissement attendu (ROI). Cela peut être de générer des revenus, aider dans la promotion d’un produit ou d’un service, réduire des coûts ou améliorer l’image de marque.

Les bons produits sont conçus pour avoir un impact positif sur leurs utilisateurs. Le “MVP” est la première étape pour analyser l’impact du produit sur son audience cible. La définition des fonctionnalités d’un MVP doit être liée aux KPIs associés à la vérification de cet impact. Si on revient à l’exemple de Dropbox, le ROI est basé sur la génération de revenus. L’idée du MVP n’était pas seulement de savoir si les gens étaient intéressés par l’utilisation du service, mais surtout s’ils étaient prêts à payer pour cela. Avoir un KPI indiquant que les gens étaient intéressés et un autre indiquant qu’ils n’étaient pas prêts à payer aurait potentiellement pousser Dropbox, non pas à abandonner son projet, mais à repenser son business model.

Transformer un “Minimum Viable Product” en “Most Valuable Product” est facilité par l’adoption d’une approche scientifique basée sur l’observation des comportements des utilisateurs et la validation systématique des impacts au travers de la récolte de données d’usage.

C’est un Produit

“P” comme “Product”. Un MVP doit être une version minimale du produit permettant de valider qu’il répond à un besoin méritant d’être résolu. Cela peut être juste une “landing page” expliquant la proposition de valeur ou un peu plus. Le MVP peut aussi être une version manuelle du futur produit offrant le service (cf la technique du magicien d’Oz vue précédemment) ayant comme unique but de valider l’attraction du service pour une population donnée.

On pourrait dire qu’une maquette ou une démonstration peuvent faire le même travail de validation, mais un MVP est livré en production et visible d’une population plus importante (mais pas trop), dans le but de valider s’il commence à résoudre les problèmes de cette population. Doit-il être accessible par le plus grand nombre ? Cela dépend du contexte, mais il est préférable de se limiter, dans un premier temps, à une audience de “early adopters” qui pourraient être intéressés par la proposition de valeur.
Le produit est alors une “beta version”, il faut donc faire attention à l’image du produit (et de la marque).

Conclusion

Alors que le but d’un POC (Proof of Concept) est de dérisquer la faisabilité technique d’un produit, le but d’un MVP est de dérisquer la problématique business la plus critique de ce produit, et à moindre frais.

Souvent, les incompréhensions reposent sur la définition de “Minimum”. Notre responsabilité en tant que Product Owner/Manager est de réduire autant que possible le périmètre du produit pour récupérer du feedback le plus tôt possible, et en tirer les enseignements conséquents. Penser simple et accepter que tous les cas ne seront pas traités n’est pas toujours facile à faire entendre au client, mais c’est primordial dans la démarche.

Avant de parler de MVP, il faut que tout le monde comprenne en quoi consiste un développement itératif et incrémental. Un MVP est juste une première étape menant à un produit à succès, et il faut être clair avec les parties prenantes sur ce qui va être développé et pourquoi, dans un premier temps, “seulement” ça.

Introduction

Une fin d’après-midi ensoleillé, alors qu’on prenait un Datapéro* avec les collègues, quelqu’un a posé cette question fâcheuse :

« Est-ce que vous connaissez une autre base de données colonne que Cassandra ? »

Question fâcheuse, déjà, parce qu’on était concentrés à trouver qui avait mangé la dernière chips.

Question fâcheuse, ensuite, parce qu’on ne trouvait pas la réponse à une question si évidente. C’est vrai, on entend souvent Java vs C#, AWS vs GCP, Windows vs Linux, Nintendo vs Sony, mais Cassandra vs… ?

Image 1 : Google autocomplétion sur le thème : cassandra vs ...

Les 9 premiers résultats ne sont pas vraiment des bases de données colonne, au mieux des bases de données clés-valeurs. Hbase on connait mais on n’est pas vraiment fans donc on l’omet ici, et voilà qu’apparaît timidement le nom de ScyllaDB.

Ah, mais je connais ScyllaDB ! C’est une base de données colonne migrable de manière transparente depuis Cassandra, bien plus rapide et utilisée par personne.

Il y a quelque chose qui cloche dans ta phrase… Enquête.

Ecosystème

Il était une fois ScyllaDB...

ScyllaDB ça vient d’où ? Pourquoi on n’en parle pas plus ? Deux questions tout à fait pertinentes. L’histoire de ScyllaDB commence en décembre 2014 par une startup du nom de Cloudius Systems. Cette startup spécialisée dans le développement d’applications C++ est à l’origine de deux projets :

• OSv : un OS conçu spécialement pour le cloud permettant de simplifier les stacks utilisées par les VM. C’est une application open source sous licence Apache.
• Seastar : un framework C++ que l’on retrouvera dans ScyllaDB (spoiler alert!). Il promet notamment :
• un networking plus performant en laissant de côté la stack Linux, par l’utilisation de l’intel DPDK qui permet d'accélérer le processing de packet.
• Une amélioration des communications entre threads au sein du CPU en limitant les “Locking operations”.
• La mise en place d’une architecture Shared-nothing (chaque noeud est alors indépendant et autonome dans l'exécution des tâches) permettant une meilleure scalabilité horizontale.

Fort de ses deux précédentes expériences, Cloudius Systems devient ScyllaDB inc. et lance en 2015 ScyllaDB, une base de données open source sous licence Apache, distribué NoSQL orienté colonne faisant directement concurrence à Cassandra. Mis en avant par ses concepteurs comme étant Cassandra mais en C++. Le challenger supporte les mêmes protocoles (CQL, thrift), formats de fichier (SSTable) et peut être facilement interverti avec sa grande soeur.

Des arguments forts...

Par l’utilisation de leur framework maison Seastar et de son architecture Shared-nothing, il devient possible de séparer le jeu de données à processer sur les différents coeurs. Dans cette organisation, les coeurs ne partagent pas la donnée ou la mémoire et les interactions entre coeurs sont donc minimisées. S’associe à cela l’utilisation d’un système asynchrone pour gérer ces interactions, évitant ainsi les opérations bloquantes. Cela permet à ScyllaDB inc. d’annoncer : ”qu’il est nécessaire pour Cassandra d’avoir un cluster 10 fois supérieur en taille pour obtenir des résultats équivalents.”

Cassandra et ScyllaDB peuvent être interchangés. Cette affirmation est peut-être un peu exagérée, néanmoins il est possible en suivant une procédure décrite sur la documentation de ScyllaDB (ici) de bel et bien passer d’un cluster Cassandra à un cluster ScyllaDB. C’est une opération coûteuse en temps mais qui ne nécessite pas, selon la documentation, une indisponibilité du service lors de la migration. En effet, le cluster Cassandra est progressivement remplacé, dans un premier temps en écriture, puis ensuite en lecture.

Mais une visibilité réduite

La promesse semble trop belle pour être vraie ; si un outil si performant existe pourquoi n’est-il pas plus mis en avant ? De nos jours, il est impensable d'utiliser une technologie avec une communauté peu active. D’autant plus lorsque la technologie est open source, cela devient même un facteur de choix lors d’un benchmark. Et ici encore ScyllaDB ne manque pas d’arguments, tout d’abord de nombreux grands clients soutiennent et mettent en avant la solution : Samsung SDS (La branche IT de Samsung) avec un benchmark impressionnant disponible ici. AppNexus, Mogujie, Outbrain, Kenshoo, Olacabs, Investing.com, Eniro, IBM’s Compos pour ne citer qu’eux. Les retours sont unanimes. La solution ScyllaDB propose des performances excellentes même avec les paramètres d’usine, en comparaison au modèle Cassandra qui nécessite d’être optimisé pour en tirer les meilleurs résultats.

Test de popularité sur le sacro-saint Stack Overflow : c’est ici que les choses se compliquent pour ScyllaDB. En effet, l’outil est quasiment absent de la stack. Là où Cassandra tourne autour de 0,10% du total de questions sur le mois et HBase oscille vers 0,5%, ScyllaDB ne représente même pas assez de questions pour être présent dans les trends. Serait-ce dû à une documentation si limpide qu’elle ne laisse pas place aux questions ou bien à une quasi non-utilisation de l’outil hors des grands groupes partenaires ?

Image 2 : Graphe de tendance sur Stack Overflow des tags : Cassandra et HBase, ScyllaDB n’étant pas présent

Une offre triple

Outil open source, ScyllaDB possède une offre community permettant à chacun d’utiliser le service gratuitement. La limitation de l’offre community est sur le nombre de noeuds disponibles (5) pour leur manager de cluster.

Il y a donc en parallèle deux offres disponibles moyennant finance :

• Enterprise, qui propose tout d’abord de pouvoir manager un nombre illimité de clusters par le biais de leur Scylla Manager, et l’accès à un support 24/7. Le pricing quant à lui n’est pas fixe, il est nécessaire de faire une demande au service pour qu’ils évaluent la donnée et qu’ils conviennent d’un prix.
• Cloud, basé sur AWS : Scylla inc. propose également un service managé de leur solution. Celui-ci est optimisé pour les machines i3 de chez AWS et il ne semble pas qu’il y ait la possibilité d’utiliser un autre cloud provider. En ce qui concerne la tarification pour une machine, voici la tarification en location à l’heure et pour une réservation annuelle :

Performance

Maintenant que nous avons une idée de l’offre que propose ScyllaDB, comment expliquent-ils une telle amélioration de performance vis-à-vis de son concurrent direct ?

L’équipe marketing ne sourcille pas : un lien vers leur benchmark est disponible sur leur page d’accueil. Ils nous promettent des performances jusqu’à 10 fois supérieures ainsi qu’une réduction des coûts de serveurs de 2,5 fois sur AWS par rapport à un cluster Cassandra.

2.5X reduction in AWS EC2 costs

Applications using Scylla can perform 10x better and are more reliable

La différence majeure entre Cassandra et ScyllaDB, comme nous le disions plus tôt, c’est le langage utilisé. Cassandra est développée en Java et ScyllaDB en C++. Calmez-vous, on ne parle pas du vieux débat de problème de performance dont souffrait Java avant 1997 et qui entache sa réputation depuis.

Ici, c’est concret : le garbage collector de Java a du mal à gérer les grosses quantités de RAM. Par exemple, pour une machine de 256 Go de RAM il est recommandé pour l’utilisation de Cassandra de limiter le HEAP SIZE à 64Go (Documentation Cassandra). Ce n’est pas un problème en soi car la RAM n’est censée contenir que le tas c’est à dire le contenu des variables. En cas de besoin supplémentaire, il est recommandé d’utiliser un système de cache externe, et c’est là que ça coince.

Une sombre histoire de cache…

Il serait extrêmement lent de lire sur disque à chaque requête sur base de données. Pour optimiser les temps de réponse, Cassandra et ScyllaDB gardent en cache les partitions les plus souvent requêtées (il est désactivé par défaut sur Cassandra mais il reste une bonne idée pour augmenter les performances). Pour rappel, un accès RAM est 50 à 500 fois plus rapide qu’un SSD avec une connectique en PCIe. Ceci étant, en production il est impensable de laisser tourner toute l’infrastructure sur une unique machine. Le réseau devient alors plus limitant que les accès disques.

ScyllaDB utilise un système de Row cache. C’est simplement un tableau associant l’ID de la partition recherchée à la partition.

Pour Cassandra, c’est un système Key cache + Page cache.

Le key cache, stocké dans le tas (RAM allouée à Java), est un tableau associant l’ID de la partition à sa position dans le page cache. Géré nativement par le système d’exploitation, le page cache contient les partitions sous forme de SSTables (Sorted String Tables), une suite de String clé-valeur triés.

Image 3 : A gauche la gestion du cache de Java et à droite celle de ScyllaDB

En déléguant la gestion de son cache au système d’exploitation, Cassandra allège la taille de la RAM à allouer à sa JVM. Cependant, en utilisant un gestionnaire de cache extérieur, la JVM doit sérialiser les objets avant de les mettre en cache, et les désérialiser en sortie, processus qui semble être coûteux.

C’est tout ?

Conceptuellement, ScyllaDB apporte quand même 2 optimisations majeures. La première, c’est l’indépendance des threads. En effet, comme abordé en première partie de cet article, chaque thread se partage un morceau de la mémoire et n’a jamais besoin de communiquer avec les autres threads grâce à l’architecture “Shared-nothing”.

La deuxième optimisation se fait côté réseau. L’utilisation du Data Plane development Kit permet d’améliorer la vitesse de traitement des packets.

Et maintenant ?

ScyllaDB est un challenger agressif face à Cassandra. Par sa compatibilité avec l’existant et ses optimisations techniques, l’outil espère convertir la fanbase les utilisateurs de Cassandra.

La plupart des chiffres évoqués durant cet article ont été avancés par ScyllaDB. Bien qu’ils donnent la méthodologie de benchmark de manière totalement transparente, mon scepticisme couplé à mon 6ème sens d’araignée me poussent tout de même à vouloir vérifier ces affirmations utopiques. Ainsi, préparez-vous dans un prochain article à un benchmark maison des chiffres avancés par ScyllaDB.

En attendant, santé !

* Deux mots sur les Datapéros

Chez Ippon on aime la data et les apéros, du coup on s’est dit pourquoi ne pas mélanger les deux ? Le nom était tout trouvé : les “Datapéros”. On y discute régulièrement de sujets data trendy autour d’un verre. C’est lors de l’un de ces rassemblements, que l’idée de cet article est née.

Aller plus loin

Article ScyllaDB https://www.scylladb.com/product/benchmarks/

Papier ScyllaDB https://www.scylladb.com/wp-content/uploads/datasheet_why-scylladb.pdf

Comparatif Octo https://blog.octo.com/scylladb-contre-cassandra-vers-un-nouveau-mythe/

Article pour ScyllaDB https://medium.freecodecamp.org/scylladb-its-cassandra-but-better-76e3d83a4f81

Cassandra à propos du cache https://docs.datastax.com/en/cassandra/3.0/cassandra/operations/opsConfiguringCaches.html

ScyllaDB à propos du cache https://www.scylladb.com/product/technology/memory-management/

Cassandra EC2 best practices https://aws.amazon.com/blogs/big-data/best-practices-for-running-apache-cassandra-on-amazon-ec2/

Modeling real life workloads with cassandra-stress http://thelastpickle.com/blog/2017/02/08/Modeling-real-life-workloads-with-cassandra-stress.html

Datastax - How (not) to benchmark https://www.datastax.com/dev/blog/how-not-to-benchmark-cassandra

Lorsqu’on est consultant, on a tendance à changer régulièrement d’environnement de travail. Les missions s'enchaînent, on intègre de nouvelles équipes, les visages changent… Et le consultant doit constamment se réadapter à son nouveau lieu de travail et à ses nouveaux collègues.

S'intégrer dans une nouvelle équipe est souvent compliqué et demande beaucoup d'énergie. Nous ne savons jamais comment notre nouveau collègue va réagir si on lui fait une blague, ou si on lui pose une question technique. S’il a tendance à plutôt se soucier des autres ou à être dans sa bulle.

La Process Com (ou Process Communication Model) est un outil de compréhension de la personnalité et un outil de communication pratique et simple. Il permet non seulement de mieux comprendre la personnalité des gens qui nous entourent, mais aussi de mieux assimiler certains points de notre propre personnalité. Il détaille également les différentes options de communication que l’on peut avoir. Le tout sous une forme ludique et pratique qui peut être utilisée au quotidien, que cela soit au travail ou en société.

Le Process Communication Model a été créé au début des années 1980 par Taibi Kahler, un psychologue américain né en 1943 et qui s’est beaucoup intéressé à l’analyse transactionnelle durant sa carrière.

La Process Com est donc un outil utilisable facilement, qui a pour objectif de faciliter les échanges entre personnes dans les situations de communication les plus courantes.

Important : Bien que la Process Com apparaît comme pratique et amusante, il est important de ne pas en abuser et de ne pas en tirer des conclusions hâtives.

Il faut garder en tête que cet outil ne sert ni à manipuler ni à embêter son collègue de bureau en lui dressant un portrait psychologique bancal.

Les 6 types de personnalité

L’un des concepts clés de la Process Communication est de définir 6 grandes catégories de personnalité. Même si chaque individu est bien entendu unique ; lorsque l’on s'intéresse aux comportements humains, on s'aperçoit vite qu’un certain nombre de caractéristiques communes est nettement identifiable.

Ces 6 types de personnalité sont le persévérant, le travaillomane, l’empathique, le promoteur, le rêveur et le rebelle.

Important : il n’y a PAS de mauvaise personnalité. Malgré certains noms qui peuvent paraître péjoratifs, chaque personnalité a ses bons côtés. Et aucune personnalité n’est meilleure qu’une autre.

Les personnalités et le stress

Même si de nos jours, le terme stress peut être fourre-tout, il est défini par un état réactionnel de l’organisme soumis à une agression brusque. Il peut arriver partout dans notre quotidien. Lorsque l’on est en retard, lorsque le métro est bondé… Mais aussi sur notre lieu de travail.

Le stress peut apparaître lorsque les besoins psychologiques ne sont pas satisfaits. La non satisfaction de ces besoins fragilise la personne et la contraint à entrer “en zone de stress” ce qui se traduit par des comportements inadaptés à la situation.  

Chacun des types de personnalité ci-dessous développe une séquence de stress qui lui est propre, de l'état de stress léger (stress de 1er degré) à un stress plus important (stress de 2ème degré). Chacun réagira donc à sa propre manière selon le type de personnalité qui lui correspond.
Au second degré de stress, des comportements d'échec apparaissent selon le type de personnalité. Ces comportements sont inconscients, prévisibles et facilement observables. Il est possible de sortir de ce scénario d'échec à n’importe quel moment, en veillant à satisfaire positivement les besoins psychologiques du type de comportement en échec.

Le travaillomane (thinker)

Le travaillomane est responsable, il travaille de manière logique et organisée. Son efficacité et sa capacité à comprendre lui permettent de briller au travail.

Un pragmatique apprécié pour son sérieux, son sens de l’ordre et son respect des plannings.

Reconnaissez ses compétences et il sera ravi !

Comportement :

Le travaillomane perçoit le monde à travers le filtre de la pensée où il prend plaisir à tout analyser autour de lui.

Pour donner le meilleur de lui-même, il cherche à travailler avec une ou deux personnes maximum.

Il est efficace dans les environnements fonctionnels et ordonnés où chaque chose est à sa place.

Le travaillomane n'hésitera pas à rappeler le timing et l’ordre du jour en réunion pour être sûr que tout reste bien organisé.

Mode de perception et de communication :

Il utilise en priorité des phrases informatifs / interrogatifs qui lui permettent d'échanger des informations ou de poser des questions.

Le travaillomane s’entend difficilement avec un promoteur ou un rebelle.

Son langage exprime avant tout des pensées et bien peu d’émotions.

Pour bien dialoguer avec lui, il ne faut pas hésiter à lui poser des questions et à répondre de façon neutre. Faites attention aux tons directifs et à l'excès d’humour ou d'émotion, ce n’est pas quelque chose que le travaillomane affectionne.

Besoins psychologiques :

Le travaillomane a besoin d'être reconnu pour son travail. Il aime avoir des indicateurs clairs sur son travail et du feedback régulier.

Question existentielle :

Suis-je compétent ?

Cause de stress :

• Aucune reconnaissance de la qualité de son travail
• Environnement de travail chaotique

Réactions sous stress :

• Stress de 1er degré : perfectionniste, ne délègue rien, veut tout faire lui même
• Stress de 2nd degré : sur-contrôle, devient tyrannique avec ceux qui ne sont pas clairs
• Scénario d'échec du travaillomane : “Je ne peux pas m'arrêter tant que” (jusqu'à recevoir la reconnaissance)

Le persévérant (believer)

Le persévérant est une personne de principes. Ses valeurs et ses opinions sont très importantes pour lui. Il est souvent engagé dans des causes qui lui tiennent à cœur.

Plus que la réalisation, c’est sa contribution qui importe. Il a l’habitude d’aller au bout de ses projets et on peut compter sur ses engagements et sa parole.

Pour le satisfaire, faites confiance à son jugement ou demandez-lui son opinion vu qu’il apprécie donner son avis !

Comportement :

Le persévérant perçoit le monde à travers le filtre de ses opinions et de son système de valeurs. Il aime poser des questions et exprimer ses opinions.

Il préfère travailler avec des petits groupes.

Il est également plus efficace dans un environnement sérieux et traditionnel.

Il n’est pas rare de le voir prendre la parole (et de ne pas la lâcher) pour bien argumenter un dossier tant qu’il croit en son projet.

Mode de perception et de communication :

Il utilise en particulier des phrases informatifs / interrogatifs pour transmettre ses convictions.

Il exprime beaucoup son avis et n'hésite pas à poser des questions.

Pour avoir une bonne communication avec lui, utilisez un vocabulaire orienté sur les valeurs et les opinions (vous pouvez même lui faire plaisir en lui demandant les siennes). Les émotions sont toutefois à éviter avec un persévérant. Evitez également de lui couper la parole.

Besoins psychologiques :

Le persévérant a besoin d'être reconnu pour ses valeurs et ses opinions mais également pour le travail qu’il accomplit. Il recherche les environnements sérieux et traditionnels qui respectent les normes personnelles, culturelles et professionnelles.

Question existentielle :

Suis-je digne de confiance ?

Cause de stress :

• Aucune reconnaissance de ses opinions

Réactions sous stress :

• Stress de 1er degré : critique les autres, se focalise sur le négatif
• Stress de 2nd degré : développe un côté paranoïaque, part en “croisade” (cherche à imposer son point de vue)
• Scénario d'échec du persévérant : “Je ne peux pas m'arrêter tant que” (jusqu'à recevoir la reconnaissance)

Le rebelle (funster)

Le rebelle est loin d'être prévisible. Il aime se faire remarquer de par son originalité et en amusant les autres.

Plutôt individualiste, il a néanmoins besoin des autres pour s’exprimer. Le rebelle vit l’instant présent, et tout cela sans filtre.

Faites-lui une blague, ça lui fera plaisir !

Comportement :

Le rebelle voit le monde à travers le filtre de la réaction.

Il aime le travail en groupe dans un environnement riche en contacts stimulants, cela booste son efficacité.

Enthousiaste et fun, il aime lancer des blagues dans l’open space en utilisant un langage familier ou des onomatopées.

Mode de perception et de communication :

Il aime échanger des émotions avec son interlocuteur pour susciter des réactions.

Le rebelle est du genre à dire tout de suite ce qu’il adore et même ce qu’il déteste. Il est très spontané.

Pour avoir une bonne communication avec un rebelle, il faut essayer d'être amusant, de plaisanter en plus d'être décontracté et spontané. Evitez de lui imposer des contraintes, il les déteste.

Besoins psychologiques :

Le rebelle recherche des contacts ludiques pour se procurer de l’amusement. Il est plus à l’aise dans un environnement décontracté, où il n’y a pas de contraintes.

Question existentielle :

Suis-je acceptable ?

Cause de stress :

• Aucun contact / aucun amusement
• Trop de contraintes

Réactions sous stress :

• Stress de 1er degré : soupire, râle, ne comprend plus rien, invite les autres à faire à sa place
• Stress de 2nd degré : blâme les autres, fait preuve de mauvaise foi
• Scénario d'échec du rebelle : “Quoi que je fasse je suis toujours coincé”

Empathique (Harmonizer)

L’empathique prend soin des autres et de l’ambiance de son groupe. Il est connecté à ses émotions et les utilise pour se positionner par rapport au monde.

Se sentir aimé est tout ce qu’il lui faut pour être heureux.

Comportement :

L’empathique perçoit le monde selon le filtre des émotions.

Il aime travailler en groupe.

Souvent souriant, l’empathique recherche des ambiances bienveillantes dans un décor sympathique pour travailler. Il est attentif aux autres et inspire souvent confiance : c’est celui qui met de l’harmonie dans le service. Il aime à ce que l’on valorise sa personne plus que ses résultats.

L’empathique aura souvent un décor personnalisé à son bureau (photos de famille, affiche au mur ...)

Mode de perception et de communication :

Son langage exprime de nombreux sentiments et beaucoup d'émotions. Il perçoit le monde qui l’entoure avant tout par ses ressentis.

Pour bien dialoguer avec un empathique, il est important de se montrer compréhensif à ce qu’il ressent, vu que l’attention personnalisée est importante pour lui.

S'intéresser authentiquement à lui, lui montrer de l’encouragement face à ses difficultés et lui assurer votre disponibilité sont les clés pour être sur la bonne longueur d’onde avec cette personnalité.

Besoins psychologiques :

L’empathique souhaite se sentir aimé pour sa personne et non pour son travail ou ses opinions. Le tout dans un environnement agréable et bienveillant.

La satisfaction des besoins sensoriels est également très importante pour lui (voir, entendre, sentir, goûter).

Question existentielle :

Suis-je aimable ?

Cause de stress :

• Pas de reconnaissance en tant que personne
• Environnement de travail peu agréable sur le plan sensoriel

Réactions sous stress :

• Stress de 1er degré : sur-adaptation pour faire plaisir aux autres, en fait trop
• Stress de 2nd degré : fait des erreurs stupides et inhabituelles, se victimise
• Scénario d'échec de l’empathique : “Tôt ou tard quelque chose de mal va arriver”

Promoteur (Doer)

Le promoteur est un fonceur. Il adore les challenges qu’il n'hésite pas à accepter (même si parfois il n’a aucune idée de comment les réaliser). Chez lui, c’est l’action et l'efficacité qui importent. Persuasif, il peut réveiller et entraîner l'équipe avec qui il travaille.

C’est la personne idéale à inviter à courir un marathon si vous êtes sans partenaire d'entraînement.

Comportement :

Le promoteur perçoit le monde selon le filtre de l’action.

Il peut travailler seul ou en groupe vu son adaptabilité.

Il aime les défis, les résultats immédiats et les situations à haut degré d'énergie. Il cherche à travailler avec des personnes qui vont droit au but.

Il n’est pas rare de le voir prendre des risques ou de vouloir travailler sur les projets les plus difficiles.

Mode de perception et de communication :

Le promoteur utilise souvent l'impératif et invite à agir.

Il n’exprime pas ses sentiments, de peur de les considérer comme un signe de faiblesse.

Pour avoir une bonne communication avec lui, il faut rester ferme et aller droit au but. Ne pas hésiter par exemple à lui proposer des actions.

Besoins psychologiques :

Le promoteur a constamment besoin d’excitation. Il recherche les sensations fortes, le défi, le concret. Donnez-lui une mission difficile, il mettra tout en œuvre pour y arriver.

Question existentielle :

Suis-je vivant ?

Cause de stress :

• Pas de défi / d’excitation
• Pas assez d’action

Réactions sous stress :

• Stress de 1er degré : n’apporte aucun soutien (attend que les autres se débrouillent tout seuls)
• Stress de 2nd degré : manipulation, prend des risques (santé, sécurité, affaires)
• Scénario d'échec du promoteur : “Je ne vais pas me laisser coincer comme ça”

Rêveur (Imaginer)

Le rêveur est un grand penseur. Il est doué d’un fort pouvoir de concentration, d’imagination et d’introspection.

Son recul et son imagination lui permettent de modéliser des idées très complexes.

Néanmoins, d’un point de vue extérieur, le rêveur peut être vite considéré comme “dans la lune”.

Assurez-lui de la tranquillité et il vous remerciera.

Comportement :

Le rêveur perçoit le monde selon le filtre de l’inaction.

Il préfère travailler dans un coin isolé et tranquille pour être plus efficace.

Il a une attitude réservée, d’apparence sereine, il recherche peu l’interaction.

Pour travailler de façon efficace, le rêveur doit se trouver dans un bureau isolé et tranquille.

Il peut parfois ne pas finir ses phrases (ou alors dans sa tête).

Mode de perception et de communication :

Le rêveur s’exprime peu et répond de façon informative et neutre, sans exprimer ses sentiments.

Le rêveur prend rarement l’initiative et préfère attendre des directives claires et précises pour se mettre au travail.

Le meilleur moyen de communiquer avec lui et d’avoir des échanges brefs et précis.

Besoins psychologiques :

Le rêveur a un besoin psychologique de temps et de solitude. Lui laisser du temps et respecter sa solitude sont des choses qui ont tendance à le booster.

Question existentielle :

Suis-je voulu ?

Cause de stress :

• Pas de temps pour l’introspection
• Environnement de travail ne lui permettant pas de s’isoler

Réactions sous stress :

• Stress de 1er degré : passif, replié sur lui même
• Stress de 2nd degré : attend passivement, transparent physiquement
• Scénario d'échec du rêveur : “Je n'obtiens jamais ce que je désire le plus”

Communication avec les autres

En psychologie, un canal de communication est une structure cognitive et sensorielle qui relie le sujet à son environnement, et notamment aux autres sujets.

Chaque type de personnalité utilise un canal privilégié pour parler. Afin de communiquer au mieux avec une personne il conviendra de s’exprimer en utilisant son canal.

Il existe 5 canaux de communication différents.

Le canal directif

C’est un canal qui vise l'efficacité. On y donne des ordres sans nuance affective. Pour être efficace la directive sera donnée avec des verbes à l'impératif, sans émotions.

Exemples :

“Laisse-moi t’aider”

“Apportez-moi ce rapport”

C’est le canal privilégié des promoteurs, et il est également efficace lorsqu’on s’adresse à des rêveurs. Même s’il n’y a pas de volonté agressive cachée dans ce canal, il est à éviter avec tous les autres types de personnalité qui ne le supportent que très modérément.

Le canal interrogatif / informatif

C’est le canal où on échange des informations, où l’on pose des questions. L'échange est fait sous forme de questions, mais sans agressivité ni colère. Cela déclenche une réaction sous forme d’informations, d’actions ou de nouvelles questions.

Exemples :

“Où as tu mis le rapport X ?”

“Avez vous 15 minutes à m’accorder ?”

C’est le canal privilégié des travaillomanes, des persévérants et des rêveurs (lorsque ces derniers s’expriment). Dans le doute, c’est le canal qui fonctionne avec TOUS les types de personnalité.

Le canal nourricier

C’est un canal chaleureux qui vise à ce que l’interlocuteur se sente bien en apportant de l’attention ou des compliments. Pour que le message soit efficace, sans être perçu comme de la manipulation, il faut qu’il soit exprimé avec la plus grande sincérité.

Exemples :

“Je suis heureux de travailler avec vous”

“Je suis là pour toi, je vais t’aider”

C’est le canal utilisé par les empathiques.

A éviter avec les autres types de personnalités. Les persévérants et travaillomanes vont considérer que ce canal, trop flatteur, n’est pas approprié au travail. Pour les promoteurs, il peut être perçu comme l’expression d’une faiblesse. Quant au rêveur, il risque de se sentir étouffé par ces invasions de bienveillance.

Le canal émotif / ludique

Le canal émotif est celui de l'échange et de l’expression des émotions. Il vise les émotions de l’interlocuteur en suscitant des réactions.

C’est un mode de communication ludique et spontané, avec des plaisanteries, des jeux de mots, des mimiques… Pour nous permettre de travailler en s’amusant.

Exemples :

“Allez, je te file un coup de main ;)”

“Trop cool ce nouveau projet”

C’est le canal privilégié des rebelles pour d’autres rebelles. Il prépare les conditions relationnelles d’un travail efficace.
Les travaillomanes et persévérants peuvent trouver ce mode de communication trop superficiel dans un cadre professionnel.

Le canal interruptif

C’est un canal un peu particulier. Il permet d’intervenir fermement quand la communication ne se fait pas bien. Il est à utiliser lorsqu’un individu perd le contrôle de lui même, lorsqu’une réaction rapide est nécessaire. Il vise à interrompre rapidement des états de profonde confusion, de stress profond ou de panique.

Ici l’utilisation d’un verbe à l'impératif s’adressant aux cinq sens de l’interlocuteur est la seule chose dont on ait besoin.

C’est une invitation ferme et bienveillante à reprendre contact avec le monde extérieur pour interrompre un état interne très inconfortable.

Exemples :

“Ecoute-moi”

“Bois un verre d’eau”

Structure de la personnalité

Les 6 types de personnalité sont tous présents en nous. Il nous est possible de les solliciter et de nous exprimer avec leurs forces et leurs faiblesses. Certaines personnalités, moins familières, demandent plus d’effort et d'énergie à les utiliser.

La Process Com explique la structure de la personnalité en utilisant la métaphore de l’immeuble. Un immeuble de 6 étages (qui correspondent aux 6 types de personnalités) avec un ascenseur pour accéder aux différents étages mais aussi avec une cave et un sous sol.

Important : Il n’y a ni bon, ni mauvais immeuble de personnalité. Chaque immeuble correspond à une personne et à son chemin de vie.

Rez de chaussée : la base

Le rez de chaussée de cet immeuble correspond à notre personnalité de base. C’est la personnalité première, fixée en nous. Cette personnalité est innée ou acquise lors de la petite enfance (jusqu'à 7 ans).

Cette base restera notre base pour toute la vie. Il n’est donc pas possible qu’au cours de notre existence, la base de notre immeuble de personnalité change.

Cette base est la personnalité la plus utilisée. Le langage que l’on utilise au quotidien et la manière dont on perçoit le monde sont directement liés à celle-ci.

Nous avons donc tendance à nous y réfugier facilement, vu que c’est dans ce type de personnalité que nous nous sommes construits historiquement.

Les étages : la phase

Au travail, ou dans la vie privée, nous rencontrons parfois des événements marquants (reconversion professionnelle, mariage...) qui peuvent influer directement sur nos choix et notre motivation de vie. Souvent, ces changements drastiques nous font également entrer dans une nouvelle phase de personnalité.

Cette entrée dans une nouvelle phase ne modifie en rien notre base. Nous gardons les traits de personnalité associés à notre socle, mais nous sommes naturellement attirés par l’approche d’un autre type de personnalité.

Nous développerons ces nouveaux traits de personnalités pendant toute la durée de la nouvelle phase. Une phase dure au minimum quelques mois mais peut également durer une vie entière.

Certaines personnes ne changent même jamais de phase, d’autres traversent les 6, selon les événements vécus.

La phase correspond donc à l'étage du type de personnalité en développement dans notre vie actuelle.

L'ascenseur : le changement d'étage

Lors d’un échange relationnel (au travail ou dans la vie privée) nous pouvons décider de changer provisoirement d'étage afin de pouvoir établir un échange sain avec notre interlocuteur.

Plus un type de personnalité est en hauteur dans notre immeuble plus il est “difficile” pour nous d’y rester (plus l'étage est haut moins nous l’avons développé). Ce type de personnalité s’accompagnera d’un ressenti de stress inconfortable et rester à ce niveau dans le temps réduira considérablement notre énergie d’adaptation.

La cave et le sous-sol : les degrés de stress

Ici la cave correspond au premier degré de stress d’un type de personnalité (en premier le stress de la base puis de la phase en cours).
Le deuxième degré correspond à son second degré de stress (en premier le stress de la base puis de la phase en cours).

Conclusion

La Process Com est un outil pratique, simple d’utilisation, qui permet de mieux comprendre les personnes qui nous entourent, mais également nous-mêmes.

Il peut aider à communiquer dans les meilleurs conditions et à éviter ou déverrouiller les situations de stress de la vie quotidienne.

Il faut néanmoins noter que le Process Communication Model est une modélisation et non une représentation exhaustive de la nature humaine, c’est donc un modèle à utiliser avec parcimonie.

La lame de fond Cloud touche tous les domaines et il n’y a pas de raison que le Data Warehouse y échappe.

Les Data Warehouses classiques ne sont pas bien adaptés pour le Cloud, c’est pourquoi des solutions spécifiques ont vu le jour.

Les principaux acteurs du Cloud public proposent chacun leur propre solution :

• AWS Redshift
• Azure SQL Data Warehouse
• Google BigQuery

Dans cet article nous allons comparer deux des systèmes les plus en vue du moment : Amazon Redshift et Snowflake.

Avantages du Cloud par rapport à un SI On-premise :

• Pas d’achat de matériel,
• Rapidité de mise en œuvre,
• Scalabilité quasi-infinie,
• Maintenance simplifiée,
• Coût maîtrisé.

Ce dernier point est crucial car le coût d’une infrastructure est souvent caché (matériel, humain, licence, …).

En plus des avantages vus précédemment, les services entièrement gérés vous facilitent la gestion des serveurs et des mises à jour logiciels. Leur version la plus aboutie, les services serverless, vous masquent complètement les serveurs et les logiciels utilisés et vous permettent d’obtenir une facturation à la seconde et vous ne payez que ce que vous consommez.

Définition d’un Data Warehouse

Afin de mieux comparer les solutions, il faut d’abord en comprendre le but.

Un Data Warehouse va regrouper une partie (le plus étant le mieux) des données métiers d’une entreprise, fournir les outils capables de les analyser et de construire des rapports, afin de favoriser la prise de décisions dans l’entreprise.

Un Data Warehouse est assez proche d’une base de données relationnelles classiques, mais là où un SGBDR va favoriser les transactions (OLTP), le Data Warehouse va favoriser les traitements d’analyse de données (OLAP).

Il y a donc trois éléments essentiels :

1. La capacité à ingérer des données,
2. La capacité à stocker des données,
3. La capacité à analyser des données.

Il permet de regrouper à un seul endroit les données et de ne pas perturber les bases opérationnelles avec des traitements lourds et complexes.

Différence avec un Data Lake ?

La confusion entre les deux est courante au point de retrouver les deux termes dans une même conversation, un même document.

Là où un Data Lake va stocker les données au format brut, le Data Warehouse va stocker des données structurées, agrégées et souvent regroupées par usage.

Les utilisateurs diffèrent aussi : Data Scientist, Data Engineer contre statisticien, actuaire, spécialiste métier.

Un Data Warehouse va être souvent couplé à un outil de transformation de données appelé ETL (Extract Transform Load) afin d’appliquer un schéma aux données avant leur insertion (schema-on-write).

A l’inverse, un Datalake ingère des données bruts et le schéma est appliqué à la lecture des données (schema-on-read).

Les Data Warehouse vont souvent proposer une modélisation en étoile ou en flocons (snowflakes), qui sont en partie dénormalisés.

Les Data Lake, car ils stockent les données au format brut et tels que fournis par la source, sont très souvent dénormalisés.

Sans entrer dans le détail, le modèle en étoile permet de réduire le nombre de jointures lors de l’interrogation en plaçant au centre du modèle les données variables (les faits) et tout autour les référentiels (les dimensions) ce qui le rend particulièrement optimisé pour les requêtes d'analyse.

Le modèle en flocons est une variante de la modélisation en étoile qui introduit la notion de hiérarchies de dimensions, de telle manière à avoir moins de lignes par dimensions.

C’est évidemment la théorie et la frontière est beaucoup plus perméable en réalité.

Présentation d’Amazon Redshift

Amazon Redshift a été annoncé en décembre 2012 et réellement disponible début 2013. La technologie s’appuie sur le produit ParAccel dont Amazon était un investisseur important.

Techniquement Amazon Redshift est basé sur PostgreSQL version 8 mais les différences sont nombreuses et il faut surtout retenir la compatibilité SQL et de certains outils.

Stockage

Le stockage d’Amazon Redshift diffère de manière importante par rapport à PostgreSQL dont il s’inspire. Redshift est une base de données orientée colonnes et par conséquent les données sont découpées en slices qui représentent un nombre de lignes d’une colonne plutôt que par lignes d’une table.

Les données peuvent être compressées et réparties sur l’ensemble des nœuds du cluster.

Les algorithmes de répartition des données au sein des nœuds proposés sont :

1. Even (Round Robin) : les données sont réparties sans affinité,
2. All : tous les nœuds portent l’ensemble des données,
3. Key : la clé de la ligne détermine le nœud de stockage.
4. Auto : Redshift détermine la meilleure répartition en fonction du type de données et de la volumétrie.

De plus pour chaque table, il est possible de définir une clé de tri (Sort Key).

Par défaut les données ne sont pas compressées, mais il est possible de définir un algorithme pour chaque colonne.

Les formats supportés sont nombreux car beaucoup sont spécialisés dans un certain type de donnée. On peut citer : Binaire, LZO, Mostlyn, …

Cf. https://docs.aws.amazon.com/redshift/latest/dg/c_Compression_encodings.html

À noter que même activée, la compression n’est pas systématique et Redshift analyse la volumétrie afin de déterminer si la compression est pertinente (ratio entre la consommation CPU, le temps nécessaire à la compression et le gain de stockage).

Enfin l’espace de stockage est découpé en slices. Le nombre de slices est figé et dépend de la classe d’instance des nœuds du cluster.

Par exemple un nœud de type ds2.8xlarge disposera de 16 slices.

De manière globale la taille des slices est la suivante :

• 1 To pour les nœuds de type Dense Storage,
• 80 Go pour les nœuds de type Dense Compute.

Capacité maximale de stockage :

• 128 nœuds,
• 10 clusters,
• 2,56 To par nœud,

soit 3,2 Po au total.

Pour faire évoluer la capacité de stockage ou de traitement de votre cluster, vous devez invariablement rajouter des nœuds. On ne peut pas faire évoluer une capacité sans l’autre.

Format des données supportées

Nativement Redshift ne supporte que les données structurées, dont le schéma est défini par SQL et stockées dans un format propriétaire.

Il est toutefois possible de pointer vers des données stockées dans S3 au format JSON et Ion.

Ion est une extension du format JSON développée par Amazon

Modélisation

Même si Redshift est une base orientée colonnes, cela ne transparaît pas dans la modélisation qui reste comparable à PostgreSQL.

Des ordres SQL (syntaxe PostgreSQL) permettent de créer des tables, des clés étrangères, des vues.

Métadonnées

Tout comme PostgreSQL les métadonnées sont stockées dans des tables systèmes (catalogue).

Les tables catalogue système ont un préfixe PG et sont requêtables.

En cas de données externes (Spectrum par exemple) la table pg_external_schema pointe vers les schémas sources (Athena ou Hive).

Traitements

Analyse des données

Les opérations sur les données sont exprimées en ordres SQL.

Redshift parallélise les traitements en utilisant le MPP (Massively Parallel Processing) à l’exception de certaines requêtes portant sur des métadonnées qui sont exécutées par un seul nœud : le leader.

Redshift va favoriser la co-localisation des traitements et des données et c’est pourquoi le choix d’une clé de distribution performante est très important.

Import de données

L’import de données en masse (commande COPY) est possible depuis :

• S3,
• DynamoDB,
• EMR,
• Tunnel SSH pour un hôte distant.

Les formats suivants sont supportés : AVRO, CSV, JSON, Parquet, ORC et TXT.

L’import de données utilise l’architecture hautement parallèle de Redshift afin de multiplier les imports concurrents en se basant sur la clé de distribution et le nombre de fichiers en entrée.

Export de données

L’export de données (commande UNLOAD) est possible vers S3 avec ou sans chiffrement des données.

Une requête SQL permet de sélectionner les données à exporter.

Les formats de sortie sont CSV ou TSV.

Un fichier ne peut pas excéder 6,2 Go ou une valeur définie par l’utilisateur.

L’export de données utilise l’architecture hautement parallèle de Redshift afin de multiplier les exports concurrents en se basant sur le nombre de slices.

Redshift Spectrum

Redshift Spectrum, annoncé en avril 2017, permet de requêter des données externes, c’est à dire stockées dans S3, sans avoir à les charger dans des tables Redshift.

Le même langage SQL et les mêmes drivers de connexion seront utilisés, ce qui permet d’utiliser les mêmes outils pour consommer les données qu’elles soient stockées dans tables Redshift ou à l’extérieur.

Redshift Spectrum est excellent moyen pour les requêtes ponctuelles de forte volumétrie qui nécessiteraient de sur-dimensionner le cluster.

Pour décrire les données externes, on peut s’appuyer le data catalog d’AWS Glue, celui d’Amazon Athena ou un Hive Metastore.

Interfaçage

Données

L’accès aux données se fait soit avec un client compatible PostgreSQL, soit au travers des drivers JDBC et ODBC.

L’accès peut donc se faire grâce :

• à un éditeur SQL,
• au client psql,
• à une application (Java, .Net, Python, NodeJS, GO),
• à des frameworks compatibles (Spark, Flink, …),
• aux outils de BI ou d’analytiques.

Administration

En ce qui concerne le management, Redshift est accessible avec les outils suivants :

• AWS Cli : outils d’administration en ligne de commande,
• Redshift API : Acces REST pour l’administration d’un cluster Redshift,
• AWS SDK : SDK (Java et Python),
• outil pgAdmin.

Sauvegarde et restauration

La sauvegarde des données peut être automatisée :

• Toutes les 8 heures,
• Tous les 5 Go de données.

Par défaut la période de rétention est courte : une journée.

Ces snapshots sont conservés dans S3.

La restauration est simple puisqu’il suffit de sélectionner un snapshot à restaurer.

Architecture

Un cluster Amazon Redshift est constitué de deux types de nœuds.

Un nœud principal (Leader) :

• Sert uniquement de point d'accès SQL,
• Stocke les métadonnées,
• Optimise le plan d'exécution,
• Coordonne le bon déroulement des requêtes.

Des noeuds de traitement (Compute) :

• Stockage local des données au format colonne
• Exécution distribuées :
• Des requêtes,
• Des imports/exports,
• Des sauvegardes/restaurations,
• Des redimensionnements (redistribution des données).

Un cluster Redshift peut être constitué d’un seul nœud qui jouera alors les deux rôles.

Si plusieurs noeuds sont utilisés, le leader n’est pas facturé.

Elasticité

En novembre 2018, AWS a annoncé la fonctionnalité Elastic Resize. Elle permet d’ajouter ou supprimer des nœuds en quelques minutes.

Lorsqu’une opération d’Elastic Resize est lancée :

• un snapshot est créé,
• le cluster redistribue ses metadata sur tous les nœuds, ce qui le rend inaccessible pendant quelques minutes,
• puis les sessions sont reconnectées,
• et les données sont finalement redistribuées sur tous les nœuds en tâche de fond.

Présentation Snowflake

Snowflake a été créé en 2012 par deux ingénieurs Français qui étaient Lead Architects chez Oracle Teradata. Il a été développé pendant 3 ans puis mis sur le marché en 2015 uniquement sur AWS dans un premier temps (lancement sur Azure en janvier 2019).

Ils avaient sans doute compris avant les autres l’apport du Cloud pour les plateformes analytiques :

1. Un nombre quasi-infini de ressources,
2. Élasticité sans pareil grâce à la séparation du stockage et du compute, et ce en leur évitant d'avoir à provisionner et administrer des machines,
3. Une amélioration continue du produit (Snowflake revendique une version par semaine).

Snowflake a ouvert une filiale française en novembre 2017.

Région Européennes proposées :

• AWS : Francfort & Dublin,
• Azure : Pays-Bas.

Stockage

Snowflake n’intègre pas de stockage et s’appuie donc sur le datastore natif du fournisseur Cloud (S3, Azure Blob Storage).

De plus, il utilise des micro-partitions pour des raisons de disponibilité, de performances et de sécurité.

La taille de ces micro-partitions est comprise entre 50 et 500 Mo avant compression.

Tout comme Redshift, Snowflake est une base de données orientée colonnes. Les données sont donc regroupées par colonnes dans chaque micro-partition.

Les données sont automatiquement compressées par Snowflake qui détermine l’algorithme le plus adapté en fonction du type et de la volumétrie. Le facteur de compression varie de 3 à 5.

La jonction entre le stockage et les services Snowflake (traitements, métadonnées, …) se fait grâce à un service nommé Snowpipe.

Snowpipe est un service REST qui permet à Snowflake d’avertir de l’arrivée de nouvelles données.

La capacité de stockage est infinie car basée sur S3/Azure (mais 128 * 10 nœuds de traitement).

Format des données supportées

Les formats suivants sont nativement supportés : JSON, AVRO ou XML.

Modélisation

Tout comme Redshift, Snowflake est une base orientée colonnes et la modélisation se fait à travers la création de bases, de tables et de vues.

Métadonnées

À l’image des bases de données relationnelles, les méta-données sont stockées dans des tables et des vues systèmes.

Ces objets sont basés sur la norme SQL-92 Information Schema sans être toutefois entièrement compatibles.

Ces informations sont communes à l’ensemble des entrepôts virtuels et sont requêtables comme n’importe quelle donnée.

Traitement

Analyse des données

Les opérations sur les données sont exprimées en ordres SQL.

Snowflake parallélise les traitements en utilisant l’architecture MPP.

Snowflake dépend d’un stockage commun distant et l’affectation (pour traitement) des données au sein des nœuds d’un cluster utilise les micro-partitions.

Les micro-partitions sont créées à l’aide de la clé de partition (cluster keys) définie au moment de la création de la table.

La clé de partition est un élément fondamentale du bon fonctionnement de Snowflake et doit faire l’objet d’une attention particulière afin de favoriser :

• l’homogénéité de la répartition des données,
• la co-localisation des données stockées dans différentes tables mais liées d’un point de vue métier.

Import de données

L’import de données en masse (commande COPY INTO ou Snowpipe) est possible depuis :

• S3,
• Azure,
• fichiers d’un hôte distant (en passant par des stages).

Un traitement Snowpipe est lancé depuis une interface REST et peut s’intégrer à AWS Lambda.

Les formats suivants sont supportés : AVRO, CSV, TSV, JSON, Parquet, ORC et XML.

Les fichiers peuvent être dans une archive GZIP (mais un seul schéma de table par archive pour le moment).

L’import de données utilise l’architecture hautement parallèle de Snowflake afin de multiplier les imports concurrents en se basant sur la clé de distribution et le nombre de fichier en entrée.

Contrairement à Redshift, il est possible de transformer les données pendant le chargement.

Export de données

Il est possible d'exporter le contenu d'une ou plusieurs tables Snowflake en utilisant la commande "COPY INTO", c’est la même commande que pour l’import. L’origine et la destination étant inversées.

La destination peut être :

• AWS S3,
• Azure Blob Storage,
• Table de Staging Snowflake.

Filtrage des données : il est possible d'indiquer un ordre SQL afin de filtrer les données à exporter ou de sélectionner le contenu de plusieurs tables.

Taille et nombre de fichiers d’export

il est possible d'exporter les données vers un fichier unique ou bien plusieurs (par défaut) et dans ce cas le nombre de fichiers est déterminé par la valeur MAX_FILE_SIZE.

Time Travel

Derrière ce nom se cache une fonctionnalité intéressante de Snowflake : la possibilité d’accéder à toutes les données modifiées ou supprimées pendant un certain délai.

Pendant ce temps les données sont toujours accessibles avec possibilité de requête ou de jointure.

Il existe trois critères de sélection :

• TIMESTAMP : date et heure,
• OFFSET : nombre de secondes jusqu’à la date courante,
• STATEMENT : identifiant unique d’une opération sur la base.

Il est aussi possible d’annuler une suppression (commande UNDROP) d’une table, d’un schéma, d’une base de données. Cette commande est quasi instantanée car l’opération est logique et non physique. C’est la commande dont tous les DBA ont rêvés.

Interfaçage

Données

L’accès aux données se fait de manière classique au travers des drivers JDBC et ODBC.

L’accès peut donc se faire grâce :

• à l’interface web de Snowflake,
• une CLI (c.f. paragraphe ci-dessous),
• à un éditeur SQL,
• à une application (Java, .Net, Python, NodeJS, GO),
• à des frameworks compatibles (Spark, H2o, …),
• aux outils de BI ou d’analytiques.

Administration

SnowSQL est le client officiel de Snowflake, il permet de soumettre des ordres SQL (y compris DDL) et de charger/décharger les données.

Il existe le client web officiel qui permet l’accès aux données mais aussi le management des clusters et des accès.

Sauvegarde et restauration

En ce qui concerne la sauvegarde et la restauration, l’approche de Snowflake est originale et liée à leur architecture.

Étant donné que le stockage est disjoint du système et que la fonctionnalité de Time Travel offre la possibilité de restaurer des données effacées ou corrompues, il n’y a pas de sauvegarde au sens strict du terme mais une offre appelée Fail-Safe.

Il s’agit d’une période (entre 1 jour par défaut et 90 pour la souscription Enterprise) durant laquelle les données sont conservées après leur suppression/modification.

Cette période n’est pas modifiable et seul le support de Snowflake peut restaurer les anciennes données.

Ces données sont archivées par Snowflake dans plusieurs Data Center afin d’en assurer la pérennité.

En plus de dispenser les clients de cette gestion des sauvegardes tout en offrant le même niveau de service, un autre avantage est le coût de stockage qui n’est pas supporté par les clients.

Architecture

Snowflake possède trois composants principaux :

1. Stockage : système externe de collecte des données dans le Cloud (S3/Azure Blob Storage),
2. Traitements : ensemble de clusters manipulant les données,
3. Services : fonctionnalités communes (sécurité, transactions, métadonnées, …).

Pour pouvoir accéder aux données, il faut d’abord créer des entrepôts virtuels (Virtual Warehouses) qui correspondent à des nœuds de traitements et auxquels on donne accès à des données stockées sur un système de stockage.

Ces entrepôts virtuels peuvent servir à isoler certains types de traitements ou à gérer le multi-tenant.

Il existe un certain nombre de services techniques communs à tous les entrepôts virtuels.

Chaque “virtual warehouses” possède son propre cache qui permet :

• d’améliorer les performances
• d’isoler les données entre les entrepôts virtuels

Le service de métadonnées est partagé entre tous les entrepôts virtuels, ce qui permet à un nouvel entrepôt virtuel de connaître et donc d’utiliser très rapidement les données déjà connues.

L’édition Virtual Private Snowflake (VPS), qui est la plus sécurisée dans l’offre, ne partage aucune infrastructure avec d’autres clients et dispose donc de ses propres instances pour les métadonnées.

Techniquement les métadonnées sont stockées dans une base clé/valeur (foundationDB).

Concrètement, tous les serveurs sont hébergés dans le même provider que le système de stockage. C’est à dire soit AWS soit Azure.

Comparaison des deux solutions

Écosystèmes

Une solution n’a de sens que si elle s’intègre au SI et aux outils de la société.

Redshift

Redshift s’intègre évidemment avec les autres solutions de l’écosystème AWS :

Kinesis Data Firehose, SageMaker, EMR, Glue, DynamoDB, Athena, Database Migration Service (DMS), Schema Conversion Tools (SCT), CloudWatch, etc.

Intégration de données : Talend, Matillion, Attunity, Snaplogic, …

Décisionnel : Alteryx, Microstrategy, QlikView, Tableau, …

Snowflake

Snowflake ne dispose évidemment pas d’un écosystème équivalent. On peut y souscrire directement auprès de l’éditeur ou sur les plateformes AWS et Azure au travers du marketplace.

Même l’intégration avec les solutions natives de stockage des provider n’offre pas une intégration à minima avec certains outils puisque le format de stockage utilisé par Snowflake est propriétaire.

Toutefois Snowflake s'intègre avec IBM Cognos, Informatica, Matillion, Power BI, Qlik, Apache Spark, Tableau, MicroStrategy et quelques autres.

Support SQL

Les deux solutions clament un support important de la norme ANSI-SQL et une conformité ACID.

Toutefois Snowflake offre un support un peu plus étendu que Redshift.

Redshift

Redshift supporte les notions suivantes :

• Transactions
• Database, Schema, Table, Vue, ...
• Fonction utilisateur
• Numéro de séquence automatique (identity)
• Librairies (module Python utilisé par les fonctions utilisateurs)
• Utilisateurs et groupe d'utilisateurs

Les contraintes d'unicité, de clé primaire et de clé étrangère existent et peuvent caractériser une donnée mais ont un but informatif uniquement.

Par contre les contraintes de colonne NOT NULL sont supportées et appliquées.

Parmi les notions absentes, on peut noter le non-support de trigger et d’index.

Enfin parmi les types notables SQL non supportés (notamment par rapport à PostgreSQL), il y a les types suivants :

• BLOB (Bytea),
• INTERVAL,
• ENUM,
• JSON,
• IP,
• MONEY,
• XML.

Liste complète : https://docs.aws.amazon.com/fr_fr/redshift/latest/dg/c_Supported_data_types.html et https://docs.aws.amazon.com/fr_fr/redshift/latest/dg/c_unsupported-postgresql-datatypes.html

Timestamp (Timezone) : La gestion des fuseaux horaires est classique dans Redshift. Soit un timestamp à un fuseau horaire défini, soit il n’en a pas et dans ce cas c’est UTC qui est utilisé par défaut.

Snowflake

Snowflake supporte les notions suivantes :

• Transactions,
• Tables,
• Views,
• Schémas,
• Stages,
• Séquences.

Les contraintes d'unicité, de clé primaire et de clé étrangère existent et peuvent caractériser une colonne mais ont un but informatif uniquement.

Clonage : il est possible de cloner une table, un schéma ou même une base entière. L’énorme avantage de Snowflake tient encore à son architecture particulière. Cette copie se produisant sans copie de données, une table étant en effet un pointeur vers des données S3 ou Azure.

La copie est donc instantanée et peut même pointer vers une version historisée des données.

C’est donc idéal pour monter un environnement de test rapidement et avec un coût maîtrisé (passé le clonage, les tables de références et les tables clonées sont indépendantes et des données peuvent être ajoutées).

Variant : Ce type est utilisé pour stocker des données semi-structurées dans Snowflake.

Par exemple pour stocker une donnée au format JSON. L’avantage par rapport à une simple chaine de caractère est la possibilité de faire du ‘schema-on read’.

Au moment du chargement d’un type Variant, Snowflake va analyser sa structure et tenter de découvrir automatiquement sa structure.

Stage : Les stages sont en général associés aux phases de chargement/déchargement de données.

Ils correspondent à des fichiers stockés au format CSV | JSON | AVRO | ORC | PARQUET | XML soit en interne (sur les serveurs Snowflake) ou en externe (S3/Azure).

Parmi les types notables SQL non supportés, il y a : BLOB, CLOB et ENUM

Timestamp : La gestion des fuseaux horaires est source d’erreurs dans Snowflake. Un timestamp peut avoir 3 configurations différentes.

• Avec TimeZone,
• Sans TimeZone,
• Avec la TimeZone locale (celle du serveur).

Fonctions utilisateur

Redshift

Les fonctions utilisateur peuvent être développées en SQL ou en Python.

Concernant Python, la version 2.7 est supportée.

Même s’il est possible d’installer une librairie externe, les librairies suivantes sont pré installées : numpy, pandas, scipy, …

Les limitations sont peu nombreuses et évidentes : accès réseau, accès au système de fichiers.

Snowflake

Snowflake supporte deux langages pour le développement des fonctions utilisateurs SQL et JavaScript.

Lorsqu’elles sont écrites en JavaScript les fonctions utilisateur subissent les limitations suivantes :

• Mémoire : sans que l’on connaisse la valeur exacte, les fonctions Javascript sont limitées dans leur consommation mémoire.
• Durée : sans que l’on connaisse la valeur exacte, les fonctions Javascript sont limitées dans leur durée.
• Récursivité : les appels récursifs sont limités et peuvent entraîner une erreur.

Audit (traçabilité)

L’audit peut être une exigence légale d’un système de stockage d’information : être capable de tracer toutes les modifications des données et leur auteur.

Redshift

Il est possible d'activer l'audit dans Redshift et de stocker toutes les informations d'audit dans S3

Amazon Redshift utilise trois journaux différents :

• Journal de connexion : trace les tentatives d'authentification, les connexions et les déconnexions.
• Journal de l'utilisateur : trace les modifications apportées aux définitions d'utilisateur de base de données.
• Journal d'activité utilisateur : trace toutes les requêtes (avant d'être exécutées).

Snowflake

Snowflake ne propose pas d'Audit même si c'est une fonctionnalité qui est dans la roadmap du produit.

Toutefois des informations s'en rapprochant sont disponibles dans des tables système :

• query_history : texte de la requête, date et utilisateur)
• login_history : toutes les connexions à la base)
• Information schema : date de la dernière modification du schéma d'une table

Gestion des ressources et priorisation

La gestion des ressources matérielles (mémoire et cpu) est une problématique courante des Data Warehouses puisqu’elle peut permettre :

1. de garantir une exécution prioritaire pour certains traitements.
2. d’éviter la congestion du cluster à cause de la consommation excessive de certains traitements.

Redshift

Redshift propose une option appelée WorkLoad Management (WLM) afin de permettre de lier des utilisateurs et des groupes d’utilisateurs à des queues.

Ces queues ont des limites de consommation mémoire et de CPU.

Même si Redshift ne propose pas de système de priorisation, ces limites permettent tout de même de s’assurer que certaines requêtes soient favorisées et aient plus de chances d’aboutir au plus tôt.

Il existe aussi une autre fonctionnalité qui impacte la priorisation des requêtes :

• Short Query Acceleration (SQA)

Comme son nom l’indique, cette fonctionnalité permet de prioriser les requêtes courtes par rapport aux requêtes longues.

Ces requêtes disposent de leur propre système d’orchestration et n’utilisent donc pas le système de files d'attente habituel.

Un algorithme de Machine Learning permet à Redshift d’estimer le temps d’exécution des requêtes.

Snowflake

L’approche de Snowflake est radicalement différente puisqu’il repose sur un système d’entrepôt virtuel qui peut être vu comme un système de priorisation.

En affectant les traitements les plus critiques à un entrepôt dédié et dimensionné en conséquence, on peut augmenter leurs probabilités d’aboutir rapidement.

Une bonne pratique est de créer autant de virtual warehouses qu’il y a de familles de traitements différentes (chargement, exploration, data science, …).

Éditions

Il n’y a pas d’éditions différentes d’AWS Redshift. On peut simplement parler de deux versions différentes d’un même produit : Redshift et Redshift Spectrum

Concernant Snowflake, les choses sont différentes puisque l’on a pas moins de 5 éditions différentes.

Performances

Les entreprises ont aujourd’hui besoin d’analyser leurs données quasiment en temps réel et sur des volumétries très importantes.

De plus nous avons vu que contrairement à un datalake, les données d’un Data Warehouse sont souvent transformées et modélisées de manière à faciliter leur analyse (modèle en étoile, en flocon). La capacité des solutions à transformer les données est donc aussi importante que les performances d’accès.

Les deux solutions ont adopté des principes similaires afin de garantir un haut niveau de performances :

• Stockage orientée colonnes,
• Compression des colonnes en fonction du type de données,
• Découpage des données en partitions y compris au sein d’un nœud,
• Système de cache afin d'accélérer les accès répétés.

Ces performances ont aussi un impact sur la maintenance puisque les deux systèmes n’ont pas jugé nécessaire la mise en place d’index.

En ce qui concerne les performances, les benchmarks divergent puisque l’on en trouve aussi bien qui donnent Snowflake gagnant que l’inverse.

La difficulté de la comparaison vient du fait que les offres de dimensionnement des deux solutions sont différentes et que le seul critère de comparaison pertinent est dans ce cas le coût.

A coût égal, Redshift a un avantage sur son concurrent.

De toute façon il faut faire ses propres benchmarks en fonction de ses données et de ses cas d’usage.

Scalabilité

La scalabilité est évidemment un énorme avantage des solutions Cloud surtout parce qu’elle est couplée à une élasticité qui permet à un client d’adapter l’infrastructure en fonction de ses besoins.

Redshift

Voici tout d’abord les types de nœuds disponibles :

Nœuds de type “Dense Storage”

Nœuds de type “Dense Compute”

*: la gamme dc1 est remplacée par dc2

AWS Redshift offre plusieurs choix afin de dimensionner au mieux un cluster en fonction des exigences :

1. Redimensionnement Classique
2. Redimensionnement Élastique
3. Concurrence élastique

Redimensionnement classique

Ce redimensionnement cache en réalité une migration entre deux clusters. Un cluster cible est créé avec le nouveau dimensionnement désiré.

Les données sont copiées depuis l’ancien cluster vers le nouveau, et en fonction du volume de données, cette opération prend classiquement quelques heures mais peut durer plusieurs jours.

Redimensionnement élastique

Ce redimensionnement est beaucoup plus rapide que la version classique.

En effet le cluster est directement modifié (ajout ou suppression de nœud) et les données re-balancées entre les nœuds.

Cette opération prend en général quelques minutes et n’impose pas d’interruption de service.

Concurrence élastique

Avec cette option Redshift adapte automatiquement les capacités de traitement du cluster en fonction des requêtes et de la charge soumises.

De manière complètement transparente Redshift démarre et arrête de nouveaux nœuds très rapidement.

Il est possible de limiter cette fonctionnalité à des groupes d’utilisateur de Redshift et à des charges de requêtes spécifiques.

De même on peut limiter l’élasticité au travers d’un nombre maximal de clusters à utiliser.

Le système de facturation est original :

• Pour 24 heures d’utilisation de Redshift, vous gagnez une heure de concurrence élastique.
• Au-delà de ce crédit, la facturation s’effectue à la seconde.

Par défaut cette option n’est pas activée.

Snowflake

Contrairement à Redshift, il n’est pas possible de choisir le dimensionnement des nœuds mais simplement la taille des clusters. Cette approche est une conséquence liée à l’architecture particulière de Snowflake et la séparation entre traitement et stockage.

Voici les offres disponibles :

A chaque palier, le nombre de nœuds double.

Entrepôt virtuel (Virtual Warehouse)

Le premier élément de scalabilité proposé par Snowflake est le découpage en virtual warehouse.

Cela permet de séparer le type de charge en fonction de certains critères :

• priorité,
• consommation,
• criticité.

Mais aussi de séparer logiquement les traitements et donc d’offrir une meilleur isolation des données au cours de leur analyse et accès.

Cela permet surtout de dimensionner ces entrepôts en fonction du besoin réel et de manière plus fine qu’avec une solution mutualisée.

Il est évidemment possible de créer plusieurs clusters avec Redshift afin d’offrir la même granularité mais contrairement à Snowflake, les données étant hébergées sur les serveurs, cela pose la question de la sécurité et de la multiplication des copies.

Mise en veille Automatique

Il est possible de configurer le cluster (Virtual Warehouse) pour qu’il se mette en veille automatiquement après un délai d’inactivité. On peut alors configurer son redémarrage automatique en cas de soumission d’une requête. Cette opération est extrêmement rapide et ne sera pas perceptible par l’utilisateur.

Concurrence élastique

Il est possible de configurer le cluster (Virtual Warehouse) pour qu’il ajuste le nombre de clusters en fonction de la charge.

On peut définir un nombre minimal et maximal de clusters à démarrer/arrêter.

C’est le nombre de requêtes en attente qui donne l’ordre à Snowflake de démarrer un nouveau cluster.

Maintenance

Tâches de maintenance

Il s’agit des tâches récurrentes qui vont permettent de garantir le bon fonctionnement d’un Data Warehouse.

Redshift

Il y a trois tâches qui permettent de garantir le bon fonctionnement d’un cluster Redshift :

• Compression des données
• Vacuum (suppression des données, réorganisation des fichiers)
• Analyse (mise à jour des statistiques)

Ces trois tâches sont effectuées automatiquement si l’on utilise l'outil standard pour l’alimentation du cluster (à savoir la commande COPY).

Ainsi la compression n’interviendra que si la table atteint une certaine taille et donc que le ratio coût CPU/Taille sur le disque est avantageux.

Snowflake

Il n’y a officiellement aucune tâche de maintenance liée à l’utilisation de Snowflake.

On peut toutefois noter que la gestion des utilisateurs, de la sécurité et des différents environnements revient aux clients.

Montée de version

Redshift et Snowflake en tant que service managés gèrent la montée de version de leur produit respectif de manière quasi transparente pour l’utilisateur.

Leur but est évident :

1. éviter de maintenir un trop grand nombre de versions,
2. proposer une amélioration continue des fonctionnalités du produit,
3. fournir un service performant et sécurisé.

Redshift

AWS permet de configurer la mise à jour automatique de Redshift suivant une plage horaire hebdomadaire à définir (fenêtre de maintenance).

L’interruption de service est connue mais sa durée n’est pas maîtrisée.

On peut choisir une politique plus ou moins agressive de mise à jour :

• Current : la dernière version est installé automatiquement
• Trailing : l’avant dernière version est installée automatiquement

En cas de problème, Il est possible de revenir à une version précédente dans la console.

Snowflake

Avec Snowflake les mises à jour sont entièrement transparentes et le plus souvent sans aucune interruption.

C’est rendu possible grâce à l’architecture de Snowflake qui sépare données et traitements.

Des instances avec la nouvelle version sont lancées et une fois ces dernières validées, la bascule peut opérer. Les données ne sont pas impactées dans le process.

Il reste bien évidemment les mises à jour du système de stockage qui ne sont pas maîtrisées par Snowflake (S3/Azure Blob Storage).

Les deux opérateurs Cloud minimisent l’interruption de service au maximum et l’opération est majoritairement transparente pour les utilisateurs.

Sécurité

Lorsqu'il s'agit de données d’entreprise, la sécurité est un fondement essentiel. Et il y a d’ailleurs un certain nombre de normes qui la régisse (données médicales, données bancaires, …)

Le Cloud n’est pas obligatoirement moins sécurisé que le on-premise mais les scandales récents ont montré des failles au retentissement et aux conséquence énormes pour l’image de l’entreprise (Cf. https://blog.ippon.fr/2018/08/02/la-securite-du-cloud/).

Redshift et Snowflake prennent la sécurité très au sérieux.

Redshift

On peut distinguer :

1. sécurité du service
2. sécurité de la base de données

Concernant la sécurité de l’accès au service Redshift, elle est similaire à toutes les autres solutions natives d’AWS basées sur IAM (AWS Identity and Access Management).

Voici les principaux points pour l’accès aux clusters :

• Identifiants de connexion,
• Support des rôles,
• Support des Security Group,
• Redshift peut être intégré à un VPC (Virtual Private Cloud),
• Chiffrement des données,
• Utilisation de SSL pour les échanges entre les client (driver) et Redshift,
• Chiffrement des données entre S3/DynamoDB et Redshift.

Amazon Redshift utilise l’accélération matérielle pour la gestion du SSL.

Conformité

Redshift est conforme aux exigences SOC1, SOC2, SOC3, PCI DSS niveau 1, FedRAMP, et est éligible HIPAA.

Hébergeur de Données de Santé (HDS) : disponible sur certaines régions (dont Paris).

Il est possible d’activer le chiffrement des données des métadonnées et des sauvegardes.

La gestion de l’accès aux données est gérée dans Redshift de la même manière que dans un SGBD.

Snowflake

Le niveau de sécurité exigé va directement conditionner le choix de l’édition du logiciel Snowflake.

Plus le niveau d’exigence est élevé, plus le coût sera important.

Authentification :

• Multi-facteur
• Fédération d’identité (active directory, OAuth)

Autorisation

• Restriction IPs possible

Communication privée/directe entre Snowflake et vos autres VPC via AWS PrivateLink.

Contrôle des accès :

L’accès à tous les objets du compte (utilisateurs, entrepôts, bases de données, tables, etc.) est contrôlé  grâce à des rôles.

Sécurité des données :

• Toutes les données sont automatiquement chiffrées.
• Tous les fichiers stockés par étapes (pour le chargement/déchargement des données) sont automatiquement chiffrés.
• Clés gérées par le client.

Conformité

• Conformité Soc 2 Type II.
• Prise en charge de la conformité HIPAA.
• Conformité PCI DSS.

Coûts

Les deux systèmes proposent un système de facturation à la demande, fortement modulable en fonction du besoin.

Il est difficile de comparer les deux offres car :

1. Leur architecture est différente :

• Snowflake facture le traitement et le stockage séparément
• Snowflake ne facture pas les périodes d’inactivité

2. Le dimensionnement des instances est difficilement comparable (RAM/CPU, nombre de nœuds)

3. Le système d’instances réservées d’AWS permet de réduire de manière substantielle la facture de Redshift (75 % pour un engagement sur trois ans).

Nous allons donc présenter séparément les coûts des deux solutions mais sur une base de dimensionnement commune :

• un besoin de stockage de 8 To de données,
• un cluster de 8 nœuds,
• le tout basé à Dublin.

Redshift

Redshift charge par heure et par nœud en fonction du dimensionnement de ces derniers, ce qui couvre à la fois la puissance de calcul et le stockage des données.

Avec Redshift, le prix mensuel est donc obtenu en multipliant le prix horaire par la taille du cluster et le nombre d'heures dans un mois.

Snowflake

Snowflake charge par seconde et par entrepôt virtuel en fonction de la fonction du dimensionnement de ces derniers.

Avec Snowflake, le prix mensuel est donc obtenu en multipliant le prix horaire par la taille du cluster et le nombre d'heures d’utilisation réelle dans un mois.

Contrairement à Redshift, tous les nœuds ont la même capacité et seul leur nombre peut varier.

Enfin le choix de l’édition a un impact non négligeable puisque le coût varie du simple au double.

NB : le coût de transfert des données n’est pas pris en compte ici mais à ne pas négliger dans une estimation réelle.

Constats et remarques :

1. Redshift est particulièrement moins cher que Snowflake
2. Le coût de stockage est beaucoup moins élevé que le coût de traitement
3. En condition réelle et avec la mise en veille automatique, le coût de Snowflake pourrait baisser drastiquement (facture divisée par trois avec une utilisation de 12 heures par jour et quasi nulle les week-end).
4. Le coût de Redshift peut être réduit grâce à l’utilisation d’instances réservées (engagement sur un ou trois ans).

Monitoring

Redshift

Sur AWS, chaque service propose une interface de surveillance basique, directement intégrée à la console de chacun de ces services.

Pour une surveillance plus poussée et surtout pour une vision globale du fonctionnement des services, AWS propose un outil spécialisé : CloudWatch.

Cloudwatch permet :

• De consulter les métriques pré-définis
• De définir des métriques personnalisés
• De définir un tableau de bord personnalisé
• L’alerting (mail) en cas de dépassement de certains seuils
• De dimensionner automatiquement la plateforme lorsqu’il est couplé avec Amazon Auto Scaling.

La version de base de CloudWatch est gratuite mais les points suivants peuvent entraîner un surcoût :

• Fréquence de rafraîchissement plus élevée.
• Métrique supplémentaire (en général à un niveau plus fin du service, c’est à dire par nœud plutôt que global).

Écran de suivi des requêtes :

La vue détaillée est très complète et permet de comprendre a posteriori la performance d’une requête.

​Les logs Redshift sont consultables au sein de 3 tables systèmes :

• STL_ERROR : ne concerne pas les erreurs SQL mais les erreurs internes au cluster
• STL_QUERY : texte de la requête, début, fin, statut
• STL_QUERY_METRICS : nombre de lignes, utilisation CPU, disque, entrées/sorties, ...

Snowflake

L’interface de monitoring de Snowflake est plus succincte et très orientée sur les performances des requêtes.

La charge globale d’un Virtual Warehouse est visible dans l’interface Web grâce au graphique suivant :

L’écran de suivi des requêtes donne une vision plus précise des performances d’une requête :

Voici l’écran détaillé des performances d’une requête :

Synthèse

Conclusion

Il y a beaucoup de points communs entre les deux solutions qui vont adresser un même besoin : pouvoir analyser un volume important de données structurées ou semi-structurées d’entreprise.

Pour les nombreuses entreprises qui hébergent déjà leurs applications sur l'infrastructure AWS, l'adoption de Redshift comme entrepôt de données serait naturelle.

L’architecture de Snowflake met en avant la séparation entre capacité de calcul et de stockage, ce qui a des avantages et des inconvénients.

Le parti pris de Snowflake est de pousser le concept de service managé au maximum puisque les opérations de gestion et de maintenance sont quasi nulles.

Enfin Snowflake peut être vu comme un remède contre le vendor lock-in, puisque l’offre est disponible à la fois sur AWS et sur Azure Cloud. Ce qui peut permettre l’hybridation multi-cloud.

Sur ce dernier point et même si Snowflake revendique une base de code commune, il y a des développements propres à Azure/AWS (réseau, sécurité et évidemment stockage).

Aller plus loin

Documentation officielle :

https://docs.snowflake.net/manuals/index.html

https://docs.aws.amazon.com/redshift/index.html

Benchmarks :

https://fivetran.com/blog/warehouse-benchmark

https://azure.microsoft.com/mediahandler/files/resourcefiles/date-warehouse-Cloud-benchmark/Data%20Warehouse%20Cloud%20Benchmark.pdf

https://www.periscopedata.com/blog/interactive-analytics-redshift-bigquery-snowflake

Divers :

https://statsbot.co/blog/modern-data-warehouse/

https://panoply.io/data-warehouse-guide/redshift-architecture-and-capabilities/

Vous trouverez ci-dessous un comparatif des deux principaux fournisseurs de cloud Public qui sont AWS et Microsoft avec Azure.

Je vous montrerai ensuite via un petit tuto comment se connecter sur votre portail Azure via PowerShell afin d’administrer votre Cloud Azure.

Présentation des principaux Providers de Cloud Public

Actuellement Azure est le second Provider d’infrastructure de Cloud Public derrière AWS selon Magic Quadrant.

Les grands comptes ont privilégié le Cloud de Microsoft pour leur transformation car il était le premier à créer une région en France (La région de Paris) et premier hébergeur de santé à l’instar de la SNCF qui a annoncé en 2018 migrer 60% de ses applications dans le cloud de Microsoft sur Azure.

Source : https://www.lemagit.fr/actualites/252452157/La-SNCF-sappuiera-sur-Azure-pour-linformation-voyageur-et-la-maintenance-predictive

Ces deux Cloud Providers sont assez complémentaires. AWS est orienté application Web et Mobile mais aussi pionnier sur le Big Data, l’IoT et l’IA alors que Microsoft se positionne plus sur une solution « Entreprise » notamment grâce à Active Directory pour la gestion des droits et également grâce à Office 365 pour la partie messagerie.

AWS dispose d’une solution Active Directory mais celle-ci comporte quelques limitations :

• AWS Directory Service  est limité au niveau du nombre d’utilisateur et d’objets Active Directory de plus il ne permet pas de migrer sa base de données Active Directory sur AWS
• Simple AD ne permet pas de gérer des relations de confiance entre différents domaines, il n’y a pas d’équivalent au centre d'administration Active Directory et il n’y a pas de corbeille AD ni de prise en charge de powershell. Il y aussi des limitations pour la stratégie de mot de passe, et pour les extensions de schéma
• AD Connector permet de lier un AD existant mais il ne permet pas de gérer AD dans AWS

Les coûts de licences liés au cloud Azure sont vraiment attractifs pour les entreprises surtout si les applications hébergées utilisent la base de données Microsoft SQL Server entre autres même si il y a plus de serveurs linux que de serveurs windows sur Azure.

Amazon Web Service attire fortement une population de Pure Player Cloud comme les petites entreprises ou les développeurs ayant un focus pour Linux et utilisant une multitude de type de bases de données. C’est la raison pour laquelle AWS a développé un grand nombre d’outils pour répondre à ces besoins.

Source : http://www.evontech.com/what-we-are-saying/entry/microsoft-azure-vs-amazon-aws-comparison-between-two-cloud-computing-giants.html

Toutefois, si vous utilisez une majorité d’applications Microsoft, que la plupart de vos postes de travail sont sous Windows, que pour l’authentification, vous utilisez Active Directory, en passant par SQL Server pour vos bases de données et Visual Studio pour la partie développement, alors Azure est clairement la meilleure option.

Contrairement à AWS, Microsoft est profondément enraciné dans le monde de l’entreprise. A savoir que Microsoft a investi dans un cloud hybride, sachant que les entreprises dotées d'un datacenter traditionnel peuvent migrer certaines de leurs ressources locales, mais pas toutes, vers le cloud. Les services de migration dans le cloud Azure de Microsoft peuvent simplifier la migration de l’environnement On Premise vers Azure, et souvent sans aucune modification.

Ci dessous le tableau d’adoption du Cloud par les entreprises :

Comparaison des différents services :

Source : https://www.cloudhealthtech.com/blog/aws-vs-azure-vs-google

Ci-dessous une petite comparaison des fonctionnalités entre Azure et AWS

AWS

·   Plus de centres de données pour la disponibilité et une faible latence

·   Plus de services basé sur de l’Open source

·   Une meilleure prise en charge DevOps

·   Large gamme de bases de données SQL et non-SQL

·   Implication lourde dans l’IA

·   Simplification des licences

·   Prise en charge renforcée de la BI et de l’analytique

Azure

·   Prise en charge totale des applications héritées de Microsoft

·   Une plus grande sensibilisation aux besoins des entreprises

·   Migrations faciles en un clic dans de nombreux cas

·   Conversion de licences sur le Cloud

·   Bon support pour les environnements mixtes Linux/Windows

·   Meilleure offre de Cloud hybride

·   Meilleure prise en charge de la reprise après sinistre

Source : https://www.datamation.com/cloud-computing/aws-vs-azure-cloud.html

Après ce tour d’horizon entre les deux leaders du Cloud Public, nous allons voir dans cet article, comment se connecter depuis son poste de travail sur Azure afin d’être en mesure de pouvoir l’administrer via PowerShell et donc tester le Cloud Azure.

Installation des outils d’administration

Avant de démarrer ce tutorial, vous devez avoir créé un compte sur Azure, cela est gratuit, de plus Microsoft vous offre 170$ de crédit durant 12 mois afin de pouvoir tester cette solution.

• https://azure.microsoft.com/fr-fr/free/

Installer Visual Studio Code

Son intérêt : permettre d’administrer notre solution Azure aussi bien sous Windows que sous Linux et d’avoir ainsi une console unique pour administrer notre infrastructure Cloud.

1. Télécharger puis installer Visual Studio Code depuis le lien suivant : https://code.visualstudio.com/docs/?dv=win
   
2. Après avoir téléchargé et installé Visual Studio Code, installer les extensions Azure et Python pour Visual Studio Code en cliquant sur Install dans le bandeau de gauche.

Les extensions Azure nous permettent d’administrer notre Cloud avec le Shell d’Azure et Python, ce qui nous permettra par la suite de faire du serverless ou de l’automatisation !

Comme vous pouvez le voir ci-dessous, les modules sont installés.

Installer le module AZ PowerShell

Si vous souhaitez utiliser PowerShell uniquement, l’administration de votre Cloud Azure s’effectue avec le module PowerShell Az-Module

Az-module est un module PowerShell Cross-Platform permettant de manager des ressources via PowerShell.  Il est écrit en .net, et peut être  utilisé aussi bien par Windows que MacOs et n’importe quelle distribution Linux.

• Install Azure CLI with apt
• Install Azure CLI with yum
• Install Azure CLI on Linux manually

Afin d’installer le module, exécuter la commande suivante avec élévation de privilège : Install-Module -Name Az -AllowClobber

Vérifiez ensuite votre installation via la commande suivante : Get-InstalledModule -Name Az -AllVersions

Ensuite, vous pouvez vous authentifier sur Azure via la commande : Connect-AzAccount

Connectez-vous avec votre compte Microsoft :

Après vous être authentifié, vous aurez l’écran suivant

Une fois connecté, vous pouvez utiliser les commandes Azure pour accéder et administrer vos ressources. Utilisez cette commande afin de connaitre vos différentes options : Get-Command -Module Az*

Exemple de commande PowerShell

#Nous donne le contexte de connexion (Utilisateur et souscription)

Get-AzContext

#Nous donne la liste des ressources dans la souscription actuelle

Get-AzResourceGroup

#Nous donne les informations de la VM "TESTVM01" se trouvant dans le groupe de ressource "TestRG01"

Get-AzVM -ResourceGroupName TestRG01 -Name TESTVM01

# Nous donne la liste des comptes de stockage de notre souscription

Get-AzStorageAccount #New command

Les groupes de ressource

Pour classer nos différents environnements (Dev, Test ou Prod) Microsoft a mis en place des groupes de ressources (ou Ressource Group).

Les groupes de ressources nous permettent  aussi de classer nos entités par besoin métier et de suivre leur coût “global”.

Cela nous permet de regrouper nos entités (VM, Web App, Compte de stockage ou base de données SQL) dans un seul conteneur logique qui peut être sur une ou plusieurs régions. -> Ces ressources peuvent être déployées et supprimées en même temps.

Création de groupe de ressource via PowerShell

#Création du groupe de ressource

New-AzResourceGroup -name DEV -location "westeurope"

Création de zone DNS privée via PowerShell

#Création de la zone DNS privée

New-AzDnsZone -Name piermick. local -ResourceGroupName DEV -ZoneType Private -RegistrationVirtualNetworkId VN1002

Installer le client SSH

Le client SSH nous permet de nous connecter aux machines Linux. Cela est désormais natif sous Windows 10, plus besoin de passer par PuTTY !

Get-WindowsCapability -Online |? Name -like 'OpenSSH*'

Un peu de Serverless

Microsoft met à disposition les outils suivants sur Azure pour faire du serverless, Azure Functions, Logic App et Event Grid.

Azure Functions permet d’exécuter un script C#, F# et JavaScript au déclenchement d’une action, cette fonctionnalité est scalable, de plus, il est possible d'enchaîner plusieurs Azure Fonction.

Azure Logic App permet de connecter votre application se trouvant sur Azure à Dropbox, Twitter… via un connecteur et sans ligne de code, Il est même possible d’utiliser des conditions et des boucles afin de générer un workflow déclenché par un évènement.

Event Grid nous permet de centraliser les événements

Administration de votre Cloud Azure

Si vous souhaitez effectuer des labs, je vous invite à récupérer les cours de formation Azure disponible sur GIT ici :

• https://github.com/MicrosoftLearning

Maintenant que vos outils sont installés vous pouvez désormais administrer votre environnement Azure. Pour information, vous ne pouvez pas créer de “tenant” Windows Azure Active Directory, pour cela, vous devez créer une souscription.

Un tenant est une partie du Cloud Public mis à notre disposition par le Provider Cloud

• https://docs.microsoft.com/en-us/previous-versions/azure/azure-services/jj573650(v=azure.100)

Bon Cloud sur Azure 😊

L'entretien structuré est mort !
Vive le recruteur structuré !

Le recrutement est l’un des axes stratégiques des entreprises, particulièrement sur certains secteurs et métiers, structurellement pénuriques et en tension : le DIGITAL cumule ces deux points.

L’objectif de l’entretien de recrutement est de valider l’adéquation entre les besoins de l’entreprise et les compétences des candidats : hard skills et soft skills.
Jusque là cela semble simple, mais nous allons nous heurter très rapidement à des différences de vues (direction, RH, management …) lors de la définition des besoins, puis la description du candidat idéal ;).

Ces lignes sont bien parallèles
et pourtant je suis sûr aussi que ce n’est pas votre perception

Force est de constater que l’exercice le plus difficile est l'appréciation du candidat par les recruteurs, qu’ils soient RH ou opérationnel :

• Interne
• Alignement des besoins et des visions du poste, du candidat idéal …
• Surcharge de travail et fatigue du recruteur
• Déficit de compétences des recruteurs
• Biais cognitifs, préjugés, à priori ..
• Externe
• Désirabilité sociale du candidat
• Stress du candidat
• Canaux de communications différents (ProcessCom).

Ne pas se tromper lors d’un entretien de recrutement relève presque du miracle.

Heureusement l’entretien structuré a été inventé pour pallier cela …. ou PAS.

“L’entretien structuré”, de quoi parlons-nous ?

N’étant pas un adepte de ce type d’entretien, je vais volontairement en faire une synthèse rapide.
“On” nous explique qu’il faut une bonne définition de poste (bon là c’est une bonne base quand même), qu’il faut créer un questionnaire précis, à appliquer à la lettre auprès du candidat lors de son entretien, et surtout, surtout, sans changer l’ordre des questions si on veut aller jusqu’au bout de la logique (je provoque ? un peu oui).
Autre point important, les évaluateurs doivent tous être identiques (ben voyons) et ne pas rebondir (ou le moins possible) sur ce que dit le candidat, qui ne doit, lui, idéalement pas poser de question.

Voilà, on vous garantit que grâce à cela vous allez pouvoir parfaitement choisir le bon, le meilleur candidat et que cela sera une réussite (statistiques à l’appui) …

Je serais intéressé de comprendre comment ces statistiques ont été calculées, car pour être honnête je n’ai rencontré à priori personne appliquant cette méthode tout du moins en France..
Raisonner en se basant uniquement sur l’entretien, c’est un peu oublier qu’un “bon recrutement”, c’est aussi une bonne intégration, un bon management ...

Je remarque souvent que pour compenser un manque de compétences, on se dit que la mise en place d’un processus va tout régler.
Ce qui peut sans doute fonctionner pour des tâches simples et à faible valeur ajoutée, me laisse plus que dubitatif pour le recrutement, l’une des activités hautement stratégiques d’une entreprise.

Seraient-ce les mêmes qui trouvaient géniales les questions Google, telles que : (Combien de balles de golf peut contenir un bus scolaire ? - Combien d’aspirateurs sont fabriqués par an aux USA ?..)
Aux dernières nouvelles, Google en est revenu depuis, en révélant par une étude de 2017 de ses RH, que ses collaborateurs les plus efficaces n’étaient pas les plus brillants cerveaux mais ceux dotés de plus grandes qualités humaines (vérifiable ici ou là).

Ce genre de technique emprisonne le recruteur, et le candidat, dans un appauvrissement relationnel fort, qui va empêcher toute spontanéité. Cela donne une expérience candidat déplorable et un échec en puissance probable.

C’est une illusion de penser que l’on puisse remplacer les compétences de recrutement par des outils de standardisation (on a même évoqué l’IA)… En effet, le recrutement ne s’arrête pas à l'entretien et ne se joue pas simplement sur des calculs de probabilités ou de scores de “matching”. L’osmose prend tournure par la qualité des interactions entre le collaborateur entrant et ses nouveaux collègues, son manager et l’expérience que pourra lui proposer l’entreprise, favorisant ainsi son engagement.

COMPRENDRE c’est TOUT (et c’est déjà pas si mal !)

Changeons les paradigmes et l’approche de cet exercice !
Bannissons les termes comme “juger”, “évaluer” ou “apprécier” … Soyons plus humbles et intelligents, en essayant de COMPRENDRE nos candidats.
Vous verrez, cela changera tout dans l’approche de votre entretien, et cela vous évitera de rater un bon candidat.

• comprendre le candidat ou la candidate et ses compétences (hard et soft bien sûr),
• comprendre comment cette personne mènera à bien ses missions, projets ou objectifs dans ce nouveau système (service, équipe, entreprise) et s’assurer que cela sera compatible avec le fonctionnement optimal de l’entreprise / service.
• comprendre ce que le candidat ou la candidate va pouvoir vous apporter et comment...

Ce changement de Mindset, de paradigme n’est possible que par l’acquisition de connaissances, de compétences et de bienveillance, donc clairement pas en respectant à la lettre une fiche d’évaluation.

Ne jetons pas totalement la pierre non plus à “l’entretien structuré” qui a pour mérite de vouloir structurer. Mais à choisir je préfère un recruteur bien formé qu’une méthode appliquée sans connaissance ;).

La structuration ne doit pas être superficielle, mais bien la fondation de ce magnifique métier de recruteur, et en conséquence bien plus porteuse de sens.

Vive le recruteur structuré !

Comprendre quoi ?
Pour faire simple, nous pouvons catégoriser 2 types de compétences : Les Hard Skills et les  Soft Skills.

Les Hard Skills

Je recommanderais aux recruteurs d’être curieux, et de s’intéresser sincèrement aux métiers pour lesquels ils recrutent. Avoir un maximum de compréhension de ce que réalise son candidat en day-to-day permet de rester crédible durant les échanges.
Il s’agit aussi de comprendre l’environnement dans lequel évolue son candidat (travail, secteur, évolution…).

Par exemple, pourquoi aujourd’hui l’Agilité est LA culture prônée au sein des organisations, et pas/plus uniquement dans les équipes IT?
Comprendre que c’est le contre-pied du classique “Cycle en V” (Manifesto Agile, avec ses 4 valeurs et 12 principes et surtout l’état d’esprit qui en découle), et que cela va avec la réalité d’un Time To Market apporté et imposé par les GAFA(M). (typiquement, si vous êtes recruteur dans le numérique et que nous n’avez pas tout compris, c’est mauvais signe ;) ).

Les Softs Skills

Là encore, si certains recruteurs ont la fameuse “bonne intuition”, force est de constater que si nous (HR) voulons défendre un candidat auprès de la direction ou opérationnels, cela ne suffira pas.
Monter en compétences sur l’évaluation, essayer d’inclure plus de compréhension des modes de fonctionnement humains passe par “se comprendre soi-même” (oui, non pas “se connaître soi même”;) - autre sujet).

Pourquoi se comprendre ?

Parce que nous sommes tout à la fois notre pire ennemi, notre plus grand filtre, et notre meilleur cobaye !
Nous avons tous (oui, tous) des biais cognitifs, préjugés, à priori …  ce qui explique qu’il existe une loi antidiscrimination encadrant le processus de recrutement, les sujets sont assez faciles à identifier (l’origine, le nom de famille, le sexe, l’âge, l’apparence physique, le handicap …).

Les Soft Skills, sont  un peu plus subtils et compliqués à appréhender.
Pensez au lièvre et à la tortue qui est censée perdre, pensez au commercial et à l’ingénieur qui ne se comprennent pas, pensez à l’analytique hyper organisé qui parle avec un directeur artistique... ou encore, n’avez-vous pas rencontré que des commerciaux hypers-extravertis ?

N’avez-vous même jamais ressenti l’impression d’être incompris(e), ou que le projet n’était pas géré comme il le fallait.. ou comme VOUS auriez pensé qu’il eu fallu le piloter.

Vous voyez, ce n’est pas si facile : imaginez alors que nous sommes en train d’essayer de comprendre un parfait étranger en 1 heure, le tout avec tous nos prismes, préjugés et biais.

Ce que je veux expliquer, c’est que face à une personne sans les mêmes compétences comportementales, ou différents canaux de communication que vous, vous pourriez tomber sans le savoir sur une sorte de discrimination en  softs skills “à l’insu de votre plein gré” et peut-être rater le candidat qu’il vous fallait.

Et puis il y a aussi une autre raison : la méconnaissance fait peur, l’inconnu (la chose ou le nouveau collaborateur) apporte de l'appréhension, et permet à l’irrationnel de prendre sa place, alors même que dans un contexte de transformation il faut pourtant intégrer des gens différents de la culture historique de l'entreprise.

Nos ancêtres pensaient que l’Orage était une manifestation de mécontentement des dieux.

Se connaître soi-même ?

Vous pouvez commencer par vous évaluer via des outils d'évaluation (par exemple, PerformanSe, MBTI ou encore ProcessCom …). Chacun est complémentaire, n’hésitez donc pas à croiser les informations et surtout, faites-vous accompagner par une personne formée. Celle-ci pourra vous donner plus d’explications, d’informations “complétantes”, bref de la connaissance, et même de la connaissance scientifique (car les sciences “molles” ne sont pas si molles que ça en voici un exemple)

La connaissance de vous-même est le point préalable à la compréhension et acceptation du fonctionnement des autres.
En plus d’enrichir votre vision, elle vous évitera de passer à côté de candidats de qualité.

Vous l’avez compris : la structuration de l’entretien doit se faire au niveau du recruteur avant tout. Vous souhaitez augmenter vos chances de réussir vos recrutements, alors augmentez vos compétences de recruteur (que vous soyez RH ou Opérationnel/le) et de vos leaders : c’est un TOUT.

L’homme est une merveilleuse machine, capable de s’adapter et d’évoluer.
Notre rôle de recruteur est de comprendre par quel chemin notre candidat est allé, va, ou peut passer pour réussir. Reste de convaincre ensuite en interne.

Convaincus, j’espère !

Chez Ippon nous le sommes, et c’est pourquoi nous avons créé une “Belt expérience candidats” (Programme “Black Belt” : programme de formation continue autours d’expertises comme, la data, l’agilité, le cloud, le management... qui permet aux collaborateurs d’IPPON de se former et de progresser sur les compétences qu’ils souhaitent acquérir) autour des compétences des recruteurs et de l’expérience candidat. Nous sommes convaincus que proposer la meilleurs expérience candidat est profitable aussi bien pour le candidat que pour l’entreprise. Cela peut nous permettre de réaliser des recrutements parfois un peu décalés mais des recrutements qui restent maîtrisés et fiabilisés.

Cet article fait un tour d’horizon des outils et services qui permettent d’extraire les publications provenant de Twitter, Facebook et des blogs.

Introduction : quelles données ?

Les réseaux sociaux sont des plateformes numériques incontournables. En 2019, sur 7,6 milliards d’habitants, on note 3,4 milliards d’utilisateurs de réseaux sociaux (source).

Aujourd’hui les membres de ces réseaux partagent leurs propres occupations quotidiennes, mais aussi leurs avis sur des sujets d’actualité, culturels, ou encore politiques. Ainsi, Twitter, Facebook et autres Instagram, sont devenus des sources importantes d’informations. Ils permettent de jauger en quelques clics et lectures de commentaires l’état de l’opinion publique sur un sujet donné. Les sociétés utilisent également ces plateformes comme de puissants outils de communication, que ce soit pour accroître leur notoriété ou encore alimenter l'esprit de leur communauté.

En bref, des quantités immenses de données sont générées à chaque instant par le biais de ces réseaux. Cela illustre parfaitement les V de la Big Data, en effet, ces données, en plus d’être volumineuses, sont variées. Elles contiennent bien sûr le contenu des publications, suivis par différents indices de popularités et d’impressions (vues, likes, partages etc.), et par une multitude de métadonnées.

Cette data est une véritable mine à exploiter ; selon l’approche elle peut être utilisée pour répondre à différents besoins (jauge de popularité, analyse d’opinion, système de recommandation, ciblage...).

Les sociétés gérantes de ces réseaux ont bien compris la nécessité de fournir des services permettant d’extraire les données générées, et proposent parfois même des outils managés d’exploitation et de traitement de ces dernières (Twitter Analytics, Facebook Business Manager…).

Dans cet article, nous nous concentrons sur les outils d’extraction permettant de collecter les publications provenant de Twitter, Facebook et des blogs.

Twitter, un service complet et pour tous les goûts

-> Documentation

Twitter met en oeuvre plusieurs plateformes (APIs REST), qui prennent en paramètre une requête et renvoient une réponse au format JSON. Le tout est accessible selon trois offres : STANDARD (gratuit), ENTERPRISE et PREMIUM.

Dans chaque API, il est proposé plusieurs endpoints. Il en existe assez pour répondre à énormément de cas d’utilisation (stream, publier des tweets, récupérer les tendances etc.). Dans cet article, je vous présente rapidement les outils permettant :

• d’extraire (API Search Tweets, API Get Tweets Timelines)
• de streamer (Filter Realtime Tweets)

Pour pouvoir utiliser ces offres, il vous faudra d’abord suivre une procédure de création d’une App. Twitter vous demandera notamment de renseigner à quelles fins vous souhaitez utiliser leurs services, et, si tout va bien, cela vous permettra de récupérer vos clés secrètes (4 tokens API ).

API Search Tweets

Si votre but est d’extraire des publications selon une recherche particulière, c’est-à-dire selon un ou plusieurs mots-clés, selon des hashtags/noms d’utilisateur ou encore sur une période donnée ; l’API Search est celle qu’il vous faut. Elle prend une requête de recherche et renvoie un JSON avec les données des publications correspondantes.

Pour chaque publication, l’objet retourné contient un panel exhaustif d’informations. Outre le contenu du tweet, on retrouve diverses précisions sur l’auteur, la localisation, l’appareil utilisé pour la publication, sur le nombre de retweets/likes/abonnés, les mentions, les hashtags, les médias contenus et plus encore.

Concernant les limitations, celles-ci sont plutôt raisonnables. Avec l’offre STANDARD (gratuite), il est possible d’effectuer jusqu’à 400 requêtes sur une fenêtre de 15 minutes. Sachant qu’une requête renvoie 100 publications maximum. Outre le nombre de requêtes maximum, la différence entre le service STANDARD et PREMIUM se trouve dans l’accès aux anciens tweets. L’offre gratuite ne permet de récupérer que les tweets récents (date de publication inférieure à 7 jours) alors que la version payante donne accès aux publications depuis 2006. A noter aussi que la recherche de l’offre gratuite n’est pas entièrement fidèle ni exhaustive, elle peut ignorer des tweets qu’elle ne considère pas pertinents.

Avec une bonne utilisation des paramètres et de l’outil (mise en cache, curseur de page etc.), on est quand même capable d’extraire gratuitement des informations sur des milliers de tweets en un temps record.

→ Doc Twitter Search

fetched_tweets = api.search( query = "big data from:ippontech", 
                             count = 100,
                             result_type="recent")

Exemple d’utilisation de l’API Search sous Tweepy. La requête retourne les tweets les plus récents provenant du compte @ippontech contenant le mot clé big data.

Get Tweet Timelines

L’API Timelines permet notamment de récupérer le fil d’actualités, basé sur nos abonnements ou de directement récupérer les 20 derniers tweets d’un utilisateur donné.

-> Doc Tweets Timelines

Stream API (Filter realtime Tweets)

Twitter propose également un service de stream en temps réel sur une requête donnée.

-> Doc Stream

Les librairies

On peut vite se perdre parmi toutes les fonctionnalités proposées par Twitter. En effet, plus d’une dizaine d’APIs Twitter sont disponibles, avec chacune plusieurs endpoints. Heureusement, il existe des librairies les regroupant, et simplifiant leur utilisation par le biais de méthodes. Les librairies disponibles ont principalement été développées par la communauté, on en retrouve dans plusieurs langages (liste des librairies ici).

Sur Python, Tweepy est l’une des références, c’est une library assez complète et bien documentée. Elle permet la plupart des cas d’usages (stream, publication, recherche, etc.).

-> Doc Tweepy

Facebook, un service en demi-teinte

Pour récupérer des données Facebook, vous allez d’une façon ou une autre passer par le service phare : Facebook Graph API.

Facebook est par excellence le géant des réseaux sociaux (+ de 2 milliards d’utilisateurs actifs contre 320 millions pour Twitter). Il est pourtant surprenant de noter que sa plateforme de services est moins populaire que celle de Twitter. Cela s’explique par plusieurs raisons :

• Sur Facebook, les données sont protégées (en théorie...), dans le sens où il y a beaucoup plus de notions de publications, groupes, et profils privés que sur Twitter, où la grande majorité des tweets est publique. L’accès aux données est donc davantage contrôlé ;
• Là où Twitter se concentre autour… des tweets, Facebook lui, propose plusieurs services de communication et de partage (videos, groupes, pages, etc.). Ce qui complique conceptuellement la donnée ;
• La documentation de Graph API gagnerait à être plus claire et mieux organisée.

Le service requiert ainsi un nombre conséquent d'autorisations (pour une requête cela peut même atteindre une vingtaine d’autorisations) et d’usage de tokens, ce qui peut être déroutant au premier abord.

Obtenir un token

1. Se connecter avec un compte facebook sur developers.facebook.com,
2. Créer une App,
3. Allez ensuite sur la console Explorer en sélectionnant votre App,
4. Demander un user access token (token d’accès utilisateur), puis sélectionner les autorisations qui conviennent à votre utilisation.

Sachez que certains endpoints ne sont accessibles que si votre token contient les autorisations adéquates. Vous pouvez retrouver leur détail ici.

Fenêtre de sélection des autorisations afin de générer un token

• que ce soit par l’usage de requêtes classiques à l’API Rest de Graph, comme sur la requête ci-dessous qui récupère le feed de la page Ippon Technologies ;
• ou en le renseignant lors de votre usage du Facebook SDK (présent dans plusieurs environnements).

import urllib3, requests
token = "votretokenici"
page_id = "ippon.technologies"
posts = requests.get("https://graph.facebook.com/"+page_id+"/feed?access_token="+token)

Requête GET à Graph API Facebook

Limitation

Au niveau de la limitation, pour une App donnée, on est à 200 requêtes par heure, multipliée par le nombre d’utilisateurs.

-> Plus d’infos

Les articles de blogs/presse

Scraping

L’extraction de données de blog diffère de celle des réseaux sociaux, car évidemment les blogs ne sont pas fournis par un seul et même service (WordPress, Wix, etc.).

Dans le cadre de la récupération d’articles de blog, on va parler de scraping. C’est le terme pour désigner la récupération du contenu d’un site web de manière automatisée. Néanmoins, il ne faut pas oublier que les articles de blogs font partie des propriétés intellectuelles, et selon l’utilisation faite des données scrapées, cela peut entrer en conflit avec la législation du pays en vigueur, ou du moins avec la volonté de l’auteur.

Il existe des services ready-to-use pour scraper des blogs et sites en général. Les produits payants (APIFY, SCRAPERAPI), permettent notamment d’esquiver le ban de l’adresse IP, chose courante dans le cadre d’un scraping massif et régulier.

Au niveau des solutions open source, le framework Scrapy, sous un environnement Python, est l’une des références. Muni d’une très bonne documentation, il permet notamment de localiser et de récupérer directement le texte entre les balises HTML/XML (en lui fournissant un lien vers un flux RSS, que vous pouvez facilement trouver sur tous les blogs). Il permet donc de récupérer directement les infos que l’on souhaite, et même de les formater selon notre besoin, pour en extraire un fichier JSON, par exemple.

Cas d’usage : extraire et transformer les flux RSS avec Scrapy

Exemple de flux RSS, que vous pouvez retrouver ici

Ci-dessous un exemple de spider (= job scrapy) que j’ai codé pour extraire les données d’une liste de flux RSS. La méthode parse_node va tout simplement parcourir chaque noeud item du flux puis en extraire les balises qui nous intéressent.

# Lancer le script avec : scrapy crawl myspider.py -o data.json
import scrapy

class Article(scrapy.Item):
  title = scrapy.Field()
  link = scrapy.Field()
  description = scrapy.Field()
  pubDate = scrapy.Field()
  category = scrapy.Field()
  content = scrapy.Field()
  author = scrapy.Field()

class Spider(scrapy.spiders.XMLFeedSpider):
  name = "SpiderRSS"
  start_urls = [
    "http://blog.ippon.fr/feed",
    "https://fr.blog.businessdecision.com/feed/",
    "http://feeds.feedburner.com/AmazonWebServicesBlog"
  ]

  def parse_node(self, response, node):
      ns = {'dc': 'http://purl.org/dc/elements/1.1/',
            'content': 'http://purl.org/rss/1.0/modules/content/'}
      item = Article()
      item['title'] = node.xpath('title/text()').extract_first()   
      item['link'] = node.xpath('link/text()').extract_first()
      item['pubDate'] = node.xpath('pubDate/text()').extract_first()
      item['description']  = node.xpath('description/text()').extract_first()
      item['category'] = node.xpath('category/text()').extract()
      item['author'] =  node.xpath('//dc:creator/text()', ns).extract_first()
      item['content'] = node.xpath('//content:encoded/text()',ns).extract_first()
      yield item

Extrait du résultat du script en JSON

Solutions multi-médias

Il y a plusieurs solutions pour récupérer, en une seule fois, un panel de réseaux sociaux. Elles sont généralement payantes et destinées à des fins marketings, comme Twine Social Media ou Scraping Expert.

On peut trouver également des librairies et modules regroupant plusieurs plateformes, comme SocialReaper sur Python, qui scrapent Facebook, Twitter, Reddit, Youtube, Pinterest, et Tumblr à condition de fournir les clés qui vont bien.

On peut également citer la solution Hootsuite, très prisée par les services de communication des entreprises pour avoir la main sur un ensemble de plateformes. Les API ouvertes par Hootsuite sont surtout utiles pour publier sur les réseaux, mais elles proposent aussi un service d’iframe pour afficher les publications sur vos sites web.

Conclusion

En conclusion, il existe plusieurs services pour récupérer la donnée de nos chers réseaux sociaux. Il faut cependant faire attention à bien cibler son besoin, afin de choisir une solution qui lui corresponde, tant au niveau des limitations qu’au niveau des tarifs qui suivent.

Il est conseillé de bien lire la documentation des services prêts à l’emploi, qui peuvent parfois être tricky. Certains vendent seulement une agrégation d’outils open-source ou d’appels aux APIs sources, ce qui ne vaut pas forcément le coût.

Sources/Liens utiles

-> Toutes les documentations citées dans l’article

-> Qu’est ce que robots.txt ? (des infos sur les robots.txt, non abordés dans cet article mais incontournables du scraping)

-> Twitter, 40 chiffres à connaître en 2018

-> How to use Facebook Graph API and extract data using Python!

-> Collecting Facebook data with the Graph API

->[Dossier] Réseaux sociaux : comment tirer profit du Social Big Data

Vous avez des besoins spécifiques avec Elasticsearch ? Elasticsearch ne vous permet pas de personnaliser vos données en temps réel ? Le plugin est probablement la solution qui vous conviendra.
Après ces deux questions dignes d’un show télé, je vais vous donner un rapide aperçu de ce qu’il peut être possible de faire. Lors d’un projet Market Place B to B, les prix sont donnés en fonction des clients. Il est utile d’enrichir les données avec le prix sur plusieurs index pour profiter des avantages d’Elasticsearch. Ou pour un second exemple, si vous avez besoin d’avoir des logs à l’heure Parisienne et pas l’heure New-Yorkaise mais que votre Data Center est à New-York. Il est possible de supprimer l’heure de New-York et d’enrichir les données avec l’heure de Paris.

Pourquoi j’ai écrit cet article ?

Dans cadre d’un projet client, il nous a été demandé de mettre en place un plugin d’enrichissement de données. Malheureusement, les ressources disponibles étaient limitées et pas en adéquation avec la version que nous utilisions. Nous avons fini par y arriver et je vous propose de partager ce savoir faire au travers de cet article !

A qui s’adresse cet article ?

Cet article s’adresse aux personnes souhaitant créer leur premier plugin Elasticsearch pour enrichir ou transformer des données qui vont être indexées. Ce dernier aura donc pour but de vous guider dans la création d’un ingest plugin jusqu’à la création du zip contenant votre plugin.

Les technologies

Il sera réalisé en Java 8, avec maven sur les versions 6.5 et 6.6 d’Elasticsearch et Docker en 18.09.2.

Exemple de plugin

Ce type de plugin nous offre la possibilité d'intercepter un document pour le transformer ou l’enrichir selon vos souhaits. Voici un exemple concret de ce que peut offrir un plugin. Le plugin OpenNLP permet de faire de l’entity extraction (extraction d’information dans des corpus documentaire).
Les sources de cette démonstration sont disponibles à cette adresse :
https://github.com/julienconte/ingest-plugin-elasticsearch

Cette démonstration intègre directement Kibana et Elasticsearch afin de tester et visualiser les données enrichies.

Les ingests plugins plébiscités par Elasticsearch

Pour l’heure, Elasticsearch met en avant 3 plugins :

Ingest attachment processor plugin
Extrait des données sous forme de fichier PPT, XLS ou PDF

Ingest Geoip Processor Plugin
Enrichit votre document en lui ajoutant un champ geoip. Ce champ va indiquer la position géographique de l’adresse IP lors de l’envoi des données.

Ingest User Agent Processor Plugin
Extrait les données du User-Agent (le type d’application, le software à partir duquel sont envoyées les données)

*Les deux derniers plugins n’existent plus sur la version 6.7.0. Ils sont directement intégrés en tant que module à partir de cette version.

Comment ça marche?

Des définitions :

Ingest node :

Un ingest node est un node qui est créé pour intercepter les requêtes bulk et les requêtes d’indexation. Il va exécuter une tâche avant l’indexation du document.

Ingest plugin :

Un ingest plugin permet d’étendre les possibilités qu’offre un node Elasticsearch. Le node utilisé sera alors appelé un ingest node.
Il permet d’utiliser des pipelines qui feront appel à des plugins permettant de transformer ou modifier un document entrant avant indexation.

Processor :

Un processor est un processus qui va englober notre plugin. Il prend en entrée un document (la donnée qui va être indexée). Il transforme ensuite ce document et le renvoie pour qu’il soit indexé avec la bonne transformation.

Chaîne de fonctionnement des données avec un ingest plugin :

Passons à la technique !

Pour rappel, les exemples ci-dessus sont les bases de la réalisation d’un plugin orienté enrichissement de document. Ce squelette est commun à tous les plugins Elasticsearch pour les versions 6.5.4 et 6.6.

Préparation de notre POM (Project Object Model) :

Il faut commencer par créer un projet avec maven. Pour plus de facilité et pour être plus rapide, il est préférable de faire du maven assembly pour regrouper les dépendances, le jar et le fichier property dédié à notre processor dans un zip au lieu de tout créer à la main.
Il faudra rajouter ces diverses propriétés dans le POM :

<properties>
       <elasticsearch.version>6.6.1</elasticsearch.version>
       <output.directory>./docker-ek/elasticsearch/plugin</output.directory>
<!-- Cette propriété indique où sera dirigé le zip après sa création. Ici, il est redirigé --> <!-- directement dans le dossier elasticsearch pour plus de facilité -->
</properties>


<build>
    <resources>
        <resource>
            <directory>src/main/resources</directory>
            <filtering>false</filtering>
            <excludes>
                <exclude>/elastic-properties/*.properties</exclude>
<!-- On exclue la lecture du properties pour Elasticsearch  -->
            </excludes>
        </resource>
     </resources>

     <plugins>
         <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-compiler-plugin</artifactId>
             <version>3.3</version>
             <configuration>
                 <source>1.8</source>
                 <target>1.8</target>
             </configuration>
         </plugin>
         <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-assembly-plugin</artifactId>
             <version>2.6</version>
             <configuration>
                 <appendAssemblyId>false</appendAssemblyId>
                 <outputDirectory>${output.directory}</outputDirectory>
                 <descriptors>
                     <descriptor>${basedir}/src/main/assemblies/plugin.xml</descriptor>
<!-- On indique le descriptor de maven assembly -->
                 </descriptors>
             </configuration>
          <executions>
              <execution>
                  <phase>package</phase>
                    <goals>
                        <goal>single</goal>
                    </goals>
              </execution>
            </executions>
        </plugin>
    </plugins>
</build>

Configuration de l’exportation format zip :

Passons à la définition du descriptor, contenu dans le fichier plugin.xml. Il nous permet d’avoir le code, les dépendances et le fichier property directement dans le zip :

<?xml version="1.0"?>
<assembly>
   <id>plugin</id>
   <formats>
       <format>zip</format>
   </formats>
   <includeBaseDirectory>false</includeBaseDirectory>
   <files>
       <file>
           <!-- On ajoute notre properties à notre zip -->
           <source>${project.basedir}/src/main/resources/plugin-descriptor.properties</source>
           <outputDirectory>/</outputDirectory>
           <filtered>true</filtered>
       </file>
   </files>
   <dependencySets>
       <dependencySet>
           <outputDirectory>/</outputDirectory>
           <useProjectArtifact>true</useProjectArtifact>
           <useTransitiveFiltering>true</useTransitiveFiltering>
       </dependencySet>
   </dependencySets>
</assembly>

Création du fichier properties pour Elasticsearch

Il faut créer un fichier plugin-descriptor.properties, pour donner des informations sur notre plugin à Elasticsearch. Il sera situé dans notre dossier resources :

description=${project.description}
version=${project.version}
name=ingest-enrich
classname=org.elasticsearch.plugin.ingest.search.EnrichPlugin
java.version=1.8
elasticsearch.version=${elasticsearch.version}

Partie Java :

L’arborescence :

Commençons déjà par créer cette arborescence :

• plugin.xml est notre maven assembly que vous avez vu plus haut dans cet article.
• EnrichPlugin permet d’informer les processors qui composent le plugin.
• EnrichProcessor contient le coeur de votre plugin. C'est là que nous allons décrire notre traitement pour par exemple enrichir notre document.
• Factory est là pour configurer notre processor. Elle est obligatoire car elle fait partie de l’architecture de la conception d’un plugin pour Elasticsearch.
• Plugin-descriptor contient les méta-données de notre plugin comme le nom de la classe du plugin, la description.

Je ne rentrerai pas dans les détails pour les tests mais sachez qu’il y a un exemple de test unitaire disponible sur le github donné à la fin de l’article. Il est aussi possible de faire des tests d’intégrations que je n’ai pas détaillés dans la démo.

La classe EnrichPlugin :

package org.elasticsearch.plugin.ingest.search;

public class EnrichPlugin extends Plugin implements IngestPlugin {

   @Override
   public Map<String, Processor.Factory> getProcessors(Processor.Parameters parameters) {
       return Collections.singletonMap(EnrichProcessor.NAME, new Factory());
   }
}

La méthode getProcessors répertorie les processors enregistrés par notre plugin. Ici, nous n’en avons qu’un, donc nous retournons une collection avec un seul élément. On appelle la factory pour créer un processor avec son nom. Comme expliqué plus haut, elle est présente pour configurer notre processor. Il n’y a que peu de configuration à réaliser ici mais elle n’en reste pas moins obligatoire et pourrait servir à créer plusieurs processors si besoin.

La classe Factory :

package org.elasticsearch.plugin.ingest.search;

import org.elasticsearch.ingest.Processor;

import java.util.Map;

public final class Factory implements Processor.Factory {

   @Override
   public EnrichProcessor create(Map<String, Processor.Factory> registry,
                                 String processorName,
                                 Map<String, Object> config) {

       return new EnrichProcessor(processorName);
   }
}

On définit la méthode create pour créer les Processors de manière générale ce qui permettra, suivant le besoin, de créer divers processors pour un seul plugin.

On lui donne un nom de Processor (le processorName) qui permettra d’identifier de manière unique le processor.

La classe EnrichProcessor :

package org.elasticsearch.plugin.ingest.search;

import org.elasticsearch.ingest.AbstractProcessor;
import org.elasticsearch.ingest.IngestDocument;

public final class EnrichProcessor extends AbstractProcessor {

   static final String NAME = "enrich";

   EnrichProcessor(String name) {
       super(name);
   }

   @Override
   public IngestDocument execute(IngestDocument document) {
       document.setFieldValue("enrich", true);
       return document;
   }

   @Override
   public String getName() {
       return NAME;
   }
}

La méthode execute consiste à récupérer un ingestDocument. Cet ingestDocument est le document qui est en cours d’indexation. Par conséquent, en l’état, il n’est pas encore dans Elasticsearch. Vous pouvez donc l’enrichir en ajoutant, par exemple, un nouveau champ. Ici, le processor ajoute le champ “enrich” avec comme valeur true. Et pour finir, elle retourne le document pour l’indexer dans Elasticsearch.

Installation du plugin Elasticsearch :

Une fois votre plugin java terminé, il faut le récupérer en zip. Si vous avez bien préparé le terrain avec ce qui est expliqué plus haut concernant le POM, il vous suffit d'exécuter dans un terminal la commande :

mvn package

Un zip est généré dans votre dossier target que vous allez récupérer. Dans votre dossier Elasticsearch, créez un dossier plugin et collez-y votre zip. Puis installez votre plugin dans Elasticsearch à l’aide de la commande suivante :

sudo /usr/share/elasticsearch/bin/elasticsearch-plugin install file:////usr/share/elasticsearch/plugin/

Votre plugin est enfin fonctionnel. Il faut ensuite créer une pipeline.
Il faudra procéder à un appel REST avec curl (ou autre suivant ce que vous utilisez) pour créer la pipeline en indiquant son nom. Voici un exemple :

curl -H 'Content-Type: application/json' -XPUT 'localhost:9200/_ingest/pipeline/nom_pipeline --data-binary @create_pipeline.json;

Le port 9200 correspond au port par défaut d’Elasticsearch.
Le fichier create_pipeline.json est le contenu de la requête REST. Il va indiquer la liste des processors à créer :

{
   "processors": [
       {
           "enrich": {}
       }
   ]
}

Le nom enrich correspond au nom du processor donné à la classe EnrichPlugin.

Utilisation :
Pour l’utiliser, il faut faire une requête en indiquant, à la fin de celle-ci, “&pipeline=nom_pipeline” lors de l’insertion de données.

curl -H 'Content-Type: application/x-ndjson' -XPOST 'localhost:9200/data-enrich/_doc/_bulk?pretty&pipeline=enrich' --data-binary @data.json;

Voici les données, qui correspondent à notre data.json, avant enrichissement :

{ "index" : { "_id" : "1" } }
{ "name":  "first", "number":  1}
{ "index" : { "_id" : "2" } }
{ "name":  "first", "number": 2}

et voici après enrichissement, affichées via kibana :

On peut voir que le document a bien été enrichi avec le champ enrich à True.

En conclusion

Voici une bonne base pour créer l'ingest plugin dont vous avez besoin. Dans ce tutoriel, il est question de création d’un plugin d’enrichissement mais la base ne change pas d’un plugin à l’autre.

Vous pouvez aussi récupérer des informations d’un Elasticsearch déjà lancé ou du même Elasticsearch sur un autre index si vous le souhaitez.

Dans la démonstration, comme je l’ai dit au début de l’article, les tests unitaires sont déjà présents mais il manque les tests d’intégration.

Maintenant, il ne vous reste plus qu’à adapter ce plugin à votre besoin et d’y ajouter des tests d’intégrations si vous le souhaitez.