Балансировщики нагрузки Application и Network Load Balancer в Amazon Web Services

Облачная платформа Amazon Web Balancer (AWS) развивает предлагаемые сервисы. И теперь на ее серверах функционируют балансировщики нагрузки второго поколения ALB и NLB (Application Load Balancer и Network Load Balancer). Подобные системы применяют многие облачные провайдеры, например timeweb.cloud, обеспечивая рост отказоустойчивости, удобство масштабирования облаков и простоту управления нагрузкой на удаленные мощности.

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

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

Системы категории Load Balancing дают 2 основных преимущества:

1. Резервирование. Отдельно взятые физические серверы могут выйти из строя, их временно выводят из кластера на техническое обслуживание. Пользователи же этого не замечают за счет автоматического перенаправления на свободные работоспособные хосты. 
2. Масштабирование. Распределение входящего трафика даже на 2 сервера дает возможность получить практически удвоенную производительность. Мощности ЦОД позволяют брать в аренду столько хостов, сколько нужно для обеспечения задач даже крупных предприятий.

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

Есть ли различия у Application Load Balancer и Network Load Balancer?

Первое поколение балансировщиков Amazon Web Services остается активным в сети EC2 Classic. Отчасти из-за этого они получили название Classic Load Balancer. Более современные используются в остальной инфраструктуре поставщика облачных услуг. Решение ALB относят к 7-му уровню, а NLB – к 4-му. Такое разделение указывает на принадлежность к разным сетевым моделям OSI и отличающемуся принципу функционирования.

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

Соединение между клиентом и сервером происходит так:

1. Браузер или какое-то иное приложение инициирует создание HTTPS-запроса в виде текстового документа, содержащего информацию о том, что и в каком виде требуется принять с сервера.
2. Безопасность обеспечивается шифрованием веб-запроса по технологии TLS или SSL, чтобы сделать бессмысленным перехват передаваемых данных.
3. На транспортном уровне «полезная информация» сортируется, делится на отдельные пакеты в соответствии с содержимым (IP-адрес источника, приемника и т.д.).
4. Физический уровень — это та область, где двоичный код преобразуется в аналоговый сигнал для передачи по витой паре или оптоволокну. На принимающей стороне осуществляется обратный процесс.
5. Сервер при помощи ранее сгенерированного закрытого ключа для дешифрации запроса и для шифрации ответа передаваемой информации.

Все балансировщики, включая и AWS Load Balancer, принимают данные напрямую с физического уровня. Сервис 7-го уровня преобразует пакеты до прикладного уровня согласно модели сети OSI. И уже на этом шаге определяет, куда перенаправить его для обработки. Затем по логике подключается балансировщик 4-го уровня, которому требуется преобразовать пакеты данных до транспортного уровня, и только после этого появляется возможность принимать дальнейшие решения.

Особенности ALB и NLB

Применение балансировщиков обусловлено их техническими различиями. Их придется учитывать при проектировании и разработке приложений и интегрировать поддержку конкретного решения, возможности которого соответствуют задачам. Рассмотрим различия на примере обработки запросов, зашифрованных по технологии SSL/TLS, передачи данных без сквозного шифрования.

Работа с SSL/TLS

Применяется несколько методик реализации общения между клиентом и веб-сервером, хотя во всех случаях используются одни и те же протоколы SSL/TLS. Например, при использовании ALB, балансировщика нагрузки 7-го уровня, пользователь получает снижение нагрузки на серверные ресурсы. Потому что часть работы по шифрации и дешифрации сетевого трафика ложится на блок Application Load Balancer.

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

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

Функции Host-Based Routing и Path-Based Routing для HTTP-запросов

При работе без сквозного шифрования чаще обращаются к двум функциям балансировщика ALB – «маршрутизации на основе хоста» (Host-Based Routing) и «маршрутизации на основе пути» (Path-Based Routing). Их применение позволяет организовать сравнение запросов с настроенными шаблонами и распределение согласно соответствию. Такой прием широко используют, когда один облачный ресурс подключен по API к нескольким распределенным архитектурам.

Заключение

Балансировщик ALB больше заточен под веб-ресурсы, работающие по протоколу HTTP. Поэтому любые приложения, рассчитанные на применение собственных стандартов взаимодействия по сети, с ним несовместимы. Он просто не увидит передаваемые пакеты, отличные от HTTP. Поможет в ситуации NLB, способный транслировать данные в обе стороны «как есть». Он не трансформирует запросы и ответы, поэтому и считается более универсальным решением.