1. КАК SRE СЛЕДИТ
ЗА СТАБИЛЬНОСТЬЮ
HEADHUNTER
Антон Иванов
an.ivanov@hh.ru

2. HEADHUNTER
Cайт, где соискатели находят работу, а работодатели - сотрудников.
frontfront ...
3K запросов / сек
backend backend...
26K запросов / сек
PostgreSQL CassandraPostgreSQL... ...
51K запросов / сек

3. ДОСТУПНОСТЬ, %

4. ПЛАН
• SRE vs эксплуатация
• Мониторинг
• Реакция на инциденты
• Нагрузочные тесты
• Грабли, грабли и решения

5. SRE VS ЭКСПЛУАТАЦИЯ
SRE - Site Reliability Engineering

6. Эксплуатация
• железо
• сеть
• ОС (ubuntu)
• инфраструктурные
приложения
(nginx, haproxy, rsyslog и др.)
• Отдельные люди следят за
PostgreSQL
SRE
• приложения
• их настройки (jvm, таймауты и
др.)
• nginx, haproxy
• архитектура
Делаем одно и то же на разных уровнях

7. МОНИТОРИНГ

8. ЧТО ТАКОЕ “САЙТ ЛЕЖИТ”
Хочется:
• клиенты перестали платить :-)
Эксплуатация:
• >= 20 пятисоток в секунду на
фронтах
• 95% ответов >= 4 сек

9. “САЙТ ЛЕЖИТ” @SRE
• % пятисоток >= 0.5%
• site
• API
• mobile site
• из-за контролируемой
деградации
>= 5 пятисоток в секунду на
любом бэкенде
site
2100 rps
API
700 rps
mobile site
200 rps

10. НА ТЕЛЕВИЗОРАХ

11. РЕАКЦИЯ НА ИНЦИДЕНТ

12. АВТОМАТИЧЕСКИ
• Оповещение в slack
• Вместе ищем причину
• Задача в JIRA
• Подробно разбираем, описываем, прикрепляем задачи

13. ИНСТРУМЕНТЫ
• Графики
Тотальный мониторинг:
5xx, RPS, перцентили, jetty
пулы, memcached, c3p0 пулы,
CPU, RAM…
• Если нет графиков - логи

14. ВСЕ ЛОГИ ЗАПРОСА

15. REQUEST ID
front request id: 123
PostgreSQL PostgreSQL...
request id: 123request id: 123
backend backend...
request id: 123 request id: 123
Каждая строка лога имеет request id

16. GRAYLOG НЕ ПОЛЕТЕЛ
• Много логов (1.3 TB / день)
• 100% CPU на машинах Graylog
• Много потерь

17. TIMESTAMPED REQUEST ID
1477983593864a8976b43c3b85712abf
2016-11-01 09:59:53,864

18. БИНАРНЫЙ ПОИСК В ЛОГАХ
Где 09:59:53?
…
08:30:00 INFO ...
…
09:00:00 WARN ...
…
09:30:00 INFO ...
…
10:00:00 ERROR ...
…
10:30:00 INFO ...
…

19. ВСЕ ЛОГИ ПО REQUEST ID

20. НАГРУЗОЧНЫЕ ТЕСТЫ

21. НАГРУЗОЧНЫЕ ТЕСТЫ
• Раз в несколько месяцев
• Когда естественная нагрузка максимальна (у нас - днем)
• Баланс между честностью и сложностью профиля нагрузки
• Наиболее частотные запросы (в основном GET)
• Отдельный профиль для соискателей, работодателей и анонимов
• Отдельный профиль для сайта, мобильного сайта и api

22. Дальше работаем как с инцидентом.

23. ГРАБЛИ 1
ПРОТУХАНИЕ ЗАПРОСОВ

24. ПРОТУХАНИЕ ЗАПРОСОВ
• Пока запрос лежит в очередях - он протухает
• FIFO - обрабатываем самые протухшие запросы
• Вхолостую тратим ресурсы
• Сервис не может сам восстановиться
request thread pool
9 10 11 ...12
db pool queue
13 14 ...
accept backlog
21
request thread pool queue
4 5 6 7 8
timeout!

25. FAIL-FAST
• Если образовалась очередь - дальше затор - падать
• Отказаться от ненужных очередей
• например, нет свободных тредов - отпинывать задачу
• Очередь нужна? Замониторить, зажать размер
• например, зажать accept backlog
• еще лучше Connection: Keep-Alive
• Нет размера очереди? Жесткий таймаут ожидания
• например, на время взятия соединение из пула соединений к базе
• Асинхронная архитектура? Ограничить количество запросов в работе
• Как можно ближе к узкому ресурсу,
ограничение на балансировщике - так себе

26. ГРАБЛИ 2
ЛАВИНА РЕТРАЕВ

27. ЛАВИНА РЕТРАЕВ
front
balancer
front front
backend
balancer
backend backend
• Бэкенды завалены ретраями
• А если front’ов больше?
• А если 3х-уровневая архитектура?

28. ПРИНЦИПЫ РЕТРАЕВ
• Только непосредственно перед проблемой
• например, не ретраить на фронтах, если лежит бэкенд
• Четко понимать: упал сам сервис, или тот кто под ним
• например, 500/503 - упал сервис, 502 - тот, кто под ним
• помогает разбирать инциденты
• Ограничение на количество ретраев
• у нас 1-2
• Ограничение на время, в течение которого можно ретраить
• Лучше недоретраить, чем переретраить
• Ретрай “вдруг сервис затупил” - заметание проблемы под ковер

29. НУЖНО РЕТРАИТЬ
• Connection refused
• например, остановили приложение на время релиза
• Connect timeout
• например, выключили сервер для обслуживания
• Read timeout для идемпотентных запросов
• например, сервер упал в момент выполнения запроса
• Думать об этих проблемах при разработке!
• например, соединение к PostgreSQL, RabbitMQ, Cassandra

30. ГРАБЛИ 3
ЛИШНИЕ ПРОМЕЖУТОЧНЫЕ ЗВЕНЬЯ

31. БАЛАНСИРОВЩИКИ - БОЛЬ
• Лишний оверхед
• Точка отказа
• Кто должен балансировать балансировщики?
• Что делать с connect timeout до балансировщика?
• Балансировать на уровне клиентов

32. ТУПИТ PGBOUNCER
backend backend
pgbouncer
postgresql
При ~10K запросов в секунду затупил pgbouncer

33. ЗАЧЕМ PGBOUNCER
backend backend
pgbouncer
postgresql
• Бэкенду понадобилось больше
соединений? Пожалуйста!
• А если тупит база?
• Всем требуется > 10 соединений
• Бэкенды все равно ждут
• Давать бэкендам > 10 соединений
бессмысленно
5-15 5-15
20

34. УБРАЛИ PGBOUNCER
backend backend
postgresql
• Жесткий пул 10 соединений
• Понадобилось больше?
Fail-fast!
• Походы на реплики без
транзакций
10 10

35. ТО, ЧЕГО НЕТ,
СЛОМАТЬСЯ НЕ МОЖЕТ

36. МАСШТАБИРОВАНИЕ
РЕПЛИК
POSTGRESQL

37. БАЛАНСИРОВКА МЕЖДУ РЕПЛИКАМИ
• Driver открывает соединение на
произвольную реплику
• Connect timeout / connection refused -
пробует другой сервер
• Умер postgresql - connection error -
переподключение
• Потеряли соединение - socket timeout -
переподключение
• Время жизни соединения - 1 мин
• Бэкендов и соединений много,
в пределе равномерно
backend
postgresql
driver
backend
postgresql
driver
postgresql postgresql
jdbc:postgresql://postgresql1,postgresql2
?loadBalanceHosts=true
&connectTimeout=1
&socketTimeout=3

38. МИКРОСЕРВИСЫ

39. МИКРОСЕРВИСЫ
mobile sitesite API
core
vacancy
search
resume
search
billingsession
hhid negotiations banner relations rs
mailer autosearch cms corrector +100500

40. МИКРОСЕРВИСЫ
Pros:
• Демонструация монолита
(точно нужен отдельный deploy unit?)
• Контролируемая деградация
• Специфичные требования к
оборудованию
Cons:
• Владеет бизнес-команда, но знания об
отказоустойчивости в SRE
• Часто забрасывают
• Оверхед на
сериализацию/десериализацию,
сетевые походы
• Оверхед при программировании
(вызвать метод проще, чем написать
RPC)
• Инфраструктурная копипаста
• Виртуалки -> docker -> оркестрация

41. СПАСИБО
Антон Иванов
an.ivanov@hh.ru