Введение
В приложении на основе Kafka сообщения для определенных тем генерируются некоторыми производителями и отправляются брокерам Kafka. Брокеры выполняют необходимые репликации и распространяют сообщения среди потребителей соответствующих тем. После получения сообщений от брокеров потребитель выполняет некоторые задачи и сообщает брокерам, что сообщения были зафиксированы (или потреблены). Смотрители хранят смещение последнего сообщения, отправленного производителем для темы, и смещение последнего зафиксированного сообщения, сообщенного потребителем для темы.
При всплеске сообщений, получаемых брокерами, сообщения будут храниться в очередях дольше, если потребитель не сможет обработать их достаточно быстро, что повлияет на общую производительность приложения. Чтобы справиться с динамической природой скорости производства сообщений, HPA или Horizontal Pod Autotscalling of the Kafka Consumers используется для масштабирования количества Kafka Consumers таким образом, чтобы скорости производства и потребления темы соответствовали друг другу при использовании разумного количества реплик потребителей (минимизация затрат на ресурсы).
В то же время HPA также необходимо поддерживать низкую задержку обработки сообщений, что является KPI или ключевым показателем производительности Kafka Consumers. В частности, мы калибруем количество реплик с учетом следующих компромиссов:
Длительная задержка при недостаточном количестве потребителей
Слишком большое количество потребителей приводит к нерациональному использованию ресурсов.
В этой статье показано, что нативные алгоритмы Kubernetes HPA (механизм K8sHPA), основанные либо на использовании ресурсов, либо на KPI, приводят к скромной экономии и гораздо большим задержкам (latency). Federator.ai от ProphetStor использует технологии Machine Learning для прогнозирования и анализа рабочей нагрузки Kafka, а также для рекомендации количества потребительских реплик, учитывая выгоду и затраты при корректировке. Federaor.ai достигает гораздо лучшей производительности (уменьшение задержки) при гораздо меньшем количестве ресурсов (уменьшение количества потребителей в Kafka), и все это без изменения механизма K8sHPA или строчки кода Kafka. Это делает реализацию автомасштабирования потребителей Kafka простой и понятной.
Масштабирование с помощью Kubernetes Native HPA и KEDA
Контроллер HPA Kubernetes - это контроллер, который может определять количество стручков развертывания, набор реплик или набор состояний. Контроллер HPA измеряет соответствующие метрики, чтобы определить количество капсул, необходимых для удовлетворения критериев, определенных в конфигурации HPA, которая реализуется как ресурс API с информацией типа desiredMetricValue. Собственный контроллер HPA поддерживает следующие типы метрик для определения масштабирования:
Метрики ресурсов для каждого POD - метрики ресурсов, такие как использование процессора, представлены как метрики использования или необработанные метрики в зависимости от выбора desiredMetricValue. Контроллер получает метрики из соответствующих подсистем и вычисляет среднее значение как currentMetricValue. Затем с помощью приведенной ниже формулы можно рассчитать желаемое количество капсул, т.е. желаемое количество реплик (desiredReplicas).
Пользовательские метрики для каждого POD - пользовательские метрики, такие как байты сетевого приема, рассматриваются как необработанные метрики. Контроллер выполняет ту же функцию, что и в случае с метриками ресурсов для каждого блока, чтобы определить желаемыеReplicas.
Метрики ресурсов на контейнер - метрики ресурсов, такие как использование процессора, конкретного контейнера (а не всего стручка) всех соответствующих стручков используются для определения текущего значения метрики (currentMetricValue).
Внешняя метрика - метрика, специфичная для приложения, например, задержка или другой KPI, рассматривается как необработанная метрика. По желанию, в версии API autoscaling/v2beta2 контроллер может также разделить внешнюю метрику на количество стручков как currentMetricValue перед применением алгоритма ниже.
Множественные метрики - в версии API autoscaling/v2beta2 поддерживаются множественные метрики. Контроллер рассчитывает desiredReplicas для каждой метрики, как указано выше, и использует наибольшее значение desiredReplicas для масштабирования.