King of Back-end

쿠버네티스 클러스터에는 3가지의 AutoScaler 가 있습니다. HPA, VPA, CA 죠.
 
간단히 설명해보자면,
HPA : Horizontal Pod Autoscaler 의 줄임말로, 파드의 갯수를 확장/축소 해줌
VPA : Vertical Pod Autoscaler 의 줄임말로, 파드의 갯수가 아닌 지정된 리소스를 확장/축소 해줌
CA : Cluster Autoscaler 의 줄임말로, 노드의 갯수를 확장/축소 해줌
 
HPA, VPA 는 Metrics Server 가 설치되어 있어야 하며, 또 VPC 같은 경우는 따로 설치해주어야 합니다.
 
그리고 CA 는 보통 Karpenter 를 사용합니다.
 
이번 글에서는 HPA 에 대해 다뤄보고자 하는데, 사실 HPA 는 어려운 개념이 크게 없다고 생각합니다. 따라서 개념을 설명하기 보다는 HPA 가 어떤 과정을 거쳐 파드 갯수를 확장/축소하는지 알고리즘 동작방식에 초점을 맞추고자 합니다.
 
그럼 렛츠두더코드~
 
 
 
개념
 
한번 간단히 개념을 짚고 넘어가보죠.
 
 
HPA 는 쿠버네티스 컴포넌트 중의 하나인 컨트롤러 매니저에 의해 관리됩니다.
HorizontalPodAutoscaler 매니페스트에 지정된 메트릭에 대해 리소스 사용률을 주기적으로 Metrics Server 에게 질의합니다.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  namespace: hpa-example
spec:
  maxReplicas: 10
  minReplicas: 2  
  metrics:
    - resource:
        name: memory
        target:
          averageUtilization: 75
          type: Utilization
      type: Resource
    - resource:
        name: cpu
        target:
          averageUtilization: 75
          type: Utilization
      type: Resource
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: hpa-example
 
Autoscaling API Version 은 alpha, beta, v1, v2 등 다양한 버전이 있으니 사용에 주의하시기 바랍니다.
 
메트릭은 Metrics Sever 에서 가져오고, 주기는 기본적으로 15초이며, kube-controller-manager 의 --horizontal-pod-autoscaler-sync-period 파라미터에 의해 설정됩니다.
 
Metrics Server 말고 Prometheus Adapter 와 같은 외부 메트릭 서버에 질의 할 수도 있습니다.
 
가장 기본적으로 확장/축소 될 때 적용되는 갯수는 아래와 같은 알고리즘을 따릅니다.
(autoscaling/v2 부터 채택된 behavior 라는 옵션을 주면 다른 방식으로 할 수 있는데 다음 글에서 다루겠습니다)
원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]
 
알아둘 점은 공식문서에서 말하듯, 메트릭 값이 정확하게 계산되지 않기 때문에 때로는 HPA 가 스케줄링되지 않는 상황이 발생할 수도 있습니다.
 
그럼 이제 실습을 통해서 더 자세히 알아보죠!
 
 
ScaleUp 실습
 
예제에 사용되는 매니페스트는 공식 문서에 사용되는 것을 사용하겠습니다.
apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-apache
spec:
  selector:
    matchLabels:
      run: php-apache
  replicas: 1
  template:
    metadata:
      labels:
        run: php-apache
    spec:
      containers:
        - name: php-apache
          image: registry.k8s.io/hpa-example
          ports:
            - containerPort: 80
          resources:
            limits:
              cpu: 300m
            requests:
              cpu: 200m
---
apiVersion: v1
kind: Service
metadata:
  name: php-apache
  labels:
    run: php-apache
spec:
  ports:
    - port: 80
  selector:
    run: php-apache
---
apiVersion: autoscaling/v1
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  minReplicas: 1
  maxReplicas: 10
  targetCPUUtilizationPercentage: 50
autoscaling/v1 버전을 사용하고 있는데, v2 를 사용하고 싶다면 수정하셔야 합니다.
.containers[].resources 에 값을 명시하지 않으면 HPA 동작하지 않으니 반드시 명시해줍니다. 
HPA 는 .resources.requests 의 값을 사용하기 때문이죠.
minReplicas 를 0 으로 지정하면 에러가 발생합니다.
 
배포 한 후에 아래 명령어를 통해 생성된 파드에 부하를 줍니다.
$ kubectl run -i --tty load-generator --rm --image=busybox:1.28 --restart=Never -- /bin/sh -c "while sleep 0.01; do wget -q -O- http://php-apache; done"
 
부하를 준 후 10분 동안 관찰을 한 결과 입니다.
 
--horizontal-pod-autoscaler-sync-period 의 기본 값이 15초 이기 때문에 AGE 필드를 보면 대략 15초마다 평가가 된 것을 확인할 수 있습니다. 
 
그리고 4개 이상은 생성되지 않는 걸 보니 명령어 "while sleep 0.01; do wget -q -O- http://php-apache; done" 을 처리하는데 3개의 파드만 있으면 충분하단 걸 알 수 있습니다.
 
노랑색 네모는 레플리카 갯수가 증가하기 전을 표시하고 있는데, 아래 알고리즘에 의해 정말 갯수가 증가되는 지를 확인해보겠습니다. 
원하는 레플리카 수 = ceil[현재 레플리카 수 * ( 현재 메트릭 값 / 원하는 메트릭 값 )]
ceil 은 올림을 뜻합니다. 반대인 floor 는 버림을 뜻합니다. ceil 은 천장이여서 올림, floor 은 바닥이여서 버림으로 외우면 안헷갈리죠.
 
첫번째 노랑색 네모는 알고리즘에 의해 다음 평가(15초 뒤) 때 레플리카가 2개로 늘어나는 것을 확인할 수 있습니다.
 
두번째 노랑색 네모는 3개로 늘어나는 것을 확인할 수 있습니다.
 
메트릭 값은 같은 경우 그냥 퍼센트로 했는데, 아래처럼 계산해도 같은 값이 나옵니다.
파드들의 현재 메트릭 평균 값 / (파드들의 평균 request 값 * targetCPUUtilizationPercentage)
 
 
ScaleDown 실습
 
이번엔 ScaleDown 을 알아보겠습니다. 
 
메트릭 값은 수시로 변하는 동적 특성 때문에 레플리카 갯수가 자주 요동칠 수 있습니다. 이러한 현상을 thrashing 또는 flapping 이라고 부르며, 이를 방지하기 위해 stabilization window (안정화 윈도우) 라는 새로운 개념이 등장합니다.
 
HPA 는 스케일 권장 사항을 평가 시간 때마다 window 에 기록하며 5분(기본값)이 되는 시점에 window 에서 가장 높은 숫자를 선택해 스케일을 진행합니다.
 
여기서 5분은 --horizontal-pod-autoscaler-downscale-stabilization (기본값 5분) 에 의해 설정되며, 마찬가지로 kube-controller-manager 에 파라미터로 넘기면 됩니다.
 
그리고 window 는 ScaleDown 때 사용됩니다.
autoscailing/v2 의 behavior 옵션을 통해 ScaleUp 에도 사용할 수 있습니다. 뒤에서 다룹니다.
 
이제 명령어 "while sleep 0.01; do wget -q -O- http://php-apache; done" 를 중단해보죠.
그럼 최종적으로 다시 파드의 갯수가 3개 -> 1개가 된 것을 확인할 수 있습니다.
 
그런데 이미지를 보면 살짝 이상한 부분이 있으실 겁니다. 3개 -> 2개가 되는 구간의 TARGETS 를 계산해보면 2개 아닌 1개가 되야 합니다.
 
1이 아닌 이유는 바로 Sync Period 마다 바로바로 평가가 반영되는 ScaleUp 과 달리 ScaleDown 은 window 를 참고하게 됩니다.
 
여기서 window 는 우리가 아는 큐(Queue) 로 생각하면 쉽습니다. 리스트이며 FIFO 방식으로 동작하게 되죠.
 
44분 15초부터 명령어 "while sleep 0.01; do wget -q -O- http://php-apache; done" 을 중단해서 부하를 끊었습니다.
이때 window 에는  [3, 3, 3, .... 3, 3] 만 존재하게 될 것입니다.
 
15초마다 평가되고 5분이라는 stabilization 이라는 값을 가지므로 window 에는 총 1분당 4번 평가 * 5분 = 20 개의 값이 존재하게 됩니다. 3은 현재의 레플리카 갯수입니다.
 
[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3 ,3, 3, 3 ,3, 3, 3, 3]
 
2번째(44분 30초, 29%/50%)를 계산해보면 원하는 레플리카 갯수가 2개이므로, windows 에는 2 가 들어가게 됩니다.
그리고 FIFO 방식이기 때문에 가장 앞에 있는 3 이 빠지게 되죠.
[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3 ,3, 3, 3 ,3, 3, 3, 2]
 
하지만 HPA 는 가장 높은 수를 바라보기 때문에 여전히 레플리카 갯수는 3개입니다.
 
3번째(44분 45초, 1%/50%) 에는 HPA 알고리즘에 의해서 1 이 들어가게 됩니다. 그리고 가장 앞에 있는 3 이 또 빠지죠.
[3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3, 3 ,3, 3, 3 ,3, 3, 3, 2, 1]
 
 
4번째부터는 갑자기 5분을 건너뛴 49분 15초에 로그가 찍혔습니다. --horizontal-pod-autoscaler-downscale-stabilization 의 기본값이 5분이기 때문이죠.
 
딱 4번째(49분 15초, 1%/50%) 순간까지는 window 에 3 이 하나만 존재하고 있을 것이고, 동시에 1 이 window 에 들어와야 합니다.
[3, 2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
 
5번째(49분 30초, 1%/50%)  에 또 1 이 들어올 것이고, 이제 더 이상 3 은 windows 에 없게 됩니다.
따라서 가장 큰 숫자인 2 를 HPA 가 채택하게 되고,  현재 레플리카 갯수가 드디어 2 로 됩니다.
[2, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
 
6번째(49분 45초, 1%/50%) 에 또 1 이 들어올 것이고, 이제 더 이상 2 도 window 에 없게 됩니다.
window 엔 이제 1만 존재하게 되고, 최종적으로 레플리카 갯수는 1 이 됩니다.
[1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]
 
지금까지 알아본 동작은 아주 기본적인 설정값으로 진행된 동작 방식이였는데, autoscaling/v2 에 추가된 behavior 를 사용하면 커스텀한 스케일을 사용할 수 있습니다.
 
 
Behavior
 
behavior 필드는 autoscaling/v2beta2 버전부터 제공되었으며, 현재 autoscaling/v2 를 통해 안정화 버전이 사용 가능합니다.
 
behavior 필드를 통해 스케일업 동작과 스케일다운 동작을 별도로 구성할 수 있습니다. 덕분에 ScaleDown 때만 적용되던 stabilization window 을 이제 ScaleUp 때도 사용할 수 있어 thrashing(flapping) 을 방지 할 수 있습니다.
 
예를 들어, 파드로 실행되는 애플리케이션이 있는데 해당 애플리케이션은 Initializing 때만 cpu 가 튀어오르게 됩니다.
 
이러한 부분은 이미 예상되어 있고, 애플리케이션을 실행하는데 있어 전혀 문제가 안되는 부분이죠. 하지만 HPA 는 알지 못하기 때문에 스케일업을 진행하게 될 것입니다.
 
이럴 때 stabilization window 을 이용하면 불필요한 스케일업을 방지할 수 있습니다.
 
위에서 사용한 HPA 매니페스트는 아래와 같이 수정할 수 있습니다.
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: php-apache
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: php-apache
  maxReplicas: 10
  minReplicas: 2
  metrics:
    - resource:
        name: memory
        target:
          averageUtilization: 50
          type: Utilization
      type: Resource
    - resource:
        name: cpu
        target:
          averageUtilization: 50
          type: Utilization
      type: Resource
  behavior:
    scaleDown:
      stabilizationWindowSeconds: 300
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
    scaleUp:
      stabilizationWindowSeconds: 0
      selectPolicy: Max
      policies:
        - type: Percent
          value: 100
          periodSeconds: 60
        - type: Pods
          value: 4
          periodSeconds: 60
 
.behavior 영역에 있는 값들은 모두 기본값입니다.
더 많은 값들이 궁금하다면 여기!
 
.metrics 필드도 v2 로 되면서 약간의 변화가 있지만 중요한 건 behavior 입니다.
behavior:
  scaleDown:
    stabilizationWindowSeconds: 300
    selectPolicy: Max    
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
  scaleUp:
    stabilizationWindowSeconds: 0
    selectPolicy: Max    
    policies:
    - type: Percent
      value: 100
      periodSeconds: 15
    - type: Pods
      value: 4
      periodSeconds: 15
scaleUp/scaleDown : 스케일업/다운에 대한 제어 규칙을 지정합니다.
stabilizationWindowSeconds : thrashing, flapping 을 방지하기 위해 사용됩니다. 
이미 위에 "ScaleDown 실습" 섹션에서 해당 개념을 다루었으니 참고바랍니다.
(기본값 ScaleUp : 0s ScaleDown : 300s)
selectPolicy : Min, Max, Disabled 이 3개의 값 중 하나를 사용하며 정책에서 어떤 값을 선택할지 지정합니다.
만약 Min 이라면 가장 작을 숫자를 
(기본값 Max)
policy : 스케일업/스케일다운을 규제하는 정책 목록입니다.
type : Pods, Percent 중 하나를 사용하며 Pods 를 선택하면 갯수로, Percent 를 선택하며 퍼센트로 계산됩니다.
periodSeconds : 평가를 진행하는 주기입니다. 해당 정책이 true 인지 판별합니다.
value : 스케일업/다운되는 값을 지정합니다. type 이 Pods 라면 value 는 '이하' 로 계산됩니다.
 
이렇게만 보면 각 필드가 어떤건지 알기가 힘드니 예제를 통해 설명해드리죠!
 
예제는 쿠버네티스 공식 깃헙에서 제공되는 예제를 사용하겠습니다. 원문을 보고 싶다면 해당 링크를 참고해주세요!
다만, 문서에 틀린 부분이 있어서 맞게끔 수정하여서 글을 작성하였습니다.
 
 
가능한 한 빠르게 Scale Up
behavior:
  scaleUp:
    policies:
    - type: Percent
      value: 900
      periodSeconds: 60
 
60초마다 Target 메트릭 값을 평가하고, 평가가 true 라면 현재의 레플리카 갯수에 900% 증가된 레플리카 갯수를 더합니다.
 
1 -> 10 -> 100 -> 1000
1분 마다 위와 같이 파드의 갯수가 증가합니다. 이 방법은 maxReplicas 에 가장 빠르게 도달하는 방법입니다.
 
ScaleDown 은 명시되지 않았지만 기본값으로 동작합니다.
 
 
가능한 한 빠르게 Scale Up 하고, 점차적으로 Scale Down
behavior:
  scaleUp:
    policies:
    - type: Percent
      value: 900
      periodSeconds: 60
  scaleDown:
    policies:
    - type: Pods
      value: 1
      periodSeconds: 600 # (i.e., scale down one pod every 10 min)
Scale Up 경우에는 60초마다 Target 메트릭 값을 평가하고, 평가가 true 라면 현재 레플리카 갯수에 900% 증가된 레플리카 갯수를 더합니다.
 
그리고 Target 메트릭 값에 의해 Scale Down 이 될 때에는 10분마다 평가하고, 평가가 true 라면 레플리카 갯수는 하나씩 감소시킵니다.
   1000   ->   1000 ->   1000 -> … (7 more min) -> 999
(1분 지나고)   (1분 지나고) (1분 지나고)   (7분 지나고)   (총 10분이 지나고)
maxReplicas 는 1000 개라고 가정합니다.
 
 
점차적으로 Scale Up
behavior:
  scaleUp:
    policies:
    - type: Pods
      value: 1
      periodSeconds: 300
5분마다 Target 메트릭 값을 평가하고, 평가가 true 라면 현재 레플리카 갯수를 1개씩 더합니다.
 
1 -> 2 -> 3 -> 4
ScaleDown 은 지정하지 않았기 때문에 기본값을 따릅니다.
 
 
기본 값으로 Scale Up 하고, Scale Down은 하지않음
behavior:
  scaleDown:
    selectPolicy: Disabled
ScaleUp 은 기본값을 따르고 ScaleDown 은 진행되지 않습니다.
 
 
Scale Down 전 안정화
behavior:
  scaleDown:
    stabilizationWindowSeconds: 600
    selectPolicy: Max    
    policies:
    - type: Pods
      value: 5
      periodSeconds: 60
문서에는 periodSeconds: 600 으로 나와있는데 오타인거 같습니다. 전후 상황을 보면 60 이 맞습니다.
 
60초마다 Target 메트릭 값을 평가하고, 평가가 true 라면 현재 레플리카 갯수에 5개 이하를 뺍니다. 단 안정화 시간 10분(600초) 을 가집니다.
 
안정화의 동장 방식은 위에서 설명한 "Scale Down 섹션" 과 똑같습니다.
 
현재 레플리카 갯수는 10개라고 가정해보겠습니다.
 
HPA 가 생성된 기준으로 9분까지는 어떠한 ScaleDown 은 진행되지 않고, 그저 window 에 추천 레플리카 갯수를 추가합니다.
# 각 숫자는 임의의 메트릭 값으로 계산된 것으로, 큰 의미는 없습니다.
[10, 9, 8, 9, 9, 8, 9, 8, 9]
 
그리고 10분이 될 때 8 이 추가됩니다. (8 이라는 숫자는 임의의 값으로 큰 의미는 없습니다)
[10, 9, 8, 9, 9, 8, 9, 8, 9, 8]
 
60초마다 평가를 진행하고 안정화 시간이 600초였으므로 총 창에는 최대 10개의 숫자가 존재하게 됩니다.
 
selectPolicy: Max 이므로 가장 큰 숫자를 Pick 해서 HPA 는 10 개로 ScaleDown 하려고 시도하지만, 어차피 현재 레플리카 갯수가 10개이므로 변화는 없습니다.
 
그리고 11분에 7 이 추가되려고 합니다. FIFO 방식처럼 가장 앞에 있는 숫자가 빠지고, 가장 뒤에 7 이 들어가게 됩니다.
[9, 8, 9, 9, 8, 9, 8, 9, 8, 7]
 
이번 window 에선 가장 큰 숫자가 9 이므로 10 -> 9 로 ScaleDown 을 하게 됩니다.
 
ScaleUp 은 따로 명시된 것이 없으므로 기본 동작으로 따릅니다.
 
 
부정적인 시그널로 인한 ScaleUp 피하기
behavior:
  scaleUp:
    stabilizationWindowSeconds: 300
    selectPolicy: Min
    policies:
    - type: Pods
      value: 20
      periodSeconds: 60
60초마다 Target 메트릭 값을 평가하고, 평가가 true 라면 현재 레플리카 갯수에 20개 이하를 추가합니다. 단 안정화 시간 5분(300초) 을 가집니다.
 
부정적인 시그널(false positive signals) 은 아래와 같이 아주 짧은 스파이크를 말합니다.
 
 
 
현재 레플리카 갯수는 2개라고 가정해보겠습니다.
 
HPA 가 생성된 기준으로 5분까지는 어떠한 ScaleDown 은 진행되지 않고, 그저 window 에 추천 레플리카 갯수를 추가합니다.
 
60초마다 평가를 진행하고 안정화 시간이 300초였으므로 총 창에는 최대 5개의 숫자가 존재하게 됩니다. 그리고 가장 작은 숫자가 2 이므로 현재 레플리카 갯수는 2개 입니다.
# 각 숫자는 임의의 메트릭 값으로 계산된 것으로, 큰 의미는 없습니다.
[2, 3, 19, 10, 3]
 
6분이 될 때 4 라는 값이 window 에 들어오고, 가장 앞에 있는 2 는 나오게 됩니다.
[3, 19, 10, 3, 4]
 
이번 window 에선 가장 작은 숫자가 3 이므로  2 -> 3 으로 ScaleUp 을 하게 됩니다.
 
 
behavior 을 이용하면 ScaleUp/Down 에 대해 더 커스텀하게 지정할 수 있습니다.
 
지금까지는 단순히 파드의 CPU 와 Memory 로만 메트릭을 계산했지만 KEDA 와 같은 오픈 소스를 이용하면 더 다양하게 메트릭을 계산해서 HPA 를 사용할 수 있습니다.
 
 
그러면 오늘은 여기까지!

[Kubernetes] HPA(Horizontal Pod Autoscaler) 알고리즘

댓글