CI/CD와 무중단 배포

[10분 테코톡] 찬, 레넌의 CI/CD와 무중단 배포를 정리한 글

CI/CD

용어 정리
컴파일: 프로그래머가 작성한 소스코드를  기계어로 변환하는 과정
빌드: 소스 코드 파일을 컴퓨터에서 실행할 수 있는 소프트웨어 산출물로 만드는 과정. 보통 컴파일 과정을 포함
배포: 빌드의 결과물을 사용자가 접근할 수 있는 환경에 배치하는 것

CI(Continuous Integration)란?

지속적 통합이라는 뜻으로 개발을 진행하면서도 품질을 관리할 수 있도록 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리할 수 있음을 의미한다.

 

CI의 필요성

CI 이전에는 개발자들은 머지데이를 통해 모든 분기 소스코드를 병합하였다. 이는 많은 수작업과 리소스 낭비가 생겼다. 또한 개발자들이 코드를 병합할 때, 에러가 발생한 경우 디버깅하기 매우 어려웠다.

CI를 활용하면 업무를 쪼개어 코드 작성이 완료될 때마다 빠르게 자동 병합이 가능하다.

 

CI 과정

젠킨스를 이용한 CI 과정

1. 개발자가 코드 병합을 요청한다
2. CI툴(젠킨스)이 빌드와 테스트 진행한다
   1. 이상이 없는 경우 코드를 병합한다 
   2. 문제가 발생할 경우 개발자에게 피드백한다

그러나 CI 툴을 사용하는 것 만으로는 CI를 한다고 할 수 없다.

 

마틴 파울러가 제시하는 CI의 4가지 규칙

• 모든 소스코드가 살아있고 누구든 현재의 소스에 접근할 수 있는 단일 지점을 유지할 것
• 빌드 프로세스를 자동화해서 누구든 소스로부터 시스템을 빌드할 수 있게 할 것
• 테스팅을 자동화해서 언제든지 시스템에 대한 건전한 테스트 수트를 실행할 수 있게 할 것
• 누구든 현재 실행 파일을 얻으면 지금까지 가장 완전한 실행 파일을 얻었다는 확신을 하게 할 것

 

CD(Continuous Deployment)란?

지속적 배포라는 뜻으로 빌드의 결과물을 프로덕션으로 릴리스하는 작업을 자동화하는 것

 

CD의 필요성

서비스의 규모가 작아 서버가 한대인 경우, 서버에 들어가 직접 배포 스크립트를 수동으로 실행시켜 배포 가능하다. 그런데 서버의 규모가 커져 서버가 수십, 수백대로 늘어나는 경우 배포 스크립트를 일일히 실행시키기 어려울 것이다.

 

지속적 통합 vs. 지속적 제공 vs. 지속적 배포

• 지속적 통합은 빌드와 테스트까지의 자동화 작업 수행
• 지속적 제공은 프로덕션으로 릴리즈하는 작업을 수동으로 진행. QA 가능
• 지속적 배포는 프로덕션으로 릴리즈하는 Deploy작업을 자동으로 진행

 

CI/CD 흐름

1. 개발자가 코드 병합을 요청한다
2. CI/CD 툴이 빌드와 테스트를 진행
3. 에러가 발생하는 경우 개발자에게 피드백을 준다
   1. 이상이 없는 경우 코드를 병합한다
   2. CD과정을 통해 서버에 자동으로 배포한다

CI/CD 툴로는 Jenkins, Travis CI, Github Actions 등이 있다.

 

무중단 배포

리버스 프록시

• 인터넷과 서버 사이에 위치한 중계 서버
• 클라이언트가 요청한 내용을 캐싱
• 서버의 입장에서 클라이언트로부터 직접 요청을 받는 것이 아닌 리버스 프록시라는 대리 서버를 통해 요청을 받기 때문에 서버 정보를 클라이언트로부터 숨길 수 있어 보안에 용이

 

로드 밸런싱

• 부하 분산이라는 뜻
• 서버에 가해지는 부하를 분산해주는 역할
• 하나의 서버가 멈추더라도 서비스 중단 없이 다른 서버가 서비스를 계속 유지할 수 있는 무중단 배포가 가능
• 라운드 로빈 방식 등 로드 밸런싱의 다양한 알고리즘이 존재

 

무중단 배포란?

배포 자동화를 통해 서비스를 운영중일 때, 새로운 서비스를 배포하기 위해서는 기존 서비스를 종료하고 새로운 서비스를 시작해야한다. 이 두 행위 사이에 다운 타임이 발생하며 다운타임 동안 사용자들은 서비스를 이용할 수 없다. 무중단 배포는 이를 해결한다.

 

무중단 배포 구현 방법

• AWS에서 Blue-Green 무중단 배포
• 도커를 이용한 무중단 배포
• L4. L7 스위치를 이용한 무중단 배포
• Nginx를 이용한 무중단 배포(쉽고 저렴해서 많이 사용된다)

 

Nginx를 이용한 무중단 배포 방식

Rolling 배포

• 무중단 배포의 가장 기본적인 방식
• 서버를 차례대로 업데이트 시키는 방식

3대의 서버로 서비스를 운영중인 상황

1. 세대의 서버 중 한대의 서버에 로드 밸런싱을 라우팅하지 않도록 설정한다
2. 하나의 서버를 새로운 버전으로 업데이트한다
3. 라우팅 설정을 통해 다시 추가한다
4. 두번째, 세번째 서버도 마찬가지로 1,2,3를 반복해서 수행한다

장점

• 인스턴스를 추가하지 않아도 돼서 관리가 간편

단점

• 사용중인 인스턴스에 트래팩이 몰릴 수 있음
• 구버전과 신버전의 공존으로 인한 호환성 문제 발생 가능

 

Canary 배포

• 옛날 광부들이 유독 가스에 민감한 카나리아 새를 이용해 가스 누출 위험을 감지했던 것에서 유래하여 잠재적인 문제들에 대해 미리 대비하고자 나온 방식
• 신버전을 소수의 사용자들에게만 배포
• 문제가 없는 것이 확인되면 점진적으로 다른 서버에 신버전 배포

1. 첫번째 서버에는 라우팅을 하지 않도록 설정한다.
2. 첫번째 서버를 업데이트한다.
3. 라우팅 설정에 첫번째 서버를 다시 추가한다.
4. 업데이트된 첫번째 서버가 문제 없이 정상적으로 잘 작동 된다는 것을 확인한다.
5. 나머지 서버를 업데이트한다.

장점

• 문제 상황을 빠르게 감지 가능
• A/B 테스트로 활용 가능

단점

• 모니터링 관리 비용
• 구버전과 신버전의 공존으로 인한 호환성 문제

 

Blue/Green 배포

• Blue를 구버전, Green을 신버전으로 지정
• 구버전과 동일하게 신버전의 인스턴스를 구성
• 신버전 배포 시 로드 밸런서를 통해 신버전으로만 트래픽을 전환

1. 대기중인 서버를 새로운 서버 버전으로 업데이트한다.
2. 현재 서비스 중인 서버에서 대기중인 서버로 트래픽을 변경시킨다.
3. 대기중인 서버와 서비스 중인 서버가 변경된다.
4. 다음 업데이트 시 대기 중인 서버 그룹을 활용한다.

장점

• 배포하는 속도가 빠르다
• 신속하게 롤백 가능
• 남아 있는 기존 버전의 환경을 다음 배포에 재사용

단점

• 시스템 자원이 2배로 필요

 

정리

CI

• 고객의 요구사항에 빠르게 대응하기 위해 나온 XP(Extreme Programming)의 실천방안 중 1가지
• 여러 명이 하나의 코드에 대해서 수정을 진행해도 지속적으로 통합하면서 관리 가능

CD

• CI의 연장선에 있는 개념
• 빌드의 결과물을 프로덕션으로 지속적으로 배포하는 것

무중단 배포

• 다운타임 없이 서버를 운영할 수 있게 해주는 배포 방식
• Rolling, Canary, Blue-Green

리버스 프록시

• 클라이언트의 요청을 대신 받아 서버를 전달하는 대리 서버

로드 밸런싱

• 클라이언트의 요청을 여러 서버에 분산해주는 역할