Blue-Green 배포 방식

안녕하세요. 요즘 한창 API 개발 방법을 공부하고 있는 월리입니다.

오늘은 API를 Continuous Delivery(무중단 배포)하는 방법에 대해서 소개하려고 하는데요, 실제로 무중단 배포라는 것은 엄청난 장점들 외에도 해결해야 하는 문제점들을 갖고 있습니다. 예를 들자면 이런 경우죠.

 

worry.jpg

“새로운 API를 배포하고 싶은데, 그러면 업데이트 중에 서비스를 잠시 중단해야 할 것 같단 말야..”

 

위의 경우는 일반적인 서비스 배포 과정에서 항상 맞딱드리게 되는 문제였습니다. 잠시라도 서비스가 중단되게 되면 사용자들의 불편함이 생기게 될 것이고, 특정 영역의 업무에서는 꽤나 큰 위험성이 발생될 수도 있겠죠.

물론. 이전의 뛰어나신 고오급 개발자님들께서는 이러한 문제를 해결할 수 있는 여러 방법들을 고안하셨습니다. 오늘은 그 중에 하나를 소개해드리려고 해요.

 

Blue-Green Deployment (블루-그린 방식)

(한국어로 번역하면 : 빨간휴지 줄까 파란휴지 줄까?)

Screen Shot 2018-04-22 at 11.44.04 AM.png
그닥 어울리지 않나.. 무튼;;

대부분의 개발자들이 원하는 API 배포 방식은 ‘Continuous (연속적) 하고 Automatic (자동화)’ 한 방법일 것입니다. 배포를 자동화하게 되면 새로운 소프트웨어를 테스트하는 과정과 이를 새롭게 올리는 시간의 간격과 이를 통해 발생될 수 있는 갈등을 줄여줍니다. (즉, “샤샤샥” 하고 다 바꿔주는거죠.)

이미 Dave FarleyJez Humble 이라는 분들은 이러한 Continuous Delivery 에 대해 지속적으로 연구해왔고, 이미 몇 년 전에 이 주제에 대한 책을 집필하였습니다. 참고하셔도 좋을 것 같아요.

 

하지만 무중단 배포에는 문제가 있습니다. 바로 소프트웨어의 최종 테스트 단계에서 실제 운영 단계로 넘어갈때의 ‘중단 시기‘가 존재 한다는 것입니다.

예를 들어볼게요. 은행에서 갑자기 계좌를 이체하는 API를 교체하려고 한다고 가정합니다. 사실 이러한 교체 작업이 불과 몇초만에 이루어지지도 않지만, 이루어진다 하더라도 그 사이에 일어난 수 많은 계좌 이체 시도들은 모두 ‘Block’ 될 것입니다. 은행이라는 극단적인 예시를 보여드린 것 같지만, 실제 은행이 아닌 쇼핑몰이나 하물며 작은 서버일 경우에도  이러한 ‘중단 시기’ 는 꽤 골치 아픈 일이 되겠죠.

 

블루-그린 배포 방식을 이용하면 이 문제를 깔끔하게 해결할 수 있습니다. 굉장히 복잡한 기술이 필요할 것 같지만, 의외로 개념은 간단합니다.

“동일하게 구성된 환경을 하나 더 추가함으로써 문제를 해결한다.”

 

 

image.png
Blue-Green Deployment (from Martin Fowler Website)

 

위의 그림에서 파란색이 실제 운영중인 환경이라고 가정합시다. 새로운 버전의 소프트웨어를 릴리즈하고 싶은 경우, 그 소프트웨어의 테스트가 필요하겠죠? 그 테스트는 초록색에서 진행합니다.

초록색에서 테스트를 무사히 마친다면 이제 소프트웨어 버전을 업데이트 해야겠죠? 여기서 블루-그린 방식의 기존과의 차이점이 발생합니다. 기존에 파란색으로 들어가는 모든 요청(Request)을 초록색으로 향하도록 라우터 설정을 변경해주는겁니다.

그러면 파란색은 어떻게 될까요? 네. 노는거죠. (우리가 제일 좋아하는…) 농담이구요. 이제 파란색은 두가지 기능을 갖게 됩니다.

1. 이 후에 소프트웨어를 업데이트하기 전 테스트 환경으로 사용할 수 있습니다. 이전에 초록색이 담당했던 업무죠. 결국 Swapping 입니다.

2. 만약 초록색이 잘 동작하다가 갑자기 오류가 납니다. 수백번 테스트를 진행했지만 우리 까탈스러운 소프트웨어분들은 가끔 툴툴대기도 하죠. 이 때 이전 버전으로 다시 되돌리기 위한 ‘백업 서버’ 역할을 하기도 합니다. 

2번의 경우를 흔히 ‘롤백(Role-back)’ 이라고 부릅니다. 문제가 발생하면 다시 모든 요청들을 파란색으로 보냄으로써, 빠르고 간단하게 문제를 해결하는거죠.

하지만 여전히 문제가 있습니다. 바로 ‘초록색에 문제가 있는지 몰랐을 때 초록색으로 이동함으로서 유실된 요청들 (여기서는 트랜잭션이라고 하겠습니다)’  에 대한 처리가 필요하게 되죠. 

사실 이 부분도 ‘간단(왜 다들 간단하다고만 하는가?)하게’ 해결할 수 있습니다. 들어오는 모든 요청들을 항상 파란색과 초록색 양방향으로 보내는거죠. 실질적으로는 한 쪽만 사용자에게 비춰지겠지만, 요청되는 모든 트랜잭션들은 다 공유하자는겁니다. 언제 어떻게 될지 모르니까요. 말그대로 초록색이 실제 운영중이라면 파란색을 백업으로, 파란색이 운영중이라면 초록색을 백업으로 구성하자는거죠.

혹은 새로운 환경으로 전환하기 전에 운영중인 환경을 읽기 전용(Read-Only)으로 바꿔주는 방법도 있습니다. 그리고 완벽하게 전환이 마무리 되면 읽기-쓰기(Read and Write) 방식으로 바꿔주는거죠. 무튼 여러가지 방법들이 있습니다.

 

이처럼 블루-그린 방식은 다양하게 발생될 수 있는 문제점에 대한 해결방법까지 제시하고 있을 정도로 ‘꽤 믿음직스러운’ 배포 방식으로 자리매김하고 있습니다.

대신 명심해야 할 부분들이 있습니다. 우선 두 개의 환경은 분명히 서로 다르지만, 가능한 동일한 형태를 지녀야 합니다. 서로 다른 장비에 환경이 구성될 수도 있고, 혹은 하나의 서버에 가상화로 구성될 수도 있겠죠. 아니면 아예 같은 호스트(OS)안에서 IP 또는 디렉토리를 다르게 해서 구분지을 수도 있겠죠.

image.png
Using Blue-Green Deployment in docker for load balancing Nginx (Subicura’s Blog)

 

위의 그림은 수비쿠라님 블로그에서 블루-그린 방식을 이용하여 nginx를 Load-balancing 하고 있는 그림을 보여줍니다. 물론 IP를 서로 다르게 해서 서버를 로드밸런스 할 수도 있지만, 하나의 IP에서 포트를 다르게 함으로써 진행할 수도 있다는 것을 보여주고 있습니다. (위는 도커를 이용한 방식인데요, 제가 조금 더 학습한 후에 포스팅 해 보겠습니다)

 

참고 사이트

https://martinfowler.com/bliki/BlueGreenDeployment.html

http://blog.naver.com/muchine98/220267437777

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중