Как правильно и эффективно загрузить баланс в AWS - PullRequest
Новая
       10

Как правильно и эффективно загрузить баланс в AWS

0 голосов
/ 13 марта 2020

На данный момент у меня есть один экземпляр EC2 (2 ЦП, 8 ГБ ОЗУ, Linux), который имеет на нем:

  1. NodeJS Express Сервер (Backend)
  2. NodeJS "Микросервис" Express Сервер (взаимодействует с API и т. Д. c)
  3. PostgresQL DB
  4. Redis (как посредник сообщений между моим сервером (1) и мой Микросервисный сервер (2)
  5. ReactJS Приложение (интерфейс), которое обменивается данными с сервером (1)

Теперь это работает нормально с низким трафиком c, но как traffi c увеличивается (10 тыс. посещений в минутах / часах), все это перегружается, и процессор переходит в зону с устойчивой работой. Это также опасный подход, так как все мои функциональные возможности на одном экземпляре. Как быстрое решение я кластеризовал сервер (1), используя мой менеджер PM2, и теперь он работает немного лучше. Но как долгосрочное решение мне нужно разделить вещи и использовать балансировку нагрузки. Вот как я думал разделить его на разные экземпляры EC2:

  1. NodeJS Express Сервер (Backend) + NodeJS * 10 49 * Сервер (Backend) + балансировщик нагрузки между ними - каждый с 512 МБ ОЗУ, 1 ЦП
  2. NodeJS "Микросервис" Express Сервер - 512 МБ ОЗУ, 1 ЦП
  3. PostgresQL AWS RDS (1 ГБ ОЗУ, 1 ЦПУ)
  4. Redis AWS ElastiCache (cache.t2.micro)
  5. ReactJS Приложение (внешний интерфейс) - 512 МБ ОЗУ, 1 ЦП

Теперь у меня есть два вопроса:

  • Должен ли я балансировать нагрузку на свой бэкэнд (две реплики сервера) или мой веб-интерфейс (приложение ReactJS)? или может быть оба?
  • Должен ли я получить больше процессоров для бэкэнда (по 2 процессора каждый)? потому что теперь с этой новой архитектурой я не смог бы кластеризовать ее, как раньше. Что будет более эффективным? кластеризация сервера на 2 ЦП или баланс нагрузки между 2 серверами с 1 ЦП каждый?

1 Ответ

1 голос
/ 13 марта 2020
  1. вам нужно два экземпляра каждой из ваших служб, так что это 2x бэкэнд, 2x микросервис, 2x веб-интерфейс, предпочтительно работающий в разных зонах доступности.
  2. LB между каждой парой сервисов
  3. служба A вызывает LB для службы B, никогда не обслуживает напрямую B.

это означает, что у вас всегда есть хотя бы один работоспособный экземпляр каждой службы за балансировщиком нагрузки, а также при добавлении или удалении отдельной службы узлы DNS-записей и c остаются прежними - вы можете масштабировать микросервис до 3 узлов без необходимости что-либо менять где-либо еще.

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

...