ECS repornește din cauza eșecului health_check atunci când mai multe alte solicitări revin lent

Am observat că serviciile noastre de backend ECS Fargate repornesc din cauza unui timeout de răspuns la verificarea stării de sănătate:

(serviciul our-site-com-stack-BackendApiServiceStack...) (portul 8000) este nesănătos în (grupul țintă arn:aws:elasticloadbalancing:us-east-1:1234:targetgroup/dev-d-ABC-ABC123/ ABC123) din cauza (motivul Solicitarea a expirat).

Încercăm să ne dăm seama cum să efectuăm o verificare a stării de sănătate a aplicației noastre pentru ECS, care nu va reporni inutil serviciile noastre ori de câte ori baza de date este ocupată (sau alte solicitări lente sunt în așteptare).

Inițial, am simțit că situația poate fi similară cu cea descrisă aici: https://cloudsoft.io/blog/consequences-of-bad-health-checks-in-aws-application-load-balancer. Practic, dacă baza noastră de date a fost ocupată/lentă, atunci cererea ar putea expira.

Cu toate acestea, am modificat health_check pentru a nu atinge baza noastră de date RDS postgres și chiar am încercat să ne închidem baza de date.Putem ajunge la punctul final chiar și cu baza de date oprită, dar nu mai putem ajunge la el atunci când declanșăm doar 7 solicitări care vor expira (cum ar fi cererile de autentificare cu baza de date oprită) sau un număr similar de solicitări care vor fi lent a reveni (cu baza de date sus).

În stiva noastră de aplicații AWS, Route 53 este utilizat pentru a direcționa traficul către distribuția noastră CloudFront. CloudFront direcționează traficul pentru acest punct final către aplicația noastră de echilibrare a sarcinii pentru aplicația Django.

Verificarea noastră de sănătate face parte din aplicația noastră Django și, practic, returnează doar un răspuns de 200:

def health_check(cerere):
    răspuns = JsonResponse({"mesaj": "OK"})
    returnează răspunsul

Iată cum este configurat verificarea noastră de sănătate în CDK:

        self.https_listener = self.alb.add_listener(
            „HTTPSListener”,
            port=443,
            certificates=[domeniu.certificat],
            deschis=Adevărat,
        )

        scope.https_listener.add_targets(
            „BackendTarget”,
            port=80,
            targets=[self.backend_service],
            prioritate=2,
            path_patterns="*"],
            health_check=elbv2.HealthCheck(
                healthy_http_codes="200-299",
                path="/api/core/health-check/",
            ),
        )

Comanda care pornește serverul nostru de producție este:

GEVENT_RESOLVER=ares gunicorn -t 1000 -k gevent -w 4 -b 0.0.0.0:8000 backend.wsgi

În timpul unui test fără legătură, am reușit să reproducem aceeași problemă folosind Daphne:

daphne -b 0.0.0.0 -p 8000 backend.asgi:application

În timp ce cererea nu ajungea în baza de date, rămânea blocată în spatele solicitărilor care erau (sau nu se întorceau din alte motive). Am înțeles greșit cât de ușor s-ar putea bloca bucla de evenimente gunicorn (sau alt server) și va fi reproiectată pentru a folosi mai bine gevents și un backend de rezultate de țelină.