Comprobaciones de estado, disyuntores y lógica de reintento
Utilice comprobaciones de estado de ELB, comprobaciones de endpoints de Route 53 y disyuntores a nivel de aplicación para detectar fallos y redirigir el tráfico automáticamente
Comprobaciones de estado, disyuntores y lógica de reintento es una lección gratuita de Cloud & IT Cert Prep en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Cloud & IT Cert Prep, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cloud & IT Cert Prep incluye 4 lecciones en total.
Por qué es importante la detección automatizada de fallos
En los sistemas distribuidos, los componentes fallan continuamente: las instancias se bloquean, se producen particiones de red y los servicios posteriores se sobrecargan. Sin una detección automatizada de fallos, el tráfico continúa dirigiéndose a componentes defectuosos, lo que provoca fallos en cascada. AWS proporciona varias capas de comprobaciones de estado: las comprobaciones de estado de ELB detectan instancias en mal estado, las comprobaciones de estado de Route 53 detectan endpoints en mal estado y Auto Scaling reemplaza las instancias fallidas. Los patrones a nivel de aplicación, como los circuit breakers y los reintentos, completan el modelo de resiliencia.
Comprobaciones de estado de ELB
Las comprobaciones de estado de Elastic Load Balancer envían periódicamente solicitudes a los destinos registrados para determinar si están saludables. Usted configura la ruta de comprobación de estado (por ejemplo, /health), el protocolo, el puerto, el intervalo (30 segundos de forma predeterminada) y el umbral de estado saludable/no saludable (el número de éxitos o fallos consecutivos). Cuando un destino no supera las comprobaciones de estado, ELB deja de dirigirle tráfico. El destino se vuelve a evaluar continuamente y se incorpora de nuevo cuando supera el umbral de estado saludable.
# Configure ALB target group health check
aws elbv2 modify-target-group \
--target-group-arn arn:aws:elasticloadbalancing::123:targetgroup/my-tg/abc \
--health-check-protocol HTTPS \
--health-check-port 443 \
--health-check-path /health \
--health-check-interval-seconds 15 \
--healthy-threshold-count 2 \
--unhealthy-threshold-count 3 \
--matcher HttpCode=200Comprobaciones de estado de Route 53
Las comprobaciones de estado de Route 53 supervisan los endpoints desde varias ubicaciones de todo el mundo y funcionan junto con el enrutamiento DNS de conmutación por error. Existen tres tipos: las comprobaciones de endpoint consultan directamente la URL de su aplicación. Las comprobaciones calculadas combinan varias comprobaciones de estado secundarias mediante lógica AND/OR (útil para una supervisión compleja). Las comprobaciones de alarmas de CloudWatch delegan la determinación del estado en CloudWatch; son útiles cuando no puede exponer un endpoint de estado público o necesita tomar decisiones de estado basadas en métricas.
# Create endpoint health check
aws route53 create-health-check \
--caller-reference ref-$(date +%s) \
--health-check-config '{
"Type": "HTTPS",
"FullyQualifiedDomainName": "api.example.com",
"Port": 443,
"ResourcePath": "/health",
"RequestInterval": 10,
"FailureThreshold": 2,
"EnableSNI": true
}'Comprobaciones de estado de Auto Scaling
Los Auto Scaling Groups pueden utilizar dos tipos de comprobaciones de estado: las comprobaciones de estado de EC2 detectan fallos de las instancias en el nivel del hipervisor (fallo de la comprobación de estado de la instancia). Las comprobaciones de estado de ELB tienen más conocimiento del estado de la aplicación: una instancia puede estar en ejecución, pero devolver errores, y las comprobaciones de estado de ELB detectan esta situación. Puede configurar ASG para que utilice las comprobaciones de estado de ELB, de modo que los fallos en el nivel de la aplicación también activen el reemplazo de la instancia, no solo los fallos subyacentes de EC2.
# Configure ASG to use ELB health checks
aws autoscaling update-auto-scaling-group \
--auto-scaling-group-name my-asg \
--health-check-type ELB \
--health-check-grace-period 300
# Grace period: time after launch before health checks start
# Prevents premature termination during startupEl patrón de disyuntor
Un disyuntor es un patrón en el nivel de la aplicación que evita los fallos en cascada mediante la supervisión de las llamadas a un servicio descendente y la interrupción temporal de esas llamadas cuando los fallos superan un umbral. El disyuntor tiene tres estados: Closed (funcionamiento normal), Open (se ha superado el umbral de fallos y las llamadas se bloquean inmediatamente) y Half-Open (después de un tiempo de espera, se permite un pequeño número de llamadas de prueba para comprobar si el servicio se ha recuperado). AWS App Mesh y SDK de aplicaciones como Resilience4j implementan este patrón.
# Circuit breaker states
# CLOSED: All calls pass through
# failureCount < threshold -> stay CLOSED
# failureCount >= threshold -> open circuit
# OPEN: All calls fail immediately
# After timeout -> enter HALF-OPEN
# HALF-OPEN: Allow limited test calls
# Success -> return to CLOSED
# Failure -> return to OPEN
# Example threshold: 5 failures in 10 seconds -> OPENAWS App Mesh para la interrupción de circuitos
AWS App Mesh es una malla de servicios que implementa políticas de interrupción de circuitos, reintentos y tiempos de espera en el nivel de la infraestructura, sin cambios en el código. Usted define las políticas de disyuntor en la configuración del nodo virtual o del router virtual. Cuando un servicio ascendente deja de estar saludable, el proxy Envoy de App Mesh abre automáticamente el circuito y devuelve errores de inmediato en lugar de esperar a que se agoten los tiempos de espera. Esto resulta especialmente valioso en arquitecturas de microservicios que se ejecutan en ECS o EKS.
# App Mesh virtual node with circuit breaker
# (JSON configuration)
{
'spec': {
'listeners': [{
'outlierDetection': {
'consecutiveErrors': 5,
'interval': {'unit': 'ms', 'value': 10000},
'baseEjectionDuration': {'unit': 's', 'value': 30},
'maxEjectionPercent': 50
}
}]
}
}Lógica de reintentos y retroceso exponencial
La lógica de reintentos vuelve a intentar automáticamente las operaciones fallidas, pero una lógica de reintentos ingenua (un reintento inmediato en un bucle rápido) puede agravar las situaciones de sobrecarga. El retroceso exponencial aumenta exponencialmente el tiempo de espera entre reintentos: 1s, 2s, 4s, 8s... Esto reduce la carga sobre un servicio con problemas y le da tiempo para recuperarse. La variación aleatoria (la aleatorización de los intervalos de reintento) evita el problema de la estampida, en el que todos los clientes reintentan simultáneamente después de una breve interrupción. El AWS SDK implementa automáticamente el retroceso exponencial con variación aleatoria.
# AWS SDK retries with exponential backoff automatically
# Default retry config for most AWS services:
# Max retries: 3-5 (varies by service)
# Base delay: 100ms
# Max delay: ~20 seconds
# Python boto3 custom retry configuration
import boto3
from botocore.config import Config
config = Config(
retries={'max_attempts': 5, 'mode': 'adaptive'}
)
client = boto3.client('s3', config=config)Idempotencia para realizar reintentos seguros
Los reintentos solo son seguros si las operaciones son idempotentes, es decir, si realizar la misma operación varias veces produce el mismo resultado. Por ejemplo, crear un objeto de S3 con la misma clave es idempotente (produce el mismo resultado). Sin embargo, realizar un pedido dos veces crea dos pedidos, por lo que no es idempotente. Diseñe API idempotentes mediante claves de idempotencia proporcionadas por el cliente: el servidor almacena el resultado de la primera solicitud y devuelve el mismo resultado para las solicitudes posteriores que utilicen la misma clave. DynamoDB, SQS y API Gateway admiten patrones de claves de idempotencia.
# SQS message deduplication ID for FIFO queues
aws sqs send-message \
--queue-url https://sqs.us-east-1.amazonaws.com/123/orders.fifo \
--message-body '{"orderId":"ord-123","items":[...]}' \
--message-group-id 'customer-456' \
--message-deduplication-id 'ord-123-attempt-1'
# SQS deduplicates messages with same ID for 5 minutesConfiguración de tiempos de espera
Sin tiempos de espera explícitos, un servicio descendente lento hace que los subprocesos se bloqueen indefinidamente, agota el grupo de conexiones y provoca fallos en cascada. Configure tiempos de espera en cada capa: tiempo de espera de conexión (tiempo necesario para establecer la conexión TCP), tiempo de espera de lectura (tiempo necesario para recibir una respuesta) y tiempo de espera total de la solicitud. En AWS, configure el tiempo de espera de inactividad de ELB (60 s de forma predeterminada), el tiempo de espera de ejecución de Lambda (máximo de 15 min) y el tiempo de espera de integración de API Gateway (máximo de 29 s). Los tiempos de espera activan la lógica de reintentos o de disyuntor.
# Lambda: set execution timeout
aws lambda update-function-configuration \
--function-name my-function \
--timeout 30
# ALB: configure idle timeout
aws elbv2 modify-load-balancer-attributes \
--load-balancer-arn <ALB-ARN> \
--attributes Key=idle_timeout.timeout_seconds,Value=60
# API Gateway: integration timeout max 29000msColas de mensajes no entregados para el procesamiento fallido
Cuando el procesamiento de mensajes falla repetidamente, una Dead Letter Queue (DLQ) captura los mensajes que no se pudieron procesar después del número máximo de intentos de recepción. Configure DLQ en las colas de SQS y en las asignaciones de fuentes de eventos de Lambda para evitar que los mensajes problemáticos bloqueen la cola indefinidamente. Los mensajes de la DLQ se pueden inspeccionar, volver a procesar después de corregir el error o archivar. Las DLQ son un componente fundamental de las arquitecturas basadas en eventos y resistentes.
# Configure DLQ on SQS queue
aws sqs set-queue-attributes \
--queue-url https://sqs.us-east-1.amazonaws.com/123/main-queue \
--attributes '{
"RedrivePolicy": "{\"deadLetterTargetArn\":\"arn:aws:sqs:us-east-1:123:dlq\",\"maxReceiveCount\":3}"
}'
# After 3 failed processing attempts, message goes to DLQObservación de fallos con CloudWatch
Las comprobaciones de estado y los disyuntores eficaces requieren supervisión para comprender los patrones de fallo. CloudWatch es la capa de observabilidad: cree alarmas para ELB UnHealthyHostCount (instancias que no superan las comprobaciones de estado), la tasa de Lambda Errors, SQS NumberOfMessagesSentToDLQ (mensajes que llegan a la DLQ) y Target group RequestCountPerTarget. Configure notificaciones de SNS para que el equipo de guardia reciba una alerta inmediatamente cuando las comprobaciones de estado automatizadas detecten una degradación.
# CloudWatch alarm for unhealthy hosts
aws cloudwatch put-metric-alarm \
--alarm-name 'ALB-UnhealthyHosts' \
--alarm-description 'Alert when targets fail health checks' \
--metric-name UnHealthyHostCount \
--namespace AWS/ApplicationELB \
--period 60 \
--evaluation-periods 2 \
--threshold 1 \
--comparison-operator GreaterThanOrEqualToThreshold \
--alarm-actions arn:aws:sns:us-east-1:123:ops-teamComprobación rápida
Compruebe su comprensión de los conceptos de AWS Solutions Architect (SAA-C03) de esta lección.
Resumen de la lección
En esta lección ha aprendido que: las comprobaciones de estado de ELB y Route 53 automatizan la detección de fallos en el nivel de la infraestructura, los disyuntores evitan los fallos en cascada al detener las llamadas a servicios que no están saludables y el retroceso exponencial con variación aleatoria hace que los reintentos sean seguros bajo carga. Las Dead Letter Queues capturan los mensajes fallidos para su inspección. A continuación, estudiaremos RTO, RPO y los niveles de recuperación ante desastres.
Preguntas frecuentes
¿La lección «Comprobaciones de estado, disyuntores y lógica de reintento» es gratis?
Sí — el texto completo de «Comprobaciones de estado, disyuntores y lógica de reintento» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Cloud & IT Cert Prep, actualiza a CoddyKit PRO. El curso de Cloud & IT Cert Prep incluye 4 lecciones en total.
¿Qué aprenderé en «Comprobaciones de estado, disyuntores y lógica de reintento»?
Utilice comprobaciones de estado de ELB, comprobaciones de endpoints de Route 53 y disyuntores a nivel de aplicación para detectar fallos y redirigir el tráfico automáticamente Practicas Cloud & IT Cert Prep con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar Cloud & IT Cert Prep?
No se requiere experiencia previa. Cloud & IT Cert Prep en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Comprobaciones de estado, disyuntores y lógica de reintento»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de Cloud & IT Cert Prep?
Sí. Cada lección de Cloud & IT Cert Prep incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Alta disponibilidad frente a tolerancia a fallos: definiciones y compensaciones
- Patrones Multi-AZ para servicios con estado
- Activo-activo y activo-pasivo entre varias regiones
- Comprobaciones de estado, disyuntores y lógica de reintento