Merge Request & Code Review가 중요하다 : 프로젝트에서 CI/CD 파이프라인 구축 & 수행하면서 느낀점

가장 최근에 진행한 화상 스터디 플랫폼에서 여러 가지 문제점을 겪었지만, 

배포 관련 깨달음을 적고자 한다 ^^..

 

DevOps란?

DevOps는 애플리케이션과 서비스를 빠른 속도로 제공할 수 있도록 조직의 역량을 향상시키는 문화 철학, 방식 및 도구의 조합이다.

요구사항을 빠르게 반영하기 위해, 서비스 품질의 손실 위험을 최소화하면서 개발은 빠르게 진행한다.

https://en.wikipedia.org/wiki/DevOps_toolchain

CI/CD란 ?

애플리케이션 개발 단계부터 배포 때까지 자동화를 통해서 사용자에게 빈번히 배포할 수 있도록 만드는 것을 말한다.

 

- CI(Continuous Integration) : 계획 > 코드 > 빌드 > 테스트

- CD(Continuous Delivery) : 출시 > 배포 > 운영

 

는 DevOps를 위해 필수적이다.

 

Docker란?

• 가상머신 - 독립적인 각각의 Guest OS
• 도커 - OS 위에 Docker Run time

https://www.redhat.com/ko/topics/containers/containers-vs-vms

 

 

Jenkins란 ?

젠킨스는 소프트웨어 개발 시 지속적 통합 서비스를 제공하는 툴이다.

(>> Cloud Registry에 Image PUSH까지 했다)

 

---

Merge Request & Code Review가 중요하다 

결론적으로는 OAuth 로그인 로직 개발을 담당했었는데, 프론트에서 개발 환경과 프로덕션 환경을 나누지 않아 고생했다.

 

직접적인 원인

프론트 팀원이 환경변수를 나눠 자동 적용시키지 않고, 개발환경에서 쓰는 Redirect_URL로 값을 직접 바꿔가며 작업을 했다. 막바지 기간이었고, 머지 리퀘스트 후 코드 리뷰 원칙을 지키지 않고, 본인이 풀 리퀘 날리고 리뷰없이 머지를 진행했다. 이때, 개발 환경에서 쓰는 리다이렉트 URL이 프로덕션 환경에 적용되었다.

 

오류를 찾는데 오랜 시간이 걸렸고, 잠재적인 원인 & 시간이 오래 걸린 이유를 다시 한번 분석해보았다.

 

1. 우리 시스템은 Web Hook으로 deploy 브랜치에 Merge Event가 들어오면, Jenkins가 감지해서 빌드 > 테스트 를 진행하고,

.Container Registery로 Push 하여 배포까지 자동으로 진행되도록 하였다.

코드가 Merge가 되면, 잘못된 배포가 되는 것을 막을 수 있는 방안이 없었다. 즉, 배포 직전에 한 번 멈춰서 점검했어야 했다.

 

2. 환경 변수를 전역적으로 관리하고 있지 않았다. 코드에 작성해서 여러 군데 분산된 값들을 찾고 직접 바꾸느랴 오래 걸렸다.

 

3. 배포가 잘되었는지 수동으로 확인했어야 했다. 이미지가 변경되지 않는 문제가 있었는데, 혹시 ?, 컨테이너 작동하고 있는 거 맞지?? 라는 마음으로 직접 Docker 명령어를 EC2 서버에 작성해가면서 확인했다. ( 내가 직접 기다렸다가 확인하는 Polling 방식이 아니고 Event 기반 알림이 필요했다. )

즉, 올바른 버전이 잘 배포되었는지 알려주는 모니터링 툴이 필요했다.

 

4. 중단 배포로 인해 컨테이너가 죽은 것인지 잠시 배포로 인해 서비스가 안되는 것인지 불안했다 

>> 실 서비스를 사용하는 사람 입장에서는 중단 배포하면 그 시간 동안은 서비스 안되는 거임

아! 무중단 배포 전략을 사용해야겠다.

 

이로 인해

1. Merge Request + Code Review의 중요성

2. CI/CD에서 자동 Deploy는 하지 말자

3. 환경 변수를 나누자

4. 공통적으로 사용되는 값은 변수로 빼서 정의하자

5. 모니터링 툴이 필요한 이유

6. 무중단 배포 전략을 사용하자!

를 깨닫게 되었다.

 

자동 Deploy 는 위험하다 / 코드 리팩토링 / 모니터링 툴이 필요하다 / 무중단 배포전략을 사용하자!

---

쿠버네티스

컨테이너 오케스트레이션(관리 및 배포) 플랫폼으로, 분산 애플리케이션을 쉽게 배포, 스케일링 및 관리하기 위한 도구이다.

쿠버네티스가 가지고 있는 주요 특징은 다음과 같다.

1. 선언적 구성 & 자동화된 스케일링

쿠버네티스는 YAML 또는  JSON 파일을 통해 애플리케이션과 리소스의 구성을 선언적으로 정의한다.

원하는 상태를 명시하면, 쿠버네티스가 시스템을 해당 상태로 조정한다.

 

노드나 컨테이너에 장애가 발생하면, 자동으로 장애를 감지하고 복구를 시도한다.

 

쿠버네티스 클러스터는 여러 노드로 구성되며, 필요에 따라 클러스터 크기를 확장하거나 축소할 수 있다.

2. 서비스 디스커버리 및 로드 밸런싱

쿠버네티스는 서비스 간 통신을 쉽게 관리하기 위해 서비스라는 방법을 제공한다.

서비스를 생성하면 DNS이름을 통해 탐색하고, 로드 밸런싱이 자동으로 이루어진다.

 

무중단 배포 

1. Blue/ Green

구 버전(Blue)과 새로운 버전(Green) 2가지를 서버에 마련하고 한꺼번에 교체하는 방법

배포시 2배의 자원을 사용한다.

 

2. 카나리아

일부 트래픽을 새버전으로 분산시켜 테스트를 진행하는 방법

A/B 테스트도 가능하다

 

3. Rolling Update

100% capacity가 유지가 되어야 한다 => 3 제외

기존 버전의 서버를 하나씩 죽이고 새로운 버전의 서버를 하나씩 띄우면서 순차적으로 교체하는 방법

서버를 하나하나씩 버전을 업그레이드하는 방식

이전 버전과 새로운 버전이 공존하는 시간이 존재한다.

---

다음 프로젝트에서는 쿠버네티스 사용해서 

이전의 문제점들을 해결해봐야겠다

---

스노우볼 굴리기 (인상깊어서)

상황이 여의치 않다 >> 방법을 바꾸자 >> 하루도 빠뜨리지 않고 조금씩 학습하면 나중에는 그 양이 어마어마할 것이다.