Conséquences imprévues : Proxies sous charge

Le besoin d’évolutivité n’est même plus une question de nos jours. La réponse est toujours oui, vous en avez besoin. La croissance des entreprises dépend de la croissance opérationnelle des applications qui font, après tout, partie intégrante des modèles commerciaux actuels, quel que soit le secteur d’activité. Ainsi, les systèmes sont généralement déployés avec les éléments nécessaires pour atteindre cette échelle lorsque – et non si – elle sera nécessaire. Cela signifie généralement un proxy. Et les proxys responsables de l’évolutivité (généralement un équilibreur de charge) sont donc des composants assez critiques dans toute architecture moderne.

Ce n’est pas seulement que ces proxys servent de mécanisme de mise à l’échelle ; c’est qu’ils sont de plus en plus amenés à le faire de manière automatique grâce aux merveilles de la mise à l’échelle automatique. Ce mot simple et composé implique beaucoup de choses ; comme la capacité d'ordonner, par programmation, à un système non seulement de lancer une capacité supplémentaire, mais également de s'assurer que le proxy responsable de l'évolutivité connaît son existence et est en mesure de lui adresser des demandes.

On suppose que tout proxy digne de ce nom dispose des interfaces de programmation requises. L’économie des API ne se résume pas seulement au partage entre les applications et les utilisateurs. Après tout, il s’agit également d’un partage entre les systèmes, sur site et hors site, dans le cloud. Mais ce que nous ne parvenons souvent pas à reconnaître, c’est que la tâche d’ajout d’une nouvelle ressource à un proxy d’équilibrage de charge s’effectue sur le plan de gestion ou de contrôle, et non sur le plan de données.

Cela a du sens. Nous ne voulons pas interférer avec le fonctionnement du système pendant que nous collectons des statistiques ou manipulons sa configuration. C’est à ne pas faire, surtout dans une situation où nous essayons d’augmenter la capacité parce que le système fonctionne à plein régime, fournissant des applications à des utilisateurs impatients.

Mais que se passe-t-il lorsque l’inverse se produit ? Quand le fonctionnement du système interfère avec la capacité de gérer le système ?

Votre mise à l'échelle automatique (ou manuelle, d'ailleurs) va échouer. Ce qui signifie que la capacité des applications n’augmentera pas et que l’entreprise va en souffrir.

C'est mauvais, comme si tu avais besoin que je te le dise.

La raison pour laquelle cela se produit est que de nombreux proxys (qui n'ont pas été conçus avec ce paradoxe à l'esprit) partagent les ressources système pour les plans de contrôle et de données. Il n’y a aucun isolement entre eux. Le même réseau qui fournit les applications est utilisé pour gérer le proxy. La même RAM et les mêmes ressources de calcul affectées à la distribution des applications sont affectées à la gestion du proxy. Sous charge, un seul des deux obtient les ressources. Si vous essayez d’ajouter des ressources d’application au proxy afin de les faire évoluer et que vous ne pouvez pas accéder au système pour le faire, vous êtes dans une situation assez difficile.

C'est pourquoi il est important d'évaluer votre choix de proxys en tenant compte de la facilité de gestion. Pas seulement pour sa facilité de gestion. Non seulement ses capacités d'API et de script, mais aussi sa facilité de gestion sous charge . Les proxys spécialement conçus pour une échelle massive doivent disposer d'un ensemble distinct de ressources désignées comme ressources de « gestion » pour garantir que, quelle que soit la charge du plan de données avec la livraison d'applications, il peut toujours être géré et surveillé.

Dans le monde des réseaux, nous appelons cela la gestion hors bande, car elle se produit en dehors du chemin de données, le chemin principal ; le chemin critique.

La capacité à gérer un proxy sous charge, hors bande, est importante dans la capacité globale à faire évoluer – automatiquement ou manuellement – les applications et, à travers elles, l’entreprise.