День 2184. #ЗаметкиНаПолях
Масштабируем Монолиты. Начало
Монолиты среди разработчиков пользуются дурной славой. Считается что они устарели, не масштабируются и что для успеха нам нужны микросервисы. Это неправда. Хорошо спроектированный монолит - часто правильный выбор и может хорошо масштабироваться. Ключ к успеху — понимание ваших потребностей в масштабировании и применение правильных решений в нужное время.

Понимание масштаба
Монолит помещает весь код в одну развёртываемую единицу. Его преимущества - более быстрые циклы разработки, более простые отладка и развёртывания. Но по мере роста системы вы столкнётесь с проблемами масштабирования:
- Запросы к БД замедляются по мере роста объёма данных;
- API, отлично работавшее с сотнями пользователей, начинает тормозить при тысячах;
- Время сборки увеличивается по мере расширения кодовой базы.
Это естественные проблемы роста, с которыми сталкивается каждая успешная система.

1. Вертикальное масштабирование
Это предоставление приложению большего количества ресурсов на одной машине. Самая простая стратегия масштабирования и часто самый эффективный первый шаг. Прежде чем погружаться в сложные распределённые системы, подумайте, может ли модернизация существующей инфраструктуры решить проблемы с производительностью.

Вертикальное масштабирование особенно хорошо работает, когда есть явные узкие места в ресурсах. Если ЦП постоянно загружен более чем на 80%, поможет добавление дополнительных ядер. Если тормозит ввод-вывод в БД, обновление до более быстрого хранилища может значительно повысить производительность. Современные облачные платформы делают это чрезвычайно простым.

Преимущества
Поддерживается простота системы: не нужно перепроектировать архитектуру, внедрять новые шаблоны развёртывания или управлять сложностью распределённой системы. Процедуры мониторинга, отладки и эксплуатации остаются прежними.

Ограничения
В итоге вы достигнете потолка того, что может обработать одна машина. В облаке есть ограничения мощности машин, а затраты обычно экспоненциально увеличиваются. Кроме того, одна машина — это единая точка отказа.

За чем следить:
- Расходы растут быстрее, чем пользовательская база;
- Нужна лучшая избыточность и отказоустойчивость;
- Время простоя развёртывания влияет на бизнес-операции;
- Самый большой доступный размер машины приближается к 70% использования.

2. Горизонтальное масштабирование
Запускает несколько экземпляров приложения за балансировщиком нагрузки. Обеспечивает улучшенную отказоустойчивость и почти линейные возможности масштабирования.

Ключ к успешному горизонтальному масштабированию в дизайне приложения. Оно не должно сохранять состояние — каждый запрос должен содержать всю информацию, необходимую для его обработки. Это означает:
- Аутентификация через токены (например, JWT), а не сессии на сервере;
- Распределённое кэширование.

Балансировщик нагрузки играет решающую роль в этой архитектуре. Его задача — распределять трафик по экземплярам приложения. Популярные варианты включают:
- nginx: мощный, с открытым исходным кодом, отлично подходит для пользовательских конфигураций;
- YARP: обратный прокси от Microsoft, отлично подходит для приложений .NET;
- Облако: AWS ALB, Azure Application Gateway, Google Cloud Load Balancing

Преимущества
- Лучшая отказоустойчивость;
- Возможность обрабатывать больше пользователей одновременно;
- Последовательные развёртывания с нулевым временем простоя;
- Экономически эффективное масштабирование (отключение ненужных экземпляров при низком трафике).

Недостатки
В основном не технические, а архитектурные. Приложение должно быть спроектировано для горизонтального масштабирования с самого начала. Преобразование приложения с сохранением состояния в приложение без него часто требует значительного рефакторинга.

Продолжение следует…

Источник: https://www.milanjovanovic.tech/blog/scaling-monoliths-a-practical-guide-for-growing-systems