Почему одометричная балансировка нагрузки выбирает неправильный сервис при интенсивном трафике?
В традиционных подходах к балансировке нагрузки выбор алгоритма чаще всего сводится к одномерному списку: распределяй по очереди, отправляй на наименьшее число соединений, фиксируй по адресу источника или используй веса. Эта модель может казаться достаточной при нормальном трафике; но когда начинается кампания, всплеск API, трафик трансляции или внезапная плотность пользователей, для принятия решения в одиночку она оказывается слабой.
Например, если два backend дают одинаковое время отклика, а у системы нет возможности сделать второе сравнение, трафик распределяется произвольно. Может быть выбран сервис с низким временем отклика, но переполненной очередью; сервис с малым числом соединений, но уже начавший выдавать ошибки, всё ещё может оставаться кандидатом.
Эта неопределённость особенно влияет на крайние значения задержки. Пока среднее время отклика кажется приемлемым, в высоких процентилях пользовательский опыт может деградировать. Когда задержка, добавляемая контролями безопасности, контроля доступа или прикладного слоя, также не учитывается, могут выходить вперёд кандидаты, кажущиеся быстрыми, но фактически ведущие себя медленно.
Правильная модель должна читать живые сигналы сервиса в момент решения, автоматически отсеивать нездоровых кандидатов или кандидатов в режиме обслуживания. Если задействована привязка сессий, она не должна нарушать существующую привязку пользователя; выбирать наиболее подходящий сервис следует только для свободных запросов.
Именно эту фундаментальную проблему решает Fastest+ Routing: привязать решение о балансировке нагрузки не к одному ярлыку, а к поведению сервиса в реальном времени и в двух ступенях.
Наш подход
TR7 реализует Fastest+ Routing через чтение живых сигналов, двухуровневое оценивание, осведомлённость о работоспособности и конфигурацию на основе интерфейса.
Решение принимается для каждого запроса по живым данным сервиса
Логика решения работает встроенно в плоскость данных и при каждом HTTP- или TCP-запросе читает живую статистику сервиса. Выбранный сервис записывается в переменную маршрутизации, и трафик продвигается согласно этому решению. Оператор получает динамический выбор для каждого запроса без написания специального кода.
Оставшихся в равенстве кандидатов разделяет второй сигнал
На первой ступени в список кандидатов попадают сервисы с лучшим значением по первичному сигналу. Если несколько сервисов делят одинаковую оценку, на второй ступени вступает в действие вторичный сигнал. Так практические решения вроде «если время отклика одинаковое, выбери того, у кого очередь свободнее» реализуются внутри одного алгоритма.
Состояние работоспособности и привязка сессий сохраняются вместе
Сервисы в режиме обслуживания или с неподходящим состоянием работоспособности не попадают в список кандидатов. Если задействована динамическая привязка сессий, выбор Fastest+ пропускается, и существующая привязка сессии сохраняется. Этот подход при оптимизации производительности не нарушает пользовательские сессии.
Сигналы решения выбираются из интерфейса, код не нужен
Оператор лишь выбирает первичный и вторичный сигнал решения. Система автоматически генерирует необходимые строки маршрутизации на этапе формирования конфигурации. Сложная логика решения превращается в простой выбор политики для повседневной эксплуатации.
Возможности
Fastest+ Routing предоставляет продвинутые возможности маршрутизации, совместно оценивающие между backend живую производительность, работоспособность и привязку сессий.
Двухуровневый выбор минимума контролируемо разделяет равные оценки
Когда по первичному сигналу решения находится новое лучшее значение, список кандидатов сбрасывается; сервисы с тем же значением добавляются в список. На второй ступени эти кандидаты вновь сужаются по вторичному сигналу. В конфигурации по умолчанию Fastest+ среди кандидатов с низким временем отклика предпочитает сервис с более низкой мгновенной нагрузкой сессий. Благодаря этому среди сервисов, кажущихся быстрыми, предпочтение отдаётся тому, у кого нагрузка ниже.
Решение о трафике принимается не по техническим счётчикам, а по понятным сигналам сервиса
Оператор выбирает для Fastest+ два сигнала решения: среднее время отклика, время установки соединения, время ожидания в очереди, мгновенная нагрузка сессий, мгновенная заполненность очереди, ошибки соединения, плотность ошибок клиента, плотность ошибок сервера, обрывы со стороны сервиса или использованная ёмкость соединений. Эти сигналы внутри системы привязываются к соответствующим живым счётчикам сервиса; пользователю не приходится иметь дело с сырыми именами метрик. Так трафик можно направлять не просто на «кажущийся быстрым» сервис, а на backend, который в данный момент здоровее, свободнее или выдаёт меньше ошибок.
Односигнальный режим обеспечивает более простую маршрутизацию, когда это нужно
В пулах сервисов, где второе сравнение не требуется, можно использовать односигнальный режим. В этом режиме решение принимается только по лучшему значению выбранного первичного сигнала. Для более простых групп сервисов не добавляется лишняя глубина решения. Оператор может управлять как односигнальным, так и двухсигнальным режимом из одного интерфейса.
Режим обслуживания и состояние работоспособности автоматически фильтруются в процессе решения
Если backend в режиме обслуживания или его состояние работоспособности неподходящее, он не попадает в список кандидатов. Это поведение встроено в алгоритм; оно не требует отдельного ручного правила, дополнительного списка контроля доступа или операционного вмешательства. Плановое обслуживание, изоляция проблемного сервиса и временный вывод сервиса автоматически отражаются в решении о трафике. Так система выбирает только среди подходящих кандидатов.
При задействованной привязке сессий Fastest+ не нарушает существующую привязку
Когда возникают условия привязки сессий, выбор Fastest+ отключается. Запрос направляется на сервис, определённый существующей логикой привязки сессий. Генерируемое условие маршрутизации прозрачно конфигурируется системой. Благодаря этому оптимизация производительности не опережает непрерывность пользовательской сессии.
Та же модель решения применима к HTTP- и TCP-сервисам
Fastest+ может работать как на этапе HTTP-запроса, так и на этапе инспекции содержимого TCP. Для TCP-сервисов окно инспекции, необходимое для решения, создаётся автоматически. Так трафик прикладного слоя и сервисы на основе TCP рассматриваются в одной модели управления. Оператору не приходится изучать разные логики продукта в зависимости от типа сервиса.
Клиенты без привязанной сессии динамически попадают на наиболее подходящий сервис
При использовании динамической привязки Fastest+ работает только для клиентов, у которых ещё нет зафиксированной сессии. Пока существующие сессии сохраняются, новые или свободные запросы распределяются по живым сигналам. Эта модель обеспечивает сбалансированный подход как с точки зрения непрерывности пользователя, так и мгновенного использования ёмкости. Особенно при интенсивном и колеблющемся трафике она помогает эффективнее использовать пул сервисов.
Когда здоровый кандидат не найден, трафик не проваливается в чёрную дыру
Если в процессе решения подходящий backend не найден, специальное решение маршрутизации остаётся пустым. В этом случае вступает в действие поведение балансировки нагрузки по умолчанию. Когда система не может выработать специальное решение маршрутизации, вместо отбрасывания трафика впустую она возвращается к известному поведению по умолчанию. Эта логика возврата снижает операционные риски.
Операционная глубина
Fastest+ Routing спроектирован не только как выбор алгоритма; он спроектирован вместе с поведением высокой доступности, видимости, перезагрузки и интеграции.
Модель регистрации действий
Логика решения загружается при старте сервиса и определяется как два отдельных действия — односигнальное и двухсигнальное. Односигнальное действие работает с одним входом решения, двухсигнальное — с двумя входами решения. Действия могут использоваться на этапах HTTP- и TCP-запросов.
Низкая стоимость решения
Статистика сервиса читается из таблицы в памяти; дополнительный сокет, чтение файла или внешний запрос не требуются. Процесс решения выполняет линейный обход по числу сервисов. Эта структура держит решение о маршрутизации близко к плоскости данных даже в пулах с большим числом backend.
Поведение при failover кластера
В двухузловой установке высокой доступности каждый узел независимо выполняет один и тот же алгоритм. Поскольку живые сигналы оцениваются локально на узле, после failover новый активный узел продолжает принимать решения по собственной наблюдаемой статистике. Зависимость от внешнего общего хранилища оценок не возникает.
Аудит и видимость
Выбранный backend хранится в переменной маршрутизации и может добавляться в формат лога. Благодаря этому можно ретроспективно анализировать, какой запрос на какой сервис был направлен. Операционные команды могут видеть решения о трафике не только как результат, но и как отслеживаемый след маршрутизации.
Поведение при перезагрузке
При мягкой перезагрузке контекст решения перезагружается, и алгоритм стартует с новым состоянием памяти. Поскольку прошлые наблюдения времени отклика не переносятся, при первых запросах решения опираются на текущие мгновенные данные. Возможность применять изменения конфигурации без перезапуска пула снижает операционные простои.
Границы WAAP и Layer 4
Когда слой WAAP блокирует запрос, Fastest+ не вызывается; так не выполняется лишний выбор сервиса. Fastest+ действителен только в пулах HTTP- и TCP-сервисов. В Layer 4-сервисах используются опции алгоритмов Layer 4 платформы.
В каких сценариях используется
Распределение трафика e-commerce в часы кампаний
В периоды интенсивных продаж множество backend одновременно принимают трафик. Fastest+, совместно оценивая такие сигналы, как время отклика и заполненность очереди, не даёт сервисам, кажущимся быстрыми, но с переполненной очередью, излишне выходить вперёд. Результат — более сбалансированное использование сервисов и более контролируемый пользовательский опыт.
Маршрутизация с учётом ошибок для финансовых API-сервисов
В слоях финансовых API недостаточно одного лишь быстрого отклика; поведение выдачи ошибок тоже должно быть частью решения. Fastest+ может выдвигать вперёд сервисы с низкой плотностью ошибок сервера, при равенстве учитывать мгновенную нагрузку сессий. Эта структура обеспечивает более осознанное распределение для критического API-трафика.
Выбор по нагрузке и скорости на медиа-edge-узлах
В трафике трансляций и медиа наименее нагруженный узел не всегда даёт лучший пользовательский опыт. Fastest+ комбинацией использованной ёмкости соединений и времени отклика совместно оценивает как текущее использование соединений, так и поведение отклика. Так между edge-сервисами выполняется более точное распределение трафика.
Интеллектуальное разделение в мультитенантных группах SaaS-сервисов
В мультитенантных структурах группа сервисов каждого тенанта может вести себя по-разному. Fastest+ с помощью сигналов вроде обрывов со стороны сервиса и времени установки соединения может предпочитать более стабильно работающие сервисы. Этот подход делает качество сервиса на уровне тенанта более управляемым.
Часто задаваемые вопросы
Какие сигналы можно выбрать как первичное и вторичное решение?
Если достаточно одного сигнала, могу ли я использовать Fastest+ в этом режиме?
Как Fastest+ обрабатывает сервис в режиме обслуживания?
Вступает ли Fastest+ в действие при активной привязке сессий?
Работает ли один и тот же алгоритм на HTTP- и TCP-сервисах?
Как влияет на качество решения мягкая перезагрузка?
Выведите ваше решение о балансировке нагрузки за рамки одной метрики
Двухступенчатое распределение трафика по живым сигналам, настраиваемое без написания кода. Проведём по живой установке на ваших собственных сервисах.