Манная Кафка и микросервисы

DevOps Moscow meetup: *aaS (as a service), 27-02-2019
Анатолий Солдатов (Авито)

Я расскажу про то, почему мы в Авито выбрали Kafka в качестве message broker, и сделаю небольшое overview Kafka, как технологии. Также обсудим, для чего мы решили применять подход Kafka as a service и какие плюсы от него можно получить.
- Зачем нужен message broker
- Почему Kafka, а не что-то еще
- Kafka overview
- Kafka as a service

Transcript

1. Манная Кафка и микросервисы Солдатов Анатолий
2. Agenda 1. Message broker 2. Сравнение технологий для шины данных 3. Kafka overview 4. Kafka as a service 2
3. Микросервисы 3
4. Шина данных • Независимость сервисов • Асинхронное взаимодействие • Event driven архитектура • Потоки событий можно собирать в DWH 4
5. Требования к шине (1/3) • At least once delivery • Высокая пропускная способность (throughput) • Низкая задержка (latency) 5
6. Требования к шине (2/3) • Высокая отказоустойчивость • Высокая доступность • Горизонтальное масштабирование 6
7. Требования к шине (3/3) • Возможность хранить полные данные • Возможность проиграть данные на глубину три дня • Подписка на данные 7
8. Основные кандидаты 8
9. Почему Kafka? 9
10. Kafka overview (1/4) 10
11. Kafka overview (2/4) 11
12. Kafka overview (3/4) 12
13. Kafka overview (4/4) 13
14. Kafka мониторинг 14
15. Что если (1/2) • Что если медленная запись/чтение? • Что если упадет сеть? • Что если упадет брокер? • Что если упадет зукипер? 15
16. Что если (2/2) • 1KB сообщения • 3 брокера, 3 zookeeper • 1 ДЦ • 15K SAS диски • ±300 GB Mem • 10GBit Net • acks=all, replication factor=3, MIN ISR=2 16
17. Выводы (1/5) • Запись более 1M events/sec • Чтение более 1M events/sec • Zookeeper’s лучше отдельно • При падении нод важно retries > 0 17
18. Выводы (2/5) • Много памяти - хорошо • CPU - не очень важно • Сеть важна 18
19. Выводы (3/5) • Падать по месту неприятно • Читать с большим лагом неприятно • Нужно много дескрипторов 19
20. Выводы (4/5) • Падение 1 брокера не страшно • Падение 2 брокеров - доступ только на чтение 20
21. Выводы (5/5) • Падение 1 зукипера не страшно • Падение 2 зукиперов (в кластере из 3) - downtime 21
22. Проблемы эксплуатации (1/3) • Некорректный retention топиков (больше, чем место на диске) • Автоматически создавать топики опасно • Создавать топики руками для 300+ сервисов неэффективно • За топиками надо следить 22
23. Проблемы эксплуатации (2/3) • Несовместимые версии producer/consumer и Kafka • Разные библиотеки для producer/consumer с разными багами • Несовместимые форматы сериализации данных • Некорректные настройки producer/consumer • Миграции данных между кластерами 23
24. Проблемы эксплуатации (3/3) • Ввод новых элементов экосистемы (например, как заставить все микросервисы начать использовать schema registry) • Роутинг топиков для разных целей на разные кластеры (тестовый, инфраструктурный, бизнесовый и т.д.) • Как добиться plug&play и не дублировать код 24
25. Kafka как сервис: архитектура (1/2) • Серверная часть живет в Kubernetes • Серверная часть на go (sarama) • Клиентская часть - максимально простые библиотеки 25
26. Kafka как сервис: архитектура (2/2) • Push модель • Коннекты 1 в 1 • Есть ack/nack режим • Есть батчи • Есть масштабирование consumer в группах 26
27. Kafka как сервис (1/4) • Серверная часть на go • Клиентская часть для go/php • Скоро клиентская часть для python • Не ходим в Kafka напрямую, только через API 27
28. Kafka как сервис (2/4) • Масштабирование на сервере (пояснить, про что вообще речь) • Контроль аномалий на сервере • Контроль за ресурсами на сервере 28
29. Kafka как сервис (3/4) • Простая интеграция • Управление consumer/producer на сервере • Контроль за топиками на сервере 29
30. Kafka как сервис (4/4) • Конфигурация consumer/producer заранее задана • Все компоненты совместимы между собой • Единый подход к стримингу из баз данных (свои коннекторы) • “Плохие” consumer/producer тротлятся или мигрируют в отдельный кластер (настройка квот) 30
31. To be continued • Развитие Kafka as a service • Staging Kafka в Kubernetes • Streams & KSQL • Connectors • Automatisation 31
32. Сложный путь • Не все понимают, что мы не гарантируем порядок (и что за порядок такой вообще); • Битва при registry – успели огрести на невалидных данных из-за отсутствия валидации схем; 32
33. Сложный путь • А не теряет ли шина данные; А как нам интегрировать ее с экосистемой Kafka; • Kafka из будущего или проблемы с failover; • В Kafka мире это уже сделано! А когда появится у нас в шине? 33
34. Спасибо! 34
35. Вопросы 35 aksoldatov@avito.ru @MrAnatoly