В чём компромиссы вертикального и горизонтального масштабирования применительно к базе данных по сравнению со stateless веб-слоем?

Короткий ответ

Stateless веб-слой обычно масштабируется горизонтально практически без ограничений — просто добавляются новые идентичные инстансы за балансировщиком; управляемая реляционная база данных проще всего масштабировать вертикально, а горизонтальное масштабирование записи ограничено архитектурой конкретной СУБД и часто требует шардирования или смены модели данных.

Как это работает подробнее

у stateless-сервиса каждый инстанс независим и не хранит состояние между запросами, поэтому балансировщик может равномерно распределить нагрузку между любым числом реплик; у реляционной БД запись обычно идёт на единственный primary-узел, поэтому масштабирование записи горизонтально требует либо шардирования данных, либо перехода на распределённую СУБД.

Пример кода

example.txtКопировать

Web tier: 3 instances -> 10 instances (horizontal), без изменений в коде
DB tier:  db.m5.large -> db.m5.4xlarge (vertical), относительно просто
DB tier:  single primary -> 4 shards by customer_id (horizontal), требует
          изменения схемы приложения, роутинга запросов и миграции данных

Что использовать на практике

• Рекомендация. для веб-слоя горизонтальное масштабирование — стандартный первый инструмент при росте нагрузки; для БД сначала выжимают вертикальное масштабирование и read-реплики для чтения, и только когда это перестаёт хватать именно для записи, рассматривают шардирование или миграцию на распределённую БД.
• Проверка. нагрузочный тест после вертикального апгрейда БД должен показать рост пропускной способности записи пропорционально новым ресурсам инстанса, тогда как для дальнейшего роста сверх возможностей одного инстанса потребуется архитектурное решение, а не просто очередной апгрейд класса.

Подводные камни

• Риск. пытаться «просто добавить ещё одну БД» для масштабирования записи без продуманной схемы шардирования, получая несогласованные данные
• Риск. масштабировать веб-слой вертикально вместо горизонтального, упуская возможность простого масштабирования через добавление инстансов
• Риск. недооценивать объём переписывания приложения при переходе от единого primary к шардированной модели.