비용절감을 위한 AWS EKS 버전업하기(with. karpenter)

 

팀이 변경되면서 이전 인프라에 대한 부담을 가져갈 필요가 없다고 생각했는데, 다시 한 번 비용 절감 관련 문의가 들어왔다.

 

이전 서비스의 운영 리소스를 줄이는 과정에서, 또다시 문의가 들어왔고 운영을 정말 가볍게 가져가려면 시간이 들더라도 EKS를 내려놓는 게 맞다는 의견을 냈지만, 이번에도 구조를 바꾸기보다는 당장 효과를 볼 수 있는 선에서 정리하는 방향으로 결정됐다.

 

결국 이번에도 땜빵에 가까운 선택이었다.

 

그래서 이번에 진행하기로 한 작업은 다음 세 가지였다.

 

진행하기로 한 작업들 :

1. RDS serverlss ACU 사이즈 줄이기
- 2 - 8 ACU까지 사용하는데, 0.5 - 1 로 줄여보자
2. RDS reader 인스턴스 삭제

- MAU가 많이 내려가서 DB reader 인스턴스가 필요 없어짐

3. EKS 추가지원 버전에 걸려있어서 버전 업데이트

- 매달 360달러 절감 가능

 

크게 어려운 작업은 없을 거라 판단해 하루 정도의 일정으로 잡았는데, 결과적으로는 1번부터 문제가 발생했고, 3번에서는 생각보다 큰 이슈를 맞닥뜨리게 됐다.

 

1. RDS serverlss ACU 사이즈 줄이기

해당 DB는 Terraform으로 관리되고 있지 않아 콘솔에서 직접 작업을 진행했다. ACU max 값을 1로 낮춘 뒤, 2번 작업을 마치고 서버를 배포하자마자 문제가 발생했다. 처음에는 DB 문제라고 바로 인식하지 못했는데, 로그를 차분히 확인하다 보니 서버 기동 시 수행되는 JDBC 커넥션 체크가 타임아웃되고 있었다. 그래서 RDS 콘솔을 확인해보니 DB 사용량이 99%까지 치솟아 있는 상태였다.

 

 

이 DB의 평균 ACU 사용량이 대략 3 정도라는 건 알고 있었지만, 반쯤은 테스트해보자는 생각으로 진행했던 작업이 이렇게 바로 장애로 이어질 줄은 예상하지 못했다.

 

 

결국 ACU max 값을 평균 사용량보다 여유 있게 4로 조정하고, 0.5–4 범위로 설정해 작업을 마무리했다. 이 과정을 통해 DB의 ACU를 과도하게 줄였을 때 어떤 일이 발생하는지는 명확히 알 수 있었지만, 평균 사용량 자체가 변하지 않았기 때문에 비용 절감 효과는 사실상 없을 것이라는 결론에 도달했다.

 

2. RDS reader 인스턴스 삭제

이 작업은 생각보다 단순했다. 어렵게 생각한다면 서버 이중화를 전제로 작성된 일부 코드와 JDBC 설정을 정리해야 했지만, 기존 코드를 모두 삭제하고 기본적인 RDS 연결 방식을 기준으로 다시 구현하면서 Reader 인스턴스를 완전히 제거했다. 작업 자체는 오래 걸리지 않았지만, 1번 작업에서 발생한 장애로 인해 진행 중에는 꽤 당황했었다.

 

다만 결과는 명확했다. 이 작업 하나로 월 약 $250~270 수준의 비용 절감 효과를 얻을 수 있었다. 크게 눈에 띄는 작업은 아니었지만, 이번 비용 절감 작업 중에서는 가장 확실한 성과였다.

 

3. EKS 추가지원 버전 업데이트

3번작업이 이 글을 작성한 가장 큰 이유다. 큰 작업이라 생각하지 않았지만 가장 큰 문제를 일으킨 작업이었다.

 

처음엔 이전에 버전 업데이트를 한 경험이 있었고, [개발/AWS&인프라] - AWS EKS 버전 업데이트하기 에서 정리했던 방식과 동일하게 AWS 콘솔에서 클러스터 버전을 단계적으로 업데이트하고, 부가 기능들도 최신 버전으로 맞췄다.

 

문제는 바로 발생했는데, 콘솔에서 버전 업데이트를 마무리하고 1.28 버전으로 남아 있던 노드들을 삭제하고 재배포되길 기다렸지만, 노드가 다시 올라오지 않았다. 원인을 분석했지만 로그를 봐도 명확한 이유를 알 수 없었다.

 

문제는 뒤늦게 드러났다. EKS의 클러스터 버전은 올라갔지만, 노드 스케줄러로 사용하고 있는 Karpenter가 너무 구버전이었고 여전히 NodeTemplate과 Provisioner를 사용하는 구조였기 때문이다.

 

결국 EKS 클러스터 버전에 맞는 CRD를 새로 주입하고, 기존 NodeTemplate / Provisioner 기반 설정을 NodeClass / NodePool 구조로 다시 구성해야 했다.

Karpenter 업그레이드 시 주의할 점

가장 먼저 EKS 버전에 맞는 Karpenter 최소 버전을 확인해야 한다.

https://karpenter.sh/docs/upgrading/compatibility/

 

 

Helm 설치를 사용하지 않고 컨트롤러만 업데이트하는 경우, YAML 적용 전에 CRD를 반드시 먼저 적용해야 한다.

# v1.8.3은 eks 버전에 맞는 카펜터 버전
kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/v1.8.3/pkg/apis/crds/karpenter.sh_nodepools.yaml
kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/v1.8.3/pkg/apis/crds/karpenter.sh_nodeclaims.yaml
kubectl apply -f https://raw.githubusercontent.com/aws/karpenter-provider-aws/v1.8.3/pkg/apis/crds/karpenter.k8s.aws_ec2nodeclasses.yaml

이후 Karpenter 공식 문서를 기준으로 기존 설정을 옮기고, Terraform으로 설정을 재정비했다.

 

https://karpenter.sh/docs/concepts/nodeclasses/

https://karpenter.sh/docs/concepts/nodepools/

 

업데이트 순서 정리

 

1. EKS 클러스터 버전업
2. 쿠버네티스 Add-on(추가기능) 버전업
3. 카펜터 CRD 주입
4. 카펜터 컨트롤러 버전업
5. NodePool / EC2NodeClass YAML 적용
6. 노드 롤링 업데이트 (Cordon & Drain)
7. 구버전 노드 및 자원 삭제

 

3~5번 단계가 완료되기 전에는, 어떠한 노드 이벤트도 발생하지 않도록 주의해야 한다. 그리고 각 버전에 맞는 설정들이 있으니 꼭 확인해야한다.

 

추가로 알면 좋은 것들

1. 신규 설치라면 훨씬 단순하다

EKS 1.34를 새로 설치하고 최신 Karpenter를 바로 구성한 경우에는, CRD를 별도로 주입하거나 YAML을 마이그레이션할 필요가 없다. Helm 설치 과정에서 필요한 CRD가 함께 설치되고, 구버전 리소스와의 충돌도 발생하지 않는다.

 

2. CRD 버전을 잘못 지정하면 매우 귀찮아진다

CRD 버전이나 YAML의 apiVersion을 잘못 지정하면 다음과 같은 오류가 반복된다.

request to convert CR from an invalid group/version

YAML의 apiVersion(v1을 v1beta1라 잘못 표기)을 잘못 지정했거나, CRD와 리소스 버전이 어긋난 상태였던 것으로 보인다. 이 경우 CRD 변환 오류가 반복되며, 정상 복구가 사실상 어려웠다. 결국 해결하지 못하고 클러스터를 삭제 후 재설치했다. 

 

3. NodeTemplate / Provisioner → NodeClass / NodePool 변경 이유

초기 Karpenter는 Provisioner가 노드 스케줄링 정책과 인프라 설정을 모두 책임지는 구조였다.

 

AWS 환경에서는 여기에 NodeTemplate을 붙여 AMI, 서브넷, 보안 그룹 같은 EC2 설정을 함께 정의했다. 문제는 이 구조가 시간이 지날수록 책임이 과도하게 집중되고 확장성이 떨어진다는 점이었다.

 

그래서 Karpenter v1.0을 전후로 역할이 분리됐다.

 

NodePool은 어떤 파드를 대상으로 어떤 제약 조건과 스케줄링 정책을 적용할지를 담당하면, NodeClass는 실제 인프라 설정(AMI, 서브넷, 보안 그룹, IAM Role 등)을 담당하도록 이렇게 역할이 분리되었다.

 

이 구조를 도입하면서 클라우드별 확장이 쉬워졌고 CRD 구조도 명확해졌지만 구버전 리소스는 최신 EKS 클러스터에서 더 이상 동작하지 않게 됐다.

 

마치며

이번 작업에서 가장 잘했던 선택은 개발 서버에서 먼저 테스트를 진행했다는 점이다.

 

기존에 한 번 업데이트를 해봤다는 이유로, 아무 생각 없이 운영 서버에서 바로 진행했다면 전면 장애로 이어질 뻔했다.

 

EKS를 사용하면서 느끼는 점은, 버전 변경과 추가지원 종료 주기가 생각보다 빠르다는 것이다.

https://docs.aws.amazon.com/ko_kr/eks/latest/userguide/kubernetes-versions.html

 

추가지원으로 전환되면 별다른 경고 없이 비용이 발생한다.

 

이 구조가 맞는지에 대해서는 여전히 의문이 남는다. 앞으로는 신경 쓸 일이 없길 바라지만, 그럴 가능성은 높아 보이지 않는다.