🥇Cas d'utilisation du maillage de services

Noter. trad.: L'auteur de cet article (Luc Perkins) est un défenseur des développeurs au sein de l'organisation CNCF, qui héberge des projets Open Source tels que Linkerd, SMI (Service Mesh Interface) et Kuma (d'ailleurs, vous êtes-vous également demandé pourquoi Istio est pas sur cette liste ? .). Essayant une fois de plus d'amener la communauté DevOps à une meilleure compréhension du battage médiatique à la mode appelé « service mesh », il énumère 16 fonctionnalités caractéristiques qu'offrent de telles solutions.

Aujourd'hui maillage de service ― l'un des sujets les plus brûlants dans le domaine du génie logiciel (et à juste titre !). Je pense que cette technologie est incroyablement prometteuse et j’aimerais la voir largement adoptée (quand cela a du sens, bien sûr). Cependant, il reste entouré d’une aura de mystère pour la plupart des gens. En même temps, même ceux qui bien connu avec lui, il est souvent difficile de formuler ses avantages et de quoi il s'agit exactement (y compris le vôtre). Dans cet article, je vais essayer de corriger la situation en énumérant divers cas d'utilisation "mailles de services"*.

* Note trad. : ici et plus loin dans l’article, c’est exactement cette traduction (« service mesh ») qui sera utilisée pour le terme encore nouveau service mesh.

Mais je voudrais d’abord faire quelques commentaires :

Je n'ai jamais travaillé avec des maillages de services ni les ai utilisés en dehors de projets lancés pour ma propre formation. D'un autre côté, c'est moi qui ai écrit un tas de documentation pour le maillage de services interne de Twitter en 2015 (on ne l'appelait même pas un « maillage de services » à l'époque) et j'ai participé au développement du site Web et de la documentation pour Linker, donc ça veut dire quelque chose.
Ma liste est approximative et incomplète. Il se peut qu’il y ait des cas d’utilisation que je ne connais pas, et de nouvelles options apparaîtront probablement au fil du temps, à mesure que la technologie se développera et que sa popularité augmentera.
Dans le même temps, toutes les implémentations de maillage de services existantes ne prennent pas en charge tous les cas d’utilisation répertoriés. Par conséquent, mes déclarations telles que « le maillage de services peut » doivent être lues comme « individuelles, et peut-être que toutes les implémentations de maillage de services populaires peuvent… ».
L'ordre des exemples ne fait aucune différence.

Liste restreinte :

découverte de services ;
chiffrement;
Authentification et autorisation;
l'équilibrage de charge;
coupure de circuit;
mise à l'échelle automatique ;
déploiements Canary ;
déploiements bleu-vert ;
Bilan de santé;
délestage;
mise en miroir du trafic ;
isolation;
limitation du débit des demandes, tentatives et délais d'attente ;
télémétrie;
audit;
visualisation.

1. Découverte des services

TL;DR : connectez-vous à d'autres services sur le réseau en utilisant des noms simples.

Les services doivent être capables de se « trouver » automatiquement en utilisant des noms adéquats – par exemple : service.api.production, pets/staging ou cassandra. Les environnements cloud sont élastiques et un seul nom peut masquer de nombreuses instances d'un service. Il est clair que dans une telle situation, il est physiquement impossible de coder en dur toutes les adresses IP.

De plus, lorsqu'un service en trouve un autre, il devrait pouvoir envoyer des requêtes à ce service sans craindre qu'elles se retrouvent à l'entrée de son instance cassée. En d’autres termes, le maillage de services doit surveiller la santé de toutes les instances de service et maintenir la liste des hôtes aussi à jour que possible.

Chaque maillage de services implémente le mécanisme de découverte de services différemment. À l’heure actuelle, la méthode la plus courante consiste à déléguer à des processus externes tels que Kubernetes DNS. Dans le passé, sur Twitter, nous utilisions un système de noms à cet effet. Finaglé. De plus, la technologie de maillage de services permet l'émergence de mécanismes de dénomination personnalisés (même si je n'ai encore vu aucune implémentation SM avec une telle fonctionnalité).

2. Cryptage

TL;DR : débarrassez-vous du trafic non chiffré entre les services et rendez ce processus automatisé et évolutif.

Il est bon de savoir que les attaquants ne peuvent pas pénétrer votre réseau interne. Les pare-feu font un excellent travail à cet égard. Mais que se passe-t-il si un pirate informatique pénètre à l’intérieur ? Pourra-t-il faire ce qu’il veut du trafic intra-service ? Espérons que cela n'arrivera pas après tout. Pour éviter ce scénario, vous devez mettre en œuvre un réseau Zero Trust dans lequel tout le trafic entre les services est chiffré. La plupart des réseaux de services modernes y parviennent grâce à des échanges mutuels. TLS (TLS mutuel, mTLS). Dans certains cas, mTLS fonctionne dans des nuages et des clusters entiers (je pense qu'un jour les communications interplanétaires seront organisées de la même manière).

Bien sûr, pour le maillage de services mTLS facultatif. Chaque service peut gérer son propre TLS, mais cela signifie que vous devrez trouver un moyen de générer des certificats, de les distribuer entre les hôtes de service et d'inclure du code dans l'application qui chargera ces certificats à partir de fichiers. Oui, n’oubliez pas de renouveler ces certificats à intervalles réguliers. Les maillages de services automatisent mTLS avec des systèmes tels que SPIFFE, qui, à leur tour, automatisent le processus de délivrance et de rotation des certificats.

3. Authentification et autorisation

TL;DR : déterminez qui est le demandeur et définissez ce qu'il est autorisé à faire avant même que la demande n'atteigne le service.

Les services veulent souvent savoir qui effectue la demande (authentification), et à l'aide de ces informations, décide que une entité donnée est autorisée à faire (autorisation). Dans ce cas, le pronom « qui » peut cacher :

Autres services. C'est ce qu'on appelle "l'authentification" pair" Par exemple, le service web souhaite accéder au service db. Les maillages de services résolvent généralement de tels problèmes en utilisant mTLS : les certificats dans ce cas agissent comme l'identifiant nécessaire.
Certains utilisateurs humains. C'est ce qu'on appelle "l'authentification" requête" Par exemple, l'utilisateur haxor69 veut acheter une nouvelle lampe. Les maillages de services fournissent divers mécanismes, par ex. Jetons Web JSON.
Beaucoup d'entre nous l'ont fait dans le code d'application. Une demande arrive, on regarde dans le tableau users, recherchez l'utilisateur et comparez le mot de passe, puis vérifiez la colonne permissions etc. Dans le cas d’un maillage de services, cela se produit avant même que la requête n’atteigne le service.

Une fois que nous avons établi de qui provient la demande, nous devons déterminer ce que cette entité est autorisée à faire. Certains maillages de services vous permettent de définir des politiques de base (sur qui peut faire quoi) sous forme de fichiers YAML ou sur la ligne de commande, tandis que d'autres offrent une intégration avec des frameworks comme Ouvrir l'agent de stratégie. Le but ultime est que vos services acceptent toute demande, en supposant qu'elle provienne d'une source fiable. и cette action est autorisée.

4. Équilibrage de charge

TL;DR : répartissez la charge entre les instances de service selon un modèle spécifique.

Un « Service » au sein d’une section de service se compose très souvent de nombreuses instances identiques. Par exemple, aujourd'hui le service cache se compose de 5 exemplaires, et demain leur nombre pourrait passer à 11. Demandes envoyées à cache, doivent être distribués conformément à un objectif précis. Par exemple, minimisez la latence ou maximisez la probabilité d’accéder à une instance fonctionnelle. L'algorithme le plus couramment utilisé est le Round-robin, mais il en existe bien d'autres, par exemple la méthode pondérée. (pondéré) requêtes (vous pouvez sélectionner les cibles préférées), sonnerie (bague) hachage (en utilisant un hachage cohérent sur les hôtes en amont) ou méthode de moindre requête (la préférence est donnée à l'instance avec le moins de requêtes).

Les équilibreurs classiques ont d'autres fonctions, telles que la mise en cache HTTP et la protection DDoS, mais ils ne sont pas très pertinents pour le trafic est-ouest (c'est-à-dire pour le trafic circulant au sein d'un centre de données - traduction approximative) (portée typique du maillage de services). Bien sûr, il n'est pas nécessaire d'utiliser un maillage de services pour l'équilibrage de charge, mais cela vous permet de définir et de contrôler des politiques d'équilibrage pour chaque service à partir d'une couche de contrôle centralisée, éliminant ainsi le besoin d'exécuter et de configurer des équilibreurs de charge distincts dans la pile réseau. .

5. Coupure de circuit

TL;DR : arrêtez le trafic vers le service problématique et contrôlez les dégâts dans les pires scénarios.

Si, pour une raison quelconque, le service ne peut pas gérer le trafic, le maillage de services propose plusieurs options pour résoudre ce problème (d'autres seront abordées dans les sections appropriées). La coupure de circuit est l’option la plus sévère pour déconnecter un service du trafic. Cependant, cela n’a pas de sens en soi : un plan de secours est nécessaire. Une contre-pression peut être fournie (contre-pression) aux services qui font des requêtes (n'oubliez pas de configurer votre maillage de services pour cela !), ou, par exemple, colorer la page d'état en rouge et rediriger les utilisateurs vers une autre version de la page avec une « baleine qui tombe » (« Twitter est vers le bas").

Les maillages de services vous permettent non seulement de définir lors de l'arrêt suivra et que cela suivra. Dans ce cas, « quand » peut inclure n'importe quelle combinaison de paramètres spécifiés : le nombre total de requêtes pour une certaine période, le nombre de connexions parallèles, les requêtes en attente, les tentatives actives, etc.

Vous ne voulez probablement pas abuser de la coupure de circuit, mais il est bon de savoir que vous disposez d'un plan de secours en cas d'urgence.

6. Mise à l'échelle automatique

TL;DR : augmentez ou diminuez le nombre d'instances de service en fonction des critères spécifiés.

Les maillages de services ne sont pas des planificateurs, donc ils ne le font pas. effectuer vous mettre à l'échelle. Cependant, ils peuvent fournir des informations sur lesquelles les planificateurs fonderont leurs décisions. Étant donné que les maillages de services ont accès à tout le trafic entre les services, ils disposent d'informations détaillées sur ce qui se passe : quels services rencontrent des problèmes, quels services sont très peu chargés (la capacité qui leur est allouée est gaspillée), etc.

Par exemple, Kubernetes fait évoluer les services en fonction de l'utilisation du processeur et de la mémoire des pods. (voir notre reportage "Mise à l'échelle automatique et gestion des ressources dans Kubernetes" - environ. trad.), mais si vous décidez d'évoluer en fonction d'une autre métrique (dans notre cas, liée au trafic), vous aurez besoin d'une métrique spéciale. Gestion comme ça montre comment procéder avec Envoyé, Istio и Prométhée, mais le processus lui-même est assez compliqué. Nous aimerions que le maillage de services simplifie cela en nous permettant de simplement définir des conditions telles que « augmenter le nombre d'instances de service ». auth, si le nombre de demandes en attente dépasse le seuil en une minute."

7. Déploiements Canary

TL;DR : testez de nouvelles fonctionnalités ou versions de service sur un sous-ensemble d'utilisateurs.

Disons que vous développez un produit SaaS et que vous avez l'intention d'en déployer une nouvelle version intéressante. Vous l'avez testé en mise en scène et cela a très bien fonctionné. Mais certaines inquiétudes subsistent quant à son comportement en conditions réelles. En d’autres termes, vous devez tester la nouvelle version sur des problèmes réels sans risquer la confiance des utilisateurs. Les déploiements Canary sont parfaits pour cela. Ils vous permettent de démontrer une nouvelle fonctionnalité à un sous-ensemble d’utilisateurs. Ce sous-ensemble peut être constitué des utilisateurs les plus fidèles ou de ceux qui travaillent avec la version gratuite du produit, ou encore d'utilisateurs qui ont exprimé le désir de servir de « cobayes ».

Les maillages de services implémentent cela en vous permettant de spécifier des critères qui déterminent qui verra quelle version de l'application et d'acheminer le trafic en conséquence. En revanche, rien ne change pour les services eux-mêmes. La version 1.0 du service estime que toutes les demandes proviennent d'utilisateurs qui devraient le voir, et la version 1.1 pense la même chose pour ses utilisateurs. En attendant, vous pouvez modifier le pourcentage de trafic entre l'ancienne et la nouvelle version, en redirigeant un nombre croissant d'utilisateurs vers la nouvelle si elle fonctionne de manière stable et si vos « cobayes » donnent le feu vert.

8. Déploiements bleu-vert

TL;DR : Déployez une nouvelle fonctionnalité intéressante, mais soyez prêt à tout reprendre immédiatement.

Sens déploiements bleu-vert est de déployer un nouveau service « bleu », en le lançant en parallèle de l'ancien service « vert ». Si tout se passe bien et que le nouveau service fonctionne bien, l'ancien peut être progressivement désactivé. (Hélas, un jour, ce nouveau service « bleu » répétera le sort du service « vert » et disparaîtra...) Les déploiements bleu-vert diffèrent des déploiements canari dans le sens où la nouvelle fonction couvre tout à la fois utilisateurs (pas partie); Le but ici est de disposer d’une « sphère de sécurité » prête au cas où quelque chose tournerait mal.

Les maillages de services offrent un moyen très pratique de tester un service « bleu » et de passer instantanément à un service « vert » fonctionnel en cas de problème. Sans parler du fait qu'en chemin, ils fournissent de nombreuses informations (voir « Télémétrie » ci-dessous) sur le travail du « bleu », ce qui permet de comprendre s'il est prêt à fonctionner pleinement.

Noter. trad.: Vous pouvez en savoir plus sur les différentes stratégies de déploiement dans Kubernetes (y compris les stratégies Canary, Blue/Green et autres mentionnées) dans cet article.

9. Bilan de santé

TL;DR : gardez une trace des instances de service qui sont fonctionnelles et répondez à celles qui ne le sont plus.

Bilan de santé (Bilan de santé) aide à décider si les instances de service sont prêtes à accepter et à traiter le trafic. Par exemple, dans le cas des services HTTP, une vérification de l'état peut ressembler à une requête GET adressée au point de terminaison. /health... Réponse 200 OK signifiera que l'instance est saine, toute autre signifie qu'elle n'est pas prête à recevoir du trafic. Les maillages de services permettent de préciser à la fois la manière dont les fonctionnalités seront vérifiées et la fréquence à laquelle ce contrôle sera effectué. Ces informations peuvent ensuite être utilisées à d'autres fins, par exemple pour l'équilibrage de charge et la coupure de circuit.

Ainsi, la vérification de l’état n’est pas un cas d’utilisation autonome, mais est généralement utilisée pour atteindre d’autres objectifs. De plus, en fonction des résultats des contrôles d'état, des actions externes aux autres cibles du maillage de services peuvent être nécessaires : par exemple, mettre à jour la page d'état, créer un ticket sur GitHub ou remplir un ticket JIRA. Et le service mesh offre un mécanisme pratique pour automatiser tout cela.

10. Délestage

TL;DR : rediriger le trafic en réponse à un pic temporaire d'utilisation.

Si un certain service est surchargé de trafic, vous pouvez rediriger temporairement une partie de ce trafic vers un autre emplacement (c'est-à-dire « vider », « transférer »). (hangar) lui là). Par exemple, vers un service de sauvegarde ou un centre de données, ou vers un Pulsar sujet. En conséquence, le service continuera à traiter certaines demandes au lieu de planter et d’arrêter complètement de tout traiter. Le délestage est préférable à la coupure du circuit, mais il reste néanmoins déconseillé d’en abuser. Cela permet d’éviter les pannes en cascade qui provoquent le blocage des services en aval.

11. Parallélisation/miroir du trafic

TL;DR : envoyez une demande à plusieurs endroits à la fois.

Parfois, il est nécessaire d'envoyer une demande (ou une certaine sélection de demandes) à plusieurs services à la fois. Un exemple typique est l’envoi d’une partie du trafic de production vers un service de transfert. Le serveur Web de production principal envoie une requête au service en aval products.production et seulement à lui. Et le maillage de services copie intelligemment cette requête et l'envoie à products.staging, dont le serveur Web n'a même pas connaissance.

Un autre cas d'utilisation du maillage de services connexe qui peut être implémenté en plus de la parallélisation du trafic est les tests de régression. Cela implique d'envoyer les mêmes requêtes à différentes versions du service et de vérifier si toutes les versions se comportent de la même manière. Je n'ai pas encore rencontré d'implémentation de maillage de services avec un système de test de régression intégré comme Différent, mais l'idée elle-même semble prometteuse.

12. Isolation

TL;DR : divisez votre maillage de services en mini-réseaux.

Aussi connu sous le nom segmentationL'isolement est l'art de diviser un maillage de services en segments logiquement distincts qui ne connaissent rien les uns des autres. L'isolement, c'est un peu comme créer des réseaux privés virtuels. La différence fondamentale est que vous pouvez toujours profiter de tous les avantages d’un maillage de services (comme la découverte de services), mais avec une sécurité accrue. Par exemple, si un attaquant parvient à pénétrer dans un service sur un sous-réseau, il ne pourra pas voir quels services s'exécutent sur d'autres sous-réseaux ni intercepter leur trafic.

De plus, les avantages peuvent également être organisationnels. Vous souhaiterez peut-être créer un sous-réseau pour vos services en fonction de la structure de votre entreprise et soulager les développeurs de la charge cognitive liée à la nécessité de garder à l'esprit l'ensemble du maillage de services.

13. Demander une limitation de débit, des tentatives et des délais d'attente

TL;DR : Vous n'avez plus besoin d'inclure les tâches essentielles de gestion des demandes dans votre base de code.

Toutes ces choses pourraient être considérées comme des cas d'utilisation distincts, mais j'ai décidé de les combiner en raison d'une caractéristique commune : elles prennent en charge les tâches de gestion du cycle de vie des requêtes généralement gérées par les bibliothèques d'applications. Si vous développez un serveur Web dans Ruby on Rails (non intégré à un maillage de services) qui envoie des requêtes aux services backend via gRPC, l'application devra décider quoi faire si N requêtes échouent. Vous devrez également connaître la quantité de trafic que ces services seront capables de traiter et de coder en dur ces paramètres à l'aide d'une bibliothèque spéciale. De plus, l’application devra décider quand il est temps d’abandonner et de laisser la demande s’échouer (en fonction du délai d’attente). Et pour modifier l'un des paramètres ci-dessus, le serveur Web devra être arrêté, reconfiguré et redémarré.

Décharger ces tâches vers un maillage de services signifie non seulement que les développeurs de services n'auront pas à y penser, mais aussi qu'elles pourront être visualisées de manière plus globale. Si une chaîne complexe de services est utilisée, disons A -> B -> C -> D -> E, l'ensemble du cycle de vie de la demande doit être pris en compte. Si la tâche consiste à prolonger les délais d'attente dans le service C, il est logique de le faire en une seule fois, et non en partie : en mettant à jour le code du service et en attendant que la pull request soit acceptée et que le système CI déploie le service mis à jour.

14. Télémétrie

TL;DR : Collectez toutes les informations nécessaires (et pas tout à fait) auprès des services.

La télémétrie est un terme général qui inclut les métriques, le traçage distribué et les journaux. Les maillages de services offrent des mécanismes de collecte et de traitement des trois types de données. C’est là que les choses deviennent un peu floues car le nombre d’options possibles est trop important. Pour collecter des métriques, il existe Prométhée et d'autres outils qui peuvent être utilisés pour collecter des journaux couramment, Loki, vecteur etc (par exemple ClickHouse avec notre chalet pour les K8 - env. trad.), pour le traçage distribué, il y a Jaeger et ainsi de suite. Chaque maillage de services peut prendre en charge certains outils et pas d'autres. Il sera intéressant de voir si le projet peut Télémétrie ouverte permettent une certaine convergence.

Dans ce cas, l’avantage de la technologie de maillage de services est que les conteneurs side-car peuvent, en principe, collecter toutes les données ci-dessus à partir de leurs services. En d’autres termes, vous disposez d’un système unique de collecte de télémétrie, et le maillage de services peut traiter toutes ces informations de différentes manières. Par exemple:

journaux de queue d'un certain service dans la CLI ;
surveiller le volume des demandes à partir du tableau de bord du maillage de services ;
collectez les traces distribuées et transmettez-les à un système comme Jaeger.

Attention, jugement subjectif : D'une manière générale, la télémétrie est un domaine dans lequel de fortes interférences provenant du maillage de services ne sont pas souhaitables. Collecter des informations de base et suivre à la volée certaines mesures clés comme le taux de réussite des requêtes et la latence, c'est bien, mais espérons que nous ne verrons pas émerger des piles Frankenstein qui tentent de remplacer des systèmes spécialisés, dont certains ont déjà fait leurs preuves et sont bien étudiés. .

15. Audit

TL;DR : Ceux qui oublient les leçons de l’histoire sont condamnés à les répéter.

L'audit est l'art d'observer les événements importants dans un système. Dans le cas d'un maillage de services, cela peut impliquer de suivre qui a fait des demandes à des points de terminaison spécifiques pour des services spécifiques, ou combien de fois un événement lié à la sécurité s'est produit au cours du mois dernier.

Il est clair que l’audit est très étroitement lié à la télémétrie. La différence est que la télémétrie est généralement associée à des éléments tels que la productivité et l'intégrité technique, tandis que l'audit peut concerner des questions juridiques et autres qui dépassent la sphère strictement technique (par exemple, le respect du RGPD - le règlement général de l'UE sur la protection des données).

16. Visualisation

TL;DR : Vive React.js - une source inépuisable d'interfaces sophistiquées.

Il existe peut-être un meilleur terme, mais je ne le connais pas. Je veux simplement dire une représentation graphique d'un maillage de services ou de certains de ses composants. Ces visualisations peuvent inclure des indicateurs tels que les latences moyennes, les informations de configuration du side-car, les résultats du contrôle de santé et les alertes.

Travailler dans un environnement orienté service implique une charge cognitive beaucoup plus élevée que celle de Sa Majesté le Monolithe. Il faut donc à tout prix réduire la pression cognitive. Une interface graphique simple pour un service maillé avec la possibilité de cliquer sur un bouton et d'obtenir le résultat souhaité pourrait être décisive pour la croissance de la popularité de cette technologie.

N'étaient pas inclus dans la liste

Au départ, j'avais l'intention d'inclure quelques cas d'utilisation supplémentaires dans la liste, mais j'ai ensuite décidé de ne pas le faire. Les voici, ainsi que les raisons de ma décision :

Centre de données multi. À mon avis, il ne s'agit pas tant d'un cas d'utilisation que d'un domaine d'application étroit et spécifique des maillages de services ou d'un ensemble de fonctions telles que la découverte de services.
Entrée et sortie. Il s'agit d'un domaine connexe, mais je me suis limité (peut-être artificiellement) au cas d'utilisation du "trafic est-ouest". Les entrées et sorties méritent un article séparé.

Conclusion

C'est tout pour le moment! Encore une fois, cette liste est très arbitraire et probablement incomplète. Si vous pensez que j'ai raté quelque chose ou que je me suis trompé, contactez-moi sur Twitter (@luckerkins). Merci de respecter les règles de décence.

PS du traducteur

L’illustration du titre de l’article est basée sur une image de l’article «Qu’est-ce qu’un Service Mesh (et quand en utiliser un) ?" (par Gregory MacKinnon). Il montre comment certaines fonctionnalités des applications (en vert) ont été déplacées vers un maillage de services qui assure les interconnexions entre elles (en bleu).

A lire aussi sur notre blog :

Source: habr.com

Scénarios d'utilisation du maillage de services