Que sont les « Cloudformation Custom Resources » et comment les utiliser

18 novembre 2020 corexpert

philipp-katzenberger-iijruoerocq-unsplash

AWS Cloudformation, qu’est-ce que c’est ?

Cloudformation est un outil très important dans la vie de tous les jours des personnes travaillant sur le cloud AWS. Il permet d’implémenter toutes les ressources AWS d’une manière rapide et efficace. C’est un très bon exemple de IaC : Infrastructure as Code.

Cloudformation facilite donc les déploiements, la maintenance et les évolutions d’environnement entier, mais permet aussi de templatiser ces infrastructures.

Les différents services du catalogue AWS évoluent de manière continue, et totalement indépendante. On peut comparer la plateforme AWS à une immense architecture en micro-services.

Il se peut donc que Cloudformation ne soit pas à jour par rapport aux nouveautés des services. Une fonctionnalité ou un paramètre spécifique peut ne pas être implémenté dans Cloudformation, cela rendra inutilisable la stack Cloudformation pour la ressource en question.

La suite de cet article a pour but de montrer comment contourner cette limitation, et construire toutes les ressources AWS comme on le souhaite.

Les « Custom Resources »

Heureusement, les Custom Resources sont là pour nous aider. Elles permettent de provisionner les ressources AWS à chaque fois qu’une stack Cloudformation est créée, mise à jour ou supprimée.

Alors, comment ça marche ?

De manière très simple, sur un changement, Cloudformation appelle une fonction Lambda avec un event spécifique, et attendra un retour de cette fonction de manière à définir si la ressource a été correctement modifiée, ou non.

Nous remarquons ici la possibilité d’utiliser l’un des SDK proposés par AWS, par le biais de la fonction lambda ( Python, Java, Node.js, … ).

Voici le template de l’event envoyé par Cloudformation à la Lambda :

{
   "RequestType" : "Create",
   "ResponseURL" : "http://pre-signed-S3-url-for-response",
   "StackId" : "arn:aws:cloudformation:us-west-2:123456789012:stack/stack-name/guid",
   "RequestId" : "unique id for this create request",
   "ResourceType" : "Custom::TestResource",
   "LogicalResourceId" : "MyTestResource",
   "ResourceProperties" : {
      "Name" : "Value",
      "List" : [ "1", "2", "3" ]
   }
}

{

"RequestType" : "Create",

"ResponseURL" : "http://pre-signed-S3-url-for-response",

"StackId" : "arn:aws:cloudformation:us-west-2:123456789012:stack/stack-name/guid",

"RequestId" : "unique id for this create request",

"ResourceType" : "Custom::TestResource",

"LogicalResourceId" : "MyTestResource",

"ResourceProperties" : {

"Name" : "Value",

"List" : [ "1", "2", "3" ]

}

NB : Le champ ResourceProperties permet de personnaliser les paramètres de la fonction

On remarque aussi que l’event contient une URL qui correspond à l’endpoint qu’il faudra appeler quand le travail de la lambda est terminé. L’endpoint attend un statut des actions menées.

Voici un exemple de ce qu’attends l’URL :

{
   "Status" : "SUCCESS",
   "PhysicalResourceId" : "TestResource1",
   "StackId" : "arn:aws:cloudformation:us-west-2:123456789012:stack/stack-name/guid",
   "RequestId" : "unique id for this create request",
   "LogicalResourceId" : "MyTestResource",
   "Data" : {
      "OutputName1" : "Value1",
      "OutputName2" : "Value2",
   }
}

{

"Status" : "SUCCESS",

"PhysicalResourceId" : "TestResource1",

"StackId" : "arn:aws:cloudformation:us-west-2:123456789012:stack/stack-name/guid",

"RequestId" : "unique id for this create request",

"LogicalResourceId" : "MyTestResource",

"Data" : {

"OutputName1" : "Value1",

"OutputName2" : "Value2",

}

Custom Resources : use case & implémentation

Comme souvent, lorsque je travaille pour un client, je commence par construire la solution « à la main » via la console AWS, ceci me permet d’avoir rapidement une solution exploitable. Une fois cette étape terminée, je construis l’IaC via Cloudformation, afin de fournir des templates qui seront utilsés pour construire les environnements de travail jusqu’à la production.

Travaillant sur un projet AWS AppStream, j’ai eu la surprise de voir qu’il était impossible à ce jour de joindre un rôle IAM ni à l’image builder, ni à la flotte en utilisant les ressources natives Cloudformation.

J’ai pris la décision d’utiliser le SDK et ainsi développer mes propres Customs Resources.

Construire la fonction Lambda

Commençons par construire la fonction Lambda permettant de créer et détruire les ressources.

Nous retrouvons les paramètres personnalisés depuis l’event :

appstream_image_builder = event['ResourceProperties']['AppstreamImageBuilder']
appstream_fleet = event['ResourceProperties']['AppstreamFleet']

1 2	appstream_image_builder = event['ResourceProperties']['AppstreamImageBuilder'] appstream_fleet = event['ResourceProperties']['AppstreamFleet']

Ensuite, on vérifie dans l’event quelle est l’action à effectuer :

Création :

    if event['RequestType'] == "Create":
    
      LOGGER.info('appstream_image_builder: \n %s', appstream_image_builder)
      
      LOGGER.info('Creating ilmage builder')
      
      response = client.create_image_builder(
          Name=appstream_image_builder['Name'],
          ImageName=appstream_image_builder['ImageName'],
          InstanceType=appstream_image_builder['InstanceType'],
          Description=appstream_image_builder['Description'],
          DisplayName=appstream_image_builder['DisplayName'],
          VpcConfig={
              'SubnetIds': appstream_image_builder['SubnetIds'],
              'SecurityGroupIds': appstream_image_builder['SecurityGroupIds']
          },
          IamRoleArn=appstream_image_builder['IamRoleArn'],
          DomainJoinInfo={
              'DirectoryName': appstream_image_builder['DirectoryName'],
              'OrganizationalUnitDistinguishedName': appstream_image_builder['OrganizationalUnitDistinguishedName']
          },
          Tags=appstream_image_builder['Tags']
      )
      
      LOGGER.info("Image bulder created")
      LOGGER.info("Creating fleet")
      
      LOGGER.info('appstream_fleet: \n %s', appstream_fleet)
      
      LOGGER.info('Creatin fleet')
      
      response = client.create_fleet(
          Name=appstream_fleet['Name'],
          ImageName=appstream_fleet['ImageName'],
          InstanceType=appstream_fleet['InstanceType'],
          FleetType=appstream_fleet['FleetType'],
          ComputeCapacity={
              'DesiredInstances': int(appstream_fleet['DesiredInstances'])
          },
          VpcConfig={
              'SubnetIds': appstream_fleet['SubnetIds'],
              'SecurityGroupIds': appstream_fleet['SecurityGroupIds']
              },
          Description=appstream_fleet['Description'],
          DisplayName=appstream_fleet['DisplayName'],
          DomainJoinInfo={
              'DirectoryName': appstream_fleet['DirectoryName'],
              'OrganizationalUnitDistinguishedName': appstream_fleet['OrganizationalUnitDistinguishedName']
          },
          Tags=appstream_fleet['Tags'],
          IamRoleArn=appstream_fleet['IamRoleArn'],
          StreamView=appstream_fleet['StreamView']
      )
      
      LOGGER.info("Fleet created")
      send_response(event, context, "SUCCESS", {"Message": "Resource creation successful!"})

if event['RequestType'] == "Create":

LOGGER.info('appstream_image_builder: \n %s', appstream_image_builder)

LOGGER.info('Creating ilmage builder')

response = client.create_image_builder(

Name=appstream_image_builder['Name'],

ImageName=appstream_image_builder['ImageName'],

InstanceType=appstream_image_builder['InstanceType'],

Description=appstream_image_builder['Description'],

DisplayName=appstream_image_builder['DisplayName'],

VpcConfig={

'SubnetIds': appstream_image_builder['SubnetIds'],

'SecurityGroupIds': appstream_image_builder['SecurityGroupIds']

IamRoleArn=appstream_image_builder['IamRoleArn'],

DomainJoinInfo={

'DirectoryName': appstream_image_builder['DirectoryName'],

'OrganizationalUnitDistinguishedName': appstream_image_builder['OrganizationalUnitDistinguishedName']

Tags=appstream_image_builder['Tags']

)

LOGGER.info("Image bulder created")

LOGGER.info("Creating fleet")

LOGGER.info('appstream_fleet: \n %s', appstream_fleet)

LOGGER.info('Creatin fleet')

response = client.create_fleet(

Name=appstream_fleet['Name'],

ImageName=appstream_fleet['ImageName'],

InstanceType=appstream_fleet['InstanceType'],

FleetType=appstream_fleet['FleetType'],

ComputeCapacity={

'DesiredInstances': int(appstream_fleet['DesiredInstances'])

VpcConfig={

'SubnetIds': appstream_fleet['SubnetIds'],

'SecurityGroupIds': appstream_fleet['SecurityGroupIds']

Description=appstream_fleet['Description'],

DisplayName=appstream_fleet['DisplayName'],

DomainJoinInfo={

'DirectoryName': appstream_fleet['DirectoryName'],

'OrganizationalUnitDistinguishedName': appstream_fleet['OrganizationalUnitDistinguishedName']

Tags=appstream_fleet['Tags'],

IamRoleArn=appstream_fleet['IamRoleArn'],

StreamView=appstream_fleet['StreamView']

)

LOGGER.info("Fleet created")

send_response(event, context, "SUCCESS", {"Message": "Resource creation successful!"})

Destruction : Dans cet exemple, la flotte doit être stoppée avant d’être supprimée

elif event['RequestType'] == "Delete":
      LOGGER.info('Deleting Image builder')
      response = client.delete_image_builder(
        Name=appstream_image_builder['Name']
      )
      
      LOGGER.info('Stoping fleet')
      response = client.stop_fleet(
        Name=appstream_fleet['Name']
      )
      
      LOGGER.info('Waiting for fleet to be stopped ...')
      response = client.describe_fleets(
        Names=[
            appstream_fleet['Name'],
        ]
      )
      state=response['Fleets'][0]['State']

      while state != 'STOPPED':    
        time.sleep(5)
        response = client.describe_fleets(
            Names=[
                "adobeAndNotepadd-Fleet",
            ]
        )  
        state = response['Fleets'][0]['State']
        LOGGER.info('Waiting for fleet to be stopped ...')
      
      LOGGER.info('Waiting for fleet to be stopped ...')
      response = client.delete_fleet(
        Name=appstream_fleet['Name']
      )
      
      send_response(event, context, "SUCCESS", {"Message": "Resource deleted successful!"})

elif event['RequestType'] == "Delete":

LOGGER.info('Deleting Image builder')

response = client.delete_image_builder(

Name=appstream_image_builder['Name']

)

LOGGER.info('Stoping fleet')

response = client.stop_fleet(

Name=appstream_fleet['Name']

)

LOGGER.info('Waiting for fleet to be stopped ...')

response = client.describe_fleets(

Names=[

appstream_fleet['Name'],

]

)

state=response['Fleets'][0]['State']

while state != 'STOPPED':

time.sleep(5)

response = client.describe_fleets(

Names=[

"adobeAndNotepadd-Fleet",

]

)

state = response['Fleets'][0]['State']

LOGGER.info('Waiting for fleet to be stopped ...')

response = client.delete_fleet(

Name=appstream_fleet['Name']

)

send_response(event, context, "SUCCESS", {"Message": "Resource deleted successful!"})

Comme expliqué, la Custom Resource attend un statut que je remplacerai par un code retour.

Ci-dessous le code permettant de faire cet appel :

def send_response(event, context, response_status, response_data):
  '''Send a resource manipulation status response to CloudFormation'''
  response_body = json.dumps({
      "Status": response_status,
      "Reason": "See the details in CloudWatch Log Stream: " + context.log_stream_name,
      "PhysicalResourceId": context.log_stream_name,
      "StackId": event['StackId'],
      "RequestId": event['RequestId'],
      "LogicalResourceId": event['LogicalResourceId'],
      "Data": response_data
  })
  
  LOGGER.info('ResponseURL: %s', event['ResponseURL'])
  LOGGER.info('ResponseBody: %s', response_body)
  
  opener = build_opener(HTTPHandler)
  request = Request(event['ResponseURL'], data=response_body)
  request.add_header('Content-Type', '')
  request.add_header('Content-Length', len(response_body))
  request.get_method = lambda: 'PUT'
  response = opener.open(request)
  LOGGER.info("Status code: %s", response.getcode())
  LOGGER.info("Status message: %s", response.msg)

def send_response(event, context, response_status, response_data):

'''Send a resource manipulation status response to CloudFormation'''

response_body = json.dumps({

"Status": response_status,

"Reason": "See the details in CloudWatch Log Stream: " + context.log_stream_name,

"PhysicalResourceId": context.log_stream_name,

"StackId": event['StackId'],

"RequestId": event['RequestId'],

"LogicalResourceId": event['LogicalResourceId'],

"Data": response_data

})

LOGGER.info('ResponseURL: %s', event['ResponseURL'])

LOGGER.info('ResponseBody: %s', response_body)

opener = build_opener(HTTPHandler)

request = Request(event['ResponseURL'], data=response_body)

request.add_header('Content-Type', '')

request.add_header('Content-Length', len(response_body))

request.get_method = lambda: 'PUT'

response = opener.open(request)

LOGGER.info("Status code: %s", response.getcode())

LOGGER.info("Status message: %s", response.msg)

Construire le template Cloudformation

Ensuite, nous passons à la création du template Coudformation. On peut voir dans cet exemple que l’Image Builder et la flotte sont une seule et même ressource, de type : Custom::IBAndFleetBuilder, et que le champ ServiceToken correspond à l’ARN de la Lamda.

ImageBuilderAndFleetCreationFunction:
    Type: AWS::Lambda::Function
    Properties:
      Code:
        S3Bucket: "appstream-image-sources"
        S3Key: "ImageBuilderAndFleetCreationFunction/handler.zip"
      Handler: "handler.handler"
      Timeout: 300
      Runtime: python2.7
      Role: 
        Fn::ImportValue:
          !Sub "${Env}-LambdaAppstreamCreationRoleArn"
  
  ImageBuilderAndFleetCreationCustom:
    Type: Custom::IBAndFleetBuilder
    Properties:
      ServiceToken: !GetAtt ImageBuilderAndFleetCreationFunction.Arn
      
      AppstreamImageBuilder:
        Name: !Sub "${Project}-Image-Builder"
        ImageName: !Ref ImageBuilderBaseImageName
        InstanceType: !Ref ImageBuilderInstanceType
        Description: !Sub "Appstream Image builder for projet ${Project}"
        DisplayName: !Sub "${Project}-Image-Builder"
        SubnetIds: !Ref ImageBuilderSubnetlist
        SecurityGroupIds: !Ref ImageBuilderSecuritygroupslist
        IamRoleArn: 
          Fn::ImportValue:
            !Sub "${Env}-AppstreamImageBuilderRoleArn"
        DirectoryName: !Ref ImageBuilderDirectoryName
        OrganizationalUnitDistinguishedName: !Ref ImageBuilderOrganizationalUnitDistinguishedName
        Tags: 
            Env: !Ref Env
            Project: !Ref Project
            
      AppstreamFleet:
        Name: !Sub "${Project}-Fleet"
        ImageName: !Ref FleetDefaultImageName
        InstanceType: !Ref FleetInstanceType
        FleetType: !Ref FleetType
        DesiredInstances: !Ref FleetDesiredInstances
        SubnetIds: !Ref FleetSubnetlist
        SecurityGroupIds: !Ref FleetSecuritygroupslist
        Description: !Sub "Appstream Fleet for projet ${Project}"
        DisplayName: !Sub "${Project}-Fleet"
        DirectoryName: !Ref FleetDirectoryName
        OrganizationalUnitDistinguishedName: !Ref FleetOrganizationalUnitDistinguishedName
        Tags:
          Env: !Ref Env
          Project: !Ref Project
        IamRoleArn: 
          Fn::ImportValue:
            !Sub "${Env}-AppstreamFleetRoleArn"
        StreamView: !Ref FleetStreamView

ImageBuilderAndFleetCreationFunction:

Type: AWS::Lambda::Function

Properties:

Code:

S3Bucket: "appstream-image-sources"

S3Key: "ImageBuilderAndFleetCreationFunction/handler.zip"

Handler: "handler.handler"

Timeout: 300

Runtime: python2.7

Role:

Fn::ImportValue:

!Sub "${Env}-LambdaAppstreamCreationRoleArn"

ImageBuilderAndFleetCreationCustom:

Type: Custom::IBAndFleetBuilder

Properties:

ServiceToken: !GetAtt ImageBuilderAndFleetCreationFunction.Arn

AppstreamImageBuilder:

Name: !Sub "${Project}-Image-Builder"

ImageName: !Ref ImageBuilderBaseImageName

InstanceType: !Ref ImageBuilderInstanceType

Description: !Sub "Appstream Image builder for projet ${Project}"

DisplayName: !Sub "${Project}-Image-Builder"

SubnetIds: !Ref ImageBuilderSubnetlist

SecurityGroupIds: !Ref ImageBuilderSecuritygroupslist

IamRoleArn:

Fn::ImportValue:

!Sub "${Env}-AppstreamImageBuilderRoleArn"

DirectoryName: !Ref ImageBuilderDirectoryName

OrganizationalUnitDistinguishedName: !Ref ImageBuilderOrganizationalUnitDistinguishedName

Tags:

Env: !Ref Env

Project: !Ref Project

AppstreamFleet:

Name: !Sub "${Project}-Fleet"

ImageName: !Ref FleetDefaultImageName

InstanceType: !Ref FleetInstanceType

FleetType: !Ref FleetType

DesiredInstances: !Ref FleetDesiredInstances

SubnetIds: !Ref FleetSubnetlist

SecurityGroupIds: !Ref FleetSecuritygroupslist

Description: !Sub "Appstream Fleet for projet ${Project}"

DisplayName: !Sub "${Project}-Fleet"

DirectoryName: !Ref FleetDirectoryName

OrganizationalUnitDistinguishedName: !Ref FleetOrganizationalUnitDistinguishedName

Tags:

Env: !Ref Env

Project: !Ref Project

IamRoleArn:

Fn::ImportValue:

!Sub "${Env}-AppstreamFleetRoleArn"

StreamView: !Ref FleetStreamView

Conclusion

Grâce aux Custom Resources, j’ai pu livrer au client un template Cloudformation opérationnel, qu’il peut utiliser pour déployer automatiquement toutes ses ressources AppStream en un clic, mais aussi pour les supprimer lorsqu’il le souhaite.

Il est important de noter que la stack Cloudformation fait un appel à la Custom Resource lorsque celle-ci est mise à jour, ainsi pour éviter ce comportement, nous pourrons donc implémenter une fonction spécifique dans la Lambda qui sera en charge d’effectuer cette partie.

—

Références :

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html

https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/template-custom-resources.html

Big Data dans le cloud : Data Science as a Service

28 janvier 2020 corexpert

Cas d’utilisation dans la Data Science

Le client, Sanofi, troisième entreprise mondial selon le chiffre d’affaires dans le secteur de la santé, pose la problématique de créer un écosystème applicatif pour traiter et analyser l’arrivée d’un flux constant de données cliniques (essais, données patients, etc…). L’environnement se doit d’être sécurisé du fait du recueillement d’informations sensibles liées au monde médical.

Le besoin est très spécifique et fait partie du domaine du Big Data et de la Data Science.

Cela demande, d’une part, la création d’un data center capable d’assurer le stockage d’une volumétrie en constante augmentation et d’autre part la création d’outils permettant d’analyser les données pour en extraire de la valeur métier.

La donnée en question est acquise régulièrement via des laboratoires et tierces entreprises. Un traitement indispensable d’anonymisation, de formatage, et de compression est nécessaire avant d’être ingéré dans le data center.

En moyenne, on ingère 1 Téraoctet de donnée clinique tous les mois pour être traitée et stockée.

Pour rendre la donnée stockée utile, il faut assurer une haute disponibilité et la rendre requêtable d’une façon flexible, performante et en minimisant les coûts, étant donné qu’il s’agit d’une grande volumétrie de data.

En même temps, il faut assurer la sécurité de la donnée pour garantir la confidentialité du client.

Une fois accessible, une application web donnera accès à cette donnée aux utilisateurs, principalement des Data Scientists (internes ou prestaires du client) pour l’analyser.

L’application doit permettre aux Data Scientists de provisionner en « self-service » des machines virtuelles capables d’exécuter des opérations de statistique, big data et machine learning, exigeantes en termes de puissance de calcul.

On doit de même être capable de tracer les coûts par utilisateur ainsi que les flux de données depuis le data center crée.

Une infrastructure de ce genre et des machines dédiées au Data Science de cette puissance auraient un coût très élevé sur des environnements «on-premise».

Dans le cloud on va pouvoir répondre avec des solutions scalables, en donnant accès à des ressources facturées à l’utilisation avec des architectures à la hauteur des plus grandes exigences de sécurité.

Data Science as a Service

Data Lake

Pour répondre à la problématique du stockage de la data on propose un data center particulier, AWS Data Lake.

Data Lake est un data center centralisé pour tout type de donnée (structurée ou pas) et accessible à plusieurs services comme AWS Glue, AWS Athena, AWS API Gateway et ce d’une façon performante et enrichissante du point de vue métier.

AWS Service Catalog

Ensuite, pour donner accès aux utilisateurs à la donnée stockée nous faisons appel à AWS Service Catalog. Ce service nous permet de provisionner des machines virtuelles (AWS EC2) pour lesquelles on définit la capacité de calcul (Processeurs, CPU, RAM, débit, …) avec des environnements de travail préchargés : langages (Python et R), librairies et outils définis en amont dans des templates Cloudformation.

Service Catalog nous permet de générer un catalogue de machines, chacune avec un environnement de travail spécifique pour répondre aux différents besoins des utilisateurs.

Pour répondre aux besoins en termes de puissance, on choisit les m5.2xlarge, la toute dernière génération d’instance d’AWS, avec des Processeurs Intel Xeon® Platinum 8175 d’une fréquence maximale de 3,1GHz, 8 processeurs virtuels et 32 Gio de mémoire.

Le prix d’une machine on premise equivalente est proche de 6000 euros.

Grace au modèle de facturation à l’utilisation, on peut donner accès à ces machines aux utilisateurs à un prix de 0,35€ par heure.

Avec Service Catalog on fait aussi la gouvernance de tous les produits provisionnés. On peut provisionner, terminer, hiberner, réveiller nos machines instanciées, à l’image de notre catalogue de produits, d’une façon rapide et flexible.

Ceci va nous permettre entre autres d’avoir une traçabilité complète des produits, leur durée de vie et donc aussi les coûts générés.

Architecture serverless

L’architecture de la partie web utilise les briques classiques AWS d’une « single web page application », stockée dans un Amazon Bucket S3 délivrée par le CDN d’AWS, Amazon Cloudfront.

Pour l’authentification, nous utilisons AWS Cognito, lié au LDAP du client donnant accès aux appels API, créée avec AWS API Gateway.

On utilise la base de données No-SQL, Amazon DynamoDB pour stocker toutes les données nécessaires au fonctionnement de l’application.

L’ensemble de l’exécution du code de la partie backend repose sur AWS Lambda.

Ensuite, Service Catalog sert à provisionner et gérer les machines virtuelles, définies avec AWS CloudFormation.

La donnée clinique, stockée dans AWS Lake Formation, se retrouve dans des Buckets S3 « montés » au sein des machines virtuelles, dans un réseau isolé, afin de protéger l’accessibilité de la donnée.

Le versioning des projets sauvegardés par les utilisateurs et l’installation de librairies sont gérés grâce à des Git et Nexus internes pour garder le réseau fermé et éviter toute fuite de données.

Retour client

Le projet, toujours en cours, avec des nouvelles évolutions, réalisé par trois personnes, a été mis en production en moins de 6 mois. Et selon notre client :

« Travailler dans le cloud nous a permis en temps record de déployer une solution à une problématique interne qui autrement aurait nécessité plus de temps, de budget et des solutions on-premise qui auraient complexifié le projet et obligé à faire un plus grand investissement en termes de ressources. »

Notamment l’accès aux machines virtuelles de telles capacité ou d’autres services plus spécifiques comme l’Intelligence Artificielle, ouvrent les portes à la conception de solutions dans des domaines plus spécialisés.

Amazon Athena ou comment analyser facilement ses données

31 juillet 2019 corexpert

De nos jours, il est courant d’avoir un nombre très importants de données issus d’applications et de bases de données comme par exemples des logs ou des statistiques. C’est l’analyse et le traitement de ces données qui permettent d’optimiser et de mieux comprendre les usages et d’enrichir en fonctionnalités les produits. AWS propose un large éventail de services concernant les datalakes et les solutions d’analyse de données. Dans cet article, nous allons nous pencher un peu plus sur Amazon Athena, un service managé permettant de facilement analyser des données sur Amazon S3.

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/';

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 !

Itinéraire d’un projet IA : Automatisation

15 avril 2019 corexpert

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.

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

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

10 avril 2019 corexpert

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

TeamWork et Corexpert atteignent les 50 certifications AWS !

5 octobre 2018 corexpert

AWS est un environnement proposant chaque jour de nombreuses améliorations de leurs services : il suffit de jeter un coup d’œil sur la page regroupant les nouveautés pour voir la volonté d’innovation d’AWS.

Comment vérifier l’expertise nécessaire lors de la conception, du déploiement et de l’exploitation des ressources AWS lorsque celles-ci sont en perpétuelle mutation ?
En passant les attestations proposées par AWS !

Réparties en plusieurs pôles, ces certifications récompensent l’utilisation pertinente des services d’AWS, promeuvent l’établissement d’architecture raisonnée et vérifient les connaissances du candidat avec des exemples concrets issus de la sphère professionnelle. Régulièrement mises à jour et encadrées par des organismes de contrôle, ces certifications sont des garanties de l’expertise du candidat sur le sujet.

Aujourd’hui, TeamWork et Corexpert ont atteint une distinction particulière concernant le nombre de certifiés : nos équipes comptent plus de 50 certifications. Cet engagement pour le cloud d’AWS démontre la capacité de la plateforme à s’adapter et proposer des solutions pour tous types de projets. Nos experts sont prêts à répondre à toutes vos questions sur le cloud et à vous guider dans vos projets innovants. Recherche d’optimisation des coûts, volonté de migration vers le cloud, automatisation de processus, intégrations de services AWS en complément d’un environnement sur site ; toutes ces thématiques (et bien d’autres !) peuvent être partagées avec notre équipe pour élaborer une stratégie hybride ou entièrement sur le cloud !

En plus de ces certifications, TeamWork et Corexpert possèdent également des compétences reconnues dans la migration SAP et est un partenaire plébiscité par AWS pour AppStream 2.0.

Corexpert déploie SAP GUI avec Amazon AppStream

17 mars 2018 corexpert

En seulement deux jours Corexpert déploie le client SAP Gui pour l’ensemble de ses collaborateurs.

Après avoir rejoint le groupe TeamWork en septembre 2017, Corexpert a réintégré sa comptabilité en quelques semaines dans SAP. A partir de janvier 2018, l’intégralité de la gestion de Corexpert est opérationnelle dans SAP : Commandes, Facturation, saisie des temps à facturer, suivi des absences, notes de frais, workflow…

Afin de permettre à nos collègues d’utiliser le client de connexion SAP (SAP GUI, prononcez « gooey » ou G-U-I pour Graphic User Interface) il leur fallait donc un client à installer sur leur poste local ainsi qu’un compte VPN individuel afin d’accéder aux infrastructures SAP du groupe. Le client Mac n’étant pas natif, une version JAVA est disponible…

Corexpert est « born in cloud » et dans la mesure du possible nous utilisons des ressources dans Amazon Web Services pour nos applicatifs, ou des applications SaaS. Nous ne sommes pas vraiment coutumiers du déploiement sur postes utilisateurs et ne voyant pas comment faire cela avec Jenkins 🙂 nous avons décidé de mettre en oeuvre Amazon AppStream afin d’accélérer ce déploiement et s’assurer que celui-ci soit réalisé sans impact pour nos utilisateurs (disponibilité du PC/MAC etc…).

Amazon AppStream est actuellement dans sa seconde version, basé sur la technologie NICE DCV, celle-ci sécurise les pixels et les entrées d’utilisateur final à l’aide d’un chiffrement AES-256 de bout en bout. Le service ne nécessite pas de client à installer, mais un simple navigateur HTML5, authentification par email et mot de passe ou ADFS par exemple. Les applications préalablement installées sur une image Windows Server 2012, sont « streamées » vers le navigateur de l’utilisateur final.

L’architecture déployée est celle décrite ci-dessous, les utilisateurs Corexpert accèdent au portail AppStream 2 de n’importe où en SSL et la « fleet » de serveurs AppStream se trouve dans un VPC interconnecté avec le VPN & Firewall de TeamWork, Data-Centre où est hébergé l’infrastructure SAP groupe.

Le déploiement Amazon AppStream est réalisé sur « fleet on-Demand » c’est à dire que le nombre de serveur est déclenché au fur et à mesure de la connexion et demande des utilisateurs. Vous trouverez dans la petite vidéo ci-dessous un « cold-start » avec une attente constaté d’une minute.

A retenir

Un déploiement unifié et sécurisé, l’accès aux données est chiffré de bout en bout.

Une gestion centralisé du porte-feuille des application, la mise à jour du SAP GUI est appliquée et disponible pour tous les collaborateurs simultanément.

Amazon Appstream est programmatique et pilotable en ligne de commande, on planifie par exemple plus de serveurs dans la flotte Amazon Appstream lors de la saisie des temps en fin de semaine et fin de mois !

Un coût minimal de l’infrastructure, paiement à l’heure d’utilisation.

Bien débuter avec Amazon EC2 Container Service (101) – Cluster & task

17 janvier 2018 corexpert Commentaires 0 Commentaire

Nous continuons dans la série “Bien débuter avec Amazon EC2 Container Service” en se concentrant sur les tasks et les clusters qui vont les héberger.

1 – Qu’est ce qu’un Cluster

Un cluster ECS est un regroupement d’instances EC2 qui vont héberger vos containers.

Exemple d'un cluster ECS — Exemple d’un cluster ECS

Un cluster peut contenir une ou plusieurs instances, de différents types et taille. Dans notre exemple, nous utiliserons une t2.micro.

2 – Création d’un cluster ECS

Nous allons nous connecter à la console web aws pour ecs. Nous allons cliquer sur “Cluster” dans le menu de gauche. Dans l’écran suivant (liste des clusters), nous allons cliquer sur “Create Cluster” pour créer notre premier cluster.

Dans l’écran de création de cluster nous avons un formulaire très complet avec de nombreuses options. Nous allons utiliser les champs suivants :

Cluster Name : helloworldCluster
Provisioning Model : On-Demand Instance
EC2 instance type : t2.micro
VPC : choisir la VPC où vous désirez créer vos instances
Security group : Choisir/Créer un security group qui ouvre le port 80

Cliquez sur le bouton bleu “Create” pour créer le cluster. Il devrait maintenant apparaître dans la liste des clusters

3 – Task Definition ou comment définir le lancement des containers

Une task definition est une liste des paramètres qui vont permettre le lancement de nos containers.

Pour la créer, nous allons cliquer sur “Task definitions” dans le menu de gauche, puis sur le bouton bleu “Create new Task Definition”.

Cette première task definition va nous permettre de lancer un container, qui aura son port HTTP (80) lié au port 8080 sur l’instance hôte.

Pour notre exemple nous allons remplir les champs suivants :

Task Definition Name : Helloworld-1
Container Definitions : cliquez sur “add container”
- Container name : Helloworld
- Image : 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest
- Memory Limits (MB) : 128
- Port mappings :
  - Host : 8080
  - Container : 80
  - protocol : tcp
- Cliquez sur le bouton “Add”

Vous pouvez ensuite cliquer sur le bouton bleu “Create”

De nombreuses autres options sont disponibles dans le Container Definitions, pour permettre une définition fine des besoins des containers (Mapping de volumes, lien entre containers …)

4 – Exécution d’une task

Maintenant que nous avons créé notre Cluster de machine hôte et que nous avons décrit la manière de lancer le container, nous pouvons enfin l’exécuter.
Pour cela, nous allons cliquer sur le menu “Cluster” puis choisir dans la liste notre cluster helloworldCluster. Nous arrivons donc ici :

Cliquez sur l’onglet “Task” puis sur le bouton bleu “Run new Task”
Dans l’écran suivant nous allons choisir tous les éléments que nous avons créé précédemment

La task est créée et est prête à recevoir des messages.

5 – Connexion au container

Il ne reste plus qu’à valider que le container répond bien à nos requêtes HTTP.
Nous allons nous connecter directement à l’instance hôte sur le port 8080.
Pour trouver son IP, il suffit de cliquer sur le nom de la task (dans notre cas 67f6a5b4-4…) pour afficher les détails.
Dans la partie container il faut cliquer sur le triangle à côté du nom du container (helloworld) pour afficher les détails, l’IP sera dans la section “Network Bindings”

Vous pouvez ensuite aller dans votre navigateur préféré, et entrez l’url du container pour afficher la page

Félicitations, vous avez fait fonctionner votre premier container sur Amazon EC2 Container Service.

Dans le prochain article nous verrons comment aller plus loin en créant un service se basant sur l’image de container existante. Ainsi plusieurs containers seront lancés et pourront répondre à vos requêtes

Bien débuter avec Amazon EC2 Container Service (101) – ECR

30 août 2017 corexpert Commentaires 0 Commentaire

Docker est une technologie qui fait grand bruit depuis plusieurs années maintenant dans le domaine de l’IT.

docker-vs-aws — AWS vs docker in google search

Tous les grands cloud publics (Amazon Web Service, Google Cloud, Microsoft Azure) proposent une solution plus ou moins intégrée pour la gestion des containers. Dans ces articles nous allons vous expliquer comment débuter avec succès sur le service managé Amazon EC2 Container Service.

Cette série d’articles suppose que vous avez créé un VPC où seront créé les instances hôtes pour les containers docker, que la CLI AWS est installée sur votre poste et nous utiliserons une image “Hello-world” (dockercloud/hello-world) disponible sur le docker hub.

1 – Création du dépôt Docker Privé (ECR)

Pour être déployé, une image de container doit être mis à disposition dans un dépôt docker.
Plusieurs solutions sont disponibles, Amazon Web services (AWS) nous propose un dépôt privé managé (ECR) à un tarif intéressant (0,1$/Go/mois au 01/08/2017).

Pour déployer notre image sur ECR ( Amazon EC2 Container Registry ) nous allons tout d’abord récupérer cette image sur le docker hub.

docker pull dockercloud/hello-world

1	docker pull dockercloud/hello-world

Maintenant que nous avons notre image, nous allons la déposer sur ECR
Nous allons nous connecter à la console web aws pour ecs.

1a – Si vous n’avez pas encore utilisé le service

vous allez tomber sur la page “get Started”, il vous suffira alors de cliquer sur le bouton bleu “getStarted” au milieu de la page.
Sur l’écran suivant (Getting Started with Amazon EC2 Container Service), décocher la case pour ne pas déployer la demo ECS (sample)

1b – Si vous avez déjà utilisé ECS

Il suffit de cliquer sur “Repositories” puis sur “Create Repository”

2 – Sur la page suivante

vous allez pouvoir donner un nom à votre dépôt, helloworld dans notre cas. Puis l’on passe à l’étape suivante (Next step)

3 – La dernière page

elle nous donne toutes les indications pour utiliser le dépôt qui vient d’être créé.

2 – Ajout d’une image sur ECR

Nous allons déposer notre image HelloWorld sur le dépôt. Pour cela nous allons nous connecter sur ECR à partir de notre machine (notre dépôt est en ireland)

aws ecr get-login --no-include-email --region eu-west-1
 docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com

1 2	aws ecr get-login --no-include-email --region eu-west-1 docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com

Nous obtenons une ligne de commande qui va nous permettre de nous connecter à ECR

docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com
 Login Succeeded

1 2	docker login -u AWS -p eyJwRXl…...iMSIsZnR5cGUKOiJEQWRBX0tFWSJ8 https://123456789012.dkr.ecr.eu-west-1.amazonaws.com Login Succeeded

Nous sommes maintenant connectés, nous pouvons pousser l’image locale

docker tag dockercloud/hello-world:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest
docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest

1 2	docker tag dockercloud/hello-world:latest 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest docker push 123456789012.dkr.ecr.eu-west-1.amazonaws.com/helloworld:latest

Si vous vous connectez sur la console web AWS, vous pourrez voir votre image dans le dépôt

Dans le prochain article nous allons utiliser cette image pour lancer un container docker sur ECS.

@ Très bientôt

Le SLA chez Amazon Web Services #AWS

2 janvier 2017 corexpert

Cet article a été mis à jour en janvier 2019 avec les modifications du SLA fourni par AWS. Les compléments d’information ont été intégrés directement dans l’article d’origine.

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, vue 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.

Extrait de la page SLA – Amazon Route 53 au 29 décembre 2016

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 executer vos Machines Virtuelles, aka instances EC2 et le stockage virtualisé Amazon Elastic Block Store. [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é était avérée entre 99.95 et 99.0%, AWS s’engage à effectuer une remise de 10% en crédits AWS sur le service EC2, en deça de 99.0% de disponibilité AWS proposera une remise de 30% en crédits. [La période d’indisponibilité est maintenant de 90.0% à 99.99% depuis 2018 pour la remise de 10% de crédit AWS.]

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, comprendre 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 connection échouent pendant une minute sur l’instance RDS multi-AZ.

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 36 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ça 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 simple 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.

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 depuis janvier 2019 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.

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.