DevKim
[ webtooniverse ] 프로젝트 구조 변경 - 무중단 배포 도입 본문
[ 현재 프로젝트 구조의 문제점]
현재 프로젝트 구조는 이러하다.
과금 문제 때문에 jenkins → git action 으로 CI 툴을 변경했고, S3에 jar 파일을 올려 CodeDeploy에서 EC2에 배포하고 있는 상황이다.
이런 구조를 계속 가져가게된다면, 새로운 V2를 배포하기 위해서, V1 서버를 내려야하는데 이 과정에서 유저는 서비스를 이용할 수 없는 상황이다.
문제는 현재 프로젝트에서는 기능이 주기적으로 추가되고 이에 따라 배포도 빈번하게 일어나고 있기 때문에, 매번 배포시마다 사용자가 서비스를 이용하지 못하게 된다면, 유저 입장에선 서비스에 대한 신뢰도 또한 감소될 것 이라고 생각한다. 무중단 배포가 시급한 상황이었다.
[ 다양한 배포 전략 ]
MSA 아키텍처를 지향하고 있는 추세이다보니, 이런 트렌드에 맞춰 이미 다양한 배포 전략이 개발되고 발전되고 있는 것 같다. 다행이도 다양한 배포 전략에 대한 자료들은 구글링을 통해 배울 수 있었고,
대표적인 배포 방식인 롤링배포, 블루-그린 배포, 포트 변경, 카나리 배포 중에 나는 '롤링 배포' 를 선택하기로 결정했다.
[ 롤링(rolling) 배포 ]
롤링 배포는 사용중인 인스턴스 내에서 새 버전으로 점진적으로 교체하는, 무중단 배포의 가장 기본적인 방식이다.
서비스 중인 인스턴스 하나를 로드밸런서에서 라우팅 하지 않도록 한 뒤, 새 버전을 적용하여 다시 라우팅 하도록 한다. 이를 반복하여 모든 인스턴스에 새 버전의 애플리케이션을 배포한다. 인스턴스마다 차례로 배포를 진행하기 때문에 상황에 따라 손쉽게 롤백이 가능하다는 장점이 있다.
가장 매력적으로 다가왔던 장점은 설치,구현 비용이 거의 없다는 것이었고 단순하다는 점이다.
단점으로는 배포 중엔 한쪽 인스턴스의 수가 감소되므로 서버 처리 용량을 미리 고려해야한다는 점이었지만,
현재 프로젝트 규모로 봐서는 이 점이 문제가 되지 않을 것 같았다.
* 무중단 배포 환경을 이해하기 위해 공부하면서 정리해둔 내용은 아래에 따로 적어두었다. *
https://yeon-woo-kim.tistory.com/339
[ 프로젝트 구조 변경 ]
무중단 배포를 위해 Nginx를 도입함으로써, 프로젝트 구조를 다음과 같이 변경하였다.
이로써 과금에 대한 문제는 이제 피할 방법이 없어졌고.. 결국 AWS 대신 GCP로 갈아타기로했다.
NCP도 고려를 했지만 GCP에서 30만원이 넘는 크레딧을 제공하고있기에 넉넉한 GCP를 선택했다.
소중한 크레딧 덕분에.. CI 툴을 다시 Jenkins 로 바꿨고, Nginx 인스턴스 1개, worker 인스턴스 3개로 구성하게되었다.
Nginx를 리버스 프록시로 도입함으로써 무중단 배포 뿐만 아니라, 로드밸런싱 즉 부하분산도 가능해졌다.
실제로 워커 인스턴스를 2개 정도로 줄여보고, scale out시 더 많은 트래픽을 견딜 수 있는지.. 그게 아니라면 어디에서 병목이 일어나고 있는지 측정해보는 시간을 가져야겠다.
[ etc ]
0. nginx LoadBalancing config
- 따로 분산 알고리즘을 적용하지 않으면 라운드 로빈 방식이 적용되므로 따로 건들지 않았고,
max_fails =3 으로 걸어놔서 3번 정도 실패가 일어나면 서버가 죽은 것으로 간주했고 fail_timeout=3 으로 설정했다.
1. nginx 에러로그 확인시
sudo tail -f /var/log/nginx/error.log
2. systemctl reload VS. systemctl restart
1. reload
: 서버를 종료하지 않은 채 conf 설정 파일들만 새로 갱신
-> restart보다 더 효율적이게 보일 수 있지만, 서비스에 따라 reload시 수행하는 동작이 어떻게 설정되었는지에 따라 수행하는 동작이 다를 수 있어(configuration을 리로드 하도록 설정하지 않은 경우), 기대치 않은 동작을 할수도 있음
2. restart
: 서버를 stop해주고 start해주는 작업
[ 추가적으로 궁금했던 점 ]
1. 트래픽이 엄청나게 많아져도 Nginx만으로 충분할까?
- 정답은 충분하지 않다고 한다.
아무리 scale out으로 서버의 수가 많아져도 결국 트래픽은 Nginx 서버를 거쳐가고 Nginx서버에서 처리할 수 있는 용량에도 한계가 있다고 한다.
- 해결 방법으로는 3가지 방법이 있다.
1-1. Nginx 서버 scale up 하기
1-2. 네트워크 장치로 로드밸런싱 하기
: 대표적으로 L4 스위치나 L7 스위치
1-3. DNS 리다이렉션
: 로드밸런서를 여러개 두고, DNS에서도 각 로드밸런서로 분산시켜주면 각 로드밸런서가 받아야 할 트래픽은 줄어든다고한다.
'Spring Project > Webtooniverse' 카테고리의 다른 글
[webtooniverse] 내가 만든 서비스의 성능을 개선해보자 (1) - Scale out (0) | 2021.08.17 |
---|---|
[ webtooniverse ] 내가 만든 서비스는 얼마만큼의 사용자를 견딜 수 있을까? - 서버 스트레스 테스트 (1) (0) | 2021.08.17 |
[Refactor] 쿼리 성능 개선 (0) | 2021.08.12 |
[Webtooniverse] CI/CD 구조 변경 - GitHub Action (0) | 2021.08.11 |
[Webtooniverse] Jenkins+webhook으로 Build&Deploy 자동화 적용 (0) | 2021.08.11 |