En quoi consiste Amazon Athena ?

Amazon Athena est un service permettant d’interroger rapidement des données stockées dans Amazon S3 (d’autres sources seront sans doute supportées plus tard) en utilisant le langage SQL. Le service supporte de nombreux formats de fichier : CSV, JSON, ORC, Apache Parquet et Avro.
Athena est basé sur le moteur Presto 0.172 mais n’en supporte pas toutes les fonctionnalités.

Un des avantages d’Athena est de fonctionner entièrement en serverless : aucun coût d’infrastructure et pas de maintenance à gérer soi-même.
Le service est facturé en fonction du volume de données parcouru par requêtes et plusieurs méthodes existe pour optimiser le coût d’utilisation des services :
• Compresser les données ayant vocation à être analysé par Athena.
• Partitionner les données horizontalement en utilisant des préfixes dans S3.
Pour des données classées par date, nous pouvons utiliser le préfixe suivant : s3://nom-du-bucket/année/mois/jour/heure/nom-des-fichiers.csv.gzip. Cela permet à Athena de ne pas parcourir tous les fichiers à chaque requête.
• Utiliser des formats de fichier en colonne comme Parquet. De cette manière quand une requête ne porte que sur certaines colonnes, seul le volume de données de ces colonnes est facturé..

Athena n’est pas recommandé pour être un entrepôt de données (data warehouse). Pour ce besoin, il vaut mieux se tourner vers Amazon Redshift pour obtenir des performances et un résultat plus intéressant.
En continuant les comparaisons avec les services Data de AWS, Athena est limité à des requêtes SQL uniquement à la différence de Amazon EMR qui propose d’autres frameworks.

Création d’une table sur Athena

Pour pouvoir requêter des données avec Athena, il faut au préalable créer des tables avec un DDL (Data Definition Langage). Suivant la complexité de la structure de nos champs et le nombre de sources de données, les DDL peuvent vite devenir complexe à rédiger.
Voici un DDL servant à la création d’une simple Table dans Athena :

CREATE EXTERNAL TABLE IF NOT EXISTS mydatabase.cloudfront_logs (
 Date DATE,
 Time STRING,
 Location STRING,
 Bytes INT,
 RequestIP STRING,
 Method STRING,
 Host STRING,
 Uri STRING,
 Status INT,
 Referrer STRING,
 os STRING,
 Browser STRING,
 BrowserVersion STRING
 ) ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.RegexSerDe'
 WITH SERDEPROPERTIES (
 "input.regex" = "^(?!#)([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+([^ ]+)\\s+[^\(]+[\(]([^\;]+).*\%20([^\/]+)[\/](.*)$"
 ) LOCATION 's3://athena-examples/cloudfront/plaintext/';

Utilisation combinée avec AWS Glue

AWS Glue est un service d’ETL (Extract-Transform-Load) mis à disposition par AWS et reposant sur des indexeurs (crawlers).
Le crawler Glue est capable de parcourir et d’analyser automatiquement des sources de données afin d’en déterminer la structure et par la suite de créer des tables dans un catalogue appelé « Glue Data Catalog ». C’est ces catalogues qui sont ensuites accessibles depuis Athena.
En combinant l’utilisation du crawler Glue avec Athena, il est possible d’accéder de manière très rapide à des données déja triées.
Il est possible de planifier de manière périodique l’exécution du crawler Glue afin de réduire les interventions humaines et de faciliter l’accès aux données par le business.

Cas d’usage

Présenté lors de la RE:Invent 2017, ce cas d’usage repose sur S3, Lambda, Glue et bien sûr Athena. L’objectif est d’utiliser Athena afin de faciliter la consultation de backup de base de données.

Une base de données est copiée depuis un SGBDR via AWS DMS vers S3. Les fichiers sont sauvegardés au format parquet.
Le dépôt des fichiers dans S3 déclenche l’exécution d’une fonction Lambda qui va lancer le crawler Glue.
Le crawler va parcourir les données afin de mettre à jour le Data Catalog Glue.
Grâce aux catalogues, la base de données et les tables associées à celle-ci sont accessibles directement depuis Athena.

De cette manière, nous avons à disposition un backup accessible sans coût d’infrastructure associé. Seul le volume de données dans S3 et les données parcourues par Athena sont facturés.

Des outils de visualisation tels que Tableau ou Amazon Quicksight peuvent éventuellement être utilisés afin de mettre en places des dashboards.

Vous avez un projet d’entrepots de données ? Des conseils pour optimiser votre architecture existante ? N’hésitez pas à faire appel à nos experts pour vos projets !

Cette supervision est très importante dans un contexte DevOps : une meilleure vision des ressources facilite les prises de décisions, facilite le suivi de performance et permet de réfléchir plus durablement sur l’intérêt d’automatiser les tâches. La bonne mise en place et configuration de ces outils de supervision facilite une notion importante du DevOps : le dialogue entre le Dev et les Ops renforcé par des métriques fiables et partagées.

Nous allons nous pencher sur Grafana et plus spécifiquement la version 6 (une des dernières versions disponibles au moment où nous écrivons cet article). Dans un premier temps, nous aborderons l’intérêt de se baser sur AWS pour établir son outil de monitoring puis nous suivrons pas à pas la mise en place de l’infrastructure proposée.

Grafana est une plateforme open source de visualisation de métriques et de surveillance permettant de réaliser des tableaux de bord et des graphiques. La visualisation des métriques est remontée dès que les données sont disponibles et la plateforme supporte des data sources comme Cloudwatch, Influxdb, Elastichsearch ou Prometheus… Un des avantages de Grafana est aussi sa comptabilité avec plusieurs types d’authentification et ne nécessite donc pas d’utilisateurs IAM à gérer.

Voici quelques avantages à déployer Grafana sur AWS :

• Scalabilité de la base de données
Par défaut Grafana utilise SQLite3 en local mais supporte également MySQL et PostgreSQL. En utilisant Aurora MySql serverless, plus de problème d’évolutivité et le coût est indexé sur l’activité (pay as you go).

• Services managés
Avec des services comme Amazon Aurora ou l’utilisation de Docker avec Amazon ECS et AWS Fargate, plus besoin de gérer la maintenance de base de données ou de cluster ce qui se traduit par un gain de temps considérable.

Notre architecture de test

L’architecture est la suivante : un Application Load Balancer redistribue la charge sur le cluster ECS Fargate qui interroge la base de données Aurora MySQL Serverless.
D’autres services sont appelés afin de superviser (CloudWatch) ou de sécuriser (IAM, Certificate Manager et Route 53).

Place à la pratique

Pour ce tutoriel, on part du principe que le compte AWS est opérationnel et que la couche réseau (VPC, Subnets …) a été créée au préalable.

Création de la base de données Aurora MySQL

Création du cluster ECS

+ Configuration du cluster : création de Task definition Grafana (utilisation du Docker hub pour récupérer l’image Docker)

+ Configuration du cluster : inclure les variables d’environnement qui commence par GRAFANA_DATABASE_*

Task Definition ECS Fargate

+ Configuration de ECS Fargate : création du Service ECS

+ Configuration de ECS Fargate : Configuration du réseau

Permettre l’accessibilité de Cloud Watch <> Grafana avec les policies IAM

Ajouter l’IAM Policy (JSON) disponible sur le site de Grafana.

Configuration des data sources pour Grafana

Cas d’usage : monitoring le coût de run efficacement
IAM Policy pour avoir l’accès à la facturation :

{
 "Version": "2012-10-17",
 "Statement": [
 {
 "Effect": "Allow",
 "Action": [
 "aws-portal:*Billing",
 "awsbillingconsole:*Billing",
 "aws-portal:*Usage",
 "awsbillingconsole:*Usage",
 "aws-portal:*PaymentMethods",
 "awsbillingconsole:*PaymentMethods",
 "budgets:ViewBudget",
 "budgets:ModifyBudget",
 "cur:*"
 ],
 "Resource": "*"
 }
 ]
 }

Un exemple d’un tableau de bord concernant la facturation de services AWS.

Conclusion

Comme vu précédemment, la mise en place d’une plateforme de supervision est une pierre angulaire dans un environnement. Une supervision centralisée, résiliente et capable de croitre selon les besoins peut ne pas être un besoin critique au départ mais s’avère rapidement indispensable. Grâce à AWS, la notion d’agilité est possible grâce au scalling in / out et au paiement à la ressource consommée.

Vous êtes intéressés par le sujet du DevOps ? Notre prochain article à paraitre courant juin, reprends quelques bases sur ce sujet complexe !

Traitement des images et détection des défauts

Les wafers sont photographiés lorsqu’ils sortent de production. L’équipement, basé sur les lignes de productions, alerte une machine que des images de wafers sont disponibles. Une seconde machine virtuelle va chercher le lot d’images, lui applique un identifiant spécifique et envoie la donnée sur Amazon S3 afin de gérer son traitement.

L’arrivée de nouveaux fichiers sur S3 va déclencher un certain nombre d’actions, toutes orchestrées par le service AWS Step Functions. Ce service de AWS permet de coordonner et d’exécuter des actions dans un ordre spécifique. Chaque action étant strictement définie, il est possible d’obtenir un rapport précis en cas d’erreurs.

Une action se déclenche uniquement si les conditions et la tâche précédente ont été réalisées sans problème.

• Pré-traitement de l’image

Cette première action attribue à chaque image un identifiant permettant une rapide indexation des wafers et lui applique des pré-traitements utiles pour la suite du processus.

• Utilisation de Amazon DynamoDB pour la traçabilité des lots d’images.

Les identifiants de chaque lot d’images sont stockés temporairement dans une base de données NoSQL.

• Traitement en simultané des images avec le modèle.

Grâce au service AWS Lambda, les images sont confrontées au modèle établi avec Amazon SageMaker. Lambda gère la scalabilité et est serverless (pas de nécessité de gérer soi-même les serveurs où s’exécute le code). En aucun cas cette étape est un goulot d’étranglement grâce à la capacité de déploiement en simultanée de machines temporaires.

• Détection d’une défaillance possible

Si une anomalie a été détectée, un rapport d’erreur est produit indiquant où sur l’image le défaut est décelé. Grâce à l’indexation de l’étape 1, le lot de wafer imparfait est facilement identifié.

• Alerte de la fin du traitement

Une fois l’éventuel rapport d’erreur créé, une alerte est envoyée aux équipes en charge.

Avec une fiabilité de l’algorithme de plus de 98%, le résultat obtenu est largement digne de confiance et permet d’engager les opérateurs de Soitec sur des tâches plus sophistiquées et moins répétitives.

Pour conclure, voici les avantages de l’industrialisation du système :

• Optimisation financière grâce aux services serverless (paiement à la ressource consommée), à un stockage peu cher (S3) et à un environnement reposant sur des services managés (pas de frais externes à l’utilisation du service)

• Sécurité des informations entre les ressources sur site et le cloud de AWS très importante (segmentation du réseau grâce au VPC, règles de firewall et d’accessibilité précises)

• Scalabilité très importante du fait des services AWS mobilisés. Le traitement des images n’est pas limité par un seuil maximal et toutes les comparaisons avec le modèle sont faites simultanément quelle que soit la charge.

• Déploiement facilité grâce à AWS SAM. SAM est une extension de Cloud Formation permettant de déployer des environnements serverless déjà configurés.

Centralisant les ressources sur une seule stack, SAM garantit le bon déploiement de l’infrastructure sur un environnement de production et simplifie la maintenance.

Si vous aussi, comme Soitec, vous souhaitez vous emparer des opportunités qu’offrent le cloud de AWS, n’hésitez pas à nous contacter ! Nous mettrons tout en œuvre pour vos projets de migration, d’optimisation et de développement afin de rendre vos idées une réalité.

Produit phare de l’entreprise, le wafer est un disque fin semi-conducteur qui sert de support pour des circuits intégrés ou des transistors. La qualité du produit et sa vérification étaient réalisées à la main où chaque lot de wafer était observé afin d’éviter tout produit défectueux.

La volonté d’automatiser le processus de validation et la possibilité de remonter les potentielles anomalies aux équipes ont été l’opportunité de mobiliser certaines innovations portées par le cloud.

Nos experts à Corexpert et à TeamWork ont travaillé de concert pour aboutir à un résultat fiable, performant et économique. Nous avons mobilisé notre savoir-faire et les services d’AWS tels que  Amazon SageMaker, Amazon S3, AWS Step Functions, AWS Lambda et Amazon DynamoDB afin de concilier les ressources sur site et celles présentes dans le cloud.

La détection d’imperfections sur les wafers repose sur un algorithme fiable à plus de 98%, un résultat bien au-delà des attentes fixées par Soitec. Cela est aussi largement supérieur à l’algorithme de traitement d’image classique utilisé jusqu’à présent (qui n’est pas évolutif et demande un calibrage très précis à chaque maintenance de la machine) ou aux résultats d’humains (qui fatiguent vite sur ce poste pénible et laissent passer des défauts).

Ce projet a été présenté durant le AWS Summit Paris 2019 avec la participation de l’entreprise et nous vous proposons deux articles afin d’appréhender le travail effectué. Dans un premier temps, nous nous concentrerons sur la partie Deep Learning et la création du modèle vérifiant l’état du produit. Dans une seconde partie, nous aborderons le côté industrialisation et automatisation de l’infrastructure du projet.

Plan d’architecture présenté lors du AWS Summit de Paris en 2019

Deep Learning, modèle et fiabilité

L’intérêt de mobiliser les méthodes d’apprentissage automatique est de repérer les anomalies rapidement et de pointer précisément où l’imperfection se situe. Ces techniques permettent de réduire les erreurs sur des tâches laborieuses et ne nécessitent pas de connaissances spécifiques quant au produit.

La gestion des données de référence et le déploiement des modèles d’apprentissage ont été réalisés grâce au service Amazon Sagemaker. SageMaker a la particularité d’être un service managé permettant à tout développeur et spécialiste de créer, modifier et tester des modèles de données. SageMaker prend en charge et optimise les principaux frameworks utilisés dans le Machine Learning tout en permettant d’ajouter ses propres configurations.

Pour obtenir le meilleur résultat, plusieurs modèles sont configurés afin de déterminer lequel est le plus apte à détecter des défauts.

Ce graphique illustre bien comment un modèle est généré à partir de données brutes. Sagemaker permet de préparer les tâches d’apprentissage (via les notebooks), d’entrainer les modèles (jobs), puis d’étudier les modèles obtenus (models) et enfin de les déployer et d’obtenir une API pour les interroger (endpoint).

Dans un ensemble de données (data set), on sélectionne un panel d’images aléatoirement puis on l’entraine à reconnaitre les wafers conformes à ceux ayant des anomalies. Une intervention humaine peut être intégrée afin de trier les données ambiguës.

En cas de surentrainement, le modèle ne se réfère plus qu’à un produit spécifique et interprète toute déviation comme anomalie. Et à l’inverse, un modèle peu entrainé risque d’accepter des pièces souffrant de défauts mineurs comme des références. Le but est d’arriver à un équilibre entre entrainement (basé sur le data set) et capacité du modèle à déduire les défauts sur une pièce originale.

Une fois le modèle testé et validé, il est temps de le confronter aux lots d’images de wafers sortant des chaînes de production. La vérification est faite via une API créée également à partir de Sagemaker.

En conclusion :

• Amazon SageMaker est un service managé intégrant un grand nombre de frameworks facilitant la création et les tests de modèles de données.
• Plusieurs modèles sont créés pour obtenir celui qui est le plus apte à reconnaitre les erreurs.
• Il est toujours possible d’enrichir le modèle grâce à l’ajout de données sur le data set.
• La vérification entre le modèle et les images à vérifier se fait facilement grâce à une API.

Nous avons terminé sur la partie machine learning du projet, nous verrons dans un prochain article comment l’automatisation de la solution a été mise en place !

Au lieu d’effectuer un inventaire des nouveaux services (qu’AWS a très bien fait de son côté), nous avons interrogé les membres de l’équipe ayant décollés pour Las Vegas. Quels sont les services et fonctionnalités les plus intéressantes annoncées ? En tant que participant, quels sont les points forts de cette Re:Invent ? Des points négatifs ?

Sylvain (Professional Solutions Architect AWS)

Pour sa deuxième année consécutive de participation au Re:Invent, Sylvain est très intéressé par les mises à jour concernant serverless.

StepFunction – l’orchestration des services est facilitée avec l’intégration de nombreux services (ECS, Fargate, DynamoDB, SNS, SQS, Batch, Glue et SageMageker) facilitant l’automatisation, la sécurité et la supervision des workflows. Pour en savoir plus…

Lambda avec ALB – Application Load Balancers (ALB) peut maintenant être lié avec des Lambdas pour les requetes HTTPS. Un schéma pour mieux comprendre

♥ Keynote d’Andy Jassy
♥ Rencontres avec la communauté
♥ Goodies ou Swag
♥ Certifications accessibles

⊗ Beaucoup d’informations à absorber
⊗ Versatilité du niveau des sessions / workshops : il est difficile de cerner le niveau / qualité des ateliers et des intervenants.
⊗ Canadiens ont eu un swag spécial indisponible aux Français !

Mohamed (Professional Solutions Architect AWS)

Première expérience de la Re:Invent pour Mohamed qui a particulièrement apprécié les alternatives proposés par AWS pour le réseaux et une nouvelle base de données time series.

Transit Gateway – un hub central de connexion entre les VPC d’AWS et une infrastructure on-premise. Simple et facile, fini les bricolages à base de rebond SSH ou de redirection de port avec NGINX. En savoir plus…

Timestream – une base de données managée time series, alternative à DynamoDB (avec un pattern spécifique) et à d’autres solutions Opensource tel qu’InfluxDB.

♥ Ambiance (course de DeepRacer, nombreuses animations & jeux)
♥ Re:Play (Skrillex)
♥ Logistique impressionnante

⊗ Énormément d’informations à digérer
⊗ Pas assez de sessions niveau 400
⊗ Le jet-lag

Marouen (Professional Solutions Architect AWS)

Les mises à jour apportant de la flexibilité à l’usage des services AWS ont été retenu par Marouen.

DynamoDB On demand – la base de données NoSQL de AWS est maintenant bien plus flexible : il n’est plus nécessaire de surdimensionner les tables afin de pouvoir absorber les pics d’activités. En savoir plus…

Amazon FSx – plus besoin de devoir monter un EFS sur Linux et de le partager en SMB afin de pouvoir exploiter un file system managé et distribué sous Windows

♥ Les chat talk permettant de poser des questions aux Product Owners des services AWS
♥ Les jokes sur Oracle lors des Keynotes
♥ La nourriture à profusion

⊗ Las Vegas (le bruit, les casinos…)

Germain (Sales Executive)

Germain a apprécié la volonté d’AWS d’améliorer les solutions cloud hybrides.

Amazon Outpost – ce service permet d’harmoniser les services et fonctionnalités d’AWS avec ceux présents on-premise et vice-versa !
Actuellement en preview, pour en savoir plus et s’inscrire…

VMware on AWS – l’intégration de VMware Cloud sur AWS est renforcé avec Outpost mais aussi avec l’intégration du service de base de données managées Amazon RDS dans l’environnement VMware.

♥ Keynotes : immanquable mais dense techniquement
♥ De plus en plus de place aux profils non techniques
♥ Vu 360° des offres AWS et périphériques, particulièrement crucial pour se projeter à moyen-terme sur le marché

⊗ Nécessite plus de préparation : un ciblage plus en amont des sessions, une arrivée à l’event plus tôt, etc.

Encore à l’affût d’informations ? Vous pouvez retrouver les sessions enregistrées et toutes les vidéos tournées durant le Re:Invent 2018. Les slides sont disponibles également.

D’autres interrogations ? Vous souhaitez profiter des avantages du cloud ? Un projet de migration ? Contactez-nous !