AWS - Code Commit & Code deploy

Code Commit

• 파일들을 보관하는 저장 장소 (Repository) - Github과 매우 유사
  • 코드, 사진, 라이브러리, 그 밖에도 어플리케이션을 구동하기 위한 모든 파일 등..
• 동시에 많은 사람들이 저장 장소 접근 및 업데이트 가능
• 버전 컨트롤 기능 제공
  • Ex ) 언제 어떻게 누가 저장 장소 내용을 변경하였는지

Code Deploy = 자동배포 (Automated Deployment)

장점

• 새로운 기능들의 빠른 배포
• 소프트웨어 & 서버 다운타임 X
• Manual 에러 X

CD를 하지 않는다면, 서버를 닫고 작업이 이루어진 후에 작업이 끝나야만 서버를 재시작 후에 사용이 가능하다.

 

2가지 방식이 존재

 

• Rolling 배포
  • 현재 Prod에서 동작중인 서버가 있고 또 개발자들이 어떤 기능을 구현했고 그 기능을 서버에 적용하고 싶을 때 새로운 기능의 비중을 25%라고 하면 첫 배포시 75%는 기존 Prod 나머지 25%가 새로운 서버로 대체된다.
  • 예시

 

3개의 EC2 인스턴스가 존재하고 하나의 ELB로 묶여 관리가 되어있다 가정할 때

새로운 기능을 배포를 하려고 가정할 때 첫번째 인스턴스를 완전히 셧다운 한다.

첫번째 인스턴스가 비활성화 되어있기에, ELB도 수정을 해줘야 하고, 배포를 진행하게 된다.

그림과 같이 차례대로 두번째 인스턴스도 비활성화를 해서 배포를 진행하여 최종적으로는 모든 인스턴스에 배포를 진행한다.

Q : 만약 전부 배포를 완료했지만, 이슈가 존재하여 이전 버전으로 롤백을 해야할 경우는 어떻게 하는가 ?

A : Rolling 배포 방식을 사용한다면, 이전 버전으로 돌아가기 상당히 까다롭다. 한번에 돌아가기 힘들기에 Blue / Green 배포방식을 권장한다.

 

 

• Blue / Green 배포
  • 블루 = 현재 Prod // 그린 = 우리가 새로 배포할 코드들
  • 예시

마찬가지로 3개의 EC2 인스턴스고 하나의 ELB로 연결되어있고, 파란 부분은 현재 Prod에서 돌아가고 있는 원래 버전이다.

코드 디플로이는 현재 버전과 똑같은 Prod 하나를 생성한다. 새로운 버전으로 되어있는 부분은 초록색 부분인데,

 

초록부분을 ELB로 등록하고, 트래픽을 천천히 파란색에서 초록색 부분으로 이동시킨다.

그렇다면, 다음과 같이 파란색부분의 인스턴스는 모두 비활성화 되고 완전히 셧다운 된다.

 

Q : 이전 버전으로 돌아가고 싶다면 ?

A : EBL 설정만 변경하여, 초록색 부분의 트래픽을 파란색 부분으로 다시 넘겨주도록 한다.

단, 이전 버전을 삭제하지 않는다고 가정

 

그렇다면, Rolling 배포방법을 왜 쓰는가 ?

• 가장 처음 배포를 할때는 무조건 Rolling 배포 방식을 사용한다. 새로운 버전과 비교할게 없고, 상대적으로 빠른 배포가 가능하기 때문이다.
• Blue / Green 배포방식을 사용한다면, 두개의 환경을 구축해야 하기에 추가적인 비용이 부과된다.
• 서비스 어플리케이션이 발전하면 할 수록 Blue / Green 배포방식을 사용하는게 가장 적절하다.