Apache Kafka продовжує еволюціонувати під тиском хмарної економіки. Один із найпомітніших напрямків зараз — ініціатива Diskless Kafka, яку в спільноті веде компанія Aiven. Про неї детально говорить Ендрю Скофілд, principal engineer у Confluent і учасник PMC Apache Kafka, у розмові про те, куди рухається проєкт.
Йдеться не про окрему фічу, а про цілу сім’ю KIP‑ів, що радикально переосмислюють зберігання даних у Kafka: відмову від локальних дисків брокерів на користь об’єктного хмарного сховища та зміну моделі реплікації заради економії на мережі.
Чому Kafka в хмарі виявилася дорогою
Скофілд наголошує на простому, але болючому факті: запуск Kafka в хмарі — дорогий перш за все через мережу. Класична Kafka була спроєктована під датацентри, де внутрішній трафік нічого не коштував з точки зору білінгу. У такому середовищі подвійна й потрійна реплікація між брокерами була фактично «безкоштовною» з погляду мережевих платежів.
У хмарі все інакше. Дані між брокерами доводиться реплікувати через мережу, і за кожен гігабайт цього трафіку провайдер виставляє рахунок. Саме це, за словами Скофілда, і робить «Kafka на cloud storage» дорогою: ви не лише платите за зберігання, а й за постійний міжброкерний трафік.
На ранніх етапах розвитку Kafka ніхто всерйоз про це не думав. Система жила всередині корпоративних датацентрів, де мережа сприймалася як фоновий, уже оплачений ресурс. Перехід до хмарної моделі оголив те, що в старій архітектурі було прихованою передумовою: мережа не безкоштовна, а реплікація — це не лише стійкість, а й пряма витрата грошей.
Diskless Kafka з’являється як відповідь саме на цей клас проблем.
Ідея Diskless: об’єктне сховище замість локальних дисків
Концепція Diskless Kafka будується на відмові від традиційної схеми «локальний диск брокера + реплікація між брокерами» у хмарі. Натомість пропонується використовувати об’єктне сховище як основне місце зберігання, а не як допоміжний архів чи бекоп.
Скофілд формулює це прямо: суть у тому, що можна позбутися дорогого міжброкерного трафіку, якщо замість локальних дисків у хмарі використовувати хмарне об’єктне сховище. У такій моделі не потрібно реплікувати дані між брокерами в звичний спосіб — зникає необхідність постійно ганяти великі обсяги логів через мережу кластера.
З цієї точки зору Diskless — не просто оптимізація, а зміна ключової передумови: стійкість і доступність мають спиратися на саму інфраструктуру об’єктного сховища, а не на N-кратну реплікацію даних між вузлами Kafka. Це амбітний крок: об’єктне сховище стає частиною моделі зберігання самої Kafka, а не стороннім сервісом.
Технічно в Diskless Kafka брокер накопичує дані й пакетно вивантажує їх в object storage, зберігаючи «хендл» — координати партії в об’єктному сховищі. У KIP‑ах це описується як batch coordinates, тобто вказівник на блок записів. Локальне сховище при цьому перестає бути довгостроковим джерелом істини.
Сімейство KIP‑ів замість одного «магічного» дизайну
На відміну від деяких попередніх великих змін у Kafka, Diskless одразу замислюється як сімейство KIP‑ів, а не як один монолітний KIP зі слідом із десятків доповнень.
Скофілд нагадує історію з KIP‑500 (CRAFT): тоді було опубліковано досить загальний KIP, який проголошував мету — замінити ZooKeeper власним консенсус-протоколом, але не давав усіх деталей. Потім роками з’являлися супутні KIP‑и, а обговорення розтягнулося на тривалий період.
У випадку Diskless підхід інший. Уже сьогодні це позиціонується як «family of KIPs». Перший з них, KIP‑1150, пройшов голосування і отримав схвалення спільноти як фундаментальний. Скофілд підкреслює, що підтримка була незвично широкою: на дискусійному треді було дев’ять голосів від коміттерів, значно більше мінімально необхідних трьох. Це сигнал про те, що ідея Diskless викликає консенсус серед різних вендорів та учасників проєкту.
Після 1150 настала фаза деталізації. За словами Скофілда, наразі є два суттєві KIP‑и, які перебувають «під розслідуванням або обговоренням». Вони ще не завершені, але вже «в досить хорошій формі», тобто їх можна читати й розуміти, що саме зміниться в системі. Це нетипово для великих KIP‑ів: часто на ранніх стадіях навіть активним учасникам складно вчитатися в деталі. Тут же рівень зрілості вищий, але шлях до фінального голосування, на думку Скофілда, ще довгий.
Важливо й те, що до моменту, поки ці KIP‑и не будуть затверджені, жоден рядок коду Diskless не потрапить до Apache Kafka. Спочатку — узгоджений дизайн у відкритому процесі, потім реалізація. Це класична для Kafka модель: публічна дискусія, скрупульозна перевірка, потім багаторелізна реалізація.
Головний виклик: як збирати сміття в об’єктному сховищі
Один із найцікавіших технічних аспектів Diskless, який виділяє Скофілд, — проблема «смарт»‑видалення даних у хмарному сховищі. Якщо локальний диск брокера — це керований лог-файл, де Kafka чудово вміє чистити й компактити сегменти, то об’єктне сховище диктує іншу динаміку.
У Diskless-сценарії брокер накопичує дані й час від часу пакує їх у великі об’єкти в storage. Далі Kafka оперує не окремими файлами на локальному диску, а координатами цих батчів в об’єктному сховищі. Проблема починається там, де вступає в гру реальний світ: збої, падіння процесів, неповні операції.
Скофілд наводить класичний кейс: кластер може «впасти» посеред операції завантаження чергової порції даних в object storage. Частина стану могла встигнути оновитися, частина — ні. У результаті з’являються «осиротілі» об’єкти, яких Kafka більше не «бачить», але які продовжують займати місце й коштувати грошей.
Саме тому питання надійної «garbage collection» для хмарного сховища стало одним із ключових сюжетів у Diskless‑KIP‑ах. Треба дати відповідь на запитання: як, не покладаючись на ручні інструменти адміністрування, надійно виявляти й прибирати такі осиротілі об’єкти, щоб не накопичувати приховане сміття й не платити за нього роками.
Скофілд зазначає, що в поточних версіях KIP‑ів це вже обговорюється, але остаточного технічного рішення ще немає. На момент, коли він востаннє їх перечитував, там була радше дискусія, ніж фінальний дизайн. Це саме той тип питань, на які коміттери дивляться особливо прискіпливо: «що може піти не так» і «які сценарії відмов ми ще не врахували».
Очікування при цьому прагматичні: Diskless, швидше за все, так само розтягнеться на кілька релізів, як колись це було з чергами для Kafka. Перші версії можуть не повністю закривати всі сценарії збору сміття, але до загальної доступності (GA) такі механізми повинні бути надійно відпрацьовані.
Багаторелізна еволюція, а не «великий вибух»
І Diskless, і нещодавні великі зміни в Kafka демонструють спільний підхід: великі функціональні блоки впроваджуються через кілька мажорних релізів із чіткою поетапною стратегією. Скофілд згадує черги для Kafka як приклад: там теж був великий базовий KIP, а потім у наступних версіях з’являлися додаткові KIP‑и, які закривали конфігураційні прогалини або уточнювали поведінку.
Те саме очікується й від Diskless: спочатку фундамент (KIP‑1150), потім ще кілька великих технічних KIP‑ів, згодом — дрібніші доповнення. При цьому кожен крок супроводжуватиметься ретельним рецензуванням, де, за словами Скофілда, головний фокус — не стільки на тому, що добре виписано, скільки на тому, «чого не сказали». Особливо це стосується відмовостійкості та управління станом при збоях.
Такий підхід впливає і на очікування ринку. Не варто чекати, що Diskless Kafka з’явиться в одному релізі як повністю завершена система. Швидше це буде поступове розширення можливостей, де кожен новий реліз покриває черговий сегмент задач: базову інтеграцію з object storage, моделі реплікації, життєвий цикл об’єктів, угоду з відмовами.
Висновки: дорожня карта для «бездіскової» Kafka
Diskless Kafka стає однією з ключових ініціатив, що визначають майбутнє Apache Kafka в хмарному світі. Її мета чітка: позбутися надмірних витрат на мережну реплікацію між брокерами, перенісши зберігання в об’єктне хмарне сховище й змінивши саму модель захисту даних.
Уже зараз є важливі віхи: фундаментальний KIP‑1150 схвалено з широкою підтримкою, і над двома наступними ключовими KIP‑ами активно працюють. Найгостріші питання — це не стільки сам факт винесення даних в object storage, скільки операційні деталі: як надійно прибирати сміття, що робити з осиротілими об’єктами після збоїв, як гарантувати коректну поведінку кластера при часткових відмовах.
Скофілд однозначно розглядає Diskless як великий, багаторелізний проєкт. Його успіх залежатиме не лише від дизайну KIP‑ів, а й від того, наскільки рано і ретельно спільнота «прожує» всі складні кути — від моделі реплікації до garbage collection у хмарі.
Для організацій, які вже сьогодні болісно платять за міжброкерний трафік у хмарних кластерах Kafka, ця ініціатива може стати одним із найважливіших напрямків розвитку платформи в найближчі роки.
Джерело
Confluent Developer Podcast — 155 Contributors Later: Where Kafka Is Headed ft. Andrew Schofield