Par Ashley Davis
* Cet article a été initialement publié sur TheNewStack
Les applications basées sur des microservices peuvent être mises à l’échelle de plusieurs manières. Nous pouvons les mettre à l’échelle pour soutenir le développement par des équipes de développement plus grandes et nous pouvons également les faire évoluer pour de meilleures performances. Notre application peut alors avoir une capacité plus élevée et peut gérer une charge de travail plus importante.
L’utilisation de microservices nous donne un contrôle granulaire sur les performances de notre application. Nous pouvons facilement mesurer les performances de nos microservices pour trouver ceux qui fonctionnent mal, sont surchargés de travail ou surchargés en période de pointe. La figure 1 montre comment nous pourrions utiliser Tableau de bord Kubernetes pour comprendre l’utilisation du processeur et de la mémoire pour nos microservices.
Figure 1: Affichage de l’utilisation du processeur et de la mémoire pour les microservices dans le tableau de bord Kubernetes
Si nous utilisions un monolithe, cependant, nous aurions un contrôle limité sur les performances. Nous pourrions redimensionner verticalement le monolithe, mais c’est essentiellement tout.
La mise à l’échelle horizontale d’un monolithe est beaucoup plus difficile; et nous ne pouvons tout simplement pas mettre à l’échelle indépendamment l’une des «parties» d’un monolithe. Ce n’est pas l’idéal, car ce n’est peut-être qu’une petite partie du monolithe qui cause le problème de performances. Pourtant, nous aurions à redimensionner verticalement le monolithe entier pour le réparer. La mise à l’échelle verticale d’un grand monolithe peut être une proposition coûteuse.
Au lieu de cela, avec les microservices, nous avons de nombreuses options de mise à l’échelle. Par exemple, nous pouvons affiner indépendamment les performances de petites parties de notre système pour éliminer les goulots d’étranglement et obtenir la bonne combinaison de résultats de performance.
Il existe également de nombreuses façons avancées de résoudre les problèmes de performances, mais dans cet article, nous allons présenter une poignée de techniques relativement simples pour faire évoluer nos microservices à l’aide de Kubernetes:
- Mise à l’échelle verticale de l’ensemble du cluster
- Mise à l’échelle horizontale de l’ensemble du cluster
- Mise à l’échelle horizontale des microservices individuels
- Mise à l’échelle élastique de l’ensemble du cluster
- Mise à l’échelle élastique des microservices individuels
La mise à l’échelle nécessite souvent des modifications de configuration risquées de notre cluster. Pour cette raison, vous ne devez pas essayer d’apporter ces modifications directement à un cluster de production dont dépendent vos clients ou votre personnel.
Au lieu de cela, je vous suggère de créer un nouveau cluster et d’utiliser déploiement bleu-vert, ou une stratégie de déploiement similaire, pour protéger vos utilisateurs des modifications risquées de votre infrastructure.
Mise à l’échelle verticale du cluster
Au fur et à mesure que nous développons notre application, nous pourrions arriver à un point où notre cluster ne dispose généralement pas de suffisamment de calcul, de mémoire ou de stockage pour exécuter notre application. Au fur et à mesure que nous ajoutons de nouveaux microservices (ou répliquons des microservices existants pour la redondance), nous finirons par maximiser les nœuds de notre cluster. (Nous pouvons surveiller cela via notre fournisseur de cloud ou le tableau de bord Kubernetes.)
À ce stade, nous devons augmenter la quantité totale de ressources disponibles pour notre cluster. Lors de la mise à l’échelle des microservices sur un Cluster Kubernetes, nous pouvons tout aussi bien utiliser une mise à l’échelle verticale ou horizontale. La figure 2 montre à quoi ressemble la mise à l’échelle verticale pour Kubernetes.
Figure 2: mise à l’échelle verticale de votre cluster en augmentant la taille des machines virtuelles (VM)
Nous augmentons notre cluster en augmentant la taille des machines virtuelles (VM) dans le pool de nœuds. Dans cet exemple, nous avons augmenté la taille de trois machines virtuelles de petite taille afin de disposer désormais de trois machines virtuelles de grande taille. Nous n’avons pas changé le nombre de VM; nous venons d’augmenter leur taille en faisant évoluer nos machines virtuelles verticalement.
Le listing 1 est un extrait du code Terraform qui provisionne un cluster sur Azure; nous changeons le champ vm_size de Standard_B2ms en Standard_B4ms. Cela met à niveau la taille de chaque machine virtuelle dans notre pool de nœuds Kubernetes. Au lieu de deux processeurs, nous en avons maintenant quatre (un pour chaque VM). Dans le cadre de ce changement, la mémoire et le disque dur de la machine virtuelle augmentent également. Si vous déployez sur AWS ou GCP, vous pouvez utiliser cette technique pour effectuer une mise à l’échelle verticale, mais ces plates-formes cloud offrent différentes options pour différentes tailles de VM.
Nous n’avons toujours qu’une seule VM dans notre cluster, mais nous avons augmenté la taille de notre VM. Dans cet exemple, la mise à l’échelle de notre cluster est aussi simple qu’un changement de code. C’est la puissance de l’infrastructure en tant que code, la technique dans laquelle nous stockons la configuration de notre infrastructure sous forme de code et apportons des modifications à notre infrastructure en validant des modifications de code qui déclenchent notre pipeline de livraison continue (CD).
Listing 1: Mise à l’échelle verticale du cluster avec Terraform (un extrait)
Mise à l’échelle horizontale du cluster
En plus de mettre à l’échelle verticalement notre cluster, nous pouvons également le mettre à l’échelle horizontalement. Nos VM peuvent conserver la même taille, mais nous ajoutons simplement plus de VM.
En ajoutant plus de VM à notre cluster, nous répartissons la charge de notre application sur plus d’ordinateurs. La figure 3 illustre comment nous pouvons faire passer notre cluster de trois machines virtuelles à six. La taille de chaque VM reste la même, mais nous gagnons plus de puissance de calcul en ayant plus de VM.
Figure 3: mise à l’échelle horizontale de votre cluster en augmentant le nombre de machines virtuelles
Le listing 2 montre un extrait de code Terraform pour ajouter plus de VM à notre pool de nœuds. De retour dans la liste 1, nous avons mis node_count à 1, mais ici nous l’avons changé en 6. Notez que nous avons rétabli le champ vm_size à la plus petite taille de Standard_B2ms. Dans cet exemple, nous augmentons le nombre de machines virtuelles, mais pas leur taille; bien que rien ne nous empêche d’augmenter à la fois le nombre et la taille de nos VM.
En général, cependant, nous préférons peut-être la mise à l’échelle horizontale car elle est moins coûteuse que la mise à l’échelle verticale. En effet, l’utilisation de nombreuses machines virtuelles plus petites est moins chère que l’utilisation de machines virtuelles moins nombreuses mais plus grandes et plus chères.
Listing 2: Mise à l’échelle horizontale du cluster avec Terraform (un extrait)
Mise à l’échelle horizontale d’un microservice individuel
En supposant que notre cluster est dimensionné à une taille adéquate pour héberger tous les microservices avec de bonnes performances, que faisons-nous lorsque des microservices individuels sont surchargés? (Cela peut être surveillé dans le tableau de bord Kubernetes.)
Chaque fois qu’un microservice devient un goulot d’étranglement des performances, nous pouvons le mettre à l’échelle horizontalement pour répartir sa charge sur plusieurs instances. Ceci est illustré à la figure 4.
Figure 4: Mise à l’échelle horizontale d’un microservice en le répliquant
Nous accordons effectivement plus de calcul, de mémoire et de stockage à ce microservice particulier afin qu’il puisse gérer une plus grande charge de travail.
Encore une fois, nous pouvons utiliser du code pour effectuer ce changement. Nous pouvons le faire en définissant le champ réplicas dans la spécification de notre déploiement ou pod Kubernetes, comme indiqué dans la liste 3.
Listing 3: Mise à l’échelle horizontale d’un microservice avec Terraform (un extrait)
Non seulement nous pouvons mettre à l’échelle des microservices individuels pour les performances, mais nous pouvons également faire évoluer horizontalement nos microservices pour la redondance, créant ainsi une application plus tolérante aux pannes. En ayant plusieurs instances, il y en a d’autres disponibles pour récupérer la charge chaque fois qu’une seule instance échoue. Cela permet à l’instance défaillante d’un microservice de redémarrer et de recommencer à fonctionner.
Mise à l’échelle élastique pour le cluster
En passant dans un territoire plus avancé, nous pouvons maintenant penser à la mise à l’échelle élastique. Il s’agit d’une technique dans laquelle nous mettons à l’échelle automatiquement et dynamiquement notre cluster pour répondre à différents niveaux de demande.
Chaque fois qu’une demande est faible, Kubernetes peut désallouer automatiquement les ressources qui ne sont pas nécessaires. Pendant les périodes de forte demande, de nouvelles ressources sont allouées pour faire face à l’augmentation de la charge de travail. Cela génère des économies de coûts substantielles car, à tout moment, nous ne payons que les ressources nécessaires pour gérer la charge de travail de notre application à ce moment-là.
Nous pouvons utiliser la mise à l’échelle élastique au niveau du cluster pour développer automatiquement nos clusters qui approchent de leurs limites de ressources. Encore une fois, lors de l’utilisation de Terraform, il ne s’agit que d’un changement de code. Le listing 4 montre comment activer l’autoscaler Kubernetes et définir la taille minimale et maximale de notre pool de nœuds.
La mise à l’échelle élastique pour le cluster fonctionne par défaut, mais il existe également de nombreuses façons de le personnaliser. Recherchez « auto_scaler_profile » dans la documentation Terraform pour apprendre plus.
Listing 4: Activation de la mise à l’échelle élastique pour le cluster avec Terraform (un extrait)
Mise à l’échelle élastique pour un microservice individuel
Nous pouvons également activer la mise à l’échelle élastique au niveau d’un microservice individuel.
Le listing 5 est un exemple de code Terraform qui donne aux microservices une capacité «extensible». Le nombre de réplicas pour le microservice est étendu et contracté de manière dynamique pour répondre à la charge de travail variable pour le microservice (rafales d’activité).
La mise à l’échelle fonctionne par défaut, mais peut être personnalisée pour utiliser d’autres métriques. Voir le Documentation Terraform pour apprendre plus. Pour en savoir plus sur la mise à l’échelle automatique des pods dans Kubernetes, voir la documentation Kubernetes.
Listing 5: Activation de la mise à l’échelle élastique pour un microservice avec Terraform
À propos du livre: Microservices d’amorçage
Vous pouvez en savoir plus sur la création d’applications avec des microservices avec Microservices d’amorçage.
Bootstrapping Microservices est un guide pratique et basé sur des projets pour créer des applications avec des microservices. Cela vous mènera de la création d’un seul microservice à l’exécution d’une application de microservices en production sur Kubernetes, aboutissant à un pipeline de livraison continue automatisé et utilisant infrastructure en tant que code pour pousser les mises à jour en production.
Autres ressources Kubernetes
Cet article est un extrait de Microservices d’amorçage et a été un bref aperçu des façons dont nous pouvons faire évoluer les microservices lors de leur exécution sur Kubernetes.
Nous spécifions la configuration de notre infrastructure à l’aide de Terraform. Créer et mettre à jour notre infrastructure via du code de cette manière est connu sous le nom de infrastructure en tant que code, en tant que technique qui transforme le travail avec l’infrastructure en une tâche de codage et a ouvert la voie à la révolution DevOps.
En apprendre davantage sur Kubernetes, s’il te plait regarde la documentation Kubernetes et le gratuit Introduction à Kubernetes formation.
Pour en savoir plus sur l’utilisation de Kubernetes avec Terraform, veuillez consulter la documentation Terraform.
À propos de l’auteur, Ashley Davis
Ashley est un artisan logiciel, entrepreneur et auteur avec plus de 20 ans d’expérience dans le développement de logiciels, du codage à la gestion d’équipes, puis à la création d’entreprises. Il est le CTO de Sortal, un produit qui trie automatiquement les actifs numériques grâce à la magie de l’apprentissage automatique.
La poste Mise à l’échelle des microservices sur Kubernetes est apparu en premier le Linux Foundation – Formation.
