[kubernetes] hpa 사용시 주의할 점

1. hpa란

hpa란 HorizontalPodAutoscaler의 약자로 pod의 갯수를 조절해주는 k8s object입니다.
수평확장을 진행하는 object로 이를 래핑한 keda등 도 유명하지만 우선 hpa의 동작방법과 주의점을 알고있어야 합니다.

hpa의 형제격인 vpa도 존재하지만 vpa는 다운타임의 발생하는 등 단점이 존재하여 보통 hpa가 선호됩니다.

 

2. manifest

먼저 아래의 manifest를 분석하면
deployment의 replica 수를 1~10까지 조절해주되

조절하는 기준은 cpu의 평균이 50에 닿았을때 증설해달라는 요청입니다.

(memory기준으로 갈수도 있고, 외부 엔드포인트의 상황에 맞게 조절할수도 있으나 cpu기준으로 가는것이 정석적인 방식입니다)

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 50

3. 주의점

1) 평균의 함정

30~70%를 사용해서 50이 된다면 큰 문제가 없지만

20~80%을 사용한다면.. 간혹 100%를 치는 pod들이 존재한다면 이는 문제가 발생할 수 있습니다.

cpu 100% -> 프레임워크가 request를 처리하지 못함 -> probe 실패 -> restart 발생 
-> 나머지 pod에 부하 ->  처음부터 반복

이 과정이 반복되다가는 다수의 pod이 죽어버리며 과도한 증설이 발생하여 예상치못한 다량의 웜업, db커넥션이 발생하여 대형장애로 이어질 수 있습니다.

해결방안으로는 averageUtilization 수치를 낮추거나 pod의 request limit을 증대시키는게 일반적입니다.

 

2) 증설까지의 시간

실제 운영중인 서비스라고 가정하겠습니다.
minReplicas와 maxReplicas를 20 ~ 100 까지 맞춰놨습니다.

오후 8시 선착순 이벤트를 진행하기로 예정되어있습니다.

평소에는 20대만 떠있던 서비스지만 7시 50분쯤 되니 사용자가 늘어남에 따라 30대까지 확보가 되며 정상 동작하는듯 보입니다.

8시 00분 이벤트가 시작 된 순간 pod은 증설되지 않아 30대였으며 대부분의 요청에 timeout이 걸렸습니다.

8시 3분쯤 되자 pod이 60대까지 늘어났으나 이미 선착순 이벤트에 참여하지 못한 고객은 모두 이탈된 상황이었습니다.

매트릭이 수집되고 pod이 증설된 뒤 warm up 이후 probe가 확인되어 request가 들어가기까지는 서비스마다 상이하지만 보통 3분이상 소요됩니다.

hpa는 스파이크성 트래픽을 막는 용도가 아니니 주의해야 합니다.