L'art de mettre à l'échelle les conteneurs : Réessais

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 les nouvelles tentatives.

Réessais

Lorsque vous êtes un enfant jouant à un jeu, le concept de nouvelle tentative est commun à de nombreux jeux. « Recommence ! » est une expression courante qui est lancée après un échec, dans l’espoir que les autres joueurs vous laisseront réessayer. Parfois, ils le font. Parfois non. J’ai remarqué que cela empêche rarement un enfant d’essayer. 

Lors de la mise à l’échelle d’applications (ou de services si vous préférez), le concept de nouvelle tentative est à peu près le même. Un proxy, lors du choix d'un service et de la tentative de réponse à une demande, reçoit une erreur. Dans les scénarios d’équilibrage de charge de base, cela est généralement déterminé en examinant le code de réponse HTTP. Tout ce qui n’est pas « 200 OK » est une erreur. Cela inclut les délais d’expiration de la couche réseau et TCP. L'équilibreur de charge peut renvoyer aveuglément la réponse ayant échoué à l' 

demandeur ou, s’il est suffisamment intelligent, il peut réessayer la demande dans l’espoir qu’une demande ultérieure aboutira à une réponse positive.

Cela semble assez basique, mais au début de Scale, il n’existait pas de nouvelle tentative. Si cela a échoué, c’était un échec et nous nous en sommes occupés. Habituellement en essayant de recharger manuellement à partir du navigateur. Finalement, les proxys sont devenus suffisamment intelligents pour effectuer eux-mêmes de nouvelles tentatives, évitant ainsi à de nombreux claviers d'user les boutons « CTRL » et « R ».

En apparence, il s’agit d’un exemple existentiel de la définition de la folie. Après tout, si la requête a échoué la première fois, pourquoi devrions-nous nous attendre à ce qu’elle réussisse la deuxième fois (ou même 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'impact de la capacité de connexion sur les échecs. La charge sur une ressource donnée à un moment 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 – a des contraintes définies en termes de capacité. Il ne peut maintenir qu'un nombre X de connexions simultanées. Lorsque cette limite est atteinte, les tentatives d’ouverture de nouvelles connexions seront bloquées ou échoueront.

Si c'est la cause d'un échec, alors dans les microsecondes nécessaires au proxy pour recevoir une réponse d'échec, une autre connexion peut s'être fermée, ouvrant ainsi la possibilité d'une nouvelle tentative réussie.

Dans certains cas, une défaillance est interne à la plateforme. La redoutable « erreur interne du serveur 500 ». Ce statut est souvent observé lorsque le serveur n'est pas surchargé, mais a effectué un appel à un autre service (externe) qui n'a pas répondu à temps. Parfois, cela est dû au fait qu'un pool de connexions à une base de données atteint ses limites. Le recours à des services externes peut entraîner une chaîne d’erreurs en cascade qui, comme une surcharge de connexion, est souvent résolue au moment où vous recevez l’erreur initiale.

Vous pourriez également voir l’erreur très utile « 503 Service Unavailable ». Cela peut être une réponse à une surcharge, mais comme c'est le cas avec tous les codes d'erreur HTTP, ils ne sont pas toujours de bons prédicteurs de ce qui ne va pas réellement. Vous pouvez voir cela en réponse à une défaillance DNS ou dans le cas d'IIS et d'ASP, une file d'attente pleine. Les possibilités sont vraiment très variées. Et encore une fois, ils pourraient être résolus au moment où vous recevez l'erreur, donc une nouvelle tentative devrait définitivement être votre première réponse.

Bien sûr, vous ne pouvez pas simplement réessayer jusqu’à ce que les vaches rentrent à la maison. Tout comme les conséquences imprévues de la retransmission TCP (qui peuvent surcharger les réseaux et submerger les récepteurs), les nouvelles tentatives finissent par devenir vaines. Il n'y a pas de règle absolue concernant le nombre de fois que vous devez réessayer avant d'abandonner, mais entre 3 et 5 est courant.

À ce stade, il est temps d’envoyer des regrets au demandeur et d’enclencher un disjoncteur. Nous approfondirons cette capacité dans notre prochain article.