오토 스케일링(Auto Scaling) - 서버비 60% 절감의 비밀 (feat. AWS, K8s)

1. 프롤로그 - 낮에는 터지고, 밤에는 노는 서버

클라우드 서버를 처음 쓰다 보면 흔히 이런 상황을 겪습니다. 점심시간(12:00~13:00)에 트래픽이 평소보다 10배 이상 폭발하는데, 새벽엔 사용자가 거의 없는 서비스. "점심시간을 무조건 버티자!"는 생각에 고사양 서버 10대를 24시간 내내 켜두면 어떻게 될까요?

결과는 어땠을까요? 점심시간은 무사히 넘깁니다. 쾌적하죠. 하지만 문제는 새벽 3시입니다. 사용자가 거의 없는 그 시간에도 비싼 서버 10대는 전기세를 펑펑 쓰며 맹렬하게 돌아가고 있습니다.

클라우드 비용이 예상보다 많이 나오는 사례가 흔합니다. 이런 식으로 트래픽과 무관하게 서버를 과잉 provisioning 해두면, 비용이 매출을 훌쩍 넘겨버리는 상황도 생깁니다.

저는 이 패턴을 공부하면서 깨달았습니다. "트래픽은 파도처럼 출렁이는데, 서버는 벽돌처럼 고정되어 있으면 돈을 바닥에 버리는 거구나." 이 문제를 해결해준 구세주가 바로 오토 스케일링(Auto Scaling)이었습니다.

2. 처음엔 뭐가 이해가 안 갔나

처음 오토 스케일링을 공부할 때 가장 막막했던 질문들은 다음과 같습니다.

• "도대체 언제 늘리고 언제 줄여야 해?" (CPU 50%? 80%? 기준이 뭐야?)
• "서버가 켜지는 데 5분은 걸릴 텐데, 그 사이 몰려든 사용자는 어떡하지?" (Warm-up 시간)
• "갑자기 늘었다가 1분 뒤에 줄면(Flapping) 서버가 껐다 켜졌다 난리 나는 거 아냐?"

단순히 "자동으로 늘어난다"는 개념은 알겠는데, "어떻게 설정해야 사고가 안 나는지"에 대한 실제적인 감(Intuition)이 전혀 없었습니다.

3. 어떤 포인트에서 이해가 됐나

이 개념을 가장 잘 설명해준 비유는 "카카오택시 배차 시스템"이었습니다.

상황 1 - 고정 배차 (기존 방식)

• 회사에서 택시 100대를 월급 주고 고용합니다.
• 새벽: 손님은 10명인데 택시 90대가 놀고 있음. (비용 낭비)
• 출근길: 손님은 500명인데 택시가 100대뿐이라 400명이 욕함. (서비스 장애)

상황 2 - 오토 스케일링 (탄력 배차)

• 중앙 센터에서 실시간으로 수요를 모니터링합니다.
• 손님이 늘어나면: "지금 강남역에 손님 많다! 대기 중인 택시 50대 추가 투입!" (Scale Out)
• 손님이 줄어들면: "이제 손님 없다. 50대는 퇴근해라." (Scale In)

이러면 택시 회사는 필요한 만큼만 기사님 월급을 주면 되고, 손님은 기다릴 필요가 없습니다. 클라우드(Cloud)의 핵심 가치가 바로 이 "쓴 만큼만 낸다(Pay-as-you-go)"에 있으며, 오토 스케일링은 그 가치를 실현하는 도구입니다.

4. 깊게 파고들기 - 3가지 핵심 질문과 전략

질문 1 - 무엇을 기준으로 스케일링 할 것인가? (Scaling Metric)

1. CPU 사용률 (가장 기본)
   • "평균 CPU가 70% 넘으면 서버 한 대 더 띄워!"
   • 컴퓨팅 연산이 많은 서비스에 적합합니다.
2. 메모리 사용률
   • 이미지 처리나 데이터 분석처럼 메모리를 많이 먹는 작업에 적합합니다.
3. 요청 수 (Target Tracking)
   • 가장 정확하고 현대적입니다. "로드 밸런서(ALB)로 들어오는 요청이 인스턴스 당 1000건 넘으면 늘려!"
   • AWS에서는 이것을 Target Tracking Policy라고 부릅니다. "난 그냥 CPU 50% 유지하고 싶어"라고 하면 알아서 늘리고 줄입니다.

질문 2 - 서버가 뜨는 시간을 어떻게 버티나? (Provisioning Time)

서버(EC2)가 부팅되고 애플리케이션(Java/Node)이 실행되는 데 보통 3~5분이 걸립니다. 트래픽은 1초 만에 폭등하는데 5분을 기다리면 서버는 이미 터져있겠죠?

• 해결책 1: 여유분(Buffer) 두기: CPU 70%가 아니라 40~50%만 돼도 미리 늘리기 시작합니다. 조금 낭비하더라도 안전이 우선입니다.
• 해결책 2: 예측 스케일링(Predictive Scaling): 매일 점심시간 11시 50분에 예약 스케일링(Scheduled Action)을 걸어둡니다. "11시 50분에는 무조건 10대로 늘려놔"라고요.

질문 3: Scale Up vs Scale Out?

• Scale Up (수직 확장): 서버의 체급을 키우는 것. (CPU 2코어 -> 4코어). 서버를 껐다 켜야 해서 다운타임이 발생합니다. DB 확장에 주로 쓰입니다.
• Scale Out (수평 확장): 서버의 개수를 늘리는 것. (1대 -> 10대). 무중단 확장이 가능합니다. 오토 스케일링은 기본적으로 Scale Out 방식입니다.

5. 서버리스(Serverless)는 뭔가요? (feat. 피자 배달)

여기서 한 발 더 나아가면 아예 "서버 관리 자체를 안 하는" 서버리스(AWS Lambda)가 있습니다. 오토 스케일링과 서버리스의 차이는 "택시 회사 vs 피자 배달"입니다.

1. EC2 오토 스케일링 (택시 회사): 택시 기사를 고용해야 합니다. 손님이 없어도 최소 1~2명은 대기시켜야 합니다(Minimum Size). 기사가 출근하는 데 시간(Boot Time)이 걸립니다.
2. 서버리스 (배달 대행): 기사를 고용하지 않습니다. 배달 건당 수수료만 냅니다.
   • 요청 0개: 비용 0원.
   • 요청 1000개: 순식간에 배달원 1000명이 투입됩니다.
   • 관리: 필요 없습니다.

"와! 그럼 무조건 서버리스가 좋네요?" 꼭 그렇지는 않습니다. Cold Start(첫 실행 딜레이) 문제와, 24시간 내내 돌릴 경우 EC2보다 비싼 비용 구조 때문입니다. 간헐적으로 폭발하는 트래픽에는 서버리스가 최고고, 꾸준한 베이스 트래픽에는 EC2 오토 스케일링이 가성비가 좋습니다.

6. 실제 설정 - Kubernetes HPA와 쿨다운

요즘은 쿠버네티스(Kubernetes)를 많이 쓰니 HPA(Horizontal Pod Autoscaler)로 정리해봤습니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: backend-api-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: backend-api
  minReplicas: 2   # 최소 2대는 항상 유지 (새벽에도 죽지 않게)
  maxReplicas: 10  # 최대 10대까지만 (비용 폭탄 방지)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 60  # CPU가 60% 넘으면 늘려라!

주의할 점 (Cool-down / Stabilization Window): 한 번 늘렸으면 바로 줄이지 말고 좀 기다려야 합니다. 1분 만에 늘렸다가 사용자가 잠깐 줄었다고 바로 서버를 끄면, 다시 늘어날 때 대응을 못 합니다. 이를 Thundering Herd 문제나 Flapping 현상이라고 합니다. 보통 scaleDownStabilizationWindow를 5분 정도로 주어, "트래픽이 줄어도 5분간은 지켜보다가 진짜 줄면 꺼라"라고 설정합니다.

7. 비용 절감의 끝판왕 - 스팟 인스턴스(Spot Instances)

오토 스케일링으로 늘어나는 서버들은 굳이 비싼 '온디맨드(On-Demand)'를 쓸 필요가 없습니다. AWS의 '남는 서버'를 경매 방식으로 싸게 빌려 쓰는 스팟 인스턴스를 섞어 쓰면 비용을 최대 90%까지 더 줄일 수 있습니다.

• 기본 2대: 온디맨드 (절대 죽으면 안 됨)
• 추가 8대: 스팟 인스턴스 (잠깐 꺼져도 다른 스팟으로 대체하면 됨)

이 조합(Mixed Instances Policy)이 스타트업 인프라 비용 절감의 핵심 비기입니다.

8. 적용 후 변화 및 요약

오토 스케일링을 제대로 적용하면 이런 변화가 생깁니다.

1. 비용 절감: 과잉 프로비저닝 대비 서버비를 60% 이상 줄일 수 있습니다. 실제로 이런 사례가 많이 보고됩니다.
2. 수면권 보장: 새벽에 트래픽이 튀어도, 서버가 죽어도(알아서 다시 뜸), 개발자는 꿀잠을 잡니다.
3. 장애 감소: 점심시간 트래픽 폭주에도 서버가 유연하게 대처해서 502 에러가 줄어듭니다.

핵심 요약:

1. Scale Out: 서버의 개수를 늘려서 트래픽을 감당해라.
2. Buffer: 서버 뜨는 시간(3~5분)을 고려해서 미리미리 늘려라.
3. Spot Instances: 늘어나는 서버는 싼 걸 써라.

"서버 한 대를 1년 내내 켜두는 것"은 집에 아무도 없는데 에어컨을 풀가동하는 것과 같습니다. 이제 스마트하게, 필요한 만큼만 씁시다.