0Pricing
AWS Solutions Architect · 강의

상태 확인, 회로 차단기 및 재시도 로직

ELB 상태 확인, Route 53 엔드포인트 확인 및 애플리케이션 수준 회로 차단기를 사용해 장애를 탐지하고 트래픽을 자동으로 재라우팅합니다.

상태 확인, 회로 차단기 및 재시도 로직은(는) CoddyKit의 무료 AWS Solutions Architect 강의입니다. 이것은 4개 중 4번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 AWS Solutions Architect 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

자동 장애 감지가 중요한 이유

분산 시스템에서는 구성 요소가 지속적으로 장애를 일으킵니다. 인스턴스가 중단되고, 네트워크 파티션이 발생하며, 다운스트림 서비스가 과부하될 수 있습니다. 자동 장애 감지가 없으면 트래픽이 장애가 발생한 구성 요소로 계속 유입되어 연쇄 장애가 발생합니다. AWS는 여러 계층의 Health Check를 제공합니다. ELB Health Check는 비정상 인스턴스를 감지하고, Route 53 Health Check는 비정상 Endpoint를 감지하며, Auto Scaling은 장애가 발생한 인스턴스를 교체합니다. 회로 차단기와 재시도 같은 애플리케이션 수준 패턴이 복원력을 완성합니다.

ELB Health 확인

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 Health 확인

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 Health 확인

Auto Scaling Groups는 두 가지 유형의 상태 확인을 사용할 수 있습니다. 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

Circuit Breaker 패턴

circuit breaker는 하위 서비스에 대한 호출을 모니터링하고 장애가 임계값을 초과하면 일시적으로 호출을 중지하여 연쇄 장애를 방지하는 애플리케이션 수준의 패턴입니다. 회로에는 세 가지 상태가 있습니다. Closed(정상 작동), Open(장애가 임계값을 초과하여 호출이 즉시 차단됨), Half-Open(timeout 후 소수의 시험 호출을 허용하여 서비스가 복구되었는지 확인함)입니다. AWS App Mesh와 Resilience4j 같은 애플리케이션 SDK가 이 패턴을 구현합니다.

# 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

Circuit Breaking을 위한 AWS App Mesh

AWS App Mesh는 코드 변경 없이 인프라 수준에서 회로 차단, 재시도 및 timeout 정책을 구현하는 서비스 메시입니다. 가상 노드 또는 가상 라우터 구성에서 circuit breaker 정책을 정의합니다. 업스트림 서비스가 비정상이 되면 App Mesh의 Envoy 프록시가 자동으로 회로를 열고, timeout을 기다리는 대신 즉시 오류를 반환합니다. 이는 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초...). 이렇게 하면 문제가 있는 서비스의 부하를 줄이고 복구할 시간을 줍니다. 지터(재시도 간격을 무작위화)는 짧은 중단 후 모든 클라이언트가 동시에 재시도하는 집단 폭주 문제를 방지합니다. AWS SDK는 지터가 적용된 지수 백오프를 자동으로 구현합니다.

# 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

Timeout 구성

명시적인 timeout이 없으면 느린 하위 서비스로 인해 스레드가 무기한 차단되고, 연결 풀이 고갈되며 연쇄 장애가 발생합니다. 모든 계층에 timeout을 설정하십시오. 연결 timeout(TCP 연결을 설정하는 데 걸리는 시간), 읽기 timeout(응답을 받는 데 걸리는 시간), 전체 요청 timeout을 설정해야 합니다. AWS에서는 ELB 유휴 timeout(기본값 60초), Lambda 실행 timeout(최대 15분), API Gateway 통합 timeout(최대 29초)을 구성합니다. timeout이 발생하면 재시도 또는 회로 차단 로직이 실행됩니다.

# 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

실패한 처리를 위한 Dead Letter Queue

메시지 처리가 반복해서 실패하면 Dead Letter Queue (DLQ)가 최대 수신 시도 횟수 이후에도 처리되지 않은 메시지를 수집합니다. SQS 대기열과 Lambda 이벤트 소스 매핑에 DLQ를 구성하여 잘못된 메시지가 대기열을 무기한 차단하지 않도록 하십시오. 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 Errors 비율, SQS NumberOfMessagesSentToDLQ(DLQ로 이동한 메시지), 대상 그룹 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 상태 확인은 인프라 수준에서 장애 감지를 자동화합니다. 회로 차단기는 비정상 서비스에 대한 호출을 중지하여 연쇄 장애를 방지합니다. 또한 지터가 적용된 지수 백오프는 부하가 있는 상황에서도 재시도를 안전하게 만듭니다. Dead Letter Queue는 실패한 메시지를 수집하여 검사할 수 있게 합니다. 다음에는 RTO, RPO 및 재해 복구 계층을 살펴봅니다.

자주 묻는 질문

“상태 확인, 회로 차단기 및 재시도 로직” 강의는 무료인가요?

네 — “상태 확인, 회로 차단기 및 재시도 로직” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 AWS Solutions Architect 강의 전체를 잠금 해제할 수 있습니다. AWS Solutions Architect 강의에는 총 4개의 강의가 포함되어 있습니다.

“상태 확인, 회로 차단기 및 재시도 로직”에서 뭘 배우나요?

ELB 상태 확인, Route 53 엔드포인트 확인 및 애플리케이션 수준 회로 차단기를 사용해 장애를 탐지하고 트래픽을 자동으로 재라우팅합니다. 브라우저에서 직접 실행하는 실습 코드로 AWS Solutions Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

AWS Solutions Architect을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 AWS Solutions Architect은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 4번째 강의입니다.

“상태 확인, 회로 차단기 및 재시도 로직” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 AWS Solutions Architect 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 AWS Solutions Architect 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

  1. HA와 내결함성: 정의 및 절충점
  2. 상태 저장 서비스를 위한 다중 AZ 패턴
  3. 다중 리전 액티브-액티브 및 액티브-패시브
  4. 상태 확인, 회로 차단기 및 재시도 로직
← AWS Solutions Architect(으)로 돌아가기