Pour vraiment profité des avantages du Cloud nous devons revoir comment concevoir nos applications. Heureusement il est possible d’obtenir une architecture efficace rapidement en suivant quelques bons conseils. Dans cette présentation je vais montrer quelques Design Patterns qui permettront à vos applications d’être plus performantes en général (et pas seulement sur le Cloud!).
4. Cloud Design Patterns
Patterns & Practices
• Problem areas in the cloud
• Availability, Data Management, Design and Implementation, Management and
Monitoring, Messaging, Performance and Scalability, Resiliency, Security
• Design Patterns
• Cache-Aside, Circuit Breaker, CompensatingTransaction, Competing Consumers,
Compute Resource Consolidation, CQRS, Event Sourcing, External Configuration
Store, Federated Identity, Gatekeeper, Health Endpoint Monitoring, IndexTable,
Leader Election, MaterializedView, Pipes and Filters, Priority Queue, Queue-Based
Load Leveling, Retry, Runtime Reconfiguration, Scheduler Agent Supervisor,
Sharding, Static Content Hosting,Throttling,Valet Key
• Guidance
• Asynchronous Messaging, Autoscaling, Caching, Compute Partitioning, Data
Consistency, Data Partitioning, Data Replication and Synchronization,
Instrumentation andTelemetry, Multiple Datacenter, Service Metering
5. Pourquoi étudier les Design Patterns
• Communications
• Options et compromis
• Mettre un nom sur les Patterns qui émergent naturellement dans
notre code (répétition des mêmes techniques)
• Avoir une boîte à outils (solutions) bien rempli quand on frappe un
problème
6. Le Design et les Patterns sont plus
importants que les Design Patterns
• « Le voyage est plus important que la destination »
• Si on ne le comprend pas on ne l’utilise pas!
• Ce que nous allons voir est applicable un peu partout, pas seulement
dans le Cloud
8. Mise en œuvre
• Lecture
1. Lors d’une demande pour de la donnée on regarde premièrement dans le Cache
1. Si l’information n’est pas en Cache on la charge du Data Store puis on stock
l’information en Cache (read-through caching)
2. L’information en Cache est retournée au demandeur
• Écriture
• Lors d’une sauvegarde
1. L’information est mise à jour dans le Data Store (write-through strategy)
2. L’information du cache est invalidé
• Techno
• Azure Cache Service, In-Role Cache
• Memcached
9. Avantages
• Peu d’écriture, beaucoup de lecture
• Proximité de l’information
• Réduction de la bande passante (pour Cache local)
10. Problématiques et considérations
• Cohérence entre les données en le Cache et le Data Store
• Durée de vie des données en Cache
• Expulsion des données en Cache
• Amorçage du Cache
• Différents types de Cache
• Mémoire
• Disque
• Service
• Taille optimal du Cache
13. Competing Consumers pattern
• Enable multiple concurrent consumers to process messages received
on the same messaging channel
Producer Consumer
ConsumersProducers
14. Mise en œuvre
• Utilisation d’une queue pour les messages
• Communication asynchrone
• Ajout de plus de ressources pour compétitioner pour les messages
• Techno
• Azure Storage Queue
• Azure ServiceBus Queue andTopic
• MSMQ
15. Avantages
• Découplage des producteurs et consommateurs
• Plus résilient car la queue peut recevoir des messages même si les
consommateurs sont hors-service
16. Problématiques et considérations
• Communication asynchrone (gestion des valeurs de retour)
• Ordonnancement des messages
• Design des services pour la résilience (idempotent)
• Détection et gestion des messages empoissonnés
• Scaling du système de messagerie (queue)
18. Queue-Based Load Leveling pattern
• Use a queue that acts as a buffer between a task and a service that it
invokes in order to smooth intermittent heavy loads that may
otherwise cause the service to fail or the task to time out
100/s 50/s
0
50
100
150
Load
0
20
40
60
Load
50/s?/s
19. Mise en œuvre
• Utilisation d’un système de queue pour les messages
• Étudier les limites des systèmes (throughput)
• Observation du niveau de messages dans la queue
20. Avantages
• Permet d’absorber les spikes temporaire de messages
• Prévenir la surcharge de services externes (Azure SQL Database)
• Améliore la disponibilité et l’efficacité des services
21. Problématiques et considérations
• On doit étudier la limite des services afin d’éviter de les surcharger
(monitoring)
• Trop de producteurs/consommateurs pour une queue peut affecter sa
disponibilité
• Seulement pour les spikes! Si la charge reste toujours au dessus de la
limite du système nous devons trouver une autre solution (scaling)
23. Priority Queue pattern
• Prioritize requests sent to services so that requests with a higher
priority are received and processed more quickly than those of a
lower priority
1231 3 23 1
24. Mise en œuvre
• Mettre les nouveaux messages devant les messages moins
importants dans la queue
• Sinon, utilisation de plusieurs queue (1 par priorité)
• Techno
• Azure Storage Queue avec plusieurs queues
• Azure Servive Bus Subscriptions
25. Avantages
• Permet d’établir des niveaux de services (SLA)
• Prioriser les clients payants
• Laisser les messages sans deadline être traiter à la fin
• Faire du scaling uniquement où c’est payant
26. Problématiques et considérations
• Haute priorité veut dire traitement plus rapide
• Est-ce que tous les messages haute priorité doivent être traité avant
les messages basses priorités?
• Besoin d’observer le nombres de messages pour chaque priorité
séparément
• Les différentes priorités devraient être nommées avec de vrai
concepts d’affaires (enterprise vs pro vs free)
• Avoir plusieurs queues multiplie le coût de chercher des messages
27. Materialized View pattern
• Generate prepopulated views over the data in one or more data
stores when the data is formatted in a way that does not favor the
required query operations
28. Mise en œuvre
• Génération à l‘avance des vues matérialisées des données
• Les vues sont jetable (pas la source authoritative)
• Si possible indexées pour de meilleurs performances de requêtage
• Spécialement créer pour un petit nombre de requêtes
29. Avantages
• Optimisées pour la lecture et le requêtage (pas pour l’écriture)
• Données normalisées, semi structurées ou non structurées (DTO pour UI, les
rapports ou l’affichage)
• Peut-être un sous ensemble des données (sans données sensibles)
• Générées à l’avance donc moins de traitements requis (CPU)
• Pas besoin d’être dans le même Data Store que les données originales
(NoSQL)
• En cache si éphémères, peut être reconstruites facilement
• Aussi pour scénarios partiellement connecté
30. Problématiques et considérations
• Quand et comment mettre à jour les vues? (suite à un événement,
suivant un horaire ou déclanchement manuel)
• Peut utiliser beaucoup trop d’espace de stockage si on a beaucoup de
vues
• Gestion des vues avec données périmées