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 présume qu’un proxy digne de ce nom offre les interfaces programmatiques nécessaires. L’économie des API ne se réduit pas au partage entre applications et utilisateurs ; elle concerne aussi le partage entre systèmes — sur site ou dans le cloud. Ce que l’on oublie souvent, c’est que l’ajout d’une nouvelle ressource à un proxy de répartition de charge se fait sur le plan de gestion ou de contrôle, pas sur le chemin des 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.

Cela se produit parce que de nombreux proxys (qui n'ont pas été conçus en tenant compte de ce paradoxe) partagent les ressources système entre les plans de contrôle et de données. Aucune isolation n’existe entre eux. Le même réseau qui transmet les applications sert à gérer le proxy. La RAM et la puissance de calcul affectées à la transmission des applications sont utilisées aussi pour gérer le proxy. Sous charge, une seule de ces deux fonctions reçoit les ressources. Si vous tentez d’ajouter des ressources applicatives au proxy pour le faire évoluer mais que vous ne pouvez pas accéder au système, vous êtes franchement en difficulté.

C’est pourquoi vous devez évaluer votre choix de proxys en vous concentrant sur leur capacité de gestion. Ne vous limitez pas à leur simplicité d’utilisation. Ne considérez pas seulement les possibilités d’API et de script, mais aussi la gestion en situation de charge. Les proxys conçus pour des déploiements à très grande échelle doivent disposer d’un ensemble dédié de ressources « de gestion » afin que, peu importe la charge du plan de données lié à la diffusion des applications, vous puissiez toujours les gérer et les surveiller.

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.