![[ES] Defensa Contra las Artes Oscuras de los data pipelines #3: aprendiendo sobre resiliencia en almacenamiento](https://prod-assets.cosmic.aws.dev/a/3H5tRrNevkNLVFsCNi5MUOhKrDr/S3-F.webp)
[ES] Defensa Contra las Artes Oscuras de los data pipelines #3: aprendiendo sobre resiliencia en almacenamiento
Revisando sobre la resiliencia en almacenamiento de un data pipeline, cual servicio de AWS se utilizan para implementarlo el almacenamiento, como lograr ser más resiliente sobre estos servicios AWS y que caracteristicas de resiliencia obtenemos frente al negocio.
Series: Defensa Contra las Artes Oscuras de los data pipelines - resiliencia (3 articles)
- 3[ES] Defensa Contra las Artes Oscuras de los data pipelines #3: aprendiendo sobre resiliencia en almacenamiento This article
Nota relevantes
- 8-Ago-2026: Ajuste del contenido del artículo para mayor precisión del contenido.
Ya en la segunda lección , revisamos lo que significa resiliencia y como construirlo dentro de un data pipeline. Los detalles en los servicios como AWS SQS o AWS S3 ayudan realmente poner la teoria en la realidad y ver como la resiliencia es construida y gestionada dentro del data pipeline.
En esta lección empezare sobre el almacenamiento asociado al data pipeline, y esto lleva a interesantes preguntas:
🤔 ¿Qué aplicaciones de almacenamientos estan asociados?, ¿Qué servicios de AWS puedes tomar?, ¿Qué funcionalidades de los servicios AWS estan asociadas para la resiliencia? y ¿Qué procesos y caracteristicas pueden construirse con estas funcionales de los servicios AWS?
Como ingeniero y/o arquitecto de datos, tener la respuesta a estas preguntas hace que gestionar un data pipeline sea más facíl además de como mejorar su proceso también lo sea.
🚨Nota: Ten en cuenta que esto es un punto referencial para guiarte como puedes realizarlo en tu caso de uso especifico; además que las funcionalidades de los servicios AWS deben validarse siempre para ver si se mantienen vigentes o evolucionaron.
Tipos de almacenamientos y servicios AWS en un data pipeline
Un data pipeline tiene un grupo de aplicaciones de almacenamientos asociados a el con el proposito de hacer más facil la gestion de la carga de trabajo. Las aplicaciones de almacenamiento más recurrentes son las siguientes:
- Ingestion layer: Tiene los datos que se mueven desde la fuente hasta el data pipeline.
- Landing layer: Tiene una copia de los datos ingestados para procesamiento, respaldo o auditoria.
- Staging layer: Tiene los datos generados por los procesos de transformación.
La forma en como estas aplicaciones de almacenamiento interactuan con el data pipeline se muestran en el siguiente diagrama.
Si quisieramos compararlos ambos con detalles relevantes, se puede resumir en el siguiente cuadro:
| Criterios | Staging layer | Landing layer | Ingestion layer |
|---|---|---|---|
| ¿Pueden tener datos transformados? | Puede contener transformaciones como no transformados. | No tiene datos transformados. | No tiene datos transformados. |
| ¿Puede realizar operaciones de transformaciones? | Si es factible pero depende del caso. | No. | No. |
| ¿Tipo de persistencia de datos que se usa? | Temporales o permanente según el caso del dato para el data pipeline. | Más permanente según el caso. | Temporal generalmente. |
| ¿Usa una politica de persistencia y actualización en los datos? | Si. | Si. | Si. |
| ¿Cual formato de datos se usa? | Puede cambiar según lo requiere el data pipeline. | Es original según fuente o en un equivalente para consultar. | Es original según fuente o en un equivalente aprobado. |
| ¿Quién define la latencía requerida? | Dependen de la velocidad del data pipeline. | Dependen de la velocidad del data pipeline. | Dependen de la velocidad del data pipeline. |
| ¿Cual es el uso principal? | Preparación, procesamiento y almacenamiento de datos en el data pipeline. | Procesamiento o trazabilidad de datos. | Ingesta de datos para procesar. |
Dado que el ingestión layer y el landing layer son muy similares, hay casos en los que se utiliza landing para realizar las actividades de ingestion layer. Aunque sea valido en alguna forma, generalmente tenerlos separados ayuda mucho a los procesos de recuperación de datos para realizar aplicar una recuperación basado en degradación gradual para el data pipeline.
Adicional a estos tipos de almacenamientos requeridos por un data pipeline; tenemos adaptarlo según el tipo de procesamiento de datos que use el data pipeline: batch o streaming. AWS tiene diferentes servicios que se pueden utilizar para crear cada tipo de almacenamiento; en lo personal esta es la lista basica que se puede utilizar basado en la popularidad.
- AWS S3; hablando especificamente de AWS S3 General Bucket y AWS S3 Table; para casos batch tanto para staging layer, ingestión layer y landing layer, mientras que para los casos streaming puede ser una opción de landing layer. Escoger entre uno u otro servicio depende del caso de uso en realidad.
- AWS Kinesis Data Stream, AWS Data Firehose y/o AWS MSK: para el caso de streaming para ingestion layer como staging layer. Escoger entre uno u otro servicio depende del caso de uso en realidad.
Si bien hay otros servicios de almacenamiento que pueden incluirse; como EBS, DynamoDB o RDS; esto depende de como se construyta la solución sobre data pipeline o el aplicativo de almacenamiento.
Basado en la lista personal, la pregunta que se detalla ahora y se busca resolver es: 🤔 ¿Qué funcionalidades tienen estos servicios para generar resiliencia?.
Detalles de los servicios AWS y resiliencia
Las funcionalidades de un servicio permiten dar detalles requeridos para implementar las prácticas a fin de lograr la resiliencia misma.
AWS S3
Hay que tener en cuenta que los servicios de AWS S3 General Bucket y AWS S3 Table son servicios de una misma familia pero con enfoque diferentes. Desde la perspectiva de una arquitectura de datos, AWS S3 General Bucket esta orientado guardar todo tipo de datos dado que es un sistema de almacenamiento de objetos mientras que AWS S3 Table esta orientado a tablas analiticas basado en Apache Iceberg.
La combinación de AWS S3 General Bucket y AWS S3 Table permiten un gran combinación de rendimiento, escalabilidad y durabilidad de los datos para un data pipeline. Ambos servicios comparten ciertas propiedades comunes:
- La durabilidad de 99.999999999% ya que replica entre varias ZA de la región.
- La disponibilidad de 99.99% de los datos para accederlo.
- La escalabilidad de hasta 100 de exabytes sin problemas de rendimiento.
AWS S3 General Bucket tiene las siguientes funcionalidades:
| Funcionalidades | Descripción breve |
|---|---|
| S3 Replication | Replicación objetos en un bucket diferente de la misma región u otra. |
| S3 Versioning | Versionar un objeto según las operaciones de cambio y eliminación. |
| S3 Object Lock | Bloquear operaciones de cambio y eliminación de objetos en un rango especifico de tiempo. |
| AWS S3 Inventory | Auditar y reportar el estado de tus objetos en el bucket. |
MIentras que S3 Table tiene un mecanismo de replicación de tablas con el fin de generar tabla de lectura en otras regiones o la misma región para la misma cuenta o una diferente.
AWS Kinesis Data Stream, AWS Data Firehose y AWS MSK
Toda esta lista tiene eun común que son servicios de streaming; osea se encargan de ingestar, transportar y entregar datos hacia algun servicio destino; donde todos poseen replicación entre varias ZA de la región generando alta disponibilidad y tolerancia de fallos en la infraestructura.
Generalmente estos servicios se evaluan desde ciertas expectativas comunes del día a día con el fin de poder escoger cual opción más adecuada según se requiera; las expectativas más comunes son las siguientes:
| Funcionalidad | AWS Kinesis Data Stream | AWS MSK | AWS Data Firehose |
|---|---|---|---|
| Periodo de retencion de datos | ✅Entre 1 a 365 dias. | ✅ Infinito en teoria según tiempo o espacio. | ❌ No tiene. |
| Mecanismo de reintento de entrega | ❌ Requiere solucion del lado del consumidor. | ❌ Requiere solucion del lado del consumidor. | ✅ Dependiendo del destino, se usan diferentes mecanismos. |
| Mecanismo de reproducción | ✅ Con Sequence number. | ✅ Con Last committed offset. | ⚠️ Guarda los datos en un S3 General Bucket como backup ante la falla de entrega. |
| Replicación de datos a otra instancia | ❌ Requiere solución intermediaria | ✅ Con AWS MSK Replicator. | ⚠️ No una instancia pero si a un destino que esta en otra región. |
Al conocer estos detalles de estos servicios; 2 preguntas aparecen: 🤔 ¿Qué solución puedo armar con estos servicios? y ¿Qué procesos y características de resiliencia entrego al data pipeline con la solución?
💡Nota importante: si bien no se menciona en esta ocasión; y puede ser un articulo propio; el monitoreo y notificación de las instancias de un servicio AWS y las soluciones debe ser siempre incluido para tomar acciones por parte del equipo humano o las automatizaciones asociadas.
Prácticas, principios y soluciones de resiliencia para el almacenamiento
El objetivo es dar resiliencia al almacenamiento de un data pipeline con el fin de o reanudar las operaciones rapidamente o dar continuidad al procesos sin mucha perdida de tiempo.
Prácticas y principios
El pilar de AWS sobre la fiabilidad da principios y prácticas para hacer una solución más resiliente; y en lo particular y bajo mi experiencia; los principios básicos que actuan como fundamentos para soluciones más resilientes estan en el siguiente recuadro.
| ID | Principio | Practica | Objetivo | Recomendación |
|---|---|---|---|---|
| 1 | Gestión de fallas | Backup de los datos | Tener un respaldo de los datos para reanudar operaciones. | REL09-BP01 , REL09-BP03 |
| 2 | Gestión de fallas | Usar aislamiento de fallos para proteger la carga de trabajo | Limitar el impacto de una falla de un componente a un contexto funcional especifico. | REL10-BP01 , REL10-BP02 |
| 3 | Gestión de fallas | Diseñe para soportar fallo en los componentes | Tener un bajo tiempo de recuperación del componente. | REL11-BP01 , REL11-BP02 , REL11-BP06 |
| 4 | Gestión de fallas | Plan de recuperación ante el desastre | Plan ante recuperación de disrupción del data pipeline. | REL13-BP01 , REL13-BP02 , REL13-BP04 , REL13-BP05 |
| 5 | Arquitectura de carga de trabajo | Diseño de la interacción en sistemas distribuidos para prevenir la falla | Prevenir fallas en componentes. | REL04-BP01**,** REL04-BP02 |
| 6 | Arquitectura de carga de trabajo | Diseño de la interacción en sistemas distribuidos para mitigar o resistir la falla | Mitigar o resistir fallas. | REL05-BP02 , REL05-BP06 |
Con base en todas estas recomendaciones mencionadas, se puede resumir en los siguientes puntos criticos y principales:
- Desacoplacion del procesamiento del almacenamiento.
- Disponibilidad de datos con respaldo en otra ubicacion.
- Gestion de fallos del servicio por temas de hardware.
- Para streaming, control de mensajes que se envian.
Si bien se pueden incluir más principios y prácticas del pilar, es un tema que se tiene que revisar y desarrollar con detalle para lograrlo dentro de la solución que se implementa.
Propuestas de soluciones para resiliencia en almacenamiento
Hay varias soluciones alrededor de estos servicios AWS listados que se pueden clasificar según las estrategias de recuperación ante desastres que tiene AWS. El criterio de asignación de tipos depende principalmente de cuan rapido se replican los datos hacia la otra cuenta AWS o región en la misma cuenta AWS por parte de la solución como también el enfoque de la solución propuesta en la resiliencia del data pipeline. El objetivo de la clasificación es dar más una intuición al lector para entender el impacto de la solución en su uso con relación a la resiliencia.
Si bien en las imagenes pueden estar en otras cuentas AWS, pueden aplicarse a otra región dentro de la misma cuenta AWS. Se realizo a si las imagenes para marcar el alcance de la solución desde la perspectiva de cross-cuentas.
Solución #1: AWS S3 Replication + S3 Multi-Region Access Point
Una solución para un enfoque de procesamiento batch en el data pipeline, y que soporta bien con las actividades de un landing layer y staging layer. Se alinea con la estrategia de recuperación de desastres "Backup & Restore" y "Pilot Light" dado que se genera un backup de los datos que se depositan haciendo adecuado para datos procesados temporales como también para reprocesamiento o respaldo de forma continua en un rango de tiempo pensados en minutos como garantias para la mayoria de objetos.
Se proporciona varias funcionalidades alrededor de esta solución para gestionar rapidamente ciertas actividades:
- Un enfoque de desarrollo 100% orientado al serverless: logrando evitar el gestión de infraestructura en su mayoria de actividades.
- Diferentes tipo de replicación, que pueden ser bajo demanda con S3 Batch Replication o en vivo con live replication.
- Poder sincronizar los buckets con S3 two-way replication para gestionar un proceso de transicion de regreso a la región original.
- Generalmente el comportamiento de replicación dura entre segundo a minutos, aunque si se requiere dar un marco de tiempo para replicar datos, con S3 Replication Time control que es un rango de 15min en un 99.9% de los objetos.
- Para agilizar el acceso a los buckets en la solución, se puede utilizar S3 Multiple Region Access Point para abstraer estos detalles ante el data pipeline.
Compañado con un enfoque Backup de los resultados previos que se consumen, esta solución permite generar una actualización de los datos previos para ser consumidos rapidamente.
Solución #2: AWS Kinesis Data Stream + Consumidor Externo Regional
Una solución para un enfoque de procesamiento streaming en el data pipeline, y que soporta bien con las actividades de un ingestion layer. Se alinea con la estrategia de recuperación de desastres "Pilot Light", "Warm Standby", "Hot standby active/passive" dado por la baja latencia en la replicación de los datos entre los kinesis data stream.
El "Hot standby active/passive" depende de obtener datos para la región de recuperación de datos; por lo que hay una probabilidad de perder datos basado en como funciona el consumidor, aunque la estrategia permita un RPO "casi cero". La razón por la que no se clasifica como "Multisite active/active" es porque no recibe trafico de los mensajes o datos directamente por el usuario, sino que actua como respaldo de la región principal al replicar los datos.
Hay varios puntos interesantes que hay que tener presentes para esta solución.
- Un enfoque de desarrollo 100% orientado al serverless: logrando evitar el gestión de infraestructura en su mayoria de actividades.
- Te enfocas más en el modelo operativo principalmente para garantizar tener los datos en ambos entornos.
- El costo de la replicación de datos esta separado y es facíl de trazar en la mayoria de los componentes involucrados.
- No se introduce complejidad en el data pipeline original, por lo que el proceso es autogestionable la solución en el espacio de la replicación.
- Se puede utilizar un enfoque basado en consumidores personalizados como también KLC para implementar el proceso de consumidor.
- En caso de caida del pipeline original, se puede utilizar el AWS Kinesis Data Stream Backup para continuar con el proceso de forma independiente por medio de una redirección manual.
- Para poder reutilizar la región principal, se requiere un proceso manual para salvar los datos que no pasaron a la región de recuperación y preparar el stream para reanudar con un proceso de eliminación y creación del stream mismo.
Solución #3: AWS MSK + AWS MSK Replicator
Una solución para un enfoque de procesamiento streaming en el data pipeline, y que soporta bien con las actividades de un ingestion layer. Se alinea con la estrategia de recuperación de desastres "Pilot Light", "Warm Standby", "Hot standby active/passive" y "Multisite active/active" dado por la baja latencia en la replicación de los datos al basarse en el ecosistema de Apache Kafka.
Se le otorga la clasificación como "Multisite active/active" porque es más "fácil" gestionar la sincronización entre ambos clusters que estan en diferentes regiones para una misma cuenta por el mecanismo MSK Replicator. Esto no evita el problema de tener muchos procesos de sincronización según el numero de clusters crezca.
Hay algunas funcionalidades y consideraciones importantes para esta solución que uno debe tener en cuenta:
- Se puede implementar usando un enfoque serverless como server dado que MSK Replicator funciona para ambas opciones. Solo revisa que los detalles para que tipo de replicación puedes realizar.
- Se basa en un ecosistema basado en Apache Kafka. Gracias a Apache MirrorMaker 2 es que se puede realizar una replicación entre cuentas AWS para un enfoque serverless como server con EKS/ECS.
- Debes tener conocimientos sobre Apache Kafka y/o Apache MIrrorMaker 2 para operar eficientemente esta solución de replicación de datos. Esto permite capacidad más detallada operativo pero con una curva de aprendizaje más amplio.
- AWS MSK Replicator permite replicación Activo-Activo como también Pasivo-Activo.
Otras soluciónes a revisar
Hay otras soluciones que uno podria plantear y que requieren de apoyo de otros servicios de AWS para ello. Uno es el poder tener "Hot standby active/passive" al gestionar el envio de varios mensajes por medio de AWS EventBridge a diferentes AWS Kinesis Data Streams que estan en diferentes regiones.
Aquí la clave esta en entender como AWS Eventbridge funciona como intermediario, su capacidad para enviar mensajes entre los puntos de destino y que tipos de servicios de almacenamiento pueden ser utilizados para ser puntos de destino.
Otra solución es la replicación de datos en diferentes servicios AWS disponible que pueden ser equivalente. Aunque AWS MSK tiene AWS MSK Connect para integrarse con diferentes tipos de servicio de almacenamiento como S3, DynamoDB o EventBridge con el cluster, hay que revisar si hay disponible una conector disponible para ese servicio de almacenamiento o toca construir uno personalizado para integrarlos.
Por defecto el mecanismo de consumidores puede ser una opción por defecto a implementar para solucionar la situación mientras se mantiene control sobre como es el proceso de replicación. Dependiendo del servicio de almacenamiento y como funcione el conector/consumidor es que se utilice puede clasificar como "Backup & Restore", "Pilot Light" , "Warm Standby" y "Hot standby active/passive".
Procesos y características de resiliencia para el almacenamiento del data pipeline
Con las soluciones anteriores comentadas; que se basan en las prácticas del pilar de fiabilidad de AWS comentadas anteriormente; lo que se busca es dar mecanismos para crear los siguientes procesos:
- Replicación de sistemas de almacenamiento de datos: tener replicas auxiliares de los datos temporales y de entrada que el data pipeline utilizara para generar resultados.
- Planes de recuperación ante el desastre: dado que el almacenamiento es un elemento critico para la recuperación, da fundamentos para definir MTBF y MTTR para garantizar el cumplimiento del RPO y RTO.
- Equivalencia funcional de sistemas: garantizar que el data pipeline aun continue funcionando a pesar de tener componentes diferentes que reemplacen a los originales, aunque se halla afectado algunos requerimientos no-funcional asociados.
Estos procesos se busca soportar siguientes carácteristicas para el data pipeline en la siguiente forma:
- Diseña para lo desconocido: el marco de suposiciones que quiere gestionar se basa en la premisa "El dato no esta accesible desde el servicio porque el servicio no esta disponible en la región o cuenta AWS". Esto lleva que que las diferentes soluciones se aborden de una forma interesante.
- Extensibilidad gradual: la capacidad radica en que el data pipeline pueda "extenderser" hacia un nuevo servicio para obtener los datos requeridos para ello. Esto puede requerir que los scripts que interactuan con los datos deban adaptarse ante cambios, haciendo que patrones de diseño de software como strategy sean clave del proceso.
- El factor humano: al conocer las soluciones que se implementan para automatizar la resiliencia, se puede revisar en que puntos un equipo de la empresa puede intervenir para dar soporte a la arquitectura actual además de generar planes de respaldo manuales para la intervención.
Conclusión
La resiliencia del almacenamiento de un data pipeline radica principalmente en 2 puntos: tener los datos de entrada disponibles como también los resultados temporales procesados o de soporte disponibles también.
Lograr ello puede ser un desafio técnico dependiendo del tipo de data pipeline que se tiene como también el tipo de aplicación de almacenamiento que se busca recrear.
Un tema que puede complicar la situación aun más radica en la consistencia entre ambos puntos y el almacenamiento de datos final, pero eso puede ser un punto a revisar en otra ocasión ya que un tema de consistencia es necesario para ser resiliente y eso puede ser un articulo dedicado exclusivamente. El efecto más debastador radica en el almacenamiento de datos final; como un data mart o data warehouse; que se utiliza para consumo del cliente en sus operaciones:
Faltan datos ➡️ vacios en información en el almacenamiento ➡️ acciones del cliente no confiables
En la siguiente lección veremos como el procesamiento de datos; todo lo que involucra ingesta, transformación y entrega de datos; pueden ser más resiliente.
Documentación referencial
Estos son documentos claves que se utilizarón para crear el artículo, y que pueden utilizarse para entrar más en detalle:
- Resilience in Amazon S3
- Replicating S3 tables
- How Amazon S3 Tables use compaction to improve query performance by up to 3 times
- Resilience in Amazon Managed Streaming for Apache Kafka
- AWS Data Firehose - Pause and resume data delivery
- AWS MSK - AWS MSK Replicator
- AWS Well-Architected Framework: Reliability Pillar
- Disaster Recovery of Workloads on AWS: Recovery in the Cloud
- Amazon S3 Replication adds support for multiple destinations in the same, or different AWS Regions
- Introducing cross-Region event routing with Amazon EventBridge
Series: Defensa Contra las Artes Oscuras de los data pipelines - resiliencia (3 articles)
- 3[ES] Defensa Contra las Artes Oscuras de los data pipelines #3: aprendiendo sobre resiliencia en almacenamiento This article
Enjoyed reading this content? Let the author know!
Your likes, comments, shares, and saves help creators reach more builders.
Loading recommendations
Loading article