Эта схема распределения нагрузки / горизонтального масштабирования наивна?

Я предлагаю свое решение следующей проблемы и прошу вас, профессионалы в области сетевых технологий и администрирования серверов, проверить ее или выявить в ней дыры. Меня интересуют любые очевидные векторы атак или проблемы масштабируемости, которые вы можете увидеть. Спасибо!

Требования:

• Поддержка HTTPS, обрабатывается каждым сервером приложений независимо
• почти линейная горизонтальная масштабируемость
• пропускная способность, распределенная по серверам (данные ответов не все возвращаются через LB или прокси)
• что-то вроде аварийного переключения для серверов приложений и балансировщиков нагрузки
• клиент-серверная близость
• Linux-friendly (решение не с закрытым исходным кодом)
• самонастройки удобно! (т.е. низкая начальная стоимость)

Схема:

            PUBLIC NETWORK
+-----+------+--------+-----+------->
      |      |        |     |
      v      v        v     v
    +---+  +---+     +--+  +--+
    |LB1|  |LB2| ... |S1|  |S2| ...
    +---+  +---+     +--+  +--+

Избыточные балансировщики нагрузки (LB*, через что-то вроде DNS RR или просто аварийное переключение): их единственная цель - предложить клиентам URI для некоторого экземпляра сервера приложений, который клиент затем будет постоянно использовать для своих запросов. Первоначально распределение будет случайным или циклическим.

Каждый экземпляр Application Server (S*) независимо обрабатывает запросы напрямую от клиентов.

Архитектура без сохранения состояния позволяет отключать отдельные серверы. Клиенты запрашивают новый сервер у балансировщиков нагрузки в случае сбоя назначенного им сервера.

Новые серверы приложений могут раскручиваться, регистрироваться с помощью балансировщиков нагрузки и очень быстро назначаться клиентам. Все S * будут иметь DNS-запись субдомена для совместного использования сертификата с подстановочными знаками.

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

Непосредственные проблемы

Защита брандмауэром и DDoS должна осуществляться на каждом сервере, а не централизованно, как у вас с обратными прокси-серверами с балансировкой нагрузки. Централизованное управление конфигурацией, насколько я думал, это.

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