Archives de
Auteur : corexpert

How-to : Grafana 6 sur AWS avec Docker

How-to : Grafana 6 sur AWS avec Docker

Le maintien d’une infrastructure et l’optimisation des ressources sont des tâches qui nécessitent une vigilance quotidienne et des plateformes comme Grafana, Kibana ou Chronograf sont une pierre angulaire dans la surveillance des systèmes d’information.

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).

grafana-architecture

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

grafana-auroramysql

Création du cluster ECS

grafana-cluster-ecs

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

grafana-taskdefinitionDocker

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

grafana-databaseconfig

Task Definition ECS Fargate

grafana-fargate

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

grafana-fargate-serviceecs

+ Configuration de ECS Fargate : Configuration du réseau

grafana-reseau

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

grafana-datasources

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

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

grafana-dashboard-billing

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 !

Corexpert, way to performance !

Corexpert, way to performance !

Le chef de projet est la personne dans l’entreprise organisant et assurant le bon développement de projet jusqu’à sa réalisation. Son objectif est de superviser les différentes tâches telles que le respect des deadlines, la maîtrise des coûts ou la répartition du travail au sein d’une équipe…

Chez Corexpert, deux chefs de projets pilotent notre équipe de développeurs et d’architectes : Robin présent dans l’entreprise depuis 5 ans et Gaël arrivé dernièrement. Pour nos deux experts, le métier de chef de projet a été un développement professionnel qui s’est greffé à leur ancien poste de développeur.

Gaël a débuté en tant que développeur au sein d’une grande entreprise de construction puis est devenu responsable suivi de production. Aujourd’hui chargé du suivi de l’infrastructure, sa précédente expérience lui a permis d’avoir une vision générale sur le sujet : grâce à son savoir technique, Gaël a rapidement pris ses marques au sein de Corexpert et il supervise de nombreux projets de l’avant-vente à la mise en production.

Avant de devenir chef de projet, Robin a effectué ses 8 premiers mois chez Corexpert, en tant que développeur mobile IOS. Au fur et à mesure, Robin a aménagé son temps entre développement et gestion de projet afin de répondre au mieux aux problématiques clients. Cela fait maintenant trois ans qu’il est chef de projet à plein temps orienté développeur.

Même si Robin et Gaël ont la charge d’équipes à la fois distinctes et complémentaires, rien ne les empêche d’avoir une perspective globale sur l’ensemble des projets en cours qu’ils soient développeurs ou architectes. Les deux pôles sont complémentaires et ceux malgré le fait que les projets ne mobilisent pas les mêmes compétences. Le cœur de la gestion d’un projet reste identique, le but étant de mener à bien le projet et ce dans les temps et avec le budget alloué.

Pour Robin, il est primordial d’avoir des connaissances dans les deux pôles « on a besoin d’avoir des connaissances dans les deux domaines que ce soit de l’infrastructure ou du code. De mettre en commun nos compétences pour arriver à un projet solide et fiable, capable de satisfaire les besoins de nos clients ». Gaël, rejoint l’idée de Robin en ajoutant le fait que le fait de posséder un savoir large permet de se partager plus efficacement les projets afin d’être plus disponible pour le client.

Fonction Chef de Projet

La plateforme leader du cloud, AWS, dispose de nombreux services : le choix du service à mettre en place pour accomplir le projet est souvent matière à réflexion. Pour Robin, la gestion de projet repose sur la complémentarité d’une équipe : « La plateforme AWS dispose d’une multitude de services, l’équipe sait comment les utiliser mais le chef de projet va savoir orienter son équipe sur les meilleurs services en termes de performances et de coûts. » C’est d’autant plus vrai que chaque membre de l’équipe tend à se spécialiser et une bonne organisation des tâches favorise un environnement de travail agréable : le client est assuré d’avoir un expert positionné sur la question et l’expert travaille sur un projet qui l’intéresse.

De plus, avoir été « sur le terrain », permet selon Robin et Gaël, de bénéficier d’une connaissance globale d’AWS et de gagner en réactivité : nul besoin de solliciter les équipes pour certaines questions auxquelles le chef de projet peut répondre sereinement. Les besoins des clients sont plus rapidement cernés et l’offre est adaptée à leurs besoins.

Si vous êtes intéressés à travailler avec les équipes de Corexpert, n’hésitez pas à nous contacter ! Nous saurons vous accompagner dans vos projets de machine Learning, Big Data, migration…

 

Réseau mondial, où centraliser ses données ?

Réseau mondial, où centraliser ses données ?

Introduction

Grâce à ses multiples régions à travers le monde, AWS offre la capacité de créer une infrastructure réseau couvrant la totalité du globe. Dans ce cadre la question de l’emplacement des données se pose : doivent-elles être centralisées dans une région, ou réparties selon les besoins ?
Pour apporter un élément de réponse à cette problématique, nous nous sommes penchés sur les vitesses de transfert de données inter-région. Pour cas d’usage, nous avons pris un environnement Windows avec des utilisateurs travaillant sur des machines pour traiter/manipuler des données de projets hébergées sur un serveur de fichiers.

Un peu de théorie

Lorsque qu’un message est envoyé d’une machine à une autre, il va mettre un certain temps pour parcourir le chemin à travers le réseau. Ce temps est appelé la latence. On peut consulter un tableau des latences entre les régions AWS sur le site www.cloudping.co :

graphique-1

On vous déconseille de transférer des fichiers de São Paulo à Mumbai.

Lors du transfert d’un fichier, plusieurs messages sont échangés entre les machines, notamment à l’initialisation de la connexion puis durant le transfert car le fichier va être découpé en plusieurs messages. Le nombre d’échanges est dépendant du protocole de communication utilisé. Plus il y a d’échanges, plus la latence va impacter le temps total de transfert.

En pratique

Durant nos tests, en plus de comparer les temps de transfert entre les régions, nous avons également voulu voir l’impact de la version de Windows Server du côté de l’hébergeur et de la consommation des données.

Notre protocole de test :

  • Infrastructure réseau répartie sur les régions Oregon, Ireland et Singapore (liaison avec VPC peering)
  • 4 serveurs Windows Server 2008 R2, 2012 R2, 2016 et 2019 par région
  • Fichiers de test : un dossier de 400Mo contenant 210 fichiers allant de 52k à 100Mo
  • Outils de transfert : robocopy

La mise en place de l’infrastructure et les tests ont été automatisés à l’aide des services AWS CloudFormation et AWS System Manager.

Infrastructure réseau :

Infra Reseaux TestQuatre type de Windows Server (2008 / 2012 / 2016 / 2019) dans trois régions AWS distinctes (Oregon / Ireland / Singapore)

Les latences observées entre les régions :

  • Oregon – Ireland : 160 ms
  • Oregon – Singapore : 170 ms
  • Ireland – Singapore : 190 ms

Résultats des transferts :

graphique-2

graphique-3

graphique-4

On peut constater plusieurs points :

  1. Les temps de transfert sont sans commune mesure à l’intérieur d’une même région.
  2. La liaison Oregon-Ireland est plus rapide qu’Oregon-Singapore
  3. Selon la version de Windows Server, on peut avoir près de 50% de temps de chargement en plus.

Conclusion

Malgré la qualité des connexions réseaux, la distance entre les données et les utilisateurs est un facteur primordial pour une expérience de travail optimale. Il faut donc privilégier les courtes distances.

Pour pallier ce problème, nous pouvons nous appuyer sur l’offre End User Computing d’AWS qui fournit des machines de travail au plus près des données : Amazon WorkSpaces et Amazon AppStream 2.0. L’un est un service de desktop streaming et l’autre d’application streaming.

Tous deux sont accessibles par internet depuis le monde entier et utilisent des protocoles sécurisés et optimisés. En les intégrant dans un domaine Active Directory, ils offrent une porte d’entrée sécurisée vers votre système d’information, sans contraintes de mise en place de configuration réseau entre vos utilisateurs ou prestataires externes.

Vous voulez en savoir plus sur les possibilités de déploiement de Amazon WorkSpaces et Amazon AppStream 2.0 ? N’hésitez pas à nous contacter !

Itinéraire d’un projet IA : Automatisation

Itinéraire d’un projet IA : Automatisation

Dans notre article précédent, nous avons vu comment mobiliser les techniques de Deep Learning et Amazon Sagemaker pour établir un modèle de données permettant de distinguer un wafer défectueux d’un wafer de bonne qualité. Nous allons maintenant aborder l’industrialisation et l’automatisation de la solution.

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.

ml-part-2

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é.

Retour sur l’AWS Summit Paris 2019

Retour sur l’AWS Summit Paris 2019

Le mardi 2 avril 2019, Corexpert était présent au Palais des Congrès pour participer à l’AWS Summit Paris 2019. Cette journée consacrée au cloud AWS a permis de rassembler partenaires et public autour des thématiques du cloud et permettre une plus grande accessibilités des acteurs de l’innovation !

La Keynote d’ouverture introduit par Julien Grouès, directeur général d’AWS en France, s’est avérée révélatrice du potentiel du monde numérique français qui prend de l’ampleur au fil des années : 300 participants seulement il y a 7 ans contre plus de 7000 aujourd’hui, 30 témoignages clients et 70 sponsors. Des retours d’expériences de prestigieuses entreprises aux domaines diverses ont accompagné le discours du CEO français d’AWS et marqué l’ouverture de cette journée de collaboration.   

Tout au long de la journée, le dialogue était au rendez-vous. Corexpert et TeamWork ont pu échanger avec le public sur les très nombreuses thématiques et innovations proposées par la plateforme leader du marché. Corexpert a vu son stand accueillir des amateurs intéressés ou plus expérimentés en recherche d’informations complémentaires pour parfaire leur aventure dans le cloud. Jean-Cloud lui même a rencontré un franc succès chez les visiteurs !

PrésentationSoitec

Lors d’une conférence, Corexpert et Teamwork ont partagé, devant un large public, leurs travaux sur l’itinéraire d’un projet IA avec le témoignage de notre client Xavier Michallet, responsable du département Data de Soitec. Les techniques liés à l’IA sont de plus en plus intégrées dans les processus industriels et ouvrent de nombreuses perspectives. Sur des tâches laborieuses ou peu complexes, la mise en place de techniques de machine learning permettent un contrôle qualité optimal et d’engager des ressources sur des tâches plus sophistiquées et à valeurs ajoutées.

Vous pouvez retrouvez plus de détails dans nos articles dédiés à cette présentation : sur la partie Machine Learning du projet et sur la partie industrialisation de la solution.

AWSUserGroup

Ce fut également l’occasion pour les communautés AWS françaises de se réunir autour d’un stand pour échanger et partager leurs connaissances avec les visiteurs du Palais des Congrès. Toujours un moment convivial, les AWS User Groups sont un moyen d’accroitre ses connaissances et de partager des retours d’expérience ou des ateliers autour d’AWS. Vous pouvez trouver facilement un près de chez vous ! Si vous êtes Lyonnais, n’hésitez pas à rejoindre le groupe !

L’AWS Summit Paris 2019 marque aussi le lancement du championnat de course autonome : la DeepRacer League a été animée tout au long de la journée par le commentateur Marc Chavet. La course de DeepRacer League consiste à faire rouler une mini-voiture pilotée grâce au reinforcement learning partie avancée du Machine Learning. L’objectif est de réussir des tours de circuits avec un temps de parcours le plus court possible !

Deux de nos collaborateurs chez Corexpert se sont lancés dans l’aventure dans l’espoir de remporter la AWS DeepRacer Cup avec un succès mitigé. Une victoire à la course permettait de sécuriser un spot pour la grande finale qui aura lieu lors de la Re:invent 2019 aux Etats-Unis.

DeepRacer1

Nous avons également participé à l’AWS GameDay le lundi 1 avril ! Un jour avant le début du AWS Summit Paris, Corexpert et TeamWork étaient présents pour relever le challenge. L’objectif du GameDay est résoudre un problème donné avec des ressources AWS bien définies. Pour cette session, 3 applications devaient être déployées et des points étaient attribués selon le succès ou l’échec des requêtes.
Une attention particulière était portée sur la scalabilité de l’ensemble afin de résister à toutes charges. “Everything fails all the time” dixit le CTO de AWS, Werner Vogels, et une partie de cette problématique se retrouvait dans le projet à mener à bien !

Les équipes devaient en permanence surveiller et vérifier le bon fonctionnement de leur infrastructure mise à mal par un groupe pouvant changer certaines configurations (comme les tables de routage…).
Notre équipe a su démontrer son efficacité : dans le délai de 2h30, Jeremy,
Marouen et Yahya ont su gagner la seconde place du concours pour leur première participation ! 

GameDay

Itinéraire d’un projet d’IA : Machine Learning

Itinéraire d’un projet d’IA : Machine Learning

Soitec est une entreprise française concevant et produisant des matériaux semi-conducteurs utilisés dans de très nombreux équipements électroniques (smartphones, ordinateurs, automobiles…). Fondé en 1992, Soitec emploie un millier de personnes dans le monde, possède des sites industriels en France et intervient sur le marché mondial.

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-architecture

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.

graphique

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 !

Nouvelles têtes chez Corexpert !

Nouvelles têtes chez Corexpert !

De quelques employés en 2008 à une trentaine aujourd’hui, Corexpert est réputé pour son expertise et sa connaissance dans l’environnement d’AWS. C’est grâce à une équipe dynamique et qualifiée que nous pouvons conseiller et élaborer des projets d’envergure. En février, Damien et Pablo ont intégré l’équipe en tant que respectivement architecte solution et développeur. Nous avons profité de l’occasion pour leur poser quelques questions sur leur venue à Corexpert.

Tout d’abord, pourquoi avoir choisi Corexpert plutôt qu’une autre entreprise de service du numérique (ESN) ?

Damien : C’est une bonne question ! Corexpert est en concurrence avec d’autres entreprises dans le milieu. C’est en discutant avec mes relations issues de mon expérience (je travaille depuis plus de 20 ans dans l’informatique) que TeamWork et Corexpert ont été particulièrement mentionnées. Je souhaitais me tourner pleinement sur AWS et plus spécifiquement sur la technique, chose qui manquait dans mon précédent emploi.

Pablo : Avant de commencer chez Corexpert, je travaillais déjà dans une grande entreprise d’informatique. J’avais aussi envie de découvrir le cloud de AWS et de travailler grâce à des techniques en constantes innovations et d’avoir de l’autonomie sur un projet. Je souhaitais me sentir en confiance avec l’équipe de travail, qu’il existe un véritable échange et c’est le cas chez Corexpert.

Parmi la diversité d’activités que Corexpert propose, peux-tu nous citer les éléments les plus intéressants à ton sens ?

D : Le plus intéressant chez Corexpert c’est que nous avons une vision globale du projet, c’est-à-dire que nous ne participons pas uniquement à une phase mais à la totalité d’une mission. Avant-vente, conception, tests, mise en production, c’est plutôt stimulant de pouvoir s’investir dans les étapes intermédiaires du projet.

P : Je suis très autonome dans la réflexion de projet : j’adore le fait que je puisse proposer et trouver des solutions par moi-même. L’équipe qui m’entoure est très proche que ce soit lors de mes questions ou en cas de problème. La possibilité de s’autoformer, de participer à des workshops mais aussi de développer son anglais grâce à une intervenante extérieure est un véritable avantage.

Pablo-DamienPablo et Damien ont rejoint Corexpert en février 2019

Comme tu le sais, nous évoluons dans un monde où de nombreuses entreprises se spécialisent dans le cloud avec de nombreuses avancées technologiques telles que le développement de l’IA, que penses-tu de ces avancées ?

D : Ces avancées vont très vite et ce n’est pas sans conséquence. Nous avons à peine le temps de commencer à maîtriser une de ces technologies que nous en voyons une autre apparaître. L’évolution de l’informatique est exponentielle ! Les innovations sont constantes et c’est pourquoi la formation est primordiale. C’est une véritable opportunité qu’offre Corexpert de se former sur le cloud leader du marché.

P : Je suis particulièrement intéressé par l’Intelligence Artificielle et plus spécifiquement sur le Machine Learning. Grâce au Deep Learning, de très nombreuses possibilités nous sont ouvertes ! J’ai commencé à travailler sur un modèle d’interprétation qui concerne les cryptomonnaies et je compte bien développer ce projet avec les connaissances acquises avec Corexpert.

Damien tu viens d’un milieu assez similaire, pourquoi avoir voulu se tourner vers le cloud ?
Le cloud à ses débuts, je n’y croyais pas, je parle de cela il y a quelques années. Petit à petit j’ai vu son essor et l’importance qu’il a pris en si peu de temps. C’est à ce moment que je me suis dit qu’il fallait que je me lance. C’est un bouleversement, une grande étape dans la consommation de l’informatique.

Quant à toi Pablo, tu as choisi de t’orienter sur l’informatique après une première expérience dans l’architecture, pourquoi ce choix ?

Le numérique m’a toujours plu même durant l’architecture, je n’étais jamais loin du système informatique. Je trouve que l’informatique est un moyen de création. Les outils dans l’architecture nécessitent plus d’intermédiaires pour créer un bâtiment; ils sont souvent difficiles à mettre en place et alors qu’en revanche, l’informatique est plutôt un accélérateur dans un projet.

Comme Pablo et Damien que tu sois Ingénieur(e), Technicien(ne), Autodidacte, n’hésite pas à nous contacter, nous sommes toujours à la recherche de nouveaux talents. C’est la richesse des parcours de chacun qui fait notre force.
Nos offres d’emplois sont consultables sur notre site.

ELL’OWEB : découverte des services Amazon & introduction à l’IA

ELL’OWEB : découverte des services Amazon & introduction à l’IA

Corexpert soutient de nombreuses actions sur le territoire Rhône-Alpes et en particulier sur la promotion du numérique pour tous et toutes. Nous pensons que la diversité des profils et des parcours sont des atouts dans notre cœur de métier. Depuis 2018, Corexpert est en lien avec OPE (Objectif pour l’Emploi) et participe aux actions de l’association.

L’association OPE
OPE (Objectif Pour l’Emploi) est une association qui a pour but de favoriser l’égalité des chances en accompagnant les choix d’orientation et l’insertion professionnelle.

En 2018, Corexpert devient partenaire de l’association OPE, en participant à deux programmes :

· ITD (“Ingénieur-e & Technicien-ne de Demain”)
Le manque de figure d’identification pour les jeunes filles est l’une des causes explicatives de la désaffection de ces dernières pour les métiers du numérique. L’objectif est alors de faciliter les processus d’identifications grâce aux témoignages d’ingénieures et de techniciennes dans les établissements scolaires.

· ELL’OWEB
Le programme, lancé en 2017, permet de sensibiliser et d’initier des lycéennes aux métiers du numérique, en participant tous les mercredis à des ateliers gratuits sur diverses thématiques (développement web, sécurité des données…).

ELL’OWEB : La promotion 2018-2019
Cette année, les lycéennes se lancent dans la création d’un t-shirt, en participant à plusieurs ateliers sur la création du site web, du logo…

Corexpert, dont la session se déroulera le 6 mars 2019, leur permettra de découvrir plusieurs services AWS (API Gateway, Lambda, StepFunctions, DynamoDB, S3) et de s’initier à l’Intelligence Artificielle.

Architecture-elloweb.

L’atelier, d’une durée de deux heures, portera sur la création d’un dessin via une IA, qu’elles pourront intégrer, par la suite, à leur site web et/ou leur t-shirt. Les lycéennes coderont les 11 fonctions Amazon Lambda que nous leur avons préparées. A la fin de l’atelier, les lycéennes auront la possibilité de continuer à améliorer leur IA en notant les différentes images depuis leur compte Slack, et pourront choisir de partager leurs plus belles créations sur le compte Twitter de leur promotion.

Au terme de l’atelier, une invitée surprise nous parlera de son parcours exceptionnel, conjuguant études universitaires et sport de haut niveau.

Sortie du livre « Intelligence artificielle pour les développeurs » de notre experte IA

Sortie du livre « Intelligence artificielle pour les développeurs » de notre experte IA

Virginie Mathivet est directrice de la R&D et travaille au sein du laboratoire d’innovation (InTW’IT) de TeamWork en tant que spécialiste Intelligence Artificielle.

Également conférencière et auteure, son dernier livre vient de sortir aux Editions ENI. Nous en avons profité pour lui poser quelques questions.

D’où vient cette idée de livre ?

Dans une « ancienne vie », j’étais professeure d’intelligence artificielle. Souvent mes étudiants me demandaient des livres pour creuser le sujet, mais malheureusement la majorité des livres en français ne contenaient que des formules mathématiques. Et mes étudiants n’aimaient globalement pas les maths… sans compter que les concepts étaient souvent peu clairs, pas assez illustrés, et l’approche un peu trop « rude ».

Bref, j’ai eu envie d’écrire le livre que j’aurai aimé trouver lorsque j’étais étudiante. Le concept a plu et c’est ainsi qu’est né le premier livre de cette série, puis les suivants (NDLR : le livre qui vient de sortir est le 4ème).

Du coup, que retrouve-t’on dedans ?

Chaque chapitre est construit de la même manière : la première partie amène les concepts à comprendre sur une technique d’IA (comme les systèmes multi agents ou les algorithmes génétiques). Ces concepts sont expliqués à travers d’explications imagées, d’exemples ou d’analogies simples à comprendre, sans équations mathématiques complexes (pas de démonstrations non plus). N’importe qui, quel que soit son niveau, peut donc lire cette première partie. Elle se termine toujours par des cas d’usages réels et publics.

La deuxième partie du chapitre concerne plus les développeurs. En effet, chaque technique est codée depuis 0 en Java ou en C# (selon la version du livre), pour expliquer à quoi cela correspond en pratique, et comment créer un système de toute part.
Même si j’utilise principalement le Python en entreprise et que je me base sur des frameworks déjà codés, il est toujours intéressant de comprendre ce qu’il y a derrière. Et l’IA ne se limite pas au Python !

l-intelligence-artificielle-pour-les-developpeurs-concepts-et-implementations-en-c-2e-edition

Et le Deep Learning ?

Un des chapitres est dédié aux réseaux de neurones. Le Deep Learning n’est qu’une de ses branches, et donc on le retrouve en bonne place dans ce chapitre. Cependant, la majorité des concepts s’appliquent à tous les réseaux de neurones, le deep learning n’étant qu’un ensemble d’architectures « profondes » (au sens où on trouve beaucoup de couches de neurones).

Vous pouvez retrouver les livres de Virginie Mathivet directement sur le site de l’éditeur ENI ou sur les sites de vente en ligne.
Virginie Mathivet animera également un webinaire le 1er mars 2019 sur la thématique « Le Deep Learning : concepts et cas d’usage ». Pour vous inscrire c’est ici !

Le Service Level Agreement chez AWS

Le Service Level Agreement chez AWS

Article mis à jour le 16 janvier 2019 avec l’ajout du SLA pour 3 composants du service Kinesis (Data Firehouse / Video Streams / Data Streams)

Chez Corexpert, nos clients nous posent souvent cette question :

« On nous parle toujours de Haute Disponibilité et Très Haute Disponibilité chez AWS, mais s’engagent-ils vraiment ? Existe-t-il un SLA ? »

Qu’est ce que le SLA ?

Le SLA, ou Service Level Agreement, est le niveau de qualité et de performance contractuel d’un service ou d’une infrastructure technique. Dans le cas de AWS, fournisseur Cloud, on parlera donc bien d’un service, vu qu’on évolue dans le monde IaaS – Infrastructure as a Service !

Le SLA doit cadrer en premier lieu de quelle fourniture nous parlons, et les critères de performances sur lesquels le fournisseur va s’engager. On pourra donc parler de temps de réponse, de fonctionnalité assurée, de disponibilité complète du service etc.

SLA chez AWS

Nous allons parcourir ci-dessous les principaux services ou services majeurs de l’offre AWS, qui possèdent un SLA à la date de rédaction de cet article. Bien évidemment la liste est non exhaustive.

Amazon Route 53 : SLA du DNS AWS

Le service DNS de AWS, Amazon Route 53, possède un SLA de disponibilité du service du niveau le plus haut possible. En effet, on a ici un engagement de disponibilité de 100% sur le service, ce qui est explicité par « Amazon Route 53 n’échouera pas pour répondre à vos requêtes DNS dans le cycle de facturation d’un mois ». Pourquoi parler d’un mois ? Car AWS, s’engage, en cas d’éventuelle défaillance avérée, de vous rembourser sous forme de crédits sur ce cycle de facturation.

sla-amazon-route-53

Extrait de la page SLA – Amazon Route 53 au 10 janvier 2019

Amazon EC2 ou Elastic Cloud Compute : SLA des VM AWS

Service principal de AWS, Amazon EC2 et Amazon EBS fournissent respectivement l’hyperviseur managé pour exécuter vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store (EBS). Le SLA a été étendu à Amazon Elastic Container Service (ECS) et AWS Fargate (deux services ayant traits aux conteneurs Docker) depuis 2018.

Le SLA des services, avec l’engagement de Amazon Web Services, est d’au moins 99.95% mensuel. Soient moins de 22 minutes.

Si une indisponibilité est avérée entre 99.90 et 99.99%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2 et en deçà de 99.0% de disponibilité AWS propose une remise de 30% en crédits.

Il est important de noter que le SLA est lié à l’état « Region Unavailable« . Si vous ne le savez pas déjà, une région est l’ensemble de plusieurs zones (2+) de disponibilités mais dans le cadre du SLA, AWS précise que l’état « Région indisponible » vous concerne si plus d’une zone de disponibilité où vous exécutez des instances EC2 est indisponible, c’est-à-dire que les instances n’ont plus accès à Internet.

L’indisponibilité de EBS est avérée lorsque les volumes de stockage ne génèrent plus d’I/O avec une file d’attente non vide.

Amazon RDS, SLA des bases de données managées AWS

Amazon RDS est le service de Base de données managée par AWS, il supporte à ce jour MySQL, Oracle, PostgreSQL, MariaDB, Microsoft SQL Server, AuroraDB. Mais le SLA proposé par AWS, concerne uniquement les instances Multi-AZ (c’est à dire avec un serveur en Stand-By mode dans une autre zone de disponibilité) des moteurs SQL : Oracle, MariaDB, MySQL & PostgreSQL. Ce SLA est de 99.95% de disponibilité du service. L’indisponibilité est avérée quand toutes les requêtes de connexion échouent pendant une minute sur l’instance RDS multi-AZ.

sla-amazon-rds

Engagement de AWS pour RDS et remboursement en crédits au 10 janvier 2019

Amazon S3, SLA du stockage AWS

Amazon S3 est le service de stockage d’objets, il est l’un des plus anciens services de AWS et possède une durabilité des données de 99.999999999% en mode de stockage standard. Toutefois le SLA concerne la disponibilité d’accès à la données stockée via l’API AWS. Le SLA de Amazon S3 est donc calculé sur le comptage d’erreurs ou d’indisponibilité de l’API sur 5 minutes.

L’engagement de AWS est de conserver une disponibilité au-delà de 99.9% mensuel, ce qui représente moins de 43 minutes 12 secondes.

Si AWS ne peut assurer cette disponibilité sur la région où est stocké votre bucket S3, alors 10% de remise sur le coût de stockage S3 seront reversés en crédits, et en deçà de 99.0%, alors la remise en crédit s’élèvera à 25% du coût du service Amazon S3.

Depuis janvier 2019, ces règles ont été étendues à Amazon Elastic File System (EFS) avec les mêmes engagements que pour S3. Amazon EFS est un système de stockage de fichiers simples managé (AWS gère l’infrastructure pour vous).

Amazon CloudFront, SLA du CDN AWS

Amazon Cloudfront est le service CDN de AWS, avec plusieurs dizaines de « Edge Locations », ce service met en cache les requêtes web selon vos comportements et pattern d’URLs choisis. Il permet des diffusions et donc des chargements de données accélérés sur les sites web et applications mobile, notamment lorsque du contenu media transite.

AWS s’engage à maintenir une disponibilité globale du service au-dessus de 99.9% mensuel (identique à Amazon S3). Les remises effectuées sur le service, en cas de défaillance avérée, également basé sur la fréquence des erreurs d’accès aux données sont identiques à celles de Amazon S3.

AWS Shield, SLA du service de protection anti-DDoS

Lancé lors du re:Invent 2016, AWS Shield est l’officialisation de la protection anti DDoS de AWS. Le service utilise et protège les autres services Amazon CloudFront et Amazon Route 53, et son SLA, ramené sur des périodes de 24 heures, est lié directement aux SLA des produits cités précédemment. On pourra donc traduire ce SLA, par un simple rappel que l’utilisation du service AWS Shield devant Amazon CloudFront ou Amazon Route 53 ne modifie pas leur SLA.

Amazon API Gateway, SLA sur la gestion des API

Depuis janvier 2019, AWS s’engage à assurer une disponibilité de 99.95% mensuel du service Amazon API Gateway. Ce service entièrement managé facilite la gestion, la surveillance et la sécurité des API de n’importe quelle taille. En cas de rupture du service, le crédit alloué est identique à ceux de RDS : 10% de remise entre 99.0% et 99.95% et 25% de remise pour une disponibilité mensuelle moindre à 99.0%.

Amazon EMR, SLA sur les frameworks Big Data

En janvier 2019, Amazon EMR bénéfice d’un engagement en terme de disponibilité de la part d’AWS. Les frameworks Big Data gérés par le service possède un SLA de 99.9% mensuel.

emr_sla.Engagement de AWS pour EMR et remboursement en crédits au 10 janvier 2019

Amazon Kinesis, SLA sur la gestion des données en streaming

Amazon Kinesis traite de la collecte, du traitement et de l’analse de données en streaming en temps réel. Le SLA sur lequel s’engage AWS touche trois composants principaux de Kinesis : Videos Streams, Data Streams et Data Firehose. L’engagement de disponibilité des services est de 99.9% mensuel avec une remise de 10% à 25% en cas d’indisponibilité.

Synthèse des SLA chez AWS

Service AWS SLA mensuel SLA minutes/mois
Amazon Route 53 100.00 % 0 seconde
Amazon EC2 99.99 % 4 minutes 30 secondes
Amazon RDS 99.95 % 21 minutes et 36 secondes
Amazon S3 99.90 % 43 minutes et 12 secondes
Amazon CloudFront 99.90 % 43 minutes et 12 secondes
AWS Shield Cf. CloudFront ou Route 53 Cf. CloudFront ou Route 53
AWS API Gateway
99.95 % 21 minutes et 36 secondes
Amazon EMR
99.90 % 43 minutes et 12 secondes
Amazon Kinesis
(Data / Videos Stream /
Data Firehose
99.90 % 43 minutes et 12 secondes

 

Calcul du SLA d’une infrastructure AWS

Partons d’une infrastructure Web App, relativement classique. Elle est composée de plusieurs serveurs applicatifs frontaux, ici EC2 C4.Large, le code exécuté est le même sur chaque instance, et nous avons une redondance multi-zone de disponibilités. La base de données est un MySQL sur RDS en Multi-AZ (Stand-By Instance). Les éléments statiques du sites sont stockés sur S3. CloudFront, est placé devant le Load Balancer, il met en cache les éléments statiques de S3 et reroute les autres requêtes sur le LoadBalancer. Route53 gère le nom de domaine du site.

cloudcraft-web-app

Infrastructure Web : Amazon Route 53, CloudFront, S3, EC2 et RDS

Voici comment nous pouvons calculer le SLA de cette infrastructure, bien entendu celui-ci est dans le cas d’une défaillance de tous les services AWS utilisés sur une région, et dans le cadre du SLA de chacun de ses services. Dans ce cas l’infrastructure ne peut prétendre à un SLA supérieur sans redondance supplémentaire.

  • RDS Multi-AZ MySQL : SLA de 99,95 %
  • EC2 : SLA de 99.95 %
  • CloudFront : SLA de 99.9 %
  • S3 : SLA de 99.9%
  • Route 53 : 100.0 %

Le SLA de l’infrastructure brute sera de :

99.95% x 99.95% x 99.9% x 99.9% x 100% = 99,70 %

Si l’on considère que l’indisponibilité S3 n’est pas critique pour la conservation de la disponibilité de l’infrastructure web (par exemple une API) et qu’on gère via Route 53 l’éventuel downtime de CloudFront en pointant vers le Load Balancer en secours, nous gagnerons 0,2% de SLA juste par modification et optimisation du Design de l’infrastructure :

99.95% x 99.95% x 100% = 99,90 %

N’hésitez pas à poser vos questions ou nous contacter pour plus d’informations.