무중단 배포란?
앞서 포스팅했던 CI/CD로 자동 배포 후, 새로운 서비스를 배포하기 위해서는 기존 서비스 종료 후 새로운 서비스를 시작하여야 한다.
기존 서비스 종료 <-> 새로운 서비스 시작
이 사이에서 다운 타임이 발생하게 된다. 다운타임 동안 사용자들이 서비스를 이용할 수 없다.
이를 해결하기 위한 개념이 다운 타임 없이 서버를 운영할 수 있게 해주는 배포 방식인 무중단 배포이다.
무중단 배포 구현 방법
- AWS에서 Blue-Green 무중단 배포
- Docker를 이용한 무중단 배포
- L4, L7 스위치를 이용한 무중단 배포
- Nginx를 이용한 무중단 배포(쉽고 저렴하여 많이 사용!)
자주 나오는 용어
Reverse Proxy
- 클라이언트의 요청을 대신 받아 서버에 전달하는 대리 서버이다.
- 클라이언트가 요청한 내용을 캐싱할 수 있다.
- 서버 정보를 클라이언트로부터 숨길 수 있어 보안에 용이하다.(클라이언트로부터 직접 요청 받기 X)
Load Balancing
- 서버에 가해지는 부하(요청)를 여러 서버에 분산해주는 역할을 한다.
- 하나의 서버가 멈추더라도 서비스 중단(다운 타임) 없이 다른 서버가 서비스를 유지할 수 있는 무중단 배포가 가능하다.
무중단 배포(Nginx를 이용한) 방식
1. Rolling 배포
- 무중단 배포의 가장 기본적인 방식
- 서버를 차례대로 업데이트 시킨다.
세 대의 서버로 서비스를 운영하고 있다고 가정하자.
1) 세 개의 서버 중 하나에 Load Balancing을 Routing하지 않도록 설정한다.
2) 이 서버를 새로운 버전으로 업데이트 시켜준다.
3) 그 후 라우팅 설정을 통해 다시 추가해준다.
이것을 2개의 서버도 똑같이 반복한다.
장점
인스턴스를 추가하지 않아도 되서 관리가 간편하다.
단점
사용중인 인스턴스에 트래픽이 몰릴 수 있다.
구버전 신버전이 공존하여 호환성 문제를 일으킬 수 있다.
2. Canary 배포
- 신버전을 소수의 사용자들에게만 배포한다.
- 문제가 없는 것이 확인되면 점진적으로 다른 서버에 신버전을 배포한다.
네대의 서버로 서비스를 운영하고 있다고 가정하자.
1) 네 개의 서버 중 하나에 Load Balancing을 Routing하지 않도록 설정한다.
2) 이 서버를 새로운 버전으로 업데이트 시켜준다.
3) 그 후 라우팅 설정을 통해 다시 추가해준다.
위의 과정으로 인해 업데이트 된 서버가 문제 없이 작동한다면(25%)
나머지 서버 세 대에도 업데이트를 시킨다.(100%)
장점
문제 상황을 빠르게 감지할 수 있다.
A/B 테스트로 활용 가능하다.
단점
모니터링 관리 비용이 든다.
구버전과 신버전의 공존으로 인한 호환성 문제가 생긴다.
3. Blue/Green 배포
- Blue를 구버전, Green을 신버전으로 지칭한다.
- 구버전과 동일하게 신버전의 인스턴스를 구성한다.
- 신버전 배포 시 로드 밸런서를 통해 신버전으로 트래픽 전환
현재 위쪽에는 서비스 중인 서버의 그룹과 아래쪽은 대기중인 서버가 존재한다고 가정하자.
이때 새로운 서버를 적용시키고 싶다면
1) 대기 중인 서버에 새로운 버전으로 업데이트 시킨다.
2) 트래픽을 현재 서비스 중인 서버에서 대기중인 서버로 변경시켜준다.
그렇다면 위쪽이 대기 중인 서버가 되고, 아래쪽은 현재 서비스 중인 서버가 된다. 따라서 위쪽의 대기 중인 서비스는 다음번에 새로운 서비스로 업데이트 시킬 때 활용할 수 있다.
장점
배포하는 속도가 빠르다.
신속하게 롤백이 가능하다.
남아 있는 기존 버전의 환경을 다음 배포에 재사용 가능하다.
단점
시스템 자원이 2배로 필요하다.
+) Nginx
정적 파일의 경우에는 Nginx가 클라이언트로부터 직접 요청을 받아 처리하고, 저장된 정적 파일을 반환한다. 따라서 정적 파일은 Nginx를 거쳐 WAS로 전달되지 않는다.
동적 파일의 경우에는 Nginx는 동적 파일 요청을 WAS로 전달하고, WAS가 처리한 결과를 다시 클라이언트에게 반환한다.
이러한 방식으로 Nginx(Web Server)와 WAS(Web Application Server)가 협력하여 동적 파일을 처리하고 응답합니다.
