ECS 오토스케일링 완벽 가이드

AWS ECS에서 트래픽에 따라 자동으로 서비스를 확장하고 축소하는 오토스케일링 설정 방법을 초급 개발자도 쉽게 이해할 수 있도록 실무 중심으로 설명합니다. 비용 최적화와 안정적인 서비스 운영의 핵심 기술입니다.

---

목차

1. 오토스케일링_개념
2. Application_Auto_Scaling
3. CPU_메모리_기반_스케일링
4. 스케일링_정책_종류
5. 예약_스케일링
6. 스케일링_테스트
7. 5분 후 태스크 감소 확인: 4개 → 2개

---

1. 오토스케일링 개념

어느 월요일 아침, 김개발 씨는 급하게 출근했습니다. 주말 동안 서비스에 접속자가 급증하면서 서버가 다운되었다는 알림을 받았기 때문입니다.

"왜 미리 서버를 늘려두지 않았을까?" 하지만 평소에는 사용자가 적어서 서버를 많이 띄워두면 비용만 낭비됩니다.

오토스케일링은 한마디로 트래픽에 따라 자동으로 서버 개수를 조절하는 기능입니다. 마치 식당에서 손님이 많을 때는 직원을 더 투입하고, 한가할 때는 줄이는 것과 같습니다.

ECS에서는 Application Auto Scaling을 통해 태스크 수를 자동으로 늘리거나 줄일 수 있습니다. 이를 통해 비용 절감과 안정적인 서비스 운영이라는 두 마리 토끼를 모두 잡을 수 있습니다.

다음 코드를 살펴봅시다.

# AWS CLI로 Auto Scaling 대상 등록
aws application-autoscaling register-scalable-target \
    --service-namespace ecs \
    --resource-id service/my-cluster/my-service \
    --scalable-dimension ecs:service:DesiredCount \
    --min-capacity 2 \
    --max-capacity 10

# 현재 스케일링 설정 확인
aws application-autoscaling describe-scalable-targets \
    --service-namespace ecs \
    --resource-ids service/my-cluster/my-service

김개발 씨는 입사 4개월 차 백엔드 개발자입니다. 이번 주말에 마케팅팀에서 대규모 이벤트를 진행한다는 소식을 들었습니다.

평소보다 10배 많은 트래픽이 예상된다고 합니다. 어떻게 대비해야 할까요?

선배 개발자 박시니어 씨가 다가와서 말합니다. "김개발 씨, 이번 기회에 오토스케일링을 설정해보는 게 어떨까요?

그러면 이런 상황에서 자동으로 서버가 늘어나고 줄어들어서 편하답니다." 오토스케일링이란 정확히 무엇일까요? 쉽게 비유하자면, 오토스케일링은 마치 버스 회사가 운영하는 배차 시스템과 같습니다. 출퇴근 시간에는 버스를 많이 투입하고, 한가한 시간대에는 버스 대수를 줄입니다.

손님이 많을 때는 대기 시간을 줄이고, 적을 때는 운영 비용을 절감하는 것이지요. ECS의 오토스케일링도 이와 똑같은 원리로 태스크(컨테이너) 개수를 자동으로 조절합니다.

오토스케일링이 없던 시절에는 어땠을까요? 개발자들은 트래픽 패턴을 미리 예측해서 수동으로 서버 개수를 조절해야 했습니다. 월요일 아침에는 서버를 10대로 늘리고, 저녁에는 5대로 줄이는 식이었지요.

하지만 갑작스러운 트래픽 증가에는 대응할 수 없었습니다. 더 큰 문제는 새벽 시간처럼 사용자가 거의 없을 때도 서버가 계속 돌아가면서 비용이 낭비된다는 점이었습니다.

김개발 씨도 지난주에 이런 경험을 했습니다. 금요일 저녁에 갑자기 TV 프로그램에서 자사 서비스가 소개되면서 트래픽이 폭증했습니다.

서버가 느려지고 일부 사용자는 접속조차 할 수 없었습니다. 급하게 수동으로 서버를 늘렸지만, 설정하는 데만 10분이 걸렸고 그 사이 많은 사용자가 이탈했습니다.

바로 이런 문제를 해결하기 위해 오토스케일링이 등장했습니다. 오토스케일링을 사용하면 실시간 모니터링을 통해 자동으로 서버를 증설할 수 있습니다. CPU 사용률이 70%를 넘으면 태스크를 추가하고, 30% 아래로 떨어지면 태스크를 줄이는 식입니다.

또한 비용 최적화도 자동으로 이루어집니다. 무엇보다 개발자가 24시간 모니터링하지 않아도 된다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 register-scalable-target 명령으로 오토스케일링 대상을 등록합니다. 이 부분이 핵심입니다.

--service-namespace ecs는 ECS 서비스를 대상으로 한다는 의미이고, --resource-id에는 실제 클러스터와 서비스 이름을 지정합니다. --min-capacity 2는 최소한 2개의 태스크는 항상 유지하겠다는 뜻이고, --max-capacity 10은 아무리 트래픽이 많아도 10개까지만 늘리겠다는 설정입니다.

다음으로 describe-scalable-targets 명령으로 현재 설정을 확인할 수 있습니다. 이 명령을 실행하면 최소/최대 용량, 현재 상태 등을 JSON 형태로 볼 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 평소에는 태스크 2개로도 충분하지만, 점심시간(12-1시)과 저녁시간(7-9시)에는 주문이 폭증합니다.

오토스케일링을 설정해두면 이 시간대에 자동으로 태스크가 6-8개로 늘어나고, 한가한 시간에는 다시 2개로 줄어듭니다. 쿠팡, 배달의민족 같은 대형 서비스들이 모두 이런 패턴을 적극 활용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 최소 용량을 0으로 설정하는 것입니다. 비용을 아끼려는 의도지만, 이렇게 하면 트래픽이 들어왔을 때 태스크를 새로 시작하는 데 시간이 걸려서 첫 사용자는 오류를 경험할 수 있습니다.

따라서 최소한 1-2개의 태스크는 항상 실행 상태로 유지하는 것이 좋습니다. 또한 최대 용량도 너무 크게 잡으면 예상치 못한 트래픽 폭증 시 비용이 폭탄처럼 나올 수 있습니다.

실제 필요한 용량보다 20-30% 여유를 두는 정도가 적당합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 대형 서비스들은 갑작스러운 트래픽에도 문제없이 작동하는군요!" 이제 이번 주말 이벤트도 걱정 없습니다. 오토스케일링을 제대로 이해하면 안정적이면서도 비용 효율적인 서비스를 운영할 수 있습니다.

여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - 최소 용량은 1-2개로 설정하여 콜드 스타트 방지

• 최대 용량은 실제 필요량의 120-130% 수준으로 제한
• 초기에는 보수적으로 설정하고 점진적으로 조정

---

2. Application Auto Scaling

김개발 씨가 오토스케일링 대상을 등록했습니다. 그런데 박시니어 씨가 물어봅니다.

"그런데 김개발 씨, EC2 오토스케일링이랑 ECS 오토스케일링이랑 뭐가 다른지 알아요?" 김개발 씨는 당황했습니다. 둘 다 서버를 늘리고 줄이는 거 아닌가요?

Application Auto Scaling은 ECS, DynamoDB, Lambda 등 다양한 AWS 서비스의 리소스를 자동으로 조절하는 통합 서비스입니다. 마치 멀티탭 하나로 여러 전자제품을 관리하는 것처럼, 하나의 API로 여러 서비스의 스케일링을 제어할 수 있습니다.

ECS에서는 태스크 수를, DynamoDB에서는 읽기/쓰기 용량을 조절합니다.

다음 코드를 살펴봅시다.

import boto3

# Application Auto Scaling 클라이언트 생성
client = boto3.client('application-autoscaling')

# ECS 서비스에 대한 스케일링 대상 등록
response = client.register_scalable_target(
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    MinCapacity=2,
    MaxCapacity=10,
    RoleARN='arn:aws:iam::123456789012:role/ecsAutoscaleRole'
)

# 등록 결과 확인
print(f"스케일링 대상 등록 완료: {response['ResponseMetadata']['HTTPStatusCode']}")

김개발 씨는 클라우드를 배우면서 용어가 너무 많아 헷갈렸습니다. EC2 Auto Scaling, Application Auto Scaling, ECS Service Auto Scaling...

대체 이것들이 뭐가 다른 걸까요? 박시니어 씨가 화이트보드를 가져와서 그림을 그리며 설명합니다.

"자, 들어보세요. AWS에는 스케일링을 담당하는 서비스가 여러 개 있어요." Application Auto Scaling이란 정확히 무엇일까요? 쉽게 비유하자면, Application Auto Scaling은 마치 건물의 통합 관제 시스템과 같습니다.

엘리베이터, 에어컨, 조명 등 각각 다른 장치들을 하나의 시스템에서 관리하는 것이지요. 각 장치마다 별도의 리모컨을 사용하는 대신, 중앙 컨트롤러 하나로 모든 것을 제어합니다.

AWS에서도 Application Auto Scaling이라는 통합 서비스로 ECS, DynamoDB, Aurora, Lambda 등 다양한 서비스의 스케일링을 관리합니다. 과거에는 어떻게 관리했을까요? 예전에는 각 서비스마다 고유한 API를 사용해야 했습니다.

ECS는 ECS API로, DynamoDB는 DynamoDB API로 각각 스케일링을 설정했지요. 코드도 중복되고, 관리 포인트도 많아서 불편했습니다.

특히 여러 서비스를 함께 사용하는 마이크로서비스 아키텍처에서는 이런 복잡성이 배가되었습니다. 김개발 씨도 처음에는 ECS API를 직접 사용하려고 했습니다.

하지만 문서를 읽다 보니 "Application Auto Scaling을 사용하세요"라는 안내를 발견했습니다. "왜 굳이 다른 서비스를 거쳐야 하지?" 하고 의아했지만, 박시니어 씨의 설명을 듣고 나니 이해가 되었습니다.

Application Auto Scaling의 장점은 무엇일까요? 첫째, 일관된 API를 제공합니다. ECS든 DynamoDB든 같은 방식으로 스케일링을 설정할 수 있습니다.

register-scalable-target이라는 하나의 명령으로 모든 서비스의 스케일링 대상을 등록하지요. 둘째, 세밀한 제어가 가능합니다.

최소/최대 용량은 물론이고, 스케일링 속도, 쿨다운 시간 등을 조절할 수 있습니다. 셋째, IAM 역할 기반 권한 관리가 됩니다.

누가 어떤 서비스의 스케일링을 제어할 수 있는지 세밀하게 설정할 수 있습니다. 위의 Python 코드를 살펴보겠습니다. 먼저 boto3.client('application-autoscaling')로 클라이언트를 생성합니다.

이것이 Application Auto Scaling 서비스와 통신하는 창구입니다. 다음으로 register_scalable_target 메서드를 호출하는데, 여기서 주목할 점은 ServiceNamespace와 ScalableDimension입니다.

ServiceNamespace='ecs'는 ECS 서비스를 대상으로 한다는 뜻이고, ScalableDimension='ecs:service:DesiredCount'는 서비스의 희망 태스크 수를 조절하겠다는 의미입니다. 만약 DynamoDB라면 dynamodb:table:ReadCapacityUnits처럼 읽기 용량을 지정할 수도 있습니다.

마지막으로 RoleARN에는 실제 스케일링 작업을 수행할 IAM 역할을 지정합니다. 이 역할에는 ECS 태스크를 시작하고 종료할 수 있는 권한이 있어야 합니다.

실제 프로젝트에서는 어떻게 활용할까요? 마이크로서비스 아키텍처를 예로 들어보겠습니다. 주문 서비스(ECS), 재고 데이터베이스(DynamoDB), 알림 함수(Lambda)가 있다고 가정합시다.

트래픽이 증가하면 이 세 가지가 모두 함께 확장되어야 합니다. Application Auto Scaling을 사용하면 동일한 방식으로 세 서비스의 스케일링을 설정할 수 있어서 관리가 훨씬 편합니다.

주의할 점이 있습니다. IAM 역할 설정을 잘못하면 스케일링이 작동하지 않습니다. ecsAutoscaleRole에는 ecs:UpdateService, ecs:DescribeServices 등의 권한이 반드시 필요합니다.

또한 CloudWatch 메트릭을 읽을 수 있는 권한도 있어야 합니다. 처음 설정할 때는 AWS가 제공하는 관리형 정책을 사용하는 것이 안전합니다.

김개발 씨는 이제 명확히 이해했습니다. "아하, EC2 Auto Scaling은 EC2 인스턴스 자체를 늘리는 거고, Application Auto Scaling은 ECS 태스크나 DynamoDB 같은 애플리케이션 레벨 리소스를 늘리는 거네요!" 박시니어 씨가 웃으며 고개를 끄덕입니다. Application Auto Scaling의 개념을 이해하면 다양한 AWS 서비스를 일관되게 관리할 수 있습니다.

특히 마이크로서비스 환경에서 그 진가를 발휘합니다.

실전 팁

💡 - ServiceNamespace와 ScalableDimension을 정확히 매칭시켜야 함

• IAM 역할에는 충분한 권한 부여 필요
• boto3를 사용하면 Infrastructure as Code로 관리 가능

---

3. CPU 메모리 기반 스케일링

오토스케일링 대상을 등록한 김개발 씨. 하지만 아직 아무 일도 일어나지 않습니다.

박시니어 씨가 말합니다. "이제 스케일링 정책을 만들어야죠.

CPU가 70%를 넘으면 태스크를 늘리도록 설정해봅시다."

Target Tracking Scaling Policy는 특정 메트릭을 목표값으로 유지하도록 자동 조절하는 정책입니다. 마치 에어컨이 실내 온도를 26도로 유지하는 것처럼, CPU 사용률을 70%로 유지하도록 태스크를 늘리거나 줄입니다.

CPU와 메모리 사용률이 가장 많이 사용되는 메트릭이며, CloudWatch를 통해 실시간으로 모니터링됩니다.

다음 코드를 살펴봅시다.

import boto3
import json

client = boto3.client('application-autoscaling')

# CPU 기반 Target Tracking 정책 설정
response = client.put_scaling_policy(
    PolicyName='cpu-target-tracking-policy',
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    PolicyType='TargetTrackingScaling',
    TargetTrackingScalingPolicyConfiguration={
        'TargetValue': 70.0,  # CPU 70% 유지
        'PredefinedMetricSpecification': {
            'PredefinedMetricType': 'ECSServiceAverageCPUUtilization'
        },
        'ScaleOutCooldown': 60,  # 스케일 아웃 후 60초 대기
        'ScaleInCooldown': 300   # 스케일 인 후 300초 대기
    }
)

print(f"정책 ARN: {response['PolicyARN']}")

김개발 씨가 스케일링 대상 등록까지는 완료했습니다. 이제 트래픽이 몰리면 자동으로 서버가 늘어날까요?

테스트를 위해 부하를 걸어봤지만 아무 변화가 없습니다. 박시니어 씨가 모니터를 보더니 말합니다.

"아직 스케일링 정책을 만들지 않아서 그래요. 대상만 등록하고 언제 늘릴지 기준을 안 정했거든요." 스케일링 정책이란 무엇일까요? 쉽게 비유하자면, 스케일링 정책은 마치 자동 온도 조절 장치와 같습니다.

에어컨에 "26도를 유지하세요"라고 설정하면, 온도가 올라가면 냉방을 강하게 하고 내려가면 약하게 합니다. 스케일링 정책도 똑같습니다.

**"CPU 사용률을 70%로 유지하세요"**라고 설정하면, 사용률이 올라가면 태스크를 추가하고 내려가면 줄입니다. 정책이 없으면 어떻게 될까요? 스케일링 대상만 등록하고 정책을 만들지 않으면, AWS는 "언제 늘려야 하는지" 모릅니다.

마치 에어컨은 있지만 리모컨이 없는 것과 같지요. 수동으로 원하는 태스크 수를 변경할 수는 있지만, 자동으로는 아무 일도 일어나지 않습니다.

김개발 씨도 이 부분에서 한참 헤맸습니다. 분명히 오토스케일링을 설정했는데 작동하지 않아서 AWS 문서를 뒤적였습니다.

그리고 깨달았습니다. "아, 정책을 별도로 만들어야 하는구나!" Target Tracking 정책의 장점은 무엇일까요? 첫째, 설정이 매우 간단합니다.

목표값만 지정하면 AWS가 알아서 언제 늘리고 줄일지 계산합니다. Step Scaling이나 Simple Scaling처럼 복잡한 임계값을 여러 개 설정할 필요가 없습니다.

둘째, 안정적인 성능을 유지합니다. CPU가 70%를 넘지 않도록 계속 조절하므로, 사용자는 항상 빠른 응답 속도를 경험합니다.

셋째, 비용 효율적입니다. 필요 이상으로 태스크를 늘리지 않고, 딱 필요한 만큼만 유지합니다.

위의 코드를 단계별로 살펴보겠습니다. put_scaling_policy 메서드로 정책을 생성합니다. PolicyType='TargetTrackingScaling'이 핵심인데, 이것이 목표값 추적 방식임을 나타냅니다.

TargetValue=70.0은 CPU 사용률 70%를 목표로 한다는 의미입니다. PredefinedMetricType='ECSServiceAverageCPUUtilization'은 미리 정의된 메트릭 중 ECS 서비스의 평균 CPU 사용률을 사용하겠다는 뜻입니다.

메모리를 사용하고 싶다면 ECSServiceAverageMemoryUtilization으로 변경하면 됩니다. 쿨다운 시간도 중요합니다.

ScaleOutCooldown=60은 스케일 아웃(태스크 증가) 후 60초 동안은 추가 스케일 아웃을 하지 않겠다는 의미입니다. 새로 시작된 태스크가 안정화될 시간을 주는 것이지요.

ScaleInCooldown=300은 스케일 인(태스크 감소) 후 5분 대기입니다. 스케일 인은 더 신중하게 진행하는 것이 좋습니다.

실무에서는 어떻게 활용할까요? API 서버를 운영한다고 가정해봅시다. 평소에는 CPU 30%로 여유롭게 돌아가지만, 점심시간에는 80-90%까지 치솟습니다.

Target Tracking 정책을 70%로 설정해두면, 점심시간 직전에 자동으로 태스크가 늘어나서 CPU 사용률이 70% 선에서 유지됩니다. 점심시간이 지나면 다시 자동으로 줄어들어 비용이 절감됩니다.

주의할 점도 있습니다. CPU를 메트릭으로 사용할 때, 목표값을 너무 높게 설정하면 위험합니다. 90%로 설정하면 이미 서버가 과부하 상태인 것이므로, 사용자가 느린 응답을 경험할 수 있습니다.

일반적으로 **60-70%**가 적절합니다. 또한 CPU가 아니라 메모리가 병목인 애플리케이션도 있습니다.

Java 애플리케이션처럼 메모리를 많이 사용하는 경우, 메모리 사용률을 메트릭으로 사용하는 것이 더 효과적입니다. 김개발 씨가 정책을 적용하고 다시 테스트했습니다. 이번에는 부하를 걸자 CPU가 올라가기 시작했고, 70%를 넘는 순간 새로운 태스크가 자동으로 시작되었습니다.

"와, 정말 자동으로 늘어나네요!" 김개발 씨는 신기해하며 모니터링 화면을 바라봤습니다. Target Tracking 정책을 이해하면 복잡한 계산 없이도 안정적인 오토스케일링을 구현할 수 있습니다.

목표값 하나만 잘 정하면 됩니다.

실전 팁

💡 - CPU 목표값은 60-70%가 적당 (너무 높으면 위험)

• 메모리 집약적 앱은 메모리 메트릭 사용 고려
• ScaleInCooldown은 ScaleOutCooldown보다 길게 설정

---

4. 스케일링 정책 종류

김개발 씨가 Target Tracking 정책을 성공적으로 적용했습니다. 박시니어 씨가 슬랙으로 메시지를 보냅니다.

"잘했어요! 근데 내일 새벽 3시에 배치 작업이 있잖아요.

그때는 Step Scaling을 써보는 게 어떨까요?"

AWS는 세 가지 스케일링 정책을 제공합니다. Target Tracking은 목표값 유지, Step Scaling은 단계별 조절, Scheduled Scaling은 예약된 시간에 변경입니다.

마치 난방을 자동 온도 조절, 수동 단계 조절, 타이머 예약 중에서 선택하는 것과 같습니다. 각 정책은 서로 다른 상황에 최적화되어 있습니다.

다음 코드를 살펴봅시다.

import boto3

client = boto3.client('application-autoscaling')

# Step Scaling 정책: CPU가 80% 넘으면 3개, 90% 넘으면 5개 추가
response = client.put_scaling_policy(
    PolicyName='cpu-step-scaling-policy',
    ServiceNamespace='ecs',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    PolicyType='StepScaling',
    StepScalingPolicyConfiguration={
        'AdjustmentType': 'ChangeInCapacity',
        'StepAdjustments': [
            {'MetricIntervalLowerBound': 0, 'MetricIntervalUpperBound': 10, 'ScalingAdjustment': 2},
            {'MetricIntervalLowerBound': 10, 'MetricIntervalUpperBound': 20, 'ScalingAdjustment': 3},
            {'MetricIntervalLowerBound': 20, 'ScalingAdjustment': 5}
        ],
        'Cooldown': 60
    }
)

김개발 씨는 Target Tracking으로 일반 트래픽은 잘 처리했습니다. 하지만 매일 새벽 3시에 실행되는 대용량 배치 작업은 좀 다릅니다.

CPU가 순식간에 100%까지 치솟고, 작업이 끝나면 다시 정상으로 돌아옵니다. 박시니어 씨가 설명합니다.

"이런 급격한 변화에는 Step Scaling이 더 적합해요. CPU 증가 폭에 따라 서버를 더 많이 늘릴 수 있거든요." 스케일링 정책의 종류는 무엇이 있을까요? 쉽게 비유하자면, 이것은 마치 교통 신호 제어 시스템과 같습니다.

평소에는 자동 신호 제어(Target Tracking)로 차량 흐름에 맞춰 신호를 조절합니다. 사고나 공사가 있을 때는 수동 단계별 제어(Step Scaling)로 상황에 맞게 대응합니다.

출퇴근 시간처럼 예측 가능한 시간대는 타이머 제어(Scheduled Scaling)로 미리 신호 시간을 조정합니다. 각 정책은 언제 사용할까요? Target Tracking은 가장 간단하고 대부분의 상황에 적합합니다.

웹 서비스, API 서버처럼 지속적인 트래픽이 있고 목표 성능을 유지하고 싶을 때 사용합니다. "CPU 70% 유지"처럼 명확한 목표가 있으면 이것을 선택하세요.

Step Scaling은 더 세밀한 제어가 필요할 때 사용합니다. 예를 들어 CPU가 조금 올라가면 2개만 추가하지만, 많이 올라가면 5개를 추가하는 식입니다.

배치 작업이나 급격한 트래픽 변화가 있는 경우에 적합합니다. Scheduled Scaling은 트래픽 패턴을 미리 알고 있을 때 사용합니다.

매일 오전 9시에 출근하는 직장인들이 앱을 켜는 서비스라면, 오전 8시 50분에 미리 서버를 늘려두는 것이지요. Step Scaling 코드를 자세히 살펴보겠습니다. PolicyType='StepScaling'으로 단계별 정책임을 명시합니다.

AdjustmentType='ChangeInCapacity'는 절대값이 아니라 변경량을 의미합니다. 현재 5개 태스크가 있다면, +2는 7개가 되는 것이지요.

StepAdjustments가 핵심입니다. 첫 번째 항목 {'MetricIntervalLowerBound': 0, 'MetricIntervalUpperBound': 10, 'ScalingAdjustment': 2}는 "임계값보다 0-10% 높으면 2개 추가"라는 의미입니다.

예를 들어 알람이 70%에 설정되어 있다면, CPU가 70-80%일 때 2개를 추가합니다. 두 번째 항목은 80-90%일 때 3개, 세 번째는 90% 이상일 때 5개를 추가합니다.

이렇게 상황에 따라 다르게 반응할 수 있습니다. 실제 사례를 들어보겠습니다. 온라인 쇼핑몰을 운영한다고 가정합시다.

평소에는 Target Tracking으로 CPU 60%를 유지합니다. 하지만 블랙프라이데이 같은 대규모 이벤트 기간에는 Step Scaling을 추가로 설정합니다.

트래픽이 폭증할 때 더 공격적으로 서버를 늘려서 서비스 중단을 방지하는 것이지요. 또한 매일 자정에 일일 정산 배치가 돌아간다면, Scheduled Scaling으로 오후 11시 55분에 서버를 미리 10대로 늘려둡니다.

배치가 끝나는 오전 1시에는 다시 2대로 줄입니다. 주의할 점이 있습니다. 여러 정책을 동시에 사용할 수 있지만, 충돌하지 않도록 주의해야 합니다.

예를 들어 Target Tracking과 Step Scaling을 동시에 사용하면, 둘 다 같은 메트릭(CPU)을 보고 있을 때 예상치 못한 동작이 발생할 수 있습니다. 일반적으로 Target Tracking 하나만 사용하거나, Step Scaling과 Scheduled Scaling을 조합하는 것이 안전합니다.

또한 AdjustmentType을 잘못 선택하면 큰일 납니다. PercentChangeInCapacity는 퍼센트 변경이므로, 태스크가 2개일 때 +100%를 하면 4개가 됩니다.

하지만 태스크가 10개일 때는 20개가 되어버립니다. 절대값 제어가 필요하면 ChangeInCapacity를 사용하세요.

김개발 씨가 정리했습니다. "평소에는 Target Tracking, 배치 작업 때는 Step Scaling, 예측 가능한 시간대는 Scheduled Scaling을 쓰면 되겠네요!" 박시니어 씨가 엄지를 치켜세웁니다. 각 정책의 특성을 이해하면 상황에 맞는 최적의 오토스케일링을 구현할 수 있습니다.

처음에는 Target Tracking부터 시작하세요.

실전 팁

💡 - 대부분의 경우 Target Tracking 하나로 충분

• 급격한 변화에는 Step Scaling 사용
• 여러 정책 동시 사용 시 충돌 주의

---

5. 예약 스케일링

김개발 씨는 이제 실시간 스케일링은 마스터했습니다. 하지만 마케팅팀에서 연락이 왔습니다.

"다음 주 월요일 오후 8시에 TV 광고가 나갑니다. 트래픽 폭증 예상되니 대비해주세요." 미리 준비할 방법이 있을까요?

Scheduled Scaling은 특정 시간에 미리 서버를 늘리거나 줄이는 정책입니다. 마치 에어컨 타이머로 퇴근 30분 전에 미리 켜두는 것처럼, 트래픽이 오기 전에 서버를 준비합니다.

Cron 표현식으로 반복 일정을 설정할 수 있고, 일회성 이벤트에도 사용합니다. 예측 가능한 트래픽 패턴에 최적화되어 있습니다.

다음 코드를 살펴봅시다.

import boto3
from datetime import datetime, timezone

client = boto3.client('application-autoscaling')

# 특정 시간에 태스크를 10개로 증가 (일회성)
response = client.put_scheduled_action(
    ServiceNamespace='ecs',
    ScheduledActionName='scale-up-for-tv-ad',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    Schedule='at(2025-12-27T12:00:00)',  # UTC 시간
    ScalableTargetAction={
        'MinCapacity': 10,
        'MaxCapacity': 20
    }
)

# 매일 오전 9시에 반복 (Cron)
response2 = client.put_scheduled_action(
    ServiceNamespace='ecs',
    ScheduledActionName='morning-scale-up',
    ResourceId='service/my-cluster/my-service',
    ScalableDimension='ecs:service:DesiredCount',
    Schedule='cron(0 9 * * ? *)',  # 매일 오전 9시 UTC
    ScalableTargetAction={'MinCapacity': 5}
)

김개발 씨는 고민에 빠졌습니다. TV 광고는 오후 8시 정각에 나가는데, 그때 갑자기 트래픽이 몰리면 Target Tracking이 반응하기까지 시간이 걸립니다.

첫 몇 분간 사용자들은 느린 서비스를 경험하게 될 것입니다. 박시니어 씨가 해결책을 제시합니다.

"이럴 때는 Scheduled Scaling을 쓰세요. 오후 7시 50분에 미리 서버를 10대로 늘려두는 거예요." Scheduled Scaling이란 무엇일까요? 쉽게 비유하자면, Scheduled Scaling은 마치 빵집 주인이 아침 오픈 전에 미리 빵을 구워두는 것과 같습니다.

손님이 오는 시간을 알고 있으니, 미리 준비해서 기다리는 것이지요. 마찬가지로 트래픽이 증가할 시간을 알고 있다면, 미리 서버를 늘려서 콜드 스타트 지연을 없앨 수 있습니다.

왜 예약 스케일링이 필요할까요? 실시간 스케일링은 훌륭하지만 반응성에 한계가 있습니다. CPU가 올라가고, CloudWatch가 감지하고, 알람이 발생하고, 새 태스크가 시작되고, 헬스체크를 통과하는 데까지 2-3분이 걸립니다.

갑작스러운 트래픽 폭증 시 이 시간 동안 사용자는 오류를 경험할 수 있습니다. 김개발 씨가 지난달에 겪은 일입니다.

유명 유튜버가 자사 서비스를 소개하면서 순식간에 동시 접속자가 100배로 늘었습니다. 오토스케일링이 작동하긴 했지만, 처음 5분간은 서버가 거의 다운 상태였습니다.

많은 사용자가 "접속 안 된다"며 떠나버렸습니다. Scheduled Scaling의 장점은 무엇일까요? 첫째, 지연 시간 제로입니다.

트래픽이 오기 전에 이미 서버가 준비되어 있습니다. 둘째, 비용 예측이 가능합니다.

언제 서버가 몇 대 돌아가는지 정확히 알 수 있어서 예산 계획을 세우기 쉽습니다. 셋째, 복합 전략이 가능합니다.

예약 스케일링으로 기본 용량을 확보하고, Target Tracking으로 추가 조절을 하는 식입니다. 코드를 단계별로 살펴보겠습니다. 첫 번째 예제는 일회성 이벤트입니다.

Schedule='at(2025-12-27T12:00:00)'은 특정 시점을 지정하는 문법입니다. UTC 시간이므로 한국 시간(KST)으로 환산해야 합니다.

한국은 UTC+9이므로, 오후 8시를 원하면 12:00:00 UTC를 입력합니다. ScalableTargetAction에서 MinCapacity=10은 최소 용량을 10으로 변경한다는 의미입니다.

이렇게 하면 무조건 10개 이상의 태스크가 유지됩니다. MaxCapacity=20도 함께 설정하면 10-20개 범위에서 추가 스케일링이 가능합니다.

두 번째 예제는 반복 일정입니다. `Schedule='cron(0 9 * * ?

)'은 매일 오전 9시(UTC)에 실행된다는 의미입니다. Cron 표현식은 분 시 일 월 요일 연도순서이며,는 모든 값, ?`는 해당 없음을 의미합니다.

실무 활용 사례를 들어보겠습니다. 교육 서비스를 운영한다고 가정합시다. 학생들은 주로 평일 저녁 7-10시에 접속합니다.

이 패턴은 매우 규칙적입니다. 그렇다면: - 오후 6시 50분: 최소 용량을 10으로 증가 - 오후 10시 30분: 최소 용량을 2로 감소 이렇게 예약해두면 비용을 절감하면서도 피크 시간대에 안정적인 서비스를 제공할 수 있습니다.

또 다른 예로, 주말에만 사용되는 배달 서비스라면: - 금요일 오후 5시: 최소 용량 10으로 증가 - 월요일 오전 1시: 최소 용량 1로 감소 주의사항이 있습니다. 시간대를 반드시 확인하세요. AWS Scheduled Scaling은 UTC 기준입니다.

한국 시간(KST)은 UTC+9이므로, 한국 시간 오후 8시는 UTC 오전 11시입니다. 잘못 설정하면 한밤중에 서버가 늘어나는 황당한 상황이 발생합니다.

또한 스케일 다운도 예약해야 합니다. 스케일 업만 하고 다운을 안 하면 이벤트가 끝나도 서버가 계속 많이 돌아가서 비용이 폭탄처럼 나올 수 있습니다.

항상 쌍으로 설정하세요. 김개발 씨가 예약을 설정했습니다. TV 광고 10분 전인 오후 7시 50분에 서버를 10대로 늘리고, 2시간 후인 오후 10시에 다시 3대로 줄이도록 설정했습니다.

광고 당일, 트래픽이 몰렸지만 서비스는 안정적으로 작동했습니다. "역시 미리 준비하는 게 최고네요!" Scheduled Scaling을 잘 활용하면 예측 가능한 트래픽 패턴에 완벽하게 대응할 수 있습니다.

특히 마케팅 이벤트에 필수입니다.

실전 팁

💡 - UTC와 KST 시간대 차이 주의 (UTC+9)

• 스케일 업/다운을 쌍으로 예약
• Cron 표현식 테스트 후 적용

---

6. 스케일링 테스트

모든 설정을 완료한 김개발 씨. 하지만 박시니어 씨가 마지막 조언을 합니다.

"설정만 하고 끝이 아니에요. 실제로 잘 작동하는지 테스트해봐야죠.

부하 테스트를 해볼까요?"

스케일링 테스트는 설정이 제대로 작동하는지 검증하는 과정입니다. 마치 소방 훈련처럼, 실제 상황이 오기 전에 미리 연습해보는 것입니다.

부하 테스트 도구(Apache Bench, JMeter, Locust)로 인위적인 트래픽을 발생시키고, CloudWatch 메트릭과 ECS 태스크 수 변화를 모니터링합니다. 테스트를 통해 임계값, 쿨다운 시간 등을 최적화할 수 있습니다.

다음 코드를 살펴봅시다.

# Apache Bench로 간단한 부하 테스트
# 동시 접속 100명, 총 10,000번 요청
ab -n 10000 -c 100 http://your-service-url/

# Python으로 CloudWatch 메트릭 확인
import boto3
from datetime import datetime, timedelta

cloudwatch = boto3.client('cloudwatch')

# 최근 30분간 CPU 사용률 조회
response = cloudwatch.get_metric_statistics(
    Namespace='AWS/ECS',
    MetricName='CPUUtilization',
    Dimensions=[
        {'Name': 'ServiceName', 'Value': 'my-service'},
        {'Name': 'ClusterName', 'Value': 'my-cluster'}
    ],
    StartTime=datetime.now() - timedelta(minutes=30),
    EndTime=datetime.now(),
    Period=60,  # 1분 단위
    Statistics=['Average']
)

for point in response['Datapoints']:
    print(f"{point['Timestamp']}: {point['Average']:.2f}%")

김개발 씨는 모든 설정을 완료했습니다. Target Tracking 정책도 만들었고, Scheduled Scaling도 예약했습니다.

이제 끝일까요? 아닙니다.

실제로 작동하는지 확인해야 합니다. 박시니어 씨가 터미널을 열며 말합니다.

"자, 이제 부하를 걸어서 정말로 태스크가 늘어나는지 확인해봅시다. 설정이 잘못되어 있으면 실전에서 큰일 나거든요." 스케일링 테스트란 무엇일까요? 쉽게 비유하자면, 스케일링 테스트는 마치 소방 훈련과 같습니다.

화재 경보기를 설치만 하고 테스트하지 않으면, 실제 화재 때 작동하지 않을 수 있습니다. 마찬가지로 오토스케일링 설정을 만들었다면, 실제 트래픽 폭증 전에 모의 훈련을 해봐야 합니다.

테스트를 안 하면 어떻게 될까요? 실전에서 문제가 터집니다. 김개발 씨도 처음에는 테스트를 건너뛰었습니다.

"설정했으니까 당연히 작동하겠지" 하고 안심했지요. 그런데 실제 이벤트 때 오토스케일링이 작동하지 않았습니다.

알고 보니 IAM 역할 권한이 잘못되어 있었습니다. 사용자들은 접속 오류를 경험했고, 김개발 씨는 급하게 수동으로 서버를 늘렸습니다.

만약 미리 테스트했다면 이런 문제를 사전에 발견하고 수정할 수 있었을 것입니다. 부하 테스트는 어떻게 할까요? 가장 간단한 도구는 Apache Bench(ab)입니다.

대부분의 리눅스 시스템에 기본으로 설치되어 있습니다. ab -n 10000 -c 100은 동시 접속자 100명이 총 10,000번 요청을 보내는 시뮬레이션입니다.

더 정교한 테스트가 필요하면 JMeter나 Locust 같은 도구를 사용합니다. 이들은 시나리오 기반 테스트, 점진적 부하 증가, 실시간 그래프 등 다양한 기능을 제공합니다.

코드를 단계별로 살펴보겠습니다. Apache Bench 명령은 매우 간단합니다. -n은 총 요청 수, -c는 동시 접속자 수입니다.

서비스 URL을 입력하면 즉시 부하가 발생합니다. CPU가 올라가는 것을 CloudWatch에서 실시간으로 확인할 수 있습니다.

Python 코드는 CloudWatch 메트릭을 조회하는 방법을 보여줍니다. get_metric_statistics 메서드로 특정 기간 동안의 CPU 사용률을 가져올 수 있습니다.

Period=60은 1분 단위 집계를 의미하며, Statistics=['Average']는 평균값을 보겠다는 뜻입니다. 이 데이터를 그래프로 그리면 부하 테스트 중 CPU 변화와 태스크 증가 시점을 시각적으로 확인할 수 있습니다.

실제 테스트 시나리오를 예로 들어보겠습니다. 김개발 씨는 다음과 같은 순서로 테스트했습니다:

---

7. 5분 후 태스크 감소 확인: 4개 → 2개

실전 팁

💡 - 프로덕션이 아닌 개발 환경에서 먼저 테스트

• CloudWatch 메트릭과 태스크 수를 동시에 모니터링
• 테스트 후 비용 확인 및 리소스 정리 필수

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!