[쿠버네티스] 오토 스케일링(HPA) 적용기

MSA 수강신청 프로젝트를 진행할 때,

시스템 가용성을 유지하기 위해 오토 스케일링을 적용해보게 되었다.

(애초에 오토 스케일링을 위해 MSA로 배포했다)

 

쿠버네티스는 Load Balancing, Persistance Volume 등 오케스트레이션에 도움이 되는 기능들을 제공한다.

 

이번에는 그 중 Horizontal Pod Autoscaler(HPA)를 사용했다.

 

 

HPA

HPA는 CPU, Memory와 같은 리소스 사용량에 따라 Pod의 개수를 조절하는 기능이다.

 

제한 리소스량을 yaml 파일을 통해 지정하면 해당 제한을 넘칠 경우 Pod이 늘어나고,다시 제한 아래로 일정시간 내려갈 경우 Pod이 줄어든다.(트래픽 분산의 경우 알아서 일어난다)

 

실제 사용했던 yaml 파일을 살펴보자.

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: lecturebe-hpa
  namespace: default
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: lecturebe
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

 

수강 신청 기능을 담당하는 백엔드에 대한 HPA yaml 파일 내용이다.

minReplicas: 1
maxReplicas: 10

 

최소 레플리카를 1개 오토 스케일링이 일어난 후 최대 레플리카를 10개로 설정한다.

(레플리카: 클러스터 내에서 동작하는 Pod 수)

 

약 10번의 부하 테스트를 직접 진행했을 때, 

1~2번을 제외하곤 모두 CPU 사용량의 폭발적인 증가로 인해 백엔드 서비스가 망가졌기 때문에

CPU 기준을 메모리보다 낮게 설정했다.

metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50
  - type: Resource
    resource:
      name: memory
      target:
        type: Utilization
        averageUtilization: 70

 

CPU의 경우 사용량 50프로, 메모리의 경우 사용량 70프로를 넘길 경우 오토 스케일링이 일어나게 된다.

 

behavior 필드를 통해 scaleDown, scaleUp에 대해 자세한 정책을 결정할 수 있다.

behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      policies:
      - type: Percent
        value: 10
        periodSeconds: 60

 

현재 예시에선 scaleDown에 대해서만 정의해놨다.

 

리소스 사용량이 기준치 아래로 내려갔다고 바로 스케일을 줄여버리면,

일시적인 트래픽 감소 이후 다시 증가하는 상황에서 서비스에 문제가 발생할 수 있다.

 

그래서 stabilizationWindowSeconds를 300초로 설정해서,

리소스 사용량을 300초 동안 살펴보고 스케일 다운을 판단하게 했다.

 

policies 를 이용해 pod의 개수를 줄일 때 60초마다 10퍼센트씩 줄이도록 설정했다.

 

마찬가지로, 한 번에 많은 Pod을 줄일 경우 안정성이 떨어질 수 있기 때문에 사용했다.

 

(찾아보니 퍼센트 말고도 직접적인 개수를 지정할 수 있다는데,

이때 여러 정책이 함께 설정되면 selectPolicy 필드를 이용해 어떤 정책을 우선시 할 지 설정 가능하다고 한다.

 

selectPolicy는 기본 값이 Max이며, Min으로 설정해 보다 느리게 스케일 다운이 일어나도록 설정가능하다.)

 

HPA 시 기준으로 삼을 Pod의 리소스도 지정해야한다.

 

필요하다 생각되는 리소스를 Deployment에 추가하면 된다.

spec:
      containers:
      - name: lecturebe
        
        ...
        
        resources:
          limits:
            cpu: 500m
            memory: "256Mi"
          requests:
            cpu: 200m
            memory: "128Mi"

 

request - 최소 리소스, limits - 최대 리소스

 

 

트러블슈팅

처음 HPA를 적용했을 때 타겟 서비스의 리소스 사용량을 가져오지 못하는 문제가 있었다.

unable to get metrics for resource cpu: unable to fetch metrics from resource metrics API: the server is currently unable to handle the request

 

이 경우 리소스 사용 통계를 생성해주는 metrics-server가 설치되지 않아서 그렇다.

 

다음 명령어를 이용해서 배포한다.

kubectl apply -f https://github.com/kubernetes-sigs/metrics-server/releases/latest/download/components.yaml

 

이때, 매트릭스 서버의 인증 구성이 되지 않았기 때문에 인증 구성 생략 내용을 deployment에 추가해야했다.

(어쩐지 동작을 안하더라)

args:
- ...
- ...
- --kubelet-insecure-tls

 

이제 metric-server Pod 이 잘 동작하고 있다면,

$ kubectl get hpa -w

명령을 통해 잘 적용된 것을 확인할 수 있다.

 

 

테스트 결과

 

각 HPA가 잘 적용되어 CPU 사용량이 50%를 넘어간 서비스의 경우 오토스케일링이 일어나

레플리카가 2개가 되면서 안정화하는 모습을 확인할 수 있었다.