Pull to refresh
EPAM
Компания для карьерного и профессионального роста

Чем проще, тем лучше, или когда ELB не нужен

EPAM corporate blog Amazon Web Services *
Скорее всего, передовой облачный провайдер Amazon Web Services в первую очередь ассоциируется с EC2 (виртуальные инстансы) и ELB (балансировщик). Типичная схема разворачивания web-сервиса — EC2 инстансы за балансировщиком (Elastic Load Balancer).Преимуществ у такого подхода очень много, в частности, у нас «из коробки» есть проверка состояния нод, мониторинг (количество запросов, логи), легко настраивамое авто-масштабирование и т.д. Но далеко не всегда ELB — лучший выбор для распределения нагрузки, а иногда и вовсе не подходящий инструмент.

Под катом я покажу два примера использования Route 53 вместо Elastic Load Balancer-а: первый — из опыта компании Loggly, воторой — из моего личного.

Loggly


Loggly — сервис централизованного сбора и анализа логов. Инфраструктура развернута в облаке AWS. Основную работу по сбору логов выполняют так называемые коллекторы — приложения, написанные на C++, котороые принимают информацию от клиентов по TCP, UDP, HTTP, HTTPS. Требования к коллекторам очень серьёзные: работать максимально быстро и не терять ни одного пакета! Другими словами, приложение должно собирать все логи, не смотря на интесивность входящего трафика. Естественно, коллекторы должны горизонтально масштабироваться, и трафик между ними должен распределяться равномерно.

Первый блин комом


Ребята из Loggly для балансировки сначала решили использовать ELB.



Первая проблема, с которой они столкнулись, была производительность. При десятках тысяч событий в секунду задержка на балансировщике начала расти, что было несопоставимо с назначением коллекторов. Далее проблемы посыпались, как спелые яблоки: невозможно пересылать трафик на порт 514, не поддерживается UDP, ну и известная проблема «холодного баласировщика» Pre-Warming the Load Balancer — проявляется при резком возрастании нагрузки.

Замена на Route53


Далее начали искать замену ELB. Оказалось, что простой DNS round robin полностью устраивает, и Route53 решает задачу распределения трафика, исключая проблемы с ELB. Без промежуточного звена в виде балансировщика задержка уменьшилась, так как трафик начал идти напрямую от клиентов к инстансам с коллекторами. Никакого дополнительного «разогрева» не требуется при резких увеличениях объёмов сообщений. Также Route53 проверяет «здоровье» коллекторов и повышает доступность системы в целом, потери информации сводятся к нулю.

Вывод


Для высоконагруженных сервисов с резкими флуктуациями количества запросов, использующих различные протоколы и порты, лучше даже не пытаться использовать ELB: рано или поздно столкнётесь с ограничениями и проблемами.

Percona Cluster


В нашей инфраструктуре основное хранилище данных — это Percona Cluster. Множество приложений используют его. Основными требованиями были отказоустойчивость, производительность и минимальные усилия по поддержке его. Хотелось один раз сделать и забыть.

Со стороны приложения решили использовать постоянное для каждого окружения (dev, test, live) DNS имя для общения с кластером. Тем самым облегчили жизнь разрабочикам и себе по конфигурации и сборке приложений.

ELB не подошёл


Балансировщик нам не подошёл примерно по тем же причинам, что и в случае Loggly. Сразу подумали о HA Proxy в качестве балансировки нагрузки, тем более, что Percona советуют использовать именно такое решение. Но получать ещё одну точку отказа в виде HA Proxy сервера не хотелось. Кроме того, дополнительные расходы на содержание и администрирование никому не нужны.

Route53 + Percona


Когда обратили внимание на этот сервис в качестве распределителя нагрузки и проверки состояния серверов кластера, казалось что в несколько кликов получим нужный результат. Но, после детального изучения документации, нашли фундаментальное ограничение, которое рубило на корню всю архитектуру окружения и кластера в нем. Дело в том, что Percona Cluster, как и большинство остальных серверов, расположены в приватных подсетях, а Route 53 может проверять только публичные адреса!

Огорчение длилось не долго — возникла новая идея: проверку состояния сделать самим и использовать Route 53 API для обновления DNS записи.

Итоговое решение


На проекте повсеместно для мониторинга системных сервисов используется Monit. Его и настроили для следующих автоматических действий:
  • Проверка порта MySQL
  • Изменение DNS записи при отсутствии ответа
  • Отсылка нотификации
  • Попытка перезапустить сервис

Получаем такое поведение при падении одной из нод кластера: служба поддержки получает уведомление, DNS запись изменяется так, что больная нода не получает запросов, monitd пытается перезапустить сервис, при неудаче — опять нотификация. Приложение продолжает работать как ни в чем не бывало, даже не подозревая о проблемах.

Заключение


Два случая, описанные в статье, показывают, что Route 53 иногда для распределения нагрузки и обеспечения отказоустойчивости подходит гораздо лучше, чем ELB. В то же время, API облачных провайдеров позволяет обходить многие ограничения их же сервисов.
Tags:
Hubs:
Total votes 10: ↑9 and ↓1 +8
Views 6K
Comments Comments 14

Information

Founded
1993
Location
США
Website
www.epam.com
Employees
over 10,000 employees
Registered
Representative
vesyolkinaolga