[인프라] Nginx 사용하여 Blue/Green 무중단 배포 도입

무중단 배포 도입 배경

 GitLab 파이프라인을 사용하여 CI/CD를 구축하였는데 build 되고 서비스가 배포되는데 약 8초 정도 애플리케이션이 중단되는 문제점이 발생되었다.

 

 추후 프로젝트를 리팩토링하거나 버전을 업그레이드 할 때 마다 애플리케이션이 중단되는 문제점을 해결하기 위해 팀원들과 상의 후 Nginx를 설치하고 Blue/Green 배포 방식으로 무중단 배포를 도입하기로 하였다.

 

 또, 기존에 GitLab 파이프라인 스크립트와 프로젝트 내에 Docker 파일을 두고 빌드를 하였는데, 젠킨스와 GitLab을 연동하여 젠킨스로 Build를 했다. → Build 속도가 훨씬 빨라짐

---

Nginx 란?

 시장에서 점유율이 높은 apache와 같은 웹서버 중 하나로 가벼우면서 여러 요청을 한 번에 처리할 수 있는 장점을 가진다. 또 apache 보다 동작이 단순하고 전달자 역할만 하기 때문에 동시접속에 특화되어 있다.

 

 예를 들어 동시접속자가 700명 이상이라면 서버를 증설하거나, nginx 환경을 권장한다고 할 정도로 성능이 좋고 다중접속에 특화되어있다.

 

 

 nginx의 구동 방식은 Event Driven(비동기처리방식)으로 요청이 들어오면 어떤 동작을 해야하는지만 알려주고 다른 요청을 처리하는 방식이다.

 

 그렇기 때문에 CPU와 관계없이 모든 입/출력들을 전부 Event Listener로 전달해서 흐름이 끊기지 않고 응답이 빠르게 진행되어 1개의 프로세스로 보다 더 빠른 작업이 가능하게 된다.

 

Nginx 역할

HTTP 서버 역할

 웹서버의 역할은 HTML, CSS, JavaScript, 이미지와 같은 정적인 정보를 웹 브라우저(Chrome, Explore, Opera, FireFox 등)에 전송하는 역할을 한다.

 

리버스 프록시(Reverse Proxy) 역할

 서버 앞단에 웹서버를 이용하여 사용자가 바로 서버에 접근하지 않고 앞에 있는 웹서버에 요청을 하도록 하는 역할이다. 사용자의 요청에 따라 리버스 프록시 서버(Nginx)는 서버의 포트나 디렉토리에 연결하여 준다.

 

 이렇게 되면 사용자가 직접하는 요청과 프록시 서버를 거친 요청이 다르기 때문에 직접적으로 노출되지 않는 보안상 이점이 있고, 하나의 요청을 분배하여 여러 형태로 처리하는 분산처리가 가능하게 된다.

 

EC2 서버에 Nginx 설치 ( 프로젝트 서버 - Ubuntu Server 20.04 LTS )

1. apt 업데이트

 Ubuntu에는 기본적으로 apt가 설치되어있기 때문에 사용 전 업데이트 및 업그레이드 하면 된다.

• 패키지 인덱스 정보 업데이트

sudo apt update

• 패키지 업그레이드

sudo apt upgrade

 

Ubuntu APT란?

- APT(Advanced Packaging Tool)
- 데비안과 우분투를 포함하여 데비안(debian) 계열 리눅스 배포판들의 주 패키지 관리 도구
- apt 관리 도구인 apt-get과 apt-cache에서 자주 사용하는 명령어들을 통합하여 보다 사용자 친화적으로 고안된 새 apt 패키지 관리 도구
- 리눅스 시스템에 패키지를 설치하고 제거하는데에 사용

 

📌 apt 사용법 참조 블로그
: http://taewan.kim/tip/apt-apt-get/

Ubuntu 패키지 관리 툴: apt 사용법

2. Nginx 설치

# apt install [패키지명] -> 패키지 설치
sudo apt install nginx

# apt remove nginx [패키지명] -> 패키지 삭제
sudo apt remove nginx

3. Nginx 시작, 종료, 재시작, 상태, 실행 테스트

sudo service nginx start # nginx 시작
sudo service nginx stop # nginx 종료
sudo service nginx restart # nginx 재시작
sudo service nginx status # nginx 상태
sudo nginx -t # 실행 테스트

• Nginx 실행, 종료 화면

Spring Boot  + Nginx 사용하여 무중단 배포

무중단 배포란?

 예전에 배포라고 하면 클라이언트가 서비스를 사용하지 않는 새벽 시간대에 남아 서비스를 정지하고 배포를 진행하였다. 이 때, 치명적인 문제가 발견되면 아침까지 또는 클라이언트가 사용해야하는 시간이라면 긴급점검을 걸고 문제를 해결했어야 했다. 이렇게 되면 롤백조차 어렵기 때문에 배포의 부담이 매우 컸다.

 

 위처럼 서비스를 정지하지 않고 서비스를 배포할 수 있는 방법이 무중단 배포이다.

Blue / Green 무중단 배포

  Rolling 배포, 카나리 배포 등 여러 배포 방식이 있지만 호환성 문제와 자원을 늘리지 않고, EC2 하나만 사용하기 때문에 간단하고 쉽게 무중단 배포를 할 수 있는 방법인 Blue/Green 방식을 채택

 

 블루 그린 무중단 배포에서 블루는 구 버전, 그린은 신버전을 의미한다. 운영중인 구버전과 동일하게 신버전의 인스턴스를 구성한 후 로드밸런서를 통해 모든 트래픽을 한번에 신버전 쪽으로 전환하는 방식을 말한다.

 

장점?

• 구버전의 인스턴스가 그대로 남아있어서 손쉬운 롤백이 가능하다.
• 구버전의 환경을 다음 배포에 재사용할 수 있다.
• 운영환경에 영향을 주지 않고 새 버전 테스트 가능.

단점?

• 시스템 자원이 두배로 필요하다. 
• 새로운 환경에 대한 테스트가 전제되어야 한다.

EC2를 사용한 배포 순서

1. EC2(리눅스 서버)에 Nginx 1대와 스프링부트 jar 2대를 사용한다.
   • Nginx : 80(http), 443(https) 포트 사용,
   • 스프링부트1(9001), 스프링부트2(9002)
2. 사용자는 서비스 주소로 접속한다 (80 또는 443 포트)
3. Nginx는 사용자의 요청을 받아 현재 연결된 스프링부트로 요청을 전달한다.
4. 배포가 필요하면 Nginx와 연결되지 않은 스프링부트로 배포한다.
5. 배포가 끝나고 정상적으로 배포를 한 스프링부트가 구동중인지 확인한다.
6. 5에서 확인한 스프링부트가 정상 구동중이면 nginx reload를 통해 해당 스프링부트의 포트를 nginx가 연결하도록 한다.
7. 만약 배포시 문제가 생겨서 rollback이 필요하면 ngix가 배포전에 연결되었던 스프링부트를 다시 연결하면 된다.
8. 신규 코드 배포가 발생 될 때 마다 JAR 실행 포트가 9001 → 9002 → 9001 → 9002 .. 식으로 스위칭

무중단 배포를 위한 Nginx 설정

1. default 파일 열기

sudo vim /etc/nginx/sites-enabled/default

include /etc/nginx/conf.d/service-url.inc;
proxy_pass $service_url;

아래 위치에 위 두줄을 추가한다.

try-files $uri/ =404; #이 부분은 주석처리하기

 

2. service-url.inc 파일 열기

sudo vim /etc/nginx/conf.d/service-url.inc

위 폴더에 아래의 코드 추가

set $service_url http://127.0.0.1:9001;

nginx가 자동으로 9001 포트에 포워딩할 수 있게 해준다.

기본포트 (80)으로 접속하게 되면 자동으로 9001 포트에 연결됨

 

3. nginx 재시작

sudo service nginx restart