10. Эксплуатация и best practices

Эксплуатация Kafka — это не “запустить и забыть”, а регулярно управлять:

соглашениями об именах (чтобы система была понятной),
стратегией партиций (чтобы масштабирование не ломалось),
жизненным циклом данных (retention/compaction/архив),
обновлениями и rebalancing после изменений инфраструктуры,
удалением устаревших потоков данных (с безопасным планом).

Термины и сущности

Термин	Определение
Partition strategy	Как вы выбираете число партиций и ключи, чтобы параллелизм и throughput были управляемыми.
Data lifecycle	Политики хранения: retention, compaction, архивирование и удаление.
Rolling update	Поочерёдное обновление узлов кластера с минимизацией простоя и сохранением устойчивости.
Rebalancing	Перераспределение партиций/лидеров на узлах для выравнивания нагрузки и устойчивости.
Cleanup	Безопасное “устаревание”: перевод в архив/снижение retention/удаление после проверки.

Конвенции именования разделов

Цель — чтобы имя:

объясняло назначение,
было предсказуемым для фильтрации и ownership’а,
поддерживало версионирование.

Рекомендуемый шаблон (пример):

<domain>.<env>.<event>.<schema_version>

Примеры:

orders.prod.created.v1
orders.prod.updated.v1
payments.stage.completed.v2

Production best practices:

версии схем/семантики добавляйте в конец имени (чтобы миграции были управляемыми),
избегайте “общих” имен без домена (обычно они приводят к хаосу в ownership’е),
заранее договоритесь, какие части имени обязательны и как обозначаются breaking changes.

Стратегия partition’ов

Партиции — это единица параллелизма и распределения нагрузки.

Практические правила

1) Partition count выбирайте под ожидаемый throughput и целевую параллельность consumer’ов. 2) Для сохранения порядка используйте ключ (ключ влияет на распределение по партициям). 3) Старайтесь не менять число партиций “в лоб”: это операция, которая требует продуманного rebalancing и ожиданий по лагу.

Производственная модель принятия решений (простая)

если throughput растёт линейно и consumer’ы масштабируются — увеличивайте партиции заранее (в пределах бюджета).
если throughput ограничен downstream (БД/HTTP) — сначала увеличивайте параллелизм обработки и тюните consumer’ов, а не партиции.

Data lifecycle: retention, compaction и архивирование

В production “жизненный цикл” обычно состоит из трёх этапов:

1) Hot: данные нужны для обработки (короткий retention). 2) Warm: данные могут понадобиться для backfill/аналитики (длиннее retention). 3) Cold/Archive: данные либо в архиве, либо в режиме “минимальной стоимости” хранения.

Полезные параметры:

time-based retention: retention.ms
size-based retention: retention.bytes
compaction: cleanup.policy=compact (обычно для “последнего состояния по ключу”)

Best practices:

retention выбирайте по SLO аналитики/повторной обработки (backfill) и по стоимости хранения,
compaction включайте только когда ключ действительно отражает бизнес-сущность (иначе выигрыш минимален),
планируйте изменение retention как контролируемый rollout (особенно если включаете/выключаете compaction).

Rolling updates: как обновлять кластер без сюрпризов

Цель rolling update — не только “обновиться”, но и гарантировать, что:

записи продолжают проходить,
leader’ы и ISR стабилизируются,
consumer’ы переживают rebalances без потери SLO.

Production-порядок (шаблон)

1) Проверьте baseline health: нет under-replicated и критической деградации. 2) Выберите один broker/узел для рестарта (очередь). 3) Перезапустите контролируемо (drain/cordon/очередь pod’ов — в зависимости от вашей платформы). 4) После рестарта дождитесь стабильного leader/ISR состояния. 5) Повторите для следующего узла.

Мини-команды для Kubernetes-подхода (идея):

# Посмотреть health/признаки деградации через ваши метрики/команды
kubectl -n kafka get pods -o wide

# Принудительно перезапустить один pod (для практики)
kubectl -n kafka delete pod <broker-pod-name>

# Проверить, что consumer’ы продолжают двигаться
kafka-consumer-groups.sh --bootstrap-server kafka-0.kafka:9092 --describe --group orders-worker

Комментарий:

“правильный” rolling update зависит от того, что вы используете для эксплуатации (оператор/кластер менеджер/ручная стратегия).

Rebalancing после изменений инфраструктуры

Когда вы:

добавляете брокеры,
меняете количество партиций,
меняете capacity,

может потребоваться перераспределение партиций по узлам.

Вариант: kafka-reassign-partitions.sh (CLI)

Обычно workflow такой:

1) сгенерировать план перераспределения в JSON, 2) выполнить reassign, 3) мониторить ход операции.

Пример (шаблон):

bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-0.kafka:9092 \
  --generate \
  # ВАЖНО: замените опции под вашу версию Kafka
  # и под вашу топологию (список broker’ов, план перераспределения).
  # Файл плана (в JSON) создаётся на предыдущем шаге.
  --plan-json plan.json \
  --throttle 200000

bin/kafka-reassign-partitions.sh \
  --bootstrap-server kafka-0.kafka:9092 \
  --execute \
  --reassignment-json-file reassignment.json

Комментарий:

plan.json и reassignment.json готовятся под вашу топологию и политический контракт нагрузки,
throttle помогает избежать ухудшения latency на production.

Cleanup старых потоков данных (безопасный подход)

Технически удаление данных — последняя операция. В production обычно делают безопасный pipeline:

1) Identify: найти устаревшие потоки (нет consumer’ов или lag стабильно 0). 2) Validate: подтвердить с ownership’ом, что данные не нужны для backfill. 3) Degrade: либо снизить retention/стоимость, либо перевести в архивное хранилище. 4) Delete: выполнить удаление только после согласования и window’а.

Проверка прогресса consumer’ов (идея):

kafka-consumer-groups.sh \
  --bootstrap-server kafka-0.kafka:9092 \
  --describe \
  --group <group-name>

Best practices:

делайте delete batch’ами с контролем ошибок,
обязательно логируйте решения и причины удаления (audit),
после удаления проверяйте, что upstream/downstream не завели новые зависимости на старые данные.

Production checklist (коротко)

Практика	Зачем
Единый формат имен разделов и версионирование	меньше хаоса и ошибок интеграции
Partition count и ключи выбраны под параллельность consumer’ов	устойчивый throughput
Retention/compaction имеет lifecycle-план	контролируемые стоимость и поведение
Rolling updates по одному узлу + проверки ISR/прогресса	меньше инцидентов
Rebalancing выполняется как planned операция (с планом/лимитами)	предсказуемая деградация
Cleanup делается через identify/validate/degrade/delete	безопасное удаление