L’art de faire évoluer les conteneurs : les nouvelles tentatives

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 à passer à autre chose. 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 nécessaires pour garantir la mise à l’échelle : les nouvelles tentatives, les disjoncteurs, la découverte, la répartition, et la supervision.

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

Nouvelles tentatives

Quand on est enfant et qu’on joue, le concept de nouvelle tentative est courant dans de nombreux jeux. Après un échec, on lance souvent « On recommence ! », dans l’espoir que les autres joueurs nous laisseront réessayer. Parfois, ils acceptent. Parfois, non. Mais j’ai remarqué que cela empêche rarement un enfant de retenter sa chance.

Lorsqu’on met à l’échelle des applications (ou des services, si vous préférez), le principe d’une nouvelle tentative est sensiblement le même. Après avoir choisi un service et tenté de traiter une requête, un proxy reçoit une erreur. Dans les scénarios d’équilibrage de charge simples, celle-ci est généralement détectée en examinant le code de réponse HTTP. Toute réponse autre que « 200 OK » est considérée comme une erreur. Cela inclut les délais d’expiration au niveau du réseau et de la couche TCP. L’équilibreur de charge peut soit renvoyer aveuglément la réponse ayant échoué au

demandeur ou, s’il est suffisamment intelligent, il peut réessayer la requête dans l’espoir qu’une tentative ultérieure aboutisse à une réponse positive.

Cela semble assez élémentaire, mais aux débuts du passage à l’échelle, les nouvelles tentatives n’existaient pas. En cas d’échec, c’était un échec et nous faisions avec. Généralement, en essayant manuellement de recharger la page depuis le navigateur. Les proxys ont fini par devenir suffisamment intelligents pour effectuer eux-mêmes de nouvelles tentatives, évitant ainsi à bien des claviers d’user leurs touches « CTRL » et « R ».

À première vue, c’est l’illustration parfaite de cette définition de la folie. Après tout, si la requête a échoué la première fois, pourquoi s’attendre à ce qu’elle aboutisse à la deuxième tentative (voire à la troisième) ?

La réponse réside dans la raison de l’échec. Lors de la mise à l’échelle des applications, il est important de comprendre l’incidence de la capacité de connexion sur les échecs. La charge d’une ressource donnée à un instant donné n’est pas fixe. Des connexions sont constamment ouvertes et fermées. La plateforme d’application web sous-jacente – qu’il s’agisse d’Apache ou d’IIS, d’un moteur node.js ou d’une autre pile technologique – est soumise à des contraintes de capacité bien définies. Elle ne peut maintenir qu’un nombre X de connexions simultanées. Lorsque cette limite est atteinte, les tentatives d’ouverture de nouvelles connexions restent en attente ou échouent.

Si telle est la cause d’un échec, il est possible que, pendant les quelques microsecondes nécessaires au proxy pour recevoir une réponse indiquant cet échec, une autre connexion se soit fermée, permettant ainsi à une nouvelle tentative d’aboutir.

Dans certains cas, la défaillance est interne à la plateforme. La redoutable erreur « 500 Internal Server Error ». Ce statut apparaît souvent lorsque le serveur n’est pas surchargé, mais qu’il a fait appel à un autre service (externe) qui n’a pas répondu à temps. Cela se produit parfois lorsqu’un pool de connexions à une base de données atteint ses limites. La dépendance à des services externes peut entraîner une cascade d’erreurs qui, comme une surcharge de connexions, est souvent résolue au moment où vous recevez l’erreur initiale.

Vous pourriez également rencontrer la très peu utile erreur « 503 Service Unavailable ». Celle-ci peut être due à une surcharge, mais comme pour tous les codes d’erreur HTTP, elle ne permet pas toujours de déterminer précisément l’origine réelle du problème. Elle peut notamment survenir à la suite d’une défaillance DNS ou, dans le cas d’IIS et d’ASP, lorsque la file d’attente est pleine. Les causes possibles sont en réalité très diverses. Là encore, le problème peut être résolu avant même que vous ne receviez l’erreur ; votre premier réflexe doit donc impérativement être de réessayer.

Bien sûr, vous ne pouvez pas réessayer indéfiniment. À l’instar des conséquences imprévues de la retransmission TCP — qui peut surcharger les réseaux et submerger les destinataires —, les nouvelles tentatives finissent par devenir inutiles. Il n’existe pas de règle absolue quant au nombre de tentatives à effectuer avant d’abandonner, mais il est courant d’en faire entre 3 et 5.

À ce stade, il est temps d’informer le demandeur que sa requête ne peut pas être satisfaite et d’activer un disjoncteur. Nous approfondirons ce mécanisme dans notre prochain article.

À 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