Сколько балансировщиков лучше использовать на проекте?

Question

[horn313]

Есть небольшой сайт на WP, лежит на AWS (хотя думаю вопрос более общий - и может быть применим к другим облачным провайдерам)
Имеется две среды - разработка и прод. Разработка ведется крайне редко, порой тестовый сервак вообще выключается.
В настоящий момент на проекте два отдельных балансировщика - один перенаправляет трафик на тестовый сервер, второй соответственно на прод. По факту балансировщик просто выполняет роль перенаправления - за балансировщиком стоит по 1 серверу - балансировать там некуда.
Лично я не вижу смысла использовать 2 различных балансировщика, хотя коллега уверяет что "Это более безопасный архитектурный шаблон, чем использование общего ALB как для работы, так и для тестирования."
Хотелось бы услышать еще какое-либо мнение по этому вопросу, т.к. я не понимаю в чем здесь безопасность - больше вижу бесполезное "накручивание" на проекте и бесполезный платеж за 2 балансировщик.

Answer 1

[Вадим]

Зафигачьте всю development инфраструктуру в терраформ и поднимайте только тогда, когда есть необходимость, затем все удаляйте (останавливайте EC2, отключите/не используйте в autoscaling in dev) Создайте для это отдельный aws account и/или дочернюю aws организацию - так будет правильно! Dev и Prod должны быть разные аккаунты - best practices!

Answer 2

[Евгений]

Я поддержу Вадим : опишите эту инфраструктуру как код и поднимайте тестовый стенд только тогда, когда вам надо
В идеале, да - лучше создать второй аккаунт AWS( и связать их в организацию для централизованного управления), чтобы изменениями инфраструктуры теста случайно не задеть прод.
Подход разделения, как описывает ваш коллега, правильный(пункты дальше описывают далеко не все кейсы, так, что в голову пришло пока ответ писал):
1. Трафик теста не пересекается с трафиком прода, что позволяет измерять нагрузку (и планировать, в том числе, расходы на инфраструктуру, у AWS вы как раз в основном за нагрузку и платите) на приложение прямо на балансировщике (если у вас все таки появится больше нагрузки и придется применять горизонтальное масштабирование - добавлять нод приложения за балансером)
2. Трафик теста не пересекается с трафиком прода - не возникнет коллизий, "лишней" нагрузки на балансировщик, всплеска ошибок в мониторинге балансировщика из-за тестового стенда
3. Правила на балансировщике могут быть обезличены(не иметь отношения к среде) и протестированы до внедрения в прод - важно для развития приложения