L'art de mettre à l'échelle les conteneurs : Surveillance

La mise à l’échelle des conteneurs ne se résume pas simplement à placer un proxy devant un service et à s’en aller. La mise à l'échelle ne se limite pas à la distribution. Dans le monde en évolution rapide des conteneurs, cinq capacités distinctes sont nécessaires pour garantir la mise à l'échelle : les nouvelles tentatives , les disjoncteurs , la découverte , la distribution et la surveillance.

Dans cet article sur l’art de mettre à l’échelle les conteneurs, nous allons nous pencher sur la surveillance.

Surveillance

Surveillance. À une époque où tout semble être à l’écoute et/ou à la surveillance, depuis la vitesse à laquelle nous conduisons jusqu’au contenu de notre réfrigérateur, ce mot laisse un goût amer dans beaucoup de bouches. Nous pouvons utiliser – et le faisons souvent – le mot « visibilité » à la place, mais ce sophisme sémantique ne change pas ce que nous faisons : nous observons, de près.

Tout ce qui concerne l’échelle repose sur la surveillance, c’est-à-dire sur la connaissance de l’état des ressources sur lesquelles vous répartissez les demandes. Envoyer une requête vers une « zone morte » parce que la ressource est tombée en panne ou a été récemment fermée revient à s’engager dans une impasse sans débouchés. C'est une perte de temps.

La surveillance se décline sous de nombreuses formes. Il y a la surveillance « Puis-je vous joindre » d'un ping au niveau de la couche réseau. Il y a la surveillance « êtes-vous à la maison » d'une connexion TCP. Et il y a le « répondez-vous à la porte » d'une requête HTTP. Ensuite, il y a la surveillance « Avez-vous déjà bu votre café » qui détermine si le service répond correctement ou non.

En plus de vérifier simplement l'état de santé et l'exécution d'un service, il faut également surveiller les performances. La rapidité avec laquelle le service répond est essentielle si vous distribuez les demandes en fonction des temps de réponse. Des changements soudains dans les performances peuvent indiquer des problèmes, ce qui signifie qu’il s’agit de données historiquement significatives qui doivent également être surveillées.

Il existe une surveillance active (laissez-moi vous envoyer une vraie demande !), une surveillance synthétique (laissez-moi vous envoyer une fausse demande) et une surveillance passive (je vais simplement m'asseoir ici et regarder ce qui arrive à une vraie demande). Chacune d’entre elles présente des avantages et des inconvénients, et toutes constituent des méthodes de surveillance valables. L’essentiel est que le proxy soit capable de déterminer le statut : est-il en marche ? est-il en panne ? a-t-il quitté le bâtiment avec Elvis ?

L'accessibilité, la disponibilité et les performances sont autant d'aspects de la surveillance et sont nécessaires pour garantir l'évolutivité. Cela signifie qu’il ne s’agit pas seulement de surveillance, mais de s’assurer que les proxys d’équilibrage de charge disposent d’informations à jour concernant l’état de chaque ressource vers laquelle ils peuvent diriger une demande.

Si vous pensez à la nature des conteneurs et à la propension à les associer à une architecture basée sur des microservices, vous pouvez voir que la surveillance devient rapidement une proposition cauchemardesque. C’est parce que le modèle d’équilibrage de charge le plus populaire dans les environnements de conteneurs est celui des proxys de transfert (et side-car). Les deux nécessitent que chaque nœud soit informé de la santé et du bien-être de chaque ressource à laquelle il pourrait avoir besoin d’envoyer une demande. Cela signifie surveiller presque toutes les ressources.

Vous pouvez imaginer qu’il n’est pas vraiment efficace pour une ressource donnée de dépenser ses propres ressources limitées en répondant à quinze ou vingt proxys de transfert quant à son statut. La surveillance dans un tel modèle a un effet négatif significatif sur les performances et la capacité, ce qui rend la mise à l’échelle encore plus difficile.

La surveillance n’a jamais eu un impact aussi important à l’échelle que celui que nous observons avec les conteneurs.

Et pourtant, c’est essentiel – comme indiqué ci-dessus – car nous ne voulons pas perdre de temps avec des ressources « sans issue » si nous pouvons l’éviter.

Les défis liés à la surveillance nécessaire sont l’une des raisons pour lesquelles le service mesh continue de gagner en popularité (et en popularité) en tant que futur modèle d’échelle dans les environnements de conteneurs.

Parce que la surveillance n’est pas facultative, mais elle ne doit pas non plus être un fardeau.