0Pricing
AWS Solutions Architect · Leçon

Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative

Utilisez les contrôles d’intégrité ELB, les contrôles des points de terminaison Route 53 et les disjoncteurs au niveau de l’application pour détecter les pannes et réacheminer automatiquement le trafic.

Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative est une leçon AWS Solutions Architect gratuite sur CoddyKit. Ceci est la leçon 4 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage AWS Solutions Architect, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours AWS Solutions Architect comprend 4 leçons au total.

Pourquoi la détection automatisée des pannes est importante

Dans les systèmes distribués, les composants tombent continuellement en panne : des instances s’arrêtent brutalement, des partitions réseau surviennent et les services en aval deviennent surchargés. Sans détection automatisée des pannes, le trafic continue d’être envoyé vers les composants défaillants, ce qui provoque des pannes en cascade. AWS fournit plusieurs niveaux de contrôle d’intégrité : les contrôles d’intégrité ELB détectent les instances défaillantes, les contrôles d’intégrité Route 53 détectent les Endpoints défaillants et Auto Scaling remplace les instances défaillantes. Les modèles au niveau de l’Application, comme les disjoncteurs et les nouvelles tentatives, complètent la résilience globale.

Vérifications d’intégrité ELB

Les vérifications d’intégrité d’Elastic Load Balancer envoient périodiquement des requêtes aux cibles enregistrées afin de déterminer si elles sont opérationnelles. Vous configurez le chemin de vérification d’intégrité (par exemple, /health), le protocole, le port, l’intervalle (30 secondes par défaut) et le seuil d’état sain ou défaillant (nombre de réussites ou d’échecs consécutifs). Lorsqu’une cible échoue aux vérifications d’intégrité, l’ELB cesse de lui acheminer du trafic. La cible est réévaluée en continu et ajoutée de nouveau dès qu’elle atteint le seuil d’état sain.

# 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=200

Vérifications d’intégrité Route 53

Les vérifications d’intégrité Route 53 surveillent des points de terminaison depuis plusieurs emplacements dans le monde et fonctionnent conjointement avec le routage DNS de basculement. Il en existe trois types : les vérifications de point de terminaison interrogent directement l’URL de votre application. Les vérifications calculées combinent plusieurs vérifications d’intégrité enfants à l’aide d’une logique AND/OR (utile pour la surveillance complexe). Les vérifications basées sur des alarmes CloudWatch délèguent la détermination de l’état à CloudWatch — elles sont utiles lorsque vous ne pouvez pas exposer de point de terminaison d’intégrité public ou lorsque vos décisions d’état doivent reposer sur des métriques.

# 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
  }'

Vérifications d’intégrité de la mise à l’échelle automatique

Les groupes Auto Scaling peuvent utiliser deux types de vérifications d’intégrité : les vérifications d’intégrité EC2 détectent les défaillances d’instances au niveau de l’hyperviseur (échec de la vérification d’état de l’instance). Les vérifications d’intégrité ELB tiennent davantage compte de l’application : une instance peut être en cours d’exécution tout en renvoyant des erreurs, ce que les vérifications d’intégrité ELB détectent. Vous pouvez configurer l’ASG pour utiliser les vérifications d’intégrité ELB afin que les défaillances au niveau de l’application déclenchent également le remplacement de l’instance, et pas uniquement les défaillances sous-jacentes d’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 startup

Le modèle du disjoncteur

Un disjoncteur est un modèle au niveau de l’application qui évite les défaillances en cascade en surveillant les appels à un service en aval et en interrompant temporairement ces appels lorsque les défaillances dépassent un seuil. Le circuit possède trois états : Closed (fonctionnement normal), OPEN (le seuil de défaillances est dépassé, les appels sont immédiatement bloqués) et HALF (après un délai d’attente, un petit nombre d’appels de test sont autorisés pour vérifier si le service a récupéré). AWS App Mesh et des SDK d’application tels que Resilience4j implémentent ce modèle.

# 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 -> OPEN

AWS App Mesh et les disjoncteurs

AWS App Mesh est un maillage de services qui implémente les disjoncteurs, les nouvelles tentatives et les stratégies de délai d’attente au niveau de l’infrastructure, sans modifier le code. Vous définissez les stratégies de disjoncteur dans la configuration du nœud virtuel ou du routeur virtuel. Lorsqu’un service en amont devient défaillant, le proxy Envoy d’App Mesh ouvre automatiquement le circuit et renvoie immédiatement des erreurs au lieu d’attendre l’expiration des délais. Cette fonctionnalité est particulièrement utile dans les architectures de microservices exécutées sur ECS ou 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
      }
    }]
  }
}

Logique de nouvelle tentative et temporisation exponentielle

La logique de nouvelle tentative réexécute automatiquement les opérations qui ont échoué, mais une logique naïve (nouvelle tentative immédiate dans une boucle serrée) peut aggraver les situations de surcharge. La temporisation exponentielle augmente exponentiellement le temps d’attente entre les nouvelles tentatives : 1 s, 2 s, 4 s, 8 s… Cela réduit la charge sur un service en difficulté et lui laisse le temps de récupérer. La gigue (intervalle aléatoire entre les nouvelles tentatives) évite le problème du troupeau tonitruant, où tous les clients réessaient simultanément après une brève interruption. Le SDK AWS implémente automatiquement la temporisation exponentielle avec gigue.

# 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)

Idempotence pour des nouvelles tentatives sûres

Les nouvelles tentatives ne sont sûres que si les opérations sont idempotentes : effectuer plusieurs fois la même opération produit le même résultat. Par exemple, créer un objet S3 avec la même clé est idempotent (le résultat est identique). En revanche, passer deux fois une commande crée deux commandes : l’opération n’est pas idempotente. Concevez des API idempotentes à l’aide de clés d’idempotence fournies par le client : le serveur stocke le résultat de la première requête et renvoie le même résultat pour les requêtes suivantes utilisant la même clé. DynamoDB, SQS et API Gateway prennent en charge les modèles de clés d’idempotence.

# 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 minutes

Configuration des délais d’attente

Sans délais d’attente explicites, un service en aval lent bloque indéfiniment les threads, épuise le pool de connexions et provoque des défaillances en cascade. Définissez des délais à chaque niveau : délai d’établissement de la connexion (temps nécessaire pour établir la connexion TCP), délai de lecture (temps nécessaire pour recevoir une réponse) et délai global de la requête. Dans AWS, configurez le délai d’inactivité de l’ELB (60 s par défaut), le délai d’exécution de Lambda (15 min maximum) et le délai d’intégration d’API Gateway (29 s maximum). Les délais d’attente déclenchent votre logique de nouvelle tentative ou de disjoncteur.

# 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 29000ms

Files d’attente de lettres mortes pour les traitements échoués

Lorsque le traitement d’un message échoue à plusieurs reprises, une file d’attente de lettres mortes (DLQ) capture les messages qui n’ont pas pu être traités après le nombre maximal de tentatives de réception. Configurez des DLQ sur les files SQS et les mappages de sources d’événements Lambda afin d’empêcher les messages incorrects de bloquer indéfiniment votre file. Les messages de la DLQ peuvent être inspectés, rejoués après correction du bogue ou archivés. Les DLQ constituent un composant essentiel des architectures résilientes orientées événements.

# 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 DLQ

Observation des défaillances avec CloudWatch

Des vérifications d’intégrité et des disjoncteurs efficaces nécessitent une surveillance permettant de comprendre les tendances des défaillances. CloudWatch est la couche d’observabilité : créez des alarmes sur ELB UnHealthyHostCount (instances qui échouent aux vérifications d’intégrité), le taux d’erreurs Lambda, SQS NumberOfMessagesSentToDLQ (messages envoyés à la DLQ) et RequestCountPerTarget du groupe cible. Configurez des notifications SNS afin que votre équipe d’astreinte soit immédiatement alertée lorsque les vérifications d’intégrité automatisées détectent une dégradation.

# 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-team

Vérification rapide

Vérifiez votre compréhension des concepts AWS Solutions Architect (SAA-C03) présentés dans cette leçon.

Récapitulatif de la leçon

Dans cette leçon, vous avez appris que les vérifications d’intégrité ELB et Route 53 automatisent la détection des défaillances au niveau de l’infrastructure, que les disjoncteurs empêchent les défaillances en cascade en interrompant les appels vers les services défaillants et que la temporisation exponentielle avec gigue rend les nouvelles tentatives sûres en cas de charge élevée. Les files d’attente de lettres mortes capturent les messages défaillants afin qu’ils puissent être inspectés. Nous allons maintenant étudier RTO, RPO et les niveaux de reprise après sinistre.

Questions Fréquemment Posées

La leçon « Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative » est-elle gratuite ?

Oui — le texte complet de « Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours AWS Solutions Architect, passe à CoddyKit PRO. Le cours AWS Solutions Architect comprend 4 leçons au total.

Qu'est-ce que j'apprendrai dans « Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative » ?

Utilisez les contrôles d’intégrité ELB, les contrôles des points de terminaison Route 53 et les disjoncteurs au niveau de l’application pour détecter les pannes et réacheminer automatiquement le traf… Tu pratiques AWS Solutions Architect avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.

Dois-je avoir de l'expérience pour commencer AWS Solutions Architect ?

Aucune expérience préalable n'est requise. AWS Solutions Architect sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 4 sur 4.

Combien de temps prend la leçon « Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative » ?

La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.

Peux-tu écrire et exécuter du code dans cette leçon AWS Solutions Architect ?

Oui. Chaque leçon AWS Solutions Architect inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.

Toutes les leçons de ce cours

  1. HA ou tolérance aux pannes : définitions et compromis
  2. Modèles Multi-AZ pour les services avec état
  3. Actif-actif et actif-passif multi-Régions
  4. Contrôles d’intégrité, disjoncteurs et logique de nouvelle tentative
← Retour à AWS Solutions Architect