0Pricing
AWS Solutions Architect · 강의

ECS 서비스 자동 확장 및 로드 밸런싱

ECS 서비스에 ALB를 연결해 경로 기반 라우팅을 구성하고, CPU 또는 사용자 지정 CloudWatch 지표에 따라 반응하도록 서비스 자동 확장을 설정합니다.

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

ECS 서비스 자동 확장이 필요한 이유

ECS 서비스에서 desired count를 고정하면 트래픽 변동에 대응할 수 없습니다. 리소스를 과도하게 프로비저닝하면 비용이 낭비되고, 부족하게 프로비저닝하면 성능이 저하됩니다. ECS Service Auto Scaling은 CloudWatch 지표에 따라 작업의 desired count를 자동으로 조정합니다. 이 기능은 내부적으로 DynamoDB, Aurora, ElastiCache에서도 사용하는 동일한 프레임워크인 Application Auto Scaling 서비스를 사용합니다. ECS 서비스 자동 확장은 대상 추적, 단계별 확장, 예약된 확장 정책을 지원합니다.

ECS를 확장 가능한 대상으로 등록하기

확장 정책을 추가하기 전에 Application Auto Scaling에서 ECS 서비스를 확장 가능한 대상으로 등록해야 합니다. 최소 및 최대 작업 수와 클러스터 이름, 리소스 ID로 사용할 서비스 이름을 지정합니다. 이렇게 하면 자동 확장이 작동할 범위가 설정됩니다. 최소 개수는 항상 기본 용량을 유지하도록 하고, 최대 개수는 확장이 지나치게 진행되어 Fargate 용량이나 EC2 인스턴스를 모두 소진하는 것을 방지합니다.

aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id 'service/MyAppCluster/MyAppService' \
  --min-capacity 2 \
  --max-capacity 20

ECS 서비스를 위한 대상 추적

Target Tracking은 대부분의 ECS 서비스에 권장되는 자동 확장 정책입니다. 가장 일반적인 대상 지표는 ECSServiceAverageCPUUtilization입니다. 대상을 50~70%로 설정하면 ECS가 해당 CPU 수준을 유지하도록 작업을 추가하거나 제거합니다. 또 다른 강력한 지표는 ALBRequestCountPerTarget입니다. 작업당 ALB 요청 수를 추적하고 인스턴스당 목표 요청 속도를 유지하도록 확장할 수 있습니다. AWS는 적절한 대기 시간을 적용하여 확장 및 축소를 자동으로 처리합니다.

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --scalable-dimension ecs:service:DesiredCount \
  --resource-id 'service/MyAppCluster/MyAppService' \
  --policy-name 'ECSTargetTracking' \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "PredefinedMetricSpecification": {
      "PredefinedMetricType": "ECSServiceAverageCPUUtilization"
    },
    "TargetValue": 60.0,
    "ScaleOutCooldown": 60,
    "ScaleInCooldown": 300
  }'

ALB에서 ECS 서비스로 라우팅하기

Application Load Balancer (ALB)를 ECS 서비스에 연결하면 실행 중인 모든 작업에 HTTP/HTTPS 트래픽이 분산됩니다. ALB 대상 그룹은 각 작업의 IP(Fargate/awsvpc의 경우) 또는 컨테이너 포트(브리지 모드의 경우)를 등록합니다. ECS는 새 작업이 시작되면 대상 그룹에 자동으로 등록하고, 작업이 중지되면 등록을 해제합니다. ALB는 각 작업에 상태 확인을 수행하며, 비정상 작업은 서비스가 종료하기 전에 연결을 정상적으로 닫는 드레이닝 과정을 거칩니다.

여러 서비스를 위한 경로 기반 라우팅

강력한 패턴 중 하나는 ALB 경로 기반 라우팅을 사용하여 서로 다른 URL 경로를 서로 다른 ECS 서비스로 라우팅하는 것입니다. 하나의 HTTPS 리스너를 가진 단일 ALB로 다음과 같이 라우팅할 수 있습니다. /api/orders/*는 주문 ECS 서비스로, /api/users/*는 사용자 ECS 서비스로, /api/products/*는 상품 ECS 서비스로 라우팅하며, 각 서비스는 독립적으로 확장됩니다. 이렇게 하면 마이크로서비스마다 별도의 로드 밸런서가 필요하지 않아 비용을 줄이고 DNS 관리도 단순화할 수 있습니다.

# ALB listener rule for ECS microservice routing
aws elbv2 create-rule \
  --listener-arn 'arn:aws:elasticloadbalancing:...' \
  --priority 10 \
  --conditions '[{"Field": "path-pattern", "Values": ["/api/orders/*"]}]' \
  --actions '[{"Type": "forward", "TargetGroupArn": "arn:...OrdersTargetGroup"}]'

연결 드레이닝 및 등록 해제 지연

ECS 작업이 종료되는 동안(축소 또는 배포 시) ALB는 해당 작업을 드레이닝 상태로 표시하고 새 요청의 라우팅을 중지하면서 이미 처리 중인 요청은 완료되도록 허용합니다. 등록 해제 지연(기본값 300초, 0~3600초로 구성 가능)은 ALB가 연결을 강제로 닫기 전에 기다리는 시간입니다. 요청 처리 시간이 짧은 ECS 서비스라면 배포 및 축소 작업을 빠르게 수행할 수 있도록 등록 해제 지연을 더 짧게(30~60초) 설정하십시오. 연결이 오래 유지되는 경우(WebSocket, 파일 업로드)에는 더 긴 지연을 유지하십시오.

# Set deregistration delay on target group to 60 seconds
aws elbv2 modify-target-group-attributes \
  --target-group-arn 'arn:aws:elasticloadbalancing:...' \
  --attributes 'Key=deregistration_delay.timeout_seconds,Value=60'

ECS 확장을 위한 사용자 지정 지표

CPU와 메모리 외에도 애플리케이션에서 사용자 지정 CloudWatch 지표(대기열 깊이, 활성 세션, 비즈니스 KPI)를 게시하고 이를 확장의 기준으로 사용할 수 있습니다. 예를 들어 ECS 작업 하나가 대기열 메시지 50개를 동시에 처리할 수 있다면 SQS 대기열 깊이를 사용자 지정 지표로 게시하고, 작업당 메시지 50개를 대상으로 하는 대상 추적 정책을 생성할 수 있습니다. 이렇게 하면 애플리케이션 부하와 상관관계가 낮을 수 있는 인프라 지표에 의존하지 않고 비즈니스 로직에 직접 기반하여 확장할 수 있습니다.

aws application-autoscaling put-scaling-policy \
  --policy-name 'QueueDepthScaling' \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration '{
    "CustomizedMetricSpecification": {
      "MetricName": "QueueDepth",
      "Namespace": "MyApp",
      "Statistic": "Average"
    },
    "TargetValue": 50.0
  }' \
  --resource-id 'service/MyCluster/WorkerService' \
  --scalable-dimension ecs:service:DesiredCount \
  --service-namespace ecs

작업을 위한 축소 보호

EC2 Auto Scaling과 마찬가지로 ECS도 작업 축소 보호를 지원합니다. 실행 중인 작업은 ECS API를 통해 자체 축소 보호 플래그를 설정하여 중요한 작업을 처리하는 동안 축소로 종료되지 않도록 할 수 있습니다. 이는 SQS 작업자 역할을 하는 ECS 작업에 유용합니다. 긴 작업을 방금 대기열에서 가져온 작업자는 자신을 보호하고, 작업을 완료한 뒤 보호를 해제할 수 있습니다. 이 기능이 없으면 축소 과정에서 처리 중인 작업이 종료되어 작업이 중복되거나 데이터가 손실될 수 있습니다.

# From inside the ECS task container
curl -X PUT 'http://169.254.170.2/v3/tasks/scale-in-protection' \
  -H 'Content-Type: application/json' \
  -d '{"ProtectionEnabled": true, "ExpiresInMinutes": 60}'

확장 지표: CPU, 메모리, ALB 비교

확장 지표를 신중하게 선택하십시오. CPU 사용률은 기본값이며 연산 중심의 워크로드에 적합합니다. 메모리 사용률(ECSServiceAverageMemoryUtilization)은 메모리 중심 애플리케이션에 유용하지만, 메모리를 확장하려면 작업을 추가해야 합니다. 작업이 동시 처리량이 아니라 작업당 메모리 한도의 제약을 받는다면 작업 정의의 메모리 할당을 수정하는 편이 더 나을 수 있습니다. ALBRequestCountPerTarget는 사용자 경험과 직접적인 상관관계가 있으므로 웹 API에 가장 실용적인 지표입니다. 작업당 실제 요청 속도를 기준으로 확장하십시오.

ECS 배포 회로 차단기

ECS Deployment Circuit Breaker는 실패한 배포를 자동으로 감지하고 마지막으로 안정적이었던 버전으로 롤백합니다. 이 기능이 없으면 상태 확인에 실패하는 컨테이너가 포함된 잘못된 배포에서도 ECS가 새 작업을 무기한 시작하려고 시도합니다. 회로 차단기를 활성화하면 새로 시작된 작업 중 일정 비율이 감지 기간 내에 상태 확인에 실패할 때 ECS가 배포를 FAILED로 표시하고 이전 작업 정의 리비전으로 자동 롤백합니다. 이를 통해 잘못된 배포로 인해 서비스 성능이 장시간 저하되는 것을 방지할 수 있습니다.

aws ecs create-service \
  --cluster 'MyAppCluster' \
  --service-name 'MyAppService' \
  --task-definition 'myapp-task:5' \
  --desired-count 3 \
  --deployment-configuration '{
    "deploymentCircuitBreaker": {
      "enable": true,
      "rollback": true
    },
    "minimumHealthyPercent": 100,
    "maximumPercent": 200
  }'

종단 간 아키텍처: ECS + ALB + 자동 확장

프로덕션에 사용할 수 있는 컨테이너화된 웹 API 아키텍처는 다음과 같습니다. Route 53이 도메인을 ALB DNS 이름으로 확인하고, ALB가 HTTPS(ACM 인증서)를 종료하며 WAF 규칙을 적용한 뒤 요청을 ECS 서비스 대상 그룹으로 라우팅합니다. 3개의 AZ에 걸친 프라이빗 서브넷의 Fargate 작업이 요청을 처리하고, ECS Service Auto Scaling이 ALBRequestCountPerTarget에 대한 대상 추적을 사용하여 작업 수를 2개에서 50개 사이로 조정합니다. 작업은 프라이빗 서브넷의 RDS Aurora 및 ElastiCache에 연결됩니다. 모든 로그는 CloudWatch Logs로 전송되며, 지표는 CloudWatch 대시보드와 경보를 구동합니다.

빠른 확인

이 단원에서 다룬 AWS Solutions Architect (SAA-C03) 개념을 이해했는지 확인하십시오.

단원 요약

이 단원에서는 다음을 배웠습니다. ECS Service Auto Scaling은 대상 추적(CPU, ALB 요청 또는 사용자 지정 지표)을 사용하는 Application Auto Scaling으로 구성된 최소 및 최대 범위 안에서 작업 수를 조정합니다. ALB 경로 기반 라우팅을 사용하면 URL 경로를 서로 다른 대상 그룹으로 라우팅하여 하나의 로드 밸런서로 여러 ECS 마이크로서비스를 제공할 수 있습니다. 또한 Deployment Circuit Breaker는 실패한 배포가 서비스 성능을 장시간 저하시키기 전에 자동으로 롤백합니다. 이것으로 ECS 및 컨테이너 모듈을 마치고, 다음에는 AWS에서 Kubernetes를 실행하는 Amazon EKS를 살펴보겠습니다.

자주 묻는 질문

“ECS 서비스 자동 확장 및 로드 밸런싱” 강의는 무료인가요?

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

“ECS 서비스 자동 확장 및 로드 밸런싱”에서 뭘 배우나요?

ECS 서비스에 ALB를 연결해 경로 기반 라우팅을 구성하고, CPU 또는 사용자 지정 CloudWatch 지표에 따라 반응하도록 서비스 자동 확장을 설정합니다. 브라우저에서 직접 실행하는 실습 코드로 AWS Solutions Architect을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

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

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

“ECS 서비스 자동 확장 및 로드 밸런싱” 강의는 얼마나 걸리나요?

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

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

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

이 강의의 모든 강의

  1. ECS 클러스터, 작업 정의 및 서비스
  2. EC2 시작 유형과 Fargate 비교
  3. ECR: 컨테이너 이미지 저장 및 가져오기
  4. ECS 서비스 자동 확장 및 로드 밸런싱
← AWS Solutions Architect(으)로 돌아가기