[Infra] Blue-Green 해야할까..?

한강섭·2025년 9월 21일

msa 배포 인프라 전략 캠퍼스페이

쏠쏠해영 프로젝트

목록 보기

5/8

우리 프로젝트에서 최종적으로 결정하고 구성한 아키텍처이다. 지금부터 이 아키텍처를 배포할 때 어떤 전략을 통해서 배포하였는지 그렇기에 어떤 점을 고려했는 지 정리해보자 한다.

아키텍처에 맞게 띄워진 DOCKER이다. 하나의 EC2안에 전부 띄웠기 때문에 이렇게 구성된 것을 확인할 수 있다.

배포 전략

서비스별 독립 컨테이너 활용

solsol-shop/
├── Dockerfile
├── app.jar
├── .env
└── docker-compose.yml

각 마이크로서비스가 독립적인 컨테이너로 패키징되어 개별 배포가 가능하다.

GitLAb CI/CD 기반 자동화 배포

# 브랜치별 자동 배포 트리거
rules:
  - if: '$CI_COMMIT_BRANCH == "back/stock/main"'  # 재고 서비스
  - if: '$CI_COMMIT_BRANCH == "back/pay/main"'    # 결제 서비스  
  - if: '$CI_COMMIT_BRANCH == "back/shop/main"'   # 쇼핑 서비스
  - if: '$CI_COMMIT_BRANCH == "back/orchestrator/main"'  # 오케스트레이터

단일 스테이지 전략

stages:
	- deploy #  build + deploy를 한 Job에서 처리

Gradle 기반 Spring Boot 빌드

image: gradle:8.9.0-jdk21   # Java 21 + Gradle 8.9
script:
  - cd $SERVICE_DIR
  - chmod +x gradlew
  - ./gradlew clean bootJar --no-daemon  # 데몬 없이 깨끗한 빌드
  - cp build/libs/*.jar $APP_JAR         # 표준화된 JAR 이름

--no-daemon: 으로 CI 환경에서 메모리 효율성
clean bootJar: 의존성 충돌 방지
모든 서비스에서 app.jar로 통일

무중단 배포 전략

Docker Compose 기반 Rolling Update

# 서버에서 실행되는 배포 명령
ssh ${EC2_USER}@$EC2_HOST "
  cd /home/${EC2_USER}/solsol-stock &&
  docker compose build app &&                    # 새 이미지 빌드
  docker compose up -d --no-deps --force-recreate app  # 무중단 교체
"

Git Push -> GitLab CI 트리거가 발동 -> Gradle 빌드 -> JAR 생성 -> SCP 업로드 -> Docker 이미지 빌드 -> 컨테이너 교체 -> 헬스체크

--no-deps : 의존 서비스 영향 없음
--force-recreate : 새 컨테이너로 완전 교체
Docker 네트워크 : 기존 연결 유지

배포 워크플로우

1단계 코드 커밋 & 푸시

git push origin back/stock/main

2단계 자동 빌드 & 테스트

script:
	- cd $SERVICE_DIR
    - chmod +x gradlew
    - ./gradlew clean bootJar --no-daemon
    - cp build/libs/*.jar $APP+JAR

3단계 보안 업로드

scp -o StrictHostKeyChecking=no $APP_JAR ubuntu@j13a106.p.ssafy.io:/home/ubuntu/solsol-stock/app.jar

4단계 무중단 배포

ssh ubuntu@j13a106.p.ssafy.io "
  cd /home/ubuntu/solsol-stock &&
  docker compose build app &&
  docker compose up -d --no-deps --force-recreate app
"

5단계 자동 검증

# 배포 후 자동 헬스체크
curl -f http://j13a106.p.ssafy.io/api/stock/actuator/health

Rolling Update vs Blue-Green

사실 Rolling Update 가 무중단이라고 하였지만 완전한 무중단은 아니다.

완전한 무중단 배포인 Blue-Green 방식에 대해서 소개하고 오해가 생김을 막고자 한다.

Rolling Update는 그냥 동일한 포트에서 돌아가고 있던 컨테이너를 SIGTERM 신호를 통해 중지하고, 새 컨테이너를 즉시 시작한다.
그렇기에 다운타임이 약 2~3초 정도 생긴다. (컨테이너 교체시간)

하지만 Blue-Green 방식은 Blue(현재) 환경이 존재하는 채로 Green(새로운) 환경을 새로 배포한 후 Nignx 설정 변경으로 트래픽을 전환한다.
이렇게 전환하기에 다운타임이 0초 완전 무중단을 할 수 있다. 하지만 메모리, CPU, 포트 모두 2배가 필요하다.