18 марта с 18:33 до 18:46 (мск) для 15% клиентов наблюдалась недоступность сервиса api.mindbox.ru

Корневая причина недоступности — ошибка конфигурации приложения при развертывании кластера в kubernetes

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

Во время инцидента на пострадавших проектах синхронные запросы расчета и сохранения заказов, операции получения информации по клиенту, а также операции персонализации сайтов завершались с ошибками.

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

• В 18:34 - система мониторинга зафиксировала недоступность синхронных сервисов api.mindbox.ru. Инженеры приступили к диагностике
• В 18:39 - установили причину: отказ ноды из-за перегрузки по CPU. Приступили к выводу отказавшей ноды из кластера
• В 18:46 - полностью восстановилась доступность сервисов для всех клиентов

Отчёт

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

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

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

Все входящие запросы в API проходят через наш API Gateway. Этот сервис отвечает за роутинг запросов в конкретные конечные сервисы. Чтобы не допустить каскадный отказ всего API-гейта мы используем паттерн Circuit Breaker. Он отслеживает вызовы к внешнему сервису и при обнаружении слишком большого количества неудачных попыток временно блокирует вызовы, предотвращая тем самым падение всей системы. Этот отказ затронул примерно 10% трафика, что привело к тому, что Circuit Breaker отключил часть вызовов, уменьшив радиус отказа.

Что улучшили

• Увеличили требования приложения по количеству ресурсов таким образом, чтобы при запуске приложения был достаточный запас по ресурсам, что позволит избежать перегрузки при старте и обеспечит более плавное развертывание.
• Настроили мониторинг, который срабатывает если время ответа на конкретном сервере существенно хуже чем в среднем на остальных. Это позволит максимально быстро определить и устранить проблемный сервер.

Что улучшим

• Будем автоматически выводить из балансировки входящих запросов поды на проблемных серверах - 2-й квартал 2024
• Создадим запас по незанятым ядрам в размере 8% от общей емкости сервера. Это позволит нам справляться с внезапными всплесками нагрузки без риска перегрузки серверов - 2-й квартал 2024
• Введем в descheduler новую политику, которая будет способствовать более равномерному распределению нагрузки между серверами, перераспределяя поды с более загруженных серверов на менее загруженные. Это обеспечит равномерное использование ресурсов и уменьшит вероятность перегрузок - 2-й квартал 2024
• Внедрим механизм автоматического вывода сервера из эксплуатации на основе метрик системы мониторинга. Это позволит сократить время недоступности сервисов в случае возникновения критических ошибок - 4-й квартал 2024