Ранее наши коллеги уже освещали вопрос необходимости Enterprise Service Mesh в компании. В этой статье мы хотим подробнее рассказать об интеллектуальных сервисах, которые позволяют облегчить жизнь администраторам, повысить надёжность систем и сделать их быстрее.
В настоящий момент наш продукт включает в себя следующие сервисы:
Predictive Colocator – размещает связанные между собой приложения на одинаковых нодах, уменьшает задержку при передаче данных;
Discovery R&L – находит начальные лимиты (limit) и реквесты (request) для любых приложений с целью их гарантированного старта при применяемой конфигурации;
Anomaly Detection – выявляет аномалии в работе элементов облачной инфраструктуры;
Predictive Autoscaler – определяет будущую нагрузку на приложения, заранее поднимает или опускает необходимое количество подов.
В рамках этой статьи кратко рассмотрим некоторые аспекты работы двух сервисов: Predictive Autoscaler и Anomaly Detection.
Predictive Autoscaler
Перед тем как мы приступим к описанию, приведём небольшой пример. Представьте, что вы пришли вечером домой и захотели заварить чай. Вы включили чайник, чтобы вскипятить воду, но неожиданно электричество во всём районе отключилось. Этот пример в некотором смысле иллюстрирует ситуацию превышения потребления электроэнергии над её генерацией. Но одно дело, когда вы остались без чая, и совершенно другое, если где-то в больнице таким образом отключится аппарат ИВЛ.
Аналогичная ситуация может произойти и в облачной инфраструктуре, только вместо электрической нагрузки на сеть у нас будет пользовательская нагрузка на сервис по cpu и memory. Превышение лимитов нагрузки будет приводить к потере запросов. Для нас в Сбере ключевой является ценность «всё – для клиента», и мы не можем позволить себе терять запросы. Ведь под ними может скрываться любая ситуация из экосистемы Сбера – заказ такси опаздывающим на работу человеком, срочный банковский перевод для близких или просто вечерний просмотр сериала после тяжёлого рабочего дня. С другой же стороны, мы не можем постоянно держать завышенные лимиты, так как эти ресурсы всегда ограничены.
Решением в данной ситуации будет использование нашего сервиса Predictive Autoscaler, который в режиме реального времени позволяет определить необходимое количество подов приложения: при увеличении нагрузки оперативно поднять их недостающее количество, а при снижении – плавно опустить.
Описание алгоритма
Для предсказания количества подов приложения используются два ключевых алгоритма: стандартный Horizontal Pod Autoscaler (HPA) и Predictive Autoscaler (Рис.1).
В качестве входных данных Predictive Autoscaler использует временной ряд определённой метрики 'value' (например, 'cpu'), а также данные по ограничениям ресурсов пода ('pod_limit') и его желаемой загрузке ('ratio').
Расчёт количества подов в алгоритме HPA производится следующим образом: hpa_pods = value / (pod_limit * ratio). Результат округляется в большую сторону. Также накладывается ограничение в части минимального и максимального количества подов.
Predictive Autoscaler рассчитывает количество подов аналогично, однако вместо последнего фактического значения величины используется предсказанное значение: predicted_pods = prediction / (pod_limit * ratio).
Для обучения и предсказания модель принимает на вход несколько значений метрики из прошлого.
Для предсказания значений Predictive Autoscaler использует две модели – CatBoostModel (CBM) и Moving Average (MA) с некоторой шириной окна.
CatBoostModel – это модель градиентного бустинга на деревьях решений. Модель позволяет предсказать рост нагрузки, чтобы своевременно реагировать на неё поднятием дополнительных подов.
Из двух полученных значений выбирается максимальное. Таким образом, модель CBM позволяет быстро реагировать на рост нагрузки, а MA в свою очередь частично демпфирует колебания и не позволяет быстро опустить поды, что актуально при резкопеременном характере нагрузки.
Демонстрация работы алгоритма
Модель CBM позволяет предсказывать значение величины на основе данных, которые она видела при обучении. Это является преимуществом для обнаружения возрастающей нагрузки. При этом модель быстро реагирует на снижение нагрузки, что может негативно сказаться при её резкопеременном характере.
Скользящее среднее реагирует на рост нагрузки с большой задержкой, что не позволяет использовать его в качестве основной модели предсказания, однако реакция на снижение также медленная.
Использование комбинированной модели позволяет с высокой скоростью реагировать на рост нагрузки и при этом медленно реагировать на её снижение.
На рисунках ниже мы продемонстрировали влияние модели скользящего среднего на замедление реакции модели градиентного бустинга при снижении нагрузки.
Anomaly Detection
Микросервисная архитектура стала достаточно популярной за счёт её существенных преимуществ: масштабируемости, возможности использовать разные технологии и мультиплатформенности. Иногда микросервисы могут вести себя неадекватным образом из-за проблем, связанных, например, с инфраструктурой (проблемы с конкретной нодой в облаке), неполадками сети или большой единовременной нагрузкой. Для исправления подобных инцидентов есть поддержка. Однако бывают случаи, когда аномальное поведение видно не сразу, ведь сложно одновременно следить за работой сотен микросервисов. Система детектирования аномалий способна существенно сократить время устранения проблем в приложениях с микросервисной архитектурой за счёт автоматической идентификации и локализации аномалий. При возникновении аномалии заинтересованные люди будут мгновенно уведомлены.
Принцип работы
По каждому микросервису на основе метрик (загрузка процессора, памяти, количество байт, полученных и отправленных по сети, время ответа) алгоритм классификации предсказывает его статус.
Статусы определяются в зависимости от потребности бизнеса:
Normal – нормальное поведение сервиса;
Cpu_hop – значение CPU не соответствует текущему потоку запросов и потреблению памяти;
Memory_leak – значение memory не соответствует текущему потоку запросов и потреблению CPU;
Network_loss – потери запросов сервиса.
Достаточно полезным наблюдением для этой задачи является то, что микросервис, испытывающий какую-либо аномалию, отвечает не так быстро, как от него ожидают (Рис. 3). У него растёт метрика response time (время ответа микросервиса), но проблема заключается в том, что она увеличивается также и в случае повышения количества запросов. Больше нагрузка – сервис дольше отвечает. Тут в игру вступает наблюдение за другими метриками сервиса и их причинно-следственными связями с метрикой response time. Одним из возможных решений по разделению аномального и нормального поведения является рассмотрение корреляции метрики response time и метрики, отражающей количество запросов к микросервису. При повышении количества запросов к микросервису увеличивается и response time, значит между этими метриками растёт корреляция, но такое поведение не наблюдается в случае аномалии – там response time и количество запросов могут не коррелировать вообще. Метрика response time меняется в аномальном случае по другим причинам.
Root cause analysis (RCA)
Бывает такое, что один микросервис, испытывая проблемы, вызывает проблемы у других микросервисов (Рис. 4). Его аномальное поведение расползается на несколько зависимых сервисов по графу SOA (service-oriented architecture). Поэтому нужен отдельный класс алгоритмов для нахождения «корневой первопричины» аномального поведения, чтобы люди из поддержки могли быстро исправить возникшую неполадку в источнике, а не ходить по всем аномальным сервисам. Данную технологию мы тоже применили в Anomaly Detection. В целом RCA заслуживает отдельной статьи и будет описан в будущем.
Каждый сервис – это решение конкретной проблемы у администраторов, разработчиков и бизнеса. Наши интеллектуальные сервисы продолжают развиваться, и в скором будущем мы надеемся сделать Enterprise Service Mesh ещё стабильнее и надёжнее. Надеемся, что эта статья натолкнёт вас на мысли разработать и у себя в компании нечто подобное.
Авторы: Корст Ростислав Андреевич и Проничев Артём Валерьевич.
