DevOps 지식 허브
DevOps 지식 허브

Kubernetes HPA (Horizontal Pod Autoscaler) 튜닝 실용 가이드

Kubernetes HPA (Horizontal Pod Autoscaler) 튜닝에 대한 이 실용 가이드를 통해 최적의 애플리케이션 성능과 비용 효율성을 확보하세요. CPU, 사용자 정의 및 외부 메트릭을 사용하여 HPA를 구성하는 방법을 배우고, `stabilizationWindowSeconds` 및 `policies`를 사용하여 고급 스케일링 동작을 마스터하세요. 이 문서는 Kubernetes 배포가 변동하는 부하에 동적으로 적응하고, 리소스 과잉 프로비저닝을 방지하며, 높은 가용성을 유지하도록 보장하는 실행 가능한 단계, 코드 예제 및 모범 사례를 제공합니다.

29 조회수

Kubernetes HPA(Horizontal Pod Autoscaler) 튜닝 실용 가이드

쿠버네티스는 애플리케이션 배포, 관리 및 확장 방식을 혁신했습니다. 확장 기능의 핵심에는 Horizontal Pod Autoscaler(HPA)가 있습니다. HPA는 CPU 사용량 또는 기타 선택된 메트릭을 기반으로 배포, 복제 컨트롤러, 복제셋 또는 스테이트풀셋의 파드 복제본 수를 자동으로 조정하는 강력한 메커니즘입니다. HPA는 변동하는 로드를 처리하는 데 엄청난 이점을 제공하지만, 신중한 구성과 튜닝을 통해 진정한 잠재력을 발휘할 수 있습니다.

이 가이드에서는 쿠버네티스 Horizontal Pod Autoscaler 구성 및 최적화의 실용적인 측면에 대해 알아봅니다. 기본 개념, 핵심 매개변수, 고급 튜닝 전략 및 모범 사례를 다루어 애플리케이션이 수요에 효율적으로 적응하고, 다양한 로드에서 성능을 유지하며, 인프라 비용을 최적화할 수 있도록 보장합니다. 이 글을 끝까지 읽으면 HPA를 최대한 활용하는 방법에 대한 확실한 이해를 얻게 될 것입니다.

Horizontal Pod Autoscaler (HPA) 이해하기

HPA는 현재 수요에 맞게 애플리케이션의 파드 수를 자동으로 확장하거나 축소합니다. HPA는 지정된 메트릭을 지속적으로 모니터링하고 대상 값과 비교합니다. 관찰된 메트릭이 대상을 초과하면 HPA는 스케일 업 이벤트를 시작하고, 대상 아래로 떨어지면 스케일 다운을 트리거합니다. 이러한 동적 조정은 프로비저닝 과잉 없이 애플리케이션이 최적으로 성능을 발휘하는 데 충분한 리소스를 확보하도록 보장합니다.

HPA는 다음을 기반으로 확장할 수 있습니다:

  • 리소스 메트릭: 주로 CPU 사용량 및 메모리 사용량 (metrics.k8s.io API를 통해 사용 가능하며, 일반적으로 쿠버네티스 Metrics Server에서 제공).
  • 사용자 지정 메트릭: custom.metrics.k8s.io API를 통해 노출되는 애플리케이션별 메트릭 (예: 초당 요청 수, 큐 깊이, 활성 연결 수). 일반적으로 prometheus-adapter와 같은 어댑터가 필요합니다.
  • 외부 메트릭: external.metrics.k8s.io API를 통해 노출되는 클러스터 외부 소스의 메트릭 (예: Google Cloud Pub/Sub 큐 크기, AWS SQS 큐 길이). 이 역시 외부 메트릭을 가져올 수 있는 사용자 지정 메트릭 API 서버가 필요합니다.

효과적인 HPA 튜닝을 위한 사전 요구 사항

HPA 구성을 시작하기 전에 다음 기본 요소가 준비되었는지 확인하십시오:

1. 정확한 리소스 요청 및 제한 정의

이것은 아마도 가장 중요한 사전 요구 사항일 것입니다. HPA는 사용량 백분율을 계산하기 위해 올바르게 정의된 CPU 및 메모리 요청에 크게 의존합니다. 파드에 CPU 요청이 정의되지 않은 경우 HPA는 CPU 사용량을 계산할 수 없으므로 CPU 기반 확장이 불가능합니다.

  • 요청 (Requests): 컨테이너에 대해 보장되는 최소 리소스를 정의합니다. HPA는 이러한 값을 사용하여 파드당 대상 사용량을 결정합니다.
  • 제한 (Limits): 컨테이너가 소비할 수 있는 최대 리소스를 정의합니다. 제한은 단일 파드가 과도한 리소스를 소비하여 동일한 노드의 다른 파드에 영향을 미치는 것을 방지합니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 1
  selector:
    matchLabels:
      app: my-app
  template:
    metadata:
      labels:
        app: my-app
    spec:
      containers:
      - name: my-container
        image: my-image:latest
        resources:
          requests:
            cpu: "200m"  # CPU 코어의 20%
            memory: "256Mi"
          limits:
            cpu: "500m"
            memory: "512Mi"

2. 쿠버네티스 Metrics Server 설치

HPA가 CPU 및 메모리 사용량 메트릭을 사용하려면 클러스터에 쿠버네티스 Metrics Server가 설치되어야 합니다. Kubelets에서 리소스 메트릭을 수집하여 metrics.k8s.io API를 통해 노출합니다.

3. 애플리케이션 가시성

사용자 지정 또는 외부 메트릭의 경우 애플리케이션이 관련 메트릭을 노출해야 하며 (예: Prometheus 엔드포인트를 통해) 이러한 메트릭을 수집하여 쿠버네티스 API에 노출할 방법이 필요합니다. 일반적으로 Prometheus 어댑터 또는 사용자 지정 메트릭 API 서버를 사용합니다.

HPA 구성: 핵심 매개변수

HPA 매니페스트의 기본 구조를 살펴보겠습니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70

주요 매개변수:

  • scaleTargetRef: HPA가 확장할 대상 리소스 (예: Deployment)를 정의합니다. apiVersion, kind, name을 지정합니다.
  • minReplicas: HPA가 축소할 최소 파드 수입니다. 높은 가용성을 위해 최소 1 또는 2로 설정하는 것이 좋습니다. (부하가 0일 때도)
  • maxReplicas: HPA가 확장할 최대 파드 수입니다. 이는 과도한 확장을 방지하고 비용을 제한하는 안전 장치 역할을 합니다.
  • metrics: HPA가 모니터링해야 하는 메트릭을 정의하는 배열입니다.
    • type: Resource, Pods, Object 또는 External이 될 수 있습니다.
    • resource.name: Resource 유형의 경우 cpu 또는 memory를 지정합니다.
    • target.type: Resource 유형의 경우, Utilization (요청된 리소스의 백분율) 또는 AverageValue (절대값)입니다.
    • averageUtilization: Utilization 유형의 경우, 대상 백분율입니다. HPA는 current_utilization / target_utilization * current_pods_count를 기반으로 원하는 파드 수를 계산합니다.

응답성 및 안정성을 위한 HPA 튜닝

기본 구성 외에도 HPA는 autoscaling/v2 (또는 이전 버전의 v2beta2)를 통해 고급 튜닝 옵션을 제공하여 스케일링 동작을 보다 세밀하게 관리하고 "쓰래싱" (빠른 스케일 업 및 스케일 다운 주기)을 방지합니다.

1. CPU 및 메모리 대상 (averageUtilization / averageValue)

올바른 대상 사용량을 설정하는 것이 중요합니다. 낮은 대상은 더 빠른 확장 (더 반응성이 좋지만 비용이 더 많이 들 수 있음)을 의미하고, 높은 대상은 더 느린 확장 (덜 반응성이 좋지만 비용이 저렴할 수 있지만 성능 저하 위험)을 의미합니다.

  • 최적의 대상 결정 방법: 로드 테스트 및 프로파일링이 가장 중요합니다. 애플리케이션에 부하를 점진적으로 증가시키면서 리소스 사용량 및 성능 메트릭 (지연 시간, 오류율)을 모니터링합니다. 애플리케이션의 성능이 저하되기 시작하는 CPU/메모리 사용량을 식별합니다. 이 임계값보다 낮은 HPA 대상을 설정합니다. 일반적으로 CPU의 경우 60-80% 범위입니다.
  • 균형 잡힌 접근: 예기치 않은 스파이크에 대한 충분한 여유를 두되, 지속적으로 프로비저닝 과잉 상태가 되지 않도록 너무 낮은 값을 설정하지 않는 대상을 목표로 합니다.

2. 스케일링 동작 (behavior 필드)

HPA autoscaling/v2에서 도입된 behavior 필드는 스케일 업 및 다운 이벤트에 대한 세밀한 제어를 제공하여 "쓰래싱" (빠른 스케일 업 및 스케일 다운 주기)을 방지합니다.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleUp:
      stabilizationWindowSeconds: 60 # 다시 스케일 업하기 전에 60초 대기
      policies:
      - type: Pods
        value: 4
        periodSeconds: 15 # 15초마다 최대 4개의 파드 추가
      - type: Percent
        value: 100
        periodSeconds: 15 # 또는 15초마다 현재 파드 수의 100% 증가 (더 제한적이지 않은 쪽 선택)
    scaleDown:
      stabilizationWindowSeconds: 300 # 스케일 다운하기 전에 5분 대기
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # 60초마다 최대 50%의 파드 제거
      selectPolicy: Max # '가장 공격적인' (적은 수의) 파드를 허용하는 정책 선택

scaleUp 구성:

  • stabilizationWindowSeconds: 빠른 스케일 업/다운 주기 (플래핑)를 방지합니다. HPA는 스케일 업 시 이 창의 메트릭을 고려하여 고조된 메트릭이 지속될 때만 스케일 업하도록 합니다. 일반적인 값은 30-60초입니다.
  • policies: 스케일 업 이벤트 중에 파드가 추가되는 방식을 정의합니다. 여러 정책을 정의할 수 있으며 HPA는 더 많은 수의 파드를 허용하는 정책 (가장 공격적인 스케일 업)을 사용합니다.
    • type: Pods: 고정된 수의 파드로 확장합니다. value는 추가할 파드 수를 지정합니다. periodSeconds는 이 정책이 적용되는 시간 창을 정의합니다.
    • type: Percent: 현재 파드 수의 백분율로 확장합니다. value는 백분율입니다.

scaleDown 구성:

  • stabilizationWindowSeconds: scaleDown에 더 중요합니다. HPA가 스케일 다운을 고려하기 전에 대상 아래의 메트릭을 관찰해야 하는 시간을 지정합니다. 일시적인 감소 시기에 조기 스케일 다운을 방지하여 "콜드 스타트" 및 성능 저하를 피하기 위해 더 긴 창 (예: 300-600초)을 사용합니다. 안정적인 환경을 위한 중요한 설정입니다.
  • policies: scaleUp과 유사하게 파드가 제거되는 방식을 정의합니다. HPA는 selectPolicy가 Min인 경우 가장 적은 수의 파드를 결과로 하는 정책을 사용하고, selectPolicy가 Max인 경우 가장 많은 수의 파드를 결과로 하는 정책을 사용합니다.
    • type: Pods: 고정된 수의 파드를 제거합니다.
    • type: Percent: 현재 파드의 백분율을 제거합니다.

  • selectPolicy: 여러 scaleDown 정책이 정의된 경우 어떤 정책을 적용할지 결정합니다. Min은 기본값이지만 일반적으로 보수적인 다운 스케일링에 권장됩니다. Max는 가장 많은 수의 파드를 결과로 하는 정책 (가장 덜 공격적인 다운 스케일링)을 선택합니다.

  • 경고: 공격적인 scaleDown 정책 또는 짧은 stabilizationWindowSeconds를 scaleDown에 사용할 때는 주의하십시오. 애플리케이션의 초기화 시간이 길거나 상태 저장 연결을 처리하는 경우 빠른 다운 스케일링은 서비스 중단 또는 사용자 지연 시간 증가를 초래할 수 있습니다.

고급 HPA 메트릭 및 전략

CPU 및 메모리가 일반적이지만 많은 애플리케이션이 실제 워크로드를 더 잘 반영하는 사용자 지정 또는 외부 메트릭에서 더 잘 확장됩니다.

1. 사용자 지정 메트릭

CPU/메모리가 애플리케이션의 로드 또는 성능 병목 현상의 직접적인 지표가 아닐 때 사용자 지정 메트릭을 사용합니다. 예: 초당 HTTP 요청 수 (QPS), 활성 연결 수, 메시지 큐 길이, 배치 작업 백로그.

사용자 지정 메트릭을 사용하려면:
1. 애플리케이션은 이러한 메트릭을 노출해야 합니다 (예: Prometheus exporter를 통해).
2. 이러한 메트릭을 스크랩하여 custom.metrics.k8s.io API를 통해 노출할 수 있는 사용자 지정 메트릭 어댑터를 배포합니다 (예: prometheus-adapter).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-app-hpa-qps
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 15
  metrics:
  - type: Pods # 메트릭이 배포 전체에 대한 것이라면 Object 사용
    pods:
      metric:
        name: http_requests_per_second # 애플리케이션/어댑터에서 노출된 메트릭 이름
      target:
        type: AverageValue
        averageValue: "10k" # 파드당 초당 10,000개 요청 목표

2. 외부 메트릭

애플리케이션의 워크로드가 쿠버네티스에서 직접 실행되지 않는 외부 시스템에 의해 구동될 때 외부 메트릭이 유용합니다. 예: AWS SQS 큐 깊이, Kafka 토픽 지연, Pub/Sub 구독 백로그.

외부 메트릭을 사용하려면:
1. 외부 시스템에서 메트릭을 가져올 수 있는 사용자 지정 메트릭 API 서버가 필요합니다 (예: AWS CloudWatch 또는 GCP Monitoring용 특정 어댑터).

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: my-worker-hpa-sqs
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-worker
  minReplicas: 1
  maxReplicas: 20
  metrics:
  - type: External
    external:
      metric:
        name: aws_sqs_queue_messages_visible # 외부 소스의 메트릭 이름
        selector:
          matchLabels:
            queue: my-queue-name
      target:
        type: AverageValue
        averageValue: "100" # 파드당 큐에 보이는 메시지 100개 목표

3. 여러 메트릭

HPA는 여러 메트릭을 동시에 모니터링하도록 구성할 수 있습니다. 여러 메트릭이 지정되면 HPA는 각 메트릭에 대해 원하는 복제본 수를 독립적으로 계산한 다음 이러한 원하는 복제본 수 중 가장 큰 수를 선택합니다. 이렇게 하면 애플리케이션이 관찰된 모든 로드 차원에 대해 충분히 확장됩니다.

# ... (HPA 기본 설정)
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70
  - type: Pods
    pods:
      metric:
        name: http_requests_per_second
      target:
        type: AverageValue
        averageValue: "10k"

모니터링 및 검증

효과적인 HPA 튜닝은 지속적인 모니터링 및 검증이 필요한 반복적인 프로세스입니다:

  • HPA 이벤트 관찰: kubectl describe hpa <hpa-name>을 사용하여 HPA의 상태, 이벤트 및 스케일링 결정을 확인합니다. HPA가 확장 또는 축소된 이유에 대한 귀중한 통찰력을 제공합니다.
  • 메트릭 및 복제본 모니터링: 관찰 가능성 스택 (예: Prometheus, Grafana)을 사용하여 애플리케이션의 리소스 사용량 (CPU, 메모리), 사용자 지정/외부 메트릭, 시간 경과에 따른 실제 파드 복제본 수를 시각화합니다. 들어오는 로드의 변화와 상관 관계를 파악합니다.
  • 로드 테스트: 예상되는 최대 부하를 시뮬레이션하여 HPA의 응답성을 검증하고 스트레스 상황에서 애플리케이션이 예상대로 성능을 발휘하는지 확인합니다. 이러한 테스트를 기반으로 HPA 매개변수를 조정합니다.

HPA 튜닝 모범 사례

  • 잘 정의된 리소스 요청/제한으로 시작: 정확한 리소스 기반 HPA의 기초입니다. 이것이 없으면 HPA는 CPU/메모리에 대해 효과적으로 작동할 수 없습니다.
  • 현실적인 minReplicas 및 maxReplicas 설정: minReplicas는 가용성을 위한 기본값을 제공하고, maxReplicas는 과도한 비용 및 리소스 고갈에 대한 안전망 역할을 합니다.
  • 대상 사용량 점진적으로 조정: 약간 보수적인 CPU 대상 (예: 60-70%)으로 시작하여 반복합니다. 지연 시간이나 처리 스파이크에 대한 버퍼를 남기지 않기 위해 100% 사용량을 목표로 하지 마십시오.
  • stabilizationWindowSeconds 활용: 빠른 스케일링 진동을 방지하는 데 필수적입니다. scaleUp (예: 1-2분)보다 scaleDown에 더 긴 창 (예: 5-10분)을 사용하여 안정성을 보장합니다.
  • 애플리케이션별 메트릭 우선순위 지정: CPU 또는 메모리가 애플리케이션 성능 병목 현상과 직접적으로 상관되지 않는 경우, 사용자 지정 또는 외부 메트릭을 사용하여 더 정확하고 효율적으로 확장합니다.
  • 모니터링, 테스트, 반복: HPA 튜닝은 일회성 설정이 아닙니다. 애플리케이션 동작, 트래픽 패턴 및 기본 인프라가 변경될 수 있습니다. HPA 성능을 정기적으로 검토하고 필요에 따라 설정을 조정합니다.
  • 애플리케이션의 확장 특성 이해: 요청 수에 따라 선형적으로 확장됩니까? 시작 시간이 깁니까? 상태 저장입니까? 이러한 특성은 HPA 전략에 영향을 미칩니다.

결론

쿠버네티스 Horizontal Pod Autoscaler는 쿠버네티스 환경에서 탄력적이고 비용 효율적이며 성능이 뛰어난 애플리케이션을 구축하는 데 중요한 구성 요소입니다. 핵심 메커니즘을 이해하고, 정확한 리소스 요청을 정의하고, 스케일링 동작 매개변수를 신중하게 튜닝함으로써 애플리케이션이 정밀하게 다양한 로드에 자동으로 적응하도록 보장할 수 있습니다.

효과적인 HPA 튜닝은 측정, 관찰 및 조정의 지속적인 여정입니다. 반복적인 프로세스를 수용하고, 적절한 경우 고급 메트릭을 활용하고, 애플리케이션 성능을 지속적으로 모니터링하여 쿠버네티스 내에서 동적 확장의 전체 잠재력을 발휘하십시오.