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

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 tenir là. Elle ne se limite pas à la répartition, et dans l’univers en constante évolution des conteneurs, cinq fonctionnalités distinctes sont indispensables pour assurer la mise à l’échelle : les nouvelles tentatives, les disjoncteurs, la découverte, la répartition et la surveillance.

Dans cet article consacré à l’art de la mise à l’échelle des conteneurs, nous allons nous pencher sur la répartition de charge.

Distribution

Le secret pour faire évoluer n’importe quel système a toujours reposé, en partie, sur la manière dont les requêtes sont réparties entre un ensemble fini de ressources. Même le cloud et sa capacité de calcul apparemment infinie ne changent rien à cette recette. Au moment où une requête est reçue, la liste des ressources susceptibles de l’accepter et de la traiter est nécessairement finie. Point final.

La décision concernant la ressource vers laquelle diriger une requête revêt donc une importance considérable. Si elle est envoyée à la mauvaise ressource, les performances risquent d’en pâtir. Si elle est envoyée à la bonne, le consommateur ou l’employé sera ravi du résultat.

Aux débuts de la mise à l’échelle, ces décisions reposaient uniquement sur des algorithmes : tourniquet, nombre minimal de connexions, temps de réponse le plus rapide. Ces mécanismes éprouvés existent toujours aujourd’hui, mais ils sont peu à peu devenus un simple facteur parmi d’autres dans le processus décisionnel, plutôt que le seul facteur pris en compte.

Cela s’explique par le fait que nous ne nous appuyons plus uniquement sur des processus décisionnels fondés sur les connexions (autrement dit, le « bon vieux équilibrage de charge »). Lorsque l’équilibrage de charge consistait principalement à gérer les connexions TCP, les méthodes de répartition basées sur les connexions étaient pertinentes. Mais désormais, le passage à l’échelle repose autant sur l’architecture que sur les algorithmes, et la répartition des requêtes peut nécessiter un calcul complexe faisant intervenir de nombreuses variables situées au-dessus — littéralement — de la couche 4 et allant au-delà de ses protocoles.

La distribution est d’autant plus complexe que les architectures actuelles sont elles-mêmes de plus en plus distribuées, non seulement entre différents clouds, mais aussi entre différents conteneurs. Plusieurs versions d’une même application (ou API) peuvent être en service simultanément. Le système chargé de distribuer la requête doit en avoir connaissance, être capable de les distinguer et garantir son acheminement vers le bon point de terminaison.

Aujourd’hui, les décisions ne reposent plus uniquement sur la capacité de connexion, mais de plus en plus sur des paramètres de couche 7 (HTTP) : noms d’hôte, méthodes d’API (autrement dit, l’URI), clés d’API, en-têtes HTTP personnalisés intégrant des numéros de version, localisation, appareil et utilisateur. Les requêtes sont évaluées dans leur contexte, et les décisions sont prises en quelques microsecondes.

Aujourd’hui, la distribution nécessite une approche architecturale à plusieurs niveaux. Plus on s’enfonce dans l’architecture de l’application, moins le niveau de granularité est élevé. Lorsqu’un proxy doit prendre une décision de répartition de charge entre X instances identiques d’un même microservice, il peut très bien ne s’appuyer que sur des équations traditionnelles fondées sur des algorithmes. En revanche, aux frontières extérieures de l’environnement, les contrôleurs d’entrée prennent parfois des décisions complexes en fonction de variables de la couche HTTP.

À l’extérieur, la distribution est régie par l’architecture. À l’intérieur, par les algorithmes.

Ces deux éléments sont des composants essentiels – peut-être même les plus essentiels – pour faire évoluer les conteneurs à grande échelle.

Tous deux s’appuient sur des informations précises et en temps réel concernant l’état de santé des ressources auxquelles ils sont susceptibles de distribuer les requêtes. Nous aborderons la supervision dans les prochains articles de cette série.

À 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