어떤 배포 전략(CI/CD, canary, blue-green)이 마이크로서비스에 적합한가요?

Question

Accepted Answer

독립적 배포 가능성이 핵심 목적이므로, 각 서비스는 **자체 CI/CD 파이프라인**과 하루에도 여러 번 안전하게 출시하기 위한 **저위험 릴리스 전략** — 일반적으로 canary나 blue-green — 이 필요합니다.

## 서비스별 파이프라인

각 서비스는 자체 주기로 빌드, 테스트, 배포합니다. 한 서비스의 변경이 전체 시스템 릴리스를 유발하지 않습니다.

```text
commit ─▶ build ─▶ unit + contract test ─▶ image ─▶ deploy(서비스 하나)
```

## 릴리스 전략

| 전략 | 방법 | 장점 | 단점 |
|---|---|---|---|
| 롤링 | 인스턴스를 점진적으로 교체 | 단순, 기본값 | 잠시 버전 혼재 |
| Blue-green | 두 환경, 트래픽 전환 | 즉각 롤백 | 인프라 2배 |
| Canary | 새 버전에 소량의 % 전송 | 영향 범위 제한 | 좋은 지표 필요 |

## 실제 canary

```text
v1 ████████████████ 95%   ← 오류율 / 지연 관찰
v2 █                 5%   ← 정상이면 승격, 아니면 롤백
  └─ SLO에 대한 자동 점검이 승격 vs 중단을 결정
```

## Blue-green

```text
[ Blue v1 ] ◀─ 운영 중 ──┐
[ Green v2 ] ◀─ 유휴     ├─ 라우터 전환 ─▶ Green이 운영; Blue는 즉각 롤백
```

## 함정

하위 호환 스키마가 없으면, 두 버전이 동시에 실행되므로 canary/blue-green이 깨집니다. 항상 버전 간 호환되도록 변경을 설계하세요.

## 왜 중요한가

잦고 저위험인 배포야말로 마이크로서비스의 복잡성을 감수할 만한 가치를 만드는 요소입니다. 느리고 위험한 릴리스는 자율성의 이점을 지워버립니다.

canary와 blue-green은 잘못된 배포의 영향 범위를 제한하고 거의 즉각적인 롤백을 제공하여, 배포를 두려운 사건에서 일상적이고 자동화된 매일의 활동으로 바꿉니다.

롤링	인스턴스를 점진적으로 교체	단순, 기본값	잠시 버전 혼재
Blue-green	두 환경, 트래픽 전환	즉각 롤백	인프라 2배
Canary	새 버전에 소량의 % 전송	영향 범위 제한	좋은 지표 필요