CI/CD 기본 개념과 필요성
CI/CD란?
CI/CD는 소프트웨어의 개발 및 배포를 자동화하는 프로세스입니다.
CI (Continuos Integration)
지속적 통합
내가 작성한 코드를 main 또는 dev 브랜치에 통합하는 과정입니다. push를 할 때 자동으로 빌드와 테스트를 하도록 설정을 할 수 있다는 장점이 있습니다.
만약 main과 dev 브랜치를 나누어 개발하는 방법을 선택한다면 main용 CI와 dev용 CI를 따로 작성할 필요 없이 브랜치 조건만 다르게 해서 하나의 yaml/파이프라인으로 관리 할 수 있습니다.
CD (Continuos Delivery or Deployment)
지속적 제공
통합된 코드를 언제든 배포할 수 있는 상태로 유지하는 것을 의미합니다. 이 경우에 자동으로 배포와 테스트를 한 후에 운영 서버에 배포하는 것은 사람이 승인하여야 이루어 지는 구조입니다.
지속적 배포
승인 단계를 거치지 않고 자동으로 운영 환경까지 배포하는 것을 의미합니다. 서비스는 승인 없이 이루어지기에 빠르지만 안정성은 지속적 제공보다 떨어집니다.
CI/CD의 필요성
코드 통합에 따른 번거로움과 오류의 감소
여러 개발자가 작업을 하다 합치는 경우에 main에 merge를 할 때 테스트를 검증하지 않으면 오류가 발생할 수 있습니다. 자신의 컴퓨터에서는 작동하더라도 실제 통합 서버에서는 잘 작동하지 않을 수 있기 때문입니다. 또한 비슷한 환경을 컴퓨터에 구축해서 돌리려고 한다면 pull로 최신 내용을 가져오는 것과 테스트를 하나씩 실행하고 확인하는 것에 시간이 걸리기 때문에 이 절차를 자동으로 실행하는 것은 이점이 있습니다.
배포 과정 수동의 번거로움
직접 코드가 완성 될때마다 빌드하고 배포를 하게 되면 실수가 발생 할 수도 있으며, 귀찮습니다. 그렇기 때문에 배포를 자동으로 할 수 있도록 구현하는 것이 필요합니다. 물론 승인 방식을 통한 이중 체크로 구현해도 괜찮습니다.
혹시 모를 오류 발견
사람이 직접 테스트를 돌리고 합치게 되면 실수로 테스트를 누락하여 오류가 발생했다는 내용을 놓칠 수도 있습니다. 그렇기에 매번 합칠 때마다 자동으로 테스트를 실행하게 하여 오류를 초기에 발견하는 것은 비용 감소에 도움이 됩니다.
CI/CD 구현 도구
가장 유명한 툴은 'Jenkins'와 'Github Action'입니다.
Jenkins
Jenkins는 다양한 플러그인과 커뮤니티를 기반으로 편리하게 CI/CD를 도와주는 도구입니다.
장점
Jenkins의 장점으로는 다양한 플러그인을 지원하여 커스터마이징을 자유롭게 할 수 있다는 점이 있습니다. 또한 파이프라인으로 인한 병렬 실행으로 대규모나 복잡한 워크플로우에 강력합니다.
단점
다만 서버를 추가로 따로 뛰어야 해서 관리와 비용적인 면에서 부담이 될 수도 있습니다. 거기다 깃허브 액션보다 학습이 어려워 배우는 것에 시간이 걸린다는 단점도 존재합니다.
Github Actions
깃허브에 내장된 CI/CD 서비스로 별도의 설치 없이 Github 저장소에서 바로 실행이 됩니다.
장점
깃허브에서 제공하는 서비스라 깃허브와 호환성이 좋고 깃허브 UI에서 변화를 확인할 수 있습니다. 또한 깃허브에서 클라우드 Runner를 제공하여 따로 서버를 뛰우지 않고 빌드/테스트까지 가능하다는 장점이 있습니다. 또한 YAML 파일 기반이라 간단하게 작성할 수 있습니다.
단점
깃허브에 종속되어 다른 환경에서는 사용하지 못한다는 점과 클라우드 러너가 제공하는 OS에 한정되어 있어 테스트 자체를 내 EC2 서버에서 하고 싶다면 내 EC2를 따로 Self-hosted Runner로 등록해서 사용해야 한다는 번거로움이 있습니다.
보안 관점에서의 환경별 설정 관리 전략
1. 코드와 비밀 값 분리
소스코드와 레포지토리에 API 키나 DB 비밀번호와 같은 민감한 값을 포함하지 하고 관리하는 전략입니다.
.env 파일 사용
.env 파일을 만들어 배포를 한 후에 이 값을 사용하는 방법과 env 파일을 올려서 사용하는 방식이 있으나 env 파일을 올리는 방법은 보안 상 사용하지 않습니다.
Secret 기능 활용
Github Action이나 Jenkins는 Secret Stroe를 제공합니다. 이를 이용해서 민감한 값은 secret store에 저장하고 워크 플로어에서 직접 사용을 할 때 꺼내 사용하는 방법이 있습니다. 이 때 동적으로 .env 파일을 생성합니다.
Cloud Secret Mananger 기능 활용
AWS에서 제공하는 기능으로 IAM 권한이 있는 애플리케이션을 대상으로 정보를 제공해줍니다. 자동 로테이션을 지원하여 안전합니다. 다만 초기 설정이 복잡하고 비용이 발생할 수 있습니다.
깃 서브 모듈
애플리케이션 코드와 설정 코드를 분리하여 별도의 레포지토리로 관리하는 방식입니다. 다만 Submodule 관리가 귀찮다는 단점이 있습니다. 환경별 config 버전을 깃으로 관리할 수 있다는 장점이 있습니다. 비밀 값이 깃에 기록되고 비밀 값 변경 시 config 변경이 필요하기 때문에 CI/CD YAML 방식보다 효율이 떨어진다고 생각됩니다.
2. 환경별 분리
Dev, Prod 용 환경을 분리하여 각각 다른 시크릿키를 사용하는 방법을 사용하는 방법입니다. 운영 환경 키가 외부에 노출되지 않도록 완전히 분리하는 방법입니다.
환경별 배포 전략
환경 변수 설정 방법
dev와 prod 별로 다른 Secret Store를 사용하여 환경 변수를 분리하는 방법과 config 파일을 분리하여 CI/CD가 브랜치에 따라 올바른 파일을 선택할 수 있게 하는 방법이 있습니다.
배포 실패 시 롤백 전략
Blue-Green Deployment
Blue와 Green으로 2개의 서버를 동시에 운영하고 새 버전에 문제가 생기면 이전의 버전으로 트래픽을 되돌리는 방법입니다.
Canary Deployment
소프트웨어의 업데이트를 점진적으로 적용하여 전체 시스템에 미치는 영향을 최소화하기 위한 배포로 일부 사용자에게 새로운 버전을 배포하고 문제가 생길 시에 자동으로 롤백할 수 있습니다. 다만 모니터링을 지속적으로 해야한다는 단점이 있습니다.
Rolling Update with Health Check
기존 애플리케이션 서버를 한 번에 다 바꾸지 않고 조금씩 새 버전으로 교체하는 방식으로 서버가 많을 때 유용합니다. Health Check는 배포를 할 때 정상적으로 동작하는 지를 확인하는 것을 말하며 Http 엔드포인트의 200 코드를 확인하는 것이나 TCP 포트가 열러있는 지를 확인하는 방식이 있습니다. 기본은 헬스 체크에 실패한 새 버전에서만 롤백합니다.
롤백 시 주의 점
DB 마이그레이션
원래 사용하던 DB에서 다른 DB로 옮기는 것을 의미합니다. 위의 전략으로 애플리케이션은 롤백할 수 있지만 DB는 한번 변경하게 되면 롤백을 하는 것이 어렵습니다. 따라서 배포 이후 일정 기간 동안 새 컬럼에 대한 추가는 가능하지만 삭제는 불가능한 Backward-compatible 설계를 사용하거나 DB를 구버전과 신버전 둘다 지원할 수 있게 설계 하는 방법이 있습니다. 또한 DB 마이그레이션 툴을 이용하여 DB 변경을 버전 별로 관리하고 롤백 스크립트를 정의하는 방법도 있습니다.
모니터링과 알람 필요
서버를 업데이트 한 이후에 트래픽이 몰리고 에러가 발생한다면 문제가 발생할 수 있기에 수동으로 에러를 발견하기 전 미리 자동으로 에러를 감지하고 롤백하는 기능을 이용할 필요성이 있습니다. 에러율과 응답속도, CPU와 메모리 사용량 등을 모니터링하고 임계치를 넘으면 자동으로 롤백이 되도록 트리거를 설정합니다.
파이프 라인 최적화 전략
병렬 실행
여러 작업을 동시에 실행해서 파이프 라인의 시간을 줄이는 방법이 있습니다. Lint test, Unit Test, End-to-End Test 등을 동시에 실행하는 것과 프론트 엔드와 백엔드의 테스트를 동시에 실행하는 것이 있습니다.
캐시 활용
의존성을 매번 새로 설치하면 시간이 낭비 되기 때문에 package가 변경 되지 않는 한 그대로 사용할 수 있도록 캐시를 활용하여 속도를 개선하는 방안이 있습니다.
아티팩트 재사용
도커 이미지와 빌드 산출물을 여러 번 빌드 하지 않도록 하나의 작업에서 생성한 결과물을 다른 Job에서 재사용할 수 있게 설정하는 방법이 있습니다.
Fail Fast 전략
에러가 발생하면 즉시 파이프 라인을 중지 하여 이후의 작업 실행으로 인한 시간을 절약하는 방법이 있습니다.
- 출처
사진: Unsplash의Laura Ockel
