Tiered Storage

Традиционный Kafka-кластер хранит все данные локально на дисках брокеров. Это простое решение, но оно создаёт критическое ограничение: объём данных в кластере прямо пропорционален числу брокеров и размеру их дисков. Если вы хотите хранить месяц данных — нужны большие диски. Если хотите хранить год — нужно значительно масштабировать кластер.

Tiered Storage решает эту проблему, разделяя данные на горячий (local) и холодный (remote) уровни.

Проблема традиционного хранения

Рассмотрим типичный сценарий: production-кластер с топиком events, 10 ТБ данных за месяц, retention = 30 дней. При replication factor = 3:

Общий объём дисков = 10 ТБ * 3 реплики = 30 ТБ
Стоимость NVMe SSD (i3.8xlarge): ~$7.5/час * 3 брокера = $22.5/час
Годовая стоимость: ~$200 000

Большинство consumer-трафика приходится на последние часы или дни — «горячие» данные. Данные недельной давности читаются значительно реже. Тем не менее вы платите за хранение всех 30 ТБ на дорогостоящих SSD.

Архитектура Tiered Storage

Tiered Storage разделяет данные на два уровня:

Remote Log Manager

Remote Log Manager (RLM) — это компонент брокера, отвечающий за:

1. Offloading: перенос закрытых сегментов из local tier в remote tier
2. Metadata tracking: отслеживание, какие офсеты хранятся в remote tier (метаданные хранятся в internal Kafka топиках)
3. Fetch routing: при запросе consumer на offset в remote tier — скачивание сегмента из объектного хранилища и обслуживание запроса

RLM — это плагин-интерфейс (RemoteLogManagerPlugin). Confluent, AWS MSK и другие managed-решения предоставляют реализации для S3, GCS и Azure Blob Storage.

local.log.retention.ms и local.log.retention.bytes

Ключевые параметры tiered storage:

Пример конфигурации для топика с 7-дневной глобальной retention и 12-часовой локальной:

kafka-configs.sh --bootstrap-server localhost:9092 \
  --entity-type topics \
  --entity-name events \
  --alter \
  --add-config \
  "remote.log.storage.enable=true,\
   local.log.retention.ms=43200000,\
   log.retention.ms=604800000"

Данные старше 12 часов автоматически переносятся в S3 (или другое remote хранилище). Глобальный retention 7 дней контролирует, когда данные удаляются из remote tier.

Путь чтения (Fetch Path)

Когда consumer запрашивает данные:

1. Брокер определяет, в каком tier находится запрошенный offset
2. Если offset в local tier → обычное чтение с диска (задержка: единицы миллисекунд)
3. Если offset в remote tier → RLM скачивает нужный сегмент из объектного хранилища, буферизует и возвращает данные (задержка: 100-500 мс в зависимости от размера сегмента и сети)

Cost vs Latency Trade-off

Tiered Storage — это компромисс:

Для большинства production-сценариев:

• Local retention = 2-24 часа — достаточно для большинства consumer lag’ов
• Remote retention = 7-90 дней — полная история в объектном хранилище
• Экономия = 60-80% стоимости брокерских дисков при сохранении полной истории

Статус: production с Kafka 3.6

Tiered Storage стало production-ready в Kafka 3.6 (2023-10). В Kafka 4.0 (2025-03) feature получил значительные улучшения:

• Поддержка KRaft без ZooKeeper (ZK-режим не поддерживался в tiered storage)
• Улучшенное восстановление брокера с remote tier
• Пониженная задержка fetch для remote segments

На 2026-04, Kafka 4.2 (latest stable) включает полностью зрелый tiered storage. Managed-решения: AWS MSK с S3, Confluent Cloud с встроенным tiered storage, Aiven for Apache Kafka.