RollingUpdate vs Recreate 각각의 장단점 알아보기

이번 포스트에서는 쿠버네티스의 두 가지 배포 전략, RollingUpdate 전략과 Recreate 전략에 대해 살펴봅니다. 각각의 장단점을 분석하고, 어떤 상황에 어떤 전략을 선택하면 좋은지에 대해 논의합니다.

쿠버네티스에서 애플리케이션을 배포할 때, 두 가지 주요 전략을 사용할 수 있습니다. 첫 번째는 RollingUpdate 이며, 이는 새로운 버전의 파드를 점진적으로 배포하는 방식입니다. 기존의 파드는 서서히 종료되고, 새로운 파드는 차례로 추가됩니다. 두 번째는 Recreate 방식으로, 기존의 파드를 모두 종료한 후 새로운 파드를 생성하는 방법입니다. 이 두 가지 전략은 각각의 특징이 있으며, 상황에 따라 적합한 방법을 선택하는 것이 중요합니다.

목차

1. RollingUpdate 장단점
2. Recreate 장단점
3. RollingUpdate vs Recreate
4. RollingUpdate 사용 사례
5. Recreate 사용 사례
6. 결론

1. RollingUpdate 장단점

장점
RollingUpdate 전략의 가장 큰 장점은 무중단 배포입니다. 새 버전의 애플리케이션이 실행되는 동안 기존 버전도 계속 운영되므로 사용자에게 서비스 중단을 최소화할 수 있습니다. 또한, 이 방식은 점진적으로 변경사항을 배포하기 때문에, 문제가 발생했을 때 빠르게 이전 버전으로 되돌릴 수 있는 유연성을 제공합니다.

단점
하지만, RollingUpdate 전략은 파드 간의 의존성이 높은 경우, 예상치 못한 문제가 발생할 수 있습니다. 이를 해결하기 위해 더 많은 테스트가 필합니다. 또한, 새로운 파드를 추가하여 동시에 여러 버전을 실행하기 때문에, 더 많은 리소스를 소모할 수 있습니다.

자세한 사항은 공식 문서를 확인하세요.

2. Recreate 장단점

장점
Recreate 방식은 간단한 구조로 인해 구현이 용이합니다. 모든 기존 파드를 먼저 종료한 후 새로운 파드를 배포하기 때문에, 두 버전 간의 호환성 문제가 발생하지 않습니다. 이 방식은 서비스가 일시적으로 중단되지만, 안정적인 배포를 진행할 수 있습니다. 특히, 스테이트리스(stateless) 애플리케이션에서 효과적입니다.

단점
Recreate 방식의 가장 큰 단점은 배포 중에 서비스가 완전히 중단 된다는 점입니다. 이는 사용자 경험에 부정적인 영향을 미칠 수 있으며, 특히 실시간 서비스에서는 치명적인 문제가 될 수 있습니다. 또한 대규모 서비스의 경우도 마찬가지로 모든 파드를 동시에 종료하는 것은 매우 위험할 수 있으며, 사용자에게 큰 불편을 초래할 수 있습니다.

자세한 사항은 공식 문서를 확인하세요.

3. RollingUpdate vs Recreate

RollingUpdate 전략과 Recreate 전략은 각각의 장단점이 있기 때문에 적절하게 상황에 맞는 배포 전략을 선택해야 합니다.

RollingUpdate 전략은 일반적으로 안정성과 가용성이 중요한 상황에서 선택하는 것이 좋습니다. 예를 들어, 고객에게 지속적인 서비스를 제공해야 하는 웹 애플리케이션이나 대규모 시스템에서는 RollingUpdate 가 적합합니다.

Recreate 전략은 빠른 배포가 필요하거나 애플리케이션의 버전 간 호환성이 보장되는 경우, 즉, 시스템 다운타임이 큰 문제가 되지 않는 경우에 적합합니다.

4. RollingUpdate 사용 사례

기본적으로 쿠버네티스에서는 Deployment의 기본 업데이트 전략을 RollingUpdate 방식을 사용하고 있습니다. 기본적인 설정으로 MaxUnavailable: 25%, maxSurge: 25%로 설정되어 있습니다.

• maxUnavailable – 업데이트 프로세스 중에 사용할 수 없는 최대 파드의 수를 지정합니다. 값으로는 숫자, 비율이 될 수 있습니다.
• maxSurge – 생성할 수 있는 최대 파드의 수를 지정합니다. 값으로는 숫자, 비율이 될 수 있습니다.

RollingUpdate 전략에 대한 설정 값을 변경하여 간단한 애플리케이션을 배포합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deploy
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: rolling-update
  template:
    metadata:
      labels:
        app: rolling-update
    spec:
      containers:
      - name: nginxstore
        image: nginx           # 기존 이미지
        imagePullPolicy: Never
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: rolling-update-service
spec:
  selector:
    app: rolling-update
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

위의 deployment 리소스에서 사용된 이미지는 기본 NGINX 페이지이며 아래와 같습니다.

이 예시는 기존 웹 애플리케이션에서 사용한 이미지가 아래와 같이 업데이트되어 deployment 리소스를 수정한다는 가정입니다.

해당 페이지에 대해 변경 사항이 발생하여 업데이트를 해야 할 때, RollingUpdate 배포 전략을 사용하여 이미지 업데이트를 진행합니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: rolling-update-deploy
spec:
  replicas: 2
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: rolling-update
  template:
    metadata:
      labels:
        app: rolling-update
    spec:
      containers:
      - name: nginxstore
        #image: nginx           # 기존 이미지
        image: nginxstore:1     # 신규 이미지
        imagePullPolicy: Never
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: rolling-update-service
spec:
  selector:
    app: rolling-update
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

deployment를 수정한 뒤 수정된 deployment 리소스를 배포하면 아래와 같이 신규 파드가 점진적으로 배포되며, 기존 파드가 하나씩 삭제되는 것을 확인할 수 있습니다.

5. Recreate 사용 사례

Recreate 전략은 기존 파드를 모두 종료한 후 새로운 파드를 생성하는 방식이기 때문에, 주로 단일 인스턴스 애플리케이션 또는 서비스 중단이 허용되는 비즈니스 로직을 다룰 때 사용됩니다.

(※ Recreate 전략을 사용할 경우, 서비스 중단이 발생해도 문제가 없을 때에 사용해야 합니다.)

이번 예시에서도 마찬가지로, 기본 NGINX 이미지를 커스텀된 이미지로 변경하는 상황으로 가정합니다.

Recreate 전략에 대한 deployment 리소스 구성은 아래와 같습니다.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: recreate-deploy
spec:
  replicas: 2
  strategy:
    type: Recreate
  selector:
    matchLabels:
      app: recreate
  template:
    metadata:
      labels:
        app: recreate
    spec:
      containers:
      - name: nginxstore
        image: nginx
        imagePullPolicy: Never
        ports:
        - containerPort: 80

---
apiVersion: v1
kind: Service
metadata:
  name: recreate-service
spec:
  selector:
    app: recreate
  ports:
    - protocol: TCP
      port: 80
      targetPort: 80
  type: ClusterIP

Recreate 배포 전략은 동작이 단순하기 때문에 구성이 어렵지 않습니다. .spec.strategy.type==Recreate 을 추가하면 됩니다.

Recreate 배포 전략을 사용한 deployment 리소스를 배포한 뒤, 수정 사항이 일어났을 때를 확인합니다.

실시간 파드의 상황을 보면 기존에 있던 두 개의 파드가 완전히 종료된 후, 새로운 파드가 생성되는 것을 확인할 수 있습니다.

6. 결론

위에서 다룬 내용을 간단히 정리하자면 RollingUpdate 전략과 Recreate 전략은 완전히 다른 배포 전략입니다.

RollingUpdate 전략의 경우 기존 파드를 점진적으로 교체하여 애플리케이션을 업데이트하는 방식입니다. 이 과정에서 새로운 버전의 파드가 생성되고, 기존 파드가 점차 종료됨으로써 서비스 중단 없이 업데이트를 할 수 있습니다.

Recreate 전략의 경우 현재 실행 중인 모든 파드를 종료하고 새로운 파드를 생성하여 시작합니다. 그렇기 때문에 서비스 중단이 발생하게 되지만, 한 번에 새로운 버전으로 전환되므로, 사용자에게 동일한 버전을 제공할 수 있습니다.

Kubernetes 환경의 NGINX Plus Ingress Controller를 직접 사용해 보시려면 NGINX STORE에 연락하여 논의하십시오.