Обзор Application Delivery Controller

Application Delivery Controller (ADC) — это программный балансировщик и контроллер доставки приложений. Он ставится в вашем контуре перед backend-сервисами и API: принимает входящий L4/L7-трафик, сопоставляет его с правилами обработки, применяет политики TLS, маршрутизации, доступности и безопасности, а затем передаёт запрос в подходящий upstream.

Проще говоря, ADC принимает запросы к приложениям, обрабатывает их по заданным правилам и отправляет на подходящие backend-серверы.

Продукт поставляется on-premises. При необходимости вместе с ним можно поставить другие решения Servicepipe: Web DDoS Protection или Web DDoS & Bot Protection.

Что умеет ADC

ADC закрывает основные сценарии доставки приложений и API:

  • Балансирует L4/L7-трафик. Работает с TCP/UDP и HTTP(S), распределяет запросы между backend-узлами и поддерживает разные методы балансировки.

  • Управляет TLS и сертификатами. Выбирает сертификат по SNI, терминирует или проксирует TLS, настраивает TLS до upstream и поддерживает SSL-профили с cipher suites.

  • Проверяет доступность backend. Выполняет активные и пассивные health checks, исключает недоступные узлы из балансировки и возвращает их в работу после восстановления.

  • Поддерживает отказоустойчивые схемы. Работает в режимах Active/Active и Active/Standby, а также может использовать RHI для прекращения BGP-анонса VIP вашего сервиса на время недоступности ваших upstream.

  • Маршрутизирует HTTP-трафик, опираясь на заданные условия. В качестве условий можно указать URI, Host, HTTP-метод, IP-адрес клиента, заголовки, cookie, query-параметры и другие признаки запроса.

  • Изменяет HTTP-запросы и ответы. Может переписывать URI, менять заголовки, возвращать редиректы, преобразовывать тело запроса или ответа.

  • Ограничивает нагрузку на backend. Устанавливает лимиты по IP, потребителю (Consumer), маршруту (Route), количеству активных запросов, числу HTTP-заголовков, размеру request line и размеру отдельных заголовков. Запросы сверх лимита блокируются.

  • Пишет логи и помогает в диагностике. Отправляет события в Syslog и Kafka, поддерживает SNMP, а для сетевой диагностики можно использовать tcpdump и анализ TLS-трафика.

Подробнее про эти возможности читайте в разделе Функционал ADC.

Где находится ADC в инфраструктуре

ADC размещается перед backend-приложениями, API или внутренними сервисами. Типовая схема выглядит так:

  1. ADC анонсирует публичный IP сервиса по протоколам динамической маршрутизации. Например, через BGP.

  2. Клиент отправляет запрос к публичному адресу сервиса.

  3. Запрос приходит на ADC. ADC принимает соединение на L4 или L7.

    Для HTTPS-сценариев ADC выбирает сертификат по SNI и терминирует или проксирует TLS.

  4. ADC сопоставляет запрос с маршрутом, затем обрабатывает запрос по заданным вами политикам, выбирает upstream и передаёт туда.

    Пример настройки: ADC проверяет запрос на соответствие лимитам (rate limits), затем добавляет служебный HTTP-заголовок и только после этого отправляет в нужный upstream.

  5. Запрос уходит на один из backend-узлов.

  6. Backend возвращает ответ на ADC.

  7. ADC возвращает ответ клиенту.

    В зависимости от настроенных политик ADC может просто передать ответ backend, а может сначала изменить его — например, заменить технический ответ backend на публичный JSON в формате вашего API.

  8. ADC записывает события в настроенные системы логирования и диагностики.

В результате backend-сервисы не принимают внешний трафик напрямую. ADC становится точкой, через которую вы управляете доступностью приложений, маршрутизацией трафика, TLS, логированием и прикладными политиками.

Как ADC обрабатывает трафик

ADC может обрабатывать трафик в двух режимах:

  • HTTP(S) — работает на уровне приложения. ADC разбирает HTTP-запрос и может выбирать маршрут по URI, Host, HTTP-методу, IP-адресу клиента, переменным и другим условиям. В этом режиме можно подключать HTTP-плагины, изменять запросы и ответы, настраивать лимиты, таймауты и upstream, в который нужно передать запрос.

  • TCP и UDP — работает в stream-режиме на транспортном уровне. ADC принимает TCP- или UDP-соединение и передаёт трафик на нужный upstream без разбора HTTP-запроса.

Режим работы вы задаёте сами в конфигурационном файле conf/config.yaml с помощью параметра proxy_mode.

Функционал ADC

Балансировка L4/L7

ADC может балансировать трафик на разных уровнях:

  • На L7 ADC разбирает HTTP-запрос и понимает его параметры: метод, URI, Host, заголовки, cookie, query string и другие признаки. Опираясь на них, вы можете гибко управлять маршрутизацией. Пример: можно отправлять запросы к /api/orders в upstream заказов, а запросы к /api/catalog — в upstream каталога.

  • На L4 ADC работает с TCP/UDP-трафиком в stream-режиме. Он не разбирает HTTP или другой прикладной протокол, а проксирует соединение по транспортным признакам: адресу и порту сервера, адресу клиента и SNI для TLS-соединений.

Вы настраиваете, в какие upstream отправлять разные типы трафика. Если в upstream входит несколько серверов, вы можете выбрать метод балансировки:

  • Round Robin — распределяет запросы между узлами по кругу с учётом весов.

  • CHash — выбирает узел по хэшу заданного ключа, например header, cookie, consumer или переменной.

  • Least Conn — отправляет запрос на узел с наименьшим числом активных соединений.

  • EWMA — учитывает задержку backend и отдаёт предпочтение узлам с меньшим временем ответа.

  • Weighted Source Hashing — привязывает запросы к backend по хэшу источника с учётом весов.

Если нужно сохранять привязку клиента к backend, можно настроить персистентность. ADC поддерживает привязку по Source IP, HTTP Cookie, HTTP-заголовкам и SSL ID сессии.

TLS и сертификаты

ADC может быть центральной TLS-точкой перед приложениями.

Для входящих HTTPS-соединений вы добавляете серверный сертификат, указываете SNI и выбираете допустимые версии TLS. Когда клиент устанавливает TLS-соединение, ADC смотрит на SNI и выбирает подходящий сертификат для домена.

После этого возможны разные схемы:

  • TLS termination — ADC завершает TLS-соединение от клиента и дальше отправляет запрос к upstream по нужной схеме.

  • TLS bridging — ADC расшифровывает трафик, применяет политики, а затем снова устанавливает HTTPS-соединение до upstream.

  • TLS до upstream — ADC подключается к backend по HTTPS и при необходимости проверяет сертификат upstream.

Если upstream требует от ADC клиентский сертификат, его предъявление можно настроить в маршруте.

Отдельно вы можете управлять cipher suites. Для TLS до версии 1.2 используется синтаксис OpenSSL, а для TLS 1.3 — настройка через ssl_conf_command.

Health checks и отказоустойчивость

Чтобы не отправлять трафик на недоступные backend-узлы, можно настроить health checks. Доступны два типа проверок:

  • Активные — ADC сам периодически отправляет служебные запросы на backend. Проверка может идти по HTTP, HTTPS или TCP. Если узел несколько раз подряд не отвечает или отвечает ошибками, ADC помечает его как недоступный и исключает из балансировки.

  • Пассивные — ADC анализирует реальные ответы backend на пользовательский трафик. Если на реальных запросах появляются ошибки или таймауты, узел тоже может быть временно исключён из распределения нагрузки.

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

Для отказоустойчивости самого ADC доступны режимы Active/Active и Active/Standby. В Active/Active несколько узлов могут одновременно обрабатывать трафик. В Active/Standby один узел активен, а второй подключается к работе, если первый дал сбой.

Маршрутизация, BGP и RHI

ADC работает в сетевом контуре, поэтому для него важна не только балансировка внутри продукта, но и маршрутизация на уровне инфраструктуры.

Для статической маршрутизации вы можете настраивать маршруты в ОС сервера. Временные изменения удобно проверять через ip route, а постоянные маршруты задавать через nmcli и профили NetworkManager.

Для динамической маршрутизации используется BGP через BIRD. BIRD устанавливает BGP-сессии с соседями, принимает и анонсирует маршруты, применяет import/export-фильтры и синхронизирует маршруты с таблицей ядра.

RHI управляет BGP-анонсом VIP, основываясь на состоянии upstream. Если связанные с VIP backend-узлы недоступны, RHI снимает VIP с интерфейса, и BIRD перестаёт анонсировать этот адрес. Когда backend восстанавливаются, RHI возвращает VIP на интерфейс, и анонс снова появляется. Это полезно, если сервис работает в нескольких дата-центрах: трафик не идёт туда, где за VIP сейчас нет живых backend.

Программируемая обработка HTTP-трафика

ADC может не только выбрать backend, но и изменить HTTP-запрос или ответ.

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

Основные сценарии:

  • Переписать запрос перед upstream. Через плагин proxy-rewrite вы можете изменить URI, HTTP-метод, Host или заголовки запроса. Например, клиент обращается к /api/v1/products/SKU-1001, а backend получает /internal/items/SKU-1001.

  • Изменить ответ перед клиентом. Через плагин response-rewrite вы можете добавить, удалить или перезаписать response headers, заменить тело ответа целиком или изменить его фрагменты по регулярному выражению.

  • Вернуть редирект. Благодаря плагину redirect, ADC может не отправлять запрос в upstream, а сразу вернуть клиенту 301, 302, 307 или другой код редиректа с заголовком Location.

  • Преобразовать payload по шаблону. Через плагин body-transformer ADC может разобрать JSON, XML, form-urlencoded, plain или multipart body и собрать по шаблону новое тело запроса или ответа. Это полезно, например, когда публичный API и внутренний backend используют разные форматы.

  • Описать условную логику. Через плагин logic-flow вы можете задать гибкие if/elseif/else-правила. Пример правила: если метод GET, URI начинается с /api/orders и есть заголовок Authorization, отправить запрос в orders_pool; если заголовка нет — вернуть 401.

Так ADC становится не просто балансировщиком, а точкой, где можно управлять поведением HTTP-трафика без изменения backend-приложений.

Лимиты и защита backend от перегрузки

ADC может ограничивать трафик до backend, чтобы приложение не получало больше запросов, чем способно обработать. Вы можете настроить лимиты на:

  • Частоту запросов в секунду — через плагин limit-req. Подходит, если нужно сгладить всплески и не пропускать резкие пики в backend.

  • Число запросов за временной период (например, 100 запросов в минуту или 10 000 запросов в день) — через плагин limit-count. Подходит для квот по Consumer, IP, Route или другому признаку.

  • Число одновременных активных запросов — через плагин limit-conn. Полезно для долгих операций, загрузки файлов, streaming-ответов, long polling, медленных клиентов и WebSocket.

  • Количество HTTP-заголовков в запросе — через плагин header-count-limit. Если заголовков больше, чем разрешено, ADC отклоняет запрос.

  • Размер request line и отдельных HTTP-заголовков — через настройки client_header_buffer_size и large_client_header_buffers на уровне NGINX.

Эти механизмы помогают защищать backend от перегрузки, ошибок клиентов и части злоупотреблений на уровне HTTP.

Логирование, диагностика и наблюдаемость

ADC может отправлять события во внешние системы логирования.

Для Syslog используется плагин syslog. Для Kafka — kafka-logger. В обоих случаях вы можете настроить формат логов: например, передавать метод, URI, статус ответа, IP клиента, upstream, задержки, route ID и другие поля.

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

Для мониторинга системного состояния используется SNMP. В документации описана настройка SNMP v2c и SNMP v3. Для защищённого мониторинга лучше использовать SNMP v3: он поддерживает аутентификацию, шифрование и контроль целостности.

Для диагностики трафика доступны сетевые инструменты:

  • tcpdump — захват пакетов и запись PCAP для анализа в Wireshark или других инструментах;

  • ecapture — анализ TLS-трафика через eBPF и получение ключевого материала в формате SSLKEYLOGFILE;

  • tshark и Wireshark — разбор захваченного трафика, включая HTTP и HTTP/2 после расшифровки.

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

Управление ADC

ADC можно администрировать несколькими способами:

  • GUI и API — для управления сущностями балансировщика: сервисами, маршрутами, stream-маршрутами, upstream, сертификатами, секретами, глобальными правилами, плагинами и proto-файлами.

  • SSH — для доступа к консоли сервера. Через SSH вы настраиваете сетевые параметры, системные службы, журналы, маршрутизацию, BGP, sysctl и диагностику.

  • IPMI/BMC — для аппаратного управления физическим сервером: питание, консоль, датчики, события оборудования и виртуальные носители.

IPMI/BMC доступен только при физической установке ADC. При виртуальной установке этот интерфейс не используется.

Также в системном контуре используется NTP через chrony, чтобы синхронизировать время. Это важно для журналов, диагностики, TLS и корректного сопоставления событий.

Совместная поставка с другими продуктами Servicepipe

ADC отвечает за доставку приложений: балансировку, маршрутизацию, TLS, health checks, обработку HTTP-трафика, лимиты, логи и диагностику.

Если нужно расширить защитный контур, вместе с ADC можно поставить другие решения Servicepipe:

  • Web DDoS Protection — для защиты от сетевых и прикладных DDoS-атак;

  • Web DDoS & Bot Protection — для выявления и блокировки автоматизированного трафика.

В такой поставке ADC управляет доставкой приложений, а защитные продукты добавляют фильтрацию DDoS-атак, ботов и прикладных атак в одном контуре.

Установить ADC

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