[Kubernetes] Deployment 배포 전략 종류

Deployment 배포 전략 종류

쿠버네티스(Kubernetes)에서 Deployment 객체를 사용하여 애플리케이션을 배포할 때, 원하는 방식에 따라 여러 가지 배포 전략(Deployment Strategy)을 적용할 수 있음.

기본적으로 쿠버네티스 Deployment에는 크게 두 가지 전략이 내장되어 있음.

이를 확장하거나 변형해서 다양한 배포 패턴을 구현할 수 있음.

 

RollingUpdate 전략 - 개요

RollingUpdate 전략은 기존 버전의 파드를 점진적으로 종료하고, 새 버전의 파드를 점진적으로 생성하면서 트래픽 중단을 최소화하는 전략임.

이 방식은 한 번에 하나 혹은 여러 개의 파드를 새 버전으로 교체해나가기 때문에, 애플리케이션 다운타임을 최소화하고 점진적(Gradual) 배포가 가능함.

 

RollingUpdate 전략 - 주요 설정 항목

1. spec.strategy.type

RollingUpdate

 

2. spec.strategy.rollingUpdate.maxUnavailable

업데이트 과정에서 불가능(Unavailable)해질 수 있는 파드의 최대 개수 또는 비율

 

3. spec.strategy.rollingUpdate.maxSurge

동시에 추가로 생성할 수 있는 파드의 최대 개수 또는 비율

 

RollingUpdate 전략 - 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 2
      maxSurge: 3
  template:
    ...

 

1. maxUnavailable

2로 설정하여, 업데이트 과정에서 최대 2개의 파드가 동시에 비활성화(Unavailable) 상태일 수 있음.

 

2. maxSurge

3로 설정하면, 새 버전을 배포하는 도중 기존 파드 수(replica)보다 최대 3개 더 많은 파드를 일시적으로 생성할 수 있음.

 

RollingUpdate 전략 - 장점

1. 무중단 배포(또는 최소 중단 배포)

트래픽을 끊지 않고 점진적으로 배포 가능

 

2. 탄력적인 리소스 사용

일시적으로 추가 파드를 생성하여 서비스 여유분을 확보

 

RollingUpdate 전략 - 단점

1. 배포 속도가 상대적으로 느릴 수 있음(점진적으로 교체)

2. 모든 파드가 동시에 업데이트되는 것이 아니므로, 특정 시점에는 구 버전과 신 버전이 혼재할 가능성이 있음

 

Recreate 전략 - 개요

Recreate 전략은 기존에 실행 중인 모든 파드를 한 번에 종료하고, 새 버전의 파드를 그 후에 새롭게 생성하는 방식임.

다운타임이 발생하더라도 배포 과정을 단순화하고, 파드 간 충돌 또는 구버전과 신버전의 동시 혼재를 피하고 싶을 때 사용할 수 있음.

 

Recreate 전략 - 주요 설정 항목

1. spec.strategy.type

Recreate

 

2. spec.strategy.rollingUpdate는 Recreate 전략에서는 적용되지 않음

 

Recreate 전략 - 예시

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: Recreate
  template:
    ...

 

Recreate 전략 - 장점

배포 과정이 매우 단순함

이전 버전과 새로운 버전이 겹치는 구간이 없으므로, 버전 충돌 이슈가 없음

 

Recreate 전략 - 단점

구 버전 파드가 모두 종료된 뒤에 새 버전이 올라오기 때문에, 업데이트 과정에서 서비스가 잠시 중단(다운타임)됨

다운타임이 허용되지 않는 프로덕션 환경에서는 선호되지 않을 수 있음

 

그 외 확장된 배포 방식

쿠버네티스가 기본적으로 제공하는 Deployment 전략은 RollingUpdate와 Recreate 두 가지이지만, 실제 운영 환경에서는 Blue/Green, Canary, A/B 테스트 등 다양한 시나리오를 적용할 때가 많음.

이들은 Deployment 자체의 배포 전략을 활용하거나, 이외의 오브젝트(Service, Ingress, Istio, Argo Rollouts 등)와 연계해 구현할 수 있음.

 

그 외 확장된 배포 방식 - Blue/Green Deployment

Blue 환경과 Green 환경 두 개의 독립된 환경(Deployment)을 운영함.

새 버전을 Green 환경에 먼저 배포하여 충분히 테스트를 진행함.

모든 테스트가 통과되면 서비스 트래픽을 Blue에서 Green으로 스위칭함.

Service 라우팅, Ingress 라우팅 등을 전환함.

스위칭에 성공하면 Blue 환경을 제거(또는 유지)함.

 

1. 장점

완벽히 분리된 환경에서 신 버전을 미리 확인할 수 있어 안정성 확보가 용이

트래픽 전환 순간에만 서비스가 변화하기 때문에 예측이 쉬움

 

2. 단점

두 개의 환경(리소스)을 동시에 유지해야 하므로 인프라 비용 증가

전환 시점에 따라 짧은 트래픽 지연이나 스위치 이슈가 발생할 수 있음

 

그 외 확장된 배포 방식 - Canary Deployment

신규 버전을 배포할 때 전체 트래픽 중 일부(소량)만 먼저 새 버전으로 라우팅함.

새 버전의 안정성이 확인되면 할당되는 트래픽 비율을 점진적으로 늘림.

모든 점검을 통과하면 최종적으로 전체 트래픽을 신규 버전에 연결함.

 

1. 방법

Service 라벨 셀렉터 분할: 버전별로 Deployment를 따로 구성하고, 각각 다른 셀렉터를 사용한 뒤, Service에서 두 Deployment로 트래픽을 분할할 수 있도록 구성

Istio 등 서비스 메시 사용: 라우팅 규칙(가중치)를 제어해 소량 트래픽을 특정 버전(Subset)으로 보낼 수 있음

Argo Rollouts: 쿠버네티스 원천 객체(Deployment)에 직접 Canary, Blue/Green 등의 전략을 추가로 지원

 

2. 장점

실제 사용자 트래픽으로 새 버전을 검증하기 때문에, QA로 발견하기 어려운 문제를 빠르게 찾을 수 있음

신 버전이 문제가 생길 경우 빠르게 롤백 가능

 

3. 단점

트래픽 라우팅 조정이 필요하므로, 인프라나 도구(서비스 메시, Ingress Controller 등)의 지원이 필요

모니터링 및 알림 체계가 갖춰져 있어야, 문제 발생 시 신속하게 대응 가능

 

그 외 확장된 배포 방식 - A/B Testing Deployment

A/B 테스트는 Canary와 유사하지만, 서로 다른 버전을 대상으로 유저 피드백(행동 양상, 전환율 등)을 수집해 비교·분석하는 데 목적이 있음.

A/B 테스트에서는 단순히 안정성을 보는 것이 아니라, 어떤 버전이 사용자의 반응이 더 좋은지(비즈니스 성능, UI/UX 개선도 등)를 시험하기 위해 트래픽을 분할함.

쿠키 기반 라우팅, 해시 기반 라우팅 등 좀 더 고도화된 라우팅 전략이나 마케팅·분석 툴과 연동이 필요한 경우가 많음.

 

롤백과 배포 이력

1. kubectl 명령어

kubectl rollout undo deployment/my-app

kubectl rollout history deployment/my-app

 

2. Deployment Revision History

spec.revisionHistoryLimit 값을 통해 저장할 히스토리 개수를 제한할 수 있음.

이를 통해 특정 이전 버전으로 쉽게 롤백할 수 있음.

RollingUpdate를 사용할 경우, 배포 실패 시 자동으로 롤백하는 옵션(spec.progressDeadlineSeconds)도 고려할 수 있음.

 

요약

1. RollingUpdate

기본 설정으로, 점진적 교체로 다운타임을 최소화. 대부분의 서비스에 권장되며, maxUnavailable와 maxSurge 등 파인 튜닝이 가능.

 

2. Recreate

모든 파드를 종료 후 새 버전을 생성. 다운타임이 발생하지만, 간단하고 버전 간 혼재를 피해야 할 때 효과적.

 

3. Blue/Green

완전히 분리된 환경에서 새로운 버전을 준비 후 트래픽 스위치. 인프라 비용이 더 들지만 높은 안정성.

 

4. Canary

트래픽 일부만 새 버전에 유입하여 점진적 모니터링. 확장성 있고 리스크가 낮은 배포가 가능하지만, 라우팅 설정이 필요.

 

5. A/B Testing

Canary와 비슷하지만, 두 버전에 대한 사용자 행동 분석이 목적. 라우팅/분석 도구가 필수적.

 

배포 전략은 서비스의 특성, 다운타임 허용 여부, 리소스 여유도, 운영 인프라 성숙도 등에 따라 결정됨.

대규모 트래픽 환경에서는 무중단 배포(Zero-Downtime)가 거의 필수적임.

모니터링과 자동 롤백 메커니즘을 철저히 갖추는 것이 중요함.

또한, Istio나 Argo Rollouts 같은 추가 도구를 사용하면 Canary, Blue/Green, Progressive Delivery 등 복잡한 시나리오도 효율적으로 구현할 수 있음.

결국, “최적의 배포 전략”은 서비스 안정성, 변경 빈도, 리소스, 조직 문화 등 다양한 요인을 종합적으로 고려해 결정해야 함.