0Pricing
AWS Solutions Architect · Урок

Проверки состояния, автоматические выключатели и логика повторных попыток

Используйте проверки состояния ELB, проверки конечных точек Route 53 и автоматические выключатели на уровне приложения для обнаружения сбоев и автоматической перенаправки трафика.

«Проверки состояния, автоматические выключатели и логика повторных попыток» — бесплатный урок AWS Solutions Architect на CoddyKit. Это урок 4 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения AWS Solutions Architect, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс AWS Solutions Architect содержит 4 уроков всего.

Почему важно автоматическое обнаружение сбоев

В распределённых системах компоненты постоянно выходят из строя: экземпляры аварийно завершают работу, происходят сетевые разделения, зависимые службы перегружаются. Без автоматического обнаружения сбоев трафик продолжает поступать к неисправным компонентам, вызывая каскадные сбои. AWS предоставляет несколько уровней проверки работоспособности: проверки работоспособности ELB обнаруживают неисправные экземпляры, проверки работоспособности Route 53 обнаруживают неисправные конечные точки, а Auto Scaling заменяет вышедшие из строя экземпляры. Такие шаблоны на уровне приложения, как автоматические размыкатели и повторные попытки, дополняют общую картину устойчивости.

Проверки работоспособности ELB

Проверки работоспособности Elastic Load Balancer периодически отправляют запросы зарегистрированным целевым объектам, чтобы определить, работают ли они нормально. Вы настраиваете путь проверки работоспособности (например, /health), протокол, порт, интервал (по умолчанию 30 секунд) и порог работоспособности/неработоспособности (количество последовательных успешных попыток или сбоев). Когда целевой объект не проходит проверки работоспособности, ELB прекращает направлять на него трафик. Целевой объект постоянно проверяется повторно и добавляется обратно после достижения порога работоспособности.

# 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

Проверки работоспособности Route 53

Проверки работоспособности Route 53 отслеживают конечные точки из нескольких глобальных местоположений и работают вместе с маршрутизацией DNS при отказе. Существует три типа: проверки конечной точки напрямую опрашивают URL вашего приложения. Вычисляемые проверки объединяют несколько дочерних проверок работоспособности с логикой AND/OR (это удобно для сложного мониторинга). Проверки оповещений CloudWatch передают определение состояния CloudWatch — это полезно, когда невозможно открыть общедоступную конечную точку работоспособности или требуется принимать решения о состоянии на основе метрик.

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

Проверки работоспособности Auto Scaling

Группы Auto Scaling могут использовать два типа проверок работоспособности: проверки работоспособности EC2 обнаруживают сбои экземпляров на уровне гипервизора (сбой проверки состояния экземпляра). Проверки работоспособности ELB лучше учитывают состояние приложения: экземпляр может работать, но возвращать ошибки, и проверки работоспособности ELB обнаружат это. Вы можете настроить ASG на использование проверок работоспособности ELB, чтобы сбои на уровне приложения также запускали замену экземпляра, а не только сбои базовой инфраструктуры 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

Шаблон автоматического размыкателя

Автоматический размыкатель — это шаблон на уровне приложения, который предотвращает каскадные сбои: он отслеживает вызовы нижестоящего сервиса и временно прекращает их, когда число сбоев превышает порог. У размыкателя есть три состояния: Closed (обычная работа), Open (порог сбоев превышен, вызовы немедленно блокируются) и Half-Open (после тайм-аута разрешается небольшое количество тестовых вызовов, чтобы проверить, восстановился ли сервис). AWS App Mesh и SDK приложений, такие как Resilience4j, реализуют этот шаблон.

# 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 для автоматического размыкания

AWS App Mesh — это сервисная сетка, которая реализует автоматическое размыкание, повторы и политики тайм-аутов на уровне инфраструктуры без изменения кода. Вы определяете политики автоматического размыкания в конфигурации виртуального узла или виртуального маршрутизатора. Когда вышестоящий сервис становится недоступным, прокси-сервер Envoy в App Mesh автоматически размыкает цепь и сразу возвращает ошибки, вместо того чтобы ждать истечения тайм-аутов. Это особенно полезно в архитектурах микросервисов, работающих на ECS или 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
      }
    }]
  }
}

Логика повторов и экспоненциальная задержка

Логика повторов автоматически повторяет неудачные операции, но наивная логика повторов (немедленные повторы в тесном цикле) может усилить перегрузку. Экспоненциальная задержка увеличивает время ожидания между повторами по экспоненте: 1 с, 2 с, 4 с, 8 с… Это снижает нагрузку на испытывающий проблемы сервис и даёт ему время на восстановление. Случайная задержка (рандомизация интервалов между повторами) предотвращает проблему стадного эффекта, когда все клиенты одновременно повторяют запросы после кратковременного сбоя. SDK AWS автоматически реализует экспоненциальную задержку со случайным смещением.

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

Идемпотентность для безопасных повторов

Повторы безопасны только в том случае, если операции идемпотентны — многократное выполнение одной и той же операции даёт один и тот же результат. Например, создание объекта S3 с одним и тем же ключом идемпотентно (результат одинаков). Но повторное размещение заказа создаёт два заказа — это неидемпотентная операция. Проектируйте API идемпотентными с помощью ключей идемпотентности, заданных клиентом: сервер сохраняет результат первого запроса и возвращает тот же результат для последующих запросов с таким же ключом. DynamoDB, SQS и API Gateway поддерживают шаблоны ключей идемпотентности.

# 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

Настройка тайм-аутов

Без явных тайм-аутов медленный нижестоящий сервис заставляет потоки блокироваться на неопределённый срок, исчерпывая пул соединений и вызывая каскадные сбои. Устанавливайте тайм-ауты на каждом уровне: тайм-аут подключения (время установления TCP-соединения), тайм-аут чтения (время ожидания ответа) и общий тайм-аут запроса. В AWS настройте тайм-аут простоя ELB (по умолчанию 60 с), тайм-аут выполнения Lambda (максимум 15 мин) и тайм-аут интеграции API Gateway (максимум 29 с). Тайм-ауты запускают вашу логику повторов или автоматического размыкания.

# 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

Очереди недоставленных сообщений для обработки сбоев

Когда обработка сообщения неоднократно завершается сбоем, очередь недоставленных сообщений (DLQ) сохраняет сообщения, которые не удалось обработать после максимального количества попыток получения. Настройте DLQ для очередей SQS и сопоставлений источников событий Lambda, чтобы некорректные сообщения не блокировали очередь на неопределённый срок. Сообщения в DLQ можно проверить, повторно обработать после исправления ошибки или архивировать. DLQ — важнейший компонент отказоустойчивых архитектур, управляемых событиями.

# 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

Наблюдение за сбоями с помощью CloudWatch

Для эффективной работы проверок работоспособности и автоматических размыкателей необходим мониторинг, позволяющий понять характер сбоев. CloudWatch — это уровень наблюдаемости: создавайте оповещения для ELB UnHealthyHostCount (экземпляры, не прошедшие проверки работоспособности), частоты ошибок Lambda, SQS NumberOfMessagesSentToDLQ (сообщения, попавшие в DLQ) и Target group RequestCountPerTarget. Настройте уведомления SNS, чтобы дежурная команда немедленно получала оповещения, когда автоматические проверки работоспособности обнаруживают ухудшение состояния.

# 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

Быстрая проверка

Проверьте своё понимание концепций AWS Solutions Architect (SAA-C03) из этого урока.

Итоги урока

В этом уроке вы узнали: проверки работоспособности ELB и Route 53 автоматизируют обнаружение сбоев на уровне инфраструктуры, автоматические размыкатели предотвращают каскадные сбои, прекращая вызовы недоступных сервисов, а экспоненциальная задержка со случайным смещением делает повторы безопасными при высокой нагрузке. Очереди недоставленных сообщений сохраняют неудачные сообщения для проверки. Далее мы рассмотрим RTO, RPO и уровни аварийного восстановления.

Часто задаваемые вопросы

Урок «Проверки состояния, автоматические выключатели и логика повторных попыток» бесплатный?

Да — полный текст урока «Проверки состояния, автоматические выключатели и логика повторных попыток» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс AWS Solutions Architect, подпишись на CoddyKit PRO. Курс AWS Solutions Architect содержит 4 уроков всего.

Чему я научусь в уроке «Проверки состояния, автоматические выключатели и логика повторных попыток»?

Используйте проверки состояния ELB, проверки конечных точек Route 53 и автоматические выключатели на уровне приложения для обнаружения сбоев и автоматической перенаправки трафика. Ты практикуешь AWS Solutions Architect с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.

Нужен ли мне опыт, чтобы начать AWS Solutions Architect?

Предыдущий опыт не требуется. AWS Solutions Architect на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 4 из 4.

Сколько времени занимает урок «Проверки состояния, автоматические выключатели и логика повторных попыток»?

Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.

Можно ли писать и запускать код в этом уроке AWS Solutions Architect?

Да. Каждый урок AWS Solutions Architect включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.

Все уроки этого курса

  1. HA и отказоустойчивость: определения и компромиссы
  2. Шаблоны Multi-AZ для сервисов с состоянием
  3. Активный и пассивный режимы в нескольких регионах
  4. Проверки состояния, автоматические выключатели и логика повторных попыток
← Назад к AWS Solutions Architect