Модуль 9.7: Конвеєри стрімінгових даних (MSK / Confluent / Dataflow)
Складність: [COMPLEX] | Час на виконання: 3 год | Передумови: Модуль 9.2 (Брокери повідомлень), Модуль 9.6 (Пошук та аналітика), основи розподілених систем
Чому цей модуль важливий
Розділ «Чому цей модуль важливий»У лютому 2024 року великий онлайн-маркетплейс обробляв 850 000 замовлень на день. Їхній конвеєр подій — створення замовлення, підтвердження оплати, оновлення складу, створення доставки — працював через власний кластер Kafka у Kubernetes. Команда платформи витрачала 15 годин на тиждень на обслуговування: перезапуск брокерів, перерозподіл даних між дисками, моніторинг ZooKeeper та оновлення версій.
Одного вівторка один із брокерів втратив свій диск через збій у хмарного провайдера. Кластер увійшов у нестабільний стан, частина подій перестала підтверджуватися. Команда витратила 6 годин на ручне відновлення даних. У цей час 12% замовлень “зависли” із затримкою до 4 годин.
Вони перейшли на керований сервіс Amazon MSK. Тепер той самий кластер коштує на 20% дешевше (бо AWS бере на себе керуючий рівень), а команда витрачає на Kafka 2 години на тиждень замість 15. Всі оновлення та заміни серверів відбуваються автоматично.
Цей модуль навчить вас будувати промислові системи стрімінгу даних. Ви дізнаєтеся, коли варто запускати Kafka самому, а коли — платити за керований сервіс, як працює шардинг через партиції, як моніторити затримку споживачів (lag) та як гарантувати, що дані не загубляться при передачі.
Managed Kafka vs Власний кластер (Strimzi)
Розділ «Managed Kafka vs Власний кластер (Strimzi)»| Фактор | Керований (MSK/Confluent) | Власний (Strimzi у K8s) |
|---|---|---|
| Операційна робота | Провайдер патчить сервери та диски | Ви робите все самі |
| Затримка (Latency) | 1-5 мс (через VPC) | < 1 мс (всередині кластера) |
| Контроль | Обмежений налаштуваннями провайдера | Повний контроль над кожним байтом |
| ZooKeeper | Прихований або відсутній (KRaft) | Ви керуєте самі |
Порада: Якщо у вас немає окремого фахівця з Kafka, завжди обирайте керований сервіс. Kafka — це одна з найскладніших систем у світі для самостійної експлуатації.
Партиції: Основа масштабування
Розділ «Партиції: Основа масштабування»Топік у Kafka ділиться на партиції (partitions). Це одиниця паралелізму.
- Якщо у вас 6 партицій, ви можете запустити максимум 6 подів-воркерів, які будуть читати дані одночасно.
- Якщо ви запустите 7-й под — він просто буде стояти пустим.
Ключ партиціонування (Partition Key)
Розділ «Ключ партиціонування (Partition Key)»За допомогою ключа ви кажете Kafka, куди покласти повідомлення.
- Порожній ключ: Дані розкидаються випадково. Максимальна швидкість, але немає черговості.
- Ключ =
order_id: Всі події по одному замовленню потраплять в ОДНУ партицію. Це гарантує, що вони будуть оброблені суворо по черзі (спочатку “Створено”, потім “Оплачено”).
Моніторинг затримки (Consumer Lag)
Розділ «Моніторинг затримки (Consumer Lag)»Lag — це найважливіша метрика в стрімінгу. Це різниця між тим, скільки повідомлень уже прийшло в Kafka, і скільки ваш под встиг обробити.
- Lag = 0: Все ідеально, ви встигаєте за трафіком.
- Lag росте: Ваші поди працюють занадто повільно або трафіку стало забагато. Потрібно додавати воркерів.
Schema Registry: Контракти даних
Розділ «Schema Registry: Контракти даних»Коли один відділ компанії пише дані в Kafka, а інший — читає, вони мають домовитися про формат. Schema Registry — це сервіс, який перевіряє, чи не зламав відправник структуру даних (напр. видалив важливе поле). Якщо формат не співпадає — Kafka просто не прийме повідомлення. Це рятує від “зіпсованих” даних у продакшні.
Типові помилки
Розділ «Типові помилки»| Помилка | Чому це стається | Як виправити |
|---|---|---|
| Мало партицій | Створили “по дефолту” | Створюйте топіки з запасом партицій (напр. 12-24), бо їх кількість важко збільшувати потім |
acks=1 для важливих даних | Думка, що це швидше | Це небезпечно. Використовуйте acks=all, щоб бути впевненим, що дані записані на всі сервери |
| Немає моніторингу Lag | Думають, що CPU достатньо | Слідкуйте саме за Lag. Под може мати 10% CPU, але “відставати” від реальності на годину |
| Використання Kafka як БД | Здається, що там можна зберігати все вічно | Kafka — це тимчасова черга. Зберігайте там дані від 1 до 7 днів |
Тест
Розділ «Тест»1. Що станеться, якщо кількість подів-споживачів перевищить кількість партицій у топіку?
Зайві поди будуть знаходитися в стані очікування (idle). Вони не отримають жодного повідомлення, поки один із активних подів не вимкнеться. Kafka не вміє ділити одну партицію між двома споживачами одночасно.
2. Навіщо потрібен 'Replication Factor' і яке значення є стандартом?
Він визначає, на скількох фізичних серверах копіюються ваші дані. Стандарт для продакшну — 3. Це дозволяє системі вижити, навіть якщо один сервер повністю згорить, а інший буде на обслуговуванні.
Практична вправа: Стрімінг подій
Розділ «Практична вправа: Стрімінг подій»- Створіть топік
prod-eventsіз 6 партиціями та реплікацією 3. - Запустіть воркер (Deployment) із 3 репліками. Перевірте в консолі, як партиції розділилися між ними (по 2 на кожного).
- Збільште кількість реплік воркера до 6. Перевірте, чи кожен под тепер читає свою партицію.
- Надішліть повідомлення з ключем і переконайтеся, що воно потрапило в ту саму партицію, що і попереднє з цим же ключем.
Наступний модуль
Розділ «Наступний модуль»Переходьте до Модуля 9.8: Глибоке занурення в управління секретами — ви навчитеся використовувати HashiCorp Vault та Secrets Store CSI для динамічної ротації паролів та автоматичного надання прав доступу вашим подам.