Blue Green 배포 (Feat. 무중단 배포)
<Blue Green 배포>
안녕하세요.
Blue Green 배포 글로 돌아온,
개발자 김모씨입니다.
혹시 이전 포스팅인 A/B 테스트란? 글 모두 보셨나요?
오늘 할 이야기는 A/B 테스트와 비슷한 점이 많으니,
아직 안 보신 분들은~ 얼른 훑고 오시죠!
A/B 테스트란? (알파베타 테스트)
안녕하세요. A/B 테스트에 관한 글로 돌아온, 개발자 김모씨 입니다. 오늘의 주제에 앞서, 시나리오를 하나 떠올려 보죠. " A씨는 인터넷 쇼핑몰 회사에 다니는 FE(Front-End) 엔지니어입니다. 몇날몇�
artist-developer.tistory.com
A/B 테스트를 한 문장으로 요약하자면...
"개선요소를 Before/After 버전을 A/B의 임의 고객 그룹에 전달하여, 양쪽 그룹 고객들의 반응을 살핀다"
정도겠네요.
오늘도 시나리오로 시작해보죠.
"
A씨는 인터넷 포털 회사에 다니고 있습니다.
N사, D사에 밀려 사용자 확보가 어렵지만,
어느새 동시 사용자 수백명의 포털사이트가 되었어요.
어썸(AWESOME)- 한 개발자인 A씨는 유저들의 반응을 자주 모니터링합니다.
그리고 유저들이 매번 필요하다고 요청했던, 검색어 추천 기능을 개발했어요.
이제 개발된 기능을 배포해야겠죠?
그런데 어떡하죠?
기능을 업데이트 하려면 인터넷 포털 사이트를 잠시 닫아야 되는데...
아직 유저층이 두텁지 못해서, 유저가 N사로 이탈할까봐 무섭네요.
A씨는 어떻게 배포해야 할까요?
"
이런 시나리오처럼,
웹, 앱, 게임 등 수많은 분야에서
개발자들은 배포를 고민하게 됩니다.
크게 두가지 방법이 있죠.
1. 유저들의 사용률이 낮은 새벽 시간대에 서버를 내리고 배포한다.
2. 사용률이 높은 시간대에 무중단 배포를 한다.
오늘의 이야기인 Blue Green 배포 방식은
2번. 무중단배포 방식의 대표적인 방법입니다.
Blue Green 배포란?
Blue Green 배포를 쉽게 말하면,
"두 버전을 모두 올리고, 유저의 요청을 라우터단에서 중계하여, 서서히 새 버전으로 요청을 이동시킨다"
라고 할 수 있어요.
이전 버전을 Blue,
A씨가 개발한 기능이 추가된 버전을 Green 이라고
추상화해서 부릅니다.
사실 색깔은 중요하지 않죠.
스텝별로 접근해보죠.
1. 두 버전을 모두 클러스터 환경에 올립니다.
2. 처음에는 기존 버전인 Blue 클러스터로 모든 트래픽이 라우팅됩니다.
3. 새로운 버전은 Green 클러스터에서 테스트를 진행합니다.
4. 테스트가 완료된 후, 서서히 Green 클러스터로 유저의 트래픽을 라우팅합니다.
이 때, Green 클러스터로 전송되는 트래픽은 Blue 클러스터에도 동시에 라우팅됩니다. (백업 용도)
5. 모든 트래픽을 새 버전인 Green 클러스터로 라우팅 합니다.
간단하죠?
이렇게 해서 무중단배포가 완성되는 거에요.
그럼 기존 버전이 있던 Green 클러스터는 어떻게 되냐구요?
두가지 용도로 사용됩니다.
1. 이후 새로운 버전을 업데이트 하기 위한 테스트 공간
: 기능은 추가적으로 계속 개발되겠죠? 그 테스트를 위한 환경으로 남아있는 거죠.
또 다음의 무중단 배포 시에 사용될 것이고요.
2. 신규 버전의 오류 시 롤백(roll-back) 용도
: 수많은 테스트를 거쳤지만, 신규 버전은 유저가 늘어나면 어떤 오류를 발생시킬지 알 수 없어요.(like 시한폭탄)
치명적인 오류가 발생할 경우,
서버 자체를 이전 버전으로 roll-back 하는 것도 한가지 해결책이 될 수 있죠.(마지막 해결책...)
그럴 경우를 대비한 이전 버전의 백업 환경의 역할을 담당합니다.
이와 같은 Blue Green 배포 방식은
컨테이너, 클러스터 환경에서 쉽게 사용될 수 있습니다.
적용 가능한 툴로는
Docker, Docker Swarm, Kubernetes 등이 있겠네요.
물론, 해당 기능을 제공하는 상용화된 여러 제품군들도 많습니다.(Redhat의 OpenShift 등)
Blue Green 배포의 장점
그럼, Blue Green 배포의 장점에는 어떤 것들이 있을까요?
1. Zero Downtime
: 앞서 언급한 것처럼, 가장 핵심적인 장점은 무중단 배포입니다.
유저가 업데이트를 체감하지 못하게 함으로써,
유저의 불편함이나 이탈을 최소화할 수 있죠.
2. 쉬운 롤백(roll-back)
: Blue Green 배포 방식이 아닌, 중단 후 배포 방식을 선택했다고 가정해보죠.
배포 후 신규 버전에서 치명적인 결함이 발견되었어요. 어떤 조치를 취할 수 있을까요?
신규 버전에는 이미 활성 사용자들이 있기 때문에,
'서버를 다시 닫고, 데이터를 백업한 후, 기존 서버로 롤백하고, 다시 서버를 연다.'
하는 방식으로 롤백이 수행되어야 합니다.
Blue Green 배포 방식은 이와 같은 문제를 발생시키지 않는, 최적의 롤백 환경을 제공하죠.
3. 최종단계 테스트
: 새로운 기능을 추가하여 신규 배포하는 일은, 개발자들에게 여전히 부담스러운 일임이 분명합니다.
새 버전이 어떤 오류를 발생시킬지 예측하기 어려우니까요.
Blue Green 배포 방식을 채택할 경우,
위의 스텝 설명 4번에서, 'Blue/Green의 동시 라우팅을 최대한 길게 유지'하는 방식으로 최종단계 테스트를 수행합니다.
유저가 요청한 트래픽을 점차 늘려가며 100%에 도달할 때까지
Blue 클러스터와 Green 클러스터 양 쪽 버전 모두에 보내는 거죠.
이를 통해서, 예상치 못한 결함을 잡아낼 수 있습니다.
이와 같은 장점들로 인하여,
최근에는 수많은 IT 분야에서 Blue Green 배포 방식이 채택되어 활용되고 있습니다.
♣♣♣
자 오늘은 이렇게
Blue Green 배포가 무엇인지,
무중단 배포는 어떻게 이루어지는지
하는 것들에 관해 알아보았습니다!
오늘의 이야기를 요약해 줄 좋은 GIF 파일이 있어 공유드립니다.
어때요?
한 눈에 잘 들어오죠?
이처럼 DevOps 엔지니어들은
Old 버전(Blue)과 New 버전(Green) 사이의 트래픽을
적절하게 Load Balancing 함으로써,
서비스의 무중단 배포를 수행한다는 점!
기억하시고요.
그럼 오늘은 여기까지!
좋아요와 구독하기는 개발자 김모씨에게 큰 힘이 됩니당당당
감사합니당당당
