С чем ассоциируют highload в Ozon
Как правило, highload — это высокие риски. В этот период каждый член команды может пожалеть о принятом решении, а если произойдёт ошибка, пользователи её тут же заметят. Иногда последствия могут быть ещё серьёзнее, например, компания попадает в новости или теряет много денег из-за простоя сервиса. Поэтому требования к качеству работы очень высокие.
Мы запускаем тесты каждую ночь, за исключением, пожалуй, высоких сезонов — тогда уже пользователи тестируют нас и проверяют, хорошо ли мы подготовились.
Чаще всего highload возникает во время распродаж, например, перед Новым годом или гендерными праздниками. А ещё в Ozon есть hammer — это когда на главной странице появляются полки с бешеными скидками на три товара.
В моменты hammer нагрузка на сервис вырастает в несколько раз всего за пару минут. Например, так было в ноябре 2023 года — с фоновых 350 000 RPS нагрузка стала 600 000 RPS. При этом сервис не сломался и не упал — пользователи продолжили совершать покупки и ничего не заметили.
Как в Ozon готовятся к перегрузкам
Чтобы маркетплейс оставался стабильным при любых перегрузках, инженеры постоянно его тестируют.
Нашим сервисом пользуются миллионы уникальных посетителей. Поэтому RPS (количество запросов в секунду) у нас очень высокий — доходит до сотен тысяч. При этом мы не прокси-сервер и не рассчитываем траекторию полёта на Марс.
В команде проводят несколько типов тестов. Среди самых частых: центральный тест по сайту, эмуляция нагрузки во время hammer, и дополнительные стресс-тесты. Последние делает каждая команда — каждый инженер тестирует отдельные сервисы. После этих тестов всё спускается в продакшн.
Основная задача — не навредить пользовательскому опыту наших посетителей. Поэтому мы постоянно придумываем новые проверки. Например, эмуляцию нагрузки во время hammer внедрили относительно недавно.
На этапе продакшна тесты не заканчиваются, команда проводит их ещё раз, но уже более бережно — инженеры настраивают автоматические остановки тестов, если что-то идёт не так. Например, команда внимательно следит за следующими метриками:
- Ресурсы CPU
- Нагрузка на сеть
- Память
- Response time
- Error rate
- Троттлинг
- Hit rate
- Лаги в топиках
Я считаю, что метриками нужно покрывать всё, что хоть как-то ограничивает работу системы и может повлиять на время ответа сервиса, перфоманс и производительность.
Параллельно с тестами за работой маркетплейса следит группа оперативной поддержки. Специалисты дежурят круглосуточно и сменяют друг друга по очереди. Важно вовремя отреагировать на инцидент, чтобы маркетплейс продолжал работать. Количество человек в смене зависит от критичности сервиса. Обычно инженеры дежурят по одному, но если сервис критичный, то по двое.
Как удается развертывать обновления и ничего не сломать
В высокий сезон на маркетплейсе действует принцип замораживания кода — никто не меняет исходный код, пока не пройдут распродажи. Для остального времени в Ozon используют метод канареечного деплоя — по этому принципу новый код тестируют только на определённых группах пользователей. Это снижает нагрузку на сервис и помогает избежать проблем, которые с ней связаны.
Если UI-тест прошёл успешно, мы постепенно раскатываем канарейку на всех пользователей. Шаг раскатки зависит от сервиса. Например, деплой будет занимать около двух часов, если нужно прогреть холодные кеши и не положить нижележащие системы.
В Ozon процесс деплоя автоматизирован — инженеру достаточно отслеживать метрики и прожимать процент канарейки для нового релиза.
Зачем нужно кешировать сервис
Одна из главных задач в Ozon — кешировать всё, что можно. Например, в кэш идут key value, memory — всё это во внутренних и внешних хранилищах. Вот почему это полезно:
- ускоряется работа витрины;
- запросы становятся дешевле, потому что данные переиспользуются;
- кратковременные сбои нижележащих систем сглаживаются и становятся незаметны.
У Ozon уходит много ресурсов на кэширование — 42 сервера в каждом из которых по 96 ядер и по терабайту оперативной памяти. У сетевых интерфейсов скорость 25 гигабит в секунду. Все это выделено только под кэш и оно того стоит.
Кратко: как сохранить сервис от перегрузок
- Проводить тесты на разных этапах разработки продукта и отслеживать ключевые метрики.
- Следить за работой сервиса. Идеальный вариант — круглосуточная группа оперативной поддержки, которая быстро отреагирует на инцидент.
- Раскатывать обновления методом канареечного деплоя. А во время высокого сезона вводить принцип замораживания кода.
- Кэшировать данные, чтобы экономить ресурсы и ускорять работу сервиса.