무중단 배포 실전: 블루그린 vs 카나리, NHN LB로 트래픽 전환하고 롤백까지

배포할 때마다 서비스가 잠깐 멈춘다면

기존 서버를 내리고 새 버전을 올리는 방식은 단순하지만, 그 사이 짧은 공백이 생깁니다. 트래픽이 적은 새벽이라면 넘어갈 수 있어도, 24시간 돌아가는 서비스라면 그 순간의 오류와 이탈이 그대로 지표에 남습니다. 그래서 배포 중에도 서비스가 멈추지 않게 하는 것이 목표가 됩니다.

Martin Fowler는 배포 자동화의 어려움이 "최종 테스트를 마친 소프트웨어를 실제 운영으로 넘기는 컷오버 그 자체"에 있다고 짚습니다. 이 컷오버를 매끄럽게 만드는 두 가지 대표 전략이 블루그린과 카나리입니다. 둘 다 새 버전을 별도로 준비한 뒤 트래픽을 옮긴다는 점은 같고, 옮기는 방식에서 갈립니다. 하나씩 보겠습니다.

블루그린: 두 환경을 통째로 바꾼다

블루그린 배포는 최대한 동일하게 구성한 두 개의 프로덕션 환경을 둡니다. 한쪽을 blue, 다른 쪽을 green이라 하면 언제나 하나만 live입니다. 새 버전을 배포할 때는 지금 쉬고 있는 환경(예: green)에서 최종 테스트를 마칩니다.

검증이 끝나면 라우터를 전환해 들어오는 모든 요청을 green으로 보냅니다. 그 순간 blue는 놀게 됩니다(idle). 사용자는 전환을 거의 느끼지 못하고, 새 버전으로 넘어갑니다. 여기서 블루그린의 가장 큰 장점이 나옵니다. 문제가 생기면 라우터를 다시 blue로 되돌리면 됩니다. Fowler의 표현대로 "신속한 롤백" 경로가 확보되는 것이죠.

한 번 전환하고 끝이 아닙니다. green이 안정적으로 자리 잡으면, 이번엔 blue를 다음 배포의 스테이징으로 씁니다. 그렇게 두 환경이 live·이전 버전(롤백용)·다음 스테이징 사이를 번갈아 순환합니다. 대신 전환 시점에는 두 환경이 함께 존재해야 하므로 그만큼 자원이 필요하다는 점은 감안해야 합니다. 여기서 Fowler가 짚는 실무 난점이 하나 더 있습니다. 데이터베이스입니다. 특히 스키마를 바꿔야 할 때는 두 버전이 같은 데이터를 문제없이 다루도록 별도의 설계가 필요합니다. 애플리케이션은 통째로 바꿔도 데이터는 그럴 수 없기 때문이죠.

카나리: 조금씩 흘려보내며 확인한다

카나리 배포는 접근이 다릅니다. Fowler의 정의를 그대로 옮기면, 카나리는 "새 버전을 전체 인프라에 배포하기 전에 소수 사용자에게 조금씩 노출해 새 버전 도입의 위험을 줄이는 기법"입니다. 갱도의 카나리아처럼, 소수에게 먼저 내보내 이상 신호를 감지하는 것이죠.

먼저 일부 사용자만 새 버전으로 보냅니다. 누구를 먼저 보낼지는 선택입니다. 무작위 표본을 쓰기도 하고, 내부 직원에게 먼저 공개한 뒤 외부로 넓히기도 하며, 프로필이나 인구통계 기준으로 고르기도 합니다. 그리고 새 버전에 대한 확신이 커질수록 더 많은 서버와 사용자로 확대합니다.

카나리의 이점은 분명합니다. 실제 운영 환경에서 용량 테스트를 하면서, 문제가 보이면 사용자를 이전 버전으로 되돌리는 안전한 롤백 경로를 함께 갖습니다. 부하를 천천히 올리며 새 버전이 운영에 주는 영향을 지표로 관찰할 수 있다는 것이 별도 테스트 환경과 다른 지점입니다.

NHN LB로 실제 트래픽을 전환하는 법

두 전략 모두 "트래픽을 어디로 보낼지"를 실제로 결정하는 것은 로드 밸런서입니다. NHN Cloud 로드 밸런서는 인스턴스를 멤버로 등록해 트래픽을 분배하고, 리스너에서 수신 포트와 프로토콜을 정의합니다. 여기에 상태 확인(health check)이 더해집니다. 등록된 멤버가 정상 동작하는지 주기적으로 확인하고, 실패한 인스턴스는 부하 분산 대상에서 제외합니다. 공식 문서의 표현대로 "예기치 못한 장애나 점검에도 중단 없이 서비스를 제공"하는 평상시 가용성이 여기서 나옵니다. 블루그린의 무중단은 여기에 더해, 전환 전에 green을 충분히 검증하는 데서 나옵니다.

블루그린은 이렇게 구현합니다. 새 버전(green) 인스턴스를 멤버로 등록하고 상태 확인으로 정상 동작을 확인한 뒤, 리스너가 바라보는 대상을 green으로 전환하면 컷오버가 됩니다. 문제가 보이면 이전 멤버 구성으로 되돌려 롤백합니다. 라우터를 되돌린다는 Fowler의 개념이, NHN LB에서는 멤버·대상 전환으로 이뤄지는 셈이죠.

카나리는 한 가지 짚을 점이 있습니다. NHN Cloud 로드 밸런서의 분산 방식은 Round Robin, Least Connections, Source IP 세 가지이고, 가중치(weight) 방식은 없습니다. 그래서 카나리는 두 갈래로 구현합니다. 첫째, Round Robin에서 새 버전 멤버 수를 소수로 등록해 멤버 수 비율만큼 트래픽을 나눕니다(예: 신규 1대 기존 9면 약 10%). 둘째, L7 규칙으로 특정 조건의 요청만 새 대상 그룹으로 전달해, 내부 사용자나 일부 세그먼트에게 먼저 노출합니다. 뒤쪽 방식이 "내부 직원에게 먼저"라는 카나리 원칙과 잘 맞습니다.

롤백까지 설계해야 무중단이 완성됩니다

두 전략의 공통점을 하나만 꼽으면 이전 버전을 살아 있는 상태로 남겨 둔다는 점입니다. 블루그린은 이전 환경을, 카나리는 이전 버전을 그대로 두기 때문에, 되돌리는 동작이 곧 롤백이 됩니다. 새 버전을 어떻게 올릴지만큼이나 어떻게 되돌릴지를 미리 정해 두는 것이 무중단 배포의 실제 안전망입니다.

실무에서 이 설계는 생각보다 손이 많이 갑니다. 어느 전략이 서비스에 맞는지, 로드 밸런서의 멤버·리스너·상태 확인을 어떻게 구성할지, 전환 기준과 롤백 조건을 무엇으로 삼을지가 서비스마다 다릅니다. 스피디는 NHN Cloud Platinum 파트너로서 이런 무중단 배포 구조와 로드 밸런서 구성, 롤백 절차를 서비스 상황에 맞게 함께 설계하고 운영을 지원합니다. 배포가 부담스러운 이벤트가 아니라 반복 가능한 일상이 되도록 만드는 것이 목표입니다.

이것만 기억하세요

자주 묻는 질문 (FAQ)