У новому епізоді подкасту Confluent Developer провідний інженер Confluent і учасник PMC Apache Kafka Ендрю Скофілд говорить не лише про черги чи окремі фічі, а про те, як сьогодні живе й змінюється сам проєкт Kafka. Зсередини спільноти він бачить масштаб контриб’юторів, динаміку складних KIP-ів (Kafka Improvement Proposal), суперечки довкола multi‑tenancy та загальну мету — зробити Kafka більш загального призначення.
155 людей над одним релізом: як виглядає масштаб спільноти Kafka
Останній мажорний реліз Apache Kafka 4.2 став показовим з погляду того, як виросла спільнота проєкту. До нього долучилися 155 контриб’юторів. Для будь-якої окремої компанії це фактично нереальна цифра для однієї інженерної команди — втримати в штаті 155 розробників, що працюють над одним продуктом, важко навіть теоретично.
У випадку Kafka це не одна команда, а розподілена спільнота з різних компаній і організацій, які вкладаються в платформу, якою самі користуються або яку продають. Важливий момент: тут не йдеться про символічні патчі. У проєкт заходять складні функції, які потребують скоординованої співпраці між вендорами, операторами великих кластерів і ядром мейнтейнерів.
Саме ця широка кооперація, зауважує Скофілд, дає те, що практично неможливо відтворити в межах однієї корпорації: живу конкуренцію ідей, багатосторонній дизайн критичних змін і постійну перевірку рішень на реальних сценаріях використання.
Як проходить KIP: мінімум три голоси й пошук «дірок» у дизайні
Формальний механізм розвитку Kafka — KIP-и, пропозиції змін, які проходять публічне обговорення. Для того щоб KIP отримав «зелене світло», потрібно щонайменше три голоси committers. Цей кворум фактично означає дозвіл: можна починати реалізацію, код може рухатися до репозиторію.
На перший погляд KIP-и часто виглядають досить дружніми до читача, особливо якщо обмежитися описовою частиною: що змінюється, як вплине на поверхню API, які сценарії з’являться для користувачів. Але внутрішній процес рецензування набагато жорсткіший.
Той, хто голосує за KIP, не просто читає текст — він активно шукає «дірки». Скофілд описує це як перевірку на те, «чого ви не сказали». Чи є незакриті сценарії відмов? Чи визначено поведінку при крешах? Як це працюватиме при оновленнях?
Характерний приклад з обговоренням Diskless Kafka: одна з критичних тем — як надійно збирати сміття (garbage collection) в об’єктному сховищі. Дані з брокера потрапляють у cloud storage блоками, які потім позначаються координатами. Якщо посеред цього процесу брокер падає, у системі можуть з’явитися «загублені» об’єкти. Виявити й коректно прибрати їх — нетривіальна задача, яка повинна бути чітко описана ще на рівні KIP-а, задовго до того, як код потрапить у main.
Така логіка рев’ю повторюється для кожної великої ініціативи: спільнота не просто перевіряє, що KIP «гарно написаний», а намагається заздалегідь уявити всі способи, як усе може піти не так.
KIP-и з «колективним авторством»: коли один вендор — замало
В Apache Kafka традиційно чимало KIP-ів мають одного автора. На цьому тлі деякі нові ініціативи виділяються масштабом співробітництва.
Скофілд звертає увагу на KIP, в якому відразу шість авторів — рідкісна ситуація для проєкту. Йдеться про проєкт cluster mirroring (новий вбудований механізм disaster recovery) — приклад того, як кілька вендорів і користувачів із різних сторін узгоджують дизайн складної, багаторелізної функції.
Схожа історія й з Diskless Kafka. Тут перший, фундаментальний KIP‑1150 уже пройшов голосування, причому з дев’ятьма голосами committers — суттєво більше мінімально необхідних трьох. Такий результат означає не просто формальний кворум, а широку підтримку ідеї з боку різних учасників екосистеми: спільнота фактично сказала, що хоче саме такого напрямку руху.
Проте навіть після погодження «парасолькового» KIP-у на зразок 1150 робота тільки починається. За ним ідуть детальні, вузькоспеціалізовані KIP-и, де розписується конкретний протокол, структури даних, переходи станів. І кожен із них знову проходить той самий цикл рецензування, пошуку прогалин і поступового наближення до реалізації, яка зможе безпечно потрапити в продакшн-кластери по всьому світу.
Multi-tenancy: усі розуміють, що воно буде, але не як саме
Один із найбільш очікуваних напрямків розвитку Kafka — повноцінний multi‑tenancy. Формально KIP на цю тему вже існує, це «досить великий документ». Але, за оцінкою Скофілда, обговорення застопорилося: немає відчуття, що дискусія реально рухається вперед.
При цьому скепсис стосується не самої ідеї multi‑tenancy, а поточного формату її реалізації. Скофілд прямо говорить, що майбутнє Apache Kafka майже напевно включатиме multi‑tenancy. Однак він не впевнений, що саме теперішній KIP у нинішньому вигляді стане тією реалізацією, яка врешті-решт буде прийнята. Можливо, документ еволюціонує, переформулюється, розіб’ється на кілька, змінить модель — це попереду.
Причина, чому потреба в multi‑tenant Kafka так відчутна, проста: сьогодні багато команд уже симулюють її власними силами. Типовий патерн — один спільний кластер Kafka і різні команди або «клієнти», які розділяють простір назв через префікси в іменах топіків. Далі накладаються політики доступу, внутрішні домовленості, інфраструктурні обмеження — і з’являється квазі‑multi‑tenancy, яка тримається на дисципліні, а не на вбудованих гарантіях платформи.
Бажана модель виглядає інакше: кожен тенант «бачить» свій кластер, може створювати топік із довільною назвою на кшталт T1, і не знає про те, що фізично працює на спільному залізі з іншими. Ізолюють усе — від метаданих до ресурсів. Скофілд упевнений, що до цього стану Kafka прийде. Питання лише в тому, через який саме KIP і з якими проміжними компромісами.
«Зробити Kafka більш загального призначення»: що за цим стоїть
Якщо піднятися над конкретними ініціативами — Diskless Kafka, cluster mirroring, multi‑tenancy — простежується спільний вектор. Скофілд формулює його як прагнення зробити Kafka більш general purpose.
Ідея в тому, щоб розробник, маючи конкретну задачу, не мусив щоразу ставити собі запитання: «Чи можу я це зробити на Kafka, чи тут вона вже не підходить?» Наразі існує низка сценаріїв, які платформа не підтримує достатньо добре. Серед прикладів, які він згадує, — робота з великими повідомленнями. Є й інші зони, де Kafka «майже» підходить, але бракує кількох ключових можливостей.
У цьому контексті:
- disaster recovery вбудованого рівня означає, що Kafka може бути «рідним» рішенням для сценаріїв, де раніше доводилося клеїти зовнішні тулінги;
- підтримка зберігання в хмарних об’єктних сховищах знімає бар’єр для тих, кому критичні витрати на мережу між брокерами;
- multi‑tenancy відкриває шлях до того, щоб один великий кластер безпечно обслуговував десятки й сотні ізольованих середовищ.
Разом це наближає Kafka до ролі не просто стримінгового рушія, а базової платформи обміну подіями і повідомленнями, яка закриває ширший спектр задач, не вимагаючи від команд «обходити кути» чи будувати власні надбудови.
Висновок: повільні дискусії, швидкі зрушення
Картина, яку описує Ендрю Скофілд, не виглядає як «мовчазна еволюція» ядра Kafka. Це радше постійний діалог між кількома спільнотами одночасно: великими внутрішніми користувачами, комерційними постачальниками, мейнтейнерами та авторами KIP-ів.
Частина ініціатив іде швидко — як cluster mirroring, що за місяць від публікації KIP-а вийшов на стадію «готового до серйозного аудиту» дизайну. Інші, як multi‑tenancy, буксують у дискусіях, але при цьому мають майже гарантоване майбутнє в якомусь оновленому вигляді.
У центрі всього — механізм KIP-ів, де кожна значуща зміна проходить через мінімум три голоси committers і багато раундів обговорень, під час яких шукають не те, що вже описано, а те, про що забули згадати. У поєднанні з 155‑ю контриб’юторами лише в одному релізі 4.2 це створює ту саму «повільну, але стійку» динаміку, яка дозволяє Kafka одночасно зберігати стабільність і рухатися в бік більш універсальної платформи.
Джерело
155 Contributors Later: Where Kafka Is Headed ft. Andrew Schofield | Ep. 34 | Confluent Developer