Дата последнего изменения: 14.02.2023
Стандартное веб приложение работает на одном сервере: собственно веб-сервер, кеширование, база данных приложения. Достаточно часто ресурсов сервера перестаёт хватать и приходится переходить на новый тарифный план или производить апгрейд сервера. Это первый шаг в долгом процессе - вертикальное масштабирование, когда добавляются ресурсы сервера. Рано или поздно происходит упор в ограничение возможностей либо хостинга, либо "железа".
Следующий шаг - разделение приложения, когда приложение делится на составные части (web, БД, кеш) и эти части работают на разных серверах. С точки зрения производительности большинству проектов бывает достаточно такого разделения. Однако такое деление не решает задачу надёжности и отказоустойчивости. Каждый узел не зарезервирован и в случае выхода из строя любого из них перестаёт работать весь проект в целом.
Следующий логический шаг - научиться масштабировать дальше. Научиться представлять любой узел системы в виде кластера серверов, которые будут взаимозаменяемы, и в случае аварии проект продолжит работу. На этом этапе возникают сложности: просто так добавить несколько серверов под БД, несколько серверов под web уже становится сложно, потому что приходится значительно переписывать, перерабатывать логику веб-приложения.
Основные задачи, которые решает веб-кластер - это задача производительности и задача отказоустойчивости: