deploy가 실패하면 rollback을 어떻게 처리하나요?

Question

Accepted Answer

deploy가 문제를 일으키면, 사용자에 대한 영향을 최소화하기 위해 동작하는 상태로 빠르게 **rollback**해야 합니다. 효과적인 rollback 전략 — 그리고 모니터링, 자동 rollback, forward-fix의 관련 실천 — 은 안정적인 deploy에 필수적입니다.

## 왜 rollback 능력이 중요한가

```text
deploy는 때때로 테스트를 통과한 문제(버그, 오류, 성능 문제)를 일으킴.
production에서 그런 일이 생기면:
  → 동작하는 상태를 빠르게 복원해야 함 (사용자 영향/다운타임 최소화)
  → 빠르고 안정적인 rollback이 필수 — 나쁜 deploy를 빠르게 되돌릴 수 있어야 함
→ "어떻게 rollback하는가?"는 필요하기 전에 답해져야 함.
```

## rollback 접근법

```text
✓ 이전 버전 재deploy — 마지막 known-good artifact/버전을 deploy
  (버전 관리된 artifact가 이를 쉽게 함: v1.2.3을 되돌리려면 v1.2.2 deploy)
✓ BLUE-GREEN → 트래픽을 이전 환경으로 다시 전환하여 즉각 rollback
✓ CANARY → canary가 문제를 보이면, rollout 중지 (소수의 사용자만 영향)
✓ 데이터베이스 변경 → 더 까다로움 (하위 호환 migration 필요; 아래 참조)
✓ Feature FLAG → 재deploy 없이 문제 있는 기능 비활성화 (동작의 즉각 "rollback")
```

## 중요한 고려 사항

```text
⚠️ 데이터베이스 migration → migration이 파괴적/비호환적이면 rollback이 어려움:
  → 하위 호환 migration 사용 (이전 코드가 새 스키마와 동작하도록)
  → 스키마 변경을 코드에서 분리; expand-then-contract 패턴
✓ 모니터링 → 문제를 빠르게 감지 (rollback해야 함을 알도록) — 오류/지표 알림
✓ 자동 rollback → 일부 pipeline은 실패한 health check 시 자동 rollback
✓ FORWARD FIX → 때로는 forward fix(빠른 패치)가 rollback보다 나음
✓ rollback 연습/테스트 → 필요할 때 실제로 동작하는지 확인
```

## 왜 중요한가

rollback 전략을 이해하는 것이 중요한 이유는, **deploy가 때때로 실패하고 빠르게 복구할 수 있는 것이 안정성에 필수적**이므로 production deploy에 가치 있는 실용 지식이기 때문입니다.

좋은 테스트가 있어도 deploy는 가끔 production에서 문제를 일으키며, 그럴 때 **동작하는 상태를 빠르게 복원**(사용자 영향과 다운타임 최소화)하는 것이 중요합니다 — rollback 능력을 안정적인 deploy의 핵심 부분으로 만들며, **필요하기 전에** 계획되어야 합니다.

**rollback 접근법** — 이전 버전 재deploy(버전 관리된 artifact로 쉬워짐), **blue-green**의 즉각 rollback(트래픽을 다시 전환), **canary** rollout 중지(영향 제한), 재deploy 없이 문제 있는 기능을 비활성화하기 위한 **feature flag** 사용 — 을 이해하는 것은 다양한 deploy 전략에 맞는 옵션을 제공합니다.

**중요한 고려 사항**을 이해하는 것은 성숙한 deploy 실천을 반영합니다: **데이터베이스 migration은 rollback을 어렵게** 만들므로(파괴적이거나 비호환적인 스키마 변경은 단순히 되돌릴 수 없음), **하위 호환 migration**(이전 코드가 새 스키마와 동작하도록)과 expand-then-contract 같은 패턴을 사용하는 것이 필수입니다 — 진정으로 까다롭고 중요한 실제 관심사입니다.

**모니터링**(rollback해야 함을 알도록 문제를 빠르게 감지)의 역할, **자동 rollback**(실패한 health check 시), **forward-fix** 옵션(때로는 빠른 패치가 rollback보다 나음), **rollback 테스트**의 중요성(필요할 때 동작하는지 확인)을 이해하는 것은 deploy 복구에 대한 포괄적인 사고를 반영합니다.

deploy가 실패할 수 있고 빠른 복구가 안정성에 필수적이며(사용자 영향 최소화), rollback 접근법, 데이터베이스 migration 과제, 지원 실천(모니터링, 자동화, forward-fix)을 이해하는 것이 나쁜 deploy로부터 효과적으로 복구하는 것을 가능하게 하므로, rollback 전략을 이해하는 것은 안정적인 production deploy에 가치 있고 실용적으로 중요한 지식입니다 — deploy 안전성의 중요한 측면이자, 좋은 CI/CD에서도 발생하는 불가피한 실패를 처리하는 운영 성숙도를 반영합니다.