Хранение 50 ТБ audit-логов на одном Kafka-брокере при репликации 3 в AWS может обходиться примерно в $12,3 тыс. в месяц только на блочном хранилище. На этом фоне облачный Kafka перестает быть просто «Kafka в Kubernetes» и превращается в историю про экономику: сколько стоят не диски, а сами паттерны чтения, автоскейлинг и изоляция команд.
Об этом подробно пишет InfoQ в материале Viquar Khan, где разбирается архитектурный разворот Kafka в сторону cloud-native-модели: tiered storage, телеметрия для FinOps, более мягкое масштабирование consumer-групп, виртуальные кластеры и Share Groups. Для русскоязычных платформенных команд вывод довольно прямой: в облаке дорого не только хранить данные, но и не понимать, кто, когда и зачем их перечитывает.
Kafka перестраивают под экономику облака
Исторически Kafka был заточен под вполне земную инфраструктуру: локальные диски на брокерах, append-only лог, чтение из page cache операционной системы, миллисекундные задержки и максимальная предсказуемость. Этот дизайн отлично работал в bare metal и классических дата-центрах, но при переносе в публичное облако выяснилось, что старая архитектурная добродетель плохо дружит с новой моделью биллинга. Репликация данных между зонами доступности, дорогое блочное хранилище и длинные сроки retention быстро раздувают счет.
В статье приводится показательный пример Discover Financial Services. Компания перевела legacy-среду card settlement в cloud-native-архитектуру с Apache Kafka как центральной событийной шиной, а данные отправляет дальше в Amazon EMR и Apache Spark для fraud detection и risk scoring. По данным InfoQ, после миграции срок внедрения ценовых изменений сократился с шести месяцев до трех недель, а платформа научилась обрабатывать 4 млн транзакционных записей за девять минут. Но такой выигрыш по скорости разработки и аналитике неизбежно вскрывает второй слой проблемы: экономика эксплуатации большой мультиарендной стриминговой платформы в облаке начинает жить по своим правилам.
Отсюда и главный сдвиг: Kafka постепенно движется от монолитной схемы, где compute и storage жестко связаны на уровне брокера, к более разнесенной архитектуре. Самый заметный шаг здесь — KIP-405 и tiered storage. Идея проста: горячие данные остаются на локальном, быстром уровне, а холодные сегменты после ролловера уезжают в объектное хранилище вроде Amazon S3. Внутри брокера за это отвечает Remote Log Manager. На бумаге все выглядит как очевидная оптимизация, но в реальной эксплуатации дешевый storage почти всегда означает более дорогой доступ к нему.
Именно поэтому автор статьи отдельно предупреждает: включать tiered storage «везде и сразу» — плохая идея. Выигрыш появляется там, где retention измеряется неделями и годами, а не часами, и где большая часть массива — действительно холодные данные. В качестве примера приводится сценарий compliance и аудита: если финансовая организация держит 50 ТБ логов на брокер в AWS EBS gp3 по цене $0,08 за ГБ в месяц при факторе репликации 3, только хранение обходится примерно в $12 288 в месяц на брокер. Перенос холодных сегментов в S3 Standard по $0,023 за ГБ в месяц снижает стоимость примерно до $1 178. То есть экономия может приближаться к 90%, а на более дорогих io2-томах — и превышать этот уровень. Важно, что автор оговаривает контекст: расчеты основаны на публичных ценах AWS в регионе US East по состоянию на 2025 год, и финальная цифра зависит от региона, скидок и характера чтения.
Самая дорогая строчка в счете — не диск, а чужой replay
На этом месте у облачного Kafka начинается менее очевидная часть. Когда данные лежат в объектном хранилище, стоимость платформы зависит уже не только от объема, но и от числа обращений к API. Если одна команда запускает массивный replay или ML-пайплайн перечитывает исторические топики неэффективными батчами, платить за это будет не абстрактный «кластер», а вполне конкретный бюджет на запросы к S3 и сетевую активность. Поэтому в статье звучит важный тезис: платформенным командам нужна видимость расходов на уровне клиентов и consumer-паттернов. Иначе один неудачный job может устроить скачок расходов, а разбираться, кто именно его вызвал, придется уже после закрытия месяца.
Из этого вытекает и второй архитектурный сдвиг — Kafka все меньше выглядит как чисто инфраструктурный компонент и все больше как «экономическая ОС» для событийных платформ. Речь не о красивой метафоре, а о вполне приземленной операционке: chargeback-механизмы, телеметрия для FinOps, правила на replay тяжелых топиков, выбор между стриминговой и почти-очередной семантикой в зависимости от профиля нагрузки. Для бизнеса это означает, что владение Kafka в облаке больше нельзя сводить к SRE-поддержке брокеров. Для разработчиков — что дешево хранить терабайты истории еще не значит дешево их читать.
Еще один болезненный сюжет — масштабирование потребителей. Старый протокол ребалансировки в Kafka делал любое динамическое изменение consumer group почти неизбежным источником пауз: при скейле приходилось фактически тревожить всю группу. В статье подчеркивается, что протокол нового поколения заметно снижает этот операционный барьер. В практическом смысле это хороший сигнал для Kubernetes-native сценариев, где autoscaling давно хочется включать чаще, чем хотелось потом чинить лаги и stop-the-world-эффекты на ребалансе.
Не менее важен и вопрос мультиарендности. До сих пор крупные организации часто выбирали между двумя неидеальными вариантами: отдельный Kafka-кластер на команду или общий кластер со слабой изоляцией и постоянными спорами о noisy neighbors. Виртуальные кластеры, о которых идет речь в материале, предлагают промежуточную модель: строгие границы между арендаторами без физического дублирования всей инфраструктуры. Для компаний с десятками продуктовых команд это особенно важно: платить за отдельный кластер на каждый домен дорого, а жить в одном общем без жестких ограничений еще дороже, просто счет приходит не сразу, а через инциденты.
Наконец, статья обращает внимание на Share Groups — подход, который ослабляет традиционную связку между числом партиций и параллелизмом потребителей. Для Kafka это почти идеологический сдвиг. Раньше рост consumer-side throughput часто упирался в необходимость перепартиционировать топики, а это уже отдельный проект с миграциями, рисками для ordering и неприятными побочными эффектами для продакшена. Share Groups обещают более гибкую модель, где масштабирование потребителей меньше зависит от прежних решений по partition count. Для команд это означает меньше архитектурных долгов, заложенных на старте «на вырост».
Дальше — самый амбициозный вопрос: может ли Kafka вообще уйти в почти бездисковое будущее, где локальный storage на брокере перестанет быть центром всей конструкции. Пока это не похоже на историю про быстрый и безусловный переход. Слишком многое в производительности Kafka десятилетиями держалось именно на локальности данных и предсказуемости диска. Но направление уже видно: чем активнее Kafka встраивается в облачную экономику, тем меньше ее можно оценивать только по latency и throughput и тем больше — по тому, насколько прозрачно она позволяет считать стоимость хранения, replay, изоляции арендаторов и эластичного масштабирования. Для платформенной инженерии это, возможно, и есть главный апгрейд: облачный Kafka становится не просто шиной событий, а дисциплиной учета архитектурных последствий каждого чтения и каждой партиции.