Вчера мы писали о недавно вышедшем свежем релизе Apache Kafka 3.1.0, который вышел в январе 2022 года. Сегодня рассмотрим, как безболезненно перейти на эту версию и избежать возможных побочных эффектов, связанных с некоторыми архитектурными изменениями платформы.
Побочные эффекты и подводные камни обновления
Напомним, в Apache Kafka 3.1.0 добавлена новая фича с расширением SASL/OAUTHBEARER с поддержкой OAuth/OIDC, что позволяет использовать для аутентификации и авторизации сервисы сторонних провайдеров. Также свежий релиз поддерживает Java 17 и содержит множество улучшений и исправлений, важных для администратора кластера и разработчика распределенных приложений Kafka Streams, о чем мы подробно рассказывали здесь. Однако, из-за эволюционного развития архитектурных идей в разных версиях Apache Kafka обновление становится достаточно сложной задачей.
Например, побочным эффектом обновления может стать падение производительности из-за увеличения загрузки ЦП вследствие разных версий на брокерах и клиентах. В частности, формат сообщения в версии 0.10.0 включает новое поле метки времени и использует относительные смещения для сжатых сообщений. Формат сообщения на диске можно настроить с помощью log.message.format.version в файле server.properties. По умолчанию он имеет версию 0.10.0. Если клиент-потребитель использует версию до 0.10.0.0, брокер может преобразовывать сообщения в более ранний формат перед отправкой ответа. Но в этом случае брокер не может использовать передачу с нулевым копированием. Тестирование, проведенное сообществом Kafka, показало рост загрузки ЦП с 20% до 100% после обновления, что потребовало немедленного обновления всех клиентов, чтобы вернуть производительность в норму. Чтобы избежать такого преобразования сообщений до того, как потребители будут обновлены до версии 0.10.0.0, можно установить для параметра конфигурации log.message.format.version значение 0.8.2 или 0.9.0 при обновлении брокера до версии 0.10.0.0. Таким образом, брокер по-прежнему может использовать передачу с нулевым копированием для отправки данных старым потребителям, после обновления которых можно изменить формат сообщения на брокере и пользоваться новым форматом сообщения, который включает новую отметку времени и улучшенное сжатие. Преобразование поддерживается для обеспечения совместимости и может быть полезно для поддержки нескольких приложений, которые еще не обновлены до более новых клиентов. Поэтому очень важно максимально избегать преобразования сообщений, когда брокеры были обновлены, а большинство клиентов — нет.
Также стоит помнить, что в релизе 3.1.0 вместо метрик измерения задержек на клиенте в мили- и нано-секундах bufferpool-wait-time-total, io-waittime-total и iotime-total в новом релизе используются bufferpool-wait-time-ns-total, io-wait-time-ns-total и io-time-ns-total соответственно.
Кроме того, из-за объявления устаревшим протокола быстрой перебалансировки EAGER, по умолчанию используемого с Kafka 2.4, пользователям рекомендуется подготовиться к завершению обновления своих приложений до кооперативного протокола в версии 3.1. Это касается только пользователей, которые все еще используют версию старше 2.4, и пользователей, которые уже обновились, но еще не удалили конфигурацию upgrade.from, установленную с при обновлении с версии ниже 2.4. Первой категории пользователей нужно сперва обновиться до версии между 2.4 и 3.1, настроить конфигурацию upgrade.from, затем удалить ее и обновиться до окончательной версии 3.1+. Во втором случае достаточно просто отключить конфигурацию upgrade.from при обновлении выше 3.1.
При обновлении с версии 0.11.0.x до 2.1.x, нужно помнить об изменении схемы, используемой для хранения смещений потребителей. После изменения версии inter.broker.protocol.version на последнюю, перейти на более раннюю будет невозможно. Все эти и другие нюансы относительно совместимости схем данных, архитектурных особенностей и конфигурационных параметров следует помнить, принимая решение о миграции на новую версию. Тем не менее, поскольку в свежих релизах появляются новые полезные фичи и исправляются обнаруженные ошибки, вопрос о переходе чаще всего является только вопросом времени. Поэтому далее мы рассмотрим, как перейти на Apache Kafka 3.1.0 с версии 0.8.x до 3.0.x.
Пошаговый план перехода на Apache Kafka 3.1.0 для администратора кластера
Для непрерывного обновления платформы потоковой передачи событий с версии 0.8.x до 3.0.x. на релиз с 3.1.0, необходимо выполнить следующие действия:
- Обновить properties для всех брокеров и добавить свойства inter.broker.protocol.version и log.message.format.version, привязав их к версиям Kafka. В частности, свойство CURRENT_KAFKA_VERSION относится к исходной (предыдущей) версии, от которой идет обновление. Также нужно добавить свойство CURRENT_MESSAGE_FORMAT_VERSION, что относится к используемой в настоящее время версии формата сообщения. Если версия формата сообщения была ранее переопределена, следует сохранить ее текущее значение. При обновлении с версии до 0.11.0.x свойство CURRENT_MESSAGE_FORMAT_VERSION должно быть установлено в соответствии с CURRENT_KAFKA_VERSION. Таким образом, следует установить параметры
- broker.protocol.version=CURRENT_KAFKA_VERSION, например, 3.0, 2.8 и пр.
- message.format.version=CURRENT_MESSAGE_FORMAT_VERSION, например, 0.10 и пр.
При обновлении с версии 0.11.0.x или выше, когда формат сообщения не был переопределен, нужно переопределить только версию межброкерского протокола: inter.broker.protocol.version=CURRENT_KAFKA_VERSION, например, 3.0, 2.8 и пр.
- Обновлять брокеры следует по одному, сперва выключив каждый, обновив код и перезапустив, чтобы убедиться, что поведение и производительность кластера соответствуют ожиданиям. На этом этапе все еще можно откатиться назад, если есть какие-либо проблемы.
- После проверки поведения и производительности кластера надо увеличить версию межброкерского протокола, отредактировав broker.protocol.version и установив для нее значение 3.1.
- Перезапускать брокеры тоже следует по одному, чтобы новая версия протокола вступила в силу. Как только брокеры начнут использовать последнюю версию протокола, понизить кластер до более старой версии станет невозможно.
- После переопределения версии формата сообщения, необходимо выполнить еще один последовательный перезапуск, чтобы обновить его до последней версии. Когда все или большинство потребителей обновлены до версии 0.11.0 или более поздней, нужно изменить значение параметра message.format.version на 3.1 на каждом брокере и перезапустить их один за другим. Важно, что старые клиенты Scala, которые больше не поддерживаются, не поддерживают формат сообщений, представленный в версии 0.11, поэтому, чтобы избежать затрат на преобразование форматов или использовать преимущества семантики строго однократной доставки сообщений (exactly once), следует переходить на более новые клиенты Java.
Все подробности по администрированию и использованию Apache Kafka для потоковой аналитики больших данных вы узнаете на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков больших данных в Москве:
Источники
