Canary Release(카나리 배포)

개념

Canary Release(카나리 배포)는 SW 배포의 방법 중 하나이다. 조금씩 사용자의 범위를 늘려가며 피드백을 통해 배포하는 방식을 카나리 배포라고 한다. 쉽게 말해, 일부 사용자들에게 SW를 배포한 뒤 괜찮다면 사용자들을 늘려가며 배포하는 방식을 뜻한다. 

 

이 기법의 이름은 광부들이 광산으로 들어갈 때 새장에 카나리아(카나리)라는 새를 새장에 넣어 가져가는 것에서 유래했다. 광산에서 유독가스가 누출되면 광부들이 중독되기 전에 카나리아가 먼저 죽게 된다. Canary release는 비슷한 개념으로 잠재적 문제를 초기에 발견하여 전체 운영환경이나 사용자에게 영향을 미치는 것을 방지한다.

 

Canary release 라는 이름이 별로 친숙하게는 들리지 않는다. 하지만, 이 기법은 단계별 배포(phased rollout) 혹은 점진적 배포(incremental rollout)이라는 이름으로, 적지 않은 시간 동안 사용되어 왔다.

 

Canary Release 

 

위와 같은 기존의 서비스가 있다고 했을 때, 새로운 버전의 SW를 배포하고자 한다.

이 상황에서, 서비스의 안정성이나 사용자의 피드백이 필요한 상황 속에서 임의의 사용자들을 선정한다. 이 때, 사용자들 선정 방법에는 무작위나 내부 직원(Alpha Test) 등 다양한 방법들이 있을 수 있다. 그러나 인구통계학적인 특성을 활용한다면 모집단으로의 확장(정식 배포)에서도 같은 결과를 가져올 수 있다.

여기서는 약 5%의 사용자를 선정하여 신규 버전을 배포하고 사용하게 한다. 그리고 성능 및 여러 가지에 대하여 사용자들의 피드백을 관찰하며 긍정적인 결과를 받거나, 또는 서비스 안정성에 대한 확신이 서게 되면 더 많은 사용자들에게 서비스를 제공한다. 즉, 더 많은 서버에 배포하여 더 많은 사용자들이 들어오도록 할 수 있다. 신규 버전을 배포하는 좋은 방법 중 하나는 PhoenixServers 를 이용하여 기존 서버들을 용도 변경하여 배포하거나, ImmutableServers를 사용하여, 새로운 서버들에 배포하고 기존 서버들은 폐기시키는 것이다.

이러한 Canary release는 장점만 존재하는 것은 아니다. 대표적인 단점 중 하나는, 관리비용이다. 버전 관리를 위해 동시에 여러 개의 소프트웨어 버전을 관리해야 하는 것에서 오는 비용이다. 때로는 동시에 2개 이상의 버전이 운영 환경에 배포되도록 할 수도 있겠지만 그리 좋은 방법은 아니다. 배포 버전의 개수를 최대한으로 작게 가져가는 것이 아무래도 유지보수에 있어서는 유리하다.

 

A/B Testing과의 차이

 Canary release는 기술적 구현의 유사성으로 인해 A/B 테스팅을 구현하는 하나의 방법이 될 수 있다. 그렇지만, 이 둘은 다른 개념이다. Canary release는 문제를 발견하고 이상이 있는 경우 롤백하는 것에 초점이 맞추어져 있지만, A/B Testing은 하나의 가설을 다양한 구현체를 사용하여 테스트하는 것을 목적으로 하기 때문이다. Canary release의 롤백을 감지하기 위한 비즈니스 지표를 모니터링하고 있다면, 이를 동시에 A/B 테스팅에 사용하는 것은 결과를 잘못된 결과를 가져올 수 있기에 경계해야 한다. 또한 실제로, A/B 테스팅에서 통계적으로 중요한 정보를 얻기 위한 충분한 데이터를 수집하는 데는 며칠이 걸릴 수 있지만, canary release에서의 배포는 불과 몇 분 혹은 몇 시간만에 끝내도록 요구하기 때문이다.

 

참고

외국 포스트

네이버 블로그 포스트