DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

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

리소스 요청, 메트릭, 스케일 동작, 안정화 윈도우 및 검증 명령어를 사용하여 Kubernetes HPA를 튜닝합니다.

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

Kubernetes Horizontal Pod Autoscaler(HPA)는 트래픽 급증 시 앱의 응답성을 유지할 수 있게 해주지만, 메트릭과 제한이 앱의 동작 방식을 반영해야만 합니다. 제대로 튜닝되지 않은 HPA는 너무 늦게 스케일링하거나, 너무 빨리 축소하거나, 리소스 요청이 누락되어 전혀 스케일링하지 않을 수 있습니다.

이 가이드는 CPU, 메모리, 사용자 정의 메트릭, 외부 메트릭 및 스케일링 동작 제어를 사용하여 Kubernetes HPA를 튜닝하는 방법을 보여줍니다.

Horizontal Pod Autoscaler(HPA) 이해하기

HPA는 애플리케이션의 파드 수를 현재 수요에 맞게 자동으로 늘리거나 줄입니다. 지정된 메트릭을 지속적으로 모니터링하고 이를 목표 값과 비교합니다. 관찰된 메트릭이 목표를 초과하면 HPA는 스케일 업 이벤트를 시작하고, 목표 아래로 떨어지면 스케일 다운을 트리거합니다. 이 동적 조정을 통해 애플리케이션이 과도하게 프로비저닝되지 않으면서 최적으로 성능을 발휘할 수 있는 충분한 리소스를 확보할 수 있습니다.

HPA는 다음을 기준으로 스케일링할 수 있습니다.

  • 리소스 메트릭: 주로 CPU 사용률 및 메모리 사용률(metrics.k8s.io API를 통해 제공되며, 일반적으로 Kubernetes 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 기반 스케일링이 불가능합니다.

  • 요청: 컨테이너에 대한 최소 보장 리소스를 정의합니다. HPA는 이 값을 사용하여 파드당 목표 사용률을 결정합니다.
  • 제한: 컨테이너가 소비할 수 있는 최대 리소스를 정의합니다. 제한은 단일 파드가 과도한 리소스를 소비하여 동일한 노드의 다른 파드에 영향을 미치는 것을 방지합니다.
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. Kubernetes Metrics Server 설치

HPA가 CPU 및 메모리 사용률 메트릭을 사용하려면 클러스터에 Kubernetes Metrics Server가 설치되어 있어야 합니다. Kubelet에서 리소스 메트릭을 수집하고 metrics.k8s.io API를 통해 노출합니다.

3. 애플리케이션 관측 가능성

사용자 정의 또는 외부 메트릭의 경우 애플리케이션이 관련 메트릭(예: Prometheus 엔드포인트를 통해)을 노출해야 하며, 일반적으로 Prometheus 어댑터 또는 사용자 정의 메트릭 API 서버를 사용하여 이러한 메트릭을 수집하고 Kubernetes 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로 설정하는 것이 좋습니다.
  • 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/메모리 사용률을 식별합니다. 일반적으로 CPU의 경우 60-80% 범위에서 이 임계값 아래로 HPA 목표를 설정합니다.
  • 균형 유지: 예상치 못한 급증을 처리할 수 있는 충분한 여유를 두지만 지속적으로 과도하게 프로비저닝되지 않을 정도로 낮은 목표를 목표로 합니다.

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초마다 현재 파드 수를 두 배로 늘림(덜 제한적인 쪽 선택)
    scaleDown:
      stabilizationWindowSeconds: 300 # 스케일 다운 전에 5분 대기
      policies:
      - type: Percent
        value: 50
        periodSeconds: 60 # 60초마다 최대 50%의 파드 제거
      selectPolicy: Max # 가장 큰 허용 스케일 다운 변경을 허용하는 정책 선택

scaleUp 구성:

  • stabilizationWindowSeconds: 최근 시간 창에 걸쳐 스케일링 권장 사항을 평활화합니다. 스케일 업은 일반적으로 앱이 빠르게 반응할 수 있도록 짧은 창을 사용합니다.
  • policies: 스케일 업 이벤트 중에 파드가 추가되는 방식을 정의합니다. 여러 정책을 정의할 수 있으며 HPA는 가장 많은 수의 파드(가장 공격적인 스케일 업)를 허용하는 정책을 사용합니다.
    • type: Pods: 고정된 수의 파드로 스케일 업합니다. value는 추가할 파드 수를 지정합니다. periodSeconds는 이 정책이 적용되는 시간 창을 정의합니다.
    • type: Percent: 현재 파드 수의 백분율로 스케일 업합니다. value는 백분율입니다.

scaleDown 구성:

  • stabilizationWindowSeconds: scaleDown에 더 중요하며, HPA가 스케일 다운을 고려하기 전에 메트릭이 목표 아래에 있어야 하는 시간을 지정합니다. 더 긴 창(예: 300-600초)은 일시적인 침체 동안 조기 스케일 다운을 방지하여 "콜드 스타트" 및 성능 저하를 피합니다. 이는 안정적인 환경을 위한 중요한 설정입니다.

  • policies: scaleUp과 유사하게 파드가 제거되는 방식을 정의합니다. selectPolicy가 Min이면 HPA는 가장 적은 수의 파드(가장 공격적인 스케일 다운)를 초래하는 정책을 사용하고, selectPolicy가 Max이면 가장 많은 수의 파드(가장 보수적인 스케일 다운)를 초래하는 정책을 사용합니다.

    • type: Pods: 고정된 수의 파드를 제거합니다.
    • type: Percent: 현재 파드의 백분율을 제거합니다.

  • selectPolicy: 여러 scaleDown 정책이 정의된 경우 적용할 정책을 결정합니다. Max가 기본값이며 가장 큰 스케일 변경을 허용하는 정책을 선택합니다. 더 보수적인 다운스케일링을 원할 때 Min을 사용합니다.

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

고급 HPA 메트릭 및 전략

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

1. 사용자 정의 메트릭

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

사용자 정의 메트릭을 사용하려면:

  1. 애플리케이션이 이러한 메트릭을 노출해야 합니다(예: Prometheus 내보내기를 통해).
  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. 외부 메트릭

외부 메트릭은 애플리케이션의 워크로드가 Kubernetes에서 직접 실행되지 않는 외부 시스템에 의해 구동될 때 유용합니다. 예: 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 전략에 영향을 미칩니다.

최종 요점

HPA 튜닝을 피드백 루프로 취급하십시오. 정확한 리소스 요청으로 시작하고, 현실적인 minReplicas 및 maxReplicas를 설정하고, 실제 수요를 추적하는 메트릭을 선택하고, 프로덕션 트래픽이 이에 의존하기 전에 부하 테스트로 스케일 업 및 다운 동작을 검증하십시오.