EKS Architecture WorkFlow Organization (EKS 아키텍처 정리)

# 최근 EKS를 기반으로 인프라를 구성 하였는데 구성한 WorkFlow를 정리 하였다.

- EKS 서비스를 활용하여 인프라를 구성 시 고려해야할 사항이 여러가지가 존재 하였다.

- 추후에 이러한 문제를 사전에 방지 하기 위해서 관련 오류 사항에 대해 정리를 하고자 한다.

1. 빌드와 배포 문제 CI/CD

EKS는 Docker Image형태로 하나의 서비스가 배포 되는데 소스코드를 수정 후 실제 운영환경에서 테스트를 하기 위해서는 매번 빌드 과정을 거쳐야만 했다. 빌드 과정이 번거로운게 Docker Image로 매번 말아서 ECR이나 프라이빗 Repository에 올려야 하므로 빌드에 소요되는 시간과 충돌에 대해서 항상 고민이 되었다. 실제로 Codebuild에서 A라는 사람이 빌드를 하고 있을때 B라는 사람이 동시에 빌드를 하게 되면 Codebuild 이미지가 정상적으로 떨어지지 않는 경우가 발생 하였다.

그래서 보통 기업에서는 빌드 배포 하는 날짜를 정해두어 고정된 날짜에 빌드와 배포를 수행하므로 이러한 문제에 대해서 대응을 하는것 같다. 아니면 Codebuild 옵션에서 단일 빌드만 허용? 이런 비슷한 옵션이 있는데, 해당 옵션을 체크하면 일단 현재 빌드 대상만 빌드를 수행하고, 다음사람이 동시에 빌드를 진행해도 선 진행된 빌드가 끝나야 다음 빌드가 진행 된다.

2. EKS 버전 업그레이드 문제

EKS는 AWS에서 제공하는 관리형 쿠버네티스 서비스이다. 관리형이라는 말은 Saas형태로 AWS에서 일정부분을 관리해주는 서비스 이다. 그런데 이게 문제가 뭐냐면 버전 업그레이드가 상당히 자주 된다... -_- 왜 때문인지는 모르겠지만 버전을 올릴때마다 내부의 OpenSource들은 버전이 올라갔네? 하면서 아몰랑 하면서 죽어버린다. 지금까지 겪었던 프로그램 들 중에서는 ALB와 Ingress를 담당하는 ApplicationLoadBalancerController나 CertManager 등이 버전 업그레이드 하니까 죽어버리더라. 이게 문제가 뭐냐면 실제 서비스는 ALB나 Ingress에 태워서 서비스를 할텐데 저 두개가 죽어버리면 서비스 자체가 안되는? 아주 큰 문제가 발생하게 될 것이다.

해결책은, 매우 수동적인 방법인데 일단 첫번째 해결책은 EKS 클러스터 버전이 업그레이드 되면 업그레이드 된 버전을 새로 생성해보고 테스트 서비스를 올려본다. (여기서 말하는 테스트 서비스는 Nginx나 Apache이고 ALB하고 Ingress 태워서 DNS까지 생성되는지 확인하거 접속까지 해봐야 한다.) 물론 클러스터를 생성할때 이전 버전의 애플리케이션을 설치를 해야 한다. 정상적으로 올라온거 확인되고, 로그등도 찍어보고 여러가지 검토를 한 뒤에 서비스를 올리는 작업을 수행 한다.

두번째 해결책은 버전이 업그레이드 됐다고 해서 바로 업그레이드를 하는것이 아니라, 최대한 버틴다. 최소 몇개월을 버틸수 있을것이다. 이 버티는 기간에 관련 문서와 각종 테스트를 수행하고, 문제가 없으면 클러스터를 새로 생성해서 올리든지, 아니면 기존의 클러스터에서 버전을 업그레이드 설치를 하던지 결정을 하면 될 것이다.

3. 업무 역할의 문제

업무의 역할의 문제가 대두 된다. 나는 이번과정에서 AWS VPC, 관련 네트워크 인프라 구축, EKS 클러스터를 생성 및 CI/CD 빌드와 배포까지 담당을 하였다. 개발자는 개발만 하고 Commit/Push만 하면 자동으로 빌드되서 운영환경에 배포되도록 시스템을 만들었는데, 이게 굉장히 힘들었다. 일단 빌드 배포에서 Dockerfile의 표준화와 작성의 문제, CodeCommit에 올라가있는 buildspec.yaml 파일의 작성, CodeCommit에서 개별 브랜치에서 마스터 브랜치로의 정책 문제(코드 충돌 관련), 빌드 배포도 어려운데 나는 EKS 클러스터까지 -_- 말썽이 생기면 신경써야 하는 아주 똥같은 상황이 연출이 되었다.

그래서 클러스터 하나 만들어서 웹서버 배포하는데 1시간이 채 걸리지 않는 고도의 반복 숙달된 능력을 갖게 되었지만 어찌됐던 스트레스 오지게 받았다.

거기다가 FontEnd와 Backend가 나누어져 있으니, 하나의 통 서비스만 구축을 했던 나로서는 당황스럽 더라, Frontend와 Backend 연계도 내가 EKS pod 로그 뒤져가며 신경을 써야 했다. 어쩌어찌 되긴 했는데, 지금도 문제는 없으나 내부 Ingress로 서비스를 넣어야 하는 작업이 남아 있긴 하다.

어쨌든 혼자서 할 수 있는 일이긴 하다. 고도화? 작업이 남아 있긴 하지만 클러스터의 생성과 서비스의 디테일을 신경써야 한다면 혼자서는 힘들거 같고 최소 3명정도는 있어야지 돌아가지 않을까 싶다. 그래서 다른곳은 Devops 팀이 따로 있는가 싶기도 하다.

4. 결론

재밌었다.

# 기타 (EKS Workflow 및 관련 프로세스 설명)

EKS_WorkFlow_Architecture.drawio

0.01MB

워크 플로우 설명

① 유저는 웹 애플리케이션 10번 으로 들어간다. 개발자는 10번으로 들어가도 되고 2번 Bastion을 통해서 EKS에 접근하여 작업을 할 수 있다.

② BastionHost 인데 Public망에 존재하면 Private 환경에 있는 자원에 접근을 하기 위해서 존재한다.

③ EKS 클러스터 인데 조금 더 큰 개념이지만 AWS에서는 MasterNode의 역할을 한다고 볼 수 있다.

④ Kubernetes이다.

⑤ pod 인데, pod는 컨테이너 관련된 정보를 정의 한다.

⑥ service 인데, service는 ClusterIP, NodePort, Loadbalancer로 구성할 수 있다.

⑦ Ingress는 service와 밀접한 관련이 있는데 클러스터 내부에서 ALB 역할을 해준다고 보면 된다.

⑧ AWS ALB 인데 Loadbalancer 서비스가 생성되면 AWS에서는 ELB가 생성이 되는데, ALB가 생성되게 하기 위해서는 Ingress를 정의 해줘야 한다.

⑨ 타겟 그룹인데 EKS 클러스터 내부의 서비스와 ALB간의 포트를 포워딩 해주는 역할을 한다고 볼 수 있다.

⑩ 웹 애플리케이션인데 pod에서 실행한 docker image를 실행한다.

⑪ ECR인데 개발자가 CodeCommit에 배포하는 순간 buildspec.yaml이 동작하고 그 과정에서 Dockerfile이 실행된다. buildspec.yaml 파일에 따라서 Docker로 말린 이미지가 ECR에 업로드 된다.

⑫ Dockerfile에 정의된 내용으로 빌드가 된다.

⑬ CodeCommit은 개발자가 작성한 코드를 저장하는 코드 저장소 이다.

⑭ Commit된 코드를 buildspec.yaml 파일에 따라 빌드를 해주는 역할을 한다.

⑮ Codepipeline은 CodeCommit과 CodeBuild 과정을 파이프라인을 통해서 모니터링 한다.

 

- 끝 -