Служба AWS ECS, выполняющая SSH за сетевым балансировщиком нагрузки + целевая группа, медленно развертывается с CodeDeploy - PullRequest
Новая
       40

Служба AWS ECS, выполняющая SSH за сетевым балансировщиком нагрузки + целевая группа, медленно развертывается с CodeDeploy

0 голосов
/ 17 января 2019

У меня есть служба ECS, которая обслуживает процесс SSH. Я развертываю обновления для этого сервиса через CodeDeploy. Я заметил, что этот сервис гораздо медленнее развертывается, чем другие сервисы с одинаковыми образами, развернутыми одновременно с использованием CodePipeline. Разница с этим сервисом в том, что он находится за NLB (остальные не за LB или за ALB).

Служба настроена на 1 контейнер, развертывание 200% / 100%, поэтому службы выводят 1 новый контейнер, проверяют его работоспособность, а затем удаляют старый. То, что я вижу, происходит:

  1. Новый контейнер запущен в Initial состоянии
  2. 3 + минуты спустя, Новый Контейнер становится Healthy. Старый Контейнер входит Draining
  3. 2 + минуты спустя, Старый контейнер заканчивает Draining и останавливается

Таким образом, развертывание занимает 5-7 минут, в основном в ожидании проверки работоспособности или слива. Однако я почти уверен, что SSH запускается очень быстро, и у меня есть следующие настройки для целевой группы, которые должны сделать все относительно быстро:

  • Проверка работоспособности TCP на правильном порту
  • Порог здоров / нездоров: 2
  • Интервал: 10 с
  • Задержка отмены регистрации: 10 с
  • Задержка остановки ECS Docker: 65 с

Таким образом, минимальное время от завершения SSH до завершения работы старого контейнера будет:

  • 2 * 10 = 20 с для проверки работоспособности TCP, чтобы обратиться к здоровому
  • 10 с для задержки отмены регистрации до остановки Docker
  • 65 с для тайм-аута остановки Docker

Это 115 секунд, что намного меньше наблюдаемых 5-7 минут. Другие сервисы занимают 1-3 минуты, а время LB / Target Group там не так агрессивно.

Есть какие-нибудь идеи, почему мой сервис за NLB, кажется, медленно переключается между этими переходами жизненного цикла?

1 Ответ

0 голосов
/ 16 февраля 2019

Вы не делаете здесь ничего плохого; это просто кажется (текущим) ограничением этого продукта.

Недавно я заметил аналогичные задержки во времени регистрации / доступности со службами ECS за NLB и решил изучить. Я создал простой эхо-сервер TCP Javascript и настроил его в качестве службы ECS за NLB (счетчик служб ECS, равный 1). Как и вы, я использовал проверку работоспособности TCP с порогом работоспособности / нездоровья 2 и задержкой интервала / отмены регистрации 10 секунд.

После того, как начальное развертывание было успешным, и сервис, доступный через NLB, я хотел посмотреть, сколько времени потребуется для восстановления сервиса в случае полного сбоя базового экземпляра. Для симуляции я убил сервис через консоль ECS. После нескольких итераций этого теста я постоянно наблюдал временную шкалу, похожую на следующую (время указано в секундах): 

0s:   killed service
5s:   ECS reports old service draining
      Target Group shows service draining
      ECS reports new service instance is started
15s:  ECS reports new task is registered
      Target Group shows new instance with status of 'initial'
135s: TCP healthcheck traffic from the load balancer starts arriving 
      for the service (as measured by tcpdump on the EC2 host running 
      the container)
225s: Target Group finally marks the service as 'healthy'
      ECS reports service has reached a steady state

Я выполнил те же тесты с простым приложением Express за ALB, и разрыв между ECS, запускающим службу, и ALB, сообщившим, что она работоспособна, составлял 10-15 секунд. Наилучший результат, достигнутый нами при тестировании NLB, составил 3,5 минуты от остановки сервиса до полной доступности.

Я поделился этими результатами с AWS через службу поддержки, специально попросив уточнить, почему до начала проверки работоспособности службы NLB был постоянный промежуток в 120 секунд и почему мы последовательно видели 90-120 секунд между началом проверок работоспособности и доступностью службы. , Они подтвердили, что это поведение известно, но не предложили время для разрешения или стратегии по снижению задержки в доступности услуг.

К сожалению, это мало поможет решению вашей проблемы, но, по крайней мере, вы можете знать, что не делаете ничего плохого.

...