Github Actions + AWS S3 + AWS CodeDeploy + Nginx 를 활용한 블루/그린(Blue/Green) 무중단 배포 - Spring Boot CI/CD

해당 글에서는 세부적인 AWS 설정에 대해 다루지 않습니다. 🫣

구체적인 설정에 대해서는 다음 글들을 참고해주세요!

 

Github Actions, AWS CodeDeploy를 활용한 CI/CD - Node.js(1)

Github Actions, AWS CodeDeploy를 활용한 CI/CD - Node.js(2)

 

 

🧐 블루/그린 배포란?

 

블루/그린 배포란 무중단 배포 방식 중 하나입니다.

무중단 배포란 애플리케이션의 중단 없이 배포를 하는 것을 말하는데, 애플리케이션은 언제 중단될까요?

 

서비스가 업데이트 되어 새롭게 배포를 해야하는 상황을 가정해보겠습니다.

기존 서버를 8080 포트에 배포중이고 새롭게 배포하는 서버 또한 8080 포트에 배포를 하려면 기존에 실행되던 서버를 안전하게 종료한 후에, 새로운 서버를 실행해야 합니다.

이렇게 서버를 새롭게 배포하는 과정에서 서버가 잠깐 내려가게 되는데, 이러한 과정을 중단 배포라고 합니다.

 

중단 배포의 문제를 해결하기 위해 무중단 배포라는 개념이 등장했고 대표적으로 Rolling, Blue/Green, Canary 방식이 존재합니다.

 

Blue/Green 배포란 이전 버전에 있던 사용자 트래픽을 이전 버전과 거의 동일한 새 버전으로 점진적으로 이전하는 배포 방식입니다.

좀 더 구체적으로 이전 버전인 Blue 환경(8081 포트), 새 버전인 Green 환경(8082 포트)이 있다고 해보겠습니다.

또한 모든 요청은 Nginx(80 포트) 로 들어오고 Nginx 는 모든 요청을 Blue 환경에서 처리하도록 하고 있습니다.

이 때, 새로운 서버를 배포하기 위해서는 Green 환경(8082 포트)에 서버를 실행한 후, Nginx 가 모든 요청을 Green 환경에서 처리할 수 있도록 트래픽을 전환해주면 됩니다.

 

서버가 정상적으로 실행된 후에 트래픽을 전달함으로써 서비스가 종료되고 실행되는 것을 기다릴 필요가 없어집니다.

이를 통해 중단 배포를 방지하는 방식이 Blue/Green 배포 방식입니다.

 

(Rolling, Canary 배포 방식에 대한 설명은 해당 게시글에서 다루지 않습니다. 😅)

 

 

💡 전체 흐름

 

이제 Spring Boot를 블루/그린 배포하기 위한 전체적인 흐름에 대해 이해해보겠습니다!

 

1. 먼저 Github Actions를 이용하여 Github Repository에 올린 프로젝트를 빌드합니다.

2. 배포에 필요한 파일들과 빌드가 완료된 프로젝트를 압축하여 AWS S3에 업로드합니다.

3. 이어서 Github Actions를 이용하여 AWS CodeDeploy를 실행합니다.

4. AWS CodeDeploy를 이용하여 AWS S3에 업로드된 압축파일을 AWS EC2 인스턴스로 가져옵니다.

5. AWS EC2에 압축파일을 가져온 후 압축을 해제합니다.

6. 압축을 해제하면 프로젝트 빌드 파일, 배포에 필요한 스크립트들이 존재합니다.

7. AWS CodeDeploy를 이용하여 스크립트들을 순서대로 실행하여 배포합니다.

 

이 때, 블루/그린 배포를 하기 위해 7번 과정에서 3가지 과정을 거칩니다.

 

7-1. Green 환경에 새로운 WAS 를 실행합니다.

7-2. Green 환경에 WAS 가 정상적으로 실행됐는지 Health Check 를 진행합니다.

7-3. Health Check 에 성공했다면, 트래픽을 Green 환경으로 전달합니다.

 

 

🚀 Nginx 설정

 

먼저 사용중인 EC2 인스턴스에 Nginx 를 설치해야합니다.

sudo apt install nginx

 

설치가 완료되면 다음 명령어를 통해 정상적으로 실행되고 있는지 확인해줍니다.

sudo systemctl status nginx

 

다음과 같이 표시되면 정상적으로 동작하는 것입니다. 🤩

 

 

다음으로는 http(80) 로 접속하면 Nginx 에서 요청을 다른 포트로 전달할 수 있도록 아래 설정을 해줍니다.

 

sudo vim /etc/nginx/conf.d/service-url.inc 로 파일 생성

# service-url.inc
# 아래 파일로 nginx가 바라볼 포트를 지정한다.
# 내용은 배포시 마다 실행되는 scripts로 동적으로 변경된다.

set $service_url http://127.0.0.1:8081;

 

sudo vim /etc/nginx/nginx.conf 로 설정 파일 수정

# nginx.conf

http {
    server {
        include /etc/nginx/conf.d/service-url.inc;

        location / {
                # service_url로 요청 전달!
                proxy_pass $service_url;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header Host $http_host;
        }
    }
}

 

다음과 같이 설정을 마쳤다면 Nginx 의 reverse proxy 기능을 사용하여 Blue/Green 배포를 적용할 수 있게 됩니다.

nginx.conf 파일은 Nginx 의 설정 파일인데 proxy_pass 값을 설정해서 80 포트로 들어온 요청을 $service_url 로 넘겨줄 수 있게 됩니다.

현재 $service_url 을 127.0.0.1:8081 로 설정한 상태이고, 이 값은 동적으로 8081과 8082 포트로 설정됩니다.

$service_url 값이 바뀔 때 Nginx 를 reload 하여 트래픽을 전환하는 방식입니다.

 

 

🚀 Health Check 용 API 추가

 

Nginx 설정을 마쳤으면 새로운 서버가 정상적으로 실행됐는지 확인할 때 사용할 API 를 추가합니다.

 

다음 API 는 CodeDeploy 가 실행할 스크립트에서 사용됩니다.

 

@RestController
public class HealthController {

		@GetMapping("/health")
		public String checkHealth() {
				return "healthy";
		}
}

 

 

🚀 스크립트 작성

 

이제 Blue/Green 배포를 위한 스크립트들을 작성해보겠습니다.

먼저 새로운 버전의 서버를 실행하는 스크립트를 작성합니다.

 

scripts/run_new_was.sh

CURRENT_PORT=$(cat /etc/nginx/conf.d/service-url.inc | grep -Po '[0-9]+' | tail -1)
TARGET_PORT=0

if [ ${CURRENT_PORT} -eq 8081 ]; then
  TARGET_PORT=8082
elif [ ${CURRENT_PORT} -eq 8082 ]; then
  TARGET_PORT=8081
else
  echo "[$NOW_TIME] No WAS is connected to nginx"
fi

TARGET_PID=$(lsof -Fp -i TCP:${TARGET_PORT} | grep -Po 'p[0-9]+' | grep -Po '[0-9]+')

if [ ! -z ${TARGET_PID} ]; then
  echo "Kill WAS running at ${TARGET_PORT}."
  sudo kill ${TARGET_PID}
fi

nohup java -jar -Dserver.port=${TARGET_PORT} /home/ubuntu/application/*.jar
echo "Now new WAS runs at ${TARGET_PORT}."

exit 0

 

• CURRENT_PORT : 현재 Nginx 가 바라보고 있는 포트 번호를 service-url.inc 파일에서 읽어옵니다.

• TARGET_PORT : 새로운 서버를 배포할 포트를 현재 Nginx 가 바라보고 있지 않은 포트로 설정합니다.

• TARGET_PID : 새로운 서버를 배포할 포트에서 현재 실행중인 프로세스 아이디입니다. 새로운 서버를 배포하기 위해 기존에 실행중인 프로세스가 있다면 종료합니다.

• 기존에 실행중인 서버를 종료한 뒤 새로운 서버를 TARGET_PORT 에 실행합니다.

 

다음으로는 새롭게 실행한 서버가 정상적으로 실행됐는지를 확인하기 위한 스크립트를 작성합니다.

앞서 작성했던 Health Check 용 API 를 활용합니다.

 

scripts/health_check.sh

CURRENT_PORT=$(cat /etc/nginx/conf.d/service-url.inc | grep -Po '[0-9]+' | tail -1)
TARGET_PORT=0

if [ ${CURRENT_PORT} -eq 8081 ]; then
  TARGET_PORT=8082
elif [ ${CURRENT_PORT} -eq 8082 ]; then
  TARGET_PORT=8081
else
  echo "No WAS is connected to nginx"
  exit 1
fi

echo "Start health check of WAS at 'http://127.0.0.1:${TARGET_PORT}' ..."

for RETRY_COUNT in 1 2 3 4 5 6 7 8 9 10
do
  echo "#${RETRY_COUNT} trying..."
  RESPONSE_CODE=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:${TARGET_PORT}/health)

  if [ ${RESPONSE_CODE} -eq 200 ]; then
    echo "New WAS successfully running"
    exit 0
  elif [ ${RETRY_COUNT} -eq 10 ]; then
    echo "Health check failed."
    exit 1
  fi
  sleep 10
done

 

• RETRY_COUNT : 10초 간격으로 총 10번 서버가 정상적으로 실행됐는지 Health Check 를 시도합니다.

• RESPONSE_CODE : 앞서 작성했던 Health Check 용 API (http://127.0.0.1:${TARGET_PORT}/health) 를 호출합니다. 200 성공 응답을 받은 경우, 서버가 정상적으로 실행됐다는 것을 의미합니다. (exit 0)

• 10번 모두 Health Check 에 실패할 경우 서버가 정상적으로 실행되지 않은 것으로 간주하여 스크립트는 실패합니다. (exit 1)

 

새로운 버전의 서버가 정상적으로 실행됐다는 것을 확인하면 (Health Check 성공)

이제 Nginx 가 바라보고 있는 포트를 새로운 버전이 실행된 포트로 전환해주기만 하면 끝입니다.

 

scripts/switch.sh

CURRENT_PORT=$(cat /etc/nginx/conf.d/service-url.inc | grep -Po '[0-9]+' | tail -1)
TARGET_PORT=0

echo "Nginx currently proxies to ${CURRENT_PORT}."

if [ ${CURRENT_PORT} -eq 8081 ]; then
  TARGET_PORT=8082
elif [ ${CURRENT_PORT} -eq 8082 ]; then
  TARGET_PORT=8081
else
  echo "No WAS is connected to nginx"
  exit 1
fi

echo "set \$service_url http://127.0.0.1:${TARGET_PORT};" | sudo tee /etc/nginx/conf.d/service-url.inc

echo "Now Nginx proxies to ${TARGET_PORT}."
sudo service nginx reload

echo "Nginx reloaded."

 

• 현재 Nginx 가 바라보고 있는 포트를 설정하는 파일인 /etc/nginx/conf.d/service-url.inc 파일을 TARGET_PORT 로 수정합니다.

• sudo service nginx reload : reload 명령어를 사용하여 Nginx 가 설정 파일만 다시 불러오도록 합니다. restart 명령어는 서버를 내렸다가 재실행하는 반면, reload 명령어는 설정만 불러오기 때문에 더 빠르게 동작합니다.

 

 

🚀 appspec.yml 작성

 

appspec.yml 파일은 AWS CodeDeploy 에서 배포를 관리할 때 사용하는 파일입니다.

위에서 작성한 3가지 스크립트를 순서대로 실행할 수 있도록 다음과 같이 작성합니다.

 

appspec.yml

version: 0.0
os: linux
files:
  - source: /
    destination: /home/ubuntu/application
    overwrite: yes

permissions:
  - object: /home/ubuntu
    pattern: "**"
    owner: ubuntu
    group: ubuntu

hooks:
  ApplicationStart:
    - location: run_new_was.sh
      timeout: 180
      runas: ubuntu
    - location: health_check.sh
      timeout: 180
      runas: ubuntu
    - location: switch.sh
      timeout: 180
      runas: ubuntu

 

• 작성한 순서대로 스크립트가 실행됩니다.

• 스크립트가 성공한 경우에만 다음 스크립트가 실행되고 실패할 경우 배포는 실패합니다.

 

 

🚀 Github Actions 워크플로우 작성

 

정말 마지막입니다!! 😆

Github Actions 워크플로우를 작성해서 특정 이벤트가 발생했을 때 jobs 가 실행되도록 작성합니다.

 

.github/workflows/deploy.yml

name: deploy

on:
  push:
    branches: [ develop ]

env:
  AWS_S3_BUCKET: ${{ secrets.AWS_S3_BUCKET }}

jobs:
  build:
    runs-on: ubuntu-20.04

    steps:
      - name: Checkout
        uses: actions/checkout@v3

      - name: create secret files
        working-directory: src/main/resources
        run: |
          touch application.yml
          echo "${{ secrets.APPLICATION_YML }}" >> application.yml

      - name: Set up JDK 11
        uses: actions/setup-java@v3
        with:
          distribution: 'corretto'
          java-version: '11'

      - name: Grant execute permission for gradlew
        run: chmod +x gradlew
        shell: bash

      - name: Build with Gradle
        run: ./gradlew build -x test
        shell: bash

      - name: Make zip file
        run: zip -r ./code-deploy.zip ./build/libs/*.jar ./scripts/* -j ./appspec.yml
        shell: bash

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v1
        with:
          aws-access-key-id: ${{ secrets.AWS_ACCESS_KEY }}
          aws-secret-access-key: ${{ secrets.AWS_SECRET_KEY }}
          aws-region: ${{ secrets.AWS_REGION }}

      - name: Upload to S3
        run: aws s3 cp --region ap-northeast-2 ./code-deploy.zip s3://$AWS_S3_BUCKET/code-deploy.zip

      - name: Code Deploy
        run: aws deploy create-deployment
          --application-name codedeploy-application
          --deployment-config-name CodeDeployDefault.OneAtATime
          --deployment-group-name GROUP
          --s3-location bucket=$AWS_S3_BUCKET,bundleType=zip,key=code-deploy.zip

 

• on.push.branches : 특정 브랜치에 push 가 발생했을 때 해당 워크플로우가 동작합니다. 위와 같은 경우에는 develop 브랜치에 push 가 발생하면 워크플로우가 실행됩니다.

• Make zip file job : S3 에 업로드 해야할 파일들을 code-deploy.zip 이라는 파일로 압축하는 과정입니다. 서버를 실행하기 위해 필요한 빌드된 프로젝트 파일(./build/libs/*.jar), Code Deploy Agent 가 실행할 스크립트 파일(./scripts/* -j), Code Deploy Agent 의 배포 관리 파일(./appspec.yml)을 압축합니다.

• Upload to S3 job : 압축한 code-deploy.zip 파일을 S3 에 업로드합니다.

• Code Deploy job : Code Deploy Agent 를 실행합니다. S3 에 업로드된 code-deploy.zip 파일을 EC2 로 가져와서 압축을 해제하고 appspec.yml 파일을 참고하여 순서대로 스크립트를 실행합니다.

 

 

🤩 결과 확인

 

 

Current port of running WAS is 8082.
Kill WAS running at 8081.
Now new WAS runs at 8081.
Start health check of WAS at 'http://127.0.0.1:8081' ...
#1 trying...
#2 trying...
#3 trying...
New WAS successfully running
Nginx currently proxies to 8082.
Now Nginx proxies to 8081.
Nginx reloaded.

 

Github Actions 와 AWS CodeDeploy 가 성공하면 새로운 서버가 배포된 후에 Nginx 가 reload 되어 트래픽을 전환하는 것을 확인할 수 있습니다.

 

$ ps -ef | grep java

ubuntu  5516  1 10 16:23 ?  00:00:21 java -jar -Dserver.port=8082 /home/ubuntu/application/application.jar
ubuntu  5692  1 26 16:25 ?  00:00:22 java -jar -Dserver.port=8081 /home/ubuntu/application/application.jar

 

Blue/Green 배포 전략을 사용했기 때문에 위와 같이 신버전과 구버전의 서버가 실행되는 상태가 유지됩니다.

신버전의 포트를 확인하기 위해서는 현재 Nginx 가 바라보고 있는 포트를 service-url.inc 파일에서 확인하면 됩니다.

 

신버전과 구버전이 실행중이기 때문에 얻을 수 있는 이점이 있습니다.

Blue/Green 배포 전략의 대표적인 장점이라고도 할 수 있는데, 만약 새롭게 배포한 서버에서 문제가 발생한다면 빠르게 service-url.inc 파일에서 포트만 수정한 후 Nginx 를 reload 하여 다시 구버전의 서버를 사용하도록 할 수 있습니다.