Миграция с Confluent на Redpanda в один клик с помощью Shadowing

TL;DR: Раньше миграция с Confluent означала использование MirrorMaker, пользовательских скриптов и рискованных выходных с полным переключением. Начиная с версии 26.2, это в прошлом. Функция Redpanda Shadowing теперь поддерживает создание живой реплики кластера Confluent Cloud или Confluent Platform (а также любого источника Apache Kafka), передавая данные топиков, схемы, оффсеты и ACL по одной ссылке. Это позволяет сначала протестировать реальные рабочие нагрузки, а затем переключать приложения по одному в удобном для вас темпе. Уже доступно в Redpanda Self-Managed 26.2, а также в Redpanda Cloud BYOC и Dedicated.

Сделка по покупке Confluent компанией IBM, завершившаяся в марте 2026 года, побудила команды разработчиков платформ заново оценить поставщиков потоковых данных и пересмотреть долгосрочные стратегии. Большинство наблюдателей ожидают, что IBM направит дорожную карту потоковой передачи данных в сторону закрытой экосистемы в стиле «чисто от IBM», а не независимого специалиста по современному мидлверу, каким был Confluent.

От команд потоковой передачи данных, пересматривающих свой стек, мы редко слышим: «мы не уверены, что Redpanda лучше». Чаще звучит: «мы знаем, что она лучше, но миграция выглядит рискованной, и мы не можем включить ее в план». Это вполне здравый взгляд.

Исторически миграция с Confluent означала развертывание отдельного стека репликации с помощью MirrorMaker (на базе Kafka Connect), работу с транслированными оффсетами, самостоятельную миграцию Schema Registry на стороне и ставку всего бизнеса на рискованный уик-энд с полным переключением. Слишком много движущихся частей и точек отказа, из-за чего проект буксует, а модернизация откладывается еще на квартал.

Функция Redpanda Shadowing в версии 26.2 устраняет этот риск. Shadowing — это встроенная в брокер функция репликации с сохранением оффсетов и полной точностью данных, которую клиенты Redpanda уже используют для аварийного восстановления (DR), миграции оборудования и распространения данных между регионами облака и дата-центрами. В версии 26.2 исходным кластером также может быть Confluent Cloud, Confluent Platform или любой кластер, совместимый с Kafka, с использованием открытого исходного кода Schema Registry. В результате получается неспешная параллельная миграция, которая гарантирует, что все устаревшие приложения Confluent продолжат работу без сбоев.

Почему Schema Registry была элементом, из-за которого все останавливалось

В плане миграции все внимание приковано к топикам, и это справедливо. Именно там хранятся данные, но именно Schema Registry обычно тормозит весь проект. Это последний компонент, который кто-либо оценивает. Он находится между каждым продюсером и каждым консьюмером, а команды приложений постоянно развивают общие контракты данных. Ошибка здесь может сломать все приложения сразу, а не только те, которые используют конкретный топик.

Раньше это делалось вручную следующим образом: выгрузить каждый субъект из Confluent Schema Registry с помощью скрипта. Загрузить их в новый реестр, соблюдая порядок зависимостей. Ошиблись в ссылке — импорт не удался. Перенастроить параметры совместимости для каждого субъекта, потому что они не переносятся автоматически. Затем выровнять ID, так как формат передачи данных зашивает ID схемы в каждую запись, и ваши консьюмеры с радостью будут десериализовать мусор, если эти ID не совпадают. Затем повторить все сначала, пока вы писали скрипт, схемы продолжали меняться.

Redpanda Migrator в составе Redpanda Connect частично упростил эту задачу, но это все равно был еще один развертываемый компонент, который нужно настраивать, защищать и обслуживать на протяжении всей миграции. Для многих команд, управляющих критически важной инфраструктурой потоковой передачи, период параллельной миграции без простоя (с полным циклом тестирования приложений посередине) создавал избыточную сложность, из-за чего проект бесконечно откладывался на «следующий квартал».

Shadowing уже умел реплицировать схемы. Теперь он синхронизирует их из любого кластера Confluent.

Репликация схем в режиме «байт-в-байт» между кластерами Redpanda уже работала в предыдущих версиях путем создания тени внутреннего топика _schemas. Нововведением версии 26.2 является репликация Schema Registry в режиме API. Вместо обязательного использования источника Redpanda, теневой кластер опрашивает любой реестр, поддерживающий стандартный REST API Schema Registry (включая Confluent и Kafka). Затем Shadowing импортирует все субъекты, версии и настройки совместимости непосредственно во встроенный Schema Registry от Redpanda.

Под капотом Shadowing работает на основе запросов на вытягивание (pull). Каждый брокер в теневом кластере выполняет задачи репликации, которые получают данные из источника через стандартные API Kafka и Schema Registry. Теперь вся миграция выполняется по одной ссылке: данные топиков со стороны Kafka, схемы со стороны реестра, а также оффсеты потребителей и ACL рядом с ними. Один файл конфигурации, мастер в пользовательском интерфейсе, Kubernetes CRD или модуль Terraform для заполнения и автоматизации. Выбирайте то, что вам по душе.

Половина конфигурации, отвечающая за реестр схем, выглядит максимально просто:

Здесь два цикла синхронизации поддерживают актуальность реестров. Инкрементная синхронизация (tail sync) запускается по умолчанию каждые 10 секунд и улавливает точечные изменения. Полная синхронизация (full sync) сканирует все выбранные субъекты каждые пять минут, чтобы подхватить все, что было пропущено инкрементной синхронизацией. Предусмотрен настраиваемый лимит частоты запросов (max_source_requests_per_second, по умолчанию 30), чтобы не перегружать исходный реестр. Это важнее, чем кажется, особенно когда источником является реестр Confluent Cloud, за использование которого вы платите.

Несколько свойств, которые делают эту функцию мощной, а не просто работоспособной:

• Имена субъектов и ID версий сохраняются. Продюсеры и консьюмеры, определяющие схемы по ID, продолжают работать после переключения. Именно этот момент часто нарушается при ручной миграции.
• Ссылки между схемами импортируются в порядке зависимостей. Субъекты, ссылающиеся на другие субъекты, разрешаются корректно. Поддерживается репликация сложных иерархических схем Avro, Protobuf и JSON Schema.
• Схемы проверяются при импорте. Перед импортом Redpanda проверяет каждую схему на соответствие собственной реализации Schema Registry. Некоторые специфичные для Confluent расширения (наборы правил, теги метаданных, группы совместимости) не имеют аналогов в Redpanda. Если такое расширение обнаруживается, режим FAIL (по умолчанию) пропускает эту схему и сообщает об ошибке; режим REMOVE удаляет неподдерживаемые поля и импортирует остальное без сбоя миграции. В любом случае вы узнаете об этом во время контролируемой синхронизации, а не в момент необратимого переключения.
• На время действия ссылки запись в целевой объект блокируется. Как и в случае с данными топиков, Redpanda отклоняет клиентские записи в контексты схем, которыми управляет активная теневая ссылка, поэтому оба реестра не могут разойтись в процессе миграции. Контексты за пределами фильтра ссылки остаются доступными для записи.

В Redpanda Cloud вы также можете управлять отказоустойчивостью непосредственно со страницы Shadow Link в Cloud Console или через Data Plane API.

Что еще более важно, для Shadow Links можно выполнять отработку отказа (failover) по одному топику за раз. Таким образом, миграция превращается в последовательность небольших, незаметных для конечных пользователей переключений. Выберите приложение с наименьшим риском, переведите его топики, направьте его продюсеры и консьюмеры на Redpanda, понаблюдайте за ним в течение недели и переходите к следующему.

Оффсеты групп потребителей уже реплицированы, поэтому консьюмеры возобновляют работу с того места, где остановились, вместо сброса к началу разделов для полной переигровки. Списки ACL уже настроены, поэтому вам не придется изменять правила авторизации в 2 часа ночи.

Работа с разветвленными многопользовательскими средами Confluent

Демонстрация с одним кластером — это простой случай. Реальные, зрелые развертывания Confluent / Kafka обычно отражают десятилетнюю историю организации: по одному реестру на каждое окружение, бизнес-подразделение, поглощение или ИТ-феодализм, с пересекающимися именами субъектов и политиками совместимости для каждого субъекта, настроиться которые никто уже не помнит. Иногда такие кластеры делят общий реестр. Это означает, что вам понадобятся различные варианты.

Реестр схем Redpanda поддерживает контексты: независимые пространства имен для субъектов в рамках единого реестра, каждое из которых имеет собственный счетчик идентификаторов схем, режим и настройки совместимости. Эта реализация совместима с API контекстов Confluent, поэтому, если ваши инструменты уже используют контексты, они продолжат работать. Контексты включены по умолчанию в версии 26.2, а также на кластерах BYOC и Dedicated в Redpanda Cloud.

Это дает вам реальный контроль над тем, как именно пройдет миграция:

• Реплицируйте подмножество. Параметр source_filter выбирает определенные контексты, определенные субъекты или их объединение, используя квалифицированный синтаксис субъектов (:.staging:orders-value). Вам не обязательно мигрировать все сразу с самого начала.
• Сохраняйте имена контекстов или переназначайте их. Отозначение назначения identity сохраняет имена исходных контекстов — это стандартный выбор для прямой миграции. Точное отображение (exact) позволяет переименовывать контексты на лету, что позволяет объединять несколько исходных реестров в один кластер Redpanda без конфликтов: каждый исходный реестр попадает в собственный целевой контекст.
• Изолируйте команды без изоляции операций. Несколько команд используют единый кластер Redpanda и Реестр схем с идентификаторами и настройками совместимости для каждого контекста, вместо того чтобы заставлять кого-то развертывать отдельный Реестр схем для каждой команды.

Не готовы к миграции? Используйте Redpanda в качестве страховки

У этого же механизма есть и второе применение, с которого обычно начинают склонные к осторожности команды.

Настройте теневой кластер Redpanda (shadow cluster) на свое развертывание Confluent или Kafka и оставьте его в таком состоянии. Топики, смещения, списки управления доступом (ACL) и схемы реплицируются непрерывно. Теперь у вас есть горячий резерв на другой платформе, в другом домене сбоев и с другой поддержкой, как правило, по гораздо более низкой цене, чем второй кластер Confluent. Это создает трамплин для будущей миграции на Redpanda и повышает надежность вашей критически важной инфраструктуры потоковой передачи данных.

Некоторые команды используют эту конфигурацию в течение квартала или дольше, прежде чем переключать что-либо. Это полноценное самостоятельное решение (Redpanda как кластер аварийного восстановления для основного кластера Confluent или Kafka) и наиболее честный способ оценки миграции, поскольку теневой кластер содержит ваши реальные производственные схемы и данные все это время. Во время миграции в Redpanda также можно запускать синтетические рабочие нагрузки, выступающие в роли некоего промежуточного кластера и еще больше повышающие уверенность.

Убедитесь в этом на практике от начала и до конца

Лучше один раз увидеть, поэтому мы создали практическую лабораторию, которая запускает настоящий стек Confluent Platform (Confluent Kafka в режиме KRaft плюс Confluent Schema Registry) в качестве источника миграции и реплицирует все в теневой кластер Redpanda. Все работает в Docker Compose и занимает всего 20 минут.

Лаборатория намеренно не ограничивается самым простым вариантом использования. Она регистрирует два простых субъекта Avro (orders-value, customers-value), устанавливает для одного из них режим совместимости BACKWARD и добавляет вторую, совместимую версию, а затем нагромождает сложности, которые часто ломают написанные вручную миграции:

• Ссылка на схему: shipping-value указывает на address-value, поэтому вы можете наблюдать, как Теневое копирование (Shadowing) импортирует их в порядке зависимостей.
• Субъект JSON Schema и субъект Protobuf наряду с субъектами Avro.
• Режим совместимости FULL_TRANSITIVE для одного из субъектов, чтобы подтвердить, что настройки для каждого субъекта реплицируются корректно, а не возвращаются к глобальному значению по умолчанию.

Затем она генерирует реальные записи в кодировке Avro для кластера Confluent и считывает их обратно дважды: один раз разрешая схемы через реестр Confluent, а второй — через реестр теневого кластера Redpanda (изменение, требующее всего одной правки конфигурации в приложении). Записи расшифровываются одинаково в обоих случаях. Это и есть весь тест, который вы можете легко повторить в своем окружении Confluent со своими приложениями и схемами.

Лаборатория также проверяет, что реестр теневого кластера остается «заблокированным» до отработки отказа, предотвращая повреждение реплики, и развертывает Redpanda Console на теневом кластере, чтобы вы могли просматривать реплицированные схемы и данные или настраивать параметры связей и данные через пользовательский интерфейс.

Если застрявшая миграция Реестра схем — это единственное, что стоит между вами и переключением, эта лаборатория покажет, что это больше не проблема. Ищите ее в Redpanda Labs.

Теневое копирование и репликация схем в режиме API являются функциями уровня Enterprise и требуют либо лицензии Redpanda Enterprise, либо пробной версии Redpanda Cloud/BYOC. Вы можете сгенерировать пробный ключ для локального запуска лаборатории и оценки работы с вашим собственным реестром.

Попробуйте уже сегодня

Многие платформенные команды уже давно хотели модернизировать свою инфраструктуру Kafka и/или вырваться из тисков Confluent, но ждали, когда процесс миграции станет менее болезненным. Именно эту проблему мы решили в версии 26.2. И это уже доступно в Redpanda Self-Managed и Redpanda Cloud (кластеры BYOC и Dedicated).

Redpanda Shadowing теперь позволяет мигрировать с Confluent или Kafka тем же способом, который защищает вас от сбоев: плавно, с помощью живой реплики вашего кластера, сохраняющей смещения. Просто синхронизируйте и проверьте свои данные, схемы, политики безопасности и полноценные приложения, а затем выполните переход за одно согласованное переключение. Никаких MirrorMaker, пользовательских скриптов, множества инструментов или масштабных миграций в выходные дни. Ваши приложения едва ли заметить переезд.

• Запустите лабораторию: labs/docker-compose/confluent-schema-registry-shadowing/
• Прочитайте документацию: Redpanda Self-Managed: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry ContextsRedpanda Cloud: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts‍
• Redpanda Self-Managed: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts
• Redpanda Cloud: Migrate Schemas from Confluent Schema Registry, Shadowing overview, Configure Shadowing, Schema Registry Contexts‍
• ‍Сравните платформы потоковой передачи: Redpanda против Confluent
• Закажите демонстрацию, чтобы узнать больше