AWS ECS Fargate: балансировщик нагрузки приложения возвращает 503 со странным паттерном

Question

(ПРИМЕЧАНИЕ: я изменил свой исходный пост, поскольку теперь я собрал немного больше данных.)

Что-то только что начало происходить сегодня после нескольких недель без проблем, и я ничего не могу придуматьЯ изменил, что вызвало бы это.

У меня есть приложение Spring Boot, работающее за прокси-сервером NGINX (все Dockerized), которое находится в кластере AWS ECS Fargate.

После развертыванияЯ заметил, что - случайно (как, иногда, этого не происходит) - вызов служб, обслуживаемых Spring Boot, будет 503 (за прокси-сервером NGINX). Похоже, что это происходит при каждом втором развертывании, с последующим развертыванием, решающим проблему, то есть вызовы на сервер будут выполняться некоторое время (возможно, несколько секунд; возможно, несколько минут), но затем останавливаются.

IЯ посмотрел на «HealthyHostCount» и заметил, что когда я получаю 503, и моя основная целевая группа говорит, что ни в одном из них нет зарегистрированных / здоровых хостов. Я не уверен, что заставило бы TG отменить регистрацию цели, тем более что последующее развертывание, похоже, «решило» эту проблему.

Любое понимание / помощь будет высоко оценено.

Спасибозаранее.

ОБНОВЛЕНИЕ Похоже, что это происходит сразу после того, как я "завершаю исходный набор задач" из развертывания Blue / Green из CodeDeploy. Мне интересно, если это проблема с AZ, то есть я не указал достаточно задач для их выполнения.

Answer 1

Оказывается, это была проблема с тем, как я настроил одну из моих целевых групп и / или ALB, хотя какова была точная проблема, я не мог определить, когда я заново создал TG и сервис изscratch.

Если бы мне пришлось угадывать, я бы предположил, что мой TG не был настроен с правильным портом, или у ALB было плохое правило / слушатель.

Answer 2

Я думаю, вероятно, что ваши службы не проходят проверку работоспособности в TargetGroup.

Когда TargetGroup определяет, что существующая цель неработоспособна, она отменяет ее регистрацию, в результате чего ECS запускает задачу длязамени это. Тем временем вы, как правило, будете видеть ошибки шлюза, подобные этой.

На странице ECS выберите вашу службу, затем перейдите на вкладку События ... если я прав, здесь вы увидите сообщения о причинахзадача была остановлена ​​как «нездоровый» или «тайм-аут проверки работоспособности».

Причиной может быть множество причин. Перегруженный кластер (вероятно, не в случае с Fargate), нехватка ресурсов, неудержимый запрос, который съедает всю память или ЦП.

В вашем случае пахнет как проблема медленного запуска. Веб-сервисы ECS имеют «льготный период проверки работоспособности» ... то есть время ожидания до начала проверок работоспособности. Если ваш контейнер занимает слишком много времени, чтобы начать работу при первом запуске, первая пара проверок работоспособности может завершиться неудачно и привести к циклу выполнения задач. Новое развертывание может быть медленнее, если ваши образы особенно велики, потому что хост ECS должен загрузить образ. Fargate, в целом, немного медленнее, чем хосты EC2, из-за накладных расходов на настройку сети. Если медленный запуск является вашей проблемой, вы можете попытаться увеличить этот льготный период, но вам также следует выяснить, как ускорить время запуска вашего контейнера (уменьшить размер изображения, другие настройки nginx для ускорения инициализации и т. Д.).