서비스 규모가 커질수록 새로운 Version을 한 번에 모든 사용자에게 적용하는 것은 위험합니다.

새로운 코드에 문제가 있을 경우 전체 사용자가 영향을 받을 수 있기 때문입니다.

기존 방식:

새 Version 배포

↓

전체 사용자 적용

↓

문제 발생

↓

전체 장애

Canary 배포는 일부 사용자에게만 새로운 Version을 먼저 적용하고 문제가 없는지 확인한 뒤 점차 확대하는 방식입니다.

기본 구조:

사용자 100%

↓

90% 기존 Version

↓

10% 새로운 Version

확인 후:

10%

↓

50%

↓

100%

으로 Traffic을 증가시킵니다.

이번 글에서는 Docker Compose Canary 배포 개념부터 Container 구성, Nginx Traffic 제어, 점진적 배포 과정, Rollback 방법까지 Production 서버 기준으로 알아보겠습니다.

Table of Contents

Canary 배포란 무엇인가?

Canary라는 이름은 광산에서 유래되었습니다.

과거 광부들은 위험한 가스 감지를 위해 카나리아 새를 사용했습니다.

서비스 배포에서도 같은 의미입니다.

새로운 Version을 소수 사용자에게 먼저 적용하여 위험을 확인합니다.

구조:

기존 서비스

↓

새 Version 일부 적용

↓

문제 확인

↓

전체 확대

Blue Green과 Canary 차이

Blue Green:

Version A

↓

Version B 전체 전환

Canary:

Version A 90%

Version B 10%

차이:

방식	특징
Blue Green	한 번에 Traffic 전환
Canary	점진적 Traffic 증가

Docker Compose Canary 배포 구조

기본 구조:

사용자

↓

Nginx / Load Balancer

↓

App Stable

↓

App Canary

예:

app-v1

↓

기존 서비스


app-v2

↓

신규 테스트 Version

Docker Compose Stable Container 구성

기존 Version:

services:

  app-stable:

    image: my-app:1.0

    container_name: app-stable

구조:

사용자

↓

app-stable

Docker Compose Canary Container 구성

새 Version:

services:

  app-canary:

    image: my-app:2.0

    container_name: app-canary

구조:

일부 사용자

↓

app-canary

Docker Compose Traffic 비율 제어

Canary 배포의 핵심은 Traffic 제어입니다.

예:

초기:

Stable 90%

Canary 10%

검증 후:

Stable 50%

Canary 50%

최종:

Canary 100%

Docker Compose Nginx Canary 설정

Nginx upstream 예:

upstream app {

    server app-stable:3000 weight=9;

    server app-canary:3000 weight=1;

}

의미:

Stable

90%


Canary

10%

Traffic 분배:

사용자 요청

↓

Nginx

↓

비율 분배

Docker Compose Canary 배포 과정

1단계:

기존 서비스 운영

app-v1

↓

100% Traffic

2단계:

Canary 실행

app-v2 시작

3단계:

일부 Traffic 전달

90 : 10

4단계:

Monitoring 확인

확인:

Error Rate
Response Time
CPU
Memory

5단계:

확대

10%

↓

50%

↓

100%

Docker Compose Canary Healthcheck 적용

새 Version은 반드시 검증해야 합니다.

설정:

healthcheck:

  test:

    - CMD

    - curl

    - localhost:3000

  interval: 10s

  retries: 5

과정:

Canary 실행

↓

Health Check

↓

Traffic 적용

Docker Compose Canary Monitoring

Canary 배포에서는 Monitoring이 매우 중요합니다.

확인 항목:

Error Rate

예:

기존

0.1%


Canary

5%

문제 감지 가능

Response Time

응답 속도 증가 확인

Resource

CPU

Memory

Docker Compose Canary Rollback

문제 발생:

Canary 오류 증가

즉시:

Canary Traffic 제거

변경:

upstream app {

    server app-stable:3000;

}

결과:

전체 사용자

↓

Stable Version

Docker Compose Canary와 CI/CD 연결

자동화 구조:

Git Push

↓

CI Build

↓

Canary Container Deploy

↓

일부 Traffic 적용

↓

Monitoring

↓

확대 또는 Rollback

Pipeline:

Build

↓

Deploy Canary

↓

Test

↓

Traffic 증가

↓

Complete Deploy

Docker Compose Canary 장점

위험 감소

전체 장애 방지

실제 사용자 환경 테스트

Production 데이터 기반 확인 가능

빠른 문제 발견

초기 사용자 반응 확인

Rollback 쉬움

Traffic 제거만으로 복구

Docker Compose Canary 단점

운영 복잡도 증가

두 Version 관리 필요

Monitoring 필수

문제 감지 시스템 필요

Database 변경 주의

Schema 호환 필요

Docker Compose Production Canary 구조

실제 운영:

사용자

↓

Load Balancer

↓

Nginx

↓

Stable App 90%

Canary App 10%

↓

Redis

↓

Database

↓

Monitoring

Docker Compose Canary Best Practice

자주 묻는 질문

Canary 배포는 작은 서비스에도 필요한가요?

가능하지만 운영 규모가 커질수록 효과가 커집니다.

Blue Green과 Canary 중 어떤 것이 좋은가요?

서비스 특성에 따라 다릅니다.

빠른 전환은 Blue Green, 위험 최소화는 Canary가 적합합니다.

Docker Compose에서도 Canary가 가능한가요?

가능합니다.

Nginx, Load Balancer를 이용해 Traffic 제어 구조를 만들 수 있습니다.

Canary 배포에서 가장 중요한 것은 무엇인가요?

Monitoring과 Rollback 준비입니다.

마무리

Docker Compose Canary 배포는 새로운 Version을 안전하게 출시하기 위한 중요한 운영 전략입니다.

핵심 구조:

기존 Version 유지

↓

새 Version 일부 적용

↓

Monitoring

↓

Traffic 확대

↓

전체 전환

이 방식을 사용하면 Production 서비스 장애 위험을 줄이고 안정적으로 새로운 기능을 배포할 수 있습니다.

다음 글에서는 Blue Green과 Canary를 포함한 전체 운영 방식을 정리하는 Docker Compose 무중단 배포 전략을 알아보겠습니다.

Docker Compose Canary 배포 완벽 가이드! 점진적 Version 배포와 안전한 Traffic 제어 방법 알아보기