Если вы планируете установить балансировщик трафика (систему, которая распределяет входящие запросы между серверами), важно внимательно проанализировать бизнес-процессы и собственные требования, чтобы выбрать оптимальное решение.
В каких сценариях стоит выбирать программный балансировщик
Программные решения работают лучше, чем аппаратные, в следующих случаях.
Нужна максимальная гибкость. Если вы часто меняете версии сервисов, добавляете новые микросервисы (небольшие самостоятельные компоненты приложения) или переписываете маршруты, лучше использовать программные балансировщики трафика. Особенность таких решений — гибкость. Разработчики могут быстро изменить настройки программного обеспечения и при необходимости «откатить» их.
При этом облачные решения часто не имеют ограничений по производительности. Вы можете быстро подключить новые серверы и повысить пропускную способность балансировщика.
Если же использовать аппаратные решения, то масштабирование станет целым проектом. Потребуется купить оборудование, подключить его и правильно настроить. Это может занять недели и даже месяцы.
Эта проблема особенно остра, когда команды проводят эксперименты. Поэтому ИТ-компаниям, которые часто тестируют разные решения, стоит использовать именно программные решения. Программные балансировщики позволяют быстро запустить и отключить отдельную тестовую среду без заимствования мощностей из основной системы.
Используются микросервисная архитектура и контейнеризация. Программный балансировщик интегрируется с API (набором правил, по которым программы обмениваются данными) платформы оркестрации, например Kubernetes. Платформа оркестрации — это система, которая автоматически управляет приложениями в контейнерах. Контейнер — это изолированная среда, в которой приложение запускается вместе с необходимыми компонентами. Благодаря такой интеграции балансировщик автоматически получает информацию об изменении состава сервисов и экземпляров приложений (отдельных запущенных копий). Это упрощает работу в средах, использующих микросервисную архитектуру и программный слой для управления обменом данными между микросервисами (service mesh).
Благодаря динамическому обновлению конфигурации (настроек) новые или удаленные экземпляры начинают учитываться без перезагрузки балансировщика и без прерывания активных соединений. В отдельных сценариях балансировщик может направлять трафик непосредственно к самим приложениям, сокращая количество промежуточных сетевых переходов. Это способствует уменьшению задержек и более эффективному использованию ресурсов в высоконагруженных микросервисных средах.
Требуется интеграция с DevOps и CI/CD. DevOps — подход, в рамках которого разработчики и специалисты по эксплуатации вместе отвечают за выпуск и стабильную работу ПО. CI/CD — автоматизированный процесс проверки, сборки и выпуска изменений. Современная ИТ-инфраструктура строится по принципу «инфраструктура как код» (IaaC): ее настройки описывают в файлах так же, как программный код. Это означает, что все настройки — от сетевых политик до правил маршрутизации — хранятся в репозиториях (системах хранения файлов с историей изменений), проходят код-ревью (проверку другими специалистами) и применяются автоматически через заданные последовательности операций (пайплайны).
Программные балансировщики хорошо интегрируются в такую инфраструктуру благодаря двум особенностям.
1. Управление через API. Большинство современных программных балансировщиков предоставляют интерфейс для управления с помощью стандартных веб-запросов (REST API) и могут управляться с помощью декларативных конфигураций (описаний требуемого состояния системы) или инструментов автоматизации, использующих текстовые форматы YAML и JSON для записи структурированных настроек.
Хранить конфигурацию балансировщика можно в Git (системе контроля версий, которая сохраняет историю изменений) вместе с кодом приложений.
Получать информацию об изменениях можно через API платформы после выполнения команд kubectl apply (которая применяет заданные настройки в Kubernetes — системе управления контейнерными приложениями) или terraform apply (которая применяет описанную конфигурацию инфраструктуры в Terraform).
«Откатывать» изменения можно за секунды с помощью команды git revert, которая создает новое изменение, отменяющее результат выбранной предыдущей правки.
2. Интеграция с Terraform и Ansible. Terraform — инструмент, с помощью которого специалист описывает требуемое состояние инфраструктуры балансировщика: виртуальные сервисы (точки, на которые поступает трафик), сетевые интерфейсы (средства подключения к сети), цифровые сертификаты, пулы серверов (группы серверов, между которыми распределяется нагрузка) и другие объекты. При выполнении команды terraform apply инструмент сравнивает описание с фактической конфигурацией и приводит ее к заданному состоянию. Это снижает риск дрейфа конфигурации, т.е. незапланированных расхождений между требуемыми и фактическими настройками.
Ansible — инструмент, который автоматизирует повторяющиеся операции по обслуживанию инфраструктуры: обновление настроек, изменение правил маршрутизации, управление цифровыми сертификатами, настройку параметров безопасности и выполнение массовых изменений.
В контейнерных средах (например, Kubernetes) балансировщик может автоматически получать информацию об изменении состава сервисов через API платформы оркестрации, благодаря чему новые экземпляры приложений начинают обслуживаться без ручного вмешательства.
В результате балансировщик становится частью единого CI/CD-конвейера и поддерживает полностью автоматизированный процесс развертывания и сопровождения приложений.
Важно быстро масштабировать систему. Если нагрузка на сервисы может существенно меняться, то аппаратный балансировщик не подойдет. Если трафик резко увеличится, то оборудование станет бутылочным горлышком в системе. Оно перестанет справляться со своей задачей, из-за чего инфраструктура будет работать нестабильно, а безопасность окажется под угрозой.
Этого недостатка нет у программных решений. Обычно пользователи могут буквально за несколько кликов запустить дополнительные копии программного балансировщика перед запланированным скачком нагрузки.
Ограничен бюджет. Аппаратные решения, особенно импортные, стоят дорого. Капитальные затраты на покупку балансировщика трафика начинаются от 5–8 млн руб., а решения для крупного бизнеса продаются и за 50–80 млн руб. Такие расходы в условиях текущего кризиса могут стать проблемой для бизнеса.
Программные балансировщики можно разворачивать на стандартных серверах, а также на облачных платформах. Благодаря этому можно избежать крупных инвестиций в специализированное оборудование.
Используется преимущественно облачная инфраструктура. Современный бизнес может вообще не создавать собственные серверные и полностью полагаться на сторонние решения. Если вы используете облачную инфраструктуру в частном или публичном облаке, то покупка аппаратных балансировщиков не имеет смысла.
В таком случае программные решения — лучший вариант. Вы сможете быстро развернуть балансировщик в виртуальной среде и настроить интеграцию с другими модулями системы.
Когда лучше использовать аппаратный балансировщик
Аппаратные балансировщики используются в трех сценариях.
Требуется гарантированная высокая производительность. Аппаратные балансировщики предназначены для обработки больших объемов сетевого трафика с предсказуемой производительностью. Благодаря использованию тех или иных специализированных аппаратных ускорителей — ASIC (микросхем для конкретной задачи), FPGA (перенастраиваемых программируемых микросхем), сетевых процессоров или SSL-акселераторов (модулей, ускоряющих шифрование и дешифрование трафика), выбираемых в зависимости от платформы, — они эффективно выполняют задачи балансировки, обработки защищенных соединений по протоколу TLS и сетевой фильтрации при высокой нагрузке.
Такие решения способны обеспечивать пропускную способность от десятков до сотен гигабит в секунду, поддерживать миллионы одновременных соединений и очень высокую скорость установления новых соединений. Кроме того, специализированная аппаратная архитектура позволяет минимизировать задержки обработки трафика и обеспечить стабильную производительность даже при пиковых нагрузках.
Используются ресурсоемкие функции обработки сетевых соединений и веб-трафика (уровни L4–L7) при отсутствии собственных ресурсов. Программные балансировщики умеют выполнять SSL/TLS-терминацию (принимать защищенное соединение и расшифровывать его для дальнейшей обработки), анализировать трафик и фильтровать угрозы, но каждое такое действие «съедает» процессорное время ваших серверов. Если инфраструктура уже испытывает высокую нагрузку, выполнение этих функций может потребовать выделения дополнительных вычислительных ресурсов или отдельных серверов.
Аппаратный балансировщик переносит выполнение ресурсоемких операций на специализированные аппаратные ускорители. В зависимости от модели это может включать SSL/TLS-терминацию, обработку веб-трафика уровня L7, а также веб-защиту с помощью межсетевого экрана веб-приложений (WAF) и противодействие DDoS-атакам — массовому потоку запросов или данных, цель которого перегрузить сервис.
Такой подход позволяет разгрузить вычислительные ресурсы серверов общего назначения и обеспечить стабильную производительность даже при высокой нагрузке.
Есть требования к использованию выделенного оборудования. В некоторых секторах (госсектор, банки, объекты критической информационной инфраструктуры) решение принимается не на основе производительности, а исходя из нормативных ограничений. В этой сфере программные балансировщики и облачные решения не подходят.
Нередко политики безопасности прямо запрещают размещение критических сервисов на стандартном оборудовании. Требуется специализированное устройство с сертификацией ФСТЭК России или ФСБ России, гарантирующее отсутствие недекларированных возможностей (скрытых функций, не указанных разработчиком) и защищенную обработку данных.
Кроме того, законодательство (например, Федеральный закон от 07.04.2025 № 58-ФЗ) обязывает бизнес в определенных секторах использовать решения только из реестра отечественного ПО или реестра российской радиоэлектронной продукции, что автоматически исключает большинство программных решений.
Рекомендации
Кратко резюмируем рекомендации об использовании того или иного типа балансировщика в зависимости от требований бизнеса.
Типичные сценарии
Прежде чем углубляться в технические характеристики программных и аппаратных решений, стоит посмотреть на задачу с точки зрения конкретного сценария работы бизнеса. Опыт показывает, что для 80% проектов выбор балансировщика очевиден.
* * *
Выбор между программным и аппаратным балансировщиком — это не битва технологий, а поиск компромисса между гибкостью и производительностью. Для 90% современных проектов, особенно работающих в облаках или на контейнерных платформах, программное решение — оптимальное начало. Оно легко автоматизируется и может масштабироваться вместе с бизнесом. Аппаратные балансировщики остаются нишевым решением для высоконагруженной инфраструктуры и КИИ.
Алексей Лобачев, эксперт в области ИТ-трансформации и основатель компании «5А»
