카나리 배포
GitLab v19.5Offering: GitLab.com, GitLab Self-Managed, GitLab Dedicated
요약
카나리 배포는 널리 쓰이는 지속적 배포 전략으로, 플릿의 일부만 애플리케이션의 새 버전으로 업데이트합니다. 지속적 전달을 도입할 때 조직은 어떤 배포 전략을 사용할지 결정해야 합니다. 새 버전의 애플리케이션에 문제가 있어도 사용자 중 일부만 영향을 받으며, 해당 변경 사항을 수정하거나 빠르게 되돌릴 수 있습니다.
카나리 배포는 널리 쓰이는 지속적 배포 전략으로, 플릿의 일부만 애플리케이션의 새 버전으로 업데이트합니다.
지속적 전달을 도입할 때 조직은 어떤 배포 전략을 사용할지 결정해야 합니다. 가장 널리 쓰이는 전략 중 하나가 카나리 배포이며, 플릿의 일부를 먼저 새 버전으로 업데이트합니다. 카나리라고 부르는 이 하위 집합은 이른바 탄광 속 카나리아 역할을 합니다.
새 버전의 애플리케이션에 문제가 있어도 사용자 중 일부만 영향을 받으며, 해당 변경 사항을 수정하거나 빠르게 되돌릴 수 있습니다.
사용 사례#
카나리 배포는 포드 플릿의 일부에만 기능을 배포하고, 사용자 일부가 임시로 배포된 기능을 사용하는 동안 그 동작을 관찰하려는 경우에 사용할 수 있습니다. 모두 정상이라면 문제가 없다는 확신을 가지고 해당 기능을 프로덕션에 배포할 수 있습니다.
카나리 배포는 사용자 인터페이스가 바뀌지 않지만 성능이 유지되거나 개선되는지
확인해야 하는 백엔드 리팩터링, 성능 개선 등의 변경에도 특히 유용합니다.
사용자에게 보이는 변경에 카나리를 사용할 때는 주의해야 합니다. 기본적으로
같은 사용자의 요청이 카나리 포드와 비카나리 포드에 무작위로 분산되어
혼란이나 오류가 생길 수 있기 때문입니다.
필요하다면
Kubernetes 서비스 정의에서 service.spec.sessionAffinity를 ClientIP로 설정하는
방법을 고려할 수 있지만,
이는 이 문서의 범위를 벗어납니다.
Canary Ingress를 사용한 고급 트래픽 제어#
카나리 배포는 Canary Ingress를 사용하면 더 전략적으로 운영할 수 있습니다. Canary Ingress는 가중치, 세션, 쿠키 등의 요소에 따라 안정 배포와 카나리 배포 사이에서 들어오는 HTTP 요청을 제어하는 고급 트래픽 라우팅 서비스입니다. GitLab은 사용자가 새 배포를 빠르고 안전하게 전개할 수 있도록 Auto Deploy 아키텍처에서 이 서비스를 사용합니다.
카나리 배포에서 Canary Ingress를 설정하는 방법#
Auto DevOps 파이프라인이 auto-deploy-image의 v2.0.0+를
사용하면 Canary Ingress가 기본으로 설치됩니다.
Canary Ingress는 새 카나리 배포를 만들 때 사용할 수 있게 되고, 카나리 배포가 프로덕션으로
승격되면 삭제됩니다.
처음부터 설정하는 예시는 다음과 같습니다.
- Auto DevOps가 활성화된 프로젝트를 준비합니다.
- 프로젝트에 Kubernetes 클러스터를 설정합니다.
- 클러스터에 NGINX Ingress를 설치합니다.
- 위에서 할당된 Ingress 엔드포인트를 기준으로 기본 도메인을 설정합니다.
- Auto DevOps 파이프라인에서
auto-deploy-image의v2.0.0+를 사용하는지 확인합니다. 사용하지 않는다면 문서에 따라 이미지 버전을 지정합니다. - 새 Auto DevOps 파이프라인을 실행해
productionjob 이 성공하고 프로덕션 환경이 생성되는지 확인합니다. - Auto DevOps 파이프라인용
canary배포 job을 구성합니다. - 새 Auto DevOps 파이프라인을 실행해
canaryjob 이 성공하고 Canary Ingress로 카나리 배포가 생성되는지 확인합니다.
배포 보드에 Canary Ingress 배포 표시(더 이상 사용되지 않음)#
이 기능은 GitLab 14.5에서 더 이상 사용되지 않습니다.
카나리 배포를 보려면 배포 보드를 올바르게 구성해야 합니다.
- 배포 보드를 활성화하는 단계를 따릅니다.
- 카나리 배포를 추적하려면 Kubernetes 배포와 포드에
track: canary레이블을 지정해야 합니다. 빠르게 시작하려면 GitLab 이 제공하는 카나리 배포용 Auto Deploy 템플릿을 사용할 수 있습니다.
배포에 따라 레이블은 stable 또는 canary 여야 합니다.
레이블이 비어 있거나 없으면 GitLab은 트랙 레이블을 stable로 간주합니다.
그 밖의 트랙 레이블은 모두 canary(임시)로 간주합니다.
이를 통해 GitLab은 배포가 안정 배포인지 카나리(임시) 배포인지 구분할 수 있습니다.
배포 보드를 구성하고 파이프라인이 최소 한 번 실행된 뒤, Pipelines > Environments의 환경 페이지로 이동합니다. 파이프라인이 실행되면 배포 보드가 카나리 포드를 뚜렷하게 표시하므로 각 환경과 배포의 상태를 빠르고 명확하게 파악할 수 있습니다.
카나리 배포는 배포 보드에서 노란색 점으로 표시되므로 쉽게 알아볼 수 있습니다.

Canary Ingress의 현재 트래픽 가중치를 확인하는 방법(더 이상 사용되지 않음)#
이 기능은 GitLab 14.5에서 더 이상 사용되지 않습니다.
-
배포 보드로 이동합니다.
-
오른쪽에서 현재 가중치를 확인합니다.

Canary Ingress의 트래픽 가중치를 변경하는 방법(더 이상 사용되지 않음)#
이 기능은 GitLab 14.5에서 더 이상 사용되지 않습니다.
환경의 배포 보드에서 트래픽 가중치는 GraphiQL을 사용하거나 GraphQL API에 요청을 보내 변경할 수 있습니다.
배포 보드를 사용하려면 다음 단계를 수행합니다.
- 프로젝트의 Operate > Environments로 이동합니다.
- 오른쪽 드롭다운 목록에서 새 가중치를 설정합니다.
- 선택한 값을 확인합니다.
다음은 GraphiQL을 사용한 예시입니다.
-
GraphiQL Explorer로 이동합니다.
-
environmentsCanaryIngressUpdateGraphQL 뮤테이션을 실행합니다.mutation { environmentsCanaryIngressUpdate(input:{ id: "gid://gitlab/Environment/29", # Your Environment ID. You can get the ID from the URL of the environment page. weight: 45 # The new traffic weight. For example, if you set `45`, 45% of traffic goes to a canary deployment and 55% of traffic goes to a stable deployment. }) { errors } } -
요청이 성공하면
errors응답에 빈 배열이 담깁니다. GitLab은 Canary Ingress의 가중치 파라미터를 업데이트하기 위해 Kubernetes 클러스터에PATCH요청을 보냅니다.