ECS 오토스케일링이 드디어 빨라졌다: 고해상도(20초) 메트릭 실전 적용기

Tech_News

ECS 오토스케일링이 드디어 빨라졌다: 고해상도(20초) 메트릭 실전 적용기

TeEm0 2026. 6. 20. 09:00

도입: 트래픽 스파이크 때마다 한 박자 늦던 그 답답함

ECS로 서비스 운영해본 사람이라면 한 번쯤 겪어봤을 거다. 트래픽이 갑자기 튀는데 태스크는 한참 뒤에야 늘어나고, 그 사이에 응답 지연이나 5xx가 줄줄이 터지는 상황. 모니터링 대시보드 보면서 "왜 아직도 안 늘어나?" 하다가 결국 평소에 태스크를 넉넉하게 띄워놓는 식으로 땜빵하게 된다. 비용은 비용대로 나가고.

이 문제의 근본 원인 중 하나가 CloudWatch 메트릭의 해상도였다. 기존 ECS 서비스 오토스케일링은 기본적으로 1분(60초) 단위 메트릭에 의존했다. CPU가 임계치를 넘어도 메트릭이 집계되고 알람이 평가되고 스케일링이 트리거되기까지 분 단위 지연이 깔려 있었다는 얘기다.

이번에 AWS가 ECS 서비스 오토스케일링에 20초 해상도 고해상도 메트릭을 지원하기 시작했다. 단순한 숫자 변경이 아니라, AWS 자체 벤치마크 기준으로 스케일 아웃 트리거 시간이 363초 → 86초(76% 단축, 4.2배), 새 태스크 프로비저닝까지 포함한 전체 시간이 386초 → 109초(72% 단축, 3.5배)로 줄었다고 한다. 트래픽 대응과 비용 최적화에 직결되는 변화라 안 짚고 넘어갈 수가 없다.

핵심: 1분에서 20초로, 무엇이 달라지나

왜 1분 메트릭이 느렸나

타깃 트래킹 스케일링이 동작하는 흐름을 쪼개보면 이렇다.

ECS/CloudWatch가 CPU·메모리 같은 지표를 수집하고 집계한다.
CloudWatch 알람이 일정 주기로 메트릭을 평가한다.
임계치를 넘으면 Application Auto Scaling이 스케일링 액션을 발동한다.
ECS가 새 태스크를 띄우고 ALB에 등록하고 헬스체크를 통과한다.

1분 메트릭에서는 1~2단계에서만 이미 수십 초~1분 이상이 깔린다. 메트릭이 1분에 한 번 찍히니, 트래픽이 튄 직후의 데이터 포인트가 다음 분이 되어야 반영된다. 거기에 알람 평가 주기까지 더해지면 "지표상 부하가 올랐다"는 사실을 인지하는 데만 수 분이 걸린다.

고해상도 메트릭의 동작

고해상도 메트릭은 이 집계·평가 주기를 20초 단위로 당긴다. 비유하자면, 기존이 1분마다 한 번 창밖을 내다보고 비가 오는지 판단하던 거라면, 고해상도는 20초마다 내다본다. 비 오기 시작하면 더 빨리 우산을 펼 수 있는 거다.

이번 기능에서 새로 추가된 미리 정의된 메트릭은 두 개다.

ECSServiceAverageCPUUtilizationHighResolution
ECSServiceAverageMemoryUtilizationHighResolution

이름에서 보이듯 평균 CPU 사용률과 평균 메모리 사용률 기반이다. 타깃 트래킹 정책에서 이 메트릭을 고르면 ECS 서비스가 20초 간격으로 스케일링 결정을 평가하게 된다. AWS Fargate, ECS Managed Instances, EC2 등 모든 컴퓨트 옵션에서 동작한다.

설정은 두 단계

핵심은 두 가지다. (1) 서비스에 20초 해상도 메트릭을 켠다. (2) 그 메트릭을 쓰는 타깃 트래킹 정책을 건다. 콘솔이라면 서비스 생성/수정 시 Monitoring 섹션에서 20초 해상도 메트릭을 추가하고, Service auto scaling 섹션에서 Target Tracking을 고른 뒤 위의 HighResolution 메트릭을 선택하면 끝이다.

CLI로 한다면 대략 이런 흐름이다. 먼저 서비스에 고해상도 메트릭을 활성화한다.

aws ecs update-service \
  --cluster my-cluster \
  --service my-web-service \
  --service-connect-configuration ... \
  --enable-high-resolution-metrics 2>&1 || true

# 실제 플래그 명칭/위치는 최신 CLI 버전에 따라 다를 수 있으니
# `aws ecs update-service help` 로 확인하는 걸 권장한다.

※ 위 플래그명은 환경/버전에 따라 다를 수 있어 공식 문서 확인이 필요하다. 메트릭이 켜진 뒤 배포가 완료되면 고해상도 메트릭이 생성되기 시작한다.

그다음 Application Auto Scaling으로 타깃 트래킹 정책을 건다. CPU 60%를 타깃으로 잡는 예시다.

# 1) 스케일 대상 등록
aws application-autoscaling register-scalable-target \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-web-service \
  --scalable-dimension ecs:service:DesiredCount \
  --min-capacity 2 \
  --max-capacity 20

# 2) 고해상도 메트릭 기반 타깃 트래킹 정책 생성
cat > policy.json <<'EOF'
{
  "TargetValue": 60.0,
  "PredefinedMetricSpecification": {
    "PredefinedMetricType": "ECSServiceAverageCPUUtilizationHighResolution"
  },
  "ScaleInCooldown": 60,
  "ScaleOutCooldown": 60
}
EOF

aws application-autoscaling put-scaling-policy \
  --service-namespace ecs \
  --resource-id service/my-cluster/my-web-service \
  --scalable-dimension ecs:service:DesiredCount \
  --policy-name cpu-highres-tt \
  --policy-type TargetTrackingScaling \
  --target-tracking-scaling-policy-configuration file://policy.json

정상적으로 들어가면 정책 ARN과 생성된 CloudWatch 알람 정보가 출력된다.

{
    "PolicyARN": "arn:aws:autoscaling:ap-northeast-2:111122223333:scalingPolicy:...:resource/ecs/service/my-cluster/my-web-service:policyName/cpu-highres-tt",
    "Alarms": [
        {
            "AlarmName": "TargetTracking-service/my-cluster/my-web-service-AlarmHigh-xxxxxxxx",
            "AlarmARN": "arn:aws:cloudwatch:ap-northeast-2:111122223333:alarm:..."
        },
        {
            "AlarmName": "TargetTracking-service/my-cluster/my-web-service-AlarmLow-xxxxxxxx",
            "AlarmARN": "arn:aws:cloudwatch:ap-northeast-2:111122223333:alarm:..."
        }
    ]
}

예전에는 이 정도의 공격적인 스케일링을 하려면 스텝 스케일링 정책을 손으로 정교하게 짜야 했는데, 이제는 타깃 트래킹 + 고해상도 메트릭 조합으로 설정 한 번에 비슷한 반응성을 얻을 수 있다는 게 AWS의 설명이다. 그동안 커스텀 엔지니어링으로 땜빵하던 부분이 설정 하나로 대체되는 셈이다.

실무 관점: 트레이드오프와 흔한 함정

비용 — 공짜가 아니다

오해하기 쉬운 부분인데, "빠른 오토스케일링" 기능 자체는 추가 비용이 없다. 다만 고해상도 메트릭이 새로운 과금 차원을 만든다. 표준 해상도(60초) 메트릭은 무료지만, 20초 해상도 메트릭은 CloudWatch 비용이 추가로 발생한다. 정확한 단가는 원문에 명시되어 있지 않으니 CloudWatch 요금 페이지를 직접 확인해야 한다.

그래서 트레이드오프 판단이 중요하다. 고해상도 메트릭 비용을 더 내더라도, 평소 태스크를 넉넉하게 띄워두던 "선제적 패딩"을 줄일 수 있다면 전체 컴퓨트 비용은 오히려 내려갈 수 있다. 스케일 아웃이 충분히 빨라지니까 미리 capacity를 깔아둘 필요가 줄어드는 거다. 반대로 트래픽이 늘 잔잔하고 스파이크가 거의 없는 서비스라면 굳이 고해상도까지 켤 이유가 없다.

워크로드별 권장 (개인 판단 기준)

스파이크가 잦고 급격한 서비스(이벤트성 트래픽, 외부 캠페인 연동 API 등): 고해상도 켤 만하다. 스케일 아웃 지연이 곧 장애로 이어지는 케이스.
완만하게 증감하는 서비스: 60초로도 충분한 경우가 많다. 비용 대비 이득이 작다.
큐 기반 워커(SQS depth 등 커스텀 메트릭): 이번에 추가된 건 CPU/메모리 고해상도 프리디파인드 메트릭이라, 큐 깊이 같은 커스텀 메트릭은 별도로 고해상도로 publish하는 설계가 필요하다. 적용 가능 여부는 문서 확인 필요.

흔한 함정

함정 1 — 메트릭을 안 켜고 정책부터 만든다. 서비스에 고해상도 메트릭을 활성화하고 배포가 완료되기 전에는 HighResolution 메트릭에 데이터 포인트가 안 찍힌다. 이 상태로 타깃 트래킹을 걸면 알람이 데이터 부족 상태로 빠지고 스케일링이 동작하지 않는다. 콘솔이나 알람에서 이런 메시지를 보게 된다.

State: INSUFFICIENT_DATA
StateReason: Insufficient Data: 1 datapoint were unknown.

순서가 핵심이다. 메트릭 활성화 → 배포 완료 → 메트릭 생성 확인 → 정책 연결 순으로 가야 한다.

함정 2 — 쿨다운을 그대로 둔다. 메트릭 평가는 20초로 빨라졌는데 ScaleOutCooldown을 기존처럼 300초로 길게 잡아두면, 정작 추가 스케일 아웃이 쿨다운에 막혀서 고해상도의 이점이 반감된다. 위 예시처럼 쿨다운도 짧게(예: 60초) 재검토하는 게 좋다. 단, 너무 짧으면 출렁임(flapping)이 생길 수 있으니 실측하며 조정해야 한다.

함정 3 — 다운스트림 한계를 무시한다. ECS 태스크는 빨리 늘어나는데 DB 커넥션 풀이나 외부 API rate limit이 그걸 못 받쳐주면, 빠른 스케일 아웃이 오히려 다운스트림을 때려서 장애를 키운다. 스케일링이 빨라질수록 "내 서비스의 진짜 병목이 어디인가"를 다시 봐야 한다.

함정 4 — 프로비저닝 한계를 메트릭으로 해결하려 한다. 벤치마크에서 트리거는 86초로 줄었지만 전체 시간은 109초였다. 즉 태스크 이미지 풀, 컨테이너 기동, ALB 등록·헬스체크에 걸리는 시간은 여전히 남는다. 이미지 슬림화, 헬스체크 주기 튜닝 같은 기본기가 같이 받쳐줘야 체감 효과가 산다.

모니터링 대시보드 팁

고해상도 전환 후에는 대시보드 위젯의 period도 같이 손봐야 한다. 위젯을 60초 period로 두면 모처럼 켠 20초 데이터의 디테일이 뭉개진다. CPU/메모리 위젯은 20초 또는 그에 맞는 짧은 period로 보고, 옆에 DesiredCount와 RunningCount, ALB의 TargetResponseTime/5xx를 나란히 두면 "지표가 오름 → 태스크가 늚 → 지연이 잡힘"이라는 인과를 한눈에 검증할 수 있다.

정리

한 줄 요약: ECS 서비스 오토스케일링이 20초 해상도 메트릭을 지원하면서 스케일 아웃 반응이 약 4배 빨라졌고, 그동안 스텝 스케일링으로 땜빵하던 공격적 스케일링을 타깃 트래킹 설정 하나로 대체할 수 있게 됐다.

누가 언제: 트래픽 스파이크가 잦아서 평소 태스크를 넉넉히 깔아두던 서비스라면 지금 검토할 가치가 충분하다. 고해상도 메트릭 비용은 추가되지만, 선제적 패딩을 줄여 전체 컴퓨트 비용을 낮추는 방향으로 충분히 상쇄할 수 있다. 반대로 트래픽이 완만한 서비스나, 병목이 ECS 태스크가 아니라 DB·외부 API 쪽인 경우엔 효과가 제한적이니 무작정 켜지 말고 트레이드오프를 따져보자. 적용할 땐 메트릭 활성화 순서와 쿨다운 재조정을 꼭 챙겨야 한다.

참고 자료

728x90

저작자표시 비영리 동일조건 (새창열림)