2025. 1. 13. 22:39ㆍBackend
[250113]
오늘 상용 배포 때 알게 된 카나리 배포 관련 내용을 간략히 기록
카나리 배포
카나리 배포의 카나리(Canary) 는 탄광에서 나오는 유독 가스를 사전에 감지하기 위해 광부들이 가스에 민감한 카나리 새를 데리고 갱도를 사전 탐사(?) 하는데서 비롯되어, 다가올 위험을 사전에 알려준다는 의미로 사용된다. 카나리 배포는 새로운 버전의 애플리케이션을 모든 사용자에게 한 번에 릴리즈하지 않고 일부 사용자에게만 먼저 제공하여 점진적으로 롤아웃하는 배포 방식이다. 일부만 릴리즈 된 서버에서 에러가 발생하지 않거나 정상적으로 동작하는 것을 확인한 후에, 개발자는 점진적으로 모든 시스템에 새로운 버전의 애플리케이션을 배포할 수 있다. 좀 더 정리된 말로 카나리 배포는 일부 서버에만 새로운 버전을 배포하고, 일부 트래픽을 새 버전으로 분산하는 방법을 의미한다.
상황 가정
쿠버네티스 환경에서 여덟개의 파드로 운영중인 시스템이 있다고 가정하자. 이 시스템을 카나리 배포한다면 어떻게 진행해야할까? 우선 필자는 카나리 배포가 점진적으로 배포한다는 개념만 알았지, 어떻게 점진적으로 배포하는 것인지 구체적으로 생각해보지 못했다.
카나리 배포는 점진적으로 서비스를 배포하기에 전체 파드 중 몇개의 파드에 신규 버전을 릴리즈할지 개발자나 운영자가 정할 수 있다. 만약 카나리 배포 시 weight 를 10% 로 정하면 8개 중 1개의 파드(=0.8개의 반올림) 에만 신규 버전을 릴리즈 한다.
사내 배포 툴에서는 위처럼 CanaryWeight 와 CanaryReplicaCount 를 지정할 수 있다. 이 두 값의 적절한 설정이 중요한데, 만약 weight 는 50% 로 설정하고 replica count 는 1로 설정하면 전체 트래픽의 50%가 단 하나의 파드로 집중되어 서버 과부하가 발생할 수 있다. 그렇기에 replica count 와 weight 비율을 상황에 맞게 조절하며 배포할 수 있어야 한다. 개인적으로 코드 업데이트가 크지 않을 땐 weight 값을 높여도 되지만, 대규모 마이그레이션이나 리팩토링된 코드를 배포하는 경우라면 weight 를 소극적으로 선정하여 트래픽 추이를 봐야한다고 생각한다.
위 이미지는 weight 를 10 으로 맞추고 배포했을 때 서버 metric 을 캡쳐한 것 이다. 빨간색 동그라미에선 아주 적은 비율의 트래픽만이 신규 버전으로 할당된 것을 볼 수 있다. 메트릭을 확인하면서 신규 버전이 안정적으로 배포됐다고 판단되면 완전히 신규 버전 서버를 배포할 수 있다 (by 개발자). 만약 일부 배포된 신규 버전이 불안정하거나 error rate 가 점점 높아진다면 신규버전을 rollback 하고 모든 파드를 기존 애플리케이션으로 유지하도록 조치하면 된다. 위 이미지에서는 신규 버전(보라색)이 안정적으로 릴리즈 됐기에 구버전의 서버(파란색)를 점진적으로 제거한다.
+ 현재(회사)는 Spinnaker 의 웹 인터페이스를 통해 canary 배포 진행상황을 모니터링하고 제어할 수 있다. 추후 ArgoCd 로 마이그레이션이 예정되어 있는데 두 도구의 카나리 배포 방식의 차이점도 추가로 조사해봐야겠다.
'Backend' 카테고리의 다른 글
테크 블로그 모아보기 개발 기록 (1) (13) | 2024.09.30 |
---|