Версия сайта для слабовидящих
Что лучше: один или несколько кластеров Apache Kafka, когда и зачем разворачивать новый кластер вместо масштабирования существующего, какие задачи администрирования поручить локальным DevOps-инженерам, а что решать централизовано.
Один или несколько кластеров Apache Kafka?
Продолжая разговор про эффективное управление корпоративным кластером Apache Kafka, сегодня рассмотрим, когда и зачем нужно разворачивать новый кластер вместо масштабирования существующего. Хотя платформа отлично поддерживает горизонтальное масштабирование, безопасный физический предел одного кластера составляет около 200 000 разделов всего или 4000 разделов на один брокер. Разумеется, эти показатели могут быть выше при использовании высокопроизводительного оборудования, в т.ч. пропускная способность сети, выделенное хранилище, процессор и память. В любом случае, запускать слишком много приложений-продюсеров и потребителей в одном кластере Kafka может привести к нарушению SLA по задержке обработки данных из-за большой вариативности сценариев использования.
Поэтому вескими причинами для использования нескольких кластеров Kafka будут следующие:
- строгие правила изоляции данных, которые нельзя смешивать, например, персональных данные клиентов или сотрудников, данные платежных карт и пр. требуют очень высоких гарантий безопасности;
- распределение по разным географическим регионам. Чтобы сократить время обработки данных проще иметь отдельный кластер Kafka в каждом регионе, где работают приложения.
- Разные требования к доступности данных. RPO, RTO и SLA могут сильно отличаться для различных конвейеров потоковой обработки. Поэтому разные кластера Apache Kafka проще настроить по-разному для различных бизнес-подразделения и приложений независимо друг от друга, с теми настройками, которые подходят лучше всего для конкретного случая.
При развертывании нескольких изолированных кластеров, которые не могут обмениваться данными, возрастает количество хранилищ, которые нужно администрировать и сопровождать. С другой стороны, преимуществом одного кластера Kafka будет более быстрая обработка данных и простота централизованного управления, о чем мы писали в прошлый раз.
Таким образом, администратору кластера Kafka надо найти баланс между количеством кластеров, развернутых в локальной инфраструктуре компании или в облаке. Сократить расходы на обслуживание нескольких больших кластеров, которые используются многими корпоративными приложениями, поможет сервисный подход (KaaS, Kafka as a Service). Чтобы внедрить его, прежде всего, следует определить общие компоненты любого кластера Kafka: брокеры, Apache ZooKeeper и реестр схем (Schema Registry). А такие компоненты, как ACL-списки управления доступом, пользователи, сертификаты TLS, хранилище и схемы данных могут различаться от кластера к кластеру, но вполне могут управляться одной командой администраторов.
Как организовать процессы управления кластерами и общими службами?
Если не все управление корпоративными кластерами централизовано и локальные администраторы (DevOps-инженеры), эксплуатирующие Kafka, могут задавать собственные настройки, надо ограничить их пороговыми значениями. Например, задать допустимый лимит количества топиков, которые можно создавать в день, срок и объем хранения данных в них, а также установить максимальную пропускную способность. Обеспечить соблюдение квот потребления пропускной способности для каждой команды можно с помощью механизма квотирования, о котором мы писали здесь. Это позволит равномерно утилизировать ресурсы кластера, чтобы каждая команда разработчиков приложений не могла потреблять больше, чем ей выделено.
Аналогичным образом следует решить вопрос с автоматическим масштабированием, чтобы с помощью внешних (по отношению к Kafka) инструментов системного администрирования иметь возможность выделять или освобождать вычислительные ресурсы, (память, ЦП и дисковое пространство) пропорционально трафику сообщений и без прямого вмешательства человека. Поскольку Kafka отлично поддерживает горизонтальное масштабирование, можно добавить больше узлов-брокеров в существующие кластеры или сократить их количество при снижении нагрузки. Особенно удобно делать это при развертывании Kafka в виде контейнера на платформе Kubernetes, что мы разбирали в этом материале.
Можно повысить пропускную способность кластера, добавив больше разделов в топик, чтобы потреблять данные несколькими параллельными потребителями, если общий хронологический порядок сообщений не важен. Поскольку Kafka гарантирует упорядоченность сообщений только в рамках раздела, изменение количества разделов в уже существующем топике приведет к потере хронологии событий. Также придется заранее определить количество разделов для топика с учетом количества экземпляров приложений-потребителей, т.к. число разделов в топиках Kafka не меняется автоматически по числу развернутых приложений-потребителей. Впрочем, можно определить количество разделов топика Kafka по следующему набору эмпирических правил:
- в общем случае количество разделов должно быть больше или равно количества экземпляров приложений-потребителей;
- в периоды низкой нагрузки количество разделов должно превышать количество экземпляров потребителей;
- в периоды пиковой нагрузки количество разделов должно быть равно количество экземпляров потребителей;
- количество разделов обычно растет с увеличением бизнеса.
В качестве инструментов самообслуживания для настройки кластера Kafka в соответствии с требованиями конкретной команды, централизованная служба сопровождения обычно предоставляет локальным Devops-инженерам соответствующие интерфейсы: API, CLI или GUI, интегрированные со средствами CI/CD. Таким образом, локальные Devops-инженеры могут управлять операциями в своих кластерах Kafka, настраивать и администрировать их, а также запрашивать ресурсы у глобальной команды сопровождения KaaS-решения.
Кроме этого, в зоне ответственности локального DevOps-инженера остается управление схемами данных, которые описываю структуру сообщений интеграционного обмена между приложениями-продюсерами и потребителями. Если топик и схемы данных используются одной командой, они могут оставаться полностью приватными, когда все права доступа имеет лишь команда-владелец данных.
Но в случае распределенного между разными командами использования данных в кластере Kafka следует тщательно продумать процесс управления ими. Для этого можно использовать подход федеративного управления вычислениями в сетке данных (Data Mesh), поддоменами которой являются кластеры Kafka, управляемые локальными командами.
В заключение отметим важность эффективного управления кластером с точки зрения экономики. Какие инфраструктурные компоненты являются самыми дорогими в эксплуатации популярной платформы потоковой передачи сообщений и как снизить затраты на сетевые ресурсы и хранилища данных при использовании Apache Kafka, вы узнаете в нашей новой статье. А здесь мы рассматриваем геораспределенную репликацию кластеров.
Освойте администрирование и эксплуатацию Apache Kafka для потоковой аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
- Apache Kafka для инженеров данных
- Администрирование кластера Kafka
- Администрирование Arenadata Streaming Kafka
Источники
