배포 전략

학습 목표

rolling·recreate·blue-green·canary의 트래픽·인프라 차이를 설명할 수 있다.

Deployment strategy·readiness·Service selector로 무중단·점진 배포를 설계할 수 있다.

feature flag와 배포를 분리해 릴리스 리스크를 줄이는 방법을 설명할 수 있다.

rollback·blast radius·RTO 관점에서 전략을 선택·비교할 수 있다.

문제 상황

• kubectl set image 한 번에 전체 Pod가 바뀌었고, 버그가 100% 사용자에게 노출됐다
  • canary·점진 트래픽 필요
• 롤링 중 구·신 버전 API 스키마가 달라 500이 났다
  • backward compatible·feature flag 없이 배포
• DB 스키마 마이그레이션과 앱 배포를 동시에 해 롤백 불가
  • expand/contract·배포 순서 분리
• staging은 green인데 prod 전환에 30분 — DNS·LB 수동 스위치
  • blue-green 자동화·검증 gate 부재
• 장애 시 rollout undo만 알고 데이터·캐시 롤백은 못 한다
  • blast radius·상태ful 워크로드 고려 부족
• CI는 잘 도는데 배포 전략 문서가 없어 팀마다 apply 방식이 다르다
  • 표준 전략·runbook 필요

앞서 Deployment 롤링 업데이트·CI/CD deploy job까지 봤다. 이번 편은 어떤 방식으로 새 버전을 노출할지 — 배포 전략을 고른다.

1. 전략 한눈에

전략	트래픽 전환	다운타임	롤백 속도	인프라 비용
Recreate	한 번에 교체	있음	image revert + 재배포	낮음
Rolling	Pod 순차 교체	없음(설정 의존)	rollout undo	낮음
Blue-green	전체 스위치	없음	selector/LB 되돌림	2배 (일시)
Canary	비율 점진	없음	weight 0%	중간
Feature flag	코드 경로 분기	없음	flag off	낮음(플랫폼)

risk exposure:  Recreate → Rolling → Blue-green → Canary → Flag (앱 레벨)
rollback speed: Blue-green (switch) ≈ Flag (instant) > Rolling > Recreate

• 배포(deploy) — 바이너리·이미지·manifest 교체
• 릴리스(release) — 사용자에게 기능 노출 — flag로 분리 가능
• K8s 기본 — Deployment RollingUpdate (6편)
• 조직 전략 — blue-green·canary는 Service·Ingress·GitOps와 조합

2. Rolling · Recreate

K8s Deployment 내장 전략. 같은 Service 뒤에서 Pod를 바꾼다.

strategy.type	동작	적합
RollingUpdate	새 Pod ready → 구 Pod 종료	무중단 stateless API
Recreate	전부 terminate → 새로 create	dev·schema break 허용

spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1
      maxUnavailable: 0
  template:
    spec:
      containers:
        - name: app
          image: my/api:1.4.0
          readinessProbe:
            httpGet:
              path: /health/ready
              port: 8080

파라미터	실무
maxUnavailable: 0	capacity 유지 — readiness 필수
maxSurge: 25%	빠른 교체 vs 노드 여유
progressDeadlineSeconds	stuck rollout fail

kubectl rollout status deployment/api
kubectl rollout history deployment/api
kubectl rollout undo deployment/api

• 구·신 동시 serving — API 호환 필요 (expand/contract)
• StatefulSet·Job — rolling 패턴이 다름 (9편)
• rolling 한계 — 트래픽 비율 제어는 Ingress canary·mesh가 담당

3. Blue-green

두 환경(blue=현재, green=신규)을 동시에 띄우고, 검증 후 한 번에 트래픽 전환.

1. green에 v2 배포 (트래픽 없음)
2. smoke / integration test on green
3. Service selector 또는 LB target switch → green
4. blue 유지 (빠른 rollback) → 확인 후 scale down

구현	설명
Service selector	version: blue → version: green patch
두 Deployment	api-blue, api-green — replica 각각
Ingress/LB	backend pool swap
GitOps	overlay 한 파일로 selector 변경 PR

# active traffic → green (after validation)
spec:
  selector:
    app: api
    version: green

• 장점 — 롤백 = selector revert (초~분)
• 단점 — 배포 중 2× 리소스·DB 양쪽 호환
• DB migration — green만 새 스키마 읽기 가능하게 expand 먼저
• CI/CD — deploy job이 green apply → test job → promote job

4. Canary

신버전에 일부 트래픽만 보내 지표 확인 후 비율 확대.

단계	트래픽	관측
1%	canary Deployment	error rate, latency p99
10%	weight up	business metric
50%	half	saturation
100%	promote stable	decommission old

K8s 패턴	메커니즘
Ingress NGINX	canary annotation + weight
두 Deployment	api-stable, api-canary
Argo Rollouts	ReplicaSet weight·analysis
Service mesh	VirtualService traffic split (19편)

# Ingress NGINX canary (요지)
metadata:
  annotations:
    nginx.ingress.kubernetes.io/canary: "true"
    nginx.ingress.kubernetes.io/canary-weight: "10"

• 자동 promote — Prometheus SLO gate (error budget)
• 실패 — weight 0 + canary scale down
• rolling과 병행 — canary Deployment 내부는 rolling update

5. Feature flag

배포 ≠ 릴리스 — 코드는 prod에 있어도 flag off면 미노출.

	배포 전략	feature flag
단위	Pod·LB·route	코드 분기
롤백	infra revert	flag toggle (초)
대상	버전·인스턴스	사용자·tenant·%
상태	stateless에 유리	실험·A/B

if flags.Enabled("new-checkout", user.ID) {
    return checkoutV2(c)
}
return checkoutV1(c)

• LaunchDarkly·Unleash·OpenFeature — 플랫폼 표준화
• canary + flag — infra 10% + flag로 내부 only
• flag debt — 출시 후 dead code 제거 일정
• ConfigMap flag — 간단하지만 전파 지연·캐시 (8편)

6. 롤백 · blast radius

개념	의미
rollback	이전 known-good 상태로 복귀
blast radius	장애 영향 범위 (사용자·region·tenant)
RTO	복구 목표 시간
RPO	허용 데이터 손실

전략	rollback	blast radius
Recreate	재배포	100% 즉시
Rolling	undo / revision	교체 순간 구간
Blue-green	selector swap	전환 전 green만
Canary	weight 0	canary % 만
Flag	off	flag 대상 만

reduce blast radius:
  · canary 1% → region shard → tenant allowlist
  · flag default off → gradual enable
  · DB expand/contract (no destructive migrate with deploy)

• immutable artifact — 롤백 = 동일 digest 재지정 (11~12편)
• rollout undo ≠ DB undo — migration backward compatible
• runbook — who promotes, metric threshold, comm channel
• Game day — rollback drill 분기 1회

7. 실무 선택

상황	권장
stateless API, 팀 소규모	Rolling + readiness
zero-downtime + 빠른 revert	Blue-green
prod 리스크 큰 변경	Canary + metric gate
UI·비즈니스 실험	Feature flag
dev/staging	Recreate OK
monolith DB breaking	expand/contract + flag, no big-bang

안티패턴
prod 100% immediate	canary·flag 없음
blue-green 무검증 switch	green smoke skip
flag 영구 on	코드 경로 rot
rollback 미연습	RTO 모름

8. 정리

• Rolling/Recreate — K8s Deployment 기본; readiness·maxUnavailable
• Blue-green — 전체 전환, 빠른 rollback, 2× cost
• Canary — 비율·지표 기반 promote; Ingress·Rollouts·mesh
• Feature flag — 릴리스와 배포 분리
• blast radius — canary·flag·shard로 노출 축소
• 다음 — IaC·GitOps (Terraform, Argo CD, PR 배포)

다음에 다룰 것

• Terraform plan/apply, state, drift
• Argo CD sync·reconcile, PR 기반 배포

---

해당 내용은 Production Kubernetes (Berkus & Box) 및 Kubernetes Documentation — Deployments, Workloads 를 참고했습니다.