복원력 있고 고가용성인 아키텍처 시나리오
다중 AZ 데이터베이스 장애 조치, 급증하는 트래픽에 대한 자동 확장 및 Route 53 상태 확인 장애 조치 시나리오를 다뤄 신뢰성 개념을 확실히 익힙니다.
복원력 있고 고가용성인 아키텍처 시나리오은(는) CoddyKit의 무료 AWS Solutions Architect 강의입니다. 이것은 4개 중 2번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AWS Solutions Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.
시나리오 1: 다중 AZ 웹 애플리케이션
시나리오: 한 회사가 2계층 웹 애플리케이션(ALB → EC2 → RDS)을 운영하며 AWS Region 내 단일 장애 지점을 모두 제거하려고 합니다. 해결책: ALB(본질적으로 다중 AZ로 구성됨) 뒤에 있는 최소 2개의 Availability Zones에 걸친 Auto Scaling Group에 EC2 인스턴스를 배포합니다. 동기식 대기 복제를 위해 RDS Multi-AZ를 활성화합니다. 비정상 인스턴스에서 자동으로 트래픽을 우회하도록 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 Read Replicas를 생성하고 BI 쿼리가 복제본 엔드포인트를 사용하도록 지정합니다. Read Replicas는 비동기 복제를 사용하므로 분석 작업에서는 약간의 지연을 허용할 수 있습니다. 이렇게 하면 기본 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 급증에 따른 Auto Scaling
시나리오: 상태 비저장 API가 ALB 뒤의 EC2에서 실행됩니다. 업무 시간에는 CPU 사용량이 90%까지 급증하고 밤에는 거의 0으로 떨어집니다. 회사는 인스턴스 집합을 자동으로 확장하려고 합니다. 해결책: 평균 CPU 사용률 60%를 목표로 하는 Target Tracking scaling policy를 사용하여 Auto Scaling Group을 구성합니다. CPU가 60%를 초과하면 ASG가 인스턴스를 자동으로 추가하고, 목표보다 낮아지면 인스턴스를 제거합니다. 아침 업무 시간이 시작되기 전에 최소 용량을 미리 준비하여 아침 트래픽 급증 시 지연을 방지하도록 예약된 확장 작업을 추가합니다.
# 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에서 기본 웹 애플리케이션을 운영하며, 기본 애플리케이션이 비정상 상태가 되면 us-west-2의 정적 S3 호스팅 유지 관리 페이지로 장애 조치하려고 합니다. 해결책: 기본 ALB 엔드포인트를 모니터링하는 Route 53 상태 확인을 생성합니다. 장애 조치 라우팅 정책을 사용하는 Route 53 레코드 2개를 생성합니다. 기본 레코드는 상태 확인과 연결된 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 분리
시나리오: 주문 처리 Backend가 데이터베이스에 쓰기 작업을 수행하지만, 유지 관리 기간 중 데이터베이스를 사용할 수 없게 되는 경우가 있어 주문이 손실됩니다. 해결책: 주문을 받는 Frontend와 주문을 처리하는 Backend 사이에 SQS queue를 배치합니다. 주문을 즉시 queue에 넣어 고객에게 즉시 접수 확인을 제공합니다. 백그라운드 작업자가 데이터베이스를 사용할 수 있을 때 queue에서 주문을 가져와 처리합니다. 유지 관리 중에는 주문이 삭제되지 않고 queue에 쌓이므로 비동기 분리를 통해 복원력을 확보할 수 있습니다.
# 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시간을 충족하는 재해 복구 솔루션이 필요합니다. 해결책: Pilot Light DR 전략을 구현합니다. RDS Cross-Region Read Replica를 사용하여 핵심 데이터베이스를 DR Region에 복제해 둡니다. 정상 운영 중에는 애플리케이션 서버를 DR Region에서 실행하지 않고, 최소한의 '핵심' 요소인 데이터베이스만 준비된 상태로 유지합니다. 재해가 발생하면 Read Replica를 독립 실행형으로 승격하고 CloudFormation을 사용하여 미리 생성한 AMIs에서 애플리케이션 서버를 시작합니다. 서버를 시작해야 하므로 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 Dead-Letter Queue
시나리오: SQS queue의 메시지가 소비자 Lambda의 버그로 인해 반복적으로 처리에 실패합니다. 메시지가 계속 다시 나타나 queue를 차단합니다. 해결책: 기본 queue에 Dead-Letter Queue (DLQ)를 구성합니다. 메시지가 설정 가능한 횟수만큼 처리에 실패하면(maxReceiveCount), SQS가 메시지를 무한히 다시 전달하는 대신 DLQ로 자동 이동합니다. 이렇게 하면 기본 queue가 정상 메시지를 처리할 수 있게 됩니다. DLQ에 메시지가 쌓일 때 엔지니어링 팀에 알리도록 DLQ의 ApproximateNumberOfMessagesVisible 지표에 CloudWatch 경보를 설정합니다.
# 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 Global Database
시나리오: 한 회사가 US와 유럽에서 사업을 운영합니다. RDS가 us-east-1에 있기 때문에 유럽 사용자의 데이터베이스 읽기 지연 시간이 높습니다. 해결책: Amazon Aurora Global Database를 사용합니다. 기본 클러스터는 us-east-1에 두고, 읽기 전용 보조 클러스터를 eu-west-1에 추가합니다. Aurora는 스토리지 수준 복제를 사용하여 일반적으로 1초 미만의 지연 시간으로 데이터를 보조 Region에 복제합니다. 유럽 사용자는 eu-west-1의 보조 클러스터에서 읽기 작업을 수행합니다. 리전에 재해가 발생하면 보조 클러스터를 1분 이내에 기본 클러스터로 승격할 수 있으며, 이는 AWS 다중 리전 DB 옵션 중 가장 우수한 RTO입니다.
# 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: ALB 및 Auto Scaling을 사용하는 ECS 서비스
시나리오: ECS Fargate에서 실행되는 컨테이너화된 API 서비스가 CPU 사용률에 따라 확장되고 AZ 장애에도 운영을 지속해야 합니다. 해결책: 실행 중인 작업 전체에 트래픽이 분산되도록 ECS 서비스를 Application Load Balancer target group에 등록합니다. 서비스 구성에서 여러 서브넷을 지정하여 여러 AZ에 작업을 배치합니다. ECS 서비스 CPU 사용률을 기준으로 하는 대상 추적 정책을 사용하여 ECS Service Auto Scaling을 구성하고 작업 수가 자동으로 증가하거나 감소하도록 합니다. 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을 사용한 상태 확인 장애 조치
시나리오: 한 회사가 서로 다른 AZ에 있는 EC2 인스턴스 2개에서 동일한 도메인을 제공하고 있습니다. 비정상 인스턴스로 트래픽 전송을 자동으로 중단하도록 Route 53을 구성하려고 합니다. 해결책: 동일한 가중치(50/50)를 사용하는 Route 53 Weighted Routing을 적용하고 각 레코드에 엔드포인트 상태 확인을 연결합니다. 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: 다중 리전 HA를 위한 DynamoDB Global Tables
시나리오: 한 모바일 게임 애플리케이션에서 us-east-1과 ap-southeast-1 양쪽의 플레이어 데이터를 짧은 지연 시간으로 읽고 쓸 수 있어야 합니다. 단일 리전 DynamoDB Table을 사용하면 아시아 사용자의 지연 시간이 높아집니다. 해결책: DynamoDB Global Tables를 활성화합니다. Global Tables는 다중 마스터 복제를 사용하여 지정된 Regions 전체에 데이터를 자동으로 복제하므로 어느 Region에서나 쓰기 작업을 받을 수 있습니다. 아시아 사용자는 로컬 지연 시간(~5ms)으로 ap-southeast-1 복제본에 쓰고 읽습니다. Global Tables는 타임스탬프를 기준으로 '마지막 작성자 우선' 전략을 사용하여 충돌을 해결합니다. 전체 리전 장애에 대한 RTO는 거의 0에 가깝고, 트래픽이 살아남은 리전으로 단순히 라우팅됩니다.
# 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) 개념을 이해했는지 확인해 보세요.
단원 요약
이 단원에서는 리전 내 HA를 위한 Multi-AZ ASG 및 RDS, 리전 간 DR을 위한 Route 53 장애 조치 라우팅, queue를 차단하지 않고 실패한 메시지를 격리하기 위한 SQS DLQ, 리전 간 읽기 확장 및 1분 미만의 RTO 장애 조치를 위한 Aurora Global Database에 관한 시나리오를 살펴보았습니다. 다음으로는 고성능 및 비용 최적화 아키텍처 시나리오를 다룹니다.
자주 묻는 질문
“복원력 있고 고가용성인 아키텍처 시나리오” 강의는 무료인가요?
네 — “복원력 있고 고가용성인 아키텍처 시나리오” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AWS Solutions Architect 강의 전체를 잠금 해제할 수 있습니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.
“복원력 있고 고가용성인 아키텍처 시나리오”에서 뭘 배우나요?
다중 AZ 데이터베이스 장애 조치, 급증하는 트래픽에 대한 자동 확장 및 Route 53 상태 확인 장애 조치 시나리오를 다뤄 신뢰성 개념을 확실히 익힙니다. 브라우저에서 직접 실행하는 실습 코드로 AWS Solutions Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.
AWS Solutions Architect을(를) 시작하는 데 경험이 필요한가요?
사전 경험은 필요하지 않습니다. CoddyKit의 AWS Solutions Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 2번째 강의입니다.
“복원력 있고 고가용성인 아키텍처 시나리오” 강의는 얼마나 걸리나요?
대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.
이 AWS Solutions Architect 강의에서 코드를 작성하고 실행할 수 있나요?
네. 모든 AWS Solutions Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.
이 강의의 모든 강의
- 보안 아키텍처 시나리오
- 복원력 있고 고가용성인 아키텍처 시나리오
- 고성능 및 비용 최적화 시나리오
- 혼합 영역 종합 미니 시험