[DEVOPS-005][기초] 안전하게 배포하고 문제 생기면 되돌리기 > IT 기술 공유

• 목록

[이번 수업]

테스트를 통과한 프로그램을 실제 서비스에 안전하게 전달하는 CD와 대표 배포 전략을 배웁니다. 새 버전의 중단·복귀 기준도 로컬 Python 예제로 연습합니다.

[선수지식]

DEVOPS-001~004의 협업, 컨테이너 이미지, 여러 서비스 실행, CI 빌드·테스트 개념을 알고 있으면 좋습니다. Python 한 파일을 실행할 수 있으면 충분합니다.

[학습목표]

1. 지속적 전달과 지속적 배포의 차이를 설명한다.
2. 재생성·롤링·블루그린·카나리 전략을 비교한다.
3. 지표로 승격 또는 롤백을 결정하는 배포 게이트를 만든다.

[핵심개념]

CD는 문맥에 따라 지속적 전달(Continuous Delivery)과 지속적 배포(Continuous Deployment)를 뜻합니다. 지속적 전달은 빌드·테스트를 통과한 아티팩트, 즉 배포 결과물을 언제든 운영에 내보낼 수 있게 유지하되 최종 승인을 사람이 할 수 있습니다. 지속적 배포는 정해진 자동 검증을 통과하면 운영 반영까지 자동으로 진행합니다.

재생성(Recreate)은 기존 인스턴스를 모두 내린 뒤 새 버전을 띄워 단순하지만 중단 시간이 생깁니다. 롤링(Rolling)은 기존 인스턴스를 조금씩 새것으로 바꿉니다. 동시에 추가할 수 있는 수와 unavailable, 즉 사용할 수 없어도 되는 수를 제한해 가용성과 자원 사용량의 균형을 잡습니다.

블루그린(Blue-Green)은 기존·신규 환경을 함께 준비하고 검증한 뒤 트래픽 대상을 바꿉니다. 복귀가 빠르지만 두 환경의 자원이 필요합니다. 카나리(Canary)는 트래픽의 작은 비율만 새 버전에 보내 지표를 본 뒤 10%, 25%, 50%, 100%처럼 늘립니다. 위험 노출은 작지만 정확한 트래픽 분배와 자동 분석이 필요합니다.

롤백은 이전 코드를 다시 실행하는 것만이 아닙니다. 이전 이미지 식별자와 설정을 보관해 같은 상태를 재현해야 합니다. 데이터베이스는 이미 저장된 데이터를 되돌리기 어려우므로 새·구 버전이 함께 작동하는 호환 변경을 먼저 적용하고 나중에 낡은 필드를 제거합니다. 되돌릴 수 없는 변경은 수정 버전을 내는 롤포워드가 더 안전할 수 있습니다.

배포 전에 성공·중단 조건을 수치로 정합니다. 준비 상태, 오류율, 응답 지연, 핵심 기능 성공률을 일정 시간 관찰하고 안정 버전과 후보 버전을 나눠 비교합니다. 롤백 후에도 이전 버전의 상태와 데이터 호환성을 다시 확인해야 배포가 끝납니다.

[따라하기]

아래 내용을 release_gate.py로 저장합니다. 외부 시스템을 변경하지 않고 후보 지표만 판정합니다.

```python
candidate = {"error_rate": 2.1, "p95_ms": 220}
limits = {"error_rate": 1.0, "p95_ms": 250}

failed = [
    name for name, value in candidate.items()
    if value > limits[name]
]

decision = "ROLLBACK" if failed else "PROMOTE"
print(f"failed={failed}")
print(f"decision={decision}")
```

macOS·Linux는 `python3 release_gate.py`, Windows는 `py release_gate.py`를 실행합니다. py가 없다면 `python release_gate.py`를 사용하세요. 오류율이 한도를 넘으므로 예상 결과는 다음과 같습니다.

```text
failed=['error_rate']
decision=ROLLBACK
```

error_rate를 0.5로 바꾸면 decision=PROMOTE가 나옵니다. 실제 환경에서는 한 번의 측정이 아니라 충분한 표본과 관찰 시간을 사용합니다.

[흔한 실수]

- 최신 태그처럼 내용이 바뀌는 이름으로 배포해 운영 버전을 재현하지 못합니다. 변경되지 않는 버전이나 다이제스트를 기록하세요.
- 상태 점검 직후 성공으로 판단해 지연된 오류를 놓칩니다. 전략에 맞는 관찰 구간을 둡니다.
- 애플리케이션만 되돌리고 데이터베이스·설정·메시지 형식의 호환성을 확인하지 않습니다.

[보안 주의]

빌드와 배포 권한을 분리하고 운영 배포는 보호된 승인과 감사 로그를 거치게 하세요. CI에서 만든 검증된 동일 아티팩트를 승격하고 출처와 무결성을 확인하며 배포 토큰과 비밀값을 저장소·로그·명령 인자에 넣지 말고 짧은 수명의 최소 권한 자격을 사용합니다. 롤백도 운영 변경이므로 본인 소유 또는 허가받은 환경에서만 실행하고, 실습에는 실제 자격증명을 사용하지 마세요.

[직접 해볼 과제]

1. candidate의 p95_ms를 300으로 바꿔 실패 항목이 두 개가 되는지 확인하세요.
2. 블루그린과 카나리 중 하나를 골라 전환 단계, 확인 지표, 롤백 조건을 다섯 줄 체크리스트로 작성하세요.

[확인문제]

1. 지속적 전달과 지속적 배포는 운영 반영 단계에서 어떻게 다른가요?
2. 롤링·블루그린·카나리 배포는 트래픽 전환 방식이 어떻게 다른가요?
3. 데이터베이스 변경이 포함된 배포에서 코드만 되돌리면 위험한 이유는 무엇인가요?

[다음 학습]

DEVOPS-006에서는 Kubernetes의 Pod, Deployment, Service 같은 핵심 객체로 컨테이너 애플리케이션의 원하는 상태를 선언하는 방법을 배웁니다.

[공식 참고 자료]

- NIST SP 800-204C DevSecOps 구현: https://csrc.nist.gov/pubs/sp/800/204/c/final
- NIST SP 800-204D CI/CD 공급망 보안: https://csrc.nist.gov/pubs/sp/800/204/d/final
- Kubernetes 롤링 업데이트·롤백: https://kubernetes.io/docs/tasks/run-application/update-deployment-rolling/
- Argo Rollouts 배포 전략 개념: https://argo-rollouts.readthedocs.io/en/stable/concepts/