Я предлагаю свое решение следующей проблемы и прошу вас, профессионалов в области сетевых и серверных администраторов, проверить его или найти в нем бреши. Меня интересуют любые очевидные векторы атак или проблемы масштабируемости, которые вы можете увидеть. Спасибо!
PUBLIC NETWORK
+-----+------+--------+-----+------->
| | | |
v v v v
+---+ +---+ +--+ +--+
|LB1| |LB2| ... |S1| |S2| ...
+---+ +---+ +--+ +--+
Избыточные балансировщики нагрузки (LB *, через что-то вроде DNS RR или просто аварийное переключение): их единственная цель - предложить клиентам URI для некоторого экземпляра сервера приложений, который затем клиент будет постоянно использовать для своих запросов. Первоначально распределение будет случайным или циклическим.
Каждый экземпляр сервера приложений (S *) независимо обрабатывает запросы напрямую от клиентов.
Архитектура без сохранения состояния позволяет отключать отдельные серверы. Клиенты запрашивают новый сервер у балансировщиков нагрузки, если их назначенный сервер выходит из строя.
Новые серверы приложений могут раскручиваться, регистрироваться в балансировщиках нагрузки и очень быстро назначаться клиентам. Все S * будут иметь запись DNS субдомена для совместного использования подстановочного сертификата.
Наивная реализация может быть выполнена полностью на одном сервере с нулевым резервированием и делегировать ответственность для расширения по мере необходимости.
Брандмауэр и защита от DDoS-атак должны управляться на каждом сервере, а не централизованно, как у обратных прокси-серверов с балансировкой нагрузки. Насколько я понял, централизованное управление конфигурацией - это так далеко.
Эта схема не использует преимущества географического положения или времени ответа сервера, как это было бы в случае с Anycast DNS. Это сознательный компромисс для большей вероятности привязки к серверу, и, возможно, его можно будет использовать позже.
В целом это выглядит неплохо, но в схеме есть пробелы.