Что вы знаете о балансировке нагрузки виды
Перейти к содержимому

Что вы знаете о балансировке нагрузки виды

  • автор:

Что такое балансировщик нагрузки и как он работает

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

При этом нагрузка на каждый сервер может быть неравномерной. Избыточная нагрузка на один из серверов приводит к очевидным последствиям — увеличению времени отклика, задержки сети, простою или недоступности ресурса, потере трафика и клиентов.

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

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

Что такое балансировщик нагрузки серверов

Балансировщик нагрузки (Load Balancer) — это сервис для распределения запросов между серверами кластера. Балансировщик позволяет сохранить доступность ресурса даже при аномальной нагрузке.

Балансировка нагрузки может производиться по разными критериям: в порядке очереди, по степени загруженности серверов, по количеству подключений и многим другим аспектам.

Распределение нагрузки можно настроить для разных сервисов:

  • веб-приложение,
  • прокси-сервер,
  • брандмауэр,
  • DNS-сервер,
  • система DPI и др.

Популярные алгоритмы балансировки нагрузки

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

  • Интенсивность нагрузки. При выборе способа балансировки стоит протестировать примерную нагрузку, которая может возникнуть на сетевом уровне, объем трафика на конечных серверах, нагрузку на процессор. На основе этих данных вы сможете подобрать подходящий балансировщик.
  • Оптимальное распределение ресурсов. Важно, чтобы в сети не было «лишних»элементов: всё оборудование должно быть в рабочем состоянии и использоваться по назначению. Это нужно для корректной работы балансировщика.
  • Необходимая скорость. Рекомендуем выбирать балансировщик, который не замедлит обработку запросов.

Для распределения нагрузки чаще всего используются следующие алгоритмы:

  • Round Robin,
  • Weighted Round Robin,
  • Least Connections,
  • Sticky Sessions.

Round Robin

Round Robin — это алгоритм распределения нагрузки, который отправляет запросы к серверам в порядке очереди.

Предположим, что у вас есть три сервера и между ними нужно равномерно распределить все запросы. Round Robin будет направлять запросы по очереди: сначала первому серверу, потом второму, а затем третьему. После этого он будет повторять этот цикл из раза в раз.

Преимущества Round Robin:

  • простая логика работы,
  • низкая стоимость реализции.

Также у этого алгоритма есть недостаток — нагрузка может распределяться не оптимально. Если в сеть включены серверы с разными техническими характеристиками, нагрузка будет распределяться не по возможностям той или иной машины. Этот недостаток можно исправить, если использовать Weighted Round Robin.

Weighted Round Robin

Алгоритм Weighted Round Robin — это улучшенная версия Round Robin, которая позволяет назначать «вес» серверам. В Weighted Round Robin собраны преимущества стандартного Round Robin и исправлены его недостатки.

Чем хороша технология Weighted Round Robin:

  • простой настройкой,
  • дешевизной,
  • возможностью присвоить каждой машине весовой коэффициент — коэффициент допустимой нагрузки.

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

Least Connections

Least Connections — это алгоритм, который распределяет нагрузку между серверами, ориентируясь на количество подключений. Как это работает на практике?

Предположим, что в вашей сети три сервера. К первому серверу подключен один пользователь, ко второму — два, а к третьему — три. Согласно алгоритму Least Connections, входящий запрос придет к серверу с наименьшим количеством подключений, то есть к первому серверу.

Алгоритм Least Connections хорош тем, что учитывает не только нагрузку на оборудование, но и количество подключений. Благодаря этому трафик в сети распределяется «справедливо» — то есть с учетом большего числа критериев.

Однако у этой технологии есть и недостаток — если пользователь автоматически переподключится к другому серверу, ему нужно будет авторизоваться заново. Это будет происходить каждый раз при перенаправлении пользовательского запроса к другому серверу.

Sticky Sessions

Sticky Sessions — это алгоритм, который распределяет нагрузку не только по количеству подключений к серверам, но и по IP-адресам элементов сети.

Например, в сети есть сервер с адресом 123.123.123.123. Если он был менее загружен и принял пользовательский запрос, создается клиентская сессия. Эта сессия длится, пока пользователь не отключится самостоятельно. Сессия может разорваться без участия клиента только в одном случае: если сервер недоступен. Если это произошло, клиент переподключается к доступному серверу с другим IP и сессия создается заново.

Пример использования балансировщика нагрузки от SpaceWeb

Посмотрим, как работает балансировщик. Для этого создаем 3 виртуальных сервера и объединяем их в кластер с помощью балансировщика:

Для двух серверов устанавливаем приоритет 1, для третьего — приоритет 2. Трафик будем балансировать по протоколу HTTP на 80 порту.

Теперь отправим 1000 запросов к балансировщику:

for((i=0;i<1000;i=i+1)); do wget -o /dev/null http://77.222.63.167/; done

Результат проверяем на конечных узлах с помощью анализа лога посещений:

grep Wget /var/log/nginx/access.log |wc -l357
grep Wget /var/log/nginx/access.log |wc -l285
grep Wget /var/log/nginx/access.log |wc -l358

Видим, что запросы распределились равномерно согласно установленному весу.

Теперь сэмулируем аварийную ситуацию: выключим один из серверов и повторим отправку 1000 запросов на баласировщик. Смотрим распределение:

grep Wget /var/log/nginx/access.log |wc -l555
grep Wget /var/log/nginx/access.log |wc -l445

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

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

Мы рассказали о самых популярных вариантах балансировки нагрузки на ваш ресурс. Вы можете задействовать нужный тип распределения нагрузки самостоятельно или использовать наш балансировщик: в этом случае вы сэкономите время на настройке услуги. Также при использовании балансировщика от SpaceWeb есть возможность выиграть в плане цены: настройка некоторых решений стоит дорого.

Что такое балансировка нагрузки в сети?

img

Современные веб-сайты и приложения генерируют большой трафик и одновременно обслуживают многочисленные запросы клиентов. Балансировка нагрузки помогает удовлетворить эти запросы и обеспечивает быстрый и надежный отклик веб-сайта и приложений.

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

Что такое балансировка нагрузки?

Балансировка нагрузки (Load Balancing) распределяет высокий сетевой трафик между несколькими серверами, позволяя организациям масштабироваться для удовлетворения рабочих нагрузок с высоким трафиком. Балансировка направляет запросы клиентов на доступные серверы, чтобы равномерно распределять рабочую нагрузку и улучшать скорость отклика приложений, тем самым повышая доступность веб-сайта или сервера.

Балансировка нагрузки применяется к уровням 4-7 в семиуровневой модели OSI.

  • L4. Направление трафика на основе сетевых данных и протоколов транспортного уровня, например IP-адреса и TCP-порта.
  • L7. Добавляет переключение содержимого в балансировку нагрузки, позволяя принимать решения о маршрутизации в зависимости от таких характеристик, как HTTP-заголовок, унифицированный идентификатор ресурса, идентификатор сеанса SSL и данные HTML-формы.
  • GSLB. Global Server Load Balancing расширяет возможности L4 и L7 на серверы на разных сайтах.

Почему важна балансировка нагрузки?

Балансировка нагрузки необходима для поддержания информационного потока между сервером и пользовательскими устройствами, используемыми для доступа к веб-сайту (например, компьютерами, планшетами, смартфонами).

Есть несколько преимуществ балансировки нагрузки:

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

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

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

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

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

Как работает балансировка нагрузки?

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

Load Balancing

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

Балансировщики нагрузки динамически добавляют или отключают серверы в случае высокого или низкого спроса. Таким образом, обеспечивается гибкость.

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

Типы балансировки нагрузки

Балансировщики нагрузки различаются по типу хранилища, сложности и функциональности балансировщика. Ниже описаны различные типы балансировщиков нагрузки.

Аппаратное обеспечение (Hardware-Based)

Аппаратный балансировщик нагрузки — это специализированное оборудование с установленным проприетарным программным обеспечением. Он может обрабатывать большие объемы трафика от различных типов приложений.

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

Программное обеспечение (Software-Based)

Программный балансировщик нагрузки работает на виртуальных машинах или серверах белого ящика, как правило, в составе ADC (application delivery controllers — контроллеры доставки приложений). Виртуальная балансировка нагрузки обеспечивает превосходную гибкость по сравнению с физической.

Программные балансировщики нагрузки работают на обычных гипервизорах, контейнерах или как процессы Linux с незначительными накладными расходами на bare metal сервере.

Виртуальный (Virtual)

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

Облачный (Cloud-Based)

Облачная балансировка нагрузки использует облачную инфраструктуру. Вот некоторые примеры облачной балансировки нагрузки:

  • Балансировка сетевой нагрузки. Балансировка сетевой нагрузки основана на уровне 4 и использует информацию сетевого уровня, чтобы определить, куда отправлять сетевой трафик. Это самое быстрое решение для балансировки нагрузки, но ему не хватает балансировки распределения трафика между серверами.
  • Балансировка нагрузки HTTP(S). Балансировка нагрузки HTTP(S) основана на уровне 7. Это один из наиболее гибких типов балансировки нагрузки, позволяющий администраторам принимать решения о распределении трафика на основе любой информации, поступающей с адресом HTTP.
  • Внутренняя балансировка нагрузки. Внутренняя балансировка нагрузки почти идентична балансировке сетевой нагрузки, за исключением того, что она может балансировать распределение во внутренней инфраструктуре.

Алгоритмы балансировки нагрузки

Различные алгоритмы балансировки нагрузки предлагают разные преимущества и сложность в зависимости от варианта использования. Наиболее распространенные алгоритмы балансировки нагрузки:

Round Robin (По-круговой)

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

Round Robin

Least Connections (Наименьшее количество подключений)

Алгоритм наименьшего количества подключений предполагает отправку нового запроса наименее загруженному серверу. Метод наименьшего соединения используется, когда в пуле серверов много неравномерно распределенных постоянных соединений.

Least Connections

Least Response Time (Наименьшее время отклика)

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

Least Response Time

Hash (Хеш)

Алгоритм хеширования определяет, куда распределять запросы, на основе назначенного ключа, такого как IP-адрес клиента, номер порта или URL-адрес запроса. Метод Hash используется для приложений, которые полагаются на сохраненную информацию о пользователях, например, тележки на веб-сайтах интернет магазинов.

Hash

Custom Load (Пользовательская нагрузка)

Алгоритм Custom Load направляет запросы к отдельным серверам через SNMP (Simple Network Management Protocol). Администратор определяет нагрузку на сервер, которую балансировщик нагрузки должен учитывать при маршрутизации запроса (например, использование ЦП и памяти, а также время ответа).

Custom Load

Заключение

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

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

Как устроен балансировщик нагрузки: алгоритмы, методы и задачи

Рассказываем, как устроены алгоритмы и методы балансировки, какие существуют точки отказа в инфраструктуре, в чем преимущества облачных балансировщиков.

Изображение записи

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

Из статьи вы узнаете, как устроены алгоритмы и методы балансировки, какие существуют точки отказа, в чем разница между Load balancer и прокси.

Что такое балансировка сетевой нагрузки

Балансировка нагрузки — метод распределения сетевого трафика и задач между сетевыми устройствами.

На старте развития сервиса все компоненты (Frontend, Backend, база данных) могут находиться на одном сервере. Если нагрузка растет, его можно масштабировать вертикально: поменять конфигурацию сервера на более мощную или быстро добавить ресурсов в облачный сервер — добавить число vCPU или объем памяти.

На какое-то время этого будет достаточно, но в конечном итоге мощности сервера может не хватить, и задачи разделятся на несколько серверов. Так, фронтенд уйдет на отдельный сервер, бэкенд — на второй, а база данных будет храниться еще на одной машине. Причем каждый из серверов тоже можно «проапгрейдить» вертикально.

выбор конфигурации

В облачных балансировщиках доступны различные комбинации протоколов, которые имеют дело с нагрузкой L4 и нагрузкой L7-уровней.

  • TCP–TCP — классическая L4-балансировка,
  • TCP–PROXY — информация о клиенте не теряется и передается в отдельном заголовке соединения,
  • UDP–UDP — UDP-протокол быстрее, чем TCP, но менее надежен,
  • HTTP–HTTP — L7-балансировка,
  • HTTPS–HTTP — L7-балансировка с шифрованием и терминацией SSL-сертификата на балансировщике.

тип балансировщика

Заключение

На этом мы закончим обзор балансировщиков нагрузки. Мы рассмотрели современные подходы балансировки сетевой нагрузки, изучили функционал Load balancer и алгоритмы балансировки.

Балансировщики нагрузки — обязательный элемент сложной инфраструктуры, которая состоит из нескольких серверов и требует «умных» подходов к управлению трафиком.

Алгоритмы балансировки нагрузок

Рано или поздно веб-приложения перерастают среду одного сервера. Компаниям требуется увеличить или их доступность, или масштабируемость, или и то, и другое. Чтобы сделать это, они развёртывают своё приложение на нескольких серверах и ставят перед ним балансировщик нагрузок для распределения входящих запросов. Чтобы справляться с нагрузками, большим компаниям могут потребоваться тысячи серверов, на которых запущено веб-приложение.

В этом посте мы рассмотрим способы, которыми один балансировщик нагрузок может распределять HTTP-запросы на множество серверов. Мы начнём снизу и проделаем весь путь вверх до современных алгоритмов балансировки нагрузок.

▍ Визуализация проблемы

Давайте начнём сначала: с одного балансировщика нагрузок , отправляющего запросы одному серверу . Запросы отправляются с частотой 1 запрос в секунду (request per second, RPS), и каждый запрос постепенно уменьшается в размере, пока сервер обрабатывает его.

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

Мы видим, что при частоте 3 RPS — часть запросов отбрасывается . Если запрос поступает на сервер , пока обрабатывается другой запрос , то сервер его отбросит . Это приводит к тому, что у пользователя отображается ошибка, и такую ситуацию нужно избегать. Чтобы устранить проблему, можно добавить к нашему балансировщику нагрузок ещё один сервер .

Отбрасываемых запросов больше нет! Наш балансировщик нагрузок в этом случае отправляет по очереди запрос каждому серверу ; это называется балансировкой нагрузок циклическим перебором (round robin). Это одна из самых простых разновидностей балансировки нагрузок, которая хорошо работает, когда серверы имеют одинаковую мощность, а запросы одинаково затратны.

▍ Когда round robin не подходит

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

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

Хотя большинство запросов обрабатывается успешно, некоторые приходится отбрасывать . Один из способов решения этой проблемы заключается в создании «очереди запросов».

Очереди запросов позволяют нам справляться с неопределённостью, но при этом приходится идти на компромисс. Мы будем отбрасывать меньшее количество запросов , однако ценой того, что некоторые запросы будут иметь повышенную задержку. Если вы понаблюдаете за показанной выше симуляцией, то заметите, что запросы немного меняют цвет. Чем дольше они не обрабатываются, тем сильнее меняется их цвет. Также вы заметите, что благодаря различиям в стоимости запросов серверы начинают проявлять признаки дисбаланса. Очереди накапливаются на серверах , которым не повезло и которым приходится обрабатывать множество затратных запросов подряд. Если очередь заполнена, мы отбросим запрос .

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

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

Однако несмотря на свои недостатки, round robin по-прежнему остаётся стандартным методом балансировки HTTP-нагрузок для nginx.

▍ Совершенствование round robin

Можно улучшить round robin так, чтобы он лучше справлялся с колебаниями. Существует алгоритм, называющийся «weighted round robin» («взвешенный цикличный перебор»); он заключается в том, что люди присваивают каждому серверу вес, определяющий, сколько запросов ему отправлять.

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

Хотя это позволяет лучше справляться с колебаниями мощности серверов , чем стандартный round robin, нам всё равно нужно решить вопрос колебаний запросов . На практике ручное указание весов быстро оказывается неэффективным. Сложно свести производительность сервера к одному числу, и для этого потребуется тщательное тестирование нагрузок с реальными рабочими нагрузками. Это делают редко, поэтому другой вариант weighted round robin вычисляет веса динамически при помощи вспомогательной метрики: задержки.

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

На этот раз я добавил к каждому серверу текст, отображающий среднюю задержку трёх последних обработанных запросов . Затем мы решаем, отправить ли 1, 2 или 3 запроса каждому серверу , на основании относительного различия в задержках. Результат очень схож с исходной симуляцией weighted round robin,
но отсутствует необходимость заранее указывать вес каждого сервера . Этот алгоритм также сможет адаптироваться к изменениям производительности сервера со временем. Это называется «dynamic weighted round robin».

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

▍ Уходим от round robin

Кажется, dynamic weighted round robin хорошо учитывает колебания и мощности сервера , и затрат на запросы . Но что, если я скажу вам, что можно решать задачу ещё лучше и при помощи более простого алгоритма?

Это называется балансировкой нагрузок по принципу «least connections» (наименьшего количества соединений).

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

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

Давайте посмотрим это в действии в симуляции схожего уровня сложности и с теми же параметрами, что и в алгоритме dynamic weighted round robin. Эти параметры в оригинале статьи тоже рандомизированы, так что можно обновить страницу, чтобы увидеть новые варианты.

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

▍ Оптимизация задержек

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

Часто нас больше волнуют задержки. Они измеряются в миллисекундах с момента создания запроса до его обработки. При обсуждении задержки в этом контексте обычно говорят о разных «перцентилях». Например, 50-й перцентиль (также называемый «медианой») определяется как значение в миллисекундах, ниже которого 50% запросов и выше которого 50% запросов.

Я запустил на 60 секунд три симуляции с одинаковыми параметрами и каждую секунду фиксировал различные измерения. Симуляции отличались лишь алгоритмом балансировки нагрузок. Давайте сравним медианы для каждой из трёх симуляций:

Возможно, вы этого не ожидали, но round robin имеет самую низкую медианную задержку. Если бы мы не рассматривали все остальные точки данных, то упустили бы общую картину. Давайте взглянем на 95-й и 99-й перцентили.

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

Мы видим, что round robin плохо проявляет себя на высоких перцентилях. Почему round robin имеет отличную медиану, но плохие 95-й и 99-й перцентили?

При round robin состояние каждого сервера не учитывается, поэтому довольно много запросов будут отправляться к серверам , находящимся в состоянии простоя. Вот как мы получаем низкий 50-й перцентиль. С другой стороны, мы запросто будем отправлять запросы на перегруженные серверы , таким образом — получая плохие 95-й и 99-й перцентили.

Полные данные мы можем рассмотреть в виде гистрограммы:

Я выбрал параметры этих симуляций таким образом, чтобы избежать отбрасывания всех запросов . Это гарантирует, что мы будем сравнивать одинаковое количество точек данных для всех трёх алгоритмов. Давайте снова запустим симуляции, но с увеличенным значением RPS, чтобы все алгоритмы перестали справляться. Ниже показан график кумулятивных запросов , отбрасываемых с течением времени.

Least connections справляется с перегрузками гораздо лучше, но ценой чуть больших задержек 95-го и 99-го перцентиля. В некоторых случаях это может быть приемлемым компромиссом.

▍ Ещё один алгоритм

Если нам действительно нужно оптимизировать задержки, то требуется алгоритм, учитывающий их. Разве не будет здорово, если мы сможем скомбинировать алгоритмы dynamic weighted round robin и least connections? Так мы получим задержку weighted round robin и надёжность least connections.

Оказывается, не у нас первых возникла такая мысль. Ниже показана симуляция, использующая алгоритм под названием «peak exponentially weighted moving average» (или PEWMA). Название длинное и сложное, но не торопитесь, скоро мы его разберём.

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

Как он это делает? Он сочетает методики из dynamic weighted round robinс методиками из least connections, а поверх добавляет немного своей магии.

Для каждого сервера алгоритм отслеживает задержку последних N запросов . Вместо того, чтобы использовать её как среднее, он суммирует значения, но экспоненциально снижает коэффициент масштаба. Это приводит к тому, что чем старее задержка, тем меньше она влияет на сумму. Недавние запросы влияют на расчёт сильнее, чем старые.

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

Как же он проявляет себя в сравнении с другими алгоритмами? Сначала давайте взглянем на 50-й, 95-й и 99-й перцентиль и сравним их с показанными выше данными least connections.

Мы видим улучшения во всех перцентилях! Гораздо больше они проявляются на высоких перцентилях, но стабильно присутствуют и в медиане. Вот те же данные в виде гистограммы.

А как насчёт отброшенных запросов ?

Изначально производительность лучше, но со временем алгоритм начинает вести себя хуже, чем least connections. Это логично. PEWMA оппортунистичен, он пытается добиться наилучшей задержки, а это значит, что он иногда может обеспечивать неполную загрузку сервера .

Я хочу здесь добавить, что PEWMA имеет множество параметров, которые можно настраивать. Реализация, которую я написал для этого поста, использует конфигурацию, хорошо работающую в тестированных мной ситуациях, однако дальнейшая настройка может обеспечить более качественные результаты в сравнении с least connections. Это один из недостатков PEWMA по сравнению с least connections: дополнительная сложность.

▍ Заключение

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

Обязательное примечание : всегда следует выполнять бенчмарки собственных нагрузок, а не воспринимать советы из Интернета как панацею. В моих симуляциях игнорируются реальные ограничения (медленный запуск сервера, сетевые задержки), они настроены для демонстрации свойств каждого алгоритма. Это не реалистичные бенчмарки, которые стоит принимать за чистую монету.

В конце оригинала статьи есть песочница, в которой можно поэкспериментировать с большинством параметров в реальном времени.

  • ruvds_перевод
  • балансировка нагрузки
  • балансировщик нагрузки
  • оптимизация запросов
  • веб-серверы

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *