스파크성 트래픽에 노드 증설이 따라오지 못하던 Cluster Autoscaler를 Karpenter로 교체한 기록입니다. 동작 원리와 적용 시 고려 사항, 겪은 이슈, 그리고 프로비저닝 속도와 비용에서 얻은 효과를 공유합니다. ||
안녕하세요, 비브로스 백엔팀에서 인프라를 맡고 있는 박진홍입니다.
23년 상반기 EKS Blue-Green 업데이트에 이어 Karpenter 도입기를 소개해드리고자 합니다.
기존 AWS Cluster AutoScaler를 사용하였지만, 스파크성 트래픽시 노드 스케일링 속도에 문제가 있었고 비용 최적화를 위해 Karpenter 도입에 대해 고민하였습니다.
시작하기전 Kubernetes 엔지니어들의 많은 고심이겠지만.. 인프라의 변경사항은 "낭만이 아니라 헬이다!!!" 라는 말과 같이 유사한 영상이 있어 공유드립니다!
웃으면서 봐주시면 감사하겠습니다. 
(링크드인 출처 링크)
Karpenter 도입 계기
비브로스의 “똑닥” 어플은 실시간 병원 접수/예약 서비스를 제공하고 있습니다. 매일 사용자가 몰리는 아침, 점심 그리고 새벽에 크게 스파크성 트래픽이 쏟아지게 되어 서버, 데이터베이스에 과부하로 서비스 지연 및 장애가 발생하게 됩니다.
사전에 인프라 리소스를 예측하여 늘려놓아도 독감시즌 및 연휴이후 평일에 병원을 내원하시는분들이 많아서 예측하기 어렵고, 무한정 인프라를 늘리기에는 클라우드 비용에 대한 제약사항이 있어 다른 방안을 찾게 되었습니다.
현재 똑닥 인프라는 ECS(Elastic Container Service)에서 EKS(Elastic Kubernetes Service)로 모두 마이그레이션하여 사용하고 있고, 백엔드 서비스 뿐만아니라 Cron Job, Batch Job, Action Runner를 Kubernetes 환경에서 사용하고 있습니다.
Kubernetes 노드 프로비저너로 기존 Cluster Autoscaler를 통해 Manage NodeGroup(서비스 개별)으로 노드 프로비저닝을 하였지만, 스파크성 트래픽이 몰릴 경우 노드가 늘어나는 시간이 오래걸리고, 원하는 인스턴스 타입으로 비용 최적화를 할 수 없다는 단점이 있었습니다.
기존 똑닥 인프라는 Auto Scaling Group(이하 ASG)를 통해 Cluster Autoscaler 기능이 구현되어 있음
Cluster AutoScaler 작동 원리
Pod가 배포/확장되어 더이상 기존 노드에 배정받지 못할 경우 Pod는 PENDING 상태가 됩니다.
Cluster AucoScaler는 AWS ASG을 통하여 자동으로 노드를 추가/제거 합니다.
PENDING 상태의 Pod는 새로 구성된 노드로 Kube-scheduler에 의해 새로운 노드로 배정합니다.
이에 인프라 부서에서는 노드의 프로비저닝을 기존 Cluster Autoscaler(이하 CA) 에서 프로비저닝 속도가 빠른 Karpenter로 변경하게 기획하였습니다.
Karpenter 알아보기
Karpenter란 2020년 11월에 출시된 오픈소스로 Kubernetes 예약할 수 없는 파드를 감지하고, 새로운 노드를 자동 확장/병합/제거가 가능한 노드 스케일러 이며 구성항목으로는 “Provisioner”와 “AWSNodeTemplate” 를 통해 구성할 수 있습니다.
Karpenter 작동 원리
Pod가 배포/확장되어 더이상 기존 노드에 배정받지 못할 경우 Pod는 PENDING 상태가 됩니다.
Karpenter는 스케쥴링 되지 않은 Pod를 관찰하고, Provisioner 조건에 맞는 EC2 인스턴스 타입을 결정하고, EC2 Fleet 요청을 통해 인스턴스를 생성합니다.
추가된 노드가 준비되면, Karpenter는 kube-scheduler 대신해서 Pod를 노드에 배치합니다.
위와 같이 CA와 다르게, PENDING인 Pod가 있을 경우 실시간(Just-in-time)으로 프로비저닝하게 되며, 사전에 설정한 프로비저닝 조건에 맞춰 확장이 일어나게 됩니다. Karpenter 도입시 장점을 정리해보면 하기와 같습니다.
(링크드인 출처 링크)
Karpenter 도입 계기
비브로스의 “똑닥” 어플은 실시간 병원 접수/예약 서비스를 제공하고 있습니다. 매일 사용자가 몰리는 아침, 점심 그리고 새벽에 크게 스파크성 트래픽이 쏟아지게 되어 서버, 데이터베이스에 과부하로 서비스 지연 및 장애가 발생하게 됩니다.
사전에 인프라 리소스를 예측하여 늘려놓아도 독감시즌 및 연휴이후 평일에 병원을 내원하시는분들이 많아서 예측하기 어렵고, 무한정 인프라를 늘리기에는 클라우드 비용에 대한 제약사항이 있어 다른 방안을 찾게 되었습니다.
현재 똑닥 인프라는 ECS(Elastic Container Service)에서 EKS(Elastic Kubernetes Service)로 모두 마이그레이션하여 사용하고 있고, 백엔드 서비스 뿐만아니라 Cron Job, Batch Job, Action Runner를 Kubernetes 환경에서 사용하고 있습니다.
Kubernetes 노드 프로비저너로 기존 Cluster Autoscaler를 통해 Manage NodeGroup(서비스 개별)으로 노드 프로비저닝을 하였지만, 스파크성 트래픽이 몰릴 경우 노드가 늘어나는 시간이 오래걸리고, 원하는 인스턴스 타입으로 비용 최적화를 할 수 없다는 단점이 있었습니다.
기존 똑닥 인프라는 Auto Scaling Group(이하 ASG)를 통해 Cluster Autoscaler 기능이 구현되어 있음
Cluster AutoScaler 작동 원리
Pod가 배포/확장되어 더이상 기존 노드에 배정받지 못할 경우 Pod는 PENDING 상태가 됩니다.
Cluster AucoScaler는 AWS ASG을 통하여 자동으로 노드를 추가/제거 합니다.
PENDING 상태의 Pod는 새로 구성된 노드로 Kube-scheduler에 의해 새로운 노드로 배정합니다.
이에 인프라 부서에서는 노드의 프로비저닝을 기존 Cluster Autoscaler(이하 CA) 에서 프로비저닝 속도가 빠른 Karpenter로 변경하게 기획하였습니다.
Karpenter 알아보기
Karpenter란 2020년 11월에 출시된 오픈소스로 Kubernetes 예약할 수 없는 파드를 감지하고, 새로운 노드를 자동 확장/병합/제거가 가능한 노드 스케일러 이며 구성항목으로는 “Provisioner”와 “AWSNodeTemplate” 를 통해 구성할 수 있습니다.
Karpenter 작동 원리
Pod가 배포/확장되어 더이상 기존 노드에 배정받지 못할 경우 Pod는 PENDING 상태가 됩니다.
Karpenter는 스케쥴링 되지 않은 Pod를 관찰하고, Provisioner 조건에 맞는 EC2 인스턴스 타입을 결정하고, EC2 Fleet 요청을 통해 인스턴스를 생성합니다.
추가된 노드가 준비되면, Karpenter는 kube-scheduler 대신해서 Pod를 노드에 배치합니다.
위와 같이 CA와 다르게, PENDING인 Pod가 있을 경우 실시간(Just-in-time)으로 프로비저닝하게 되며, 사전에 설정한 프로비저닝 조건에 맞춰 확장이 일어나게 됩니다. Karpenter 도입시 장점을 정리해보면 하기와 같습니다.