О масштабировании решения

Rate this post

Мы уже говорили об оптимизации Вашего проекта «Оптимизация сервера и сайта». Сегодня пришло время поговорить о масштабировании. Что такое масштабирование? Это повышение качества работы проекта за счет увеличения производительности ресурсов.

Масштабирование бывает вертикальное, когда увеличивают мощность ресурса, или горизонтальное, когда увеличивают количество ресурсов. Второй вариант кроме общего прироста производительности, обеспечивает избыточность, что повышает отказоустойчивость.

О масштабировании, как и в принципе о развитии проекта стоит подумать заранее. Даже если сейчас у вас все работает хорошо, завтра может оказаться не так. И тогда у вас останется достаточно мало времени на принятие верного решения. Как же к этому подготовиться?

Не лишним будет иметь систему мониторинга серверов вашего проекта и информацию за определенный период, чтобы определить некоторые тренды дальнейшего использования ресурсов. Контролировать нужно как минимум:

Доступность сервера
Занятые аппаратные ресурсы (CPU, Memory, Disk Usage, Network Usage)
Ошибки работы систем

Также есть утилиты, позволяющие искусственно создавать нагрузку на веб-ресурс. Например, ab и siege.

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

Что же делать, если Ваш проект вдруг перестал справляться с нагрузкой и Вы не знаете в чем проблема?

Выполнить какую-то очевидную оптимизацию, для того чтобы снизить остроту ситуации.
Настроить систему мониторинга (если Вы еще этого не сделали)
Найти узкое место
Выполнить масштабирование, для устранения ключа проблемы, обнаруженного в п.3

Помимо анализа результатов мониторинга необходимо оценить факторы, которые мониторинг может не учитывать, такие как, например, причина нагрузки:

«Вы заказали новый рекламный проект, и он начал приносить свои плоды?»
«Сейчас время новогодних распродаж?»
«Вы объявили об акции или другом выгодном предложении?»
«Вы опубликовали горячую новость или интересный контент?»

Итак, вы нашли причину. Что же делать дальше?

На этом этапе важно понимать подход бизнеса. Есть два варианта:

Чтобы работало хорошо.
Чтобы работало недорого.

Конечно же это крайности. Но вы должны быть готовы к тому, что такой выбор перед Вами встанет.

Далее. Несмотря на то, что Вы уже проводили оптимизации текущей архитектуры, проанализируйте еще раз возможности оптимизации. Вполне может быть, что-то было упущено или поменялись условия, и существующую проблему все же можно решить путем оптимизации. Нет? А если добавить аппаратных ресурсов ?

Если Вы пока что «ютитесь» на одном сервере, но приняли решение о горизонтальном масштабировании, Вы можете рассмотреть стандартные варианты, и в зависимости от Вашего узкого места выбрать сове решение.

Схема 1. Увеличение количества серверов приложения.

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

Схема 2. Увеличение количества балансировщиков.

Нужна, когда Вы уперлись в недостаток ресурсов балансировщика. Смело можете ставить несколько и использовать DNS Round Robin для распараллеливания запросов.

Схема 3. Снятие нагрузки с базы данных.

Поможет использование нескольких копий баз данных. Для поддержки актуального состояния всех баз используется репликация. Есть несколько видов репликации мастер-мастер, мастер-слэйв. Обычно операций чтения значительно больше чем операций записи (однако, это не всегда так), поэтому запись на мастер, а чтение со слэйвов в большом количестве случаев решат проблему. Кроме этого на слэйвах можно незаметно для пользователя делать тяжелые вычисления и бекапы.

О том, чтобы масштабировать Ваше решение было проще, нужно беспокоиться еще на этапе планирования архитектуры приложения. Чем меньше связанности компонентов, тем проще масштабирование. Есть разные подходы к разбиению приложения на части:

Технически. Когда выносят на отдельный сервер обособленные сервисы.
Логически. Когда выносят на отдельный сервер обособленные функциональные узлы.

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

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