ALOM

Patterns orientés cloud

UBER

Problématiques :

Comment déployer les services ?

Comment gérer la configuration des services ?

Comment analyser l'enchaînement des appels ?

Comment connaître l'état de l'application ?

Cloud "as a service"

IaaS : Infrastructure as a Service
PaaS : Platform as a Service
SaaS : Software as a Service

Cloud 🇫🇷

IaaS : VM, Disks, Load-Balancers
- OVH Cloud
- Scaleway
- nua.ge
- hopla.cloud
- Outscale
PaaS : Database, Middleware, Object Storage, Runtime Java / Container, Functions
- OVH : Databases & k8s, Object Storage
- Scaleway: Databases & k8s, Object Storage, Serverless Functions
- Clever-Cloud: PaaS, Databases, Object Storage
- Scalingo: PaaS, Databases

Cloud 🇺🇲

IaaS : VM, Disks, Load-Balancers
- AWS EC2
- GCP GCE
- Azure VM
PaaS : Database, Middleware, Object Storage, Runtime Java / Container, Functions
- AWS : RDS Databases, EKS, S3 Object Storage, AWS Lambdas
- GCP Cloud SQL, GKE, GCS Object Storage, Cloud Functions, App Engine, Pub/Sub
- Azure SQL Database, AKS, Azure Blob Storage, Azure Functions

Une architecture Cloud

Une application Java dans un assemblage de services Cloud

Une architecture Cloud

DNS (Route53)
Load Balancers (ALB)
VM (EC2) ⬅️ notre code est ici
Base de données managée (PostgreSQL)
Cache managé (ElasticSearch)
CDN (CloudFront)
Stockage objet (S3)
Messaging (SQS)
Mailing (SES)

Patterns d'architecture

Configuration externalisée

Permet d'exécuter un service dans multiples environnements sans modifications

Accès BDD
Gestion sécurité
etc...

Plusieurs stratégies

Profiles : un fichier de configuration par profil
Variables d'environnement
Serveur de configuration

Configuration externalisée en Spring

Profils

Activation par la properties spring.profiles.active
ou variable d'environnement SPRING_PROFILES_ACTIVE

Permet de charger un fichier application-{profile}.properties en plus du application.properties.

Exemples: application-local.properties et application-prod.properties contenant des ports/connexions BDD différentes.

Configuration externalisée chez Spring

Variables d'environnement

Toutes les properties Spring peuvent être surchargées par des variables d'environnement

Les . sont remplacés par des _.
Tout est mis en majuscule
Le camel-case est convertit en _

Configuration externalisée chez Spring

Variables d'environnement

Exemples:

server.port=8080 ➡️ SERVER_PORT=8080
trainer.service.username=vegeta ➡️ TRAINER_SERVICE_USERNAME=vegeta
trainer.serviceUrl=https://someurl:8080 ➡️ TRAINER_SERVICE_URL=https://someurl:8080

Configuration externalisée chez Spring

Interpolation de properties

Il est possible dans des properties d'en utiliser d'autres

trainer.service.host=someHost
trainer.service.port=8080
trainer.service.url=https://${trainer.service.host}:${trainer.service.port}

Patterns d'architecture

Centralisation des logs et correlation

Centralisation des logs

Dans un environnement load-balancé, les requêtes d'un utilisateur peuvent être traitées par n'importe quel serveur.

Dans un environnement cloud, on ne peut pas forcément accéder aux machines pour consulter les fichiers de log.

Dans un environnement conteneurisé, on ne peut pas forcément accéder aux logs des containers (kubernetes...)

Centralisation des logs

On envoie tous les logs dans un service dédié

un service lit les fichiers de log ou la sortie standard `stdout` et envoie les lignes au serveur
les logs sont indexés et conservés
une IHM permet de les consulter

Centralisation des logs

logs JSON

Pour rendre les logs _requêtables_, ils sont souvent parsés :

2023-11-28T14:05:57.429+01:00  INFO 62385 --- [           main] c.miage.altea.tp.trainer_api.TrainerApi  : Started TrainerApi in 2.891 seconds (process running for 3.219)

On configure parfois les loggers pour émettre du JSON directement utilisable en centralisation.

Centralisation des logs

Produit connus :

Stack "ELK"

Elasticsearch : indexation des logs, et recherche "full-text"
Logstash : Parsing des fichiers de logs, et envoi à Elasticsearch
Kibana : IHM de consultation d'Elasticsearch : recherche, dashboards...

Correlation des logs

Observer la séquencialité des appels

Observer les logs d'un même utilisateur

Trouver des points de contention

Aide au debugging

Correlation des logs

Correlation des appels via des Headers HTTP

Création d'un id pour chaque requête reçue

Transmission de l'id à chaque requête envoyée

Envoi des traces à un outil centralisé

Correlation des logs

Spring Cloud Sleuth permet de gérer ces correllation (il modifie les RestTemplate pour transmettre ces fameux headers).

Zipkin permet de collecter/consulter ce type d'information

Correlation des logs

Patterns d'architecture

Observabilité / Métriques

Métriques

Observer la santé des services

healthcheck : est-ce que le service répond, est-ce que la BDD est bien connectée
trace : récupérer les dernières requêtes HTTP traitées
metrics : consommations mémoire / CPU

Métriques métier (~analytics)