Виктор Корейша — Cамые распространенные ошибки при работе с Apache Kafka

Transcript

1. Ozon Tech 2022 Cамые распространенные ошибки при работе с Apache Kafka Виктор Корейша, руководитель отдела Message Bus
2. 2 • Руковожу отделом Message Bus в Ozon Tech • Член программного коммитета конференции Ural Digital Weekend • Веду подкаст «Кода кода» 
 https:/ /podcast.ru/1551786898 Пара слов обо мне Виктор Корейша
3. Сегодня мы поговорим о…. Как работает Apache Kafka: базовое устройство, термины Распространенные ошибки в параметрах и настройке Распространенные ошибки в архитектуре и использовании 3
4. Вспомним что такое Apache Kafka 4 Спойлер: это менеджер очередей
5. Будет полезно Тем, кто только начинает работать с Kafka Тем, кто уже работает, но не погружался в детали Тем, кто согласился, что Kafka — это менеджер очередей 5 ?
6. Вспомним что такое Apache Kafka 6 Распределённый брокер сообщений
7. События на складе Пример использования 7
8. События 8 2. Заказ №1 Собран item №1 3. Заказ №1 Собран item №2 4. Заказ №1 Доставлен 5. Заказ №1 Отгружен 1. Заказ №1 Поступил в работу
9. Использование событий 1. Складской учет 
 2. Бухгалтерские системы 
 3. Системы учета рабочего времени 
 4. Системы трекинга 
 5. … 2. Заказ №1 Собран item №1 3. Заказ №1 Собран item №2 4. Заказ №1 Доставлен 5. Заказ №1 Отгружен 1. Заказ №1 Поступил в работу
10. Положим события на «конвейерную ленту» 10
11. Партиция 2. Заказ №1 Собран item №1 3. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу Продюсер Консьюмер 
 Бухгалтерия Консьюмер 
 Складской учет
12. Для ускорения работы запустим несколько «лент» 12
13. Топик 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер
14. Топик 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер
15. Топик 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер
16. 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер Консьюмер-группа Складской учет Консьюмер #1 Консьюмер #2 Консьюмер-группа Бухгалтерия Консьюмер #1
17. 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер Консьюмер-группа Складской учет Консьюмер #1 Консьюмер #2 Консьюмер-группа Бухгалтерия Консьюмер #1
18. В одной консьюмер-группе Количество партиций 18 Количество консьюмеров ≥
19. 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер 0 1 2 Офсет 0 1 2 Партиция Консьюмер- группа Бухгалтерия Консьюмер- группа Склад
20. Партиция 0 1 2 Продюсер 2 1 2 Консьюмер-группа склад 2 1 0 Консьюмер-группа бухгалтерия 2 1 0 Офсеты 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер 0 1 2 Офсет 0 1 2 Партиция
21. 1. Producer — источник появления данных 2. Consumer — потребитель данных 3. Topic — Наименование потока данных, в котором кафка хранит сообщения на определенную тему 4. Partition — Дополнительный логический блок используемый для параллельной вычитки сообщений 5. O ff set — Cообщение записанное в партицию Термины 21
22. Внутреннее устройство 22 Брокер 1 Партиция 0 Брокер 2 Партиция 1 Брокер 3 Партиция 2 Партиция 3
23. Внутреннее устройство 23 Брокер 1 Партиция 0 Брокер 2 Партиция 1 Брокер 3 Партиция 2 Партиция 3 Партиция 0 Партиция 0 Партиция 1 Партиция 1 Партиция 2 Партиция 2 Партиция 3 Партиция 3
24. Внутреннее устройство 24 Брокер 1 Партиция 0 Брокер 2 Партиция 1 Брокер 3 Партиция 2 Партиция 3 Партиция 0 Партиция 0 Партиция 1 Партиция 1 Партиция 2 Партиция 2 Партиция 3 Партиция 3
25. 1. Kafka Broker — приложение написанное на языке java 2. Kafka Cluster — логическое объединение kafka брокеров 3. Leader — Партиция из которой осуществляется вычитка и запись 4. Replica — Копия лидер партиции, используется для обеспечения резервирования Термины 25
26. Распространенные ошибки в параметрах и настройке 26
27. как работают retention.bytes/retention.ms Сообщения пропадают из топика 27
28. Сообщения в Kafka не удаляются брокерами по мере их обработки консьюмерами — данные в Kafka могут храниться днями, неделями, годами. Благодаря этому одно и то же сообщение может быть обработано сколько угодно раз разными консьюмерами и в разных контекстах. 28
29. 29 Retention Policy 1. Ограничиваем по размеру • retention.bytes • Type: long • Default: -1 (без ограничений) • Max: 9223372036854775807
30. 30 Retention Policy 1. Ограничиваем по размеру • retention.bytes • Type: long • Default: -1 (без ограничений) • Max: 9223372036854775807 2. Ограничиваем по времени • retention.ms • Type: long • Default: 604800000 (7 дней) • Min: -1 • Max: 9223372036854775807
31. 31 Retention Policy 1. Ограничиваем по размеру • retention.bytes • Type: long • Default: -1 (без ограничений) • Max: 9223372036854775807 2. Ограничиваем по времени • retention.ms • Type: long • Default: 604800000 (7 дней) • Min: -1 • Max: 9223372036854775807 Cleanup Policy 1. Delete • Удалять сегменты либо при истечении срока их хранения, либо при достижении предельного размера 2. Compact • Включает log compaction, который сохраняет последнее значение для каждого ключа
32. 32 Ошибка: Не устанавливать retention.bytes или retention.ms
33. Как правильно коммитить офсет и почему? Почему чтение дольше записи? 33
34. Продюсер обеспечивает надежность данных с помощью параметра конфигурации acks: • none • one • all Запись 34 Продюсер Подтверждение Сообщение Лидер Реплика Реплика
35. Конфигурация min.insync.replicas задает число реплик, которые должны быть синхронизированы, чтобы можно было продолжить запись Запись 35 Продюсер Подтверждение Сообщение Лидер Реплика Реплика
36. Чтение 36 Консьюмер Сообщение Запрос Лидер
37. 37 Каким образом мы можем обозначить сообщения в партиции, как обработанные?
38. 38 Каким образом мы можем обозначить сообщения в партиции, как обработанные? 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер
39. 39 Каким образом мы можем обозначить сообщения в партиции, как обработанные? Кафка сохраняет офсеты в отдельном топике 2. Заказ №1 Собран item №1 4. Заказ №1 Собран item №2 1. Заказ №1 Поступил в работу 5. Заказ №3 Поступил в работу 7. Заказ №3 Собран item №4 3. Заказ №2 Поступил в работу 6. Заказ №2 Собран item №3 8. Заказ №2 Собран item №3 Продюсер
40. Чтение 40 Консьюмер Сообщение Запрос Лидер Подтвержде ние o ff set-commit Лидер Реплика Реплика
41. 41 Ошибка: Коммитить офсеты после каждой вычитки
42. Почему сжатие работает лучше, если писать бачами Как писать больше и быстрее? 42
43. Накладные расходы на пакетную запись постоянны и не поддаются уменьшению (record batch overhead) Батчинг 43 Продюсер Сообщение (50 байт) Брокер Bach Overhead (61 байт) Сообщение (50 байт) Bach Overhead (61 байт) Сообщение (50 байт) Bach Overhead (61 байт)
44. linger.ms — задает верхнюю границу задержки batch.size — размер пакета, который будет отправлен сразу Бачинг 44 Продюсер Сообщение (50 байт) Сообщение (50 байт) Сообщение (50 байт) Брокер Bach Overhead (61 байт)
45. Apache Kafka поддерживает различные алгоритмы сжатия Сжатие 45 Сжатие на продюсере Сжатие на брокере compression.type gzip, snappy, lz4 и zstd gzip, snappy, lz4 и zstd Сеть Нагрузка снижается Не меняется Место на диске Меньше места на диске Меньше места на диске Ресурсы Процессор продюсера (скейлится) Процессор брокера (ограничен в скейлинге)
46. Батчинг + сжатие 46 Продюсер Сообщение (50 байт) Брокер Bach Overhead (61 байт) Продюсер Сжатые данные (30 байт) Брокер Bach Overhead (61 байт) Сообщение (50 байт) Bach Overhead (61 байт) Сжатые данные (30 байт) Bach Overhead (61 байт)
47. Батчинг + сжатие 47 Продюсер Сообщение (50 байт) Сообщение (50 байт) Сообщение (50 байт) Брокер Bach Overhead (61 байт) Продюсер Сжатые данные (70 байт) Брокер Bach Overhead (61 байт)
48. Чем больше батч, тем эффективнее сжатие 48 Сжатие одного сообщения Сжатие бача Размер сообщения 90-220 байт - Суммарный размер 50МБ 50МБ Размер после сжатия (gzip) 41МБ 11МБ Эффективность сжатия 21 % 354 %
49. 49 Ошибка: Сжимать сообщения по одному
50. Распространенные ошибки в архитектуре и использовании 50
51. Группа постоянно падает в ребаланс А чего она не читает то? 51
52. Каждый консюмер в группе принимает сообщения от одной или нескольких партиций в топике. Консьюмеры 52 Партиция 1 Топик Партиция 2 Партиция 3 Партиция 4 Партиция 5 Партиция 6 Консьюмер №1 Консьюмер №2 Консьюмер №3
53. Если консьюмер выбывает, происходит ребалансировка Консьюмеры 53 Партиция 1 Топик Партиция 2 Партиция 3 Партиция 4 Партиция 5 Партиция 6 Консьюмер №1 Консьюмер №2 Консьюмер №3
54. Ребалансировка Каждый консюмер лишается назначенных партиций и ничего не обрабатывает, пока их не назначат обратно Поэтому иногда такую ребалансировку называют stop-the-world 54
55. Каждый консьюмер использует два потока: поток пользователя и «нить серцебиения» • Если не удается получить контрольный сигнал от консьюмера до истечения session.timeout.ms, запускается раунд ребалансировки 
 • Частота с которой консьюмеры сообщают о работоспособности задается в heartbeat.interval.ms 
 • max.poll.interval.ms — время, в течение которого 
 консьюмер может бездействовать, прежде чем получить дополнительные записи. Как брокер понимает, что консьюмер выбыл? 55
56. 56 Ошибки: • Занижать эти интервалы. • Блокировать «серцебиение» со стороны консьюмера. • Слишком тяжеловесные консьюмеры
57. 57 С Kafka 2.4 появилась пошаговая кооперативная ребалансировка (через CooperativeStickyAssignor)
58. Почему лучше делать по одной группе на каждый топик? Одна консьюмер-группа, чтоб править всеми 58
59. Каждый консюмер в группе принимает сообщения от одной или нескольких партиций в топике. Консьюмеры 59 Топик Топик Топик Консьюмер-группа
60. Каждый консюмер в группе принимает сообщения от одной или нескольких партиций в топике. Консьюмеры 60 Топик Топик Топик Консьюмер-группа
61. 61 Ошибка: Слишком большая консьюмер-группа
62. Почему это далеко не всегда хороший план Retry topic 62
63. Консюмер не может обработать потребленное сообщение Проблема 63 Продюсер Консьюмер
64. 64 Ошибка №1: Вообще не продумать такой вариант
65. Можем повторять или пропустить Проблема 65 1002 Продюсер Консьюмер
66. Закомитим новый офсет или оставим старый? Проблема 66 1000 1001 1002 1003 1004 Продюсер Консьюмер
67. 67 Продюсер Консьюмер Основной топик Retry топик Retry Консьюмер Retry топик 2 Retry Консьюмер 2 DLQ
68. 68 Ошибка №2: Сначала закоммитить офсет, а потом пытаться положить в Retry topic
69. Категории ошибок Исправимые ошибки Корневая причина — внешняя по отношению к сообщению и консюмеру 69 Неисправимые ошибки Все равно будут случаться, независимо от того, сколько раз мы попробуем повторно выполнить операцию Консьюмер Консьюмер Другие Так нейросеть изобразила прочие ошибки в очереди сообщений в стиле супрематизм
70. 70 Ошибка №3 Использовать Retry topic по умолчанию
71. Другие сложности 71 Продюсер Консьюмер Retry Консьюмер
72. 72 Ошибка №4: Забыть 
 о последовательности событий
73. Telegram: @koreysha Подкаст «Кода кода» https:/ /podcast.ru/1551786898 Спасибо за внимание Виктор Корейша, руководитель отдела Message Bus, Ozon Tech