Использование haproxy/iptables+etcd+confd для автоматического service...

Использование haproxy/iptables + etcd + confd для автоматического service-discovering’а в переменчивых сетях Сергей Пузырёв

Service-oriented architecture 1.  Приложение состоит из множества слабо связанных

сервисов, которые общаются друг с другом с использованием четко определённого API.

2.  Сервисы ничего не знают о клиентах, их задача – оказывать сервис.

3.  Клиента не волнует, каким образом работает сервис. 4.  Сервисы используют другие сервисы.

Service-oriented architecture Что такое сервис? 1.  У сервиса есть интерфейс – API. 2.  Сервис имеет точку входа (endpoint) – обычно пара

IP:port. 3.  Сервис может пользоваться другими сервисами. В этом

случае он должен быть правильно сконфигурирован.

Service-oriented architecture Пример сервиса - memcached: 1.  API: стандартный протокол memcached. 2.  Endpoint: например, 10.0.0.7:11211. 3.  Сервисы, которыми пользуется memcached, отсутствуют.

Client Memcached

Service-oriented architecture Пример сервиса - mcrouter: (github.com/facebook/mcrouter) 1.  API: стандартный протокол memcached. 2.  Endpoint: например, 10.0.0.6:11211. 3.  Mcrouter пользуется двумя сервис memcached. Endpoint

сервиса memcached забит в конфиг mcrouter.

Client Mcrouter

Memcached Memcached

Service-oriented architecture Несложное PHP-приложение:

Php-fpm

Memcached

MySQL slave

Nginx

Php-fpm

MySQL master Memcached

Mcrouter

Static storage

16 отношений client<->service

Service-oriented architecture Сложное приложение (мопед не мой):

Как связывать сервисы друг с другом? Дешево и сердито: хардкод endpoint’ов в конфиги. Плюсы: 1.  Очень быстрый старт. 2.  Просто, нужен только vim. 3.  Ничего не ломается само. Минусы: 1.  Не работает в большом проекте. 2.  Требуется вручную поддерживать документацию. 3.  Сложно вносить массовые изменения, подключать

новые инстансы сервисов, мигрировать сервисы.

Как связывать сервисы друг с другом? Дешево и сердито: DNS + хардкод. Плюсы: 1.  Лишь немного сложнее хардкода IP-адресов. 2.  Почти так же просто, нужен только vim и DNS-сервер. 3.  Проще вносить массовые изменения. Минусы: 1.  По прежнему не работает в большом проекте. 2.  Так же требуется вручную поддерживать документацию. 3.  Сложно подключать новые инстансы сервисов. 4.  Асинхронность внесения изменений, лаги. 5.  Софт часто не перерезолвливает записи.

Появляются сотни сервисов. Потом тысячи.

Как связывать сервисы друг с другом? Системы управления конфигурацией (Puppet, SaltStack, etc.). Плюсы: 1.  При правильной организации проще вносить

изменения. 2.  Один инструмент для всего. Минусы: 1.  Медленно! 2.  При неправильной организации вносить изменения

становится очень сложно. 3.  Неактуальная документация продолжает существовать.

Как связывать сервисы друг с другом? Пусть роботы всё делают за нас! Системы service-discovering’а.

Service-discovering Что это такое? Система обнаружения сервисов (СОС) – специальный сервис, в котором другие сервисы могут делать две вещи: 1.  Регистрироваться (записывать свой endpoint). 2.  Находить другие сервисы (читать предварительно

зарегистрированные endpoint’ы других сервисов).

Часто системы обнаружения сервисов предоставляют также сервис распределённых блокировок. Примеры: Zookeeper, etcd, consul, SkyDNS, etc.

Service-discovering Etcd: что это такое и как с этим жить? github.com/coreos/etcd Etcd - высоконадёжное распределенное хранилище параметров конфигурации, задаваемых в форме key->value. Etcd также можно использовать как систему распределенных блокировок.

Service-discovering Confd: что это такое и зачем оно нужно? www.confd.io Confd - легковесная система конфигурации, специально созданная для отслеживания данных в etcd, шаблонизирования конфигов и перезапуска приложений при изменении данных в etcd. NB: нередко вместо Confd можно использовать скрипт на bash, наподобие while true ; do smth ; done .

Service-discovering

Etcd

Client

Confd

Announcer

Mcrouter

Announcer

Memcached

Announcer

Memcached

Confd

Как связывать сервисы друг с другом? Системы service-discovering’а: Плюсы: 1.  Очень быстрое внесение изменений. 2.  Не требуется документировать, что где работает и как

должно быть сконфигурировано. Минусы: 1.  Сложно. 2.  Страшно – “а вдруг развалится?”. 3.  Внешние сущности в виде confd и announcer’а. В идеале

нужно обучать сервисы общаться с etcd напрямую.

Как связывать сервисы друг с другом? Что мы хотели? 1.  Приложения не должны постоянно перезапускаться (до

свидания, confd). 2.  Мы не хотели привязывать тонны legacy-кода наших

приложений к СОС. 3.  Облегчить миграцию сервисов на новые endpoint’ы, не

требующую переконфигурации тысяч других сервисов (ради чего и затевалось).

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

Как связывать сервисы друг с другом?

Как связывать сервисы друг с другом? Трудно связать сервисы друг с другом? Давайте инкапсулируем связь между сервисами в отдельный сервис!

Etcd + iptables/HAproxy + confd Было так:

Etcd

Client

Confd

Announcer

Mcrouter

Announcer

Memcached

Announcer

Memcached

Confd

Etcd + iptables/HAproxy + confd А стало так:

Etcd

Client

Confd

Announcer

Mcrouter

Announcer

Memcached

Announcer

Memcached

Confd

HAProxy

Etcd + iptables/HAproxy + confd Почему так? 1.  Некоторые приложения трудно перезапускать. 2.  Постоянно писать шаблоны к разному софту утомляет. 3.  Бесплатная статистика от HAproxy. 4.  В простых кейсах получаем еще и бесплатную

балансировку.

Что плохо? 1. HAproxy не умеет в UDP.

Etcd + iptables/HAproxy + confd А iptables DNAT умеет:

Confd Confd

Etcd

iptables DNAT

iptables DNAT

Client statsd Carbon (Graphite)

Результат 1.  Миграции сервисов становятся безболезненными. 2.  Добавление новых инстансов сервисов в простых кейсах

(когда можно просто добавить инстанс в пул HAProxy) происходит очень легко.

3.  Нельзя забыть что-то переконфигурировать. 4.  Новых конфигов требуют только новые типы сервисов.

Спасибо за внимание.

s.puzirev@corp.mail.ru