AWS EKS 클러스터 도입 #들어가며

EKS는 AWS에서 서비스하는 완전 관리형 쿠버네티스 서비스 입니다. 마스터 노드가 포함되어 있어 클러스터당 추가 요금 정책이 책정되어있으며 관리형 서비스이기 때문에 API 엔드포인트가 제공되며 마스터노드로의 접근과 관리를 제한하고 있습니다.

오래전에 외부 프로젝트를 진행하면서 잠시 AKS(Azure Kubernetes Service)를 사용하면서 쿠버네티스의 강력함을 체감했습니다. 서비스에 대한 디스커버리나 노드와 컨테이너를 패킹하고 개발 문서를 작성하듯 프로비저닝 하며 관리할수 있다는점, 개발 환경이나 인프라 구성을 빠르게 생성하고 수정할수 있다는 점에서 쿠버네티스는 너무나 강력하다는것을 알게 되었습니다.

저는 프로젝트 단위로 일을 해왔는데, 프로젝트가 시작되면 인프라설계와 프론트, 백엔드, 컴플라이언스까지 모든 부분을 설계하고 요구사항을 맞춰주는 작업을 혼자 해야 하는 경우가 종종 있었습니다. 고객사 별로 요구사항과 요건이 조금씩 다르긴 하지만 거의 대부분을 클라우드 환경에서 작업을 했습니다. 그럴 때마다 인프라를 구성하고 안정적으로 만들기 위해 요구되는 시간이 많아지고, 물리적으로 필요한 시간이라고 생각을 해왔습니다. 컨테이너 기반이어도 마찬가지였습니다. 배포를 위한 저장소와 저장소에서 배포까지의 파이프라인, 서비스를 교체해주는 러너, 모니터링, 로깅등 해야할 일이 너무 많았습니다. 저는 프로젝트 설계와 매니징도 해야하지만 실제 코드를 짜는 실무도 해야하기 떄문에 이러한 시간을 줄이고자 하는 욕구가 강했습니다.

그러다 맨 처음 ECS를 찾아 사용해봤습니다. 반 관리형 서버리스 이다 보니, 서버를 직접 세팅할 일도 없고 Terraform을 이용하거나 AWS Cloudformatio 등을 이용하면 손쉽게 원하는 프로젝트의 배포에 맞춰서 쉽게 서비스를 교체할 수 있는점이 좋았습니다. 하지만 저는 단순히 서비스를 교체하는것에 그치지 않고 CI/CD 의 완전한 호환성과 오케스트레이션, 매끄러운 배포와 롤백에 대한 요구사항이 남아 있었습니다.

결국 미지의 영역인 EKS를 사용해보기로 결심했고 나름대로 스터디를 해가며 (엄청나게..) 실제 서비스에 적용해 보았습니다. 서론이 길었지만 앞으로의 내용은 Terraform 과 EKS를 통해 클러스터를 구성하는 과정에 대해서 기록합니다.