🔧
DevOps
Deployment
배포
애플리케이션을 운영 환경에 릴리스하는 과정. 자동화가 핵심.
상세 설명
Deployment는 개발된 애플리케이션을 실제 사용자가 접근할 수 있는 운영 환경에 배포하는 전체 과정을 말합니다. 단순히 코드를 서버에 올리는 것을 넘어서, 빌드, 테스트, 스테이징, 프로덕션 배포까지의 파이프라인 전체를 포함합니다.
현대적인 배포 전략에는 Blue-Green 배포, Canary 배포, Rolling 배포 등이 있습니다. Blue-Green은 두 개의 동일한 환경을 유지하며 트래픽을 전환하고, Canary는 일부 사용자에게만 먼저 배포하여 문제를 조기에 발견합니다. Rolling은 점진적으로 인스턴스를 교체하는 방식입니다.
배포 자동화는 DevOps의 핵심입니다. CI/CD 파이프라인을 통해 코드 커밋부터 프로덕션 배포까지 자동화하면 휴먼 에러를 줄이고 배포 빈도를 높일 수 있습니다. GitHub Actions, Jenkins, ArgoCD 같은 도구들이 널리 사용됩니다.
무중단 배포(Zero-downtime deployment)는 서비스 가용성을 유지하면서 배포하는 것으로, 사용자 경험에 직접적인 영향을 미칩니다. Kubernetes의 Deployment 리소스는 이러한 무중단 배포를 기본으로 지원하며, readinessProbe와 livenessProbe로 헬스체크를 수행합니다.
코드 예제
# Kubernetes Deployment with Rolling Update
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-server
labels:
app: api-server
spec:
replicas: 3
strategy:
type: RollingUpdate
rollingUpdate:
maxSurge: 1 # 롤링 업데이트 중 추가 Pod 수
maxUnavailable: 0 # 무중단 배포 보장
selector:
matchLabels:
app: api-server
template:
metadata:
labels:
app: api-server
spec:
containers:
- name: api
image: myapp:v2.0.0
ports:
- containerPort: 8080
readinessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 5
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: 8080
initialDelaySeconds: 15
periodSeconds: 20
resources:
requests:
memory: "256Mi"
cpu: "250m"
limits:
memory: "512Mi"
cpu: "500m"실무에서 이렇게 말해요
시니어: "이번 릴리스부터 Canary 배포로 바꿔보자. 먼저 5% 트래픽만 새 버전으로 보내고 모니터링 해보자."
주니어: "그러면 ArgoCD에서 Analysis 템플릿 설정하면 되나요?"
시니어: "맞아, Prometheus 메트릭 기반으로 에러율 1% 넘으면 자동 롤백되게 해두자."
면접관: "Blue-Green 배포와 Canary 배포의 차이점과 각각 언제 사용하면 좋은지 설명해주세요."
지원자: "Blue-Green은 전체 트래픽을 한 번에 전환해서 빠른 롤백이 가능하고, Canary는 점진적으로 트래픽을 늘려 리스크를 줄입니다. 중요한 변경사항은 Canary로, 긴급 핫픽스는 Blue-Green으로 배포합니다."
리뷰어: "maxUnavailable: 1로 설정하면 롤링 업데이트 중 서비스 저하 가능성 있어요. 무중단이 중요하면 0으로 바꾸세요."
개발자: "네, 그리고 readinessProbe initialDelaySeconds도 앱 기동 시간 고려해서 늘려야겠네요."
주의사항
- readinessProbe 없이 배포하면 아직 준비 안 된 Pod로 트래픽이 가서 503 에러 발생
- DB 마이그레이션과 배포를 동시에 하면 롤백이 어려움 - 마이그레이션은 backward compatible하게
- 리소스 limits 없이 배포하면 하나의 Pod가 노드 전체 리소스를 점유할 수 있음
- 배포 전 staging 환경에서 충분히 테스트하고, 프로덕션에는 점진적 롤아웃 적용