L’art de faire évoluer les conteneurs : la supervision

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

La mise à l’échelle des conteneurs ne consiste pas simplement à placer un proxy devant un service et à s’en aller. Elle ne se limite pas à la répartition de la charge et, dans l’univers en constante évolution des conteneurs, cinq fonctionnalités distinctes sont indispensables pour assurer cette mise à l’échelle : les nouvelles tentatives, les disjoncteurs, la découverte, la répartition de la charge, et la supervision.

Dans cet article consacré à l’art de faire évoluer les conteneurs, nous allons nous pencher sur la supervision.

Surveillance

Surveillance. À une époque où tout semble écouter et/ou observer le moindre de nos faits et gestes, de notre vitesse au volant jusqu’au contenu de notre réfrigérateur, ce mot laisse un goût amer à beaucoup de gens. Nous pouvons — et c’est souvent le cas — employer plutôt le terme « visibilité », mais cette pirouette sémantique ne change rien à ce que nous faisons : nous surveillons, de près.

Tout ce qui touche à la mise à l’échelle repose sur la supervision, c’est-à-dire sur la connaissance de l’état des ressources entre lesquelles vous répartissez les requêtes. Envoyer une requête vers une « zone morte » parce que la ressource est tombée en panne ou a été récemment arrêtée revient à s’engager dans une impasse sans aucune issue. C’est une perte de temps.

La surveillance peut prendre de nombreuses formes. Il y a la surveillance « puis-je vous joindre ? » effectuée par un ping au niveau de la couche réseau. Il y a la surveillance « êtes-vous chez vous ? » d’une connexion TCP. Et il y a le « répondez-vous à la porte ? » d’une requête HTTP. Enfin, il y a la surveillance « avez-vous déjà pris votre café ? », qui détermine si le service répond correctement ou non.

Outre la simple vérification de l’état de santé et du bon fonctionnement d’un service, il convient également d’en surveiller les performances. La rapidité avec laquelle le service répond est cruciale si vous répartissez les requêtes en fonction des temps de réponse. Des variations soudaines des performances peuvent révéler des problèmes ; il s’agit donc de données historiques importantes qui doivent elles aussi être surveillées.

Il existe une surveillance active (laissez-moi vous envoyer une vraie requête !), une surveillance synthétique (laissez-moi vous envoyer une requête simulée) et une surveillance passive (je vais simplement rester là et observer ce qui arrive à une vraie requête). Chacune présente des avantages et des inconvénients, et toutes constituent des méthodes de surveillance valables. L’essentiel est que le proxy puisse déterminer l’état du service : est-il opérationnel ? est-il indisponible ? a-t-il quitté les lieux avec Elvis ?

L’accessibilité, la disponibilité et les performances sont autant d’aspects de la supervision nécessaires pour garantir l’évolutivité. Autrement dit, il ne s’agit pas seulement de superviser, mais aussi de s’assurer que les proxys d’équilibrage de charge disposent d’informations à jour sur l’état de chaque ressource vers laquelle ils sont susceptibles d’acheminer une requête.

Si l’on considère la nature des conteneurs et la tendance à les associer à une architecture basée sur des microservices, on comprend vite que la supervision peut rapidement virer au cauchemar. En effet, dans les environnements conteneurisés, le modèle d’équilibrage de charge le plus répandu repose sur des proxys directs (et des proxys side-car). Dans les deux cas, chaque nœud doit connaître l’état de santé et le bon fonctionnement de toutes les ressources auxquelles il pourrait être amené à envoyer une requête. Cela implique donc de superviser la quasi-totalité des ressources.

Vous imaginez bien qu’il n’est pas vraiment efficace pour une ressource donnée de mobiliser ses propres ressources limitées afin de communiquer son état à quinze ou vingt proxys directs. Dans un tel modèle, la surveillance a un impact négatif considérable sur les performances comme sur la capacité, ce qui complique encore davantage le passage à l’échelle.

Jamais encore la supervision n’avait eu un impact aussi important sur le passage à 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 qui mènent à une « impasse » si nous pouvons l’éviter.

Les difficultés liées à la supervision indispensable expliquent notamment pourquoi le maillage de services s’impose de plus en plus (et gagne du terrain) comme le futur modèle de mise à l’échelle dans les environnements de conteneurs.

Parce que la supervision n’est pas facultative, mais elle ne devrait pas non plus être une contrainte.

À propos de l’auteur

Lori Mac VittieIngénieur émérite et évangéliste en chef | F5

Lori MacVittie est ingénieure émérite et évangéliste en chef au sein du bureau du directeur technique de F5. Elle possède une expertise approfondie dans la fourniture d’applications, les stratégies d’automatisation et les infrastructures. Elle est réputée pour sa capacité à rendre la complexité intelligible, qu’elle définisse des garde-fous pour les agents d’IA, analyse des architectures multicloud fragiles ou explore les limites des systèmes évolutifs. Elle cumule plus de trente ans d’expérience dans le secteur, couvrant le développement d’applications, l’architecture informatique ainsi que l’exploitation des réseaux et des systèmes. Avant de rejoindre F5, elle a été rédactrice spécialisée dans les technologies et a reçu plusieurs distinctions. MacVittie est titulaire d’un master en informatique et est une autrice prolifique dont les publications couvrent la sécurité, le cloud et l’architecture d’entreprise. Elle est également une passionnée de jeux de société et de jeux vidéo, et assume pleinement ses avis bien tranchés sur le fromage.

Autres articles de Lori Mac Vittie