Как работают балансировщики нагрузки Application Load Balancer и Network Load Balancer в Amazon Web Services (AWS)
Application Load Balancer (ALB) и Network Load Balancer (NLB) — это балансировщики нагрузки второго поколения от коммерческой публичной облачной платформы Amazon Web Services (AWS). Понимание того, на что способны эти новые продукты и как они работают, позволит вам полноценно воспользоваться всеми преимуществами их новой функциональности.
Что такое балансировщик нагрузки?
Балансировщик нагрузки принимает входящий сетевой трафик от клиента и, основываясь на некоторых критериях этого трафика, отправляет эти сообщения на один из нескольких бэкенд-серверов (смотрите рисунок 1).
Рисунок 1. Балансировщики нагрузки распределяют входящий сетевой трафик от клиента между несколькими бэкенд-серверами.
Балансировщики нагрузки являются ключевым элементом для создания превосходных современных интернет-приложений, поскольку они обеспечат вашему приложению следующие преимущества:
- Резервирование. Сервер приложений может выйти из строя, но до тех пор, пока остается хотя бы один сервер приложений, балансировщик нагрузки может направлять трафик клиента на оставшиеся в рабочем состоянии сервера приложений.
- Масштабируемость. Так, например, два сервера, работающие за балансировщиком нагрузки, позволят обрабатывать вдвое больший трафик от клиентов. Другими словами, по мере увеличения вашего сетевого трафика, балансировщики нагрузки позволят вам легко добавлять все больше и больше бэкенд-серверов.
Отметим также, что при выводе на рынок новых продуктов второго поколения компания AWS не убрала балансировщик нагрузки прошлого поколения из продуктовой линейки, а переименовала его в Classic Load Balancer, и позиционирует его для работы с приложениями, которые были построены в сети EC2 Classic.
В чем разница между Application Load Balancer и Network Load Balancer?
В официальной документации облачной платформы AWS для Application Load Balancer и Network Load Balancer приложение ALB называется балансировщиком нагрузки «уровня 7», а NLB именуют балансировщиком нагрузки «уровня 4». Эти уровни, как можно легко догадаться, являются прямой отсылкой к сетевой модели OSI (детальнее проиллюстрировано на рисунке 2).
Рисунок 2. Application Load Balancer является балансировщиком нагрузки «уровня 7», а Network Load Balancer — балансировщиком нагрузки «уровня 4»
Модель OSI классифицирует различные операции, связанные с сетевым обменом данными между одной компьютерной программой на одном компьютере и другой компьютерной программой на другом компьютере. Полное объяснение сетевой модели OSI может занять целую книгу, но ниже приведенная иллюстрация (смотрите рисунок 3) может наглядно продемонстрировать движение сетевого трафика вниз и вверх по сетевой модели OSI. Эта общеизвестная информация поможет нам лучше понять, какие трансформации происходят с сетевым трафиком, когда он достигает балансировщика нагрузки.
Рисунок 3. Наглядная демонстрация движения сетевого трафика вниз и вверх по сетевой модели OSI
Если не вдаваться в детали, то соединение между клиентом и сервером происходит следующим образом:
- На прикладном уровне веб-браузер создает HTTP-запрос, представляющий собой небольшой текстовый документ, описывающий, какой ресурс браузер хочет получить с веб-сервера.
- Для обеспечения безопасного соединения между браузером и сервером веб-запрос шифруется с использованием криптографического протокола транспортного уровня TLS (или SSL). Этот процесс использует открытый ключ сервера для превращения полезной нагрузки (payload) HTTP в нечитаемый фрагмент зашифрованных двоичных данных.
- Несколькими уровнями ниже, на транспортном уровне, зашифрованная полезная нагрузка разделяется на пакеты TCP. Каждый пакет является частью полезной нагрузки HTTP, «обернутой» в метаданные, такие как исходный IP-адрес, откуда был отправлен TCP-пакет, и IP-адрес назначения, куда должен быть доставлен этот пакет.
- Физический уровень принимает необработанные цифровые единички и нули, которые являются TCP-пакетами в двоичном представлении, и превращает их в аналоговый сигнал, такой как электрический импульс на медном проводе, световой импульс в оптоволоконном кабеле или радиоволна в воздухе. На другом конце соединения другое устройство превращает этот аналоговый сигнал обратно в цифровые «1» и «0».
- Сетевой трафик начинает свой путь назад по сетевой модели OSI, когда единички и нули интерпретируются назад в ТСР-пакеты, которые затем снова собираются в исходную полезную нагрузку зашифрованных данных.
- Сервер использует свой закрытый ключ для дешифровки зашифрованной с помощью TLS (или SSL) полезной нагрузки обратно в исходный текстовый документ HTTP-запроса.
- Сервер использует незашифрованный HTTP-запрос, чтобы определить, какой ресурс необходимо отправить назад по сети.
Таким образом, знание того пути, которое сетевое соединение проходит через сеть, дает нам понимание, что балансировщик нагрузки — это нечто большее, чем просто пару линий между клиентом и балансировщиком нагрузки, а также между балансировщиком нагрузки и бэкенд-сервером, как это было показано на упрощенной схеме работы балансировщика нагрузки на рисунке 1. Эти линии скрывают сложное сетевое взаимодействия. В действительности, клиент отправляет свое сообщение вниз по стеку уровней сетевой модели OSI; когда это сообщение достигает балансировщика нагрузки, оно перемещается обратно вверх по стеку уровней; а затем, следуя далее по сетевому пути от балансировщика нагрузки к серверу назначения, сообщение проходит повторную трансформацию — опускаясь сразу к нижнему физическому уровню, а затем опять поднимаясь вверх к прикладному уровню.
Собственно, «уровень» балансировщика нагрузки непосредственно указывает на то, до какого уровня сетевой модели OSI должно быть трансформировано сетевое сообщение, полученное по сети на физическом уровне, чтобы балансировщик нагрузки смог его обработать и отправить назад по сети к выбранному им конечному месту назначения. То есть, сообщение после обработки балансировщиком нагрузки опять трансформируется вниз по стеку до физического уровня, а затем проходит обратное преобразование до прикладного уровня уже на стороне сервера.
Другими словами, для того, чтобы Application Load Balancer, который является балансировщиком нагрузки «уровня 7», смог прочитать HTTP-запрос и определить, куда этот запрос должен быть направлен, сетевое сообщение перед этим подвергнется трансформации до прикладного уровня сетевой модели OSI (детальнее смотрите на рисунке 4).
Рисунок 4. Для того чтобы балансировщик нагрузки «уровня 7» (Application Load Balancer) смог прочитать HTTP-запрос и определить, куда этот запрос должен быть направлен, сетевое сообщение должно перед этим быть трансформировано вплоть до прикладного уровня сетевой модели OSI
Аналогичным образом, балансировщик нагрузки «уровня 4» (в данном случае речь идет о Network Load Balancer) считывает заглавную информацию, содержащуюся в TCP-пакете, чтобы определить, куда направить это сообщение, но остальная информация, содержащаяся в этих пакетах, ему для принятия решения не нужна. Поэтому для Network Load Balancer требуется трансформация сетевого сообщения до транспортного уровня сетевой модели OSI (детальнее смотрите на рисунке 5).
Рисунок 5. Для принятия решения балансировщику нагрузки «уровня 4» (Network Load Balancer) требуется трансформация сетевого сообщения до транспортного уровня сетевой модели OSI
Основные особенности работы Application Load Balancer и Network Load Balancer
Уровень балансировщика нагрузки, который вы используете для своего приложения, оказывает непосредственное влияние на то, что вы можете реализовать при помощи этого балансировщика нагрузки, а также делает различные балансировщики нагрузки лучше подходящими под конкретные шаблоны проектирования приложений.
Работа с SSL/TLS
Существует несколько подходов к реализации шифрования SSL/TLS для сетевого трафика между клиентом и веб-сервером. К примеру, одним из распространенных применений для балансировщика нагрузки «уровня 7» (в данном случае речь идет об Application Load Balancer) является снижение использования ресурсов веб-сервера (смотрите рисунок 6). При таком подходе «тяжелая работа» по шифрованию и дешифрованию сетевого трафика ложится на балансировщик нагрузки. Таким образом, веб-серверу, который расположен за Application Load Balancer, необходимо будет обрабатывать только незашифрованные HTTP-запросы, так как эти запросы уже были расшифрованы балансировщиком нагрузки.
Рисунок 6. Подход к реализации шифрования SSL/TLS для сетевого трафика между клиентом и веб-сервером, при котором «тяжелая работа» по шифрованию и дешифрованию сетевого трафика ложится на балансировщик нагрузки Application Load Balancer.
Тем не менее, существуют приложения, для которых по регулятивным требованиям или соображениям безопасности необходимо в обязательном порядке осуществлять шифрование данных во время передачи сообщений по сети. Использование для таких приложений балансировщика нагрузки «уровня 7» только увеличит загрузку ваших ресурсов (смотрите рисунок 7). Application Load Balancer работает на прикладном уровне, поэтому он вынужден будет сразу расшифровать HTTP-запрос для проверки его заголовков, а затем снова зашифровать запрос, чтобы отправить его к месту назначения. После этого вашему веб-серверу придется расшифровать это сетевое сообщение снова, чтобы прочитать его. Это приведет не только к появлению дополнительной латентности за счет дублирования шифрования и дешифрования сетевого трафика, но и создаст дополнительные угрозы безопасности, так как в этом случае ваш закрытый ключ должен будет храниться как на уровне балансировщика нагрузки, так и на уровне веб-сервера.
Рисунок 7. Использование Application Load Balancer для приложений, которым требуется реализация сквозного шифрования, является нецелесообразным, так как это приводит к появлению дополнительной латентности и создает новые угрозы безопасности.
Таким образом, если вашему приложению требуется реализация сквозного шифрования, то более целесообразно будет использовать Network Load Balancer, который работает на транспортном уровне, а не балансировщик нагрузки «уровня 7» (смотрите рисунок 8). При таком дизайне приложения полезная нагрузка не будет расшифровываться на уровне балансировщика нагрузки. Вместо этого Network Load Balancer просто будет направляет TCP-пакеты на ваш веб-сервер. Это уменьшит латентность приложения, а также обеспечит его действительно сквозным шифрованием между клиентом и веб-сервером.
Рисунок 8. Использование Network Load Balancer для приложений, для которых требуется осуществление шифрования данных во время сетевой передачи, уменьшит латентность приложения, а также обеспечит его действительно сквозным шифрованием между клиентом и веб-сервером.
Функциональность Host-Based Routing и Path-Based Routing для HTTP-запросов
Если сквозное шифрование не требуется, то вы можете использовать одни из самых мощных функций балансировщика нагрузки Application Load Balancer: Host-Based Routing (Маршрутизация на основе хоста) и Path-Based Routing (Маршрутизация на основе пути). При такой конфигурации балансировщик нагрузки «уровня 7» использует правила, которые проверяют HTTP-заголовки входящего запроса. Если путь запроса совпадает с одним шаблоном, тогда Application Load Balancer направляет запрос на один компьютер, но если он совпадает с другим шаблоном, то этот запрос направляется на другой компьютер (смотрите рисунок 9). Это может быть чрезвычайно полезно для микросервисных или других распределенных архитектур, где у вас есть один общедоступный API, но несколько компонентов включают разные секции API.
Рисунок 9. Функции Host-Based Routing и Path-Based Routing — это один из самых мощных инструментариев в арсенале разработчика современных веб-приложений
Стоит отдельно подчеркнуть, что функциональность «Маршрутизации на основе хоста» и «Маршрутизация на основе пути» доступна только при использовании балансировщика нагрузки «уровня 7», так как для этой возможности необходима детальная информация из HTTP-запроса. Network Load Balancer оперирует только заголовками TCP-пакетов для своей работы, поэтому он не может читать заголовки HTTP-запросов, как это делает Application Load Balancer.
Протоколы прикладного уровня, отличные от HTTP
Не каждое веб-приложение построено на основе протокола HTTP. Например, многопользовательская игра в реальном времени может быть реализована на основе собственного упрощенного протокола прикладного уровня поверх TCP (или даже UDP) для связи между игровым клиентом и игровым сервером. Для такого взаимодействия Application Load Balancer не будет работать, поскольку этот балансировщик нагрузки ожидает, что на прикладном уровне весь сетевой трафик будет HTTP.
В данном случае стоит использовать Network Load Balancer, поскольку он может направлять TCP-пакеты от игрового клиента к игровому серверу. Кроме того, для игр в реальном времени не менее важным будет и то, что балансировщик нагрузки «уровня 4» также способствует уменьшению латентности приложения, так как сетевые сообщения не будут проходить всю трансформацию от физического уровня до прикладного и обратно, когда будут обрабатываться этим балансировщиком нагрузки.
Появились вопросы или нужна консультация? Обращайтесь!
Вечный параноик, Антон Кочуков.
См. также:
Авторизуйтесь для этого