Kafka 2.6: rolling upgrade с 2.4 и что incremental cooperative rebalancing меняет на практике

Apache Kafka 2.6.0 вышел на прошлой неделе, и мы с ним не стали тянуть: production-кластер на 2.4 давно ждал обновления, а в 2.6 есть несколько вещей, которые нам интересны прямо сейчас. Главное - incremental cooperative rebalancing вышел из экспериментального статуса, а в TLS-слое закрыли ряд болячек с handshake timeout'ами под нагрузкой.

Rolling upgrade с 2.4 до 2.6 - это два minor-шага по документации Kafka, и мы прошли через 2.5 как промежуточную точку. Кластер из пяти брокеров, темпы около 150 MB/s на запись в пиках, consumer-группы под DWH-задачи.

Почему rebalancing нас вообще беспокоил

В классическом eager rebalancing при любом изменении группы - новый consumer вошёл, старый упал, брокер перезапустился - все участники группы останавливают обработку, сдают разделы, и координатор перераспределяет их заново. Даже если изменение касается одного раздела. Это называется stop-the-world rebalance, и в нашем случае он проявлялся так: при перезапуске брокера в rolling upgrade consumer-группа уходила в rebalance на несколько секунд, lag начинал расти, и если следующий брокер перезапускался до того как группа отошла - lag накапливался.

Не катастрофа, но неприятно: у нас пять брокеров, каждый перезапуск - rebalance, пять rebalance подряд с короткими паузами на восстановление. В 2.3 появился incremental cooperative rebalancing как экспериментальная фича, а в 2.6 он дошёл до production-ready. Суть в том, что при изменении группы consumer отдаёт только те разделы, которые нужно перераспределить, а не все сразу. Остальные продолжают обрабатываться без паузы.

Как мы это тестировали

Перед rolling upgrade на production подняли нагрузочный стенд - три брокера, воспроизвели топологию groupid-ов и topic/partition-схему в уменьшенном масштабе. Producer-нагрузка через kafkacat, consumer-группы с включённым partition.assignment.strategy=CooperativeStickyAssignor.

Наблюдали за consumer lag через Burrow и метрики из JMX в Prometheus. Зафиксировали baseline с eager rebalancing (2.4), потом обновили стенд до 2.6 и включили cooperative.

Разница видна в метрике kafka.consumer.fetch-manager-metrics:records-lag-max в момент перезапуска брокера. При eager - lag уходит в пик, потом ступенька на несколько секунд пока группа перебалансируется, потом consumer догоняет. При cooperative - пика нет, lag практически не реагирует на перезапуск одного брокера. Оставшиеся consumers просто продолжают работать.

Второй эффект - rebalance duration в метриках client-а. Eager rebalance занимал у нас от 3 до 8 секунд (зависит от количества разделов в группе, у нас некоторые топики по 24 раздела). Cooperative с StickyAssignor - доли секунды на второй фазе, которая перераспределяет освободившиеся разделы.

Rolling upgrade на production

Схема стандартная: по одному брокеру, ждём что UnderReplicatedPartitions падает обратно в ноль после каждого шага. Между 2.4 и 2.6 нет прямого пути - через 2.5 обязательно, иначе проблемы с log format version. На каждом брокере server.properties до перезапуска, потом перезапуск, потом проверка реплик.

Общее время на пять брокеров - около 40 минут, из которых половина это ожидание репликации после каждого шага. Даунтайма не было. Consumer-группы с cooperative rebalancing вели себя заметно спокойнее чем мы ожидали - именно по сравнению с предыдущими rolling upgrade на этом кластере.

Пара наблюдений по ходу:

• inter.broker.protocol.version нужно обновлять отдельным шагом после того как все брокеры уже на новой версии. Преждевременное обновление - старый брокер не сможет общаться с кластером. Мы знали, но напомнить стоит.
• TLS-улучшения в 2.6 в нашем случае проявились в одном конкретном месте: раньше при высокой нагрузке иногда видели SSL handshake failed в логах клиентов, которые подключались через SSL listener. После обновления этих ошибок нет. Точнее - были связаны с тем, что 2.4 в определённых условиях тянул handshake дольше чем client-side timeout. В 2.6 это ушло.
• Cooperative rebalancing не включается автоматически. Нужно явно выставить partition.assignment.strategy=CooperativeStickyAssignor на каждом consumer. Старый StickyAssignor - не то же самое: он sticky, но не cooperative. Мы обновили конфиги consumer-приложений параллельно с upgrade брокеров.

Что с lag-ом по итогу

После перевода всех consumer-групп на CooperativeStickyAssignor картина стала значительно предсказуемее. Lag ведёт себя ровно: растёт когда producer гонит быстрее чем consumer успевает, падает когда нагрузка спадает. Rebalance-всплески, которые раньше добавляли шум и периодически вызывали вопросы «а что это было», исчезли.

Это важно для нас именно потому, что по lag'у мы отслеживаем здоровье пайплайна. Когда каждый rolling restart добавлял несколько пиков на графике - нужно было каждый раз объяснять что это не проблема, а плановая операция. Теперь на графике тихо.

Кластер на 2.6.0 работает пятый день, замечаний нет. Следующий шаг - смотреть на KIP-405 (tiered storage), который активно обсуждается в сообществе: offload партиций в object storage архитектурно интересная история, но реализация в активной разработке и в 2.6 не вошла.