TL;DR: KIP‑1150 (Diskless Topics) предлагает Kafka писать сообщения сразу в облачное хранилище (S3 и аналоги), минуя диски брокеров. Это сильно экономит деньги и упрощает масштабирование в облаке, но увеличивает задержки и делает Kafka зависимой от облачных сервисов. Отлично для дешёвых, "толстых" потоков логов, но плохо подходит для real-time систем с миллисекундными требованиями.
Эта статья – моя личная попытка разобраться в KIP-1150. Я не претендую на истину, скорее хочу поделиться мыслями и предложить обсудить это предложение.
Давайте представим, что кластер Apache Kafka может обходиться без постоянного хранения данных на локальных дисках брокеров – вместо этого все сообщения сразу пишутся в облачное хранилище (например, Amazon S3). Звучит радикально, но именно это предлагается в KIP‑1150 под названием Diskless Topics. Идея в том, чтобы перенести репликацию с брокеров на объектное хранилище (Diskless Kafka: 80% Leaner, 100% Open). Проще говоря, Kafka будет хранить данные топика напрямую в внешнем хранилище, минуя привычную многократную запись на диски разных брокеров. Такой подход обещает серьёзное снижение расходов на инфраструктуру и упрощение масштабирования в облаке – недаром вокруг KIP‑1150 поднимается столько шума. Давайте разберёмся, какие плюсы и минусы у «бездискового» Kafka, и честно оценим, чем придётся поступиться ради экономии.
Схема из блога Aiven: зелёным показаны потоки данных в классической Kafka с репликацией между зонами (AZ), синим – в режиме Diskless (запись сразу в S3). Видно, что Diskless Topics устраняют межзоновые пересылки: каждый брокер пишет данные своего AZ прямо в общее хранилище, где они доступны всем.
Плюсы KIP‑1150 (Diskless Topics)
Снижение затрат на ~80% и отказ от дорогостоящих дисков.
Главная "фишка" – резкое уменьшение совокупной стоимости владения Kafka в облаке. Благодаря тому, что данные не дублируются на нескольких брокерах, а хранятся единым экземпляром в S3, пропадают затраты на лишние SSD и межзоновый трафик. По оценкам авторов KIP, исключение дисков из «горячего» пути репликации убирает привычные боли (ребалансировку кластера, “горячие” партиции, лимиты IOPS) и снижает расходы на cross-AZ трафик и хранение до 80% (Diskless fixes two problems in Kafka). Реальные бенчмарки подтверждают экономию того же порядка: при оптимальном размере батчей можно срезать ~80% стоимости по сравнению с классической репликацией. Для облачных развертываний Kafka, где до 80–90% бюджета сейчас уходит на сеть и диски, это колоссальная выгода.
Авто-масштабирование и простое управление кластером.
Diskless Kafka обещает сделать кластеры эластичными по-настоящему. Добавление нового брокера больше не требует переливания в него терабайт старых данных – все данные уже лежат в объектном хранилище, так что новый брокер готов обслуживать трафик за считанные секунды (The Hitchhiker’s guide to Diskless Kafka). Точно так же при снижении нагрузки лишние брокеры можно быстро выключить без долгого перемещения реплик. По сути, масштабирование происходит “на лету”, без дорогостоящих ребалансов и простоя. К тому же исчезает жёсткая привязка раздела (partition) к конкретному лидеру-брокеру: любая нода в кластере может принять запись для “бездискового” топика, а значит, нагрузка автоматически балансируется по зоне доступности – если один брокер перегружен, продюсеры мгновенно переключатся на соседний в той же AZ. Всё это значительно упрощает жизнь админам Kafka.
Дешёвая гео-репликация и отказоустойчивость “из коробки”.
Раз данные хранятся в облачном хранилище, которое само по себе реплицирует их между датацентрами, отпадает необходимость настраивать сложные межрегиональные репликации для резервирования. Катастрофоустойчивость повышается – при сбое целого AZ или даже региона новая инфраструктура сможет подтянуть все данные из общего хранилища. Объектные хранилища крупных облаков (S3, GCS, Azure Blob) изначально спроектированы как высокодоступные и сверхнадёжные (11 девяток), поэтому Kafka доверяет им обеспечение долговечности данных. К тому же появляется приятный бонус: данные топиков становятся легче интегрировать с Lakehouse (аналитическими хранилищами). Фактически логи Kafka уже лежат в S3, откуда их можно напрямую читать batch-фреймворками или SQL-движками для аналитики. Эксперты отмечают, что Diskless Topics прокладывают путь к нативной интеграции Kafka с Data Lake/Lakehouse платформами (What If We Could Rebuild Kafka From Scratch? - Gunnar Morling) – можно потреблять данные вне самой Kafka без дублирования, что большой плюс для сложных конвейеров обработки.
Гибкость: два режима в одном кластере без боли миграции.
Важно отметить, что diskless-топики вводятся как опция, а не замена всего и сразу. Кластер Kafka сможет содержать и классические разделы на локальных дисках, и новые “бездисковые” топики. Включить новинку проще простого – достаточно создать топик с параметром topic.type=diskless. Никаких изменений в клиентах или в протоколе Kafka не требуется, старые приложения ничего не заметят. Это позволяет постепенно попробовать новую фичу на отдельных потоках (например, на аналитических событиях или телеметрии), не ломая существующий продакшен. Подход Extend, don’t rewrite в KIP‑1150 гарантирует полную обратную совместимость. Более того, инициатива открытая: вместо закрытых форков Kafka получит единое штатное решение. Никакого вендер-лока или зоопарка из альтернатив – достаточно обновиться до версии с поддержкой Diskless Topics.
А теперь давайте честно взглянем на минусы...
Минусы и подводные камни
Рост задержек и падение “скорости” топиков.
За всё приходится платить, и здесь расплата – повышенные latency. Запись и чтение сообщений в “diskless” топике неизбежно медленнее из-за прохождения через внешнее хранилище и дополнительную координацию. Если обычная Kafka славится строжайшими миллисекундами, то у Diskless Kafka цифры другие: авторы признают, что это “более медленная, но экономичная Kafka”. По данным симуляций, типичная end-to-end задержка может составлять сотни миллисекунд (200–400 мс на сообщение при размере сегмента ~1 МБ). Для многих бэчевых или логирующих задач это приемлемо, но для сверхчувствительных реалтайм-пайплайнов (финансы, телеком и т.п.) такое решение вряд ли подойдёт. Таким образом, Diskless Topics – это осознанный обмен скоростью на цену. В критичных по latency сервисах придётся оставлять классические топики с локальной репликацией (благо Kafka позволяет гибко комбинировать оба типа в рамках одного кластера).
Зависимость от облачной инфраструктуры
Новая архитектура в полной мере раскрывается именно в облаке, где есть быстрые объектные хранилища и дорогой cross-AZ трафик. Если вы разворачиваете Kafka on-premise, выгода станет сомнительной: придётся самим поднимать и обслуживать распределённое хранилище (Ceph, MinIO или аналог), что добавляет сложности. Diskless режим фактически привязан к облачным провайдерам, которые дают готовое API хранения. Нужно учитывать, что вы доверяете сохранность данных внешней системе. Надёжность у S3 и аналогов фантастическая, но в теории сбой у провайдера может парализовать кластер Kafka – локальных копий-то нет. В классической Kafka данные дублируются на нескольких брокерах, а здесь весь “источник правды” – внешнее хранилище. Так что single point of failure смещается с дисков брокеров на S3 (пусть и распределённый). Кроме того, появятся прямые расходы на запросы к объектному хранилищу (PUT/LIST/GET) – при мелких сообщениях ценовой выигрыш может частично съесться оплатой API-вызовов. Придётся тонко настраивать размер загружаемых блоков данных: мелкие сегменты дают минимальную задержку, но генерируют тысячи запросов в S3, а крупные экономят на количестве операций, зато увеличивают время доставки сообщений. Админам нужно будет найти баланс под свой сценарий, то есть добавляется новая настройка производительность vs. стоимость.
Сложность и новизна решения
Хотя идеологи KIP‑1150 подчёркивают, что изменение затрагивает лишь ~1.7% кода Kafka (≈23K строк), по факту это довольно серьёзная перестройка привычной логики. Появляется новый компонент – так называемый Batch Coordinator, который централизованно присваивает глобальные offset’ы событиям.
Раньше порядок в пределах раздела обеспечивал лидер-брокер, теперь же порядок для diskless-топика ведёт отдельный координатор (грубо говоря, распределённый счётчик последовательности). Это добавляет точку координации, потенциально влияющую на сквозную производительность. Нужно будет обеспечить надёжность и отказоустойчивость самого координатора, иначе падение единственного координатора остановит весь кластер. Также реализация разбита на несколько отдельных KIP’ов (The Hitchhiker’s guide to Diskless Kafka) – ядро, координатор, компактация и пр. – что намекает на сложность задачи. Некоторые функции Kafka потребуют доработки под новую модель хранения. Например, compaction старых сообщений должна выполняться уже на уровне объектного хранилища (для этого подготовлен отдельный KIP-1165). Точно так же транзакции, гарантия exactly-once семантики и другие тонкости должны быть учтены в новой архитектуре. И хотя в KIP-1150 заявлено, что никаких изменений во внешних API не произойдёт, реальные пользователи могут столкнуться с нюансами. В общем, это большое изменение, которое ещё предстоит обкатать. По состоянию на апрель 2025 года KIP‑1150 находится в стадии обсуждения (KIP-1150: Diskless Topics) и пока не включён в релизы Kafka. Ранние прототипы и форки (Confluent, Redpanda, AutoMQ и др.) вселяют оптимизм, но окончательный дизайн может эволюционировать под влиянием комьюнити.
Не панацея от всех проблем Kafka
Важно понимать, что Diskless Topics решают конкретно проблему стоимости и масштабируемости хранения, но не устраняют другие “особенности” Kafka. Например, сохраняется разделение топиков на партиции (partitioning) и связанная с ними семантика. Некоторые эксперты мечтают при переходе на облачное хранение вообще избавиться от явных партиций – мол, на бесконечном S3 можно было бы обеспечить либо глобальный порядок сообщений, либо порядок по ключу, и не мучать разработчиков хакингом с номерами разделов (What If We Could Rebuild Kafka From Scratch? - Gunnar Morling). Однако KIP‑1150 не ставит целью переделать Kafka “с нуля” – он скорее минимально возможным образом встраивает объектное хранилище в существующую архитектуру. Поэтому всё, что касается модели данных и API Kafka (партиции, консистентность, потребители/группы и т.д.), остаётся по старинке. В итоге Diskless Kafka – это эволюция, а не революция: она решает часть болей, но явно не все. Например, одновременный доступ на запись к одному ключу, необходимости схем (Schema Registry) и прочие аспекты никуда не делись. Если Kafka вас не устраивала концептуально, новый тип топиков вряд ли всё изменит. Зато если проблема именно в масштабировании и стоимости, то здесь как раз предлагается отличное решение, встроенное в экосистему Kafka (вместо перехода на сторонние продукты).
Вывод
KIP‑1150 выводит Kafka на новый виток развития, добавляя долгожданную диссоциацию хранения и вычислений для мира облаков. Diskless Topics обещают впечатляющую экономию и гибкость: платить по факту за хранение, мгновенно масштабироваться, не беспокоиться о износе дисков и «переезде» данных при каждом шардировании. При этом Kafka остаётся Kafka – с всё той же надёжностью доставки и привычным API, просто под капотом данные будут лежать в другом месте. Конечно, за удобство приходится пожертвовать долей производительности и завязаться на облачные сервисы.
Подход не универсален: для ультра-низких задержек он не годится, да и зрелости ему пока не хватает. Тем не менее, крупные игроки рынка уже двинулись в этом направлении, выпустив собственные решения “Kafka на S3”. Теперь очередь за open-source сообществом. Если идея выстрелит, то через пару лет дисковые и бездисковые топики станут такой же обыденностью, как SSD и Tiered Storage сегодня.
Ещё раз напомню: это моя личная оценка ситуации. Может, я что-то упустил или неправильно понял – буду рад вашим поправкам и мнению в комментариях!
UPD: Комментарии разработчика
В комментариях откликнулся один из разработчиков KIP-1150 – Иван Юрченко @Ivanhoe и поделился дополнительной информацией из первых рук, за что ему огромное спасибо! 🙌
Краткое саммари:
Когда ожидать Diskless Topics в стабильном продакшене?
Примерная оценка – около 3 лет. Для сравнения: Tiered Storage шёл к general availability аж 5,5 лет, в основном из-за долгих обсуждений дизайна. Надеемся, что тут получится быстрее.Для каких сценариев подходит diskless, а для каких – нет?
Всё, где допустима задержка между producer'ом и consumer'ом до 1 секунды (p99) — например, потоки логов, телеметрия, аналитические события.
Не рекомендуется использовать для real-time аналитики, рекомендаций, рекламы и всего, что напрямую влияет на пользователя в реальном времени.Какие задержки обработки сообщений можно ожидать?
Цифры из прототипов пока не публикуются (правильное решение – чтобы не оставить неправильные ожидания на годы вперёд). Но общая архитектура такая:Буферизация на брокере – около 250 мс (можно настраивать).
Загрузка буфера в объектное хранилище – 200–300 мс для обычного S3.
Коммит через Batch Coordinator – цель добиться low two digits latency (то есть 10–99 мс). Итоговая задержка будет зависеть от нагрузки и настроек, но в общем случае стоит ожидать сотни миллисекунд.
Какой объём данных рассчитан на Batch Coordinator?
По плану: около 100 байт метаданных на один батч. С учётом оптимизаций и трюков по снижению количества долгосрочно хранимых батчей, можно ожидать, что 1 триллион батчей займёт ~100 ГБ метаданных. По современным меркам это вполне подъёмный объём для хранения и обработки.Можно ли масштабировать Batch Coordinator горизонтально?
Да! Имплементация, предложенная в KIP-1164, использует топики самой Kafka для хранения метаданных. Масштабирование происходит через увеличение количества партиций в мета-топике и распределение лидеров этих партиций по разным узлам. То есть горизонтальный рост заложен в дизайн изначально.
