HeadHunter - сайт, где соискатели находят работу, а работодатели - сотрудников.
Днем к нам приходит 3K запросов в секунду (без статики), что превращается в 25K rps к бэкендам и 50K rps к базам данных.
Раньше стабильность сайта могла быть ниже 99%. Теперь - это 99.9% и лучше.
Стабильностью сайта у нас занимается как служба эксплуатации, так и команда разработчиков SRE (site reliability engineering).
В прошлом году Николай Сивко уже рассказывал об организации службы эксплуатации и мониторинге сайта. Но эксплуатация отвечает за железо, сеть и ОС, а за приложения - команда SRE.
В докладе хочу рассказать о том, как мы построили процесс, позволяющий каждый месяц улучшать стабильность сайта, с какими техническими проблемами сталкиваемся и как решаем. В частности:
- как мы определяем, когда сайт работает, а когда - нет?
- что делаем, когда сайт лежит?
- как настроили мониторинг и другие инструменты для быстрой локализации проблемы;
- как нагружаем сайт, чтобы заранее выявить узкое место?
Чтобы не было скучно, расскажу о конкретных кейсах:
- как мы масштабировали реплики базы данных;
- почему отказались от PgBouncer для высоконагруженных бэкендов;
- почему нам не подошел Graylog, и как мы ищем в логах другим гораздо более простым и быстрым способом;
- как решили проблему заваливания себя ретраями;
- и др.
6. Эксплуатация
• железо
• сеть
• ОС (ubuntu)
• инфраструктурные
приложения
(nginx, haproxy, rsyslog и др.)
• Отдельные люди следят за
PostgreSQL
SRE
• приложения
• их настройки (jvm, таймауты и
др.)
• nginx, haproxy
• архитектура
Делаем одно и то же на разных уровнях
8. ЧТО ТАКОЕ “САЙТ ЛЕЖИТ”
Хочется:
• клиенты перестали платить :-)
Эксплуатация:
• >= 20 пятисоток в секунду на
фронтах
• 95% ответов >= 4 сек
9. “САЙТ ЛЕЖИТ” @SRE
• % пятисоток >= 0.5%
• site
• API
• mobile site
• из-за контролируемой
деградации
>= 5 пятисоток в секунду на
любом бэкенде
site
2100 rps
API
700 rps
mobile site
200 rps
21. НАГРУЗОЧНЫЕ ТЕСТЫ
• Раз в несколько месяцев
• Когда естественная нагрузка максимальна (у нас - днем)
• Баланс между честностью и сложностью профиля нагрузки
• Наиболее частотные запросы (в основном GET)
• Отдельный профиль для соискателей, работодателей и анонимов
• Отдельный профиль для сайта, мобильного сайта и api
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
• Нет размера очереди? Жесткий таймаут ожидания
• например, на время взятия соединение из пула соединений к базе
• Асинхронная архитектура? Ограничить количество запросов в работе
• Как можно ближе к узкому ресурсу,
ограничение на балансировщике - так себе
28. ПРИНЦИПЫ РЕТРАЕВ
• Только непосредственно перед проблемой
• например, не ретраить на фронтах, если лежит бэкенд
• Четко понимать: упал сам сервис, или тот кто под ним
• например, 500/503 - упал сервис, 502 - тот, кто под ним
• помогает разбирать инциденты
• Ограничение на количество ретраев
• у нас 1-2
• Ограничение на время, в течение которого можно ретраить
• Лучше недоретраить, чем переретраить
• Ретрай “вдруг сервис затупил” - заметание проблемы под ковер
29. НУЖНО РЕТРАИТЬ
• Connection refused
• например, остановили приложение на время релиза
• Connect timeout
• например, выключили сервер для обслуживания
• Read timeout для идемпотентных запросов
• например, сервер упал в момент выполнения запроса
• Думать об этих проблемах при разработке!
• например, соединение к PostgreSQL, RabbitMQ, Cassandra
31. БАЛАНСИРОВЩИКИ - БОЛЬ
• Лишний оверхед
• Точка отказа
• Кто должен балансировать балансировщики?
• Что делать с connect timeout до балансировщика?
• Балансировать на уровне клиентов
40. МИКРОСЕРВИСЫ
Pros:
• Демонструация монолита
(точно нужен отдельный deploy unit?)
• Контролируемая деградация
• Специфичные требования к
оборудованию
Cons:
• Владеет бизнес-команда, но знания об
отказоустойчивости в SRE
• Часто забрасывают
• Оверхед на
сериализацию/десериализацию,
сетевые походы
• Оверхед при программировании
(вызвать метод проще, чем написать
RPC)
• Инфраструктурная копипаста
• Виртуалки -> docker -> оркестрация