31 октября с 15:51 до 17:20 (мск) у 20% клиентов наблюдалась недоступность сервисов процессинга заказов, персонализации и алгоритмов рекомендаций.

Корневая причина недоступности — некорректная конфигурация кластера Kubernetes.

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

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

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

• 15:54 – система мониторинга зафиксировала нарушение работы сервиса процессинга заказов, инженеры приступили к диагностике
• 16:04 – проблема стала массовой, эскалировали внутри
• 16:12 – предположили, что проблема связана с работами по миграции микросервисов между группами узлов в Kubernetes, гипотеза не подтвердилась
• 16:20 – зафиксировали значительный рост времени ответов на уровне локального DNS в Kubernetes
• 16:24 – зафиксировали перегрузку по CPU у некоторых узлов Kubernetes
• 16:43 – локализовали проблему до группы узлов Kubernetes, связали с работами по миграции, начали работы по восстановлению
• 17:28 – полностью восстановили штатный режим работы сервисов, откатили миграцию

Отчёт

Наша архитектура предполагает использование сервисов через контейнеры – способ упаковки программного обеспечения для удобства запуска и гарантий консистентной работы. Для их развёртывания мы используем кластер Kubernetes. 

Кластер позволяет группировать входящие в себя узлы и распределять мощности. При плановой подготовке к Чёрной Пятнице мы решили изменить правило распределения мощности для одного из микросервисов с фиксированного на авто-масштабируемый. Изменение конфигурации позволило бы более устойчиво работать со всплесками нагрузки.

При разработке решения мы не учли, что изменение распределения приведёт к более плотному размещению контейнеров, увеличит использование ресурсов и тем самым не сможет обеспечить достаточный запас мощности, который существует при фиксированном распределении.

В результате высокой нагрузки на CPU, системные компоненты, такие как локальный DNS, стали получать меньше вычислительного ресурса. Это привело к задержкам в обработке DNS-запросов, необходимых для установления соединения с сервером. Это в свою очередь привело к росту очереди обработки HTTP-запросов, служащих для обмена информацией между контейнерами. В свою очередь это привело к ещё большему увеличению нагрузки CPU и каскадному отказу.

Что улучшим

• Добавим резервирование ресурсов узлов и покроем мониторингом его наличие - 1й квартал 2025 года.
• Улучшим план миграции микросервисов между группами узлов с целью сделать процесс более плавным и минимизировать время восстановления в случае отказа или деградации - 1й квартал 2025 года.