Горизонтальное и вертикальное масштабирование: когда добавлять железо, а когда разносить нагрузку

Горизонтальное и вертикальное масштабирование: когда добавлять железо, а когда разносить нагрузку

Коллеги, давайте разберем план выполнения. Вертикальное масштабирование — это быстрее усилить одну БД: CPU, RAM, IOPS. Горизонтальное — добавить узлы и распределить запросы, партиции или реплики. Оба пути рабочие, но у каждого своя цена: вертикаль упирается в потолок железа, горизонталь — в сложность схемы, консистентность и сеть.

Вертикаль хороша, когда упор в узкие места внутри одного сервера: не хватает памяти под рабочий набор, много сортировок, высокий latch/lock contention, тяжелые индексы. Плюс простой: меньше движущихся частей, проще бэкапы, failover и отладка. Минус очевиден: в продакшене так лучше не делать бесконечно — одна точка отказа остается, а апгрейд часто требует окна и риска.

Горизонталь нужна, когда один узел уже не вытягивает I/O и конкуренцию, а приложение умеет жить с распределением данных. Но тут сразу появляются шардирование, балансировка, кросс-узловые запросы, фантомы в аналитике и дорогая синхронизация. Схема простая, но дьявол кроется в статистике: если ключ распределен криво, один шард становится новым монолитом.

Золотое правило: сначала мониторинг, потом индексы. Смотрите CPU wait, I/O latency, объем активных данных, частоту блокировок и профиль запросов. Если бутылочное горлышко в одном ресурсе — вертикаль обычно дешевле и безопаснее. Если нагрузка уже требует изоляции по доменам, регионам или тенантам — тогда горизонталь оправдана.

Выбор не “или-или”, а “что ломается первым и сколько это чинить”. Начинайте с вертикали, пока есть запас, и переходите к горизонтали только когда архитектура приложения действительно готова к распределению.