오토스케일링 완벽 가이드

트래픽 변화에 자동으로 대응하는 오토스케일링의 모든 것을 배웁니다. HPA, VPA, Cluster Autoscaler까지 실전 예제와 함께 쉽게 설명합니다. 초급 개발자도 술술 읽히는 실무 중심 가이드입니다.

1. HPA 개념

어느 날 김개발 씨가 출근하자마자 급한 전화를 받았습니다. "우리 서비스가 다운됐어요!" 밤사이 갑자기 트래픽이 몰려서 서버가 감당하지 못한 것입니다.

박시니어 씨가 다가와 말했습니다. "오토스케일링을 설정했어야 했는데..."

**HPA(Horizontal Pod Autoscaler)**는 트래픽 변화에 따라 파드의 개수를 자동으로 늘리거나 줄이는 기능입니다. 마치 식당에서 손님이 많아지면 직원을 더 투입하고, 한가해지면 줄이는 것과 같습니다.

CPU 사용률, 메모리, 커스텀 메트릭을 기준으로 스케일링을 수행합니다.

다음 코드를 살펴봅시다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: web-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: web-app
  minReplicas: 2  # 최소 파드 개수
  maxReplicas: 10  # 최대 파드 개수
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # CPU 70% 초과 시 스케일 아웃

김개발 씨는 입사 3개월 차 백엔드 개발자입니다. 처음으로 맡은 서비스가 성공적으로 오픈했는데, 예상보다 훨씬 많은 사용자가 몰려들었습니다.

새벽 2시, 장애 알람이 울렸습니다. 서버가 과부하로 다운된 것입니다.

다음 날 출근하자마자 박시니어 씨가 김개발 씨를 불렀습니다. "어젯밤 고생 많았죠?

사실 이런 상황을 대비해서 오토스케일링이라는 게 있어요." 그렇다면 오토스케일링이란 정확히 무엇일까요? 쉽게 비유하자면, 오토스케일링은 마치 백화점 계산대와 같습니다.

평일 오전에는 계산대 2개만 열어두지만, 주말 저녁이나 세일 기간에는 계산대를 10개까지 열어서 고객을 빠르게 처리합니다. 손님이 줄어들면 다시 계산대를 줄입니다.

이처럼 오토스케일링도 트래픽 변화에 맞춰 서버 자원을 자동으로 조절하는 역할을 담당합니다. 오토스케일링이 없던 시절에는 어땠을까요?

개발자들은 트래픽을 예측해서 미리 서버를 충분히 띄워놓아야 했습니다. 문제는 예측이 빗나가는 경우가 많았다는 점입니다.

서버를 너무 적게 띄우면 장애가 발생하고, 너무 많이 띄우면 비용이 낭비됩니다. 더 큰 문제는 새벽 시간대처럼 트래픽이 급변하는 상황에서 개발자가 일일이 서버를 늘렸다 줄였다 해야 한다는 점이었습니다.

바로 이런 문제를 해결하기 위해 HPA가 등장했습니다. HPA를 사용하면 트래픽 증가 시 자동으로 파드가 추가됩니다.

또한 트래픽 감소 시 불필요한 파드를 제거해서 비용을 절감할 수 있습니다. 무엇보다 24시간 자동으로 관리되어 개발자가 잠을 잘 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. 먼저 scaleTargetRef 부분에서는 어떤 Deployment를 스케일링할지 지정합니다.

여기서는 web-app이라는 이름의 Deployment를 대상으로 합니다. 다음으로 minReplicas와 maxReplicas에서는 파드의 최소/최대 개수를 설정합니다.

최소 2개는 항상 유지하고, 최대 10개까지 늘어날 수 있습니다. 가장 중요한 부분은 metrics입니다.

여기서는 CPU 사용률을 기준으로 스케일링합니다. averageUtilization: 70은 평균 CPU 사용률이 70%를 넘으면 파드를 추가한다는 의미입니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다.

평소에는 파드 3개로 충분하지만, 점심시간이나 저녁시간에는 트래픽이 3배 증가합니다. HPA를 설정하면 자동으로 파드가 9개까지 늘어나서 빠른 응답속도를 유지합니다.

트래픽이 줄어들면 다시 3개로 줄어들어 비용을 절감합니다. 쿠팡, 배달의민족 같은 대형 서비스에서 이런 패턴을 적극적으로 사용하고 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 너무 낮은 CPU 임계값을 설정하는 것입니다.

예를 들어 CPU 30%에 스케일 아웃을 설정하면, 조금만 부하가 생겨도 파드가 불필요하게 늘어나서 비용이 낭비됩니다. 따라서 실제 트래픽 패턴을 분석한 후 적절한 임계값을 설정해야 합니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다.

"아, 그래서 자동으로 서버가 늘어나는 거군요!" HPA를 제대로 이해하면 안정적이고 비용 효율적인 서비스를 운영할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요.

실전 팁

💡 - CPU 임계값은 보통 60-80% 사이가 적절합니다

최소 파드는 2개 이상으로 설정해서 고가용성을 확보하세요
스케일 아웃 후 안정화 시간(cooldown)을 고려하세요

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

HPA를 적용한 김개발 씨의 서비스는 안정적으로 운영되는 듯 보였습니다. 하지만 며칠 후 다시 문제가 발생했습니다.

CPU는 50%밖에 안 쓰는데 메모리가 가득 차서 파드가 죽는 것입니다. 박시니어 씨가 말했습니다.

"CPU만 보면 안 돼요. 메모리도 함께 고려해야 합니다."

CPU와 메모리를 동시에 모니터링하는 멀티 메트릭 스케일링은 더 정교한 오토스케일링을 가능하게 합니다. CPU는 여유가 있어도 메모리가 부족하면 스케일 아웃이 필요합니다.

두 가지 메트릭 중 하나라도 임계값을 넘으면 스케일링이 동작합니다.

다음 코드를 살펴봅시다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: multi-metric-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 3
  maxReplicas: 15
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # CPU 70% 기준
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 80  # 메모리 80% 기준

김개발 씨는 HPA를 적용한 후 한결 마음이 편해졌습니다. 트래픽이 몰려도 자동으로 파드가 늘어나니까요.

하지만 1주일 후, 이상한 현상이 발생했습니다. CPU 사용률은 50%밖에 안 되는데 파드가 갑자기 재시작되는 것입니다.

로그를 확인해보니 OOMKilled(Out Of Memory Killed) 에러가 찍혀 있었습니다. 메모리가 부족해서 쿠버네티스가 파드를 강제로 종료시킨 것입니다.

박시니어 씨에게 물어보니 이렇게 답했습니다. "CPU만 보고 스케일링하면 이런 일이 생길 수 있어요." 그렇다면 왜 CPU만으로는 부족한 걸까요?

쉽게 비유하자면, 사람에게 필요한 영양소가 탄수화물만 있는 게 아니듯, 서버도 CPU만 중요한 게 아닙니다. 어떤 애플리케이션은 CPU를 많이 쓰고(예: 동영상 인코딩), 어떤 애플리케이션은 메모리를 많이 씁니다(예: 캐싱 서버, 대용량 데이터 처리).

만약 메모리를 많이 쓰는 애플리케이션에서 CPU만 모니터링하면, 메모리가 가득 차도 스케일 아웃이 일어나지 않습니다. CPU만 보던 시절에는 어땠을까요?

개발자들은 메모리 부족 장애를 겪고 나서야 문제를 발견했습니다. 그때는 이미 서비스가 다운된 후였습니다.

메모리 사용률을 따로 모니터링하고, 임계값에 도달하면 수동으로 파드를 늘려야 했습니다. 새벽에 메모리 알람이 울리면 개발자가 일어나서 kubectl 명령어로 파드를 추가하는 일이 잦았습니다.

바로 이런 문제를 해결하기 위해 멀티 메트릭 스케일링이 등장했습니다. 멀티 메트릭 스케일링을 사용하면 CPU와 메모리를 동시에 모니터링할 수 있습니다.

또한 둘 중 하나라도 임계값을 넘으면 자동으로 스케일 아웃됩니다. 무엇보다 각 리소스의 특성에 맞는 임계값을 따로 설정할 수 있다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. metrics 배열에 두 개의 메트릭이 정의되어 있습니다.

첫 번째는 CPU로 70%를 임계값으로 설정했고, 두 번째는 메모리로 80%를 임계값으로 설정했습니다. HPA는 이 두 메트릭을 모두 확인하면서 스케일링 여부를 결정합니다.

중요한 점은 OR 조건으로 동작한다는 것입니다. CPU가 70%를 넘거나 메모리가 80%를 넘으면 스케일 아웃이 발생합니다.

둘 다 임계값을 넘을 필요는 없습니다. 이렇게 하면 어떤 리소스가 먼저 부족해지든 대응할 수 있습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 이미지 처리 API를 개발한다고 가정해봅시다.

이미지를 업로드하면 서버 메모리에 이미지를 올려놓고 리사이징 작업을 합니다. 이 과정에서 메모리 사용량이 급증하지만 CPU는 그리 높지 않을 수 있습니다.

만약 CPU만 모니터링하면 메모리 부족으로 장애가 발생합니다. 하지만 멀티 메트릭 스케일링을 사용하면 메모리가 80%에 도달하는 순간 파드가 추가되어 안정적인 서비스가 가능합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 메모리 임계값을 CPU와 동일하게 설정하는 것입니다.

하지만 메모리는 CPU와 다르게 한 번 차면 줄어들지 않는 특성이 있습니다. 따라서 메모리 임계값은 CPU보다 조금 더 높게(70-85%) 설정하는 것이 좋습니다.

너무 낮게 설정하면 불필요한 스케일 아웃이 자주 발생합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

멀티 메트릭 스케일링을 적용한 후, 메모리 부족 장애는 완전히 사라졌습니다. "이제야 안심하고 퇴근할 수 있겠어요!" CPU와 메모리를 함께 고려하면 훨씬 안정적인 서비스 운영이 가능합니다.

여러분도 애플리케이션의 특성을 파악해서 적절한 메트릭을 설정해 보세요.

실전 팁

💡 - 메모리 임계값은 보통 75-85% 사이가 적절합니다

애플리케이션의 메모리 사용 패턴을 먼저 분석하세요
request와 limit을 명확히 설정해야 정확한 사용률 계산이 가능합니다

3. 커스텀 메트릭 스케일링

서비스가 안정화되자 김개발 씨는 새로운 고민에 빠졌습니다. 동영상 인코딩 서비스인데, CPU와 메모리는 여유가 있어도 인코딩 대기 큐에 작업이 쌓이면 사용자는 오래 기다려야 합니다.

박시니어 씨가 조언했습니다. "큐 길이를 기준으로 스케일링하면 어떨까요?"

커스텀 메트릭 스케일링은 CPU, 메모리 외에 비즈니스 로직에 맞는 지표를 기준으로 스케일링합니다. 메시지 큐 길이, API 응답 시간, 데이터베이스 커넥션 수 등 다양한 메트릭을 활용할 수 있습니다.

Prometheus 같은 모니터링 도구와 연동하여 사용합니다.

다음 코드를 살펴봅시다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: custom-metric-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: video-encoder
  minReplicas: 2
  maxReplicas: 20
  metrics:
  - type: Pods
    pods:
      metric:
        name: queue_length  # Prometheus에서 수집한 커스텀 메트릭
      target:
        type: AverageValue
        averageValue: "30"  # 파드당 평균 큐 길이 30개 초과 시 스케일 아웃
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60  # 1분 동안 관찰 후 스케일 아웃

김개발 씨의 팀은 동영상 인코딩 서비스를 운영하고 있습니다. 사용자가 동영상을 업로드하면 여러 해상도로 변환하는 작업을 처리합니다.

CPU와 메모리 기반 스케일링을 적용했지만, 여전히 문제가 있었습니다. 오후 6시쯤 되면 사용자들이 대량으로 동영상을 업로드합니다.

작업이 큐에 쌓이기 시작하는데, CPU와 메모리는 아직 70%도 안 됩니다. 스케일 아웃이 일어나지 않아서 사용자들은 10분 이상 기다려야 합니다.

박시니어 씨가 모니터링 대시보드를 보며 말했습니다. "CPU가 아니라 큐 길이를 봐야 해요." 그렇다면 커스텀 메트릭이란 무엇일까요?

쉽게 비유하자면, 은행 창구를 생각해봅시다. 직원들이 쉬고 있어도(CPU 여유) 대기 줄에 손님이 20명 넘게 서 있다면 창구를 더 열어야 합니다.

직원의 바쁜 정도가 아니라 대기 줄의 길이가 중요한 것입니다. 마찬가지로 커스텀 메트릭은 CPU, 메모리 같은 시스템 지표가 아니라 비즈니스 상황을 직접 반영하는 지표로 스케일링합니다.

커스텀 메트릭이 없던 시절에는 어땠을까요? 개발자들은 큐 길이를 직접 모니터링하다가 임계값을 넘으면 수동으로 파드를 늘렸습니다.

하지만 큐 길이는 갑자기 증가하는 경우가 많아서 대응이 늦어지기 일쑤였습니다. 또한 CPU는 여유가 있는데 큐만 길어지는 상황에서는 CPU 기반 스케일링이 전혀 도움이 되지 않았습니다.

결국 사용자 불만이 쌓이고 서비스 품질이 떨어졌습니다. 바로 이런 문제를 해결하기 위해 커스텀 메트릭 스케일링이 등장했습니다.

커스텀 메트릭을 사용하면 비즈니스 로직에 딱 맞는 스케일링이 가능합니다. 또한 사용자 경험을 직접 개선할 수 있습니다.

무엇보다 다양한 서비스 상황에 유연하게 대응할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다.

type: Pods는 파드별 메트릭을 기준으로 한다는 의미입니다. metric.name: queue_length는 Prometheus에서 수집하는 커스텀 메트릭 이름입니다.

이 메트릭은 애플리케이션이 직접 노출해야 합니다. averageValue: "30"은 파드당 평균 큐 길이가 30개를 넘으면 스케일 아웃한다는 뜻입니다.

만약 파드가 5개이고 전체 큐 길이가 200개라면, 파드당 평균은 40개이므로 스케일 아웃이 발생합니다. behavior.scaleUp.stabilizationWindowSeconds는 너무 빠른 스케일 아웃을 방지합니다.

1분 동안 메트릭을 관찰한 후 스케일 아웃 여부를 결정합니다. 이렇게 하면 일시적인 트래픽 스파이크에 과도하게 반응하지 않습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 주식 거래 시스템을 개발한다고 가정해봅시다.

장 시작 시간에는 주문이 폭증합니다. 이때 중요한 것은 CPU가 아니라 주문 처리 대기 시간입니다.

주문이 큐에 5초 이상 쌓이면 사용자는 불안해합니다. 따라서 평균 대기 시간을 커스텀 메트릭으로 설정하고, 3초를 넘으면 스케일 아웃하도록 구성합니다.

네이버페이, 카카오페이 같은 금융 서비스에서 이런 패턴을 사용합니다. 커스텀 메트릭을 사용하려면 어떻게 해야 할까요?

먼저 애플리케이션이 메트릭을 노출해야 합니다. Python에서는 prometheus_client 라이브러리를 사용합니다.

큐 길이를 Gauge 메트릭으로 등록하고 주기적으로 업데이트합니다. 그러면 Prometheus가 이 메트릭을 수집하고, Kubernetes Metrics Server가 HPA에 제공합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 메트릭 이름을 잘못 설정하는 것입니다.

HPA의 metric.name과 Prometheus에서 수집하는 메트릭 이름이 정확히 일치해야 합니다. 하나라도 오타가 있으면 메트릭을 찾지 못해서 스케일링이 동작하지 않습니다.

또한 메트릭 업데이트 주기도 중요합니다. 너무 느리게 업데이트하면 스케일링 반응이 느려집니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 큐 길이 기반 스케일링을 적용한 후, 사용자 대기 시간이 10분에서 1분으로 줄었습니다.

"이제 진짜 똑똑한 오토스케일링이네요!" 커스텀 메트릭을 활용하면 비즈니스 요구사항에 딱 맞는 스케일링 전략을 구현할 수 있습니다. 여러분도 서비스의 핵심 지표를 파악해서 커스텀 메트릭을 만들어 보세요.

실전 팁

💡 - 커스텀 메트릭은 Prometheus Adapter를 통해 HPA에 연동됩니다

메트릭 이름 규칙을 명확히 정하고 문서화하세요
stabilizationWindow를 설정해서 급격한 스케일 변동을 방지하세요

4. VPA 개념

커스텀 메트릭까지 적용한 김개발 씨는 뿌듯했습니다. 하지만 새로운 문제가 생겼습니다.

파드마다 필요한 CPU, 메모리가 다른데 일괄적으로 설정하다 보니 어떤 파드는 리소스가 남고, 어떤 파드는 부족합니다. 박시니어 씨가 말했습니다.

"파드 개수가 아니라 파드 크기를 조절하는 VPA를 알아볼까요?"

**VPA(Vertical Pod Autoscaler)**는 파드의 개수가 아니라 파드의 리소스 크기(CPU, 메모리 request/limit)를 자동으로 조절합니다. 실제 사용량을 분석해서 적절한 리소스를 추천하고 자동 적용합니다.

HPA가 수평 확장이라면 VPA는 수직 확장입니다.

다음 코드를 살펴봅시다.

apiVersion: autoscaling.k8s.io/v1
kind: VerticalPodAutoscaler
metadata:
  name: api-server-vpa
spec:
  targetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  updatePolicy:
    updateMode: "Auto"  # 자동으로 파드 재시작하며 리소스 조정
  resourcePolicy:
    containerPolicies:
    - containerName: api-container
      minAllowed:
        cpu: 100m
        memory: 128Mi
      maxAllowed:
        cpu: 2000m  # 최대 2 CPU까지
        memory: 2Gi  # 최대 2GB까지

김개발 씨는 오토스케일링의 달인이 되어가고 있었습니다. HPA로 파드 개수를 조절하고, 커스텀 메트릭으로 비즈니스 로직에 맞게 스케일링했습니다.

하지만 여전히 찝찝한 부분이 있었습니다. 어떤 파드는 CPU를 500m만 써도 충분한데 1000m를 할당해서 낭비되고, 어떤 파드는 2000m가 필요한데 1000m만 할당되어 성능이 느렸습니다.

모든 파드에 동일한 리소스를 설정했기 때문입니다. 박시니어 씨가 물었습니다.

"파드마다 필요한 리소스가 다르다는 걸 알고 있나요?" 그렇다면 VPA는 HPA와 무엇이 다를까요? 쉽게 비유하자면, HPA는 식당에 직원을 추가하는 것이고, VPA는 직원의 능력을 키우는 것입니다.

손님이 많아지면 직원을 늘리는 대신(HPA), 한 명 한 명의 업무 처리 능력을 높여서(VPA) 대응하는 방식입니다. HPA가 **수평 확장(Horizontal Scaling)**이라면, VPA는 **수직 확장(Vertical Scaling)**입니다.

VPA가 없던 시절에는 어땠을까요? 개발자들은 파드의 CPU와 메모리 설정을 추측으로 결정했습니다.

보통 넉넉하게 잡다 보니 리소스 낭비가 심했습니다. 반대로 너무 적게 설정하면 OOMKilled나 CPU throttling이 발생했습니다.

리소스를 변경하려면 Deployment 매니페스트를 직접 수정하고 재배포해야 했습니다. 운영하면서 리소스를 최적화하는 것은 거의 불가능했습니다.

바로 이런 문제를 해결하기 위해 VPA가 등장했습니다. VPA를 사용하면 실제 사용량을 분석해서 적정 리소스를 자동 계산합니다.

또한 파드를 재시작하면서 새로운 리소스를 자동 적용할 수 있습니다. 무엇보다 리소스 낭비를 줄여서 클러스터 비용을 절감한다는 큰 이점이 있습니다.

위의 코드를 한 줄씩 살펴보겠습니다. updateMode: "Auto"는 VPA가 자동으로 파드를 재시작하며 리소스를 조정한다는 의미입니다.

만약 "Off"로 설정하면 추천만 하고 적용은 하지 않습니다. "Initial"은 파드 생성 시에만 적용합니다.

minAllowed와 maxAllowed는 VPA가 설정할 수 있는 리소스의 최소/최대값입니다. 아무리 사용량이 적어도 CPU 100m, 메모리 128Mi는 보장하고, 아무리 많아도 CPU 2000m, 메모리 2Gi를 넘지 않습니다.

이렇게 경계를 설정하면 리소스가 과도하게 할당되는 것을 방지합니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 머신러닝 추론 서비스를 운영한다고 가정해봅시다. 모델 크기에 따라 필요한 메모리가 천차만별입니다.

작은 모델은 512Mi로 충분하지만, 큰 모델은 4Gi가 필요합니다. VPA를 사용하면 각 파드가 실제로 사용하는 메모리를 분석해서 자동으로 적절한 크기를 할당합니다.

이렇게 하면 리소스 낭비 없이 효율적으로 운영할 수 있습니다. VPA는 어떻게 적정 리소스를 계산할까요?

VPA는 파드의 실제 리소스 사용량을 며칠간 관찰합니다. 평균 사용량, 피크 사용량, 변동 폭을 분석해서 적정값을 추천합니다.

보통 평균보다 약간 높게, 피크보다는 낮게 설정합니다. 이렇게 하면 대부분의 상황에서 안정적으로 동작하면서도 리소스를 절약할 수 있습니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 HPA와 VPA를 같은 리소스에 동시 적용하는 것입니다.

예를 들어 CPU를 기준으로 HPA와 VPA를 모두 설정하면 충돌이 발생합니다. HPA는 파드를 늘리려 하는데 VPA는 파드 크기를 키우려 해서 예측 불가능한 동작이 일어납니다.

따라서 HPA는 CPU, VPA는 메모리처럼 다른 리소스를 대상으로 하거나, 둘 중 하나만 사용해야 합니다. 또 다른 주의점은 파드 재시작입니다.

VPA의 Auto 모드는 리소스를 변경할 때 파드를 재시작합니다. 잠깐 동안 서비스가 중단될 수 있습니다.

따라서 고가용성이 중요한 서비스에서는 updateMode: "Off"로 설정하고 추천값만 받아서 수동으로 적용하는 것이 안전합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

VPA를 적용한 후 클러스터 비용이 30% 줄었습니다. 불필요하게 큰 리소스를 할당하던 파드들이 적정 크기로 조정되었기 때문입니다.

"이제 진짜 최적화네요!" VPA를 활용하면 리소스를 낭비 없이 효율적으로 사용할 수 있습니다. 여러분도 파드의 실제 사용량을 분석해서 VPA를 적용해 보세요.

실전 팁

💡 - HPA와 VPA를 같은 리소스에 동시 적용하지 마세요

프로덕션에서는 updateMode: "Off"로 시작해서 추천값을 먼저 확인하세요
minAllowed와 maxAllowed를 꼭 설정해서 리소스 범위를 제한하세요

5. Cluster Autoscaler

HPA와 VPA로 파드를 완벽하게 관리하던 김개발 씨에게 또 다른 문제가 찾아왔습니다. 트래픽이 급증해서 파드를 20개로 늘리려는데, 클러스터에 노드가 부족해서 파드가 Pending 상태로 멈춰 있습니다.

박시니어 씨가 말했습니다. "노드 자체를 늘려야 해요.

Cluster Autoscaler를 켜봅시다."

Cluster Autoscaler는 파드가 스케줄링될 수 없을 때 노드(VM 인스턴스)를 자동으로 추가하고, 노드 사용률이 낮으면 제거합니다. HPA/VPA가 파드 레벨 스케일링이라면, Cluster Autoscaler는 인프라 레벨 스케일링입니다.

AWS, GCP, Azure 등 클라우드와 연동하여 동작합니다.

다음 코드를 살펴봅시다.

apiVersion: v1
kind: ConfigMap
metadata:
  name: cluster-autoscaler-config
  namespace: kube-system
data:
  min-nodes: "3"  # 최소 노드 개수
  max-nodes: "20"  # 최대 노드 개수
  scale-down-delay-after-add: "10m"  # 노드 추가 후 10분 대기
  scale-down-unneeded-time: "10m"  # 불필요 판단 후 10분 대기
  skip-nodes-with-system-pods: "false"
---
# AWS EKS 예시: 노드 그룹에 오토스케일링 설정
# aws eks update-nodegroup-config \
#   --cluster-name my-cluster \
#   --nodegroup-name my-nodegroup \
#   --scaling-config minSize=3,maxSize=20,desiredSize=5

김개발 씨의 서비스는 날로 성장하고 있었습니다. HPA 덕분에 파드가 자동으로 늘어나고, VPA 덕분에 리소스가 최적화되었습니다.

하지만 어느 날 저녁, 대규모 마케팅 이벤트를 진행하면서 큰 문제가 발생했습니다. 트래픽이 평소의 10배로 폭증하자 HPA가 파드를 50개까지 늘리려고 했습니다.

하지만 클러스터에는 노드가 10개밖에 없었고, 더 이상 파드를 배치할 공간이 없었습니다. 파드 30개가 Pending 상태로 멈춰 있었습니다.

김개발 씨는 급하게 AWS 콘솔에 접속해서 수동으로 EC2 인스턴스를 추가했습니다. 그렇다면 Cluster Autoscaler는 무엇일까요?

쉽게 비유하자면, 주차장을 생각해봅시다. HPA는 차를 늘리는 것이고, Cluster Autoscaler는 주차 공간을 늘리는 것입니다.

아무리 차가 많아도 주차 공간이 없으면 차를 댈 수 없습니다. 마찬가지로 파드를 아무리 늘리려 해도 노드가 없으면 스케줄링할 수 없습니다.

Cluster Autoscaler는 노드라는 인프라를 자동으로 관리합니다. Cluster Autoscaler가 없던 시절에는 어땠을까요?

개발자들은 트래픽 증가를 예측해서 미리 노드를 충분히 띄워놓아야 했습니다. 하지만 예측이 빗나가면 장애가 발생했습니다.

새벽 시간처럼 트래픽이 낮을 때는 노드가 대부분 비어 있는데도 비용을 지불해야 했습니다. 노드를 수동으로 추가하려면 클라우드 콘솔에 접속해서 VM을 생성하고 쿠버네티스 클러스터에 조인해야 했습니다.

이 과정에서 최소 5-10분이 걸렸고, 그동안 서비스는 장애 상태였습니다. 바로 이런 문제를 해결하기 위해 Cluster Autoscaler가 등장했습니다.

Cluster Autoscaler를 사용하면 파드가 Pending 상태가 되면 자동으로 노드 추가됩니다. 또한 노드 사용률이 낮으면 자동으로 노드 제거해서 비용을 절감합니다.

무엇보다 클라우드 인프라를 쿠버네티스가 직접 관리할 수 있다는 큰 이점이 있습니다. 위의 설정을 자세히 살펴보겠습니다.

min-nodes: "3"은 최소 노드 개수를 의미합니다. 아무리 트래픽이 적어도 노드 3개는 항상 유지합니다.

이렇게 하면 갑작스러운 트래픽 증가에 빠르게 대응할 수 있습니다. max-nodes: "20"은 최대 노드 개수입니다.

비용이 무한정 증가하는 것을 방지합니다. 아무리 트래픽이 많아도 노드 20개를 넘지 않습니다.

scale-down-delay-after-add: "10m"은 노드를 추가한 후 10분 동안은 제거하지 않습니다. 노드를 추가했다가 바로 제거하는 불필요한 동작을 방지합니다.

scale-down-unneeded-time: "10m"은 노드가 불필요하다고 판단된 후 10분을 기다린 후 제거합니다. 일시적인 트래픽 감소에 과도하게 반응하지 않습니다.

실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 플랫폼을 운영한다고 가정해봅시다.

평소에는 노드 5개로 충분하지만, 블랙프라이데이 같은 대규모 세일 기간에는 노드 50개가 필요합니다. Cluster Autoscaler를 사용하면 트래픽 증가에 맞춰 자동으로 노드가 50개까지 늘어나고, 세일이 끝나면 다시 5개로 줄어듭니다.

쿠팡, 11번가 같은 대형 쇼핑몰에서 이런 방식으로 비용을 최적화합니다. Cluster Autoscaler는 어떻게 동작할까요?

1분마다 클러스터 상태를 확인합니다. Pending 상태인 파드가 있는지 검사하고, 있다면 새 노드를 추가합니다.

클라우드 API를 호출해서 VM을 생성하고 자동으로 클러스터에 조인시킵니다. 반대로 노드 사용률이 50% 이하로 지속되면, 해당 노드의 파드를 다른 노드로 옮긴 후 노드를 제거합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 scale-down 시간을 너무 짧게 설정하는 것입니다.

예를 들어 1분으로 설정하면 트래픽이 조금만 줄어도 노드가 삭제되고, 다시 늘어나면 추가되는 과정이 반복됩니다. 노드 추가/제거에는 시간이 걸리므로 서비스가 불안정해집니다.

따라서 최소 5-10분 이상으로 설정하는 것이 좋습니다. 또 다른 주의점은 파드의 PodDisruptionBudget 설정입니다.

Cluster Autoscaler가 노드를 제거할 때 해당 노드의 파드를 강제로 종료합니다. 만약 PDB 설정이 없으면 서비스 가용성이 떨어질 수 있습니다.

따라서 중요한 서비스는 반드시 PDB를 설정해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다.

Cluster Autoscaler를 적용한 후 대규모 이벤트도 문제없이 처리했습니다. 노드가 자동으로 50개까지 늘어났다가 이벤트 종료 후 다시 5개로 줄어들었습니다.

"이제 새벽에 노드 추가하느라 일어나지 않아도 되겠어요!" Cluster Autoscaler를 활용하면 인프라 레벨에서 완전한 자동화를 구현할 수 있습니다. 여러분도 클라우드 환경에서 Cluster Autoscaler를 활성화해 보세요.

실전 팁

💡 - scale-down 시간은 최소 5-10분으로 설정하세요

중요한 서비스에는 PodDisruptionBudget을 반드시 설정하세요
클라우드별로 설정 방법이 다르니 공식 문서를 참고하세요

6. 스케일링 전략

모든 오토스케일링 도구를 마스터한 김개발 씨는 이제 종합적인 전략을 세울 차례였습니다. HPA, VPA, Cluster Autoscaler를 언제 어떻게 조합해야 할까요?

박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다. "각 도구의 장단점을 이해하고 상황에 맞게 조합해야 합니다."

스케일링 전략은 서비스 특성에 따라 HPA, VPA, Cluster Autoscaler를 적절히 조합하는 것입니다. CPU 집약적 vs 메모리 집약적, 예측 가능한 트래픽 vs 불규칙한 트래픽, 비용 우선 vs 성능 우선 등 다양한 요소를 고려해야 합니다.

다음 코드를 살펴봅시다.

# 전략 1: API 서버 - HPA + Cluster Autoscaler
# CPU 기반으로 파드 개수 조절, 노드 부족 시 자동 추가
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: api-server-strategy
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: api-server
  minReplicas: 5
  maxReplicas: 100
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 30  # 빠른 스케일 아웃
      policies:
      - type: Percent
        value: 100  # 한 번에 2배까지 증가 가능
        periodSeconds: 15
    scaleDown:
      stabilizationWindowSeconds: 300  # 천천히 스케일 인

김개발 씨는 지난 몇 달간 오토스케일링의 모든 것을 배웠습니다. HPA로 파드 개수를 조절하고, VPA로 파드 크기를 최적화하고, Cluster Autoscaler로 노드를 관리했습니다.

하지만 이제 새로운 의문이 생겼습니다. "이 도구들을 다 써야 하나요?

아니면 골라서 써야 하나요?" 박시니어 씨가 회의실로 김개발 씨를 불렀습니다. 화이트보드에는 여러 서비스 시나리오가 그려져 있었습니다.

"각 서비스마다 적합한 전략이 다릅니다. 함께 분석해 봅시다." 그렇다면 어떻게 전략을 세워야 할까요?

쉽게 비유하자면, 교통수단을 선택하는 것과 같습니다. 가까운 거리는 걸어가고, 중간 거리는 자전거나 버스, 먼 거리는 지하철이나 비행기를 탑니다.

목적지, 시간, 비용을 고려해서 최적의 수단을 선택합니다. 마찬가지로 오토스케일링도 서비스 특성, 트래픽 패턴, 비용 제약을 고려해서 적절한 도구를 선택하고 조합해야 합니다.

전략 없이 무작정 적용하면 어떻게 될까요? 모든 도구를 다 사용하면 오히려 복잡도만 증가하고 예측 불가능한 동작이 발생합니다.

예를 들어 HPA와 VPA를 같은 리소스에 적용하면 충돌이 일어납니다. 반대로 아무것도 사용하지 않으면 트래픽 급증 시 장애가 발생합니다.

적절한 균형과 조합이 필요합니다. 바로 이런 문제를 해결하기 위해 스케일링 전략이 필요합니다.

전략을 수립하면 서비스 특성에 딱 맞는 오토스케일링을 구현할 수 있습니다. 또한 비용과 성능의 균형을 찾을 수 있습니다.

무엇보다 예측 가능하고 안정적인 서비스 운영이 가능하다는 큰 이점이 있습니다. 대표적인 전략 패턴을 살펴보겠습니다.

전략 1: API 서버 - HPA + Cluster Autoscaler 일반적인 웹 API 서비스는 CPU를 주로 사용합니다. 트래픽이 증가하면 CPU 사용률이 올라가므로 HPA가 적합합니다.

파드가 많아져서 노드가 부족하면 Cluster Autoscaler가 노드를 추가합니다. VPA는 사용하지 않고 리소스를 고정값으로 설정합니다.

전략 2: 데이터 처리 배치 - VPA 단독 배치 작업은 파드 개수를 늘리는 것보다 파드 크기를 키우는 게 효과적인 경우가 많습니다. 데이터를 메모리에 로드해서 처리하므로 메모리가 중요합니다.

VPA를 사용해서 실제 메모리 사용량에 맞춰 리소스를 자동 조정합니다. 전략 3: 큐 워커 - HPA(커스텀 메트릭) + Cluster Autoscaler 메시지 큐를 처리하는 워커는 큐 길이를 기준으로 스케일링해야 합니다.

CPU가 여유가 있어도 큐가 쌓이면 파드를 늘려야 합니다. 커스텀 메트릭 HPA를 사용하고, 노드 부족 시 Cluster Autoscaler가 대응합니다.

전략 4: 머신러닝 추론 - VPA + Cluster Autoscaler ML 모델은 메모리를 많이 사용하지만 CPU는 적게 씁니다. 모델 크기에 따라 필요한 메모리가 다르므로 VPA가 적합합니다.

파드 개수는 고정하고 VPA로 리소스를 최적화합니다. 위의 코드를 자세히 살펴보겠습니다.

behavior 섹션은 스케일링 속도를 제어합니다. scaleUp.stabilizationWindowSeconds: 30은 스케일 아웃을 빠르게 수행합니다.

트래픽 급증 시 신속하게 대응하기 위함입니다. policies에서 value: 100은 한 번에 최대 100%(2배)까지 증가할 수 있다는 의미입니다.

반면 scaleDown.stabilizationWindowSeconds: 300은 스케일 인을 천천히 수행합니다. 5분 동안 관찰한 후 파드를 줄입니다.

이렇게 하면 트래픽이 일시적으로 줄었다가 다시 증가하는 경우에도 안정적으로 대응할 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 유튜브 같은 동영상 플랫폼을 생각해봅시다. 웹 API 서버는 전략 1(HPA + CA)을 사용하고, 동영상 인코딩 워커는 전략 3(커스텀 메트릭 HPA + CA)을 사용하고, 추천 알고리즘 서버는 전략 4(VPA + CA)를 사용합니다.

각 컴포넌트의 특성에 맞는 전략을 적용해서 최적의 성능과 비용을 달성합니다. 전략을 수립할 때 고려할 점은 무엇일까요?

첫째, 서비스의 리소스 특성을 파악하세요. CPU 집약적인지, 메모리 집약적인지, I/O 집약적인지 분석합니다.

둘째, 트래픽 패턴을 이해하세요. 예측 가능한 패턴인지, 불규칙한 패턴인지에 따라 전략이 달라집니다.

셋째, 비용과 성능 우선순위를 정하세요. 비용 절감이 중요하면 aggressive한 scale-down을, 성능이 중요하면 보수적인 scale-down을 설정합니다.

하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 모든 서비스에 동일한 전략을 적용하는 것입니다.

"HPA + VPA + CA를 다 쓰면 되겠지"라고 생각하지만, 이렇게 하면 충돌이 발생하고 관리가 복잡해집니다. 각 서비스의 특성을 분석하고 필요한 도구만 선택적으로 사용해야 합니다.

또 다른 실수는 너무 공격적인 스케일링입니다. 빠르게 늘리고 빠르게 줄이면 파드가 계속 재시작되어 서비스가 불안정해집니다.

스케일 아웃은 빠르게, 스케일 인은 천천히 하는 비대칭 전략이 일반적으로 안전합니다. 마지막으로 모니터링과 알람을 반드시 설정하세요.

오토스케일링이 제대로 동작하는지, 비정상적인 스케일링이 발생하는지 지속적으로 관찰해야 합니다. Grafana, Prometheus로 대시보드를 만들고, 이상 징후 발생 시 Slack으로 알람을 받도록 설정하세요.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 자신의 서비스를 분석했습니다.

API 서버는 HPA + CA, 이미지 처리 워커는 커스텀 메트릭 HPA, 데이터 분석 배치는 VPA를 적용했습니다. 결과는 놀라웠습니다.

서비스 안정성은 높아지고 비용은 40% 절감되었습니다. "오토스케일링은 단순히 도구를 사용하는 게 아니라, 서비스를 깊이 이해하고 전략을 세우는 것이군요!" 스케일링 전략을 제대로 수립하면 안정적이고 비용 효율적인 서비스를 운영할 수 있습니다.

여러분도 자신의 서비스 특성을 분석해서 최적의 전략을 찾아보세요.

실전 팁

💡 - 스케일 아웃은 빠르게, 스케일 인은 천천히 하는 비대칭 전략을 사용하세요

각 서비스 컴포넌트별로 다른 전략을 적용하세요
모니터링 대시보드를 만들어서 스케일링 동작을 지속적으로 관찰하세요

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

#Kubernetes#HPA#VPA#Autoscaling#CloudNative

오토스케일링 완벽 가이드

# 오토스케일링 완벽 가이드 트래픽 변화에 자동으로 대응하는 오토스케일링의 모든 것을 배웁니다. HPA, VPA, Cluster Autoscaler까지 실전 예제와 함께 쉽게 설명합니다. 초급 개발자도 술술 읽히는 실무 중심 가이드입니다. --- ## 목차 1. [HPA_개념](#hpa-개념) 2. [CPU_메모리_기반_스케일링](#cpu-메모리-기반-스케일링) 3. [커스텀_메트릭_스케일링](#커스텀-메트릭-스케일링) 4. [VPA_개념](#vpa-개념) 5. [Cluster_Autoscaler](#cluster-autoscaler) 6. [스케일링_전략](#스케일링-전략) --- ## 1. HPA_개념 어느 날 김개발 씨가 출근하자마자 급한 전화를 받았습니다. "우리 서비스가 다운됐어요!" 밤사이 갑자기 트래픽이 몰려서 서버가 감당하지 못한 것입니다. 박시니어 씨가 다가와 말했습니다. "오토스케일링을 설정했어야 했는데..." **HPA(Horizontal Pod Autoscaler)**는 트래픽 변화에 따라 파드의 개수를 자동으로 늘리거나 줄이는 기능입니다. 마치 식당에서 손님이 많아지면 직원을 더 투입하고, 한가해지면 줄이는 것과 같습니다. CPU 사용률, 메모리, 커스텀 메트릭을 기준으로 스케일링을 수행합니다. 다음 코드를 살펴봅시다. ```python apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: web-app-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: web-app minReplicas: 2 # 최소 파드 개수 maxReplicas: 10 # 최대 파드 개수 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU 70% 초과 시 스케일 아웃 ``` 김개발 씨는 입사 3개월 차 백엔드 개발자입니다. 처음으로 맡은 서비스가 성공적으로 오픈했는데, 예상보다 훨씬 많은 사용자가 몰려들었습니다. 새벽 2시, 장애 알람이 울렸습니다. 서버가 과부하로 다운된 것입니다. 다음 날 출근하자마자 박시니어 씨가 김개발 씨를 불렀습니다. "어젯밤 고생 많았죠? 사실 이런 상황을 대비해서 오토스케일링이라는 게 있어요." 그렇다면 **오토스케일링**이란 정확히 무엇일까요? 쉽게 비유하자면, 오토스케일링은 마치 백화점 계산대와 같습니다. 평일 오전에는 계산대 2개만 열어두지만, 주말 저녁이나 세일 기간에는 계산대를 10개까지 열어서 고객을 빠르게 처리합니다. 손님이 줄어들면 다시 계산대를 줄입니다. 이처럼 오토스케일링도 **트래픽 변화에 맞춰 서버 자원을 자동으로 조절**하는 역할을 담당합니다. 오토스케일링이 없던 시절에는 어땠을까요? 개발자들은 트래픽을 예측해서 미리 서버를 충분히 띄워놓아야 했습니다. 문제는 예측이 빗나가는 경우가 많았다는 점입니다. 서버를 너무 적게 띄우면 장애가 발생하고, 너무 많이 띄우면 비용이 낭비됩니다. 더 큰 문제는 새벽 시간대처럼 트래픽이 급변하는 상황에서 개발자가 일일이 서버를 늘렸다 줄였다 해야 한다는 점이었습니다. 바로 이런 문제를 해결하기 위해 **HPA**가 등장했습니다. HPA를 사용하면 **트래픽 증가 시 자동으로 파드가 추가**됩니다. 또한 **트래픽 감소 시 불필요한 파드를 제거**해서 비용을 절감할 수 있습니다. 무엇보다 **24시간 자동으로 관리되어 개발자가 잠을 잘 수 있다**는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. 먼저 `scaleTargetRef` 부분에서는 어떤 Deployment를 스케일링할지 지정합니다. 여기서는 `web-app`이라는 이름의 Deployment를 대상으로 합니다. 다음으로 `minReplicas`와 `maxReplicas`에서는 파드의 최소/최대 개수를 설정합니다. 최소 2개는 항상 유지하고, 최대 10개까지 늘어날 수 있습니다. 가장 중요한 부분은 `metrics`입니다. 여기서는 CPU 사용률을 기준으로 스케일링합니다. `averageUtilization: 70`은 평균 CPU 사용률이 70%를 넘으면 파드를 추가한다는 의미입니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 쇼핑몰 서비스를 개발한다고 가정해봅시다. 평소에는 파드 3개로 충분하지만, 점심시간이나 저녁시간에는 트래픽이 3배 증가합니다. HPA를 설정하면 자동으로 파드가 9개까지 늘어나서 빠른 응답속도를 유지합니다. 트래픽이 줄어들면 다시 3개로 줄어들어 비용을 절감합니다. 쿠팡, 배달의민족 같은 대형 서비스에서 이런 패턴을 적극적으로 사용하고 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수 중 하나는 **너무 낮은 CPU 임계값을 설정**하는 것입니다. 예를 들어 CPU 30%에 스케일 아웃을 설정하면, 조금만 부하가 생겨도 파드가 불필요하게 늘어나서 비용이 낭비됩니다. 따라서 **실제 트래픽 패턴을 분석한 후 적절한 임계값**을 설정해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 고개를 끄덕였습니다. "아, 그래서 자동으로 서버가 늘어나는 거군요!" HPA를 제대로 이해하면 안정적이고 비용 효율적인 서비스를 운영할 수 있습니다. 여러분도 오늘 배운 내용을 실제 프로젝트에 적용해 보세요. **실전 팁** 💡 - CPU 임계값은 보통 60-80% 사이가 적절합니다 - 최소 파드는 2개 이상으로 설정해서 고가용성을 확보하세요 - 스케일 아웃 후 안정화 시간(cooldown)을 고려하세요 --- ## 2. CPU_메모리_기반_스케일링 HPA를 적용한 김개발 씨의 서비스는 안정적으로 운영되는 듯 보였습니다. 하지만 며칠 후 다시 문제가 발생했습니다. CPU는 50%밖에 안 쓰는데 메모리가 가득 차서 파드가 죽는 것입니다. 박시니어 씨가 말했습니다. "CPU만 보면 안 돼요. 메모리도 함께 고려해야 합니다." CPU와 메모리를 동시에 모니터링하는 **멀티 메트릭 스케일링**은 더 정교한 오토스케일링을 가능하게 합니다. CPU는 여유가 있어도 메모리가 부족하면 스케일 아웃이 필요합니다. 두 가지 메트릭 중 하나라도 임계값을 넘으면 스케일링이 동작합니다. 다음 코드를 살펴봅시다. ```python apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: multi-metric-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-server minReplicas: 3 maxReplicas: 15 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 # CPU 70% 기준 - type: Resource resource: name: memory target: type: Utilization averageUtilization: 80 # 메모리 80% 기준 ``` 김개발 씨는 HPA를 적용한 후 한결 마음이 편해졌습니다. 트래픽이 몰려도 자동으로 파드가 늘어나니까요. 하지만 1주일 후, 이상한 현상이 발생했습니다. CPU 사용률은 50%밖에 안 되는데 파드가 갑자기 재시작되는 것입니다. 로그를 확인해보니 **OOMKilled(Out Of Memory Killed)** 에러가 찍혀 있었습니다. 메모리가 부족해서 쿠버네티스가 파드를 강제로 종료시킨 것입니다. 박시니어 씨에게 물어보니 이렇게 답했습니다. "CPU만 보고 스케일링하면 이런 일이 생길 수 있어요." 그렇다면 왜 CPU만으로는 부족한 걸까요? 쉽게 비유하자면, 사람에게 필요한 영양소가 탄수화물만 있는 게 아니듯, 서버도 CPU만 중요한 게 아닙니다. 어떤 애플리케이션은 CPU를 많이 쓰고(예: 동영상 인코딩), 어떤 애플리케이션은 메모리를 많이 씁니다(예: 캐싱 서버, 대용량 데이터 처리). 만약 메모리를 많이 쓰는 애플리케이션에서 CPU만 모니터링하면, 메모리가 가득 차도 스케일 아웃이 일어나지 않습니다. CPU만 보던 시절에는 어땠을까요? 개발자들은 메모리 부족 장애를 겪고 나서야 문제를 발견했습니다. 그때는 이미 서비스가 다운된 후였습니다. 메모리 사용률을 따로 모니터링하고, 임계값에 도달하면 수동으로 파드를 늘려야 했습니다. 새벽에 메모리 알람이 울리면 개발자가 일어나서 kubectl 명령어로 파드를 추가하는 일이 잦았습니다. 바로 이런 문제를 해결하기 위해 **멀티 메트릭 스케일링**이 등장했습니다. 멀티 메트릭 스케일링을 사용하면 **CPU와 메모리를 동시에 모니터링**할 수 있습니다. 또한 **둘 중 하나라도 임계값을 넘으면 자동으로 스케일 아웃**됩니다. 무엇보다 **각 리소스의 특성에 맞는 임계값을 따로 설정**할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. `metrics` 배열에 두 개의 메트릭이 정의되어 있습니다. 첫 번째는 CPU로 70%를 임계값으로 설정했고, 두 번째는 메모리로 80%를 임계값으로 설정했습니다. HPA는 이 두 메트릭을 **모두 확인**하면서 스케일링 여부를 결정합니다. 중요한 점은 **OR 조건으로 동작**한다는 것입니다. CPU가 70%를 넘거나 메모리가 80%를 넘으면 스케일 아웃이 발생합니다. 둘 다 임계값을 넘을 필요는 없습니다. 이렇게 하면 어떤 리소스가 먼저 부족해지든 대응할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이미지 처리 API를 개발한다고 가정해봅시다. 이미지를 업로드하면 서버 메모리에 이미지를 올려놓고 리사이징 작업을 합니다. 이 과정에서 메모리 사용량이 급증하지만 CPU는 그리 높지 않을 수 있습니다. 만약 CPU만 모니터링하면 메모리 부족으로 장애가 발생합니다. 하지만 멀티 메트릭 스케일링을 사용하면 메모리가 80%에 도달하는 순간 파드가 추가되어 안정적인 서비스가 가능합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 **메모리 임계값을 CPU와 동일하게 설정**하는 것입니다. 하지만 메모리는 CPU와 다르게 한 번 차면 줄어들지 않는 특성이 있습니다. 따라서 메모리 임계값은 CPU보다 **조금 더 높게(70-85%) 설정**하는 것이 좋습니다. 너무 낮게 설정하면 불필요한 스케일 아웃이 자주 발생합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 멀티 메트릭 스케일링을 적용한 후, 메모리 부족 장애는 완전히 사라졌습니다. "이제야 안심하고 퇴근할 수 있겠어요!" CPU와 메모리를 함께 고려하면 훨씬 안정적인 서비스 운영이 가능합니다. 여러분도 애플리케이션의 특성을 파악해서 적절한 메트릭을 설정해 보세요. **실전 팁** 💡 - 메모리 임계값은 보통 75-85% 사이가 적절합니다 - 애플리케이션의 메모리 사용 패턴을 먼저 분석하세요 - request와 limit을 명확히 설정해야 정확한 사용률 계산이 가능합니다 --- ## 3. 커스텀_메트릭_스케일링 서비스가 안정화되자 김개발 씨는 새로운 고민에 빠졌습니다. 동영상 인코딩 서비스인데, CPU와 메모리는 여유가 있어도 **인코딩 대기 큐**에 작업이 쌓이면 사용자는 오래 기다려야 합니다. 박시니어 씨가 조언했습니다. "큐 길이를 기준으로 스케일링하면 어떨까요?" **커스텀 메트릭 스케일링**은 CPU, 메모리 외에 비즈니스 로직에 맞는 지표를 기준으로 스케일링합니다. 메시지 큐 길이, API 응답 시간, 데이터베이스 커넥션 수 등 다양한 메트릭을 활용할 수 있습니다. Prometheus 같은 모니터링 도구와 연동하여 사용합니다. 다음 코드를 살펴봅시다. ```python apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: custom-metric-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: video-encoder minReplicas: 2 maxReplicas: 20 metrics: - type: Pods pods: metric: name: queue_length # Prometheus에서 수집한 커스텀 메트릭 target: type: AverageValue averageValue: "30" # 파드당 평균 큐 길이 30개 초과 시 스케일 아웃 behavior: scaleUp: stabilizationWindowSeconds: 60 # 1분 동안 관찰 후 스케일 아웃 ``` 김개발 씨의 팀은 동영상 인코딩 서비스를 운영하고 있습니다. 사용자가 동영상을 업로드하면 여러 해상도로 변환하는 작업을 처리합니다. CPU와 메모리 기반 스케일링을 적용했지만, 여전히 문제가 있었습니다. 오후 6시쯤 되면 사용자들이 대량으로 동영상을 업로드합니다. 작업이 큐에 쌓이기 시작하는데, CPU와 메모리는 아직 70%도 안 됩니다. 스케일 아웃이 일어나지 않아서 사용자들은 10분 이상 기다려야 합니다. 박시니어 씨가 모니터링 대시보드를 보며 말했습니다. "CPU가 아니라 큐 길이를 봐야 해요." 그렇다면 **커스텀 메트릭**이란 무엇일까요? 쉽게 비유하자면, 은행 창구를 생각해봅시다. 직원들이 쉬고 있어도(CPU 여유) 대기 줄에 손님이 20명 넘게 서 있다면 창구를 더 열어야 합니다. 직원의 바쁜 정도가 아니라 **대기 줄의 길이**가 중요한 것입니다. 마찬가지로 커스텀 메트릭은 CPU, 메모리 같은 시스템 지표가 아니라 **비즈니스 상황을 직접 반영하는 지표**로 스케일링합니다. 커스텀 메트릭이 없던 시절에는 어땠을까요? 개발자들은 큐 길이를 직접 모니터링하다가 임계값을 넘으면 수동으로 파드를 늘렸습니다. 하지만 큐 길이는 갑자기 증가하는 경우가 많아서 대응이 늦어지기 일쑤였습니다. 또한 CPU는 여유가 있는데 큐만 길어지는 상황에서는 CPU 기반 스케일링이 전혀 도움이 되지 않았습니다. 결국 사용자 불만이 쌓이고 서비스 품질이 떨어졌습니다. 바로 이런 문제를 해결하기 위해 **커스텀 메트릭 스케일링**이 등장했습니다. 커스텀 메트릭을 사용하면 **비즈니스 로직에 딱 맞는 스케일링**이 가능합니다. 또한 **사용자 경험을 직접 개선**할 수 있습니다. 무엇보다 **다양한 서비스 상황에 유연하게 대응**할 수 있다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. `type: Pods`는 파드별 메트릭을 기준으로 한다는 의미입니다. `metric.name: queue_length`는 Prometheus에서 수집하는 커스텀 메트릭 이름입니다. 이 메트릭은 애플리케이션이 직접 노출해야 합니다. `averageValue: "30"`은 파드당 평균 큐 길이가 30개를 넘으면 스케일 아웃한다는 뜻입니다. 만약 파드가 5개이고 전체 큐 길이가 200개라면, 파드당 평균은 40개이므로 스케일 아웃이 발생합니다. `behavior.scaleUp.stabilizationWindowSeconds`는 너무 빠른 스케일 아웃을 방지합니다. 1분 동안 메트릭을 관찰한 후 스케일 아웃 여부를 결정합니다. 이렇게 하면 일시적인 트래픽 스파이크에 과도하게 반응하지 않습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 주식 거래 시스템을 개발한다고 가정해봅시다. 장 시작 시간에는 주문이 폭증합니다. 이때 중요한 것은 CPU가 아니라 **주문 처리 대기 시간**입니다. 주문이 큐에 5초 이상 쌓이면 사용자는 불안해합니다. 따라서 평균 대기 시간을 커스텀 메트릭으로 설정하고, 3초를 넘으면 스케일 아웃하도록 구성합니다. 네이버페이, 카카오페이 같은 금융 서비스에서 이런 패턴을 사용합니다. 커스텀 메트릭을 사용하려면 어떻게 해야 할까요? 먼저 애플리케이션이 메트릭을 노출해야 합니다. Python에서는 `prometheus_client` 라이브러리를 사용합니다. 큐 길이를 Gauge 메트릭으로 등록하고 주기적으로 업데이트합니다. 그러면 Prometheus가 이 메트릭을 수집하고, Kubernetes Metrics Server가 HPA에 제공합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 **메트릭 이름을 잘못 설정**하는 것입니다. HPA의 `metric.name`과 Prometheus에서 수집하는 메트릭 이름이 정확히 일치해야 합니다. 하나라도 오타가 있으면 메트릭을 찾지 못해서 스케일링이 동작하지 않습니다. 또한 **메트릭 업데이트 주기**도 중요합니다. 너무 느리게 업데이트하면 스케일링 반응이 느려집니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. 큐 길이 기반 스케일링을 적용한 후, 사용자 대기 시간이 10분에서 1분으로 줄었습니다. "이제 진짜 똑똑한 오토스케일링이네요!" 커스텀 메트릭을 활용하면 비즈니스 요구사항에 딱 맞는 스케일링 전략을 구현할 수 있습니다. 여러분도 서비스의 핵심 지표를 파악해서 커스텀 메트릭을 만들어 보세요. **실전 팁** 💡 - 커스텀 메트릭은 Prometheus Adapter를 통해 HPA에 연동됩니다 - 메트릭 이름 규칙을 명확히 정하고 문서화하세요 - stabilizationWindow를 설정해서 급격한 스케일 변동을 방지하세요 --- ## 4. VPA_개념 커스텀 메트릭까지 적용한 김개발 씨는 뿌듯했습니다. 하지만 새로운 문제가 생겼습니다. 파드마다 필요한 CPU, 메모리가 다른데 일괄적으로 설정하다 보니 어떤 파드는 리소스가 남고, 어떤 파드는 부족합니다. 박시니어 씨가 말했습니다. "파드 개수가 아니라 파드 크기를 조절하는 VPA를 알아볼까요?" **VPA(Vertical Pod Autoscaler)**는 파드의 개수가 아니라 파드의 리소스 크기(CPU, 메모리 request/limit)를 자동으로 조절합니다. 실제 사용량을 분석해서 적절한 리소스를 추천하고 자동 적용합니다. HPA가 수평 확장이라면 VPA는 수직 확장입니다. 다음 코드를 살펴봅시다. ```python apiVersion: autoscaling.k8s.io/v1 kind: VerticalPodAutoscaler metadata: name: api-server-vpa spec: targetRef: apiVersion: apps/v1 kind: Deployment name: api-server updatePolicy: updateMode: "Auto" # 자동으로 파드 재시작하며 리소스 조정 resourcePolicy: containerPolicies: - containerName: api-container minAllowed: cpu: 100m memory: 128Mi maxAllowed: cpu: 2000m # 최대 2 CPU까지 memory: 2Gi # 최대 2GB까지 ``` 김개발 씨는 오토스케일링의 달인이 되어가고 있었습니다. HPA로 파드 개수를 조절하고, 커스텀 메트릭으로 비즈니스 로직에 맞게 스케일링했습니다. 하지만 여전히 찝찝한 부분이 있었습니다. 어떤 파드는 CPU를 500m만 써도 충분한데 1000m를 할당해서 낭비되고, 어떤 파드는 2000m가 필요한데 1000m만 할당되어 성능이 느렸습니다. 모든 파드에 동일한 리소스를 설정했기 때문입니다. 박시니어 씨가 물었습니다. "파드마다 필요한 리소스가 다르다는 걸 알고 있나요?" 그렇다면 **VPA**는 HPA와 무엇이 다를까요? 쉽게 비유하자면, HPA는 식당에 직원을 추가하는 것이고, VPA는 직원의 능력을 키우는 것입니다. 손님이 많아지면 직원을 늘리는 대신(HPA), 한 명 한 명의 업무 처리 능력을 높여서(VPA) 대응하는 방식입니다. HPA가 **수평 확장(Horizontal Scaling)**이라면, VPA는 **수직 확장(Vertical Scaling)**입니다. VPA가 없던 시절에는 어땠을까요? 개발자들은 파드의 CPU와 메모리 설정을 추측으로 결정했습니다. 보통 넉넉하게 잡다 보니 리소스 낭비가 심했습니다. 반대로 너무 적게 설정하면 OOMKilled나 CPU throttling이 발생했습니다. 리소스를 변경하려면 Deployment 매니페스트를 직접 수정하고 재배포해야 했습니다. 운영하면서 리소스를 최적화하는 것은 거의 불가능했습니다. 바로 이런 문제를 해결하기 위해 **VPA**가 등장했습니다. VPA를 사용하면 **실제 사용량을 분석해서 적정 리소스를 자동 계산**합니다. 또한 **파드를 재시작하면서 새로운 리소스를 자동 적용**할 수 있습니다. 무엇보다 **리소스 낭비를 줄여서 클러스터 비용을 절감**한다는 큰 이점이 있습니다. 위의 코드를 한 줄씩 살펴보겠습니다. `updateMode: "Auto"`는 VPA가 자동으로 파드를 재시작하며 리소스를 조정한다는 의미입니다. 만약 `"Off"`로 설정하면 추천만 하고 적용은 하지 않습니다. `"Initial"`은 파드 생성 시에만 적용합니다. `minAllowed`와 `maxAllowed`는 VPA가 설정할 수 있는 리소스의 최소/최대값입니다. 아무리 사용량이 적어도 CPU 100m, 메모리 128Mi는 보장하고, 아무리 많아도 CPU 2000m, 메모리 2Gi를 넘지 않습니다. 이렇게 경계를 설정하면 리소스가 과도하게 할당되는 것을 방지합니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 머신러닝 추론 서비스를 운영한다고 가정해봅시다. 모델 크기에 따라 필요한 메모리가 천차만별입니다. 작은 모델은 512Mi로 충분하지만, 큰 모델은 4Gi가 필요합니다. VPA를 사용하면 각 파드가 실제로 사용하는 메모리를 분석해서 자동으로 적절한 크기를 할당합니다. 이렇게 하면 리소스 낭비 없이 효율적으로 운영할 수 있습니다. VPA는 어떻게 적정 리소스를 계산할까요? VPA는 파드의 실제 리소스 사용량을 며칠간 관찰합니다. 평균 사용량, 피크 사용량, 변동 폭을 분석해서 적정값을 추천합니다. 보통 평균보다 약간 높게, 피크보다는 낮게 설정합니다. 이렇게 하면 대부분의 상황에서 안정적으로 동작하면서도 리소스를 절약할 수 있습니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 **HPA와 VPA를 같은 리소스에 동시 적용**하는 것입니다. 예를 들어 CPU를 기준으로 HPA와 VPA를 모두 설정하면 충돌이 발생합니다. HPA는 파드를 늘리려 하는데 VPA는 파드 크기를 키우려 해서 예측 불가능한 동작이 일어납니다. 따라서 **HPA는 CPU, VPA는 메모리처럼 다른 리소스를 대상**으로 하거나, 둘 중 하나만 사용해야 합니다. 또 다른 주의점은 **파드 재시작**입니다. VPA의 Auto 모드는 리소스를 변경할 때 파드를 재시작합니다. 잠깐 동안 서비스가 중단될 수 있습니다. 따라서 고가용성이 중요한 서비스에서는 `updateMode: "Off"`로 설정하고 추천값만 받아서 수동으로 적용하는 것이 안전합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. VPA를 적용한 후 클러스터 비용이 30% 줄었습니다. 불필요하게 큰 리소스를 할당하던 파드들이 적정 크기로 조정되었기 때문입니다. "이제 진짜 최적화네요!" VPA를 활용하면 리소스를 낭비 없이 효율적으로 사용할 수 있습니다. 여러분도 파드의 실제 사용량을 분석해서 VPA를 적용해 보세요. **실전 팁** 💡 - HPA와 VPA를 같은 리소스에 동시 적용하지 마세요 - 프로덕션에서는 updateMode: "Off"로 시작해서 추천값을 먼저 확인하세요 - minAllowed와 maxAllowed를 꼭 설정해서 리소스 범위를 제한하세요 --- ## 5. Cluster_Autoscaler HPA와 VPA로 파드를 완벽하게 관리하던 김개발 씨에게 또 다른 문제가 찾아왔습니다. 트래픽이 급증해서 파드를 20개로 늘리려는데, 클러스터에 노드가 부족해서 파드가 Pending 상태로 멈춰 있습니다. 박시니어 씨가 말했습니다. "노드 자체를 늘려야 해요. Cluster Autoscaler를 켜봅시다." **Cluster Autoscaler**는 파드가 스케줄링될 수 없을 때 노드(VM 인스턴스)를 자동으로 추가하고, 노드 사용률이 낮으면 제거합니다. HPA/VPA가 파드 레벨 스케일링이라면, Cluster Autoscaler는 인프라 레벨 스케일링입니다. AWS, GCP, Azure 등 클라우드와 연동하여 동작합니다. 다음 코드를 살펴봅시다. ```python apiVersion: v1 kind: ConfigMap metadata: name: cluster-autoscaler-config namespace: kube-system data: min-nodes: "3" # 최소 노드 개수 max-nodes: "20" # 최대 노드 개수 scale-down-delay-after-add: "10m" # 노드 추가 후 10분 대기 scale-down-unneeded-time: "10m" # 불필요 판단 후 10분 대기 skip-nodes-with-system-pods: "false" --- # AWS EKS 예시: 노드 그룹에 오토스케일링 설정 # aws eks update-nodegroup-config \ # --cluster-name my-cluster \ # --nodegroup-name my-nodegroup \ # --scaling-config minSize=3,maxSize=20,desiredSize=5 ``` 김개발 씨의 서비스는 날로 성장하고 있었습니다. HPA 덕분에 파드가 자동으로 늘어나고, VPA 덕분에 리소스가 최적화되었습니다. 하지만 어느 날 저녁, 대규모 마케팅 이벤트를 진행하면서 큰 문제가 발생했습니다. 트래픽이 평소의 10배로 폭증하자 HPA가 파드를 50개까지 늘리려고 했습니다. 하지만 클러스터에는 노드가 10개밖에 없었고, 더 이상 파드를 배치할 공간이 없었습니다. 파드 30개가 Pending 상태로 멈춰 있었습니다. 김개발 씨는 급하게 AWS 콘솔에 접속해서 수동으로 EC2 인스턴스를 추가했습니다. 그렇다면 **Cluster Autoscaler**는 무엇일까요? 쉽게 비유하자면, 주차장을 생각해봅시다. HPA는 차를 늘리는 것이고, Cluster Autoscaler는 주차 공간을 늘리는 것입니다. 아무리 차가 많아도 주차 공간이 없으면 차를 댈 수 없습니다. 마찬가지로 파드를 아무리 늘리려 해도 노드가 없으면 스케줄링할 수 없습니다. Cluster Autoscaler는 **노드라는 인프라를 자동으로 관리**합니다. Cluster Autoscaler가 없던 시절에는 어땠을까요? 개발자들은 트래픽 증가를 예측해서 미리 노드를 충분히 띄워놓아야 했습니다. 하지만 예측이 빗나가면 장애가 발생했습니다. 새벽 시간처럼 트래픽이 낮을 때는 노드가 대부분 비어 있는데도 비용을 지불해야 했습니다. 노드를 수동으로 추가하려면 클라우드 콘솔에 접속해서 VM을 생성하고 쿠버네티스 클러스터에 조인해야 했습니다. 이 과정에서 최소 5-10분이 걸렸고, 그동안 서비스는 장애 상태였습니다. 바로 이런 문제를 해결하기 위해 **Cluster Autoscaler**가 등장했습니다. Cluster Autoscaler를 사용하면 **파드가 Pending 상태가 되면 자동으로 노드 추가**됩니다. 또한 **노드 사용률이 낮으면 자동으로 노드 제거**해서 비용을 절감합니다. 무엇보다 **클라우드 인프라를 쿠버네티스가 직접 관리**할 수 있다는 큰 이점이 있습니다. 위의 설정을 자세히 살펴보겠습니다. `min-nodes: "3"`은 최소 노드 개수를 의미합니다. 아무리 트래픽이 적어도 노드 3개는 항상 유지합니다. 이렇게 하면 갑작스러운 트래픽 증가에 빠르게 대응할 수 있습니다. `max-nodes: "20"`은 최대 노드 개수입니다. 비용이 무한정 증가하는 것을 방지합니다. 아무리 트래픽이 많아도 노드 20개를 넘지 않습니다. `scale-down-delay-after-add: "10m"`은 노드를 추가한 후 10분 동안은 제거하지 않습니다. 노드를 추가했다가 바로 제거하는 불필요한 동작을 방지합니다. `scale-down-unneeded-time: "10m"`은 노드가 불필요하다고 판단된 후 10분을 기다린 후 제거합니다. 일시적인 트래픽 감소에 과도하게 반응하지 않습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 이커머스 플랫폼을 운영한다고 가정해봅시다. 평소에는 노드 5개로 충분하지만, 블랙프라이데이 같은 대규모 세일 기간에는 노드 50개가 필요합니다. Cluster Autoscaler를 사용하면 트래픽 증가에 맞춰 자동으로 노드가 50개까지 늘어나고, 세일이 끝나면 다시 5개로 줄어듭니다. 쿠팡, 11번가 같은 대형 쇼핑몰에서 이런 방식으로 비용을 최적화합니다. Cluster Autoscaler는 어떻게 동작할까요? 1분마다 클러스터 상태를 확인합니다. Pending 상태인 파드가 있는지 검사하고, 있다면 새 노드를 추가합니다. 클라우드 API를 호출해서 VM을 생성하고 자동으로 클러스터에 조인시킵니다. 반대로 노드 사용률이 50% 이하로 지속되면, 해당 노드의 파드를 다른 노드로 옮긴 후 노드를 제거합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 **scale-down 시간을 너무 짧게 설정**하는 것입니다. 예를 들어 1분으로 설정하면 트래픽이 조금만 줄어도 노드가 삭제되고, 다시 늘어나면 추가되는 과정이 반복됩니다. 노드 추가/제거에는 시간이 걸리므로 서비스가 불안정해집니다. 따라서 **최소 5-10분 이상**으로 설정하는 것이 좋습니다. 또 다른 주의점은 **파드의 PodDisruptionBudget** 설정입니다. Cluster Autoscaler가 노드를 제거할 때 해당 노드의 파드를 강제로 종료합니다. 만약 PDB 설정이 없으면 서비스 가용성이 떨어질 수 있습니다. 따라서 중요한 서비스는 반드시 PDB를 설정해야 합니다. 다시 김개발 씨의 이야기로 돌아가 봅시다. Cluster Autoscaler를 적용한 후 대규모 이벤트도 문제없이 처리했습니다. 노드가 자동으로 50개까지 늘어났다가 이벤트 종료 후 다시 5개로 줄어들었습니다. "이제 새벽에 노드 추가하느라 일어나지 않아도 되겠어요!" Cluster Autoscaler를 활용하면 인프라 레벨에서 완전한 자동화를 구현할 수 있습니다. 여러분도 클라우드 환경에서 Cluster Autoscaler를 활성화해 보세요. **실전 팁** 💡 - scale-down 시간은 최소 5-10분으로 설정하세요 - 중요한 서비스에는 PodDisruptionBudget을 반드시 설정하세요 - 클라우드별로 설정 방법이 다르니 공식 문서를 참고하세요 --- ## 6. 스케일링_전략 모든 오토스케일링 도구를 마스터한 김개발 씨는 이제 종합적인 전략을 세울 차례였습니다. HPA, VPA, Cluster Autoscaler를 언제 어떻게 조합해야 할까요? 박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다. "각 도구의 장단점을 이해하고 상황에 맞게 조합해야 합니다." **스케일링 전략**은 서비스 특성에 따라 HPA, VPA, Cluster Autoscaler를 적절히 조합하는 것입니다. CPU 집약적 vs 메모리 집약적, 예측 가능한 트래픽 vs 불규칙한 트래픽, 비용 우선 vs 성능 우선 등 다양한 요소를 고려해야 합니다. 다음 코드를 살펴봅시다. ```python # 전략 1: API 서버 - HPA + Cluster Autoscaler # CPU 기반으로 파드 개수 조절, 노드 부족 시 자동 추가 apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: api-server-strategy spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: api-server minReplicas: 5 maxReplicas: 100 metrics: - type: Resource resource: name: cpu target: type: Utilization averageUtilization: 70 behavior: scaleUp: stabilizationWindowSeconds: 30 # 빠른 스케일 아웃 policies: - type: Percent value: 100 # 한 번에 2배까지 증가 가능 periodSeconds: 15 scaleDown: stabilizationWindowSeconds: 300 # 천천히 스케일 인 ``` 김개발 씨는 지난 몇 달간 오토스케일링의 모든 것을 배웠습니다. HPA로 파드 개수를 조절하고, VPA로 파드 크기를 최적화하고, Cluster Autoscaler로 노드를 관리했습니다. 하지만 이제 새로운 의문이 생겼습니다. "이 도구들을 다 써야 하나요? 아니면 골라서 써야 하나요?" 박시니어 씨가 회의실로 김개발 씨를 불렀습니다. 화이트보드에는 여러 서비스 시나리오가 그려져 있었습니다. "각 서비스마다 적합한 전략이 다릅니다. 함께 분석해 봅시다." 그렇다면 어떻게 전략을 세워야 할까요? 쉽게 비유하자면, 교통수단을 선택하는 것과 같습니다. 가까운 거리는 걸어가고, 중간 거리는 자전거나 버스, 먼 거리는 지하철이나 비행기를 탑니다. 목적지, 시간, 비용을 고려해서 최적의 수단을 선택합니다. 마찬가지로 오토스케일링도 **서비스 특성, 트래픽 패턴, 비용 제약**을 고려해서 적절한 도구를 선택하고 조합해야 합니다. 전략 없이 무작정 적용하면 어떻게 될까요? 모든 도구를 다 사용하면 오히려 복잡도만 증가하고 예측 불가능한 동작이 발생합니다. 예를 들어 HPA와 VPA를 같은 리소스에 적용하면 충돌이 일어납니다. 반대로 아무것도 사용하지 않으면 트래픽 급증 시 장애가 발생합니다. 적절한 균형과 조합이 필요합니다. 바로 이런 문제를 해결하기 위해 **스케일링 전략**이 필요합니다. 전략을 수립하면 **서비스 특성에 딱 맞는 오토스케일링**을 구현할 수 있습니다. 또한 **비용과 성능의 균형**을 찾을 수 있습니다. 무엇보다 **예측 가능하고 안정적인 서비스 운영**이 가능하다는 큰 이점이 있습니다. 대표적인 전략 패턴을 살펴보겠습니다. **전략 1: API 서버 - HPA + Cluster Autoscaler** 일반적인 웹 API 서비스는 CPU를 주로 사용합니다. 트래픽이 증가하면 CPU 사용률이 올라가므로 HPA가 적합합니다. 파드가 많아져서 노드가 부족하면 Cluster Autoscaler가 노드를 추가합니다. VPA는 사용하지 않고 리소스를 고정값으로 설정합니다. **전략 2: 데이터 처리 배치 - VPA 단독** 배치 작업은 파드 개수를 늘리는 것보다 파드 크기를 키우는 게 효과적인 경우가 많습니다. 데이터를 메모리에 로드해서 처리하므로 메모리가 중요합니다. VPA를 사용해서 실제 메모리 사용량에 맞춰 리소스를 자동 조정합니다. **전략 3: 큐 워커 - HPA(커스텀 메트릭) + Cluster Autoscaler** 메시지 큐를 처리하는 워커는 큐 길이를 기준으로 스케일링해야 합니다. CPU가 여유가 있어도 큐가 쌓이면 파드를 늘려야 합니다. 커스텀 메트릭 HPA를 사용하고, 노드 부족 시 Cluster Autoscaler가 대응합니다. **전략 4: 머신러닝 추론 - VPA + Cluster Autoscaler** ML 모델은 메모리를 많이 사용하지만 CPU는 적게 씁니다. 모델 크기에 따라 필요한 메모리가 다르므로 VPA가 적합합니다. 파드 개수는 고정하고 VPA로 리소스를 최적화합니다. 위의 코드를 자세히 살펴보겠습니다. `behavior` 섹션은 스케일링 속도를 제어합니다. `scaleUp.stabilizationWindowSeconds: 30`은 스케일 아웃을 빠르게 수행합니다. 트래픽 급증 시 신속하게 대응하기 위함입니다. `policies`에서 `value: 100`은 한 번에 최대 100%(2배)까지 증가할 수 있다는 의미입니다. 반면 `scaleDown.stabilizationWindowSeconds: 300`은 스케일 인을 천천히 수행합니다. 5분 동안 관찰한 후 파드를 줄입니다. 이렇게 하면 트래픽이 일시적으로 줄었다가 다시 증가하는 경우에도 안정적으로 대응할 수 있습니다. 실제 현업에서는 어떻게 활용할까요? 예를 들어 유튜브 같은 동영상 플랫폼을 생각해봅시다. 웹 API 서버는 전략 1(HPA + CA)을 사용하고, 동영상 인코딩 워커는 전략 3(커스텀 메트릭 HPA + CA)을 사용하고, 추천 알고리즘 서버는 전략 4(VPA + CA)를 사용합니다. 각 컴포넌트의 특성에 맞는 전략을 적용해서 최적의 성능과 비용을 달성합니다. 전략을 수립할 때 고려할 점은 무엇일까요? 첫째, **서비스의 리소스 특성**을 파악하세요. CPU 집약적인지, 메모리 집약적인지, I/O 집약적인지 분석합니다. 둘째, **트래픽 패턴**을 이해하세요. 예측 가능한 패턴인지, 불규칙한 패턴인지에 따라 전략이 달라집니다. 셋째, **비용과 성능 우선순위**를 정하세요. 비용 절감이 중요하면 aggressive한 scale-down을, 성능이 중요하면 보수적인 scale-down을 설정합니다. 하지만 주의할 점도 있습니다. 초보 개발자들이 흔히 하는 실수는 **모든 서비스에 동일한 전략을 적용**하는 것입니다. "HPA + VPA + CA를 다 쓰면 되겠지"라고 생각하지만, 이렇게 하면 충돌이 발생하고 관리가 복잡해집니다. 각 서비스의 특성을 분석하고 **필요한 도구만 선택적으로 사용**해야 합니다. 또 다른 실수는 **너무 공격적인 스케일링**입니다. 빠르게 늘리고 빠르게 줄이면 파드가 계속 재시작되어 서비스가 불안정해집니다. 스케일 아웃은 빠르게, 스케일 인은 천천히 하는 **비대칭 전략**이 일반적으로 안전합니다. 마지막으로 **모니터링과 알람**을 반드시 설정하세요. 오토스케일링이 제대로 동작하는지, 비정상적인 스케일링이 발생하는지 지속적으로 관찰해야 합니다. Grafana, Prometheus로 대시보드를 만들고, 이상 징후 발생 시 Slack으로 알람을 받도록 설정하세요. 다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 자신의 서비스를 분석했습니다. API 서버는 HPA + CA, 이미지 처리 워커는 커스텀 메트릭 HPA, 데이터 분석 배치는 VPA를 적용했습니다. 결과는 놀라웠습니다. 서비스 안정성은 높아지고 비용은 40% 절감되었습니다. "오토스케일링은 단순히 도구를 사용하는 게 아니라, 서비스를 깊이 이해하고 전략을 세우는 것이군요!" 스케일링 전략을 제대로 수립하면 안정적이고 비용 효율적인 서비스를 운영할 수 있습니다. 여러분도 자신의 서비스 특성을 분석해서 최적의 전략을 찾아보세요. **실전 팁** 💡 - 스케일 아웃은 빠르게, 스케일 인은 천천히 하는 비대칭 전략을 사용하세요 - 각 서비스 컴포넌트별로 다른 전략을 적용하세요 - 모니터링 대시보드를 만들어서 스케일링 동작을 지속적으로 관찰하세요 --- 이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!

카테고리: Kubernetes

언어: Python

태그: Kubernetes, HPA, VPA, Autoscaling, CloudNative

작성자: AI Generated

프리미엄 콘텐츠 - 3개월 무료 체험 가능

CodeDeck

오토스케일링 완벽 가이드

목차

1. HPA 개념

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

3. 커스텀 메트릭 스케일링

4. VPA 개념

5. Cluster Autoscaler

6. 스케일링 전략

댓글 (0)

함께 보면 좋은 카드 뉴스

VPC 네트워크의 기초 - CIDR과 서브넷 설계 완벽 가이드

AWS 리소스 정리와 비용 관리 완벽 가이드

AWS 고가용성과 내결함성 아키텍처 설계 기초

이스티오 기반 마이크로서비스 플랫폼 완벽 가이드

Kubernetes 프로덕션 완벽 가이드