Com hem aconseguit desplegaments amb zero errors 502

Cada vegada que desplegàvem el backend de Mythex, unes quantes peticions fallaven amb 502 Bad Gateway. No gaires, però un 502 durant un desplegament vol dir que el clic d'algú no va fer res, o que una compilació que vigilava es va aturar un moment. Ho vam rastrejar fins a dos problemes separats: un watchdog d'autoreparació que lluitava contra els nostres desplegaments, i una bretxa entre el moment en què un servidor deixa d'escoltar i el moment en què l'equilibrador de càrrega deixa de enviar-li trànsit. Durant tres desplegaments de producció consecutius després de les correccions, el recompte va passar de 10 a 6 i després a 0.

La configuració

La nostra API i l'orquestrador s'executen com a contenidors en un petit grup de servidors darrere d'un Application Load Balancer (ALB) d'AWS. Un desplegament actualitza un servidor cada vegada: buida els contenidors antics, arrenca els nous i passa al següent. Un watchdog a cada servidor comprova que els contenidors estan en marxa i reinicia qualsevol que no ho estigui. Existeix perquè un procés que es caigui a les 3 de la nit torni sense que ningú s'hagi de despertar.

Les dues coses són raonables per separat. Junt, no ho eren.

Problema 1: el watchdog competia amb el desplegament

El watchdog s'executava un cop per minut i es «curava» en una sola comprovació de salut fallida. Un desplegament buida serveis deliberadament durant fins a 150 segons, i durant aquest temps una comprovació de salut hauria de fallar. Així que el watchdog s'activava en cada desplegament.

La majoria de les vegades perdia la competició sense conseqüències. Una vegada, la va guanyar: va reescriure el fitxer de compose (la descripció dels contenidors que han d'executar-se) enmig d'un desplegament, i va deixar un servidor sense cap contenidor de passarel·la, mentre la feina de desplegament informava d'èxit.

Les solucions:

• Un sol bloqueig. El desplegament ara pren el mateix bloqueig de fitxer que l'script d'arrencada del servidor, de manera que el watchdog i un desplegament no poden executar-se mai alhora.
• Quatre avisos, no un. El watchdog necessita quatre comprovacions fallides seguides abans d'actuar. Un servei en buidatge ja no sembla mort.
• Una sola definició. El fitxer de compose ara té exactament una font, publicada als servidors, en lloc de còpies que podien desviar-se.
• Verifica, no confiïs. La feina de desplegament ja no passa només perquè una ordre ha retornat. Comprova l'API, l'orquestrador, la passarel·la i el worker de publicació de cada servidor abans de poder reeixir.

Problema 2: el servidor marxava abans que el trànsit

El segon problema era més discret. Quan un desplegament buida un servidor, el servidor comença a respondre al seu endpoint de salut amb 503 perquè l'equilibrador el tregui de la rotació. El nostre ho feia durant 5 segons, i després es tancava.

Però l'ALB només comprovava la salut de tant en tant, i necessitava diverses comprovacions fallides seguides abans de deixar d'enviar-li trànsit a un destí: fins a uns 60 segons de punta a punta. Així que durant uns 55 segons, l'equilibrador continuava enviant peticions reals a un servidor que ja havia deixat d'escoltar. Aquests eren els nostres 502.

La solució va ser fer que les dues línies de temps coincidissin:

• El grup de destins ara comprova cada 5 segons i marca un destí com a no saludable després de 2 fallades: uns 10 segons per adonar-se'n.
• El buidatge continua servint trànsit real durant 15 segons després que comencin a fallar les comprovacions de salut, de manera que sempre hi ha solapament.
• Aquests paràmetres viuen a l'script que aprovisiona la infraestructura, no en una consola que algú va clicar un cop.

Fer que els números es mantinguin entre ells

Els temps d'espera com aquests depenen els uns dels altres. El buidatge ha de durar més que el temps que l'equilibrador necessita per adonar-se'n; el buidatge més el tancament han d'acabar abans que el contenidor sigui aturat per la força. És fàcil que algú canviï un número al cap de sis mesos i reintrodueixi el problema sense adonar-se'n.

Així que hem escrit aquestes relacions com a proves: el buidatge ha de ser més llarg que l'interval de comprovació de salut multiplicat pel llindar de fallades; el temps per tornar a ser marcat com a saludable ha de romandre curt; tot el buidatge ha de cabre dins del període de gràcia d'aturada del contenidor. Si canvies un número sense els altres, el CI falla. Hem fet proves de mutació de les mateixes proves: hem canviat cada número a un valor incorrecte i hem comprovat que una prova ho detectava.

Mesurar un desplegament és fàcil d'equivocar

La nostra primera mesura deia que un desplegament net estava trencat un 3 %. No ho estava. Comptàvem cada resposta que no fos 200, i un 503 d'un endpoint de salut durant un buidatge no és un fracàs: és el buidatge fent la seva feina, dient a l'equilibrador que no triï aquell servidor mentre continua servint peticions reals.

El que nota l'usuari és un 502: la petició no va arribar a res. Comptar només aquests va donar la imatge real: 10, després 6, després 0 en tres desplegaments de producció.

Què ens hem endut

• L'autoreparació ha de saber del temps d'aturada planificat. Un watchdog que no distingeix un desplegament d'un fracàs acabarà lluitant contra el desplegament.
• El buidatge és un encaix de mans. El servidor ha de continuar servint fins que l'equilibrador ha deixat demostrablement d'enviar-li trànsit, i aquesta temporització es defineix a l'equilibrador, no al servidor.
• Codifica els invariants com a proves. Els números operatius es desvien. Les proves que els relacionen entre ells no.
• Decideix què estàs mesurant abans de mesurar-ho. «Errors» era la mètrica equivocada; «peticions que no van arribar a res» era la correcta.

Si publiques una app a Mythex, res d'això no és visible per a tu, que és precisament el punt. Relacionat: com la teva app publicada segueix en línia mentre la tornes a publicar.