Налаштування Apache Kafka: де кластер втрачає дані
Втрата повідомлень у кластері рідко пов'язана із самою платформою: потік рветься на стиках конфігурації, а помічають це вже за звірками та звітами.
Найчастіша причина — розбалансування партицій: ключ партиціювання підібрано так, що одна-дві партиції забирають майже весь потік, їхні брокери впираються в диск, інші простоюють, і лаг споживача зростає без жодної аварії.
Далі — реплікація без втрат лише на словах. Фактор копій вище одиниці сам по собі нічого не гарантує, якщо підтвердження запису налаштовано від лідера і не чекає синхронних копій.
Під час падіння вузла останні записи зникають, а зміщення у споживачів уже зсунуті — відновлювати нічим, бо в копіях цих повідомлень їх не було.
Окремий клас — ємність. Пам'ять під кеш сторінок, розмір сегмента, термін і обсяг зберігання пов'язані між собою: за неправильних лімітів вузол переходить у режим лише для читання або видаляє сегменти раніше, ніж їх прочитали відстаючі групи. Застосунок при цьому помилки не отримує — він просто недолічує події через добу.
Нарешті, спостереження. Без метрик відставання для кожної групи споживачів, стану копій і алертів на стале зростання лагу інцидент знаходять за скаргами користувачів.
Налаштування Apache Kafka у нас починається з аудиту схеми партицій, параметрів підтвердження запису та політик зберігання, а закінчується тим, що розширення кластера й відмова вузла проходять без ручного перерозподілу та без втрати подій.
Продуктивність і відмовостійкість за пікових навантажень
Пікове навантаження перевіряє не середню пропускну здатність, а хвіст: за кратного зростання потоку подій вузьке місце зміщується на реплікацію, перерозподіл партицій і вибори лідера.
Вивірена конфігурація Apache Kafka переводить це у штатний режим — кластер тримає зростання в рази, а затримка публікації зростає лінійно, а не сходинками.
Режим KRaft із кворумом контролерів прибирає зовнішню координацію: метадані живуть усередині кластера, а вибір нового лідера партиції займає секунди замість хвилин.
Тривалість відновлення після відмови вузла стає передбачуваною — за фактора реплікації 3 і рознесення брокерів за зонами доступності кластер приймає записи, поки більшість реплік на зв'язку.
Для критичних топіків acks=all і min.insync.replicas не дають підтвердити запис раніше, ніж її приймуть кілька реплік, — частка втрачених повідомлень зводиться до нуля навіть за відмови брокера в момент запису.
Ідемпотентний продюсер і транзакційні записи знімають дублі, що виникають під час повторного надсилання після мережевого збою: залишаються одиниці повторів на мільйони подій замість відсотків.
Запас за навантаженням видно за трьома метриками: лаг споживачів, кількість партицій поза синхронним набором реплік і тривалість перебалансування групи.
Пороги на них виставляються заздалегідь, тому стійкість до піків перевіряється під час навчань, а не в час звітного навантаження.
Режими роботи: один вузол, власний кластер, керований сервіс
Режим роботи визначає, хто відповідає за доступність контролерів, реплікацію та оновлення. У KRaft метадані тримає кворум контролерів: на одному вузлі його немає взагалі, тому відмова диска зупиняє і запис, і читання. Тому вибір топології впирається у вимоги до відмовостійкості та контролю, а не в обсяг топіків.
Вирішальні параметри — фактор реплікації, мінімальна кількість синхронних реплік, кількість зон розміщення брокерів і вимоги до ізоляції даних.
Якщо регламент забороняє виносити дані за свій контур, керований варіант відпадає; якщо немає команди чергувань, власний кластер стає ризиком.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Один вузол, брокер і контролер разом | Стенд, розробка, потік у межах можливостей одного брокера | Реплікації немає: падіння вузла зупиняє запис і читання, оновлення лише з простоєм |
| Власний кластер, три й більше брокерів у різних зонах | Дані мають залишатися у своєму контурі, потрібен повний контроль параметрів і версій | Кворум контролерів, реплікація, сертифікати та Schema Registry — на вашій стороні |
| Керований сервіс у провайдера | Потрібна відмовостійкість, а своєї команди супроводу немає | Частина параметрів брокера закрита, версія задана провайдером, права та налаштування безпеки обмежені |
Топологію фіксуємо до налаштування TLS і Schema Registry: від неї залежать імена слухачів, схема адресації клієнтів і порядок ротації сертифікатів.
Перехід з одного вузла на кластер робимо через перестворення топіків із потрібним фактором реплікації та перенесення споживачів із фіксацією зміщень — без втрати потоку.
Як відбувається впровадження: від аудиту до передачі в експлуатацію
Етапи впровадження Kafka вибудувані так, що кожен закінчується перевірним артефактом — конфігурацією, схемою або звітом про навантажувальні випробування. Продовий трафік переводиться не «однієї ночі», а після того, як новий контур довів стійкість на реалістичному профілі.
- Аудит кластера. Знімаємо фактичний стан: кількість вузлів, розкладку партицій, фактор реплікації, відстаючі репліки, терміни зберігання й поточні права. На виході — карта вузьких місць і перелік параметрів до зміни.
- Схема партицій і тем. Проєктуємо модель під профіль потоків: ключ партиціювання, запас партицій на зростання, окремі теми для даних із різними вимогами до порядку та допустимих втрат.
- Налаштування вузлів і доступу. Піднімаємо контур: шифрування трафіку, автентифікація, права на рівні тем і груп споживачів, квоти, ліміти на розмір повідомлень. Режим роботи вибираємо так, щоб прибрати зайвий шар координації.
- Реєстр схем і сумісність. Фіксуємо контракти форматів і правило сумісності, щоб нова версія продюсера не ламала вже працюючих споживачів. Невідповідність відсікається на вході, а не в аналітиці.
- Перевірка під навантаженням. Проганяємо профіль, близький до бойового: піковий потік, затримки, падіння вузла, відновлення реплік. Пороги, за яких кластер у нормі, закладаємо в моніторинг і оповіщення.
- Передача в експлуатацію. Віддаємо регламенти, графіки та правила реагування, навчаємо чергову команду, разом проходимо навчальне перемикання. Супровід далі відбувається за документованими процедурами.
Конфігурації, схеми та регламенти, які залишаються у вас
Працюючий кластер сам по собі не розв'язує задачу: якщо через пів року ніхто не пам'ятає, чому вибрано такі параметри реплікації та як видавалися права сервісам, будь-яка зміна перетворюється на розкопки.
Тому ми віддаємо контур разом із повним комплектом артефактів — за ними нова зміна інженерів вводиться в курс без листування з авторами.
- Файли конфігурації брокерів, контролерів і реєстру схем — з коментарями, який параметр за що відповідає і що станеться за його зміни.
- Схема кластера: топологія вузлів, ролі, зони відмови, розподіл партицій і реплік, точки відмови та запас за навантаженням.
- Політики доступу: перелік сервісних облікових записів, їхні права на топіки й групи, правила ротації ключів і порядок видачі нових доступів.
- Регламент резервного копіювання: що копіюється (конфігурації, схеми, стан груп), з якою періодичністю, куди складається і як перевіряється відновлення.
- Регламент оновлення: послідовність дій за вузлами, критерії готовності до переходу на наступний, точки обов'язкової перевірки та порядок повернення до попереднього стану.
- Інструкції з розбору інцидентів: типові збої, на що дивитися насамперед, які метрики та журнали знімати і коли ескалювати.
- Інструкції для команди: як завести топік і зареєструвати схему, як під'єднати нового споживача, які перевірки проганяти перед викладкою.
Документація живе у вашому репозиторії та оновлюється разом із конфігурацією, а не окремо від неї. Опишіть задачу — повернемося з оцінкою обсягу та планом робіт, включно зі складом артефактів, що передаються.
Кейс: відмови раз на добу замість стабільного потоку
Вихідний контур
Один із наших замовників — сервіс із потоком подій від десятків джерел: платежі, статуси замовлень, телеметрія пристроїв. Кластер Apache Kafka із трьох брокерів тримав метадані в окремому координаторі, теми заводилися вручну, а зберігання повідомлень не обмежувалося нічим.
Диски заповнювалися, брокер випадав, групи споживачів ішли в ребалансування, і лаг у години пік зростав до кількох годин.
Що перебудували
Метадані перевели на вбудований консенсус KRaft — окремий координатор прибрали разом із ще однією точкою відмови. Для тем зафіксували фактор реплікації 3 і кворум синхронних реплік 2: запис вважається підтвердженим, лише коли його прийняли мінімум дві копії.
Реєстр схем підняли в кластерному режимі з перевіркою сумісності на кожній зміні, TLS і ротацію сертифікатів увімкнули для всіх клієнтів без винятків, а термін зберігання повідомлень задали окремо для кожної теми.
Метрики до і після
До: збій раз на добу, відновлення 30–40 хвилин, лаг у пік до трьох годин, втрата підтверджених подій під час перемикання лідера.
Після: відмов, що потребують ручного втручання, — нуль за кілька місяців експлуатації; лаг у години пік тримається в межах десятків секунд, відновлення за відмови вузла — одиниці хвилин, втрат підтверджених подій немає.
Що робити, якщо кластер Kafka вже розгорнуто
Працюючий кластер Apache Kafka майже ніколи не доводиться збирати заново — у більшості випадків достатньо ревізії та поетапного плану.
Спочатку фіксуємо стан: кількість брокерів, фактор реплікації топіків, значення min.insync.replicas, накопичені зміщення споживчих груп і пікові години запису. Ці цифри визначають, що можна змінювати на живій системі, а що потребує окремого вікна.
Перехід на вбудований кворум замість окремого координатора відбувається у три кроки: конвертація метаданих, додавання вузлів-контролерів, переведення брокерів у режим, коли вони бачать обидва джерела стану.
Кожен крок зворотний до фінального вимкнення координатора, а перезапуск відбувається по одному брокеру — реплікація тримає доступність, і споживачі не помічають простою.
Оновлення на живій системі підпорядковується порядку: спочатку піднімається протокол обміну між брокерами, потім оновлюються самі брокери. Новий брокер розуміє запити старого клієнта, тому застосунки перезбирати не потрібно.
Окремо перевіряємо реєстр схем: вибраний режим сумісності задає, у якому порядку реєструються нові версії, і його порушення — часта причина відмови відправників одразу після оновлення.
На працюючій системі безпечні додавання брокерів, перерозподіл партицій, тюнінг зберігання, ротація сертифікатів із періодом, коли довіреними вважаються обидва, і правки прав доступу.
Небезпечні зміна ключа партиціювання та зниження фактора реплікації без запасу за диском: розкладка повідомлень змінюється, порядок обробки ламається. План міграції збираємо етапами з явними точками відкату та критерієм, за якого зупиняємося і повертаємося назад.
Часті технічні питання з експлуатації кластера
Експлуатація кластера впирається в одні й ті самі питання: як змінювати формат повідомлень, не зупиняючи споживачів, як розвести доступ між командами та зовнішніми клієнтами, що відбувається за відмови вузла і в якому порядку відбувається планове оновлення. Нижче — короткі відповіді на те, що найчастіше уточнюють до старту робіт.
Як змінювати схему повідомлень без зупинки споживачів?
Схема зберігається в реєстрі схем із увімкненим правилом сумісності: нові поля додаються лише зі значеннями за замовчуванням.
Розгортання відбувається в порядку «спочатку споживачі, потім продюсери», а стара версія схеми залишається доступною — відкат не потребує перезбирання повідомлень.
Як обмежити доступ до кластера для зовнішніх клієнтів?
Кожному сервісу або клієнту — свій обліковий запис із правами лише на потрібні топіки: читання або запис, не ширше. Трафік іде шифрованим каналом із перевіркою сертифіката клієнта, а швидкість обмежена квотами, щоб один споживач не зайняв кластер повністю.
Що відбувається за відмови вузла?
Партиції реплікуються на кілька вузлів, тому за відмови лідер переїжджає на репліку автоматично, і запис продовжується. Відмову вузла ми регулярно проганяємо в тестовому контурі та звіряємо, що жоден споживач не втратив повідомлення.
Як відбувається планове оновлення та супровід кластера?
Оновлюємо по одному вузлу — спочатку репліки, потім основні, сервіс при цьому працює. Супровід включає моніторинг відставання реплік і споживачів, контроль місця на дисках, розбір інцидентів і узгоджені вікна робіт.
Обговоримо задачу: повернемося з оцінкою та планом робіт
Щоб повернутися з оцінкою та планом робіт, а не із загальними формулюваннями, нам потрібні вихідні дані від замовника. Нижче — набір, який закриває 90% питань на старті: за ним видно і обсяг робіт, і ризики, і порядок дій.
- Контур і топологія. Скільки брокерів, як вони рознесені за зонами доступності, хто виконує роль контролерів, чи є окремий контур під перевірки.
- Симптоми. Що саме болить: відставання реплік, часті перебалансування споживачів, зростання затримки під час піку, помилки під час оновлення схем, ручні правки конфігурації.
- Обсяги потоку. Кількість топіків і партицій, добовий обсяг повідомлень, термін і розмір зберігання, профіль навантаження — рівний чи з піками.
- Схеми даних. Чи є реєстр схем, які формати повідомлень використовуються, як зараз перевіряється сумісність версій під час випуску нових сервісів.
- Безпека й доступи. Як автентифікуються клієнти, чи увімкнено TLS, хто володіє сертифікатами і як вони продовжуються, чи потрібне розмежування прав за топіками.
- Обмеження за вікном робіт. Допустимий простій, чи можна перезапускати брокерів по одному, чи є період, коли навантаження мінімальне.
- Інфраструктура й спостережуваність. Де все розміщено, яка система зберігання під журналами, що вже збирається в моніторинг і логи.
З цим набором ми повернемося з оцінкою та планом робіт: етапи, порядок змін, точки перевірки, сценарій відкату та вимоги до вікна. Наступний крок — обговорити задачу на созвоні: уточнюємо деталі, узгоджуємо межі та фіксуємо план із відповідальними й термінами.
