![[ES] Defensa Contra las Artes Oscuras de los data pipelines #2: aprendiendo sobre la resiliencia para un data pipeline](https://prod-assets.cosmic.aws.dev/a/3FRlRZVL0j3vqfoyvmEKIvxSM7t/S3-F.webp)
[ES] Defensa Contra las Artes Oscuras de los data pipelines #2: aprendiendo sobre la resiliencia para un data pipeline
Aprendiendo sobre resiliencia y lo que se requiere conocer en principios, procesos y prácticas para aplicarlas en un data pipeline.
Series: Defensa Contra las Artes Oscuras de los data pipelines - resiliencia (3 articles)
- 2[ES] Defensa Contra las Artes Oscuras de los data pipelines #2: aprendiendo sobre la resiliencia para un data pipeline This article
Ya en la primera lección , se aprendio como cae un data pipeline: actores y sus efectos en ello. Esta realidad lleva a que el equipo de datos busque dar resiliencia a sus data pipelines para que las operaciones de la analitica de datos puedan continuar sin afectar al negocio. Aquí las preguntas son:
🤔 ¿Qué es la resiliencia?, ¿Qué implicacion hay alrededor?, ¿Comó se consigue ello?, ¿Como se asocia a un data pipeline?
Definiendo resiliencia y sus implicaciones
El pilar de la fiabilidad; parte de los pilares de AWS Well-architected framework; indica que la resiliencia es el elemento primordial del pilar mismo. La definición de resiliencia es bastante precisa que tenemos que tener en cuenta:
La resiliencia es la capacidad de una carga de trabajo para recuperarse de interrupciones en la infraestructura o el servicio, adquirir dinámicamente recursos informáticos para satisfacer la demanda y mitigar interrupciones, como configuraciones incorrectas o problemas transitorios de red.
Con esta frase, se puede entender varios puntos relevantes de lo que implica realmente la resiliencia a nivel técnico:
- La unidad de gestión es la carga de trabajo. Los procesos de resiliencia se centran alrededor de la carga de trabajo de forma independiente y atomica.
- La recuperación de disrupción desde la infraestructura y/o el servicio, por lo que involucra pensar tanto en servicio y/o infraestructura que necesita la carga de trabajo para aplicar procesos de recuperación. La etapa de diseño de solución y entendimiento de requerimientos son la base para saber como lograr ello.
- Temas de escalamiento de recursos y mitigar interrupciones son capacidades requeridas. Este punto indica capacidades que debe tener para poder lograr la resiliencia, y que desde el diseño deben poder abordarse y automatizarse.
Una solución; un data pipeline en este caso; para ser resiliente tiene que adaptarse y soportar mecanismos de resiliencia cuando se empieza a diseñar, construir y mantener alrededor de sus cargas de trabajo. La resiliencia generalmente es una capacidad que construye y evoluciona con el tiempo. Para empezar a construir una capa inicial de resiliencia y como evoluciona en el tiempo, 3 temas relevantes entran en discusión: una negociacion entre costo eficiencia, agilidad de entrega y capacidad de la solución además de la gestión de riesgos y situaciones.
Aquí la razón del porque se debe negociar cada uno para definir la resiliencia inicial:
- La "agilidad de entrega y capacidad de la solución" lo que busca es entregar una solución de forma rapida y eficiente hacia el negocio para satisfacer sus requerimientos para empoderarlos en sus actividades.
- La "gestión de riesgos y situaciones" lo que busca en poder controlar situaciones en donde la solución este inhabilitada de funcionar y afecte directamente al negocio, que riesgos hay de que ciertas situaciones pasen, como el tiempo de inactividad afecta al negocio y como poder controlar tales situaciones para reducir o eliminar los efectos.
- La "costo eficiencia" es el impacto economico de tener tanto una solución entregada al negocio, el impacto de tener soluciones adicionales para gestionar una situacion que afecta a la solución y la perdida de dinero por no entregar una solución al negocio en un rango de tiempo como también inoperativa en rangos de tiempo.
El tema de la madurez y limites de capacidad de un data pipeline como solución se reflejan en todo lo comentado anteriormente; y esta crece alrededor del siguiente hecho:
Entrega una solución al negocio para operar porque hay un equipo detras de ellas que gestionará los incidentes alrededor de la solución.
En lo personal, pienso que la fiabilidad se adquiere al tener resiliencia automatica como tambien resiliencia manual para una solucion; por lo que se espera que un data pipeline tenga mucha resiliencia automatica como primera recurso, para despues hacer que el equipo detras de la solución aplique la resiliencia manual como ultimo recurso.
Los principios, prácticas, procesos y características son ejes principales que guían como abordar desde un punto técnico al resiliencia y definen el limite de la misma en el data pipeline, que madurez tiene y donde empezar a mejorarla.
Comprendiendo un data pipeline
Ya entendiendo lo que implica la resiliencia, hay que llevarlo a la perspectiva de data pipelines y el mundo de la analitica de datos. Para ello, la siguiente imagen referencial nos ayuda a entender cuales componentes se utilizan y que flujo de actividades hay dentro de una carga de trabajo en un data pipeline, independiente de si es batch o streaming.
Cada area dentro de la imagen tiene una funcionalidad especifica que se resumen en lo siguiente:
| Area | Funcionalidad |
|---|---|
| Ingesta de datos | Captura los datos necesarios del negocio para transformarlos desde una fuente. |
| Transformacion de datos | Aplicacion de logica de negocios para obtener datos relevantes para el negocio en alguna forma. |
| Servicio/consumo de datos | Entrega de los datos utiles en puntos de consumo hacia el usuario y negocio. |
| Almacenamiento de datos | Guardar los datos temporales necesarios dentro del data pipeline. |
Basado en la imagen, podemos ver que hay a nivel de infraestructura temas como bases de datos, sistema de almacenamiento, servidores, redes y credenciales de acceso mientras que cada area requiere diferentes servicios para construir soluciones para la ingesta, transformación y entrega de datos.
Con esto en mente, hay algunas hechos que tenemos alrededor de un data pipeline:
- El almacenamiento para un data pipeline es staging layer y/o landing layer, porque son elementos universales para el flujo de transformación de datos por guardar resultados temporales para uso posterior dentro del flujo. en el data pipeline Los almacenamientos externos no son responsabilidad del data pipeline.
- El flujo de transformación puede tener 1 o más unidades de trabajo; que pueden componerse de la combinación de ingestas, transformación y entrega de los datos. Puedes tener una o más unidades que solo sea ingesta y transformación de datos mientras que tienes otra unidad que sea entrega de datos; como tambien una sola unidad que contengas los 3.
- Las unidades de trabajo siempre construyen el flujo de transformación que usara el data pipeline, ya que se encargara de orquestar las unidades de trabajo para generar los resultados deseados.
- Un data pipeline debe ser idempotente en sus resultados, modular en sus componentes para diseñarlo y configurable tanto en la personalización de un componente como también en sus parametros.
- Todo data pipeline debe generar metadatos operativos, de linaje, tecnicos y de calidad de datos. los logs son una forma de materializarlos.
Con todo lo comentado sobre un data pipeline; vemos que para lograr la resiliencia en un data pipeline se requiere de gestión de datos temporales para una carga de trabajo, replicación de sistemas de almacenamiento de datos, equivalencia funcional de sistemas en caso de sobrecarga, gestión de orquestamiento basado en politicas de reintentos en las cargas de trabajo, elección correcta de servicios y planes de recuperación ante el desastre entre otros más. Esto se debe a la diversidad de posibles incidentes que pueden ocurrir en varios puntos de un data pipeline.
La resiliencia en un data pipeline es el resultados de como un grupo de procesos predefinidos puede abordar una situación inesperada basado en el diseño y las prácticas aplicadas en los componentes junto también con la forma de interacción entre los componentes para perservar la funcionalidad lo mejor posible de forma imperceptible al usuario o equipo interno.
Dado que un data pipeline es un software con un sistema de almacenamiento de soporte estrategico, entonces todas las prácticas y procesos estaran alrededor de este contexto.
Principios, prácticas, caráceristicas y procesos alrededor de la resiliencia en un data pipeline
AWS en su pilar de fiabilidad da principios junto con prácticas en el diseño y construcción de soluciones más resilientes y de alta disponibilidad, Ahí tambien dan consejos sobre como utilizar sus servicios para ciertas situaciones como ejemplos y consejos para abordar el desarrollo. Este contenido es relevante de revisarlo y estudiarlo porque permite aplicarse al diseño, construcción y evolución de un data pipeline en su ciclo de vida.
Aquí hablaremos un breve resumen de cada uno, ya que actua como base principal sobre los servicios e infraestructura que se utilizaran para construir un data pipeline; para demostrar como estos principios se conectan con un data pipeline. Ten presente que las practicas de los principios del pilar tienen que se adaptadas en el contexto del data pipeline para encontrar el valor añadido, si es que se logra ello por lo que es una revisión previamente.
Fundamentos
Son principios base en los que cualquier solución de software; y por tanto el data pipeline; debe cubrir ya que estos es donde se fundamenta la resiliencia misma. Los principios de los fundamentos son los siguientes:
- Conocer y gestionar las limitaciones del servicio.
- Tener un topologia de la red en la solución.
Algunas prácticas asociadas a estos principios y que tiene un gran impacto son los siguientes:
| Práctica | Objetivo | Principio relacionado |
|---|---|---|
| Ser conciente de los limites y quotas de un servicio | Monitorear con metricas clave el servicio cloud como AWS Glue para saber si estamos llegando a su limite base | Conocer y gestionar las limitaciones del servicio |
| Asegura el estrecho entre el limite del servicio y su uso maximo | Poder tener más replicas del servicio en caso de necesitarlo para gestionar cargas de trabajo adicional | Conocer y gestionar las limitaciones del servicio |
| Usa una red altamente disponible para endpoints publicos para el usuario | Garantizar el acceso del resultado del data pipeline ante el usuario para que lo consuma | Tener un topologia de la red en la solución |
| Proporciona redundancia de conextion entre entornos on-premise y la nube | Garantizar que los componentes de un data pipeline pueden conectarse entre ellos sin problema independiente del tipo de entorno | Tener un topologia de la red en la solución |
Arquitectura de carga de trabajo
Son principios enfocados en el diseño de la arquitectura basado en el software e infraestructura con el fin de dar un comportamiento que soporte la resiliencia el procesamiento de la carga de trabajo. Los principios de la arquitectura de carga de trabajo son los siguientes:
- Diseño de la arquitectura de la carga de trabajo.
- Diseño de la interacción en sistemas distribuidos para prevenir la falla.
- Diseño de la interacción en sistemas distribuidos para mitigar o resistir la falla.
Algunas prácticas asociadas a estos principios son los siguientes:
| Práctica | Objetivo | Principio relacionado |
|---|---|---|
| Elige como segmentar la carga de trabajo | Ser más escalable, descoplado y soportable en los componentes para gestionar la carga de trabajo | Diseño de la arquitectura de la carga de trabajo |
| Identifica el tipo de sistema distribuido que necesitas | Saber cual tipo de interacción usara el sistema para saber como tolerar fallos en los componentes en un data pipeline | Diseño de la interacción en sistemas distribuidos para prevenir la falla |
| Hacer operaciones mutables idempotentes | Hacer un componente confiables, escalables y transparentes en el data pipeline | Diseño de la interacción en sistemas distribuidos para prevenir la falla |
| Limitar y controla las llamadas de reintentos | Dar mecanismos controlar como se consume un data pipeline o un componente | Diseño de la interacción en sistemas distribuidos para mitigar o resistir la falla |
Gestión de cambios
Son principios enfocados en como gestionar un cambio dentro del data pipeline y su entorno para lograr la fiabilidad operativa; esto aplica tanto picos bajo demanda hasta despliegue de cambios y parches de seguridad. Los principios son los siguientes:
- Monitorear los recursos de la carga de trabajo.
- Diseñar para adaptarse a los cambios bajo demanda.
- Implementar cambios.
Algunas prácticas asociadas a estos principios y que tiene un gran impacto son los siguientes:
| Práctica | Objetivo | Principio relacionado |
|---|---|---|
| Automatizar respuestas | Al detectar un evento conocido, aplicar una respuesta correctiva de forma autonoma | Monitorear los recursos de la carga de trabajo |
| Analizar logs | Conocer como es el comportamiento del data pipeline | Monitorear los recursos de la carga de trabajo |
| Usar automatización para escalar o dar recursos | Simplifica de forma segura y consistente como generar o cambiar un componente en un data pipeline | Diseñar para adaptarse a los cambios bajo demanda |
| Dar recursos cuando se necesita | Ajustar los componentes según los recursos para evitar la falla de un componente por capacidad en el data pipeline | Diseñar para adaptarse a los cambios bajo demanda |
| Usar runbooks para actividades especifica | Ejecución de cambios segun el plan y el resultado propuesto en un data pipeline o alrededor de el. | Implementar cambios |
| Integrar pruebas funcionales en el despliegue | Valida el componente funciona bien antes de integrarlo al data pipeline | Implementar cambios |
Gestión de fallos
Son principios enfocados en gestionar falla en el data pipeline de tal forma que se controle el impacto ante la carga de trabajo automaticamente y de forma manual despues. Los principios son los siguientes:
- Backup de los datos.
- Usar aislamiento de fallos para proteger la carga de trabajo.
- Pruebe la resiliencia.
- Diseñe para soportar fallo en los componentes.
- Plan de recuperación ante el desastre.
Algunas prácticas asociadas a estos principios y que tiene un gran impacto son los siguientes:
| Práctica | Objetivo | Principio relacionado |
|---|---|---|
| Identificar y backup todos los datos necesarios | Restaurar los datos requeridos estaticos para que el data pipeline reanude el trabaje de forma correcta | Backup de los datos |
| Desplegar en multiples ubicaciones | Lograr mas disponibilidad y tolerancia a fallos para un servicio utilizado en el pipeline | Usar aislamiento de fallos para proteger la carga de trabajo |
| Prueba los requerimientos escalabilidad y rendimiento | Verificar los limites del pipeline e identificar puntos vulnerables | Pruebe la resiliencia |
| Automatizar la recuperación en todos los niveles | Reducir el tiempo de recuperación de un pipeline para garantizar su disponibilidad | Diseñe para soportar fallo en los componentes |
| Recurrir a recursos saludables en caso de fallo | Es mas resiliente al tener un mecanismo de degradación gradual y recuperación rápida en infraestructura del data pipeline | Diseñe para soportar fallo en los componentes |
| Define objetivos de recuperacion para inactividad o perdida de datos | Conocer cuanto debe durar una recuperación para un pipeline basado en las necesidades del negocio | Plan de recuperación ante el desastre |
Estos principios fundamentales permiten construir procesos alrededor del data pipeline para poder realizar actividades con relación a la resiliencia en el data pipeline. Algunos procesos se enfocan en la gestión de datos temporales para una carga de trabajo, replicación de sistemas de almacenamiento de datos, equivalencia funcional de sistemas en caso de sobrecarga, gestión de orquestamiento basado en politicas de reintentos en las cargas de trabajo, elección correcta de servicios y planes de recuperación ante el desastre entre otros.
Un ejemplo de como se construye un proceso es el siguiente: lás practicas "Prueba los requerimientos escalabilidad y rendimiento", "Hacer operaciones mutables idempotentes", "Asegura el estrecho entre el limite del servicio y su uso maximo" y "Dar recursos cuando se necesita" son bases para poder crear una estrategia de orquestamiento para casos de sobrecarga de datos.
Es apartir de estos procesos que podemos construir características estrategicas hacia del data pipeline. Las características estrategicos principales que debe de conocerlos con relación al data pipeline son los siguientes:
- Diseña para lo desconocido : No conocemos todos los casos que lleven a una falla; por lo que tienes que tomar estrategias basados en un marco de suposiciones para gestionar una situación inesperada para minimizar sus efectos.
- Extensibilidad gradual: Indica que el data pipeline deberia extender; o ser "doblado"; su capacidad definidas cuando este llegando a su limite ante un situación, en vez de romperse.
- El factor humano: La automatización puede agregar complejidad a la solución, por lo que tener un proceso de intervención humana siempre es necesario gestionar situaciones complejas.
Al tener procesos relacionados con la gestión de procesos por sobrecarga y gestión de orquestamiento basado en politicas de reintentos, entonces estamos haciendo que el data pipeline esta buscando ser diseñado para lo desconocido. Los procesos pueden ayudarse a definir las características según como un proceso se define y/o se readapte segun los parametros asociados a ellos.
Conclusión
La resiliencia al final trata de recudir la intervención del equipo lo maximo posible por parte de la solución porque busque siempre garantizar el funcionamiento continuo de forma autonoma. El negocio siempre estara de acuerdo en como un data pipeline tenga esta capacidad mientras no le duela en alguna forma, y cuando se vuelva un dolor buscaran mejorar su capacidad para evitarlo.
La evolución de la resiliencia en un data pipeline involucra muchas prácticas y estrategias alrededor del comportamiento de los componentes, la interacción entre ellos por medio del orquestados y como gestionar datos temporales involucrados en la carga de proceso.
Conoce las prácticas y sus principios, arma procesos y genera características para hacer que tu data pipeline sea tan resiliente hasta que el equipo intervenga.
En la siguiente lección hablaremos sobre resiliencia en almacenamiento de datos y como servicios de AWS ayudan en ello.
Documentación referentes
Aquí los documentos que se utilizarón para construir el artículo.
- Built to Fail: Design Patterns for Resilient Data Pipelines (video)
- "Reliability Pillar: Change management" - AWS Well- Architected Framework
- "Reliability Pillar: Workload architecture" - AWS Well- Architected Framework
- "Reliability Pillar: Failure management" - AWS Well- Architected Framework
- "Reliability Pillar: Foundation" - AWS Well- Architected Framework
- "Reliability Pillar: Resiliency, and the components of reliability" - AWS Well- Architected Framework
- Built to Fail: Design Patterns for Resilient Data Pipelines
- Unlocking Data Pipeline Resilience: Strategies for Fault-Tolerant Engineering
Series: Defensa Contra las Artes Oscuras de los data pipelines - resiliencia (3 articles)
- 2[ES] Defensa Contra las Artes Oscuras de los data pipelines #2: aprendiendo sobre la resiliencia para un data pipeline 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