Освоение многокластерного развертывания и репликации с помощью Kafka

Краткий обзор Apache Kafka и распространенных вариантов использования, текущих инструментов для масштабирования многокластерных развертываний и решений по подключению для упрощения многокластерных развертываний. Оглавление Что такое Кафка? Кафка и Кубернетес Аргументы в пользу мультикластерной Kafka Мультикластер Кафка Растянутые кластеры — синхронная репликация Подключенные кластеры — асинхронная репликация Заключение Что такое Кафка? Apache Kafka, широко известный просто как , представляет собой платформу потоковой передачи событий с открытым исходным кодом, поддерживаемую Apache Software Foundation. Первоначально задуманный в , Apache Kafka был совместно создан , и , а затем выпущен как проект с открытым исходным кодом в 2011 году. Kafka LinkedIn Джеем Крепсом Нехой Наркхеде Джун Рао Wiki-страница Сегодня Kafka — одна из самых популярных платформ потоковой передачи событий, предназначенная для обработки потоков данных в реальном времени. Он широко используется для создания масштабируемых, отказоустойчивых и высокопроизводительных конвейеров потоковой передачи данных. Область применения Кафки постоянно расширяется: пять основных случаев прекрасно проиллюстрированы на сопроводительном изображении. Бриджем Панди Вкратце, важно понимать компоненты платформы Kafka и то, как они работают. Kafka работает как распределенная платформа потоковой передачи событий, предназначенная для эффективной обработки потоков данных в реальном времени. Он работает на основе модели обмена сообщениями «публикация-подписка» и следует распределенной и отказоустойчивой архитектуре. Он поддерживает постоянную, упорядоченную и разделенную последовательность записей, называемую «темами». Производители записывают данные в эти темы, а потребители читают их. Это обеспечивает развязку между производителями и потребителями данных и позволяет нескольким приложениям независимо использовать один и тот же поток данных. Ключевые компоненты Kafka включают в себя: Kafka организует данные по темам. Каждая тема представляет собой поток записей, а данные внутри темы разделены на несколько разделов. Каждый раздел представляет собой упорядоченную последовательность записей. Разделы обеспечивают горизонтальную масштабируемость и параллелизм, позволяя распределять данные между несколькими брокерами Kafka. Темы и разделы: неизменяемую : Продюсеры — это приложения, которые записывают данные в темы Kafka. Они публикуют записи по определенным темам, которые затем сохраняются в разделах темы. Производители могут явно отправлять записи в конкретный раздел или позволить Kafka определить раздел, используя стратегию секционирования. Продюсеры : Потребители — это приложения, которые читают данные из тем Kafka. Они подписываются на одну или несколько тем и используют записи из разделов, которым они назначены. Группы потребителей используются для масштабирования потребления, и каждый раздел в теме может использоваться только одним потребителем в группе. Это позволяет нескольким потребителям работать параллельно для обработки данных из разных разделов одной темы. Потребители : Kafka работает как кластер серверов, и каждый сервер называется брокером. Брокеры отвечают за обработку запросов на чтение и запись от производителей и потребителей, а также за управление разделами тем. Кластер Kafka может иметь несколько брокеров для распределения нагрузки и обеспечения отказоустойчивости. Брокеры . Чтобы обеспечить отказоустойчивость и надежность данных, Kafka позволяет настраивать репликацию для тематических разделов. Каждый раздел может иметь несколько реплик, причем одна реплика назначается ведущей, а остальные — ведомыми. Реплика-лидер обрабатывает все запросы на чтение и запись для этого раздела, а ведомые реплики реплицируют данные от лидера, чтобы оставаться синхронизированными. Если брокер с репликой-лидером выходит из строя, один из ведомых автоматически становится новым лидером, чтобы обеспечить непрерывную работу. Разделы/Репликация : Kafka поддерживает концепцию смещений для каждого раздела. Смещение представляет собой уникальный идентификатор записи внутри раздела. Потребители отслеживают свое текущее возмещение, что позволяет им возобновить потребление с того места, где они остановились, в случае сбоя или повторной обработки. Управление смещениями : Хотя ZooKeeper не является частью самого Kafka, он часто используется для управления метаданными и координации брокеров в кластере Kafka. Это помогает с выбором лидера, информацией о темах и разделах, а также с управлением координацией групп потребителей. [Примечание: ] ZooKeeper инструмент управления метаданными Zookeeper скоро будет заменен или KRaft, протоколом для внутреннего управления метаданными Kafka Raft В целом дизайн и архитектура Kafka делают ее высокомасштабируемой, отказоустойчивой и эффективной платформой для обработки больших объемов потоков данных в реальном времени. Он стал центральным компонентом во многих приложениях, управляемых данными, и инфраструктуре данных, облегчая интеграцию данных, обработку событий и потоковую аналитику. Тогда типичная архитектура Kafka будет следующей: Кластеризация Kafka — это практика совместной работы нескольких брокеров Kafka как группы для формирования кластера Kafka. Кластеризация — это фундаментальный аспект архитектуры Kafka, обеспечивающий ряд преимуществ, включая масштабируемость, отказоустойчивость и высокую доступность. Кластер Kafka используется для обработки крупномасштабных потоков данных и обеспечения работоспособности системы даже в случае сбоев. В кластере темы Kafka разделены на несколько разделов для достижения масштабируемости и параллелизма. Каждый раздел представляет собой линейно упорядоченную неизменяемую последовательность записей. Таким образом, разделы позволяют распределять данные между несколькими брокерами в кластере. Следует отметить, что минимальный кластер Kafka состоит из 3 брокеров Kafka, каждый из которых может быть запущен на отдельном сервере (виртуальном или физическом). Рекомендации по 3 узлам призваны помочь избежать сценария разделения мозга в случае сбоя брокера. Кафка и Кубернетес По мере того, как все больше компаний внедряют Kafka, растет и интерес к развертыванию Kafka в Kubernetes. Фактически, последний показывает, что более 40% крупных организаций используют свои платформы обмена сообщениями с открытым исходным кодом внутри , причем большинство из них — Kafka. отчет Dynatrace Kubernetes in the Wild за 2023 год Kubernetes . Источник В том же отчете также делается смелое заявление о том, что «Kubernetes становится «операционной системой» облака». В таком случае администраторам Kafka крайне важно понимать взаимодействие между Kafka и Kubernetes и то, как реализовать их в соответствии с масштабом. Аргументы в пользу мультикластерной Kafka Запуск кластера Kafka в единой установке кластера Kubernetes довольно прост и обеспечивает масштабируемость, необходимую теоретически. Однако в производстве картина может стать немного мрачной. Нам следует различать использование термина между Kafka и Kubernetes. В развертывании Kubernetes также используется термин для обозначения группы подключенных узлов, называемой кластером Kubernetes. Когда рабочая нагрузка Kafka будет развернута в Kubernetes, вы получите кластер Kafka, работающий внутри кластера Kubernetes, но, что более важно для нашего обсуждения, у вас также может быть кластер Kafka, охватывающий несколько кластеров Kubernetes — для обеспечения устойчивости, производительности и суверенитета данных. и т. д. кластер «кластер» Начнем с того, что Kafka не предназначен для мультитенантных установок. С технической точки зрения Kafka не понимает таких концепций, как пространства имен Kubernetes или изоляция ресурсов. В рамках конкретной темы не существует простого механизма для обеспечения соблюдения ограничений доступа безопасности между несколькими группами пользователей. Кроме того, разные рабочие нагрузки могут иметь разную частоту обновления и требования к масштабированию, например пакетное приложение или приложение реального времени. Объединение двух рабочих нагрузок в один кластер может привести к негативным последствиям или потребовать гораздо больше ресурсов, чем необходимо. Суверенитет данных и соответствие нормативным требованиям также могут налагать ограничения на совместное размещение данных и тем в определенном регионе или приложении. Отказоустойчивость, конечно, является еще одной сильной движущей силой необходимости создания нескольких кластеров Kafka. Хотя кластеры Kafka разработаны с учетом отказоустойчивости тем, нам все равно приходится планировать катастрофический сбой всего кластера. В таких случаях необходимость в полностью реплицированном кластере позволяет правильно планировать непрерывность бизнеса. Для компаний, которые переносят рабочую нагрузку в облако или придерживаются стратегии гибридного облака, вам может потребоваться настроить несколько кластеров Kafka и выполнить запланированную миграцию рабочей нагрузки с течением времени, а не рискованную полномасштабную миграцию Kafka. Это лишь некоторые из причин, по которым на практике предприятиям приходится создавать несколько кластеров Kafka, которым, тем не менее, необходимо взаимодействовать друг с другом. Мультикластер Кафка Чтобы иметь несколько кластеров Kafka, связанных друг с другом, ключевые элементы из одного кластера должны быть реплицированы в другие кластеры. К ним относятся темы, смещения и метаданные. В терминах Кафки это дублирование называется зеркалированием. Возможны два подхода к созданию мультикластеров. или Растянутые кластеры связанные кластеры. Растянутые кластеры — синхронная репликация Растянутый кластер — это логический кластер, «растянутый» на несколько физических кластеров. Топики и реплики распределены по физическим кластерам, но поскольку они представлены в виде логического кластера, сами приложения не знают об этой множественности. Растянутые кластеры обладают высокой согласованностью, ими легче управлять и администрировать. Поскольку приложения не знают о существовании нескольких кластеров, их легче развертывать в растянутых кластерах по сравнению с подключенными кластерами. Недостатком растянутых кластеров является то, что требуется синхронное соединение между кластерами. Они не идеальны для развертывания гибридного облака и потребуют кворума как минимум из 3 кластеров, чтобы избежать сценария «разделения мозгов». Подключенные кластеры — асинхронная репликация С другой стороны, подключенный кластер развертывается путем подключения нескольких независимых кластеров. Эти независимые кластеры могут работать в разных регионах или на облачных платформах и управляться индивидуально. Основное преимущество модели подключенного кластера заключается в отсутствии простоев в случае сбоя кластера, поскольку другие кластеры работают независимо. Каждый кластер также можно оптимизировать для своих конкретных ресурсов. Основным недостатком подключенных кластеров является то, что они полагаются на асинхронное соединение между кластерами. Темы, которые реплицируются между кластерами, не являются «копированием при записи», а скорее зависят от Это может привести к возможной потере данных во время процесса асинхронного зеркалирования. конечной согласованности. Кроме того, приложения, работающие в подключенных кластерах, необходимо модифицировать, чтобы они учитывали наличие нескольких кластеров. Прежде чем мы обратимся к решению этой загадки, я кратко расскажу об распространенных на рынке инструментах, обеспечивающих возможность подключения к кластеру Kafka. Сама Kafka с открытым исходным кодом поставляется с инструментом зеркалирования под названием Mirror Maker. Mirror Maker дублирует темы между разными кластерами с помощью встроенного производителя. Таким образом, данные перекрестно реплицируются между кластерами с конечной согласованностью, но без прерывания отдельных процессов. Важно отметить, что, хотя концепция Mirror Maker проста, настройка Mirror Maker в большом масштабе может оказаться довольно сложной задачей для ИТ-организаций. Управление IP-адресами, соглашениями об именах, количеством реплик и т. д. должно выполняться правильно, иначе это может привести к так называемой «бесконечной репликации», когда тема бесконечно реплицируется, что в конечном итоге приведет к сбою. Другим недостатком Mirror Maker является отсутствие динамической настройки списков разрешенных/запрещенных обновлений. Mirror Maker также не синхронизирует свойства тем должным образом, что усложняет работу при добавлении или удалении тем, подлежащих репликации. Mirror Maker 2 пытается решить некоторые из этих проблем, но многие ИТ-магазины все еще не могут правильно настроить Mirror Maker. Другие инструменты с открытым исходным кодом для репликации Kafka включают Mirus от Salesforce, uReplicator от Uber и настроенный Flink от . Netflix Для коммерческих лицензированных вариантов Confluent предлагает два варианта: Confluent Replicator и Cluster Linking. Confluent Replicator — это, по сути, соединитель Kafka Connect, который обеспечивает высокопроизводительный и надежный способ копирования данных тем между кластерами. Cluster Linking — это еще одно предложение, разработанное внутри компании и нацеленное на репликацию в нескольких регионах с сохранением смещения тем. Тем не менее, Cluster Linking — это инструмент асинхронной репликации, при котором данные должны пересекать границы сети и общедоступные каналы трафика. Как уже должно быть понятно, репликация Kafka — это важнейшая стратегия для масштабных производственных приложений, вопрос в том, какой вариант выбрать. Творческие администраторы Kafka быстро поймут, что вам могут понадобиться подключенные кластеры и расширенные кластеры или комбинация этих развертываний, в зависимости от требований к производительности и отказоустойчивости приложения. Однако что пугает, так это экспоненциальные проблемы настройки конфигураций кластера и управления ими в масштабе нескольких кластеров. Какой более элегантный способ решить этот кошмар? от Avesha — это простой способ получить лучшее из обоих миров. Создавая прямое между кластерами или пространствами имен, KubeSlice устраняет необходимость ручной настройки индивидуального соединения между кластерами Kafka. KubeSlice соединение служб По своей сути создает безопасный синхронный сетевой шлюз уровня 3 между кластерами; изолированы на уровне приложения или пространства имен. После настройки администраторы Kafka могут свободно развертывать брокеров Kafka в любом из кластеров. KubeSlice Каждый брокер имеет синхронное подключение к любому другому брокеру, к которому присоединен через срез, даже если сами брокеры могут находиться в отдельных кластерах. Это эффективно создает растянутый кластер между брокерами и обеспечивает высокую согласованность и низкие административные расходы. Возьми свой торт и съешь его тоже! Тем, кто хочет развернуть Mirror Maker в своих кластерах, это можно сделать с минимальными усилиями, поскольку подключение между кластерами делегируется KubeSlice. Таким образом, приложения Kafka могут иметь преимущества синхронной (скорость, отказоустойчивость) И асинхронной (независимость, масштабируемость) репликации в одном и том же развертывании с возможностью смешивать и сопоставлять возможности по мере необходимости. Это справедливо для локальных центров обработки данных, общедоступных облаков или любых их комбинаций в гибридной установке. Самое приятное то, что KubeSlice обеспечивает развертывание без прерывания работы, а это означает, что нет необходимости удалять какой-либо уже развернутый инструмент. Это просто вопрос создания и добавления в него Kafka. фрагмента развертывания Заключение В этом блоге представлен краткий обзор Apache Kafka и затронуты некоторые наиболее распространенные варианты использования. Мы рассмотрели текущие инструменты, доступные для масштабирования развертываний Kafka в нескольких кластерах, и обсудили преимущества и недостатки каждого из них. Наконец, в статье также представлен Kubeslice — новое решение для подключения служб, которое упрощает развертывание нескольких кластеров Kafka и устраняет головную боль, связанную с настройкой репликации Kafka между несколькими кластерами в любом масштабе. Пара ссылок, которые читателям могут оказаться полезными: (до появления KubeSlice). Старый блог с лучшими практиками использования Kafka на AWS Пошаговая настройка KubeSlice Развертывание Kafka на GKE Также опубликовано здесь.