7 марта с 8:30 до 21:50 (мск) для 90% клиентов была замедлена скорость обработки асинхронных запросов обычного приоритета.
Корневая причина недоступности — формирование чрезмерной очереди асинхронных вызовов из-за ошибки в алгоритме повторной обработки некорректных запросов.
Влияние на клиента
В период инцидента у 90% клиентов вызовы асинхронных операций обычного приоритета выполнялись с максимальной задержкой в 5 часов 30 минут.
Как выявляли и устраняли инцидент
Голоссарий
Шина асинхронных операций — очередь запросов, пришедших от всех клиентов в сервис асинхронных операций.
Шина сервиса данных клиентов — отдельная на каждый проект очередь запросов, для обработки которых требуются данные клиентов (контакты, заказы, просмотры продуктов, и т.д.).
Таймлайн
- 8:35 — Появились задержки при обработке асинхронных операций
- 8:45 — Дежурный инженер получил первые уведомления о задержках
- 11:03 — Дежурный инженер отреагировал на уведомления
- 11:41 — Дежурный инженер локализовал проблему: часть запросов в шине асинхронных операций не можем отправить в шину сервиса данных клиентов из-за того, что запросы оказываются слишком большими
- 11:52 — Дежурный исследовал гипотезу, что ранее было произведено изменение размера разрешенного сообщения одним из инженеров
- 12:02 — Обнаружили причину проблемы в наличии чересчур крупных запросов в шине сервиса асинхронных операций от одного из клиентов
- 12:05 — Дежурный приступил к подготовке решения для возникшей ситуации — настройке архивирования запросов проблемной операции
- 13:20 — Решение было выложено на сервера Mindbox
- 13:30 — Разработанное решение не повлияло на скорость обработки запросов в шине сервиса асинхронных операций. Началась подготовка второй версии решения, которая бы не архивировала проблемные запросы, а полностью их отбрасывала
- 14:35 — Новое решение было выложено на сервера Mindbox. Скорость обработки запросов в шине сервиса асинхронных операций начала расти
- 15:25−16:45 — Дежурный инженер постепенно увеличивал количество ресурсов выделенных шине обработки асинхронных операций для ускорения разбора накопившейся очереди вызовов
- 21:50 — Задержка при обработке запросов в шине асинхронных операций устранена
Отчёт
В 8:00 (мск) от одного из клиентов был получен один вызов асинхронной операции с телом запроса размером 890 КБайт. При первоначальной обработке в рамках http-запроса от клиента он был расценен как валидный и попал в шину асинхронных операций для последующей обработки. При дальнейшей обработке этого запроса фоновой задачей этот запрос обогащался данными и помещался в шину сервиса данных клиентов, чтобы непосредственно выполнить шаги операции.
Из-за большого размера исходного запроса и размера данных для обогащения суммарный размер получившегося сообщения для отправки в шину сервиса данных клиентов уже превышал лимит в 1МБайт для отправки в эту шину. Это приводило к тому, что этот запрос попадал в очередь для повторной попытки обработки, чтобы ещё раз попробовать положить его в шину сервиса данных клиентов через 1 минуту. Так как от повторной обработки размер сообщения меньше не становился, оно постоянно перекладывалось из очереди отложенных в шину обработки и обратно каждую минуту.
Из-за особенностей работы системы при таком перекладывании есть небольшая вероятность того, что сообщение может задублироваться. В итоге это сообщение задублировалось множество раз, и в очереди образовалось 1800 дублей этого сообщения. В 8:35 (мск) обработка очереди запросов стала замедляться из-за большого размера каждого из дублей.
Починка инцидента свелась к тому что:
- Нужно было выяснить, что именно произошло, и какое сообщение в этом виновато;
- Выбросить из очереди все дубли плохого сообщения;
- Увеличить скорость обработки очереди, чтобы ускорить обработку накопившихся сообщений.
Что улучшили
- Если сообщение не помещается в очередь другого сервиса при обработке очереди асинхронных операций, мы отбрасываем такое сообщение, а не пытаемся его переобработать бесконечно.
Что улучшим
- Добавим алерт на размер очереди запросов асинхронных операций, а алерты на выполнение системных операций, следящие за скоростью работы сервиса, сделаем критическими, чтобы улучшить время реакции дежурной команды — до 15 апреля 2025 года.
- Уменьшим вероятность дублирования сообщений при откладывании и сделаем экспоненциально растущую задержку для отложенных сообщений из-за ошибок — до 15 июня 2025 года.
- Усилим контроль над стабильностью сервиса асинхронных операций, ужесточив мониторинг его нарушений – до 15 августа 2025.