ECS перезапускается из-за сбоя проверки работоспособности, когда несколько других запросов возвращаются медленно.

Мы заметили, что наши серверные службы ECS Fargate перезапускаются из-за истечения времени ожидания ответа проверки работоспособности:

(service our-site-com-stack-BackendApiServiceStack...) (порт 8000) неисправен в (target-group arn:aws:elasticloadbalancing:us-east-1:1234:targetgroup/dev-d-ABC-ABC123/ ABC123) по причине (время ожидания запроса истекло).

Мы пытаемся выяснить, как выполнить проверку работоспособности нашего приложения для ECS, которая не будет без необходимости перезапускать наши службы всякий раз, когда база данных становится занятой (или ожидаются другие медленные запросы).

Мы изначально чувствовали, что ситуация может быть похожа на ту, что описана здесь: https://cloudsoft.io/blog/consequences-of-bad-health-checks-in-aws-application-load-balancer. По сути, если наша база данных была занята/медленна, то запрос мог истечь.

Однако мы изменили проверку работоспособности, чтобы она не затрагивала нашу базу данных RDS postgres, и даже попытались отключить нашу базу данных.Мы можем достичь конечной точки даже с отключенной базой данных, но мы больше не можем достичь ее, когда мы инициируем всего 7 запросов, время ожидания которых истекает (например, запросы на вход в систему с отключенной базой данных) или аналогичное количество запросов, которые будут медленными. для возврата (с базой данных).

В нашем стеке приложений AWS Route 53 используется для маршрутизации трафика в наш дистрибутив CloudFront. CloudFront направляет трафик для этой конечной точки в наш Application Load Balancer для приложения Django.

Наша проверка работоспособности является частью нашего приложения Django и просто возвращает ответ 200:

def health_check (запрос):
    ответ = JsonResponse({"сообщение": "ОК"})
    вернуть ответ

Вот как наша проверка работоспособности настроена в CDK:

        self.https_listener = self.alb.add_listener(
            "HTTPSListener",
            порт=443,
            сертификаты = [scope.certificate],
            открыть = Верно,
        )

        scope.https_listener.add_targets(
            "БэкэндТаржет",
            порт=80,
            цели = [self.backend_service],
            приоритет=2,
            path_patterns=["*"],
            health_check=elbv2.HealthCheck(
                здоровый_http_codes="200-299",
                path="/api/ядро/проверка работоспособности/",
            ),
        )

Команда, которая запускает наш рабочий сервер:

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

Во время несвязанного теста мы смогли воспроизвести ту же проблему с помощью Daphne:

дафна -b 0.0.0.0 -p 8000 backend.asgi:приложение

Хотя запрос не попал в базу данных, он застрял за блокировкой запросов, которые были (или не возвращались по другим причинам). Мы неправильно поняли, насколько легко может быть заблокирован цикл событий пушки (или другого сервера), и мы будем переделывать, чтобы лучше использовать gevents и бэкэнд результатов celery.