이중화 서버에서의 무중단 배포 (Rolling, Blue-green, Canary)

DevOps/CIㆍCD

이중화 서버에서의 무중단 배포 (Rolling, Blue-green, Canary)

Deveun 2021. 9. 17. 07:09

현재 회사에서 담당하고 있는 서비스는 온프레미스 환경에서 Rolling 전략의 배포를 진행하고 있다. DevOps가 중요해지는 만큼 배포 프로세스와 각각의 특징에 대해서 좀 더 자세히 알아보았다.

먼저, 왜 이중화 서버가 필요할까?

서버를 이중화하는 가장 큰 목표는 LoadBalance(부하균형)와 Failover(시스템 대체 작동)이다.

(1) 로드밸런싱(LoadBalance)

서버의 트래픽에 부하가 발생할 때 성능 향상을 위해서는 서버 자체를 고사양으로 업데이트하는 Scale-up 방식과 서버의 갯수를 증가시켜 트래픽이 분산되도록 하는 Scale-out 방식이 있다. 즉, 서버의 이중화는 Scale-out을 통해 서버의 성능을 향상시킬 수 있다.

이중화 서버는 L4장비(스위치)를 통해 로드밸런싱이 가능하다. 사용자가 NAT IP로 요청을 보내면 이를 Private(real) IP로 변환하며, 대체로 hash, RR방식으로 로드를 분산한다.

출처: http://kimstar.kr/blog/wp-content/uploads/2014/11/%EC%84%9C%EB%B2%84%EC%9D%B4%EC%A4%91%ED%99%94.pdf

(2) Fail-over

단일 서버로 시스템을 운영하는 경우에는 장애 발생시에 모든 서비스가 중단된다.

이는 서버 이중화를 통해서 서비스 중단의 문제를 해결할 수 있다. L4장비의 Fail-over 기능을 사용하게 되면 에러가 발생한 인스턴스 대신 다른 인스턴스에서 응답하도록 처리할 수 있으며, Health check 기능을 사용하면 지속적으로 로드밸런싱 대상 서버의 상태를 확인하여 비정상일 경우 요청을 보내지 않는다.

무중단 배포 전략 (Rolling, Blue-Green, Canary)

(1) Rolling

o 배포 절차

서버1(v1) 트래픽 차단 -> 서버1에 배포 -> 서버1(v2) 트래픽 오픈 -> 서버2(v1) 트래픽 차단 -> 서버2에 배포 -> 서버2(v2) 트래픽 오픈

: 현재 담당하는 서비스의 배포 방식이다. L4 스위치에서 배포 대상 서버로 트래픽이 들어오는 것을 차단하고 서버별로 순차적으로 배포를 진행한다. 회사에서는 인프라팀의 지원을 받아 직접 특정 서버로의 L4를 차단하는데, 다음 글을 참고해보니 카카오에서는 Health Check를 통해 L4 로드밸런싱에서 제외되도록 하는 방법을 사용하고 있다고 하니 도입할 수 있다면 고려해보는 것이 좋을 듯 하다. (참고: https://tech.kakao.com/2014/05/30/l4/)

간단하게 설명하자면 L4장비에서 해당 서버를 체크하기 위해 GET /health_check.html 요청 시 404 에러를 리턴하도록 파일을 리네임/삭제 하여 로드밸런싱 대상에서 제외하는 방법이다.

Rolling 배포는 구버전과 신버전이 동시에 존재하기 때문에 버전관리의 어려움이 있다. "all or nothing" 접근이 필요한 중요한 서비스의 경우 Blue-Green 배포가 더 적합하다. 또한, 이는 다른 서버로의 과부하가 발생할 수 있는 단점이 있다. 회사에서도 이러한 리스크를 줄이기 위해 트래픽이 가장 적은 새벽 시간대에 배포를 진행하고 있는데, CD(Continuous Deploy) 측면에서 바람직하지는 않다고 생각한다. 오프프레미스(클라우드) 환경에 비해 온프레미스 환경에서 Blue-Green 배포는 비용/관리적 측면에서 부담이 있지만 Stand-By 서버를 TB로 사용하는 등 방법을 고민해볼 필요가 있을 듯 하다.

(2) Blue-Green

o 배포 절차

기존 시스템과 동일한 환경으로 Stand-by 서버 그룹을 구성 -> Stand-by 서버 그룹을 v2로 업데이트 -> Stand-by 서버그룹(v2) 오픈 -> 신버전의 서버그룹으로 트래픽 전환 -> 기존 서버그룹(v1) Stand-by

구버전과 신버전을 동시에 나란히 구성한 뒤에 배포 시점에 일제히 트래픽을 전환하기 때문에 버전관리 문제가 발생하지 않는다. 또한 에러 발생시에 롤백이 편리하다. 리소스가 2배로 소요된다는 단점이 있는데 클라우드 환경에서는 대부분 Blue-green 배포방식을 지원해준다.

Blue-green 방식은 여러 측면에서 Rolling 배포전략보다 장점이 많은듯 보이지만 여전히 배포시점에서 트랜잭션이 interrupt 되는 문제를 어떻게 해결할 수 있을지 고민이 필요하다. 한가지 해결방법으로는 모든 트랜잭션을 두 환경에서 동시에 병렬로 처리한 뒤 배포 완료 후 중복 데이터를 처리해주는 방법이 있다고 한다. (참고: https://semaphoreci.com/blog/blue-green-deployment)

(3) Canary