Скорее всего, передовой облачный провайдер 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 облачных провайдеров позволяет обходить многие ограничения их же сервисов.
