Concevoir des applications élastiques, distribuées et résilientes
Comprendre comment une application exploite réellement le cloud en répartissant la charge, en automatisant son déploiement et en tolérant les pannes.
Le cloud permet d'obtenir ou de libérer rapidement des ressources. Une application doit cependant être conçue pour pouvoir exploiter cette capacité.
Si un logiciel dépend d'un unique serveur impossible à répliquer, ajouter automatiquement de nouvelles machines n'améliore pas nécessairement sa capacité.
Deux directions pour changer d'échelle
Vertical scaling
Une instance existante reçoit davantage de CPU ou de mémoire. La méthode est simple mais reste limitée par la capacité maximale d'une machine.
Horizontal scaling
Plusieurs instances du même service fonctionnent simultanément. La charge peut alors être distribuée entre elles.
Répartir plutôt que dépendre d'une seule instance
Le horizontal scaling demande généralement de limiter les dépendances à l'état local d'une instance. Les données persistantes doivent être placées dans des services adaptés afin qu'une requête puisse être traitée par plusieurs instances interchangeables.
Un load balancer peut ensuite répartir les requêtes entre les instances disponibles.
Lorsque la charge augmente, l'orchestrateur peut ajouter des instances. Lorsqu'elle diminue, certaines peuvent être supprimées. C'est l'un des mécanismes permettant de concrétiser l'élasticité du cloud.
Concevoir en supposant que les pannes arriveront
Une infrastructure distribuée contient de nombreux composants et aucun d'entre eux n'est infaillible. La résilience consiste donc moins à empêcher toute panne qu'à concevoir le système pour continuer à fonctionner ou se rétablir lorsqu'une panne survient.
La réplication permet par exemple de conserver plusieurs instances d'un service. Une plateforme d'orchestration peut détecter la disparition d'une instance et en démarrer une nouvelle.
La disponibilité dépend néanmoins de l'architecture complète. Répliquer une application ne suffit pas si toutes ses instances dépendent de la même base de données ou du même composant critique.
Observer pour automatiser
L'automatisation repose enfin sur des informations mesurables. Métriques, logs et traces permettent d'observer le comportement d'un système distribué.
Ces données peuvent servir aux équipes pour diagnostiquer un problème, mais aussi aux plateformes pour prendre certaines décisions automatiques, comme augmenter le nombre d'instances lorsqu'une métrique dépasse un seuil défini.
Le cloud fournit des ressources élastiques, mais la résilience reste une propriété de l'architecture. Une application doit être conçue pour se distribuer, être observée et accepter la disparition de certains composants sans dépendre d'une machine particulière.
Sources
- NIST : The NIST Definition of Cloud Computing : csrc.nist.gov
- Kubernetes : Horizontal Pod Autoscaling : kubernetes.io
- Kubernetes : Kubernetes Self-Healing : kubernetes.io
- CNCF : Cloud Native Architecture : architecture.cncf.io