프로젝트 아키텍처 변경에 따른 새로운 파이프라인을 구축했습니다...!
v1 (이전 파이프라인)
간단한 CI/CD 파이프라인이였습니다.
하나의 EC2 인스턴스에 모니터링, 서버를 같이 넣어뒀었고,
pr을 main에 올릴시에 test 검증을 했고,
main에 pr이 push 되었을 때, 이미지를 새로 말아서
dockerhub에 업로드 후, AWS Shell 을 통해서 올라온 이미지를 pull 받는 형식의 파이프라인이였습니다.
CI/CD 파이프라인 변경 이유
1) 다중 AZ 사용
추후에 만들 프로젝트인 '얼루페이' 에는 결제 시스템이 필요합니다. 그로 인해, 서버의 가용성, 안정성이 중요하다고 생각했기에 2개의 가용영역에 인스턴스를 사용하기로 결정했습니다.
(+ 국가 창업 패키지 선정으로 인한 서버 비용 증가)
2) private subnet 환경으로 변경
private subnet은 외부와 소통할 수 없습니다.
그로인해, 외부환경인 dockerhub에 접근을 할 수 없었고,
dockerhub 대신, VPC Endpoint를 사용하면서, ECR Registry에서 이미지를 가져오기로 결정했습니다.
( NAT Gateway를 사용하면 외부와 소통할 수 있지만, 비용이 너무 많이 들더라고요,,,(달에 최소 8만원 ㅎ...)
바뀐 파이프라인입니다.
v2
그림을 잘 못 그리겠는데 대충 이런식입니다.
설명:
1) github pr시에 test 진행
2) main에 pr push 되었을 때 위의 파이프라인 시작
3) 도커 이미지로 말아서 ECR에 업로드
(여기까지 build)
4) S3 버킷에 올려놓은 deploy.sh 파일 가져와서 배포 시작
5) EC2 1번 배포 시작
-> 이 과정에서 트래픽은 전부 EC2 2번으로
6) EC2 1번 배포 완료
7) EC2 1번 health check 성공시에 EC2 2번 배포 시작
-> 이 과정에서 트래픽은 전부 EC2 1번으로
8) EC2 2번 배포 완료
9) EC2 2번 health check 성공 시에 다시 트래픽 50씩 분산
바뀐 파이프라인은 Rolling 배포 전략을 사용해 무중단 배포를 구현했습니다.
Rolling 배포 선택 이유:
1) 구현이 가장 간단했음
2) 단점이 크게 영향을 미치지 않을 거 같았음
-> 롤링 배포의 단점은 2가지 정도 있습니다.
-
ex) 3개의 EC2 인스턴스가 있다고 가정해봅시다.
1번 EC2가 배포되는 동안, 2,3번으로 트래픽이 분산됩니다.
1번 EC2 배포 완료 후 2번 EC2 인스턴스 배포
-> 이 과정에서, 1번 3번은 다른 버전을 사용하게 됩니다. -
하나의 EC2 인스턴스가 모든 트래픽을 받아 서버에 과부하가 발생할 수 있습니다.
위의 두 문제점은 크게 문제가 될 것 같지 않았습니다.
이유 1) 얼루가는 현재 2개의 EC2 인스턴스를 사용하기 때문에, 여러 버전이 공존하는 오류는 없다고 판단했습니다.
이유 2) 현재 t3.small 사용중인데, 초기에는 t3.small을 다운시킬 정도의 트래픽이 없을거라고 생각했습니다.
위와 같은 이유로 rolling 배포를 이용해 무중단 배포를 구현했고, 추후 Blue-Green으로 바꿀수도 있습니다ㅎ
파이프라인 설명 끝!
