Как sre следит за стабильностью и скоростью headhunter /...
TRANSCRIPT
HEADHUNTERCайт, где соискатели находят работу, а работодатели - сотрудников.
frontfront ...
3K запросов / сек
backend backend...
26K запросов / сек
PostgreSQL CassandraPostgreSQL... ...
51K запросов / сек
ДОСТУПНОСТЬ, %
ПЛАН• SRE vs эксплуатация
• Мониторинг
• Реакция на инциденты
• Нагрузочные тесты
• Грабли, грабли и решения
SRE VS ЭКСПЛУАТАЦИЯSRE - Site Reliability Engineering
Эксплуатация• железо
• сеть
• ОС (ubuntu)
• инфраструктурные приложения(nginx, haproxy, rsyslog и др.)
• Отдельные люди следят за PostgreSQL
SRE• приложения
• их настройки (jvm, таймауты и др.)
• nginx, haproxy
• архитектура
Делаем одно и то же на разных уровнях
МОНИТОРИНГ
ЧТО ТАКОЕ “САЙТ ЛЕЖИТ”Хочется:
• клиенты перестали платить :-)
Эксплуатация:
• >= 20 пятисоток в секунду на фронтах
• 95% ответов >= 4 сек
“САЙТ ЛЕЖИТ” @SRE• % пятисоток >= 0.5%
• site
• API
• mobile site
• из-за контролируемой деградации>= 5 пятисоток в секунду на любом бэкенде
site
2100 rps
API
700 rps
mobile site
200 rps
НА ТЕЛЕВИЗОРАХ
РЕАКЦИЯ НА ИНЦИДЕНТ
АВТОМАТИЧЕСКИ• Оповещение в slack
• Вместе ищем причину
• Задача в JIRA
• Подробно разбираем, описываем, прикрепляем задачи
ИНСТРУМЕНТЫ• Графики
Тотальный мониторинг:5xx, RPS, перцентили, jetty пулы, memcached, c3p0 пулы, CPU, RAM…
• Если нет графиков - логи
ВСЕ ЛОГИ ЗАПРОСА
REQUEST ID
front request id: 123
PostgreSQL PostgreSQL...
request id: 123request id: 123
backend backend...
request id: 123 request id: 123
Каждая строка лога имеет request id
GRAYLOG НЕ ПОЛЕТЕЛ• Много логов (1.3 TB / день)
• 100% CPU на машинах Graylog
• Много потерь
TIMESTAMPED REQUEST ID1477983593864a8976b43c3b85712abf
2016-11-01 09:59:53,864
БИНАРНЫЙ ПОИСК В ЛОГАХГде 09:59:53?
…08:30:00 INFO ...…09:00:00 WARN ...…09:30:00 INFO ...…10:00:00 ERROR ...…10:30:00 INFO ...…
ВСЕ ЛОГИ ПО REQUEST ID
НАГРУЗОЧНЫЕ ТЕСТЫ
НАГРУЗОЧНЫЕ ТЕСТЫ• Раз в несколько месяцев
• Когда естественная нагрузка максимальна (у нас - днем)
• Баланс между честностью и сложностью профиля нагрузки
• Наиболее частотные запросы (в основном GET)
• Отдельный профиль для соискателей, работодателей и анонимов
• Отдельный профиль для сайта, мобильного сайта и api
Дальше работаем как с инцидентом.
ГРАБЛИ 1ПРОТУХАНИЕ ЗАПРОСОВ
ПРОТУХАНИЕ ЗАПРОСОВ
• Пока запрос лежит в очередях - он протухает
• 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• Если образовалась очередь - дальше затор - падать• Отказаться от ненужных очередей
• например, нет свободных тредов - отпинывать задачу
• Очередь нужна? Замониторить, зажать размер• например, зажать accept backlog• еще лучше Connection: Keep-Alive
• Нет размера очереди? Жесткий таймаут ожидания• например, на время взятия соединение из пула соединений к базе
• Асинхронная архитектура? Ограничить количество запросов в работе• Как можно ближе к узкому ресурсу,
ограничение на балансировщике - так себе
ГРАБЛИ 2ЛАВИНА РЕТРАЕВ
ЛАВИНА РЕТРАЕВfront
balancer
front front
backendbalancer
backend backend
• Бэкенды завалены ретраями
• А если front’ов больше?
• А если 3х-уровневая архитектура?
ПРИНЦИПЫ РЕТРАЕВ• Только непосредственно перед проблемой
• например, не ретраить на фронтах, если лежит бэкенд
• Четко понимать: упал сам сервис, или тот кто под ним• например, 500/503 - упал сервис, 502 - тот, кто под ним• помогает разбирать инциденты
• Ограничение на количество ретраев• у нас 1-2
• Ограничение на время, в течение которого можно ретраить• Лучше недоретраить, чем переретраить• Ретрай “вдруг сервис затупил” - заметание проблемы под ковер
НУЖНО РЕТРАИТЬ• Connection refused
• например, остановили приложение на время релиза
• Connect timeout
• например, выключили сервер для обслуживания
• Read timeout для идемпотентных запросов
• например, сервер упал в момент выполнения запроса
• Думать об этих проблемах при разработке!
• например, соединение к PostgreSQL, RabbitMQ, Cassandra
ГРАБЛИ 3ЛИШНИЕ ПРОМЕЖУТОЧНЫЕ ЗВЕНЬЯ
БАЛАНСИРОВЩИКИ - БОЛЬ• Лишний оверхед
• Точка отказа
• Кто должен балансировать балансировщики?
• Что делать с connect timeout до балансировщика?
• Балансировать на уровне клиентов
ТУПИТ PGBOUNCER
backend backend
pgbouncer
postgresql
При ~10K запросов в секунду затупил pgbouncer
ЗАЧЕМ PGBOUNCER
backend backend
pgbouncer
postgresql
• Бэкенду понадобилось больше соединений? Пожалуйста!
• А если тупит база?
• Всем требуется > 10 соединений
• Бэкенды все равно ждут
• Давать бэкендам > 10 соединений бессмысленно
5-15 5-15
20
УБРАЛИ PGBOUNCER
backend backend
postgresql
• Жесткий пул 10 соединений
• Понадобилось больше?Fail-fast!
• Походы на реплики без транзакций
10 10
ТО, ЧЕГО НЕТ,СЛОМАТЬСЯ НЕ МОЖЕТ
МАСШТАБИРОВАНИЕРЕПЛИК
POSTGRESQL
БАЛАНСИРОВКА МЕЖДУ РЕПЛИКАМИ• 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
МИКРОСЕРВИСЫ
МИКРОСЕРВИСЫ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 -> оркестрация
