Chaos Engineering in AWS: Resilience powered by Gen AI

© AWS Community Day Bolivia 2024. Todos los derechos reservados.
Chaos Engineering en AWS: Inyectando resiliencia, impulsada por Gen AI Gustavo Alejandro Romero Sanchez CDB302 Principal Cloud Solutions Architect Encora

Agenda 01 Introduccion a Chaos Engineering (CE) 02 El Proceso de CE y la resiliencia continua + AWS FIS 03 Introduccion a los agentes de Amazon Bedrock 04 Introduciendo Gen AI con agentes de Amazon Bedrock al proceso de CE

Sobre el expositor Principal Cloud Solutions Architect Encora Gustavo Romero

Erase una vez…

Conoce a Jose Site Reliability Engineer (SRE) en una startup de tecnología en La Paz. Le gusta jugar videojuegos Ávido fan del futbol e hincha de "The Strongest“ Le encanta las salteñas

El desafío – Caídas inesperadas A pesar de estar usando la nube de AWS y las mejores prácticas, cuando el equipo de Jose hace nuevos despliegues, estos causan caídas del sistema… ▪ El problema se detecta tardíamente ▪ Investigación manual toma horas ▪ Clientes a nivel global sufren por downtime Virtual private cloud (VPC) Availability Zone 1 Services Database Load Balancer Cache AWS Cloud DNS Region 1

Jose esta frustrado Jose esta cansado de actuar reactivamente todo el tiempo • Tiene que trabajar en incidentes los fines de semana • La frecuencia de despliegues bajo debido al miedo a las caidas • Cada incidente es unico • Esta pensando como podria resolver el problema… tal vez con IA ?

Introducción a Chaos Engineering

Chaos Engineering se trata de construir una cultura de resiliencia en la presencia de eventos inesperados en un sistema. Principios de Chaos Engineering principlesofchaos.org

Una perspectiva diferente producción Chaos Engineering

Una perspectiva diferente Lo que no podemos controlar Lo que podemos controlar Modelo de responsabilidad compartida para la resiliencia

Una perspectiva diferente observabilidad Chaos engineering mejora la Disponibilidad operativa resiliencia

Experimentos a prueba de fallos Realizar experimentos controlados, asumiendo que la carga o los errores que inyectemos serán tolerados por el sistema y son a prueba de fallos.

Cuanto confías en tu arquitectura? AWS Cloud Virtual private cloud (VPC) Availability Zone 1 Availability Zone 2 Service Auto Scaling group Region 1 DNS Database Load Balancer Cache Service Database Cache Virtual private cloud (VPC) Availability Zone 1 Availability Zone 2 Service Auto Scaling group Region 2 Database Load Balancer Cache Service Database Cache

Porque usar Chaos Engineering? Evento de resilencia/caida Costo operacional recurrente Exposicion a riesgos/residual Gastos generales altos + Costo de la oportunidad “Las buenas intenciones no funcionan, los mecanismos si.” – Jeff Bezos, founder of Amazon Resilencia continua/chaos engineering Inversion unica con mantenimiento Resiliencia Deuda Tecnica Postura de Seguridad Costo-eficiencia Consideraciones Punto de partida

El proceso de Chaos Engineering y Resiliencia Continua

Pre-requisitos para Chaos Engineering Requisito #1 Monitoreo y Observabilidad Requisito #2 Conciencia Organizacional Requisito #3 Eventos/fallas de la vida real Requisito #4 Remediación de los hallazgos

Requisito 1: Monitoreo y observabilidad

Observabilidad Encontrar la aguja en el pajar Requisito 1: Monitoreo y observabilidad

Los 3 pilares de la observabilidad ¿Puedes entender el funcionamiento interno de tu aplicación? ¿Puedes entender cualquier estado del sistema en el que tu aplicación pueda haber caído? ¿Puedes entender lo anterior solo observando tus herramientas? ¿Puedes entender el estado, sin importar cuán inusual sea la situación? Observabilidad Metricas Logs Trazas

Observabilidad de alto nivel Requisito 1: Monitoreo y observabilidad

Monitoreo de Aplicaciones Monitoreo de usuarios Requisito 1: Monitoreo y observabilidad

Requisito 2: Conciencia Organizacional Educación Catálogo de experimentos Aprendizajes Tipo de Experimento Ambiente Auto-servicio Salvaguardas Game Day Automatizacion Equipo central orquestando chaos engineering Sponsor Ejecutivo Ejecución descentralizada Tipo de Experimento Ambiente Auto-servicio Salvaguardas Game Day Automatizacion

Requisito 3: Eventos de la vida real Código & configuración ej., despliegue erróneo, expiracion de credenciales, host apagado Infraestructura ej., falla de datacenter, falla de hardware Datos y estado ej., datos corrompidos, sobrecargas Dependencias ej., integraciones de terceros, servicios de AWS Altamente improbable, pero técnicamente factible ej., Perdida física de una región en AWS, ataque de malware ' imag e: Flaticon.com

© 2022, Amazon Web Services, Inc. or its affiliates. All rights reserved. Los hallazgos a través de experimentos deben priorizarse según el nivel de impacto que puedan causar. Los hallazgos que involucren la resiliencia o la seguridad de una carga de trabajo deben tener prioridad sobre las nuevas funciones, ya que, si no se abordan a tiempo, pueden afectar a los usuarios finales. Encontrar un patrocinador ejecutivo que pueda ayudar a priorizar las prioridades si es necesario. Requisito 4: Remediación de los hallazgos

AWS Fault Injection Service

AWS Fault Injection Service (FIS) AWS Fault Injection Service Experiment template AWS Command Line Interface AWS Management Console AWS Identity and Access Management FIS safeguards FIS engine Compute Start experiment Amazon EventBridge Amazon CloudWatch alarms AWS resources Databases Networking Storage Compute Third party Monitoring Stop experiment

Plantillas de Experimentos Experimentos Acciones Objetivos Componentes

Las Acciones son la inyección de fallas ejecutadas durante un experimento aws:<service-name>:<action-type> Las acciones incluyen: • Tipo de falla • Duración • Recursos objetivo • Parámetros específicos de la falla, por ejemplo el comportamiento del rollback o el umbral de invocaciones a limitar Acciones

Acciones "actions": { "StopInstances": { "actionId": "aws:ec2:stop-instances", "parameters": { "start-instances-at-end": "true" }, "duration": "PT10M", "targets": { "Instances": "AllTaggedInstances" } }, "TerminateInstances": { "actionId": "aws:ec2:terminate-instances", "parameters": {}, "duration": "PT1M", "targets": { "Instances": "RandomInstancesInAZ" }, "startAfter": [ "StopInstances" ] } }

Objetivos Los Objetivos definen uno más recursos de AWS en los cuales se ejecutará una acción Los objetivos incluyen: • Tipo de recurso • IDs de recurso, etiquetas, and filtros • Modo de seleccion (ej., ALL, RANDOM)

"targets": { "AllTaggedInstances": { "resourceType": "aws:ec2:instance", "resourceTags": { "Purpose": "chaos-ready" }, "selectionMode": "ALL" }, "RandomInstancesInAZ": { "resourceType": "aws:ec2:instance", "resourceTags": { "Purpose": "chaos-ready" }, filters: [ { path: 'Placement.AvailabilityZone’, values: [ ‘us.east.1a’ ] }, { path: 'State.Name’, values: [ 'running’ ] } ] "selectionMode": "ALL" } Objetivos

Las Plantillas de Experimentos definen un experimento y son utilizadas en la peticion de start-experiment Las plantillas de experimentos incluyen: • Acciones • Objetivos • Alarmas de parada • Rol IAM • Descripción • Etiquetas Plantillas de Experimentos

Plantilla de Experimento { "tags”: { "Name": "StopAndRestartRandomeInstance" }, "description": "Valkyrie Stop and Restart One Random Instance", "roleArn": "arn:aws:iam::0123456789:role/MyFISExperimentRole”, "stopConditions": [ { "source": "aws:cloudwatch:alarm", "value": " "arn:aws:cloudwatch:us-east-1:0123456789:alarm:No_Traffic" } ], "targets": { "myInstance": { "resourceTags": { ”Purpose": "chaos-ready" }, "resourceType": "aws:ec2:instance", "selectionMode": ”RANDOM(1)" } }, "actions": { "StopInstances": { "actionId": "aws:ec2:stop-instances", "description": "stop the instances", "duration": "PT2M", "parameters": { "start-instances-at-end": "true" }, "targets": { "Instances": "myInstance" } } } } Descripción Rol IAM Condiciones de Parada Objetivos Acciones Nombre

Introducción a los Agentes de Amazon Bedrock

Desafíos de la automatización con IA Los LLM son poderosos, pero no pueden tomar acciones. La integración de bases de datos y sistemas es costosa y lenta. Se necesita un conjunto diverso de lenguajes de programación e interfaces. Knowledge workers están al límite de su capacidad, se necesitan herramientas adicionales Construir agentes para producción implica ingeniería compleja. 3 6

5 Agentes de Amazon Bedrock Los agentes de Amazon Bedrock planifican y ejecutan tareas de varios pasos utilizando los sistemas y los orígenes de datos empresariales, usando lenguaje natural • Utiliza el poder de los LLM para generar y responder utilizando lenguaje natural. • Descompone y orquesta tareas. • Completa tareas invocando APIs dinámicamente. • Accede de forma segura y privada a los datos de la empresa. • Muestra el rastro de chain-of-thought y los prompts subyacentes del agente. Características

Beneficios Automatiza la orquestación de tareas de varios pasos Provee acceso Seguro a datos y APIs empresariales Provee infraestructura totalmente administrada Simplifica la construcción y despliegue de asistentes de IA Se puede elegir el lenguaje de implementación 3 8

Fundamentos de los Agentes Instrucciones: “eres un agente que …” Agente Amazon Bedrock Haz esto para mi… Knowledge Bases Acciones 3 9 © 2023, Amazon Web Services, Inc. or its affiliates. All rights reserved. Hecho. Aqui esta el resultado

Introduciendo Gen AI con agentes de Amazon Bedrock al proceso de Chaos Engineering

El agente mas simple solo tiene algunas instrucciones Instrucciones: “eres un agente que solo puede guiar a los usuarios con chaos engineering. te negaras a hacer otra cosa. Proveeras respuestas simples.” Chaos Engineering bot Como puedo comenzar a usar chaos engineering? Ayudame a escribir un email Lo siento, pero no puedo ayudarte a escribir un email. Mi función es guiar a los usuarios en ejercicios de chaos engineering 4 1 Para comenzar te recomiendo familiarizarte con los conceptos y principios de chaos engineering…

Los agentes usan acciones para completar su objetivo Instrucciones: “identificar componentes en una arquitectura cloud y generar una matriz de Rumsfeld de acuerdo a la criticidad de resiliencia de cada componente” Bot Identificador de Arquitectura Listar Componentes In: arquitectura Out: componentes de arquitectura Acciones de Arquitectura Acciones de Matriz Generar Matriz In: componentes de arquitectura Out: Matriz de Rumsfeld 4 2 Identifica los componentes clave de mi arquitectura Esta arquitectura cuenta con un ELB, instancias EC2… Genera Matriz de Rumsfeld <Matriz de Rumsfeld>

Los agentes usan Knowledge Bases para encontrar información especializada Instrucciones: “eres un experto en el well-architected framework, y guias con tu conocimiento” Asistente Well-Architected Que herramientas puedo usar para chaos engineering en AWS ? AWS Fault Injection Service (AWS FIS) es un servicio para hacer experimentos de inyección de errores 4 3 Well Architected Knowledge Base Pilar de Fiabilidad Contiene guía y mejores prácticas para resiliencia y chaos engineering.

Los agentes pueden combinar Accionesy KnowledgeBases 4 4 Asistente de Chaos Engineering Instrucciones: “identificar componentes en una arquitectura cloud e inyectar errores en los componentes identificados Inyeccion de errores In: componente de arquitectura Out: Ejecucion de Test de FIS Well Architected Knowledge Base Acciones de FIS Identifica los componentes clave de mi arquitectura Esta arquitectura cuenta con un ELB, instancias EC2… Inyectar errores en EC2 <Generar JSON y ejecutar experimento en AWS FIS> Pilar de Fiabilidad Contiene guía y mejores prácticas para resiliencia y chaos engineering.

Orquestacion de Agentes – Chaos Engineering Respuesta final: El experimento de Chaos Engineering se llevó a cabo con éxito en la carga de trabajo, apuntando a puntos débiles específicos identificados a través del Well Architected Framework. Pensamiento: Para realizar la tarea, deberia: 1. Identificar la carga de trabajo a probar y sus componentes críticos. 2. Analizar la carga de trabajo utilizando el AWS Well Architected Framework para encontrar posibles puntos de falla. 3. Diseñar un experimento utilizando AWS Fault Injection Simulator (FIS) para simular los escenarios de falla identificados. 4. Orquestar la ejecución del experimento con AWS Step Functions, y evaluando el impacto. Tarea: Realizar un experimento de Chaos Engineering en la siguiente carga de trabajo … … Acción: Observación: Pensamiento: 4 5 IdentificarCargaDeTrabajo IdentificarPuntosDebiles <arquitectura, componentes objetivo> <consultar Well-Architected Framework KB> PlanificarExperimentoConFIS EjecutarExperimento <crear plantilla de experimento con FIS> ejecutar el experimento via AWS FIS <detalles de la carga de trabajo> Necesito identificar los componentes de la arquitectura. <resultados del experimento, modos de falla> Finaliza el ejercicio 1 2 3 4 <lista de puntos débiles identificados + ARNs> Sigo la guía de FIS para generar el JSON adecuado

Definición del experimento Plataforma de Pagos Acción Staging Ambiente 30 minutos Carga Duración 300 TPS Cluster de Pagos Amazon EKS Objetivos Time out Condicion Limite Alarma cuando nodos < 60% Condicion de alto Restaurar nodos CloudWatch + X-ray Hipótesis Observability / Logging A una carga de 300 TPS, si 40% son terminados, el sistema debe seguir activo Etiqueta/ID/Filtro Rollback chaos-ready Contribución Brownout – Terminar 40% de los nodos Carga de trabajo Resiliencia

Demo

Resultado – Resiliencia y Confianza Disponibilidad incrementada Respuesta ante incidentes mejorada Detección eficiente Reducción de caídas

Recomendaciones

Genera 5 tips sobre los agentes… Dame 5 tips sobre los Agentes de Bedrock 1. Gatea, camina, corre 2. Es mejor tener muchos pequeños agentes vs unos cuantos grandes 3. Usa LLMs para construir agentes! 4. Testear a fondo 5. Construye tu propio copiloto!

¡Gracias! Complete la encuesta de la sesión en el código QR Organización AWS Community Day Bolivia 2024

Chaos Engineering in AWS: Resilience powered b...

Chaos Engineering in AWS: Resilience powered by Gen AI

More Decks by Gustavo Alejandro Romero Sanchez

Other Decks in Technology

Featured

Transcript