EKS의 효율적인 파드 확장

서비스를 운영하다 보면 대형 이벤트(할인 이벤트, 마케팅 활동)등에 의해서 대규모 트래픽이 유입되는 이때 파드나 노드 리소스의 사용량이 급증하여 트래픽 급증으로 인한 서비스 부하로 이어져 사용자 응답 지연 및 장애로 이어질 수 있습니다.

쿠버네티스에서는 이러한 대규모 트래픽을 해소하기 위해서 파드를 확장하고 노드에서 실행되는 파드 특성상 노드의 리소스가 부족해질 경우 노드도 확장하게 됩니다.

파드 스케일링과 노드 스케일링

이 때 사용하는 것이 Horizontal Pod Autoscaler (HPA)와 Cluster Auto Scaler (CA)이며 말그대로 자동으로 파드의 수평적 확장을 가능하게 해주는 것이 HPA, 노드의 리소스가 부족해지는 경우 노드를 확장시켜주는 것이 CA입니다.

EKS의 자동 스케일링

예제로 두 개의 노드가 존재하고 이 노드안에 파드가 실행되는 상황에서 부하상황을 감지하기 위해서는 파드의 CPU 또는 메모리를 감지해야 합니다. 이러한 리소스를 감지하기 위해서 메트릭 서버에서는 계속해서 파드의 CPU 및 메모리 정보를 수집하게 되고 HPA 컨트롤러가 사용자가 설정한 임계치와 메트릭 서버의 리소스 사용량을 비교하여 사용자가 설정한 임계치를 기준으로 수치가 오버될 경우 레플리카셋의 수치를 변경해 더 많은 파드를 실행할 수 있도록 조정하게 됩니다. 이후 가용성을 확보하기 위해 노드의 여유공간이 존재한다면 추가로 해당 노드에 파드를 배치하게 됩니다.

그럼에도 계속해서 트래픽이 인입될 경우 노드의 리소스가 부족해지는데 더 이상 파드가 들어갈 수 있는 공간이 없을 경우 파드가 Pending 상태에 빠지게 되며 이를 클러스터 오토스케일러가 감지하여 노드를 추가적으로 실행시켜야 한다고 판단하여 AWS의 Auto Scaling Group의 Desired Capacity를 조정하여 더 많은 리소스를 생성하게 됩니다. (신규 노드 생성) 최종적으로 Pending 상태에 빠졌던 파드가 신규 노드에 들어가면서 노드의 가용성을 확보하게 됩니다.

그러나 CA를 사용하는 고객들이 어려워 하는 것이 Pending 파드가 발생하고 나서 클러스터 오토스케일러가 이러한 상태의 파드를 감지해서 Auto Scaling Group의 Desired Capacity를 변경하여 새로운 파드를 실행하기까지 걸리는 시간으로 빠른 확장이 어렵다는 것입니다.

그리고 Auto Scaling Group을 기반으로 노드가 만들어지다 보니 인스턴스 유형을 Auto Scaling Group마다 하나씩 설정해야 합니다. 마이크로서비스를 운영하다보면 각 서비스마다 사용하는 리소스 사용량이 다르며 모두 같은 인스턴스 유형을 사용하게 되면 리소스를 비효율적으로 사용하게 됩니다. 예를 들어 리소스 사용량이 작은 서비스에서 평균적으로 동일한 리소스를 가진 인스턴스 유형을 사용한다고 할 때 사용량이 남게 됩니다.

그래서 인스턴스 유형을 다르게 가져가기 위해 노드 그룹을 계속해서 추가하고 비용 절감을 위해 스팟 인스턴스 생성을 위한 노드 그룹을 만들다보면 복잡도가 증가하게 되고 이는 관리용이성 측면에서도 불편해지게 됩니다.

Karpenter

여기서 Karpenter는 다양한 워크로드를 관리할 수 있게 해주며 Pending 파드가 발생하면 오토 스케일링 그룹을 조정하는 것이 아니라 카펜터가 즉시 인스턴스를 프로비저닝하기에 더욱 빠른 확장이 가능합니다.

Karpenter 동작원리

노드의 HPA 요건을 정의하고 파드를 추가해야 하는 요건을 충족하는 상황에서 노드의 파드를 생성할 수 있는 리소스 여유량이 남아있따면 HPA에 의해서 파드가 추가되지만 리소스 부족으로 노드를 추가해야 한다면 카펜터가 이를 감지하여 현재 배치되지 못하고 있는 파드들의 리소스 요청(request)들을 보고 가장 적합한 인스턴스 유형을 선택하여 프로비저닝하게 됩니다. 따라서 리소스를 효율적으로 사용하게 되고 불필요하게 스펙이 큰 인스턴스를 만들지 않아 비용절감 효과도 가져가게 됩니다. 만약 노드가 파드의 미사용으로 인해 동작하지 않는 경우에도 이를 축소시켜 비용을 줄여줍니다.