Rivalry2

HTML Diff

0 added 0 removed

Original 2026-01-01

Modified 2026-02-26

1 <p>Горизонтальное масштабирование - техника, которая позволяет решить две задачи: выдержать большую нагрузку и повысить отказоустойчивость системы. Она используется как для нагруженных так и не нагруженных сайтов, которым важно оставаться работоспособными в случае отказа сервера. А сервера имеют свойство ломаться.</p>

2 <p>Для горизонтального масштабирования нужно как минимум два одинаковых сервера, на которые выполняется деплой приложения. Серверов может быть и три и больше. Главное в этой схеме то, что эти сервера равноправны и взаимозаменяемы. Кстати, поэтому масштабирование называется горизонтальным.</p>

3 <p>В самых продвинутых системах, сервера добавляются и удаляются автоматически при росте или уменьшении нагрузки. В любом случае, в такой схеме, смерть одного из серверов не приводит к остановке проекта. Даже если это случилось ночью, можно спокойно досмотреть сны, проснуться и включить новый сервер в работу.</p>

4 <p>А что насчет распределения запросов между серверами? С одним сервером все понятно, домен связывается с ip-адресом сервера куда отправляются все пользователи. Когда серверов два, то нужен механизм распределения, который будет решать какой запрос куда отправить. Такой процесс называют балансировкой нагрузки. Балансировать нагрузку можно разными способами.</p>

5 <h2>DNS Балансировка</h2>

6 <p>DNS позволяет добавить любое количество ip-адресов, по которым доступен домен. Когда клиент, например, браузер, запрашивает ip-адрес домена, то DNS возвращает список этих ip-адресов. Как правило клиенты используют только первый из них. На этом факте основана балансировка, DNS сконфигурирован так, что список ip-адресов всегда возвращается в случайном порядке.</p>

7 <p>DNS балансировка имеет недостатки, которые существенно ограничивают надежность и эффективность этого решения. Важнее всего то, что DNS не проверяет сервера на доступность, а приложение на работоспособность. Из-за этого, DNS всегда возвращает один и тот же список ip-адресов даже если сервер выключен или недоступен. Некоторые, продвинутые DNS умеют анализировать доступность, но даже в этом случае, реакция не будет мгновенной из-за промежуточного кеширования DNS запросов. Механизм, который помогает DNS быть эффективным в одном случае, мешает в другом.</p>

8 <h2>Балансировщик нагрузки</h2>

9 <p>Более надежное и чаще используемое решение это балансировщик нагрузки. Механизм, который принимает все входящие запросы и распределяет их между всеми доступными серверами. Балансировщиком нагрузки обычно выступает либо отдельный сервер с установленным на нем Nginx или Caddy, либо облачный сервис, такой как AWS, GCP, DO и т.д.</p>

10 <p>Балансировщики нагрузки умеют не только отслеживать доступность серверов и наличие ошибок, они умеют балансировать по нагрузке и даже географическому расположению. Выбор сервера, который физически ближе к клиенту, позволяет сократить задержку сети.</p>

11 <p>У балансировщиков нагрузки есть и недостатки. Основной - мы снова вернулись к схеме, когда есть одна точка отказа. Поломка балансировщика выводит из строя весь проект. Поэтому, там где возможно, стараются использовать балансировщик как сервис, доступный в любых облаках. Если это невозможно, то для балансировщика выбирают более надежные машины и даже аппаратный балансировщик.</p>

12 <p>Ниже пример того, как делается балансировка нагрузки в Caddy и Nginx:</p>

13 <h2>Реализация</h2>

14 <p>Начнем с деплоя. Текущая схема с Ansible легко масштабируется с одного сервера на несколько. Для этого нужно создать новый сервер и добавить его ip-адрес в inventory-файл:</p>

15 <p>Затем выполните деплой:</p>

16 <p>Теперь зайдите в интерфейс создания балансировщика нагрузки на сайте DO:</p>

17 <ol><li>Выберите датацентр, в котором находятся ваши сервера</li>

18 <li>Оставьте сеть по умолчанию, она будет такой же, в которой создавались наши сервера</li>

19 <li>Балансировщик сам может состоять из нескольких машин для надежности. Нам достаточно одной</li>

20 <li>Найдите через поиск созданные дроплеты и подключите их к балансировщику. Это можно сделать и после создания</li>

21 <li>Опишите правила, по которым, происходит проброс портов. В нашем случае снаружи и внутри будет https. Когда вы выберите эту опцию, вам предложат выбрать новый сертификат. Выберите<em>Passthrough</em>.</li>

22 <li>Затем вам предложат выбрать дополнительные опции, например,<em>Health checks</em>. Это проверки, которые будет выполнять DO, для проверки того, жив ли проект. Поправьте порт с 80 на 443. Добавьте автоматический редирект http на https.</li>

23 </ol><p>Когда все настройки поправлены, нажмите "создать балансировщик". Возьмите его ip-адрес и замените им ip-адрес сервера в файле<em>/etc/hosts</em>. Откройте сайт и убедитесь что он работает<em>devops-example.test</em>.</p>

24 <p>Как проверить что балансировка нагрузки работает? Попробуйте отключить один из серверов прямо из панели DO ;)</p>

25 <h2>Состояние на сервере</h2>

26 <p>Горизонтальное масштабирование не дается бесплатно. Ключевое ограничение горизонтального масштабирования - отсутствие состояния на сервере. Под состоянием понимаются любые данные: база данных, файлы, сессии и тому подобное. Если хотя бы что-то из этого хранится на одном из серверов приложений, то значит этого нет на других серверах, а значит пользователь то будет видеть эти данные, то нет, в зависимости от того, куда направил его балансировщик.</p>

27 <ol><li>База данных должна находиться на своем выделенном сервере</li>

28 <li>Сессии желательно хранить в куках</li>

29 <li>Файлы грузить на сервисы типа<a>Amazon S3</a></li>

30 </ol><h2>Логирование</h2>

31 <p>Другая сложность - логирование. Когда сервер один, то всегда можно зайти на него и посмотреть логи приложения или системы. Когда их несколько, непонятно куда заходить. А если серверов 10? Для анализа логов в такой схеме нужен механизм их сбора где-то в централизованном хранилище. Существует два типа решений:</p>

32 <ol><li>Облачное. Легко подключается, настраивается и просто работает. Само решение может быть частью серверной инфраструктуры как в Amazon. Там за сбор логов отвечает<a>Amazon CloudWatch</a>. В других облаках такого решения может и не быть. В таких случаях используют внешние сервисы, например<a>DataDog</a></li>

33 <li>Самостоятельное. Для этого обычно используют связку<a>ElasticSearch</a>(хранилище и поиск),<a>Logstash</a>(сборщик логов) и<a>Kibana</a>(инструмент визуализации). Иногда ее называют<a>ELK</a>стек.</li>

34 </ol><p>Какое бы решение не использовалось, на выходе получается единая панель управления, через которую можно найти всю необходимую информацию, которая когда-либо была в логах.</p>