Kafka Tiered Storage: ¿cómo diseñas la retención local y remota?

Planteamiento y alcance

Un entrevistador podría preguntar: “Si un topic de Kafka debe retener años de historial, ¿cómo diseñarías las políticas de retención local y remota de Tiered Storage?”

El núcleo no es memorizar el nombre de una configuración. Es explicar el ciclo de vida de los segmentos de log a través de los niveles local y remoto. KIP-405 mantiene un nivel local en los brokers de Kafka mientras sube los segmentos de log completados a un almacenamiento externo; la retención local puede ser más corta que la retención remota para reducir la presión sobre el disco del broker. Una respuesta completa también cubre las fallas del almacenamiento de objetos, la latencia de lectura histórica, la responsabilidad de la eliminación y la recuperación.

Qué está evaluando el entrevistador

Si entiendes el almacenamiento por niveles como una ubicación de segmentos de log fríos/calientes y no como que Kafka se convierta en un almacén de objetos.
Si puedes separar la capacidad del clúster, remote.storage.enable a nivel de topic y las políticas de retención.
Si puedes estimar la capacidad del disco caliente, la capacidad remota, el retraso de subida (upload lag) y el ancho de banda de reproducción (replay bandwidth).
Si consideras las interrupciones remotas, la consistencia de metadatos, el movimiento de particiones y la reproducción de consumidores.
Si asignas una responsabilidad clara para la eliminación remota sin un crecimiento accidental o ilimitado.

Preguntas aclaratorias

¿Qué topics necesitan almacenamiento histórico y debería habilitarse en todos los topics?
¿Cuáles son los objetivos de latencia de lectura caliente y de rendimiento de reproducción histórica?
¿Cuáles son los requisitos de presupuesto de disco local, clase de almacenamiento remoto, regionales y de cumplimiento normativo?
Durante una interrupción del almacenamiento de objetos, ¿cómo se degradan la producción, los consumidores en tiempo real y los lectores históricos?
¿La eliminación está impulsada por tiempo, tamaño, un evento de cumplimiento normativo o una política de inquilinos (tenant policy)?

Una respuesta de 30 segundos

Puedes decir:

Trataría el nivel local de Kafka como una caché caliente de baja latencia, subiría los segmentos completados a un nivel remoto y definiría la retención local y remota por separado. Habilita remote.storage.enable únicamente para los topics que lo necesiten; utiliza la retención local para controlar los discos de los brokers y la retención remota para cumplir con los requisitos de auditoría y reproducción. Cuantificaría el retraso de subida, la latencia de lectura remota, las fallas del almacenamiento de objetos y el movimiento de particiones, asignando luego un responsable para la limpieza remota. Los consumidores en tiempo real se mantienen en rutas locales; la reproducción histórica acepta latencia adicional con limitación (throttling) y monitoreo.

Razonamiento paso a paso

Establecer el ciclo de vida de dos niveles

Kafka todavía utiliza los segmentos de log de partición como la unidad básica. Los segmentos activos se escriben localmente; después del rolling, el componente de log remoto sube los segmentos y la información de índices al almacenamiento remoto configurado. Un cliente no debe asumir que cada byte histórico permanece en los discos de los brokers:

text

producer -> leader broker local segment
                    | segment roll
                    v
             remote object store
consumer <---- local cache or remote fetch

El nivel local atiende el consumo de baja latencia y el nivel remoto soporta una retención más prolongada. Mantén una ventana de seguridad observable entre la finalización de la subida y la eliminación local; la creación del objeto por sí sola no es prueba de que los índices y los metadatos sean utilizables.

Delimitar la funcionalidad por topic

Apache Kafka documenta que, tras la configuración en el broker, un topic todavía opta por participar mediante remote.storage.enable. Especifica si el modelo de gobernanza es opt-in o activado por defecto, ya que habilitar todos los topics puede multiplicar el costo y la superficie de fallas.

Separar la retención local y remota

Establece la retención local por tiempo o tamaño para preservar los datos calientes y la capacidad de lectura necesaria para la reasignación; establece la retención remota para auditoría, reproducción y cumplimiento normativo. El invariante es que la única copia local no se elimina hasta que se verifiquen los objetos remotos, los índices, los metadatos y las pruebas de recuperación. La eliminación remota necesita una auditoría independiente y manejo de reintentos.

Diseñar las lecturas y la degradación

Los consumidores en tiempo real leen primero del nivel local; un offset más allá de la ventana local activa una lectura remota. Cuando el almacenamiento remoto se ralentiza, limita la reproducción histórica para proteger el tráfico en vivo. Cuando no esté disponible, indica qué offsets son temporalmente ilegibles, cómo se disparan las alertas y cómo funciona la recuperación. Prueba el tiempo de reconstrucción de metadatos y caché durante el movimiento de particiones, cambios de líder y reinicios de brokers.

Respuesta modelo de alta calidad

Primero confirmaría la ventana de lectura caliente del topic, el rendimiento de reproducción, el período de retención y los requisitos de cumplimiento normativo. Siguiendo KIP-405, el nivel local del broker es una caché caliente y los segmentos rotados se suben a un almacenamiento de objetos remoto; solo los topics que necesitan historial habilitan remote.storage.enable. La retención local sigue el presupuesto de disco y las necesidades de reproducción en tiempo real, mientras que la retención remota sigue el período de auditoría. La condición para la eliminación son los objetos, índices y metadatos remotos verificados, no simplemente una solicitud de subida. Los consumidores mantienen baja latencia dentro de la ventana local; la reproducción más antigua utiliza lecturas remotas con limitación. Monitorearía el retraso de subida, la latencia de lectura remota, los aciertos de caché, las discrepancias de objetos/metadatos, las fallas de eliminación y los offsets ilegibles, y ejercitaría la recuperación ante interrupciones del almacenamiento de objetos, reinicios de brokers y movimientos de particiones. La limpieza remota necesita un responsable, un registro de auditoría y un procedimiento de restauración; eliminar archivos del broker no hace que esa responsabilidad desaparezca.

Errores comunes

Afirmar que tiered storage envía en streaming cada registro de Kafka directamente al almacenamiento de objetos, ignorando el segment rolling.
Proporcionar solo un interruptor de clúster y omitir remote.storage.enable a nivel de topic.
Calcular el costo del objeto omitiendo la latencia de lectura remota, el retraso de subida y el ancho de banda de reproducción.
Asumir que al eliminar archivos del broker se eliminan automáticamente los objetos remotos.
Permitir que la reproducción histórica consuma recursos necesarios para el tráfico en vivo durante una falla remota.
Omitir el monitoreo y los simulacros de recuperación para la consistencia de objetos, índices y metadatos.

Preguntas de seguimiento y respuestas

1. ¿Cómo eliges el tiempo de retención local?

Trabaja hacia atrás a partir de la ventana de rebobinado en tiempo real más grande, el presupuesto de disco, el tiempo de recuperación por reasignación y el margen de seguridad para períodos de falla. Incluye los picos de reproducción y las ventanas de mantenimiento en lugar de únicamente el retraso promedio del consumidor.

2. ¿Qué ocurre si el almacenamiento de objetos remoto no está disponible brevemente?

Pausa o limita las lecturas más allá de la ventana local, preserva el rango local verificado y genera alertas sobre fallas de subida y lectura. La producción y el consumo en tiempo real continúan dentro de la capacidad local validada; las lecturas históricas se ponen al día tras la recuperación. Expón un estado explícito para los offsets ilegibles en lugar de devolver datos vacíos.

3. ¿Cómo demuestras que la eliminación es segura?

Antes de eliminar un segmento local, verifica que su objeto remoto, índices y metadatos sean legibles y registra el rango del segmento. Para la eliminación remota, audita la política de retención, toma muestras de lecturas y ejecuta simulacros de restauración; genera alertas ante eliminaciones fallidas, objetos huérfanos y brechas en metadatos.