0

Мы планируем иметь потребителя Kafka на Java в качестве демона, который должен обнюхать Kafka для сообщений, но хотел бы знать, как мы можем автомасштабировать этого демона (-ов). Пожалуйста, предложите лучший дизайн для этогоАвтоматический масштабируемый рабочий/демон в качестве потребителя Kafka

Пройдя через этого работника AWS, это хорошее решение?

ответ

1

Предполагаю, что вы говорите об окружающей среде EBS Worker. Рабочая среда EBS, работающая на SQS, не поможет в случае кафки.

Для пользователей, определенных для очередей kafka, вам необходимо определить пользовательскую стратегию автомасштабирования. Помимо встроенного масштабирования, управляемого метками ec2, облачным экраном и ASG, вам, возможно, придется опубликовать дополнительные показатели для облачного просмотра, что позволит вам определить триггеры для автомасштабирования. С помощью предупреждений о всплытии вы можете настроить функции лямбда-поддержки, которые могут выполнять автомасштабирование. Конечно, приведенный выше упрощенный способ реализации масштабирования позволяет реализовать что-то, что работает для вашей среды.

Длина очереди (расход сообщения) является хорошей метрикой, которую следует учитывать при масштабировании, вы должны проставлять масштаб на длину очереди. Это должно быть дополнительным к масштабированию на основе CPU, IO и других критериев.

+0

Если нет работника Ebs, есть ли какой-либо потребитель Kafka, где я могу реализовать автомасштабирование ... просьба предложить – shiv455

+0

Нет .. вам нужно будет создать собственный ур – Shibashis

+0

Итак, вы имеете в виду, что cloudwatch запускает функцию лямбда, чтобы развернуть экземпляры ec2 на основе показателей как процессор или другие показатели? Нужна ли нам какая-либо группа автообновления? – shiv455