[AWS] 블루/그린(Blue/Green) 배포 방식이란?

AWS 무중단 배포 과정

지금까지 Auto Scaling, 로드밸런서를 이용해서 서버를 구축하는 과정을 알아보았습니다. 그런데 현재 서버를 운영 중인데 새로운 소스 코드를 업데이트 해야 한다면 어떻게 해야 할까요? 지금 서비스를 중단하고 소스 코드 업데이트 한 후에 다시 배포할 수도 있지만, 서비스들은 무중단 배포를 하는 것을 선호합니다.

 

그래야 기존 사용자들에게 불편함을 주지도 않고 기존 서버가 계속 운영되면서 새로운 버전의 서버를 업데이트 할 수 있기 때문에 무중단 배포를 선호합니다. 그래서 이번 글에서는 무중단 배포에 대해서 알아보겠습니다.

 

 

 

서버 단위의 블루/그린 배포

블루/그린 배포(Blue/Green deployment)는 무중단 배포 기법의 하나입니다. 블루/그린 배포 방식은 어떻게 동작하는지 알아보겠습니다.

현재 blue group 안에 두 대의 서버로 요청을 나눠서 처리하고 있다고 가정하겠습니다. 즉, blue group v1.0.1 버전을 서비스다 하다가 아래의 greep group v1.0.2 코드로 배포를 하려고 합니다.

 

 

그래서 먼저 Blue Group에 존재하는 인스턴스 수와 동일하게 Green Group에 만드는 과정이 일어납니다. 그리고 Green 그룹에 v1.0.2 버전을 배포합니다. 이렇게 블루/그린 배포는 두 개의 그룹을 가지고 진행됩니다. 여기서 얘기하는 그룹은 대상 그룹이 될 수도 있고, Auto Scaling 그룹이 될 수도 있습니다.

 

 

그리고 Blue/Green 모두 로드밸런서에 연결해서 잠시 동안 두개의 그룹 모두 트래픽을 처리하도록 연결해놓습니다.

 

 

그리고 Blue Group에 존재하는 모든 인스턴스를 종료한 후에 로드밸런서에 Blue Group을 제외하고 Green Group에서 모든 요청을 처리하도록 합니다.

 

 

 

블루/그린 배포 방식 장단점

• 첫 번째: 구, 신버전이 동시에 떠 있는 시간을 매우 짧게 처리할 수 있습니다.
• 두 번째: 롤백을 굉장히 빨리 할 수 있다. 테스트 환경에서는 문제점이 발견이 안됐는데 운영 서버에 배포를 하니 문제가 발생되면 재빨리 기존 것으로 롤백할 수 있습니다.
• 세 번쨰: 배포 과정에서 인스턴스 수가 줄지 않으므로 요청량을 처리하는 데서 오는 장애의 부담이 없습니다.

 

 

블루/그린 배포

아래와 같은 상황을 가정하고 진행해보겠습니다.

• Auto Scaling 그룹을 사용하고 있음
• 하루에 수없이 많은 인스턴스가 자동으로 생성되고 종료된다.
• 배포시 블루/그린 배포를 해야 한다.

 

 

그런데 여기서 인스턴스는 자동으로 추가되기 때문에 인스턴스가 생길 때마다 사람이 인스턴스에 접속해서 소스 코드를 최신화 시킬 수는 없습니다. 그래서 최신 소스 코드를 가지는 EC2 AMI를 사용하여 인스턴스를 만들었습니다.

 

AMI를 생성할 때만 쓰이는 Main 소스 코드를 담당하는 EC2를 가지고 있어야 합니다. (평상시에는 정지되어 있고 소스 코드가 업데이트 되어 AMI를 변경하고자 할 때 인스턴스를 실행시켜 AMI를 만듭니다.)

 

 

v1.02 버전으로 업데이트를 하기 위해서는 v1.02 버전의 새로운 AMI를 만들어야 합니다. 즉 위에서 보았던 거처럼 Green 그룹에 Blue 그룹에 존재하는 인스턴스 수와 똑같이 인스턴스 수를 만들어줍니다.

 

 

즉, 위와 같이 새로운 시작 템플릿에 새로운 버전의 AMI를 넣고 만들어야 합니다. 그리고 로드밸런서에 그린, 블루 그룹을 등록해서 잠시 동안 그린, 블루 그룹의 인스턴스들이 모든 요청을 나눠서 처리하게 합니다.

 

 

블루, 그린 그룹에서 모두 요청을 처리하는 데 문제가 없는 것을 확인되면 블루 그룹을 로드 밸런서에서 제외합니다. 

 

이렇게 간단하게 블루/그린 배포 방식에 대해 알아보았는데 다음 글에서는 실습을 진행해보겠습니다.