💧

무중단 배포 with jenkins

생성일

2022/11/04

태그

infra

linux

jenkins

목차

배경

모락 서비스를 배포한 이후, 사용자의 피드백과 추가 기능들을 함께 반영하며 운영 서버로 자주 배포하게 되었습니다. 이 과정에서 기존 버전의 운영 서버를 종료시키고, 새로운 버전의 운영 서버를 실행시키며 약 20초 정도의 다운타임이 발생하게 되었습니다. 이 20초 간의 다운타임도 문제였지만, 개발 서버에서 미처 알아차리지 못한 에러가 발생할 때도 문제가 있었습니다. 저희 프로젝트에서 배포하는 방식은 기존 버전의 jar 파일을 새로운 버전의 jar 파일로 오버라이드하고 새로운 버전의 jar 파일을 실행하는 방식이었습니다. 이러한 방식으로 인해 새로운 버전에서 에러가 발생한다면 이전 버전의 jar 파일이 없어, 롤백하기 위해서는 이전 버전의 jar 파일로 다시 오버라이드하여 서버를 실행해야 했습니다. 이와 같은 이유로 한번 에러가 발생하면 다운타임이 길어져서비스 운영에 치명적으로 다가오게 됩니다. 이에 따라 안정적인 서비스 운영을 위해 다운타임을 최소화시키고, 빠르게 롤백할 수 있는 무중단 배포 방식 을 적용하고자 하였습니다. 또한 서버가 예기치 못하게 종료되었을 때를 대비하고 트래픽 분산을 위해 로드 밸런싱 환경도 함께 적용해 보겠습니다.

무중단 배포 전략

무중단 배포 전략에는 롤링 방식, 블루/그린 방식, 카나리아 방식 등 크게 세 가지가 있습니다. 각 방식에 대한 세부적인 내용은 후디의 무중단 배포 아키텍처와 배포 전략 포스팅에 자세하게 나와있기에 이 포스팅에서는 생략하겠습니다. 저희 모락 프로젝트에서 선택한 무중단 배포 전략은 블루/그린 방식입니다. 이유는 다음과 같습니다.

•

롤링, 카나리아 방식은 호환성의 문제가 있을 것이라 판단

카나리아와 롤링 방식은 점차 새로운 버전을 도입하기때문에, 구 버전과 신 버전이 동시에 운영되는 타이밍이 존재하고, 이는 호환성의 문제를 야기할 수 있다고 생각했습니다. 예를 들어 동시에 운영되는 시점에서 사용자가 새로운 버전에서 새로 추가된 화면을 요청하는 버튼을 눌렀을 때, 구 버전의 서버로 요청이 들어가면 404 페이지가 응답될 것입니다. 반면 블루/그린 방식은 새로운 버전이 한번에 실행되기때문에, reload 하는 타이밍만 호환성 문제가 발생하여 호환성 측면에서 장점이 있다고 판단했습니다.

•

블루/그린 방식은 롤백이 쉬움

서비스 특성 상 배포를 자주 하기때문에, 배포 과정에서 새로운 버전의 에러가 발생할 가능성도 높아집니다. 이에 따라 롤백을 해야 하는 상황도 마주해야 하는데, 블루/그린 배포 방식은 구 버전의 서버가 백업용으로 떠있을 수 있고, 또는 백업된 구 버전의 jar 파일을 바로 실행 시킬 수도 있습니다. 그래서 롤백 상황 시, 라우팅만 구 버전의 서버로 바꿔주거나 구 버전의 jar 파일을 실행시켜 라우팅을 바꿔주면 롤백을 쉽게 할 수 있기때문에, 롤백 관점에서도 저희 서비스와 잘 맞는다고 판단했습니다.

물론 블루/그린 배포 방식은 리소스가 2배로 들어간다는 단점이 있습니다. 하지만 추가적으로 사용할 인스턴스는 t4g micro 이기에 비용이 상대적으로 적게 소모되고, 하나의 인스턴스를 더 사용하는 비용보다 블루/그린 방식을 사용하면서 얻을 이점이 더 높다고 판단하였습니다.

로드 밸런싱

무중단 배포 환경을 적용하면서, 안정적인 서비스 제공을 위해 로드 밸런싱 환경도 함께 구축해 보았습니다. 로드 밸런싱 환경은 서버가 처리해야 할 요청을 여러 대의 서버로 나누어 처리할 수 있는 환경을 의미합니다. 로드 밸런싱은 트래픽을 나누어 처리하기때문에 하나의 서버가 처리하는 부하를 줄일 수 있고, 만일의 상황에 하나의 서버가 예상치 못하게 다운되었을 때, 남은 서버로 서비스를 지속적으로 이용할 수 있도록 대비할 수 있는 환경을 만드는 이점도 있습니다.

인프라 구조

저희 프로젝트에서는 위와 같이 블루/그린 무중단 배포 방식과 로드 밸런싱을 모두 적용시키기로 하였고, 이러한 환경을 단순히 적용하면 총 4개의 인스턴스를 사용해야 합니다.

이 방식은 운영되지 않는 인스턴스가 2개나 있기때문에, 리소스 활용 측면에서 다소 비효율적이라고 판단하였습니다. 이에 따라 적은 리소스로 최대한 활용할 수 있는 방법을 생각해보았고 다음과 같은 인프라 구조를 떠올렸습니다.

두 개의 인스턴스 모두 8080, 8081 포트를 활용하여 총 4개의 앱 서버가 구동됩니다. 그리고 각 포트는 신 버전 또는 구 버전을 가집니다. 예를 들어 현재 두 대의 WAS 8080 포트에 신 버전이 실행되고 있다면, 8081 포트에는 구 버전이 실행되고 있는 것입니다. 이 때 블루 서버인 8081포트는 운영되진 않고, jar 파일로 백업 파일만 존재합니다.

배포 과정은 다음과 같습니다.

새로운 배포를 진행할 때 운영되지 않는 포트를 확인합니다. 

운영되지 않는 포트에 새로운 버전의 배포를 진행합니다.

새로운 버전의 서버가 구동된 것을 확인하면 현재 운영중인 다른 포트의 서버를 종료합니다.

즉 각각의 포트로 블루/그린 배포 방식을 적용하고, 두 개의 인스턴스로 로드 밸런싱을 적용하는 구조입니다. 위의 구조를 적용하여 2개의 인스턴스만으로 블루/그린 배포 방식과 로드 밸런싱의 이점을 모두 가져올 수 있었습니다.

적용하기

DB 설정

가장 먼저 새로운 인스턴스에서도 DB 에 접근이 가능하도록 DB 호스트로 추가해주었습니다. 같은 서브넷 네트워크에 있기때문에 private IP 로 추가해 주었습니다.

jenkins 파이프라인

기존에 저희 프로젝트에서는 배포를 jenkins 의 프리스타일을 활용해 진행했었습니다. 프로젝트 초기에 배포 자동화를 적용할 때 파이프라인 방식보다 신속하게 할 수 있었기때문입니다. 하지만 무중단 배포와 로드 밸런싱 등 배포 과정이 점점 복잡해지면서 프리스타일 방식으로는 적용하기 힘들겠다고 판단하였고, 배포 자동화 방식을 프리스타일 방식에서 파이프라인 방식으로 변경하였습니다.

jenkins 파이프라인은 groovy 언어의 DSL로 작성하며 declarative 방식과 scripted 방식이 있습니다.

•

declarative 방식

최상단이 'pipeline' 으로 시작하고, 기존에 정의된 문법과 형식에 따라 작성할 수 있습니다. 따라서 비교적 결과물은 간단하지만, 로직을 추가하려면 jenkins와 plugin이 제공하는 문법을 모두 숙지해야합니다.

•

scripted 방식

최상단이 'node'로 시작하고, 최소한의 문법과 형식만 따라 작성합니다. 코드는 비교적 복잡하지만, 상대적으로 자유롭게 로직의 추가와 수정이 가능합니다.

저희 프로젝트에서는 최소한의 문법만 숙지하면 자유롭게 사용할 수 있는 scripted 방식을 사용하였습니다.

이 포스팅에서는 전체 스크립트는 너무 길기때문에, 가독성을 위해 각각의 stage 에 대한 설정을 설명하겠습니다. 전체 스크립트는 jenkins prd에서 확인할 수 있습니다.

stage('check-out') {
    // Get some code from a GitHub repository
    slackSend (channel: "jenkins", color: "good",  message: "Build Started - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
    git url: 'https://github.com/woowacourse-teams/2022-mo-rak.git',
        branch: 'main'
}
Groovy
복사

check-out stage 에서는 git 명령어로 github 에서 코드를 가져옵니다. slackSend 로 슬랙에 알림을 보낼 수 있습니다. 내부의 환경 변수는 jenkins 에 설정된 환경 변수입니다.

stage('build') {
    dir ('./backend') {
        try {
            sh './gradlew clean build'
            slackSend (channel: "jenkins", color: "good",  message: "Build Succeeded - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
        } catch(e) {
            slackSend (channel: "jenkins", color: "warning",  message: "Build Failed - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
            throw e
        }
    }
}
Groovy
복사

build stage 에서는 gradle build를 수행합니다. dir 로 명령을 수행할 디렉토리를 지정할 수 있습니다. 내부 블록에서는 Groovy 문법으로 try/catch 를 수행할 수 있습니다. 내부의 sh 은 리눅스 명령어와 같이 shell script 를 수행하는 명령어입니다.

stage('deploy') {
        try {
            OUTPUT = sh ( script: '''#!/bin/bash
						{수행할 shell script}
            ''',
            returnStdout: true
            ).trim()
            OUTPUT = OUTPUT.split("\n")

            echo "result is : ${OUTPUT}"
            slackSend (channel: "jenkins", color: "good", message: "Deploy Succeeded - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
        } catch(e) {
            slackSend (channel: "jenkins", color: "warning", message: "Deploy Failed - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
            throw e
        }

}
Groovy
복사

deploy stage 에서는 두 개의 인스턴스에 배포 스크립트를 실행시키고 그 결과 받은 그린 서버 포트에 대한 정보를 받아옵니다. script 로 수행할 스크립트를 작성할 수 있습니다. 저희가 작성한 shell script 는 너무 길어 아래에 따로 뺐습니다. returnStdout 으로 스크립트 수행 후 출력되는 내용을 전달받을 수 있고, 이 출력되는 내용으로 그린 서버 포트 정보를 받아옵니다.

•

수행할 shell script

#!/bin/bash
IP_LIST=(${PRD_WAS_IP_LIST})

SIZE=${#IP_LIST[@]}
PORT_A=8080
PORT_B=8081

PREVIOUS_PORT_LIST=()
NEXT_PORT_LIST=()

for IP in ${IP_LIST[@]}
do
    if curl -s -I -X OPTIONS "http://${IP}:${PORT_A}" > /dev/null; then
        PREVIOUS_PORT_LIST+=("${PORT_A}")
        NEXT_PORT_LIST+=("${PORT_B}")
    else
        PREVIOUS_PORT_LIST+=("${PORT_B}")
        NEXT_PORT_LIST+=("${PORT_A}")
    fi
done

for index in $(seq ${SIZE})
do
    PREVIOUS=${PREVIOUS_PORT_LIST[index-1]}
    NEXT=${NEXT_PORT_LIST[index-1]}
    IP=${IP_LIST[index-1]}

    ssh -i ${PEM_KEY} ubuntu@"${IP}" "sh ${BACKUP_SCRIPT} ${NEXT} 1>/dev/null 2>/dev/null"
    scp -i ${PEM_KEY} ./backend/build/libs/*.jar ubuntu@"${IP}":/home/ubuntu/deploy 1>/dev/null 2>/dev/null
    ssh -i ${PEM_KEY} ubuntu@"${IP}" "sh ${DEPLOY_SCRIPT} ${NEXT} 1>/dev/null 2>/dev/null"
done


for retry in $(seq 10)
do
    COUNT=0
    for index in $(seq ${SIZE})
    do
        IP=${IP_LIST[index-1]}
        NEXT=${NEXT_PORT_LIST[index-1]}
        if curl -s -I -X OPTIONS "http://${IP}:${PORT_A}" > /dev/null; then
            COUNT=$(($COUNT + 1))
        fi
    done

    if [ $COUNT -eq $SIZE ]
    then
        break
    fi

    if [ $retry -eq 10 ]
    then
        exit 1
    fi

    sleep 5
done

for index in $(seq ${SIZE})
do
    echo "${IP_LIST[index-1]}:${NEXT_PORT_LIST[index-1]}"
done

for index in $(seq ${SIZE})
do
    echo "${PREVIOUS_PORT_LIST[index-1]}"
done
Bash
복사

•

IP_LIST=(${PRD_WAS_IP_LIST})

◦

jenkins 환경 변수로 저장한 운영 서버 IP 문자열을 () 를 통해 리스트로 가져옵니다.

•

for IP in ${IP_LIST[@]}

◦

각 서버의 8080 포트에 curl 명령어로 요청을 보내고 응답이 오면 현재 구동되고 있는 포트, 아니면 앞으로 구동할 포트로 나누어 저장합니다.

•

for index in $(seq ${SIZE})

◦

각 서버에 ssh 명령어로 접속하고, sh 명령어로 각 서버에 있는 백업 스크립트와 배포 스크립트를 실행시킵니다. 이 때 블루 서버 포트와 그린 서버 포트를 파라미터로 함께 줄 수 있습니다.

◦

처음에는 1>/dev/null 2>/dev/null 을 지정하지 않아 해당 스크립트를 실행시켰을 때 output 을 받기 위해 무한정 대기하는 에러가 발생했었습니다.

•

for retry in $(seq 10)

◦

10 번 돌면서 새로 실행한 서버가 잘 실행되었는지 5초 간격으로 확인합니다.

•

for index in $(seq ${SIZE})

◦

각각의 서버에서 새로 실행시킨 그린 서버의 포트를 echo 합니다. echo 를 통해 출력을 만들고 이 출력물을 다음 스테이지에서 라우팅할 때 사용하였습니다.

stage('route') {
        try {
            echo "URL_A=${OUTPUT[0]}"
            echo "URL_B=${OUTPUT[1]}"

            sh 'ssh -i {PEM_KEY} ubuntu@${WS_IP} "bash {ROUTE_SCRIPT} ' + OUTPUT[0] + ' ' + OUTPUT[1] + '"'
            slackSend (channel: "jenkins", color: "good",  message: "Route Succeeded - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
        } catch(e) {
            slackSend (channel: "jenkins", color: "warning",  message: "Route Failed - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
            throw e
        }
}
Groovy
복사

route stage 에서는 nginx 가 있는 서버에 라우팅 변경 스크립트를 실행시킵니다. 이와 함께 그린 서버의 포트를 인자로 전달합니다.

stage('kill') {
        try {
            sub_list = []
            for (res in OUTPUT) {
                sub_list.add(res)
            }
            sub_list = sub_list[(int) (sub_list.size() / 2)..sub_list.size() - 1]

            println sub_list

            PRD_KILL_WAS_IP_LIST = PRD_WAS_IP_LIST.split(" ")

            PRD_KILL_WAS_IP_LIST.eachWithIndex { item, index ->
                sh 'ssh -i PEM_KEY ubuntu@' + item + ' "bash KILL_SCRIPT ' + sub_list[index] + ' 1>/dev/null 2>/dev/null"'
            }

            slackSend (channel: "jenkins", color: "good",  message: "Down Succeeded - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
        } catch(e) {
            slackSend (channel: "jenkins", color: "warning",  message: "Down Failed - ${env.JOB_NAME} ${env.BUILD_NUMBER} (<${env.BUILD_URL}|Open>)")
            throw e
        }
}
Groovy
복사

kill stage에서는 구 버전의 서버를 내립니다. 여기서는 groovy 문법을 다소 많이 활용하였습니다. 이 과정에서 jenkins 환경 변수를 받아오려면 ${} 형태가 아닌 PRD_WAS_IP_LIST 변수명을 그대로 사용해야 groovy 의 타입으로 받아올 수 있었습니다. 여기서 익숙지 않은 groovy 문법과 에러 내용때문에 애를 많이 먹었습니다

WAS 스크립트 설정

•

backup 스크립트

cp {jar file 위치} /home/ubuntu/deploy/backup/
Bash
복사

백업 스크립트에서는 기존의 jar 파일을 backup 폴더에 복사합니다.

•

deploy 스크립트

PORT=$1
pid=$(lsof -i:${PORT} | sed -n 2p | sed -e "s/ \{1,\}/ /g" | cut -d ' ' -f 2)

if [ -n"${pid}" ]
then
        kill -15 ${pid}
        echo kill process ${pid}
else
        echo no process
fi

echo 'sleep..'
sleep 30
echo 'now start'

nohup java -jar -Dserver.port=${PORT} {jar file 위치} >> {log file 위치} &

echo 'completed'
Bash
복사

위 jenkins 파이프라인의 deploy stage에서 실행시키는 deploy 스크립트입니다. jenkins 에서 위 스크립트 수행할 때 받은 포트 인자를 PORT 변수에 저장합니다. 그리고 혹시 해당 포트에 프로그램이 실행되고 있다면 -15 로 종료시킵니다. 이후 nohup 과 java 명령어로 jar 파일을 실행시킵니다.

•

kill 스크립트

PORT=$1

pid=$(lsof -i:${PORT} | sed -n 2p | sed -e "s/ \{1,\}/ /g" | cut -d ' ' -f 2)

if [ -n"${pid}" ]; then
 	kill -15 ${pid}
  echo kill process ${pid}
 	echo 'kill 성공'
else
	echo no process
fi
Bash
복사

여기서도 jenkins 에서 해당 스크립트 수행시 인자로 받은 port 를 활용합니다. 이 port 로 기존의 앱 서버 pid 를 찾고 종료시킵니다.

이후 nginx 를 이용한 로드 밸런싱 작업은 다음 포스팅에서 이어가겠습니다.