This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
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
• 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
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: