CI & CD

CI (Continuous Integration - 지속적 통합)

VCS 시스템(Git과 같은 버전 관리 시스템)에 변경 사항이 PUSH되면 자동으로 테스트와 빌드가 수행되어 안정적인 배포 파일을 만드는 과정을 말한다.

CI라는 개념이 등장하게 된 배경

하나의 프로젝트는 여러 개발자가 함께 개발을 진행한다.

때문에 각자가 개발한 코드를 합치는 것이 큰 일이고, 이를 수동으로 진행하는 것은 많은 시간을 소요하게 된다. 이는 생산성 저하로 이어질 수 있다.

이러한 문제를 해결하기 위해 각자가 원격 저장소에 푸시했을 때 코드를 자동으로 병합하고 테스트, 빌드를 수행해주는 CI 환경을 구축하게 된 것이다.

CI를 도입하기 위한 4가지 규칙

1. 모든 소스 코드가 실행 중에 있어야 하며, 누구든 이 코드에 접근할 수 있는 단일 지점을 유지해야 함

2. 빌드 프로세스를 자동화해서 누구든 소스로부터 단일 명령어를 통해 시스템을 빌드할 수 있어야 함

3. ⭐ 테스팅을 자동화해서 언제든 시스템에 대한 테스트 수트(suite)를 실행할 수 있어야 함

   • 프로젝트의 완전성 보장을 위한 가장 중요한 요소

4. 누구든 현재 얻은 실행 파일이 가장 완전한 것이어야 함

CD (Continuous Deployment - 지속적 배포)

위의 빌드 결과물(배포 파일)을 자동으로 운영 서버에 무중단 배포를 수행하는 과정을 말한다.

CD라는 개념이 등장하게 된 배경

대량의 트래픽을 처리하기 위해 서버의 개수는 수십, 수백 대가 될 수 있다.

많은 서버에 수동으로 배포를 수행하는 것은 많은 시간을 소요한다. 이는 생산성 저하로 이어질 수 있다.

CD를 적용하는 방법

• AWS Blue-Green 무중단 배포

• Docker 이용

• Nginx 이용

• L4, L7 스위치 적용

CD(무중단 배포) 알고리즘

로드 밸런싱을 이용한다.

Rolling Development

• 서버를 하나씩 로드밸런서의 라우팅 대상에서 제외하고, 업데이트하고, 다시 연결하는 것을 반복

• 장점

  • 배포를 위해 추가적인 자원(새로운 인스턴스 등)을 사용하지 않음

• 단점

  • 특정 인스턴스가 요청을 처리하지 못하게 됨으로써 부하 발생 가능

  • 구 버전과 새 버전의 애플리케이션이 공존하게 되어 호환성 문제 발생 가능

Canary Development

• 일부 사용자에게 새 버전의 애플리케이션을 제공하고, 문제가 없다면 전 서버에 반영

• 장점

  • 새 버전에 문제가 있다면 빠르게 감지하고 수정 가능

• 단점

  • 새 버전 사용자를 대상으로 모니터링을 수행해야 함 (모니터링 비용)

  • Rolling 방식과 마찬가지로 호환성 문제 발생 가능

Blue/Green Development

• 두 개의 인스턴스 그룹을 준비하고, 하나를 운영

• 새 버전을 배포할 때 나머지 한 그룹에 새 버전을 반영하고 해당 그룹으로 라우팅 변경

• 추후 새 버전이 배포될 때에는 다른 한 그룹에 반영하고 다시 라우팅 변경

• GC Copy 알고리즘과 유사하게 동작

• 장점

  • 새 버전 반영 속도가 빠름

  • 새 버전에 문제가 있다면 롤백하는 속도도 빠름

• 단점

  • 리소스가 두 배로 필요 (기존 대비 두 배의 인스턴스가 필요하므로)