1) 빌드
[11/08] 컴파일 VS 빌드
1) 컴파일 (compile) 컴파일(compile) : 원시 코드에서 목적 코드로 옮기는 과정 원시 코드 (source code) : 원래의 문서 목적 코드 (object code) : 출력된 문서, 컴파일러나 어셈블러가 소스 코드 파일을 컴파
bean-soup-99.tistory.com
2) 배포
배포 : 작성한 코드를 빌드하고, 빌드가 완성된 실행 가능한 파일을 사용자가 접근할 수 있는 환경에 배치하는 것
EX) 빌드를 하고 생성된 jar 또는 war 파일을 WAS (Web Application Server)에 올리는 것
1) git (소스 형상 관리)에 올리기
2) 코드가 제대로 동작하는지 테스트 코드 작성
3) 테스트 수행 및 검증
➡ 빌드가 잘 되면 배포가 가능한 상태
3) CI/CD
CI (Continuous Integration)
- 지속적 통합
CI (Continuous Integration)
지속적 통합이라고도 하며, 코드 변경사항마다 빌드, 테스트까지 자동으로 진행하고 결과물을 보고 받고
리포지토리에 자동 통합되는 프로세스
지속적 통합이라고도 하며, 코드 변경사항마다 빌드, 테스트까지 자동으로 진행하고 결과물을 보고 받고
리포지토리에 자동 통합되는 프로세스
- 개발자를 위한 자동화 프로세스인 지속적 통합
- 모든 개발이 끝난 이후에 코드 품질을 관리하는 고전적 방식의 단점을 해소하기 위해 나타난 개념
EX) 기존에는 모든 개발이 끝난 이후 코드 품질을 관리
- 모든 코드를 다 작성한 후 다 통합하려면 에러가 엄청 많이 발생 (Integration Hell 발생)
- 통합할 때 에러를 다시 고치면 비용적인 측면이 많이 들어감
➡ 주기적으로 계속 통합시켜 주면서 발생하는 에러를 확인하고 고쳐나가자!
CI 프로세스
- 코드를 통합
EX) git에 자신이 개발한 코드를 올려서 통합 - 통합한 코드가 제대로 동작하는지 테스트
- 제대로 빌드가 되는지 테스트
- 결과 정리 및 버그 리포
매번 직접하기 번거로움 ➡ 자동화 도구 (EX Jenkins, Travis)
CI 특징
- 클래스에서부터 기능, 더 나아가 전체 어플리케이션에서의 테스트를 수월하게 진행
- 신규 코드와 기존 코드의 충돌을 빠르게 수정 가능
- 협업 시에 애플리케이션이 최신 상태로 유지됨을 믿을 수 있음
CD (Continuous Deploy)
- 지속적 배포
CD (Continuous Deployment)
개발자들이 코드에 변경사항을 줄 경우, 파이프 라인을 통해 이동하여 프로덕션 단계까지 자동으로 배포되는 프로세스
개발자들이 코드에 변경사항을 줄 경우, 파이프 라인을 통해 이동하여 프로덕션 단계까지 자동으로 배포되는 프로세스
- 소프트웨어가 항상 *신뢰 가능한 수준에서 배포될 수 있도록 관리하자는 개념
* 신뢰 가능한 수준?
- 테스트를 다 통과, 빌드도 잘 됨 등
CD 특징
- 애플리케이션을 프로덕션으로 빠르고 쉽게 배포
- 소비자들의 요구를 빠르게 만족시키는 서비스 출시가 가능
- 개발팀과 운영팀의 간극을 메워줄 생산성 향상
"CI가 선행됨에 따라서 CD가 가능함" ➡ CI/CD라고 묶어서 통칭해서 부름
💡 CI/CD 정리
- 지속적으로 통합하면서 테스트와 빌드를 진행
- 이를 통과한 코드에 대해서 신뢰할 수 있고 바로 배포할 수 있다는 개념
- 지속적으로 통합하면서 테스트와 빌드를 진행
- 이를 통과한 코드에 대해서 신뢰할 수 있고 바로 배포할 수 있다는 개념
4) 무중단 배포
- 롤링 배포, 카나리 배포, 블루그린 배포가 있음
EX) 기존에 동작하고 있는 서버(배포가 완료된)가 존재
- 새롭게 업데이트한 코드를 배포한다면? ➡ 충돌 발생
- 기존에 서비스 중인 1) 서버를 잠시 내리고 2) 코드를 배포한 후 3) 다시 서버를 동작 시켜야 함
- 서버가 다시 뜨는 시간만큼 다운 타임(유저에게 서비스가 불가능한 시간)이 발생
➡ 유저들에게 최대한 신뢰성있고 성능이 좋은 환경을 제공해줘야 하지만 이런 경우가 자주 발생한다면 문제가 됨
➡ 지속적인 서비스가 필요한 환경에서는 무중단 배포를 고려해야 함
필요 조건
- 두 대 이상의 서버를 서비스 해야 함
- 다운 타임이 발생하지 않으려면 실제 서비스 중인 서버와 새롭게 배포한 서버가 동시에 존재해야 함
- 비용을 줄이려면 배포할 때만 새롭게 서버를 띄우고 배포가 완료된 후에 기존 서버를 죽이면 됨
Rolling 배포
- 여러대의 서버가 있을 때 차례대로 배포하는 방법
- 배포 중인 서버를 제외한 나머지 서버들이 부하를 감당
- 하나의 서버가 중단되었을 때 나머지 서버의 부하량을 잘 파악해야 함
EX)
- 서버 1을 로드 밸런서에서 뺀다
- 서버 1에 배포한다
- 서버 1을 다시 로드 밸런서에 넣는다
- 서버2를 로드 밸런서에서 뺀다
- 서버 2에 배포한다
- 서버 2를 다시 로드 밸런서에 넣는다
*로드 밸런서 : 서버로부터 들어오는 요청을 최대한 잘 분배하는 일을 담당하는 역할을 함
장점
- 인스턴스마다 차례로 배포를 진행 ➡ 상황에 따라 손쉽게 롤백 가능
- 추가적으로 인스턴스를 늘리지 않아도 됨
- 관리가 간편함
단점
- 호환성의 문제가 발생할 수 있음
→ 배포할 서버가 너무 많다면 n대 단위로 배포를 할 수 있음
→ 배포가 모두 끝나기 전까지 유저마다 받을 수 있는 서비스가 다름
EX) 어떤 유저는 이전 서비스를 받고 누구는 신규 서비스를 받을 수 있음 - 1대에 배포하는 것 보다 최소 2배 이상 느림
- 사용중인 인스턴스에 트래픽이 몰릴 수 있음
EX) 100 까지 감당 가능한 서버 3대가 있을 때
70, 70, 70 씩 부하를 가지고 있다면 한 개의 서버만 다운타임이 생겨도
0, 105, 105가 되어 모든 서비스가 마비가 될 수 있음
Blue / Green 배포
- 실제로 서비스 중인 환경(Blue) 과 새롭게 배포할 환경(Green)을 세트로 준비하여 배포하는 방식
- 새롭게 배포할 서버를 준비하는 동안 구 버전 서버로 트래픽을 흘림
- 운영중인 구 버전과 동일하게 신 버전의 인스턴스를 구성한 후 로드밸런서를 통해 모든 트래픽을
한 번에 신 버전 쪽으로 전환/
장점
- 새롭게 배포할 환경에만 배포하면 되기 때문에 배포 속도가 매우 빠름
- 구버전의 인스턴스가 남아있어 손쉽게 롤백 가능
단점
- 시스템 자원이 두 배로 필요함
- 새로운 환경에 대한 테스트가 전제되어야 함
Canary 배포
- 소수의 유저 (EX 사내) 만 사용하는 환경 (Canary 환경)에 신규 버전을 배포
- 문제가 없다고 판단됐을 때 다른 모든 서버에 배포
- 트래픽을 단계적으로 전환 ➡ 부정적 영향을 최소화하고 상황에 따라 트래픽 양을 조절하여 롤백할 수 있음
장점
- 문제 상황을 빠르게 감지 할 수 있음 (오류를 감지 하는데 효과적)
- 구버전의 인스턴스가 남아있어 손쉽게 롤백 가능
단점
- 네트워크 트래픽 제어 부담
참고문헌
3) [CI/CD] 배포 전략 (Rolling, Blue Green, Canary)