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