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

2.
Service-oriented architecture
1. Приложение состоит из множества слабо связанных
сервисов, которые общаются друг с другом с
использованием четко определённого API.
2. Сервисы ничего не знают о клиентах, их задача –
оказывать сервис.
3. Клиента не волнует, каким образом работает сервис.
4. Сервисы используют другие сервисы.

3.
Service-oriented architecture
Что такое сервис?
1. У сервиса есть интерфейс – API.
2. Сервис имеет точку входа (endpoint) – обычно пара
IP:port.
3. Сервис может пользоваться другими сервисами. В этом
случае он должен быть правильно сконфигурирован.

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

5.
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
MemcachedMemcached

6.
Service-oriented architecture
Несложное PHP-приложение:
Php-fpm
Memcached
MySQL
slave
Nginx
Php-fpm
MySQL
master Memcached
Mcrouter
Static
storage
16 отношений client<->service

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

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

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

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

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

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

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

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

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

16.
Service-discovering
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd

17.
Как связывать сервисы друг с
другом?
Системы service-discovering’а:
Плюсы:
1. Очень быстрое внесение изменений.
2. Не требуется документировать, что где работает и как
должно быть сконфигурировано.
Минусы:
1. Сложно.
2. Страшно – “а вдруг развалится?”.
3. Внешние сущности в виде confd и announcer’а. В идеале
нужно обучать сервисы общаться с etcd напрямую.

18.
Как связывать сервисы друг с
другом?
Что мы хотели?
1. Приложения не должны постоянно перезапускаться (до
свидания, confd).
2. Мы не хотели привязывать тонны legacy-кода наших
приложений к СОС.
3. Облегчить миграцию сервисов на новые endpoint’ы, не
требующую переконфигурации тысяч других сервисов
(ради чего и затевалось).
4. Приложение не должно деградировать в условиях
сломавшейся СОС, выключившегося датацентра,
тормозящей сети и т.п. более, чем деградировало бы без
СОС.

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

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

21.
Etcd + iptables/HAproxy + confd
Было так:
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd

22.
Etcd + iptables/HAproxy + confd
А стало так:
Etcd
Client
Confd
Announcer
Mcrouter
Announcer
Memcached
Announcer
Memcached
Confd
HAProxy

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

24.
Etcd + iptables/HAproxy + confd
А iptables DNAT умеет:
Confd Confd
Etcd
iptables
DNAT
iptables
DNAT
Client statsd
Carbon
(Graphite)

25.
Результат
1. Миграции сервисов становятся безболезненными.
2. Добавление новых инстансов сервисов в простых кейсах
(когда можно просто добавить инстанс в пул HAProxy)
происходит очень легко.
3. Нельзя забыть что-то переконфигурировать.
4. Новых конфигов требуют только новые типы сервисов.

26.
Спасибо за внимание.
s.puzirev@corp.mail.ru