25 октября с 18:30 до 19:08 (мск) до 100% клиентов столкнулись с недоступностью сервиса асинхронных интеграций и сценариев

Корневая причина недоступности — внесение изменений в систему Service Discovery, предоставляющей своим пользователям актуальные адреса микросервисов и компонентов данных, без обеспечения обратной совместимости.

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

В период инцидента до 100% клиентов сталкивались с ошибками при выполнении синхронных и асинхронных операций, а также сценариев.

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

18:06 – Изменения в записях Service Discovery были применены на пред-производственном контуре

18:22 – Изменения в записях Service Discovery начали применяться на всех клиентских системах

18:34 – Мониторинг зафиксировал недоступность внутреннего сервиса сценариев

18:38 – Начат процесс отката изменений в записях Service Discovery

19:08 – Доступность сервисов была полностью восстановлена для всех клиентов

Отчёт

Для взаимодействия микросервисов мы используем мульти-тенантную архитектуру. Для её реализации необходим инструмент обнаружения адресов других микросервисов и шин данных в контексте каждого клиента (тенанта). На момент реализации архитектуры  не существовало open source решений, удовлетворяющих нашим требованиям, поэтому мы реализовали его собственными силами он называется Service Discovery. Когда поступает API-запрос, этот инструмент позволяет нужному микросервису получать адреса, необходимые для обработки этого запроса.

В рамках развития платформы мы начали перенос кластеров Kafka в Kubernetes. В этом процессе в Service Discovery проводятся несколько манипуляций. В частности для каждого кластера мы:

• меняем адрес подключения для каждого кластера на новый, чтобы тенанты могли начинали взаимодействовать с ним. На время миграции данные также зеркалируются для обеспечения непрерывной доступности. 
• вводим ограничение со стороны клиента кластера Kafka, чтобы защититься от некорректного использования кластера, негативно влияющего на надёжность системы. Значения квот для каждого кластера при этом переносятся в инструмент управления конфигурацией и мониторингом состояния сервисов Consul.

Во время миграции, позволяющей в дальнейшем управлять квотами клиентов через Consul, мы поддерживали старый формат данных и при этом добавили новые ключи с новой строкой изменения в конфигурацию Service Discovery. После тестирования и выкладки, старый формат данных перестал быть поддерживаемым.

К сожалению, в ходе тестирования изменений на одном из микросервисов мы не учли, что те же данные использовались и другими микросервисами. Это привело к нарушению обратной совместимости, в результате чего другие микросервисы не смогли получить адреса кластеров Kafka для конкретных тенантов, что затруднило их работу. Мы считаем, что логирование использования узлов микросервисами позволило бы отследить зависимости и учесть их при миграции.

Что улучшим

• Будем отображать на дашборде в Grafana изменения записей в Service Discovery. Это позволит ускорить процесс диагностики и выявления корневых причин проблем - 4й квартал 2024 года

• Внедрим механизм более плавного применения изменений записей в Service Discovery. Это позволит сократить бластрадиус и заблаговременно выявлять изменения, нарушающие обратную совместимость - 1й квартал 2025 года

• Внедрим механизм быстрого отказа изменений в записях Service Discovery. Это позволит значительно ускорить восстановление доступности сервиса для клиентов - 1й квартал 2025 года

• Откажемся от использования старого механизма Service Discovery для данных кластеров Kafka, перейдя на Consul. Это полностью устранит необходимость в ручных изменениях записей Service Discovery - 2й квартал 2025 года