Дублирование состояния в real-time-системах может обходиться дороже, чем показывает строка расходов на память: одни и те же данные нередко одновременно живут в брокере событий, движке обработки и хранилище. Для команд, строящих сервисы на Kafka и Apache Flink, это означает, что оценивать архитектуру только по CPU, RAM и числу партиций уже недостаточно.
На проблему обратило внимание издание The New Stack: типичный потоковый стек разделяет обязанности между несколькими инструментами. Kafka принимает и хранит события, Flink обрабатывает их, а прикладной сервис или база данных держит материализованный результат. Такое разделение выглядит естественно и часто оправдано, однако за него приходится платить несколькими копиями похожего состояния, дополнительными операциями записи и более сложным восстановлением после сбоев.
Главная ловушка в том, что эти расходы редко называются «стоимостью состояния». В бюджетах они расползаются по разным статьям: хранение логов Kafka, локальные файлы и checkpoint'ы вычислительного движка, сетевой трафик, репликация, диски для базы, время на обслуживание инцидентов. В результате команда может видеть приемлемое потребление памяти каждым отдельным компонентом, но не замечать, сколько инфраструктуры занято данными, которые уже существуют в другом слое.
В потоковой обработке состояние необходимо. Оно позволяет считать окна, дедуплицировать события, сопоставлять записи, поддерживать счётчики и восстанавливаться без потери результата. Проблема возникает не из-за самого stateful-подхода, а тогда, когда один и тот же контекст приходится поддерживать независимо в нескольких системах. Например, поток событий хранится ради повторного чтения, агрегаты сохраняются для расчётов, а итог дополнительно записывается для быстрого ответа приложению. Каждая копия может быть разумной по отдельности; вместе они формируют постоянный инфраструктурный налог.
Почему память — плохой единственный индикатор
Оперативная память заметнее всего: её проще измерить, она быстро заканчивается и напрямую влияет на размер инстансов. Но состояние real-time-приложения не сводится к RAM. Kafka хранит журнал событий, Flink должен регулярно фиксировать контрольные точки для отказоустойчивости, а внешнее хранилище получает обновления, необходимые продукту или пользователям. При росте нагрузки растут не только объёмы данных, но и число операций, задержки синхронизации, требования к диску и трафику между компонентами.
Особенно неприятна эта арифметика при восстановлении. После сбоя системе нужно понять, с какого согласованного места продолжать обработку, какие данные уже учтены и какие результаты можно считать актуальными. Чем больше независимых слоёв держат собственное представление одного процесса, тем важнее корректно согласовать их жизненный цикл. Ошибка здесь превращается либо в потерю данных, либо в повторную обработку, либо в дорогую ручную сверку. Последний вариант обычно не попадает в архитектурную диаграмму, хотя именно он хорошо знаком дежурным инженерам.
Это не аргумент против связки Kafka и Flink. У инструментов разные задачи: брокер событий отвечает за доставку и журнал, движок обработки — за вычисления над потоком. Попытка заставить один компонент полностью заменить другой может дать не экономию, а менее надёжную систему с неудобной эксплуатацией. Вопрос скорее в том, какие копии данных действительно нужны для требований к задержке, сроку хранения, аудиту и восстановлению, а какие появились по инерции.
Для российских команд тема практична ещё и потому, что стриминговый стек часто собирают постепенно. Сначала появляется Kafka для интеграций, затем обработчик для аналитики или антифрода, потом отдельная витрина, кэш и база для продуктовых сценариев. Каждый следующий сервис решает понятную задачу, но редко кто возвращается к полной карте владения состоянием. Через год система может быть технически исправной, но никто уже не может коротко ответить, где находится источник истины для конкретного счётчика, заказа или пользовательского профиля.
Что проверить до следующего роста нагрузки
Полезный первый шаг — описать путь одного события от поступления до конечного результата и отметить все места, где его данные сохраняются или восстанавливаются. Для каждого слоя стоит зафиксировать назначение: журнал для повторной обработки, состояние вычисления, витрина для чтения, архив или резервная копия. Затем можно проверить срок жизни каждой копии, её репликацию, объём checkpoint'ов, сетевой путь и владельца. Такая инвентаризация быстро показывает не только дублирование состояния, но и неочевидные риски: устаревшие витрины, бесконечно растущие топики и сервисы, которые нельзя восстановить без ручных действий.
Второй шаг — привязать требования к данным к реальным сценариям. Если результат нужен с минимальной задержкой, материализованная витрина оправданна. Если события должны быть доступны для повторного расчёта, нужен надёжный журнал. Но если копия существует лишь потому, что когда-то упрощала отладку или обходила ограничение ранней версии сервиса, её стоит пересмотреть. Экономия здесь измеряется не только гигабайтами: уменьшается число точек отказа, регламентов и вариантов рассинхронизации.
Дублирование состояния не исчезнет из потоковых архитектур полностью — отказоустойчивость и быстрый доступ к данным требуют компромиссов. Но по мере роста real-time-систем главным вопросом станет не «сколько памяти потребляет кластер», а «сколько раз организация платит за один и тот же факт». Команды, которые умеют ответить на него до масштабирования, получают не модную диаграмму, а более предсказуемую эксплуатацию.
