2 апреля с 15:30 до 18:00 (мск) наблюдался отказ в работе массовых и автоматических рассылок.

Корневая причина – отказ брокера очередей, отвечающего за отправку сообщений из-за отключения механизма очистки памяти при изменении архитектуры сервиса.

Влияние на клиента

До 50% транзакционных сценариев выполнялись с задержкой:

• 5% – до 1 часа
• 5% – до 40 минут
• 10% – до 27 минут
• 10% – до 14 минут
• 10% – до 10 минут
• 10% – до 6 минут

Операции отправки авторизационных и регистрационных кодов во время отказа заканчивались ошибками в 50-100% случаев. Массовые рассылки отправлялись со скоростью ниже целевой

Как выявляли и устраняли инцидент

14:17 – отказал 1 брокер кластера

14:25 – дежурный инженер получил уведомление о недоступности брокера

14:30 – произвели аварийную перезагрузку пострадавшего брокера

14:45 – кластер вернулся к штатной работе

15:30 – начался каскадный отказ брокеров кластера

16:15 – кластер потерял 6 брокеров, к починке подключились SRE-инженеры

16:25 – выявили причину отказа кластера и приступили к масштабированию брокеров

17:43 – работоспособность транзакционных сценариев полностью восстановлена

17:52 – работоспособность операций отправки авторизационных и регистрационных кодов полностью восстановлена

18:00 – все брокеры масштабированы до целевой конфигурации, кластер функционирует в штатном режиме, массовые рассылки достигли целевой скорости отправки

Отчёт

Мы используем брокер очередей Apache Kafka в качестве системы-посредника для отправки рассылок. Для обеспечения пропускной способности отправки сообщений используется специальный алгоритм очистки занятых ресурсов, опирающийся на информацию о статусе рассылок.

Мы упустили перенос этого механизма при работах по улучшению инфраструктуры сервиса. Это вызвало рост количества очередей сообщений для массовых рассылок. Достижение критического объёма очереди привело к отказу кластера Apache Kafka, отвечающего за отправки рассылок.

После локализации проблемы мы добавили каждому брокеру в кластере ресурсы для восстановления работоспособности кластера и вручную очистили занятые уже отправленными рассылками ресурсы.

Что улучшили

• Починили механику очистки занятых ресурсов для отправки массовых рассылок

• Изолировали рассылки друг от друга, разместив очереди в три независимых кластера Apache Kafka:

  • Под массовые рассылки
  • Под автоматические рассылки
  • Под транзакционные рассылки

Что улучшим

• Сделаем автоматическое ограничение на количество топиков в кластерах Kafka. Это защитит их от каскадного отказа ценой меньшей недоступности: в данном отказе это бы привело только к ошибкам клонирования рассылок – 3й квартал 2024.