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 배포를 위해서 두 개의 운영 환경을 유지해야 하므로 인프라 비용이 두 배로 들 가능성이 있다. 스타트업이나 소규모 프로젝트에서는 유지 비용이 부담이 될 수 있다.

 

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

'DevOps > CICD' 카테고리의 다른 글

[GitLab] 내장 CI/CD 사용방법  (1) 2025.02.01
[GitLab] 깃허브와 다른점이 뭘까?  (0) 2025.02.01

CI/CD ?

  • CI : Continous Integration (지속적 통합)
  • CD : Continuous Deployment/Delivery (지속적 배포)

개발자가 코드를 더 빠르고 안정적으로 빌드, 테스트, 배포할 수 있도록 도와주는 소프트웨어 개발 프로세스 자동화 기법을 말한다. 개발자가 코드를 Push(서버에 올리면) 자동적으로 해당 코드를 빌드하고 테스트 해주는 과정을 일컫는다.

 

또한, 작은 코드의 변경 사항을 주기적으로 통합해서, 버그를 초기에 미리 잡고 품질을 유지하는 것을 목표로 한다. 다른 개발자의 코드와 나의 코드가 원활히 병합되는 것을 지켜보고, 만약 실패한다면 개발자에게 알림을 보내는 것이다.

 

이때 CD 의 개념이 두가지로 나뉘는데,

 

첫번째, Continuous Delivery 로서는

코드가 안정적으로 지속적이게 배포되는 것을 Pipeline 자동화라고 하는데, CI 이후에 배포 준비까지 완료를 하지만, 운영 서버의 경우 개발자의 승인(Approve)해야 프로덕션 배포가 진행된다.

 

두번째, Continous Deployment 로서는

CI/CD 의 완전 자동화 버전이라고 하는데, 모든 변경 사항이 자동으로 프로덕션(운영 서버에) 배포되는 것을 말한다. 개발자의 별도 승인 과정 없이 코드가 Push 되자마자 배포까지 자동적으로 일어난다. 다만, 이 경우 서버에 올린 코드의 테스트가 잘 되었어야 할 것이다.

 

즉, 코드를 빠르고 안전하게 빌드, 테스트, 배포하는 자동화 프로세스를 위해서 만들어진 개념이다.

CI/CD 파이프라인으로 GitHub Actions, GitLab CI/CD, Jenkins 등이 존재한다.


다음으로 구성 요소에 대해서 알아보자.

GitLab Runner

GitLab CI/CD 파이프라인을 실행하는 프로그램이다. GitLab 의 경우 직접 CI/CD 를 실행시키지 않고, GitLab Runner 가 독립적으로 작업을 수행한다.

 

GitLab 은 '.gitlab-ci.yml' 파일을 올려놓으면, 해당 스크립트를 실행해서 CI/CD 파이프라인을 실행하는데, 이 설정 파일을 실행하는 역할을 하는 것이 바로 GitLab Runner 이다.

 

GitLab 에는 Runner 가 기본적으로 내장되어 제공되지만, 자체 서버에 GitLab Runner 를 설치하여 운영할 수도 있다. 그 설치 방법은 다음과 같다.

// Bash

// GitLab Runner 설치
curl -L https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh | sudo bash
sudo apt install gitlab-runner

// GitLab Runner 등록
sudo gitlab-runner register

// GitLab Runner 실행
sudo gitlab-runner start

 

Pipeline

Git 저장소에 Push 될 때(코드가 변경되었을 때) 자동으로 실행되는 자동화 프로세스, 즉 작업 흐름을 말한다.

 

코드가 Push 되거나 Merge Request(MR)가 발생하면 실행된다. 하나의 파이프라인은 여러 개의 스테이지들(Stages)과 작업들(Jobs)로 이루어진다.

 

Stage

파이프라인의 작업 단계를 의미한다.

일반적으로 build(빌드) - test(테스트) - deploy(배포) 의 단계로 순차적으로 실행된다.

이전 스테이지가 성공해야 다음 스테이가 실행된다.

 

Job

특정 스테이지에서 실행되는 개별 작업을 의미한다.

각 작업들은 특정 스크립트를 실행하고 결과를 반환한다.

잡들은 같은 스테이지 내에서 병렬적으로 수행된다.

 

예시

stages:
  - build
  - test
  - deploy

build-job:
  stage: build
  script:
    - echo "🔨 빌드 실행 중..."
    - mvn package

test-job:
  stage: test
  script:
    - echo "🛠️ 테스트 실행 중..."
    - mvn test

deploy-job:
  stage: deploy
  script:
    - echo "🚀 배포 중..."

 

이제 본격적으로 어떻게 GitLab 에서 CI/CD 를 구현할 수 있을지 단계적으로 알아보자.

 

GitLab Runner 등록 (gitlab-runner register)

1. GitLab Instance URL 입력

이는 깃랩이 어디에서 운영되고 있느냐에 따른 서버 주소를 지정해주는 것이다.

 

GitLab 공식 사이트를 사용할 경우는 https://gitlab.com 을 작성해주면 되고,

기업/조직에서 자체적인 서버에서 호스팅할 경우에는 해당 도메인을 작성해주면 된다.

 

즉, GitLab 이 실행되고 있는 서버의 URL 을 입력하면 된다.

 

2. 등록 토큰(Registration Token) 부여

이는 GitLab Runner 가 특정 GitLab 프로젝트 또는 그룹에 등록되려면 필요한 인증 정보같은 개념이다. 해당 토큰이 등록되어야 Runner 가 특정 프로젝트에 연결될 수 있다.

 

.gitlab-ci.yml 파일 추가

이 파일이 가장 핵심적이라고 할 수 있다. 이 설정 파일에 작성된 대로 파이프라인이 실행되기 때문이다.

 

다음과 같이 브랜치를 분리하여, 개발/운영 서버가 다른 브랜치에서 실행하도록 설정할 수도 있다.

 

다음 코드는

build 작업은 main 브랜치에서 운영 서버 1 - aws(Runner) 에서만,

deploy 작업은 main 브랜치에서 운영 서버 2 - 특정 서버(Runner) 에서만,

test 작업은 dev 브랜치에서 개발 서버 - 특정 서(Runner) 에서만 실행되도록 설정한 코드이다.

stages:
  - build
  - deploy

build-job:
  stage: build
  script:
    - echo "빌드 실행 중..."
  only:
    - main
  tags:
    - aws  # 운영 서버에서 실행

deploy-job:
  stage: deploy
  script:
    - echo "AWS 운영 서버에 배포 중..."
  only:
    - main
  tags:
    - production  # 운영 서버에서 실행

test-job:
  stage: test
  script:
    - echo "개발 서버에서 테스트 실행 중..."
  only:
    - dev
  tags:
    - dev  # 개발 서버에서 실행

 

 

실행 로그 확인

생각보다 단순하쥬?

'DevOps > CICD' 카테고리의 다른 글

[GitLab CI/CD] Blue-Green 배포 방식  (0) 2025.03.10
[GitLab] 깃허브와 다른점이 뭘까?  (0) 2025.02.01

GitHub, 전 세계적으로 인기있는 소스 코드 VCS

VCS는 Version Control System; 버전 관리 시스템을 말한다.

전 세계 대부분의 개발자들이 이 저장소를 가지고 있고, 협업 시에 활용하곤 한다.

Fork 와 FullRequest 가 주된 협업 방식으로 보여지는 플랫폼이다.

 

그렇다면 GitLab은 뭘까?

보안 이슈, 클라우드보다는 온-프레미스로 관리하고 싶어.

GitLab 은 특히 기업에서 많이 쓰인다. GitHub 에 비해 폐쇄적인 느낌이 있다.

 

GitHub 는 중앙 저장소를 두고, 클라우드 기반으로 운영된다. 그러나 기업이나 정부 기관의 경우는 공개된 클라우드에 회사의 자산을 함부로 저장하기에는 망설여지는 부분이 많았을 것이다. 이러한 요구에 맞춰서 나타난게 GitLab 이다. GitLab 은 회사가 소유한 서버에 저장소를 운영할 수 있다. 

자체적인 CI/CD 제공

GitLab 은 CI/CD 가 내장되어 있다. GitHub 의 경우에도 GitHub Actions 가 존재하지만, 따로 설정이 필요하다. 그러나 GitLab 은 애초에 처음부터 CI/CD 가 가능한 것이다. 마치 SpringBoot 에 톰캣 서버가 내장되어 있는 느낌인가..

 

버전관리 + CI/CD + 셀프 호스팅이 가능한 엔터프라이즈 DevOps 플랫폼

GitHub 가 버전관리와 오픈소스 협업에 있어서 정체성을 가지고 있다면,

GitLab 은 좀더 기업적이고 보안적인 관점이 크다.

'DevOps > CICD' 카테고리의 다른 글

[GitLab CI/CD] Blue-Green 배포 방식  (0) 2025.03.10
[GitLab] 내장 CI/CD 사용방법  (1) 2025.02.01

+ Recent posts