0Pricing
AWS Solutions Architect · Урок

Сценарии устойчивой архитектуры с высокой доступностью

Решайте задачи о переключении баз данных Multi-AZ, автоматическом масштабировании при резком росте трафика и переключении Route 53 по проверке состояния, чтобы закрепить понятия надёжности.

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

Сценарий 1: веб-приложение Multi-AZ

Сценарий: Компания использует двухуровневое веб-приложение (ALB → EC2 → RDS) и хочет устранить единую точку отказа в пределах AWS Region. Решение: Разверните экземпляры EC2 в группе автоматического масштабирования, охватывающей как минимум 2 зоны доступности, за ALB, который по своей природе работает в нескольких AZ. Включите Multi-AZ для RDS для синхронной репликации на резервный экземпляр. Настройте проверки работоспособности на ALB, чтобы автоматически перенаправлять трафик от неисправных экземпляров. При такой архитектуре потеря любой отдельной AZ вызывает автоматическое переключение на резервные ресурсы на каждом уровне.

# Create RDS with Multi-AZ enabled
aws rds create-db-instance \
  --db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --engine mysql \
  --multi-az \
  --master-username admin \
  --master-user-password Pass123! \
  --allocated-storage 100

# Create ASG across 3 AZs
aws autoscaling create-auto-scaling-group \
  --auto-scaling-group-name web-asg \
  --min-size 2 --max-size 10 --desired-capacity 3 \
  --availability-zones us-east-1a us-east-1b us-east-1c \
  --target-group-arns arn:aws:elasticloadbalancing:us-east-1:123:targetgroup/web-tg/abc

Сценарий 2: масштабирование чтения RDS при высокой нагрузке

Сценарий: Экземпляр RDS приложения электронной коммерции достигает предела по CPU в часы пик из-за аналитических запросов с интенсивным чтением от команды бизнес-аналитики. Решение: Создайте реплики чтения RDS и направьте запросы BI к конечной точке реплики. Реплики чтения используют асинхронную репликацию — для аналитики небольшая задержка допустима. Это снимает нагрузку чтения с основного экземпляра RDS, который используется для операций записи и чтения приложением. Для рабочих нагрузок с исключительно интенсивным чтением добавьте перед RDS уровень ElastiCache для часто запрашиваемых данных.

# Create a Read Replica from the primary RDS instance
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-replica \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --availability-zone us-east-1b

# Application code: use replica endpoint for reads
# Primary endpoint: prod-mysql.cluster.us-east-1.rds.amazonaws.com (writes)
# Replica endpoint: prod-mysql-replica.xyz.us-east-1.rds.amazonaws.com (reads)

Сценарий 3: автоматическое масштабирование при скачке нагрузки на CPU

Сценарий: Статeless API работает на EC2 за ALB. В рабочие часы нагрузка на CPU возрастает до 90%, а ночью падает почти до нуля. Компания хочет, чтобы парк экземпляров масштабировался автоматически. Решение: Настройте группу автоматического масштабирования с политикой масштабирования Target Tracking, рассчитанной на среднюю загрузку CPU 60%. ASG будет автоматически добавлять экземпляры, когда загрузка CPU превышает 60%, и удалять их, когда она опускается ниже целевого значения. Добавьте запланированное действие масштабирования, чтобы заранее прогреть минимальную ёмкость до начала рабочего дня и предотвратить задержки при утреннем всплеске трафика.

# Target tracking policy: scale to keep CPU at 60%
aws autoscaling put-scaling-policy \
  --auto-scaling-group-name api-asg \
  --policy-name cpu-tracking \
  --policy-type TargetTrackingScaling \
  --target-tracking-configuration '{
    "PredefinedMetricSpecification": {"PredefinedMetricType": "ASGAverageCPUUtilization"},
    "TargetValue": 60.0,
    "DisableScaleIn": false
  }'

# Scheduled action: pre-warm to 5 instances at 8 AM weekdays
aws autoscaling put-scheduled-update-group-action \
  --auto-scaling-group-name api-asg \
  --scheduled-action-name morning-scale-out \
  --recurrence '0 8 * * MON-FRI' \
  --min-size 5

Сценарий 4: переключение Route 53 на сайт DR

Сценарий: Компания использует основное веб-приложение в us-east-1 и хочет переключаться на статическую страницу обслуживания в S3 в us-west-2, если основное приложение становится недоступным. Решение: Создайте проверку работоспособности Route 53, отслеживающую конечную точку основного ALB. Создайте две записи Route 53 с политикой маршрутизации при переключении: основную запись, указывающую на ALB и связанную с проверкой работоспособности, и вторичную запись, указывающую на статический сайт в S3. Если проверка работоспособности завершается ошибкой, Route 53 автоматически возвращает DNS-ответ вторичной записи.

# Create Route 53 health check for primary ALB
aws route53 create-health-check \
  --caller-reference $(date +%s) \
  --health-check-config '{
    "Type": "HTTPS",
    "FullyQualifiedDomainName": "app.example.com",
    "Port": 443,
    "RequestInterval": 30,
    "FailureThreshold": 3
  }'

# Primary failover record (associated with health check)
# Secondary failover record -> S3 static website endpoint
# Route 53 automatically switches if health check fails

Сценарий 5: развязка компонентов с помощью SQS для повышения устойчивости

Сценарий: Серверная часть обработки заказов записывает данные в базу данных, но во время окон обслуживания база иногда становится недоступной, из-за чего заказы теряются. Решение: Разместите очередь SQS между внешним интерфейсом, принимающим заказы, и серверной частью, обрабатывающей их. Заказы немедленно помещаются в очередь, поэтому клиент сразу получает подтверждение. Фоновые рабочие процессы извлекают заказы из очереди и обрабатывают их, когда база данных становится доступной. Во время обслуживания заказы накапливаются в очереди, а не удаляются, что обеспечивает устойчивость благодаря асинхронной развязке компонентов.

# SQS-based order decoupling pattern
# 1. Frontend: PUT order to SQS (returns 200 immediately to customer)
aws sqs send-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --message-body '{"orderId": "ORD-123", "items": [...]}'

# 2. Backend worker: polls SQS when DB is available
aws sqs receive-message \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --max-number-of-messages 10

# 3. On success: delete message from queue
# 4. On failure: visibility timeout expires -> message reappears for retry
# 5. After max retries: message goes to Dead Letter Queue (DLQ)

Сценарий 6: Pilot Light для DR

Сценарий: Компании требуется решение для аварийного восстановления с RPO в 1 час и RTO в 4 часа при умеренном бюджете. Решение: Реализуйте стратегию DR Pilot Light. Поддерживайте репликацию основной базы данных в DR Region с помощью межрегиональной реплики чтения RDS. Серверы приложения в обычном режиме не работают в DR Region — в готовом состоянии поддерживается только минимальное «ядро» (база данных). В случае аварии повысьте реплику чтения до автономной базы данных и запустите серверы приложения из заранее созданных AMIs с помощью CloudFormation. RTO измеряется часами, а не минутами, поскольку серверы необходимо запустить.

# Pilot Light: replicate database to DR Region
aws rds create-db-instance-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --source-db-instance-identifier prod-mysql \
  --db-instance-class db.t3.large \
  --source-region us-east-1 \
  --destination-region us-west-2

# During disaster: promote replica in us-west-2 to standalone
aws rds promote-read-replica \
  --db-instance-identifier prod-mysql-dr \
  --region us-west-2
# Then launch app servers from AMIs using CloudFormation in us-west-2

Сценарий 7: очередь недоставленных сообщений SQS для ошибочных сообщений

Сценарий: Обработка сообщений в очереди SQS неоднократно завершается ошибкой из-за ошибки в Lambda-потребителе. Сообщения снова появляются в очереди и продолжают блокировать её. Решение: Настройте очередь недоставленных сообщений (DLQ) для основной очереди. После того как обработка сообщения завершится ошибкой заданное число раз (maxReceiveCount), SQS автоматически переместит его в DLQ вместо бесконечной повторной доставки. Это разблокирует основную очередь для исправных сообщений. Настройте оповещение CloudWatch для метрики DLQ ApproximateNumberOfMessagesVisible, чтобы уведомлять команду разработки о накоплении сообщений в DLQ.

# Set redrive policy to move failed messages to DLQ after 3 attempts
aws sqs set-queue-attributes \
  --queue-url https://sqs.us-east-1.amazonaws.com/123/orders \
  --attributes '{
    "RedrivePolicy": "{\"deadLetterTargetArn\": \"arn:aws:sqs:us-east-1:123:orders-dlq\", \"maxReceiveCount\": \"3\"}"
  }'

# CloudWatch alarm on DLQ depth
aws cloudwatch put-metric-alarm \
  --alarm-name orders-dlq-depth \
  --metric-name ApproximateNumberOfMessagesVisible \
  --namespace AWS/SQS \
  --dimensions Name=QueueName,Value=orders-dlq \
  --threshold 1 --comparison-operator GreaterThanOrEqualToThreshold \
  --evaluation-periods 1 --period 60 --statistic Sum

Сценарий 8: глобальная база данных Aurora

Сценарий: Компания работает в US и Европе. Пользователи в Европе сталкиваются с высокой задержкой чтения из базы данных, поскольку RDS находится в us-east-1. Решение: Используйте Amazon Aurora Global Database. Основной кластер находится в us-east-1, а вторичный кластер только для чтения добавляется в eu-west-1. Aurora реплицирует данные во вторичный Region с типичной задержкой менее 1 секунды на уровне хранилища. Европейские пользователи читают данные из вторичного кластера в eu-west-1. При региональной аварии вторичный кластер можно повысить до основного менее чем за 1 минуту — это лучший RTO среди всех вариантов многорегиональных баз данных AWS.

# Add a secondary region to an Aurora Global Database
aws rds create-global-cluster \
  --global-cluster-identifier prod-global \
  --source-db-cluster-identifier arn:aws:rds:us-east-1:123:cluster:prod-aurora

# Add secondary Region cluster
aws rds create-db-cluster \
  --db-cluster-identifier prod-aurora-eu \
  --engine aurora-postgresql \
  --global-cluster-identifier prod-global \
  --region eu-west-1

Сценарий 9: сервис ECS с ALB и автоматическим масштабированием

Сценарий: Контейнеризированному API-сервису, работающему на ECS Fargate, необходимо масштабироваться на основе загрузки CPU и переживать отказы AZ. Решение: Зарегистрируйте сервис ECS в целевой группе Application Load Balancer, чтобы трафик распределялся между работающими задачами. Разместите задачи в нескольких AZ, указав несколько подсетей в конфигурации сервиса. Настройте автоматическое масштабирование сервиса ECS с политикой Target Tracking по загрузке CPU сервиса ECS, чтобы автоматически увеличивать и уменьшать число задач. При отказе AZ ECS перезапустит неисправные задачи в работоспособных AZ.

# Create ECS Fargate service with ALB and multi-AZ placement
aws ecs create-service \
  --cluster prod-cluster \
  --service-name api-service \
  --task-definition api-task:5 \
  --desired-count 3 \
  --launch-type FARGATE \
  --network-configuration '{
    "awsvpcConfiguration": {
      "subnets": ["subnet-1a", "subnet-1b", "subnet-1c"],
      "securityGroups": ["sg-app"],
      "assignPublicIp": "DISABLED"
    }
  }' \
  --load-balancers '[{
    "targetGroupArn": "arn:...:targetgroup/api-tg/abc",
    "containerName": "api",
    "containerPort": 8080
  }]'

Сценарий 10: переключение при проверке работоспособности с помощью Route 53

Сценарий: Компания использует два экземпляра EC2 в разных AZ, обслуживающих один и тот же домен. Она хочет, чтобы Route 53 автоматически прекращал отправку трафика на неисправный экземпляр. Решение: Используйте взвешенную маршрутизацию Route 53 с одинаковыми весами (50/50) и свяжите проверку работоспособности конечной точки с каждой записью. Когда Route 53 обнаруживает неисправную конечную точку, он удаляет соответствующую запись из DNS-ответов и направляет 100% трафика на исправную конечную точку. После восстановления экземпляра и повторного успешного прохождения проверок работоспособности Route 53 автоматически перераспределяет трафик — ручные изменения DNS не требуются.

# Route 53 weighted record with health check association
aws route53 change-resource-record-sets \
  --hosted-zone-id Z1234567890 \
  --change-batch '{
    "Changes": [{
      "Action": "UPSERT",
      "ResourceRecordSet": {
        "Name": "app.example.com",
        "Type": "A",
        "SetIdentifier": "instance-1a",
        "Weight": 50,
        "HealthCheckId": "hc-abc123",
        "TTL": 30,
        "ResourceRecords": [{"Value": "10.0.1.10"}]
      }
    }]
  }'

Сценарий 11: глобальные таблицы DynamoDB для многорегиональной HA

Сценарий: Мобильному игровому приложению необходимо обеспечить чтение и запись данных игроков с низкой задержкой как из us-east-1, так и из ap-southeast-1. Таблица DynamoDB в одном Region создаёт высокую задержку для пользователей из Азии. Решение: Включите глобальные таблицы DynamoDB. Global Tables автоматически реплицирует данные между указанными Regions с помощью мультимастерной репликации — любой Region может принимать записи. Пользователи из Азии записывают данные и читают их из реплики в ap-southeast-1 с локальной задержкой (около 5 мс). Global Tables разрешает конфликты по стратегии «побеждает последняя запись», используя временные метки. RTO при полном отказе Region близок к нулю — трафик просто направляется в сохранившийся Region.

# Convert a DynamoDB table to a Global Table
# (table must exist in all target Regions first)
aws dynamodb create-global-table \
  --global-table-name PlayerData \
  --replication-group '[{"RegionName": "us-east-1"}, {"RegionName": "ap-southeast-1"}]'

# Add another Region to an existing Global Table
aws dynamodb update-global-table \
  --global-table-name PlayerData \
  --replica-updates '[{"Create": {"RegionName": "eu-west-1"}}]'

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

Проверьте, насколько хорошо Вы поняли концепции AWS Solutions Architect (SAA-C03) из этого урока.

Итоги урока

В этом уроке Вы разобрали сценарии, охватывающие: Multi-AZ ASG и RDS для HA в пределах Region, маршрутизацию Route 53 с переключением для межрегионального DR, DLQ SQS для изоляции ошибочных сообщений без блокировки очередей и Aurora Global Database для межрегионального масштабирования чтения и переключения с RTO менее минуты. Далее Вы разберёте сценарии высокопроизводительной и оптимизированной по стоимости архитектуры.

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

Урок «Сценарии устойчивой архитектуры с высокой доступностью» бесплатный?

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

Чему я научусь в уроке «Сценарии устойчивой архитектуры с высокой доступностью»?

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

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

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

Сколько времени занимает урок «Сценарии устойчивой архитектуры с высокой доступностью»?

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

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

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

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

  1. Сценарии безопасной архитектуры
  2. Сценарии устойчивой архитектуры с высокой доступностью
  3. Сценарии высокой производительности и оптимизации затрат
  4. Полноценный мини-экзамен по всем разделам
← Назад к AWS Solutions Architect