Назад | Перейти на главную страницу

Высокая задержка ELB с использованием NAT и общедоступных / частных подсетей

Я начал с конфигурации VPC по умолчанию для нашего приложения, но в последнее время она стала немного сложнее. Итак, в основном мы используем кластер ECS с 1 экземпляром EC2. 1 ELB, связанный с сервисом ECS.

Недавно нам пришлось реализовать SQS с Lambda и столкнуться с тем фактом, что нам пришлось использовать NAT, чтобы лямбда-функция могла получить доступ к очереди SQS. Поскольку мы добавили этот NAT, все пошло не так.

Итак, с точки зрения конфигурации сети, это в значительной степени вариант по умолчанию:

- 1 VPC (172.31.0.0/16)
- 2 Public subnets: 
  - pubsub1 - CIDR: 172.31.48.0/20
  - pubsub2 - CIDR: 172.31.0.0/20
- 2 Private subnets:
  - privsub1 - CIDR: 172.31.16.0/20
  - privsub2 - CIDR: 172.31.32.0/20

- 1 Main route table (not explicitelly assign to any subnets):
  - 172.31.0.0/16 -> local
  - 0.0.0.0/0 -> igw
- 1 Public route table (pubsub1 and pubsub2):
  - 172.31.0.0/16 -> local
  - 0.0.0.0/0 -> igw
- 1 Private route table (privsub1 and privsub2):
  - 172.31.0.0/16 -> local
  - 0.0.0.0/0 -> NAT

ELB сообщает о сбое проверки работоспособности и удаляет мой экземпляр EC2 из пула. однако, если я использую ssh для блока EC2 (используя промежуточный сервер ec2 в общедоступной подсети) и пытаюсь скрутить localhost: 80 / healthcheck.html (который является конфигурацией проверки работоспособности ELB), он отвечает корректно.

Проверяю и группы безопасности:

- 1 security group for the ELB allowing HTTP and HTTPS to ALL inbound source and allowing ALL outbound traffic
- 1 security group for the EC2 server allowing HTTP inbound from the elb-security-group (I also tried from all source)
- 1 security group for the RDS allowing TCP connection on database from ec2-security-group

Если я добавлю ELB к 2 частным подсетям, то проверка работоспособности работает. Однако при выполнении запроса curl я вижу высокую задержку:

HTTPCode=200 TotalTime=1.401
HTTPCode=200 TotalTime=1.660
HTTPCode=200 TotalTime=1.537
HTTPCode=200 TotalTime=1.529
HTTPCode=200 TotalTime=1.519

На данный момент я немного растерялся и не знаю, что делать. Я почти уверен, что это проблема сети, но я не могу ее изолировать.

Вот один из сроков запроса Chrome:

и последующий точно такой же запрос:

Я также написал на форуме AWS: https://forums.aws.amazon.com/thread.jspa?threadID=236569


ОБНОВЛЕНИЕ1

Я включил межзонную балансировку нагрузки на моем ELB, чтобы исправить проблему с проверкой работоспособности (ELB находится в общедоступных подсетях, а EC2 - в частных).
Сетевые ACL являются стандартными и разрешают все.

  1. Задержка ELB остается прежней (от 1 до 2 секунд)

    • Перемещение EC2 в общедоступную подсеть и прямое нажатие на поле сокращает время отклика до 400 мс.
  2. Экземпляр RDS, находящийся в общедоступных и частных подсетях, недоступен из нашего офиса (из внешнего мира), поскольку мы добавили NAT.


ОБНОВЛЕНИЕ2

Я исправил проблему с недоступностью RDS из нашего офиса. Я думаю, что тот факт, что мы включили NAT и что RDS использовала 4 подсети (2 общедоступные и 2 частные), вызвал проблему.
RDS должен был использовать ТОЛЬКО общедоступные подсети.. Однако изменения группы подсети для RDS недостаточно. Несмотря на то, что сведения о RDS показывают, что подсеть изменилась, они не учитываются.

Из AWS FAQ:

В: Могу ли я изменить группу подсети БД моего инстанса БД?

[...] В настоящее время обновление существующей группы подсетей БД не изменяет текущую подсеть развернутого экземпляра БД; требуется операция масштабирования типа экземпляра. Явное изменение группы подсети БД развернутого экземпляра БД в настоящее время запрещено.

Таким образом, единственный способ - изменить размер экземпляра RDS или развернуть новый экземпляр из моментального снимка базы данных, указав новую группу подсети (которая ТОЛЬКО использует общедоступные подсети). Убедитесь, что группа безопасности также правильная, потому что по умолчанию она выбирает группу по умолчанию.

Я все еще изучаю задержку ELB ...