© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Rudy Krol, Solutions Architect, AWSAlexandre Ignatovic (CTO) & Benoit Tigeot (Developer), Appaloosa Store

Alexis Daguès (CEO) & Cédric Rumiano (Cloud Native Engineer), Corexpert

27 Juin 2017

Architectures Big Data en ServerlessBonnes pratiques et design patterns

Evolution des architectures Cloud

Optimisé dans le CloudServices managés

Amazon EMR

Amazon Elasticsearch

Service

Amazon ElastiCache

AmazonRDS

Amazon Redshift

AWS Batch

Amazon Lex

AWSLambda

Architecturé pour le CloudServerless

AWSGlue

AmazonS3

AmazonDynamoDB

AmazonAthena

Amazon Kinesis

AmazonSQS

AWSStep Functions

Amazon Polly

Amazon Rekognition

Amazon Machine Learning

AWSIoT

AmazonSNS

AmazonQuickSight

«Lift & Shift»VM

Amazon EC2

AWS Lambda: Nouveau paradigme d’architecture

Architecture évènementielle

Les fonctions comme unité de déploiement

Une facturation par incrément de 100ms d’exécution

AWS Lambda: Stateless

Scalabilitéà la baisse

Mise à jour du serveur

Exception non gérée

Déploiement d’une nouvelle version

de la fonction

Une instance de fonction peut être supprimée en cas de…

Bonne pratique:Utiliser un datastore externe pour stocker les données de cache longue durée ou persistantes (ex: Amazon ElastiCache, Amazon DynamoDB, Amazon S3…)

AWS Lambda: Démarrage à froid

Effet « cold start » à la première exécution de la fonction après instanciation

• Déployer la fonction dans un VPC uniquement si nécessaire

• Activer AWS X-Ray pour mesurer les cold start

Bonnes pratiques:• Initialiser les clients et connections aux bases de

données en dehors de la fonction handler

import sys import logging import rds_configimport pymysql

rds_host = "rds-instance" db_name = rds_config.db_nametry:

conn = pymysql.connect(…except:

logger.error("ERROR:…

def handler(event, context):with conn.cursor() as cur:

…

Exécution à l’initialisation

Exécution à chaque invocation

AWS Lambda: Profil de puissance

Le coût d’exécution d’une fonction dépend du temps d’exécution (en ms) et de la taille de la mémoire allouée (de 128 Mo à 1,5 Go)

Bonne pratique:Utiliser AWS Step Functions pour optimiser l’allocation mémoire de vos fonctions

https://github.com/alexcasalboni/aws-lambda-power-tuning

AWS Lambda: Gestion des erreurs

Timeout Format input invalide

Out of memory Dépassement de limite

Erreur générée par la fonction

• Pour les invocations asynchrones, activer les Dead Letter Queues pour conserver les messages en erreurs et les traiter ultérieurement

• Utiliser AWS Step Functions pour automatiser le traitement des cas d’erreurs• Voir article blog « Automating AWS Lambda Function Error Handling with AWS Step Functions »

Bonnes pratiques:• Configurer des alarmes Amazon CloudWatch et activez Amazon CloudWatch Logs

pour collecter les logs générés par les fonctions

Types d’erreurs à gérer:

Flux de données et solutions Big Data

Orchestration / Transformation

Ingestion Collection Stockage Analyses

TraitementsVisualisation

Consommation

Batch ETL/ELT

RealtimeETL/ELT

Transactional / CDC

B.I. Tools

Data Science Notebooks

Bulk Transport

File/Object Upload

Streaming Ingest

Commits Transactional

NoSQL

Data Lake

Streaming Storage

Dashboards

Batch Analytics

Interactive Querying

Machine Learning/ Deep Learning

Realtime Analytics

= Serverless

AmazonES (Kibana)

Pattern d’architecture: Requêtage interactif

S3 Transfer Acceleration

Amazon S3 Amazon Redshift

Amazon EMR

Presto

Tez

Spark

Interactive

Amazon Athena

Amazon QuickSight

Serverless

Services managés

VM

Amazon Kinesis Firehose

AWS Snowball

Ingestion Collection Stockage Analyses

TraitementsVisualisation

Consommation

Pattern d’architecture: Analyse temps réel

ApacheKafka

KCL

AWS Lambda

Apache Storm

Amazon SNS

Notifications

AmazonElastiCache

AmazonDynamoDB

AmazonRDS

AmazonES (Kibana)

Alertes

Résultats calculs KPI

Amazon DynamoDB Streams

Amazon Kinesis Streams

Amazon Kinesis Analytics

Amazon EMR

Spark Streaming

Apache Flink

Serverless

Services managés

VM

Producteur de données

Ingestion Collection Stockage Analyses

TraitementsVisualisation

Consommation

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Alexandre Ignjatovic, Benoit Tigeot

Mai 2017

Appaloosa.ioConstruction d’un pipeline d’analytics Serverless

Appaloosa est un store d’applications simple et sécurisé

@AppaloosaStore

• 110 clients grands comptes (La Poste, Leroy Merlin, etc.)

• 60 000 applications déployées• 300 000 utilisateurs

Le Challenge

Victime de son succès

• Architecture du pipeline d’analytics ne répondant plus au besoin

Instance MongoDB

APIUtilisateurs Smartphone Interface d’administration

Administrateurs

Les symptômes

Une refonte avec deux impératifs

• Pas de DevOps, de DBA ou de SysAdmin dans l’équipe• Des technologies administrées par le fournisseur de service

• Une entreprise en croissance constante (~1000 clients en plus sur la dernière année)

• Une solution scalable et future proof

Les contraintes

• Un service en cours d’utilisation• Pas d’interruption de service envisageable

• Un volume de données collectées assez important• Jusqu’à 10 000 événements par minute

• Un budget contraint• Solution à remplacer coûtant 800€/mois

La Solution

Amazon Kinesis Firehose + Amazon DynamoDB

APIUtilisateurs Smartphone Interface d’administration

Administrateurs

Amazon Kinesis Firehose

Amazon Redshift Amazon DynamoDB

Batch d’agrégation

Avantages• Mise en place triviale• Pas d’administration

Amazon Kinesis Firehose + Amazon DynamoDB

Inconvénients• Duplication aléatoire des

données• Impossibilité d’ajouter un

consommateur à un flux Amazon Kinesis Firehose

• Alimentation par batch de Amazon DynamoDB non triviale

• Modèle de scaling Amazon DynamoDB pas adapté à une alimentation par batch

Pipeline de collection d’événements

API

Evénements

AmazonKinesis

AmazonKinesis

Firehose

AWS cloud

AWS Lambda

Amazon S3

AmazonRedshift

AWS Lambda

Utilisateurs

Accès aux données

API Amazon RDS(PostgreSQL avec dblink + postgres_fdw)

AWS cloud

AWS Lambda

AmazonRedshift

Administrateurs

Interface d’administration

Collectiond’événements

Avantages

• Efficace quelle que soit la charge en écriture et lecture• Aucune action d’administration requise• Délégation de toutes les questions de sécurité bas

niveau à AWS• Possibilité d’ajout de consommateur sur le flux Amazon

Kinesis• Architecture modulaire, qui permet de nombreuses

évolutions

Quels Bénéfices ?

Collection des données• 1 partition Amazon Kinesis

Ø 60K événements par minute

• Augmenter la capacité du pipeline ou du cluster est trivial

Scalabilité

Consultation des données• Rafraîchissement des données

Ø moins de 1 minute• Temps de réponse

Ø inférieur à 5 ms

Sur 1 mois• Amazon Kinesis (2 partitions)

Ø 24$• Amazon Redshift (1 noeud)

Ø 200$• Amazon RDS (db.t2.micro)

Ø 16$

• Total: 240$ par mois

Coûts

Avantages• 70% d’économies• Modularité du tarif

Et Ensuite ?

La suite ?

• Auto-Scaling Amazon Kinesis et Amazon KinesisFirehose ?

• Des KPIs mis à jour en temps réel dans une instance Amazon ElastiCache ou Amazon DynamoDB (avec DAX) ?

• Amazon Athena en tant qu’outil de BI ?• AWS Step Functions pour matérialiser visuellement le

workflow du pipeline ?

Pour en savoir plus

• L’histoire complète de la migration sur notre compte medium:

• bit.ly/appaloosa_aws_1• bit.ly/appaloosa_aws_2

• N’hésitez pas à visiter appaloosa.io !

© 2016, Amazon Web Services, Inc. or its Affiliates. All rights reserved.

Alexis DAGUES - CEOCédric RUMIANO - Cloud Native Engineer

Intelligence Artificielle en temps-réelsur un flux vidéo

Analyse de vidéo en Serverless avec Amazon Rekognition

Architecture Serverless – Amazon Rekognition

Votre feedback est important.Prenez quelques instants pour voter sur :

etc.ch/qZG3

Merci !