Зачем разделять компоненты Kafka: кластерная DevOps-архитектура

В продолжение темы про проявление Agile-принципов в Big Data системах, сегодня мы рассмотрим, как DevOps-подход отражается в использовании Apache Kafka. Читайте в нашей статье про кластерную архитектуру коннекторов Кафка и KSQL – SQL-движка на основе API клиентской библиотеки Kafka Streams для аналитики больших данных, о которой мы рассказывали здесь.

Из чего сделана Apache Kafka: 6 базовых компонентов

Apache Kafka – это не просто брокер сообщений, а полноценная стриминговая платформа для сбора, агрегации и обработки больших данных, включающая следующие компоненты [1]:

ядро распределенного обмена сообщениями и хранения Big Data, обеспечивающее мощную пропускную способность, низкую задержку (latency), высокую доступность и безопасность;
Kafka Connect – интеграционная структура для подключения внешних источников и приемников к Кафка;
Kafka Streams – клиентская библиотека для создания распределенных приложений для работы с потоковыми данными, хранящимися в кластерах Кафка;
дополнительные клиенты для не-Java подобных языков программирования, включая C, C ++, Python, .NET, Go и др.;
Schema Registry как центральный реестр форматов данных, поддерживающий эволюцию схем;
KSQL как механизм потокового SQL-движка, который позволяет масштабируемую потоковую обработку Big Data в Кафка с помощью SQL-подобных запросов без написания Java-кода.

5 DevOps-причин разделения кластеров Kафка

Все вышеперечисленные компоненты основаны на базовом уровне обмена сообщениями и хранения данных в Apache Kafka, включая обеспечение высокой масштабируемости, высокой пропускной способности, отказоустойчивости и прочих достоинств этой стриминговой платформы.

Тем не менее, при практическом развертывании Кафка в реальных Big Data проектах компоненты Кафка-экосистемы находятся не на одном кластере, а разделяются по нескольким. Рассмотрим, какие выгоды дает такая мультикластерная архитектура на примере KSQL и Kafka Connect [2]:

изоляция ресурсов, которая облегчает планирование мощностей, независимость коннекторов от внезапного изменения характера притока данных из отдельного источника, а также ребалансировку нагрузки при добавлении или удалении коннекторов, с сохранением производительности других коннекторов в том же кластере;
разделение сред по стадиям разработки, например, один кластер для production, другой для разработки и тестирования;
разделение владения и ответственности за операции, включая предотвращения антипаттерна использования Кафка в качестве сервисной шины предприятия — enterprise service bus, ESB;
разделение приложений, к примеру, с помощью Kafka Streams можно локально разрабатывать приложения для потоковой обработки распределенных данных, или использовать KSQL для создания сервисов, состоящих из дискретного набора SQL-операторов;
безопасность через предоставления различных прав доступа к топикам, приложениям и конвейерам обработки данных для серверов KSQL и Connect, т.к. они аутентифицируются в кластере Кафка как отдельный пользователь.

Все эти аспекты соответствуют DevOps-практикам, нацеленных на повышение эффективности процессов разработки (Development) и эксплуатации (Operation) ПО за счет непрерывной интеграции, автоматизации и активного взаимодействия профильных специалистов. Также DevOps-подход поддерживает Agile-принципы, предназначенных для ускорения итераций по выпуску надежного продукта [3].

Отдельно стоит сказать о практике использования Apache Kafka в качестве ESB-шины Сегодня это считается антипаттерном применения Кафка, поскольку централизует компоненты экосистемы, такие как коннекторы и потоковые обработчики (streams processors), образуя монолитное решение. Оптимальным вариантом считается сервисный подход, когда компоненты Кафка-платформы работают вместе, но не привязаны к друг другу на жестком уровне. Это означает, что заменить какой-то из них можно в любой момент без нанесения ущерба всей Big Data системе [4]. Такой сервисный подход без монолитной привязки компонентов друг к другу и командам разработки также соответствует принципам DevOps. Подробнее про архитектурные подходы к построению Big Data приложений и интеграции корпоративных систем читайте в следующей статье.

Как на практике эффективно использовать компоненты стриминговой платформы Apache Kafka для потоковой обработки больших данных, вы узнаете на практических курсах по Кафка в нашем лицензированном учебном центре повышения квалификации и обучения руководителей и ИТ-специалистов (разработчиков, архитекторов, инженеров и аналитиков Big Data) в Москве:

Смотреть расписание

Записаться на курс

Источники