GW LB 를 이용한 무중단 배포(업데이트)

목표

게이트웨이(GW) 와 로드밸런서(LB)를 활용하여 무중단 배포(업데이트)를 실습한다.

과정

초기 구성 변경

nginx-proxy 직접 배포 실습에서 뒷 단의 서버를 한 대에서 두 대로 늘린 후 해당 실습을 진행한다.

1. nginx 설정 파일 변경
2. upstream blog\_servs{ server awsgoo-blog-1:80; server awsgoo-blog-2:80; # 이 부분 추가 }
3. 도커 컴포즈 파일 변경
4. deploy: mode: replicated replicas: 2 # 1에서 2로 변경
5. 현재 아키텍처 구성

$ docker container ls
CONTAINER ID   IMAGE                COMMAND                   CREATED             STATUS             PORTS                               NAMES
fa9b34c12f1a   awsgoo-nginx-proxy   "/docker-entrypoint.…"   About an hour ago   Up About an hour   0.0.0.0:9889->80/tcp                awsgoo-nginx-proxy-1
c03d226201dc   awsgoo-blog          "/bin/sh -c 'service…"   About an hour ago   Up About an hour   80/tcp                              awsgoo-blog-2
9c24e7a99198   awsgoo-blog          "/bin/sh -c 'service…"   About an hour ago   Up About an hour   80/tcp                              awsgoo-blog-1

Rolling Deploy 배포

1. blog 서버의 새로운 버전을 위한 작업

기존 httpd 디렉토리를 복사하여 새로운 httpd2 를 만든다.

$ls #httpd2
blog-pull-cronjob Dockerfile        httpd.conf        pull.sh

# RUN ["git", "clone", "https://github.com/dMario24/dMario24.github.io.git", "/usr/local/apache2/app/blog"]
RUN ["git", "clone", "https://github.com/khw7385/khw7385.github.io.git", "/usr/local/apache2/app/blog"] # 새로운 블로그 작성

2. 새로운 blog 버전에 대한 도커 이미지 생성

$ docker build -t awsgoo-blog:20251015.1 .

3. 기존 서버(컨테이너)인 awsgoo-blog2를 중단하고 새로운 이미지로 컨테이너를 띄운다.

$ docker container stop awsgoo-blog-2
$ docker container rm awsgoo-blog-2
$ docker container run -d -p :80 --name awsgoo-blog-2 awsgoo-blog:20251015.1

$ docker container stop awsgoo-blog-1
$ docker container rm awsgoo-blog-1
$ docker container run -d -p :80 --name awsgoo-blog-1 awsgoo-blog:20251015.1

영상 자료는 아래 URL를 통해 확인할 수 있다.
[https://github.com/khw7385/lgcns-msa/pull/8](GW LB 를 이용한 무중단 배포(업데이트) 실습)

blue green 배포

1. 새로운 도커 컨테이너를 미리 생성
2. $ docker container run -d -p :80 --network awsgoo\_default --name new-awsgoo-blog-1 awsgoo-blog:20251015.1 $ d ocker container run -d -p :80 --network awsgoo\_default --name new-awsgoo-blog-2 awsgoo-blog:20251015.1
3. 기존 컨테이너를 중단 및 삭제 후 새로운 컨테이너를 기준 컨테이너로 이름 변경

<방식 1>

$ docker stop awsgoo-blog-1
$ docker rm awsgoo-blog-1
$ docker rename new-awsgoo-blog-1 awsgoo-blog-1

$ docker stop awsgoo-blog-2
$ docker rm awsgoo-blog-2
$ docker rename new-awsgoo-blog-2 awsgoo-blog-2

처음에 기존 컨테이너를 지우고 이름을 변경하는 식으로 진행을 했다. 하지만, 이 방식은 이름을 바꾸는 동안 두 버전의 어플리케이션이 동작할 수 밖에 없어 blue/green 무중단 배포 방식이 아니라고 생각을 하기 때문에 다른 방식이 필요하다.

<방식 2>
새로운 컨테이너를 띄우고 네트워크까지 연결하는 것까지 오케이!!

nginx 컨테이너에 진입하여 설정 파일(default.conf) 를 바꿔준다.

upstream blog_servs{
        # server awsgoo-blog-1:80; 기존
        # server awsgoo-blog-2:80; 기존
    server new-blog-1:80; # 새로운 서버
    server new-blog-2:80; # 새로운 서버
}

reload 명령을 통해 바뀐 설정을 반영한다.

$ nginx -s reload

카나리 배포

따로 카나리 배포를 진행하지 않지만 카나리 방식은 새 버전의 서버로 가는 트래픽의 양을 점차 늘리는 방식이다.

nginx 에서는 부하 분산(weight) 을 통해 카나리 배포를 구현할 수 있다.

결론

각 배포 방식은 장단점이 존재한다.

1.  Rolling Update: 기존 서버를 하나씩 교체하면서 새 버전을 배포하는 방식이다.

장점:

• 구현이 간단하고 자동화가 쉬움
• 리소스 효율적임

단점:

• 구버전과 새버전이 공존하는 시간이 존재한다. -> DB 스키마 불일치 시 문제 발생
• 배포 중 에러 발생 시 롤백 시간이 다소 길다. (하나씩 교체 중이기 때문이다.)

2.  Blue-Green 방식: 두 개의 완전한 환경을 준비하고 트래픽을 한 번에 전환하는 방식이다. 미리 서버를 띄워두고 전환 시점에 nginx, lb 를 라우팅을 변경한다.
   Blue: 기존 버전
   Green: 새 버전

장점:

• 즉시 롤백 가능(Blue 로 전환을 하면 된다.)
• 새 버전을 실제 트래픽 전환 전 미리 테스트 가능
• 완전한 무중단 배포 구현 가능

단점:

• 인프라 비용 증가
• 환경 동기화 어려움: 블루와 그린 환경이 동일해야 한다.

3.  카나리 배포: 트래픽의 일부를 새 버전으로 점진적으로 업데이트를 배포 방식이다.

장점:

• 새 버전의 안정성 검사, 문제가 생기면 일부 사용자에게만 발생
  단점:
• 구성과 관리 복잡: 트래픽 라우팅 설정 + 모니터링 체계 필요
• 모니터링 데이터 해석: 새 버전으로 가는 트래픽 시점과 양을 결정할 수 있어야 한다.