3년만에 AWS EKS 클러스터를 종료하면서 정리의 글
어제로 피앰아이에서 운영하는 모든 AWS EKS 클러스터를 종료했습니다.
현재 고가용성이 필요한 메인 서비스는 예전부터 사용하던 Elastic Beanstalk를 사용하고 있고,
EKS에 있는 서비스는 ECS로 이전하면서 3년 넘는 긴 여정을 마쳤습니다.
EKS는 쿨해보였다
당시 고가용성 서비스가 필요했고, ECS를 도입할까 했지만 k8s기반의 EKS가 더 유연하고 확장성이 좋다고 판단하여 EKS를 선택했습니다.
높은 러닝커브, AWS 리소스들의 이해도 부족으로 정말 많은 시행착오를 겪으며 메인 비즈니스 중 하나인 패널 허브를 EKS로 이전했습니다.(그전까지는 EB)
deployment, service, ingress, configmap, secret 등 k8s 리소스들을 정의하는 yaml 파일을 작성하고,
github actions를 통해 CI/CD 파이프라인을 구축하여 자동 배포까지 구현하니, 최신 트렌드에 적합한 세련된 개발자가 된 기분이었습니다.
결국 비용
결론부터 말씀드리면 비용 문제로 EKS를 종료하게 되었습니다. 비용 이슈만 없다면 EKS를 계속 사용했을 거라고 확신 합니다.
EKS는 클러스터 비용을 따로 지불해야 하고, EC2던 fargate던 노드 비용이 추가로 발생합니다.
지원 주기가 지나면 클러스터에 추가 비용을 내야하고, 추가 비용을 내지 않으려면 업데이트를 지속적으로 해야하는데
생성된 클러스터가 오래된 버전이였기 때문에 업데이트에 대한 공포가 있었습니다(실제로 문제가 있었던 경험도 있음)
기본적으로 필요한 Pods
coredns, nginx ingress, metrics-server, aws-node, kube-proxy 등 기본적으로 필요한 pod들이 많았습니다.
이 pods들은 fargate를 사용하면 비용이 더 비쌌고, 작은 EC2 인스턴스를 노드로 사용하면 이미 노드의 반은 기본 pod들이 차지하고 있었습니다.
인스턴스 크기에 따라 pods수가 정해져 있기 때문에, 비용 절감을 위해 타이트하게 운영하기 위해 많은 노력을 했지만
쉽지 않았고 관리가 힘들었습니다.
ECS로 이전하면서
ECS는 정말 간단했습니다. 서비스 생성과 LB의 간단한 설정으로 1-2시간 만에 이전이 완료되었습니다.
왜 더 빠르게 이전하지 못했을까 하는 후회가 들 정도로 간단했습니다.
그럼 이제 안씀?
네, 당분간은 안(못) 씁니다.
규모가 커진다면 EKS는 정말 좋은 선택이라고 생각합니다. NCP(네이버 클라우드 플랫폼)이나, AKS(Azure)에 서비스를 해야하는 경우가 있었을 때,
EKS를 통한 k8s 경험으로 빠르게 적응할 수 있었습니다.
다만 모든 인프라 선택은 기업의 비즈니스 모델과 상황에 따라 다르다는 점입니다.
클라우드의 고가용성과 확장성은 매력적이지만, 저희 같이 작은 규모의 기업에게 매월 수십~수백만원의 비용이 더 발생하는 것은 큰 부담이었습니다.
저는 피앰아이에 EKS는 기술적으로는 매력적이지만, 비용적으로는 부담이 되는 선택이었고, 결과적으로 당시 제 판단은 잘못되었다고 볼 수 있겠네요.