Tech Radar Cloud - Resilient

Adopt

Architecture ARM

Utiliser l’architecture ARM apporte souvent de meilleures performances pour un coût et une consommation énergétique moindres. Sa démocratisation en a fait un levier FinOps et GreenIT facilement actionnable.

L'architecture ARM (Advanced RISC Machine), réputée pour sa faible consommation d'énergie et ses performances optimisées, a longtemps été prisée pour les appareils mobiles. Ces dernières années, ARM a gagné sa place dans les datacenters, remplaçant l'architecture x86 traditionnelle. AWS promet jusqu’à 20% d’économies et 60% de gain en efficacité énergétique grâce à ses instances Graviton, en comparaison avec des machines équivalentes x86. Cette architecture est donc un levier efficace face à des problématiques de réduction des coûts et de durabilité.

Aujourd'hui, une grande majorité des logiciels sont disponibles via des images docker ARM, et des outils tels que QEMU et BuildKit simplifient la construction d’images multi-plateformes pour les applications. Dans le cas de services cloud managés (bases de données, FaaS...), le passage à l’ARM est souvent transparent sur le plan technique, mais se reflète dans les économies réalisées. Sur Kubernetes, nous pensons que l’adoption de l’architecture ARM couplée à des outils d’autoscaling performants comme Karpenter permet d’utiliser une large gamme de machines et de s’exposer ainsi à un maximum d’instances spot. Par exemple, pour Bpifrance, nous avons déployé une infrastructure à grande échelle, 100% multi-architecture. Sur cette infrastructure, Karpenter sélectionne les machines spot les plus économiques et les plus disponibles : ce sont les instances ARM qu'il choisit presque exclusivement.

Nous recommandons l'utilisation de machines ARM, mais seulement après une évaluation des performances spécifiques à chaque charge de travail avant toute transition définitive. Bien qu'elles soient en général plus efficaces, son rendement dépend des technologies utilisées et des algorithmes implémentés.

Caas

Les services de "Container as a Service" permettent de se rapprocher du "Serverless" sans fondamentalement impacter la façon dont vous organisez ou développez vos applications.

Aujourd'hui la plupart des Cloud Providers proposent une offre CaaS (e.g. CloudRun sur GCP, AWS Lambda/ECS sur AWS, ACA sur Azure). Elle permet un gain important en coûts de maintenance et d'hébergement de par certaines de leurs features (e.g. le scale à 0).

Utiliser un service CaaS aujourd'hui peut être une première grande étape dans la modernisation de vos applications ou la création d'une nouvelle application.

Le CaaS apparaît comme une vraie alternative à :

Kubernetes, de par sa complexité de mise en place et de maintenance
Serverless, de par la transformation architecturale qu'il implique

Un autre avantage du CaaS est qu'il est par définition moins vendor-lock que d'autres services d'hébergement. Votre application est ainsi packagée via un standard du marché (une image OCI) et peut potentiellement être déployée sur n'importe quel service supportant ces images OCI, comme un futur cluster Kubernetes.

Nous avons pu observer plusieurs comportements via l'utilisation de ces services : soit ils sont complètement adoptés et conviennent parfaitement aux besoins de nos clients, soit ils manquent de customisation et ceux-ci sont naturellement poussés vers l'utilisation de Kubernetes. Par exemple, il y a de cela 1 an, Cloud Run ne supportait pas le fait que le CPU soit “always allocated” et nous ne pouvions pas l’utiliser pour des applications ayant des processus en background. Ce n’est plus une problématique aujourd’hui.

Ces services sont devenus incontournables et nous les recommandons. Si l'utilisation d'un Cloud Provider n'est pas une option, il est toujours possible de construire votre propre CaaS en utilisant des technologies open source comme Knative.

Karpenter

Karpenter gère le cycle de vie des nœuds dans un cluster Kube. Il dispose de fonctionnalités pour réduire la taille de son cluster et choisir les instances cloud les moins coûteuses.

Dans le monde du node autoscaling pour Kubernetes, deux solutions majeures existent aujourd’hui :

Kubernetes Cluster Autoscaler (KCA) : déployé manuellement dans le cluster, il est encore très utilisé pour AWS EKS.

Les technologies gérées par les fournisseurs de cloud : notamment GKE avec son mode Autopilot, qui repose souvent sur KCA.

Karpenter se positionne en tant qu'alternative de KCA, avec pour vocation de fonctionner avec n'importe quel Cloud Provider. Aujourd'hui, AWS EKS ainsi qu'Azure AKS sont supportés.

Son fonctionnement n'a pas changé depuis que nous l'avons couvert dans la précédente édition de notre Tech Radar : des CRDs permettent de définir les groupes de nœuds et leurs caractéristiques à l'intérieur de Kubernetes (OS, CPU, RAM, zones de disponibilité...).

Karpenter surveille les nouveaux pods qui ne peuvent pas être assignés à un nœud existant. Dès que cela se produit, Karpenter va assigner le pod à un nœud provenant du groupe qui convient à ses contraintes d’orchestration (tolerations, nodeSelector, (anti)affinities...).

Karpenter est open-source et son développement est très actif, avec des fonctionnalités très intéressantes ajoutées à chaque version : consolidation, disruption, mises à jour automatiques de l'image des nœuds... Prenez le temps de lire chaque changelog !

C'est la solution que nous déployons chez tous nos clients utilisant EKS. Karpenter permet systématiquement de baisser le coût de votre cluster. En le déployant sur Fargate on EKS, seul le Control Plane doit être mis à jour. Notre expérience positive nous a donc poussés à le faire évoluer de Trial vers Adopt.

KEDA

KEDA permet de mettre à l'échelle les applications déployées dans Kubernetes en se basant sur des événements plus riches que des métriques système de base comme le CPU ou la RAM.

S’assurer que les infrastructures puissent supporter la charge rapidement est un de nos objectifs principaux en tant que SRE. Il est cependant difficile de scaler nos ressources par anticipation car nous nous appuyons généralement sur des métriques système comme la consommation de CPU ou RAM. C’est là que KEDA (Kubernetes Event-Driven Autoscaling) intervient.

KEDA est un composant qui étend les fonctionnalités d'autoscaling de Kubernetes en se basant sur des sources d’événements. Il permet ainsi de scaler nos applications en fonction de la charge événementielle de services comme Kafka, RabbitMQ, AWS SQS, PubSub, pour ne citer qu’eux.

On pourrait donc par exemple scaler des workers RabbitMQ en se basant sur le nombre de messages publiés / seconde dans une queue ou le nombre de messages en status “Ready”. On peut également imaginer simplement vouloir démarrer le worker lorsque des messages arrivent dans la queue dans le but de faire des économies. Nous avons bien souvent tendance à nous satisfaire du HPA natif de Kubernetes qui permet une mise à l'échelle des applications en se basant sur des métriques telles que le CPU ou la RAM. Notre expérience nous a montré que c’est loin d’être une solution optimale, surtout quand la charge est fluctuante. En permettant une mise à l'échelle automatique basée sur des événements, KEDA offre une réactivité et une flexibilité supérieure aux solutions traditionnelles de scalabilité.

KEDA est une solution puissante, facile à déployer et à maintenir. Elle s'intègre avec une multitude de sources d'événements telles que les files d'attente de messages, les bases de données ou encore les métriques personnalisées (avec Prometheus par exemple) qui en fait un choix idéal s’adaptant à bon nombre de cas d’usage.

Kubernetes

Kubernetes est le standard de la communauté pour les déploiements résilients et scalables d’applications conteneurisées, malgré une charge de travail non négligeable.

Kubernetes est un orchestrateur de conteneurs permettant de déployer à l’échelle un grand nombre d’applications et de garantir leur résilience. En effet, il permet de répondre notamment aux problématiques suivantes :

Adapter le nombre de réplicas de l’application en fonction de la charge;
Assurer la reproductibilité des déploiements;
Ajouter des composants externes sans trop complexifier le déploiement.

Avant l’ère des conteneurs, on aurait sûrement utilisé des scripts Bash ou des playbooks Ansible pour résoudre ces problématiques. Tout cet outillage est aujourd’hui remplacé par des pipelines de CI/CD permettant de produire les images des conteneurs utilisées pour le déploiement dans Kubernetes. De plus, le load balancing, qui nécessitait auparavant un système d’adresses IP virtuelles, est aujourd’hui pris en charge :

• Nativement par Kubernetes pour le load balancing interne du cluster ;

• Via des intégrations aux Cloud Providers pour le load balancing externe ;

• Via des extensions comme MetalLB sur une infrastructure bare metal.

Enfin, la gestion de la capacité de traitement et l’installation d’outils externes sont facilitées via l’utilisation de son interface en YAML et des différents outils qui en ont émergé comme Kustomize ou Helm. Cependant, il est important de considérer la maintenance de Kubernetes, qui reste conséquente même en utilisant le service managé d'un Cloud Provider, ou une alternative plus visuelle à Kubectl comme K9s. Ainsi, un CaaS sera certes moins extensible, mais plus léger à maintenir que Kubernetes.

Ainsi, nous recommandons Kubernetes à tous nos clients qui ont la capacité de le maintenir et cherchent à mettre en place une plateforme extensible sur laquelle déployer facilement des applications à grande échelle.

PCA

Un plan de continuité d'activité, ou PCA, est une pratique de résilience d’infrastructure, simplifiée par l’aspect distribué des Cloud Providers.

Un plan de continuité d'activité assure la disponibilité d'une infrastructure en cas de désastre. Il est essentiel pour maintenir un haut niveau de disponibilité et une expérience utilisateur fluide.

Avant de le concevoir, il faut estimer le Recovery Time Objective (RTO) et le Recovery Point Objective (RPO) de l'application :

Le temps de récupération (RTO) est le délai maximal acceptable entre l'interruption de service et la restauration du service.
Le point de récupération (RPO) est la durée maximale acceptable depuis le dernier point de récupération de données.

Les Clouds Providers publics proposent plusieurs façons de garantir un PCA :

• Les régions AWS sont localisées dans des pays. Il peut y en avoir plusieurs par pays et sont sous-divisées en zones de disponibilités.

• Les zones de disponibilités regroupent plusieurs datacenters différents qui hébergent les ressources du Cloud Provider.

En fonction des objectifs, l’application sera hébergée sur :
• Une seule zone de disponibilité au sein d’une région
• Plusieurs zones de disponibilité au sein d’une région, (l’approche la plus commune)

• Plusieurs zones de disponibilité au sein de plusieurs régions. Cela garantit une haute disponibilité, mais c’est le plus difficile à maintenir, car il faut garantir la cohérence des données entre plusieurs régions tout en gardant un temps de réponse bas.

Chez Theodo Cloud, nous recommandons de donner la priorité à la mise en place d’un PCA par rapport à un PRA, plan de reprise d’activité, suite à un désastre. En effet, ceux-ci sont coûteux à tester, il en découle rarement des leviers activables et nous sommes convaincus qu’il est surtout primordial qu’ils soient effectués à l’échelle du Cloud Provider.

Synthetic Monitoring

Technique de surveillance de vos applications qui consiste à simuler un utilisateur réel avec des robots pour détecter des dysfonctionnements.

Le Synthetic Monitoring est une technique complémentaire de surveillance de vos applications qui consiste à simuler un utilisateur réel avec des robots pour détecter des dysfonctionnements. En effet, la complexité des architectures cloud fortement distribuées peut rendre incomplète une supervision uniquement basée sur la disponibilité des éléments d’infrastructure.

Généralement, on s’attachera à tester en priorité les chemins critiques d’une application. C’est le parcours utilisateur qui représente la plus forte valeur business. Par exemple, pour un site de vente en ligne, il s’agira du tunnel d’achat :

recherche d’un produit
ajout au panier
paiement

Ce test permettra de s’assurer que vos clients peuvent réellement acheter sur votre site. Il a aussi le mérite de valider que vos services backend, comme la case recherche, le stockage des sessions, etc sont tous opérationnels au moment du test.

D’un simple appel à une API backend au parcours à plusieurs étapes, de nombreux outils vous permettent de mettre en place du Synthetic Monitoring. Que ce soit des outils payants comme Datadog, NewRelic ou DynaTrace ou bien des outils open source comme Blackbox Exporter (Prometheus Stack), le choix est vaste. Veuillez toutefois noter qu’il est préférable d’exécuter ces scénarios depuis l’extérieur de l’infrastructure afin de vous positionner comme un “vrai” client à votre application et ainsi détecter aussi des dysfonctionnements (coupure, latence réseau).

Attention cependant aux dépendances externes : elles peuvent générer des alertes sans que vous ne puissiez agir. Néanmoins, il apparaît important d’être informé si l’un de vos fournisseurs est indisponible. Dans ce cas-là, on vous recommandera d’avoir des procédures spécifiques pour traiter ces évènements et d’implémenter dans vos applications un système de circuit breaker. Votre application se mettra en maintenance automatiquement et vous pourrez avoir un traitement spécifique lors de vos astreintes. On peut imaginer n’être alerté que si le service est inaccessible plus de 1 heure. Le monitoring de vos applications doit être un standard dans votre cycle de développement. Comme la sécurité ou la performance, il faut une étape consacrée à la mise en place d’une surveillance du bon fonctionnement de vos services. Ne négligez pas non plus la maintenance et l’évolution. Vous ne devriez jamais passer en production sans avoir des sondes en place pour être averti en cas de dysfonctionnement. Il n’y a rien de plus frustrant que d’être prévenu par vos clients sans vous en être rendu compte avant.

On recommandera une approche “automatique” en créant des sondes pour chaque application déployée. C’est ce que nous faisons sur nos projets avec la flexibilité de l’API Kubernetes. Ainsi, aucun de nos projets ne passe en production sans avoir le monitoring adéquat validant que le service est bien rendu.

Trial

k6 est un framework de load testing extensible, idéal à utiliser en local, dans votre cluster Kubernetes, ou de façon managée via Grafana Cloud.

k6 est un framework extensible de load testing développé par Grafana Labs. Il permet de tester la résilience de votre infrastructure face à des pics de charge sur des parcours critiques.

k6 utilise JavaScript comme langage de scripting. Il est donc facile pour les développeurs web d'être autonomes pour créer des scénarios de tests à lancer contre leur application.

La force de k6 réside dans le système xk6, qui permet d’ajouter des extensions à l’outil. Le panel de fonctionnalités additionnelles à votre disposition s’est bien élargi depuis 2023. Dans les nouveaux venus, nous retrouvons par exemple le support de gRPC, de JavaScript Streams API ou encore des fonctionnalités encore plus avancées pour les browser tests. La nouvelle qui nous a le plus réjoui chez Theodo Cloud est l’arrivée d’un dashboard web intégré nativement à k6 : plus besoin de construire son propre dashboard Grafana pour analyser ses résultats !

k6 se dote aussi d’un opérateur Kubernetes, dont 8 releases sont sorties depuis notre dernier Tech Radar. Entre autres, il existe maintenant un chart Helm officiel afin de faciliter son déploiement et une CRD PrivateLoadZone qui permet à k6 Cloud de lancer les tests depuis votre cluster Kubernetes. Cependant, il est toujours nécessaire de construire sa propre image de runner k6 pour utiliser des extensions, ce qui est regrettable.

Pour de simples tests HTTP, lancer k6 en local ou depuis une VM sera suffisant pour des tests sporadiques. L'opérateur Kubernetes, quant à lui, sera votre meilleur allié pour effectuer des tests distribués à plus grande échelle. Enfin, k6 est maintenant complètement intégré à la stack Grafana Cloud, si vous cherchez une offre managée.

k6 nous semble aujourd’hui être la solution de tests de charge la plus prometteuse, même face à Locust, pour toutes vos infrastructures cloud et Kubernetes.

Locust

Locust est un outil de test de la tenue en charge de votre application à base de script Python.

Locust fait partie de la famille des outils dits de "Load testing", il permet de décrire des scénarios d'usage de vos applications et ensuite de les faire jouer en simulant de nombreux utilisateurs virtuels.

Réaliser ces tests permet de :

Gagner en confiance sur l'évolution de la performance de votre application;
Vérifier que votre infrastructure actuelle est suffisante pour tenir une charge plus importante;
Identifier les différents axes d’amélioration de la performance de votre application.

La force de Locust réside dans sa simplicité d'utilisation mais également de mise à l'échelle avec son modèle d'agent central et de workers qui permettent d'atteindre de manière quasi illimitée l’attendu de performance que vous voulez valider.

Les scénarios sont très simples à écrire et si vous êtes familier avec Python vous n'aurez que très peu de difficultés à écrire vos premiers tests.

Locust vous mettra également entre les mains une UI présentant des dashboards de performance en temps réel ainsi qu’un contrôle sur les tests en cours (Arrêt/Marche).

Le projet propose régulièrement des améliorations et s’est étoffé dans la gestion des infrastructures de test fortement distribuées et le support de protocoles autres que HTTP comme gRPC. Il offre également maintenant une version cloud de l’outil qui accélère sa mise en place.

Il existe de nombreux outils de test de charges sur le marché mais Locust est aujourd'hui l'un des plus simples et nous vous conseillons de l'essayer au même titre que k6.

Assess

Nomad

Nomad est un orchestrateur de tâches.

L'orchestrateur de tâches est devenu l'un des piliers de l'infrastructure moderne. Kubernetes étant le plus connu, on peut rapidement se persuader que c'est la seule alternative viable et qu'il faut l'adopter par défaut.

C'est un choix que de nombreuses entreprises font car la gestion de conteneurs avec Kubernetes est très mature. Cependant, l'infrastructure d'une grande part des entreprises est hétérogène (conteneurs, VM, webservices...) et serait très coûteuse à conteneuriser. Elles peuvent alors se tourner vers Nomad.

Nomad est un orchestrateur de tâches généraliste créé par Hashicorp. En plus de gérer des conteneurs, Nomad est doté de drivers supportant des tâches sous la forme de machines virtuelles, de simples scripts, d'applications Java, etc. Se présentant comme un simple binaire, Nomad est léger et simple d'installation.

Adossé à Consul (solution de Service Mesh de HashiCorp), il est possible de complètement fédérer ses applications, peu importe la forme qu'elles
ont. Cela procure à Nomad une bonne extensibilité et une capacité d'adaptation à l'existant que n'a pas Kubernetes. La migration vers un orchestrateur est donc beaucoup moins coûteuse que s'il fallait conteneuriser toutes ses applications.

Nos réserves portent sur son manque d'intégration avec les Cloud Providers existants ainsi que son adoption moins grande par la communauté
par rapport à Kubernetes. C'est toutefois un outil qu'il faut considérer si vous avez une infrastructure on- premise volumineuse ou que vos ressources à allouer à l'orchestration de vos tâches sont limitées.

Hold

CloudNativePG

CloudNativePG est un opérateur Kubernetes pour gérer le cycle de vie d'une base de données PostgreSQL.

CloudNativePG utilise 4 CRDs pour gérer des bases de données PostgreSQL :

Cluster, qui définit un

cluster PostgreSQL avec 1 ou plusieurs instances en synchronisation.
Pooler, qui permet de déployer PGBouncer devant un cluster donné.
Backup, qui représente une sauvegarde du cluster à un point donné.
ScheduledBackup, qui permet de créer des objets Backup selon une fréquence donnée.

En s'appuyant sur des fonctionnalités mises à disposition par les Cloud Providers et Kubernetes, telles que les volumes Block Storage, les Volume Snapshots et l'Object Storage, il est possible de créer des bases de données avec un bon niveau d'opérabilité. Accompagné d'une connaissance de PostgreSQL et ses options de configuration, CloudNativePG couvrira les besoins de vos applications.

Cependant notre expérience avec cet opérateur en particulier nous pousse à mettre en garde contre son utilisation en production si votre usage de PostgreSQL est intensif (téraoctets de données, milliers de transactions par seconde) :

• Une mise à jour majeure de PostgreSQL impose de créer un nouveau cluster et d'y répliquer les données de l'ancien, obligeant donc un downtime applicatif.

• La réplication d'une base de données non gérée par CloudNativePG est possible, mais mal documentée.

• Un RBAC Kubernetes trop permissif permet à quelqu'un de supprimer votre base de données en une action.

Tout cela s'accompagne donc de coûts de maintenance et d'opération non-négligeables pour garantir la bonne préservation de vos données. Un service managé de base de données vous permettra d'atteindre une meilleure sérénité à moindre coût.