[GitLab CI/CD] Blue-Green 배포 방식

Blue-Green 배포가 필요한 이유 : 무중단 배포(Zero Downtime Deployment)

무중단 배포란, 서비스를 사용하는 사용자가, 서비스의 새로운 버전으로 교체되는 와중에도 서비스의 중단을 경험하지 않는 것을 말한다. 새로운 기능을 배포할 때마다 기존 사용자 경험을 해치게 된다면 사용자의 서비스에 대한 신뢰도도 떨어지고 자꾸만 끊기는 서비스 가용성에 불편함을 느낄 것이다. 그러니까 우리의 목표는, 서비스의 구동이 끊기지 않으면서 안정적으로 서비스를 전환하는 것이다.

 

왜 Blue-Green 일까?

먼저 블루, 그린이란 각각 두 개의 운영 환경을 말한다. 그렇다. 블루와 그린 둘다 운영 환경이다. 다만 중요한 것은 두 환경은 정확히 동일하다는 것이다.

 

완벽히 동일한 환경이 일란성 쌍둥이처럼 두 개로 나뉘어져 있다고 이해하면 된다.

• Blue (현재 운영 중인 버전 ex.v1 배포전 기존 환경) : 현재 사용자가 접근하고 있는 환경
• Green (새로운 배포 버전 ex. v2) : 새로운 버전을 배포하고 테스트할 수 있는 환경

 

배포 과정에 대하여

1. 새로운 버전을 Green 환경에 배포한다. (현재 Blue 환경이 운영중이다.)
2. Green  환경에서 새로운 버전을 배포 후 , 충분히 테스트 해본다.
3. 테스트가 실패하면 롤백한다. Green 을 이전 버전으로 돌린다. (다운타임없이 빠른 롤백 가능)
4. 테스트가 성공하면 트래픽을 Blue 환경에서 Green 환경으로 전환한다.

 

GitLab 에서 무중단 배포를 실현하는 방법.

 

1. 먼저 Nginx 를 이용한 Reverse Proxy 서버가 필요하다.

upstream backend {
    server backend-v1:8083 backup;
    server backend-v2:8084;
}

upstream frontend {
    server frontend-v1:3000 backup;
    server frontend-v2:3001;
}

server {
    location /api/ {
        proxy_pass http://backend;
    }
    location / {
        proxy_pass http://frontend;
    }
}

 

참고로 예시로 든 환경은, 백엔드 서버와 프론트 서버가 각각 두개씩 구동중인 서비스이다.

 

 

2.GitLab CI/CD 파이프라인 설정

stages:
  - build
  - deploy-blue
  - deploy-green
  - switch-traffic

# 애플리케이션 빌드
build:
  stage: build
  script:
    - echo "Building application..."
    - ./gradlew build  # Spring Boot 빌드 예제
    - npm run build    # React 빌드 예제
  artifacts:
    paths:
      - build/

# Green 환경에 배포
deploy-green:
  stage: deploy-green
  script:
    - echo "Deploying to Green environment..."
    - ./deploy_backend.sh --green
    - ./deploy_frontend.sh --green
  only:
    - main

# 테스트 단계 (선택 사항)
test-green:
  stage: test
  script:
    - echo "Running tests in Green environment..."
    - ./run_tests.sh
  only:
    - main

# 트래픽 전환
switch-traffic:
  stage: switch-traffic
  script:
    - echo "Switching traffic from Blue to Green..."
    - ./switch_traffic.sh --green  # Nginx 설정 변경
  only:
    - main

 

Nginx 리버스 프록시를 설정한 후, GitLab CI/CD를 활용하여 Blue-Green 배포를 자동화할 수 있다.
GitLab에서는 .gitlab-ci.yml을 이용하여 여러 개의 스테이지를 정의하고, 배포 프로세스를 구성할 수 있다.

 

3. Nginx 에서 트래픽 전환 방법.

#!/bin/bash
echo "Switching traffic to Green..."

# 기존 Nginx 설정 백업
cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

# Nginx 설정 변경 (Green 환경으로 트래픽 전환)
sed -i 's/backend-v1:8083 backup/backend-v1:8083;/' /etc/nginx/nginx.conf
sed -i 's/backend-v2:8084;/backend-v2:8084 backup;/' /etc/nginx/nginx.conf

# Nginx 재시작
nginx -s reload

echo "Traffic successfully switched to Green!"

 

sed -i 는 텍스트 파일을 직접 수정하는 리눅스 명령어이다.

sed -i 를 사용하면 Nginx 설정 파일(nginx.conf) 에서 특정 내용을 자동으로 변경할 수 있다.

s/찾을문자열/바꿀문자열/ 패턴을 사용하여 특정 내용을 변경한다.

 

Blue-Green 배포를 적용해야 하는 이유.

무중단 배포(Zero Downtime Deployment) 실현 → 사용자가 서비스 중단을 경험하지 않는다
빠른 롤백 가능 → 문제가 생기면 즉시 이전 버전(Blue)으로 되돌릴 수 있다.
실제 운영 환경에서 미리 테스트 가능 → Green 환경에서 충분히 테스트 후 트래픽을 전환할 수 있다.
부하 분산 및 확장 가능 → 여러 개의 인스턴스를 운영하며 부하를 나눌 수 있다.

 

 

그렇다고 무중단 배포가 무조건 정답은 아니다.

무중단 배포는 인프라의 복잡성을 증가시킬 수 있다. 예를 들어, 로드 밸런서, Nginx 리버스 프록시, 배포 자동화 도구 등의 설정이 필요하다. 이러한 인프라가 없거나, 배포 다운타임이 길지 않은 경우, 무중단 배포를 도입하는 것이 오히려 복잡한 문제가 될 수 있다.

 

서버 비용도 증가한다. Blue-Green 배포를 위해서 두 개의 운영 환경을 유지해야 하므로 인프라 비용이 두 배로 들 가능성이 있다. 스타트업이나 소규모 프로젝트에서는 유지 비용이 부담이 될 수 있다.

 

마지막으로 실은, 완벽한 무중단 배포는 거의 불가능하다. 프론트, 백, 디비까지 모두 신경써야하고 구버전 환경으로 롤백될 수 있는 가능성까지 전부 고려한 예외처리도 필요하기 때문이다.