L'art de mettre à l'échelle les conteneurs : Distribution
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 distribution.
Distribution
Le secret de la mise à l’échelle de quoi que ce soit a toujours reposé, en partie, sur la manière dont les demandes sont réparties sur un ensemble fini de ressources. Même le cloud et sa réserve de puissance de calcul apparemment infinie ne changent pas cette recette. Au moment où une demande est reçue, la liste possible des ressources qui peuvent accepter cette demande et la traiter est limitée. Période.
La décision de savoir vers qui adresser une demande devient alors assez importante. Envoyez-le à la mauvaise ressource et les performances pourraient en souffrir. Envoyez-le à la bonne ressource et le consommateur/employé sera ravi du résultat.
Aux débuts de la gestion d’échelle, ces décisions étaient uniquement basées sur des algorithmes. Tournoi à la ronde. Le moins de connexions. Réponse la plus rapide. Ces mécanismes solides existent encore aujourd’hui, mais sont lentement mais sûrement devenus un facteur supplémentaire dans le processus de prise de décision plutôt que le seul facteur.
C’est parce que nous ne nous appuyons plus uniquement sur des processus de prise de décision basés sur la connexion (également appelés « bon vieux équilibrage de charge »). Lorsque l’équilibrage de charge consistait principalement à gérer les connexions TCP, les schémas de distribution basés sur les connexions étaient logiques. Mais l’échelle repose désormais autant sur l’architecture que sur les algorithmes, et la distribution des requêtes peut être un calcul complexe impliquant de nombreuses variables au-dessus (littéralement) et au-delà des protocoles de couche 4.
La distribution est compliquée par le fait que les architectures d'aujourd'hui sont elles-mêmes de plus en plus distribuées. Pas seulement à travers les clouds, mais aussi à travers les conteneurs. Plusieurs versions de la même application (ou API) peuvent être en service en même temps. Le système chargé de distribuer la demande doit être conscient et capable de les distinguer et d'assurer la livraison au bon point de terminaison.
Aujourd’hui, les décisions sont prises non seulement en fonction de la capacité de connexion, mais de plus en plus en fonction des paramètres de la couche 7 (HTTP). Noms d'hôtes. Méthodes API (alias l'URI). Clés API. En-têtes HTTP personnalisés avec numéros de version intégrés. Emplacement. Appareil. Utilisateur. Les demandes sont évaluées dans le contexte dans lequel elles sont formulées et les décisions sont prises en quelques microsecondes.
La distribution nécessite aujourd’hui une approche architecturale à plusieurs niveaux. Plus vous approfondissez l'architecture de l'application, moins vous obtenez de détails. Au moment où un proxy prend une décision d’équilibrage de charge entre X clones du même microservice, il se peut très bien qu’il n’utilise rien de plus que des équations algorithmiques traditionnelles. Pendant ce temps, aux limites extérieures de l’environnement, les contrôleurs d’entrée prennent des décisions parfois complexes basées sur des variables de la couche HTTP.
À l’extérieur, la distribution est portée par l’architecture . À l'intérieur, par des algorithmes .
Ces deux éléments sont essentiels – les plus essentiels peut-être – à la mise à l’échelle des conteneurs.
Les deux s’appuient sur des informations précises et en temps réel sur l’état (la santé) des ressources auxquelles ils peuvent distribuer des demandes. Nous aborderons la surveillance dans les prochains articles de cette série.