[팀 프로젝트] 개발 환경 자동 구축 시스템

카카오클라우드스쿨의 최종 팀 프로젝트

개인 프로젝트를 팀원들에게 공유하고 피드백을 받은 후, 아쉬운 부분을 보완하고 좀 더 규모, 기능을 확대하여 온전한 서비스를 만들어 보고자 진행된 프로젝트입니다.

소개

• 기간 : 23.03 ~ 23.05 (2개월)
• 인원 : 5명
• 담당 역할 : 리소스 모니터링, CI/CD 전략 수립
• 사용 스택 : AWS, EKS, K8S, Prometheus, Thanos, Grafana, Jenkins, ArgoCD, Helm, Nexus3

프로젝트 개요

개발자가 작성한 좋은 코드가 제품화 되기 위해서는 코드 작성 단계에서부터 서비스 배포 및 운영까지의 파이프라인이 잘 구성되어야 한다.

제품이 전달되는 과정은 프로젝트 셋업 → 개발 → CI/CD 구성 → 배포 → 운영의 단계를 거친다.

MSA로 시스템을 구성하다보면 이러한 작업은 여러번 반복되게 된다.

이러한 반복된 작업에 소모되는 리소스를 줄이기 위해 여러 타입에 따른 보일러 플레이트를 제작하여 사내에서 공통적으로 사용되는 라이브러리, 툴, 개발 규칙 따위를 전역적으로 관리한다. 

또한 개발자는 CI/CD나 운영에 관련된 지식이 부족하여도 최소한의 파이프라인과 운영에 필요한 관측치를 제공한다.

 

사내 시스템을 상정하여, 부서 별로 K8S 클러스터(Dev, Ops)를 제공하고 중앙 관리 클러스터(Central)를 통해 각 클러스터를 제어한다.

 

구성

AWS 구성도

VPC CNI add on을 통해 쿠버네티스 포드가 VPC 네트워크 대역과 동일한 IP 주소 대역을 가진다.

 

Load Balancer Controller를 통해 ingress를 관리하고 이때, target group도 같이 만들어지고, Ingress의 어노테이션에 Certificate Manager을 등록하여 SSL을 붙인다.

 

external dns는 DNS 서비스를 사용하여 쿠버네티스의 리소스를 쿼리할 수 있게 연동시켜주는 오픈소스이다. AWS Route53을 사용했고, Ingress에서 hostname을 설정하여 사용자가 도메인 이름으로 서비스에 접속할 수 있게 한다.

 

EBS CSI Driver add on을 통해 쿠버네티스 퍼시스턴트 볼륨 클레임이 EBS 볼륨을 생성하고 수명 주기를 관리.

 

쿠버네티스 externalName 타입의 서비스로 RDS 엔드포인트와 연결된 쿠버네티스 서비스를 만들어서 포드가 해당 쿠버네티스 서비스의 DNS로 데이터베이스와 통신을 할 수 있다.

 

Pod에 IAM Role이 연결된 서비스 어카운트를 사용하여 ECR과 같은 다른 AWS 서비스에 접근할 수 있게 한다. 이렇게 함으로써 IAM 권한의 범위를 서비스 계정으로 지정할 수 있고, 그러면 해당 서비스 계정을 사용하는 Pod만 해당 권한을 가지게 된다.

Service 흐름

 

 

개발자가 애플리케이션을 생성하면, 타입에 맞는 보일러 플레이트를 포크하여 레포지토리를 제공 받는다.

해당 레포지토리를 기반으로 Gitops의 CI/CD가 일어나며, 소속에 해당하는 클러스터에 배포된다.

배포된 애플리케이션에 대한 모니터링과 로깅을 제공 받는다.

시연 연상

https://www.youtube.com/watch?v=e50cfM8ad88  

 

상세 업무

 

리소스 모니터링

 

멀티 클러스터 모니터링 전략

Prometheus와 Prometheus의 여러 단점을 보완하기 위한 Thanos, Prometheus Operator 사용한다.

각 클러스터 별 Prometheus-Thanos를 운영하여 메트릭을 관측하며 중앙 클러스터에서 모든 클러스터의 메트릭을 수집해 클러스터 정보를 확인한다.

각 부서 별 클러스터는 각 클러스터의 메트릭과 Application 메트릭을 관측한다.

 

공통적으로 사용되는 Grafana Dashboard와 Prometheus Alert를 쿠버네티스 리소스로로 생성하여 재사용성과 관리 편의성을 고려했다.

클러스터와 애플리케이션에 대한 알림은 설정된 Slack에서 알림을 받을 수 있다.

 

CI/CD 전략

Application을 생성하면 각 타입에 해당하는 보일러 플레이트를 포크하는데, 이 과정에서 Source Code와 Helm Chart 레포지토리를 별도로 생성한다.

이 레포지토리를 기반으로 Gitops의 CI/CD를 수행하며, 레포지토리를 분리함으로써 커밋 로그를 통해 버전 관리를 더욱 편하게 할 수 있다.

 

Jenkins Agent를 Pod로 생성하여 각 빌드가 독립적으로 수행되고, 컴퓨팅 파워 추가 할당을 용이하도록 했다.

빌드 이미지로는 Kaniko를 사용하여 이미지 빌드 과정에서 Cache 기능을 사용할 수 있도록 성능을 향상 하고, Docker에 대한 종속성을 제거 했다.