Запускал ли Kafka в production-среде?

«Запускал ли Kafka в production-среде?» — вопрос из категории Брокеры сообщений, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Да, разворачивал и поддерживал кластеры Apache Kafka в production. Основные задачи и практики:

1. Развертывание и конфигурация:

  • Использовал Helm-чарт bitnami/kafka для Kubernetes или Ansible для развертывания на виртуальных машинах.
  • Ключевые настройки для production:
    • Репликация топиков (replication.factor=3): для отказоустойчивости.
    • Минимальное число in-sync реплик (min.insync.replicas=2): гарантия сохранности данных при потере брокера.
    • Настройка retention политик (log.retention.hours, log.retention.bytes): в зависимости от объема данных и требований.
    • Separate Zookeeper ensemble: выделенный, отказоустойчивый кластер Zookeeper.

2. Мониторинг и эксплуатация:

  • Настраивал экспортер kafka-exporter для сбора метрик в Prometheus (lag потребителей, активные брокеры, размер топиков).
  • В Grafana создавал дашборды для отслеживания здоровья кластера и лагов потребителей (consumer lag).
  • Использовал Cruise Control от LinkedIn для автоматической балансировки партиций и выявления "тропических" брокеров.

3. Интеграция и безопасность:

  • Настраивал аутентификацию с помощью SASL/SCRAM и шифрование трафика SSL/TLS.
  • Интегрировал Kafka как шину событий для микросервисов, стриминговой обработки (Kafka Streams, Flink) и передачи логов.

Пример команды для создания топика с production-настройками:

kafka-topics.sh --create 
  --bootstrap-server kafka-broker:9092 
  --replication-factor 3 
  --partitions 6 
  --topic orders 
  --config min.insync.replicas=2 
  --config retention.ms=604800000

4. Disaster Recovery:

  • Проектировал стратегии бэкапа (с помощью MirrorMaker 2 или Uber uReplicator) и отработки отказа между кластерами в разных AZ/регионах.