антон иванов, как команда sre делает head hunter стабильным
TRANSCRIPT
HEADHUNTERCайт, где соискатели находят работу, а работодатели - сотрудников.
frontfront ...
4.5K запросов / сек
backend backend...
32K запросов / сек
PostgreSQL CassandraPostgreSQL... ...
71K запросов / сек
ДОСТУПНОСТЬ, %
ПЛАН• Чем занимается SRE в HeadHunter
• Грабли 1: протухание запросов• Грабли 2: лавина ретраев• Грабли 3: лишние звенья• Микросервисы
• Чем занимается SRE в HeadHunter
• Грабли 1: протухание запросов• Грабли 2: лавина ретраев• Грабли 3: лишние звенья• Микросервисы
SRESite reliability engineering
• архитектура приложений• технологии• мониторинг приложений• разбор и реакция на софтверные инциденты• настройки в проде (jvm, таймауты и др.)• настройка балансировки (nginx, haproxy)
• железо / сеть / ОС в датацентре -> эксплуатация• автотесты / стенды / железо / сеть в test окружении ->
QA
SRE В HEADHUNTER
• Чем занимается SRE в HeadHunter
• Грабли 1: протухание запросов• Грабли 2: лавина ретраев• Грабли 3: лишние звенья• Микросервисы
ПРОТУХАНИЕ ЗАПРОСОВ
• Пока запрос лежит в очередях - он протухает
• 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!
FAIL-FAST• Если образовалась очередь - значит дальше затор - надо
падать• Отказаться от ненужных очередей
– ex, нет свободных тредов - отпинывать задачу• Очередь нужна? Замониторить, зажать размер
– ex, зажать accept backlog– еще лучше Connection: Keep-Alive
• Нет размера очереди? Жесткий таймаут ожидания– ex, на время взятия соединение из пула соединений к базе
• Асинхронная архитектура?Ограничить количество запросов в работе
• Как можно ближе к узкому ресурсу,ограничение на балансировщике - так себе
• Чем занимается SRE в HeadHunter
• Грабли 1: протухание запросов• Грабли 2: лавина ретраев• Грабли 3: лишние звенья• Микросервисы
ЛАВИНА РЕТРАЕВfront
balancer
front front
backendbalancer
backend backend
• Бэкенды завалены ретраями
• А если front’ов больше?
• А если 3х уровневая архитектура?
ПРИНЦИПЫ РЕТРАЕВ• Только непосредственно перед проблемой
– ex. не ретраить на фронтах, если лежит бэкенд• Четко понимать: упал сам сервис, или тот кто под ним
– ex. 500/503 - упал сервис, 502 - тот, кто под ним– помогает разбирать инциденты
• Ограничение на количество ретраев• Ограничение на время, в течение которого можно
ретраить• Ретрай “вдруг сервис затупил” - заметание проблемы
под ковер• Лучше недоретраить, чем переретраить
НУЖНО РЕТРАИТЬ• Connection refused
– ex, остановили приложение на время релиза• Connect timeout
– ex, выключили сервер для обслуживания• Read timeout для идемпотентных запросов
– ex, пропала связь в момент выполнения запроса
• Думать об этих проблемах при разработке!– ex, соединение к Memcached, PostgreSQL, RabbitMQ,
Cassandra
• Чем занимается SRE в HeadHunter
• Грабли 1: протухание запросов• Грабли 2: лавина ретраев• Грабли 3: лишние звенья• Микросервисы
ТУПИТ PGBOUNCERbackend backend
pgbouncer
postgresql
При ~10K запросов в секунду затупил pgbouncer
ЗАЧЕМ PGBOUNCERbackend backend
pgbouncer
postgresql
• Бэкенду понадобилось больше соединений? Пожалуйста!
• А если тупит база?– Всем требуется > 10
соединений– Бэкенды все равно ждут– Давать бэкендам > 10
соединений бессмысленно
5-15 5-15
20
УБРАЛИ PGBOUNCERbackend backend
postgresql
• Жесткий пул 10 соединений
• Понадобилось больше?Fail-fast!
• Походы на реплики без транзакций
10 10
БАЛАНСИРОВЩИКИ - БОЛЬ
• Лишний оверхед• Точка отказа• Кто должен балансировать
балансировщики?• Что делать с connect timeout до
балансировщика?• Балансировать на уровне клиентов
ТО, ЧЕГО НЕТ,СЛОМАТЬСЯ НЕ МОЖЕТ
• Чем занимается SRE в HeadHunter
• Грабли 1: протухание запросов• Грабли 2: лавина ретраев• Грабли 3: лишние звенья• Микросервисы
МИКРОСЕРВИСЫmobile sitesite API
core vacancy search
resume searchbillingsession
hhid negotiations banner relations rs
mailer autosearch cms corrector +100500
МИКРОСЕРВИСЫPros:
• Демонструация монолита(точно нужен отдельный deploy unit?)
• Контролируемая деградация• Специфичные требования к
оборудованию
Cons:• Владеет бизнес-команда, но
знания об отказоустойчивости в SRE
• Часто забрасывают• Оверхед на
сериализацию/десериализацию, сетевые походы
• Оверхед при программировании(вызвать метод проще, чем написать RPC)
• Инфраструктурная копипаста• Виртуалки -> docker ->
оркестрация