배포 전략(Deployment Strategy)

 

배포 전략(Deployment Strategy)은 애플리케이션을 운영 환경(Production)으로 안전하고 효율적으로 배포하기 위해 사용하는 방법론입니다. 이는 다운타임을 줄이고, 버그나 실패 발생 시 빠르게 롤백할 수 있게 하며, 사용자 경험을 최대한 유지하기 위해 매우 중요합니다.

아래는 주요 배포 전략 7가지와 각각의 특징, 장단점을 정리한 내용입니다.

---

✅ 1. Recreate (완전 재배포)

• 기존 버전을 종료하고 새 버전을 시작함.
• 중단 후 시작 방식.

🔹장점

• 구조가 간단하고 구현이 쉬움.
• 리소스 소비가 적음.

🔸단점

• 다운타임이 발생함.
• 트래픽이 많은 서비스에는 적합하지 않음.

---

✅ 2. Rolling Update (롤링 업데이트)

• 구 버전을 하나씩 종료하고, 새 버전을 순차적으로 배포.
• 사용자는 점진적으로 새 버전을 접하게 됨.

🔹장점

• 다운타임이 거의 없음.
• 트래픽이 안정적으로 분산됨.

🔸단점

• 롤백이 어려움 (복잡한 상태 복구 필요).
• 중간 상태에서 오류가 발생하면 문제를 추적하기 어려움.

---

✅ 3. Blue-Green Deployment

• 두 개의 환경 (Blue와 Green)을 준비.
• 현재 운영 중인 Blue를 유지하면서 Green에 새 버전을 배포한 후, 트래픽을 Green으로 전환.

🔹장점

• 트래픽 스위칭만으로 롤백 가능 → 안정성과 신속성 확보.
• 다운타임 없음.

🔸단점

• 두 배의 인프라 자원 필요.
• 상태 데이터 동기화 이슈가 생길 수 있음.

---

✅ 4. Canary Deployment (카나리 배포)

• 전체 사용자 중 일부(예: 5~10%)에게만 새 버전을 배포.
• 문제가 없으면 점진적으로 대상 확대.

🔹장점

• 문제 탐지 및 대응이 빠름.
• 실사용자 기반 테스트 가능.

🔸단점

• 트래픽 분기 로직 필요 → 구현 복잡도 증가.
• 일부 사용자에게만 이슈 발생 시 고객 불만 발생 가능.

---

✅ 5. A/B Testing 배포

• 서로 다른 버전을 동시에 배포하고, 사용자 그룹을 나누어 각기 다른 버전을 경험하게 함.
• 주로 UX 실험이나 기능 성능 비교에 사용.

🔹장점

• 실험 기반의 제품 개선 가능.
• 데이터 기반 의사결정 가능.

🔸단점

• 사용자 그룹 분리 및 로깅 시스템 필요.
• 구현 및 분석 복잡도 높음.

---

✅ 6. Shadow Deployment (그림자 배포)

• 사용자 요청을 기존 버전 + 새 버전 모두에 전달하되, 실제 응답은 기존 버전이 처리.
• 새 버전의 성능을 실시간 트래픽에서 모니터링함.

🔹장점

• 실제 트래픽 기반 테스트 가능.
• 사용자에게 영향 없음.

🔸단점

• 리소스 사용량 증가.
• 로그 수집, 분석 시스템 필요.

---

✅ 7. Immutable Deployment (불변 배포)

• 기존 인스턴스를 전혀 수정하지 않고, 새 인스턴스를 생성하여 배포.
• 구버전은 삭제되고 새 버전이 배치됨.

🔹장점

• 상태 불일치 문제 제거.
• CI/CD 파이프라인에 적합.

🔸단점

• 인프라 리소스 증가.
• 모든 구성 요소의 완전 자동화가 전제됨.

---

🧠 어떤 전략을 써야 할까?

상황	추천 전략
소규모 서비스 / MVP	Recreate, Rolling
대규모 트래픽 / 안정성 중요	Blue-Green, Canary
기능 실험 필요	A/B Testing
실서비스에서 성능 테스트	Shadow
완전 자동화 환경	Immutable

 

 

✅ Kubernetes에서 지원하는 배포 전략

쿠버네티스는 기본적으로 Deployment 오브젝트를 통해 애플리케이션을 배포합니다. 여기서 설정하는 방식에 따라 롤링 업데이트와 Recreate 전략이 기본적으로 지원되며, 커스텀 컨트롤러나 오퍼레이터, 또는 서비스 메시와 함께 사용할 경우 카나리 배포나 블루-그린 배포도 가능합니다.

1. Rolling Update (기본값)

• spec.strategy.type: RollingUpdate
• 파드(Pod)를 순차적으로 교체.
• 새 파드가 올라오면 기존 파드를 하나씩 제거.
• 다운타임 없음.

strategy:
  type: RollingUpdate
  rollingUpdate:
    maxSurge: 1
    maxUnavailable: 1

2. Recreate

• 기존 파드를 모두 제거한 후 새 파드를 생성.
• 다운타임 발생 가능.

strategy:
  type: Recreate

3. Canary Deployment (간접 지원)

• 네이티브로는 지원하지 않음.
• 하지만 다음 도구를 활용하여 구현 가능:
  • Istio, Linkerd (서비스 메시)
  • Flagger (Canary controller for Kubernetes)
  • Argo Rollouts (Argo 프로젝트의 확장)

4. Blue-Green Deployment (간접 지원)

• Service를 통해 새 버전의 파드에 트래픽을 전환.
• 수동으로 제어하거나, Argo Rollouts 등으로 자동화 가능.

---

✅ Argo CD에서 지원하는 배포 전략

Argo CD 자체는 GitOps 방식의 **상태 동기화(Declarative Sync)**에 집중된 도구입니다. 하지만 다음과 같이 전략별로 배포를 제어할 수 있습니다:

1. Argo CD 기본 전략

• Git 저장소와 클러스터 상태를 비교하여 불일치 시 kubectl apply 또는 kustomize 방식으로 적용.
• Deployment 오브젝트에 설정된 전략(Rolling, Recreate 등)을 그대로 따름.

2. Argo Rollouts를 통한 고급 전략

Argo Rollouts는 Argo CD와 통합되어 고급 배포 전략을 지원합니다.

▶️ 지원 전략

전략	설명
Blue-Green	두 개의 ReplicaSet을 유지하고 서비스 라우팅으로 트래픽 전환
Canary	트래픽 비율 조절 (예: 10%, 30%, 50%, 100%)
Progressive Delivery	단계별 분석, 실험 기반
Analysis Phase	메트릭 기반 자동 중지 또는 자동 승격 (Prometheus, Kayenta 등과 연동)
Abort/Rollback	문제 발생 시 자동 중단 및 롤백

apiVersion: argoproj.io/v1alpha1
kind: Rollout
metadata:
  name: my-rollout
spec:
  strategy:
    canary:
      steps:
      - setWeight: 20
      - pause: { duration: 1m }
      - setWeight: 50
      - pause: { duration: 2m }
      - setWeight: 100

※ Argo CD UI에서도 Rollouts 상태를 시각적으로 확인 가능함.

---

🔄 요약

전략	Kubernetes	Argo CD (with Rollouts)
RollingUpdate	✅ 기본 지원	✅ 기본
Recreate	✅ 지원	✅ 지원
Canary	🔸 서비스 메시/Flagger 등 필요	✅ Argo Rollouts 필요
Blue-Green	🔸 직접 구현 필요	✅ Argo Rollouts 필요
A/B Testing	❌ 직접 구현 필요	🔸 실험적, 분석 포함 가능
Shadow	❌ 미지원	❌ 미지원
Immutable	🔸 도구 조합 필요	✅ GitOps 방식으로 유사 구현 가능

---

🏁 결론

• Kubernetes 기본만 사용할 경우 → Rolling 또는 Recreate가 중심.
• 고급 전략이 필요하다면 Argo Rollouts와 통합해야 함.
• 서비스 메시나 분석 도구(Prometheus, Grafana, Kayenta 등)와 함께 사용하면 자동화된 배포 분석 및 롤백이 가능해져 DevOps 효율성이 극대화됩니다.