NGINX Gateway Fabric 을 사용하여 다운타임 없이 애플리케이션을 업그레이드 하는 방법을 알려줍니다.

목차

1. 개요
2. 필수 조건
3. 롤링 배포 업그레이드
4. Blue-Green 배포
5. Canary 릴리스

1. 개요

NGINX Gateway Fabric은 애플리케이션을 중단 없이 업그레이드할 수 있도록 지원합니다. 업그레이드 방법을 이해하려면 애플리케이션 다운타임을 방지하는 데 도움이 되는 NGINX 기능인 Graceful 구성 리로드와 업스트림 서버 업데이트에 대해 숙지해야 합니다.

Graceful Configuration Reloads

관련된 Gateway API 또는 Kubernetes의 기본 리소스가 변경되면, NGINX Gateway Fabric 은 NGINX 구성을 다시 생성하여 업데이트합니다. 이후 새로운 구성을 적용하기 위해 NGINX 마스터 프로세스에 리로드 신호를 전송합니다.

이러한 작업을 리로드라고 하며, 이 과정에서 클라이언트 요청이 중단되지 않으므로 Graceful 리로드로 정의됩니다.

이 프로세스에 대한 자세한 내용은 NGINX 구성 문서에서 확인할 수 있습니다.

Upstream server updates

애플리케이션 업그레이드 과정에서 엔드포인트는 자주 변경됩니다. Kubernetes는 새로운 버전의 애플리케이션을 위한 파드를 생성하고 기존 파드를 제거하며, 이에 따라 해당 엔드포인트도 추가 및 삭제됩니다.

NGINX Gateway Fabric은 EndpointSlice를 감시하여 엔드포인트 변경 사항을 감지합니다.

NGINX 구성에서 서비스(service)는 업스트림(upstream)으로, 엔드포인트(endpoint)는 업스트림 서버(upstream server)로 표현됩니다.

가장 일반적인 두 가지 경우는 다음과 같습니다:

  • 엔드포인트 추가
    NGINX Gateway Fabric은 NGINX에 해당 엔드포인트에 대응하는 업스트림 서버를 추가한 후, NGINX를 리로드합니다. 이후 NGINX는 해당 엔드포인트로 트래픽을 프록시하기 시작합니다.
  • 엔드포인트 제거
    NGINX Gateway Fabric은 NGINX에서 해당 업스트림 서버를 제거한 후, NGINX를 리로드합니다. 이후 NGINX는 더 이상 해당 서버로 트래픽을 전달하지 않지만, 대기 중인 요청은 처리한 후 다른 엔드포인트로 전환합니다.

여러 개의 엔드포인트가 준비된 상태라면, 업그레이드 중에도 클라이언트는 다운타임을 경험하지 않습니다.

또한, Readiness Probe를 설정하는 것이 좋습니다. 이를 통해 파드는 트래픽을 받을 준비가 되었음을 보고할 수 있으며, NGINX Gateway Fabric은 준비되지 않은 엔드포인트를 추가하지 않습니다.

2. NGINX Gateway Fabric 필수 조건

  • 애플리케이션을 Deployment로 배포하였습니다.
  • 이 Deployment의 파드들은 특정 Service에 속해 있으며, Kubernetes는 각 파드에 대한 엔드포인트(endpoint)를 생성합니다.
  • 클라이언트가 접근할 수 있도록, 해당 Service를 참조하는 HTTPRoute 리소스를 사용하여 애플리케이션을 노출하였습니다.

예를 들어, 아래와 같은 라우팅 규칙을 사용하여 애플리케이션을 노출할 수 있습니다.

- matches:
    - path:
        type: PathPrefix
        value: /
  backendRefs:
    - name: my-app
      port: 80

기본적인 예제로 Cafe 예제를 참고할 수 있습니다.

다음 섹션에서는 다양한 업그레이드 방법을 다룹니다:

  • 롤링 배포 업그레이드(Rolling Deployment Upgrades)
  • 블루-그린 배포(Blue-Green Deployments)
  • 카나리 릴리스(Canary Releases)

3. 롤링 배포 업그레이드

롤링 배포 업그레이드를 시작하려면, 먼저 배포(Deployment)를 새 버전 태그를 사용하도록 업데이트합니다. 그 결과, Kubernetes는 이전 버전의 파드를 종료하고 새로운 파드를 생성합니다. 기본적으로 Kubernetes는 업그레이드 중에도 일정 수의 파드가 항상 사용 가능하도록 보장합니다.

이 업그레이드는 새로운 업스트림 서버(upstream servers)를 NGINX에 추가하고, 이전의 업스트림 서버는 제거합니다. 업그레이드 중에 파드(준비된 엔드포인트)의 수가 0에 도달하지 않으면, NGINX는 트래픽을 프록시할 수 있고, 따라서 다운타임을 방지할 수 있습니다.

이 방법은 HTTPRoute를 업데이트할 필요가 없습니다.

4. Blue-Green 배포

이 방법에서는 애플리케이션의 새 버전(파란색 버전)을 별도의 배포로 배포하고, 기존 버전(초록색 버전)은 계속 실행되며 클라이언트 트래픽을 처리합니다. 이후 트래픽을 초록색 버전에서 파란색 버전으로 전환합니다. 파란색 버전이 예상대로 작동하면 초록색 버전을 종료하고, 그렇지 않으면 트래픽을 다시 초록색 버전으로 전환합니다.

트래픽을 전환하는 방법에는 두 가지가 있습니다:

  1. 서비스 셀렉터 업데이트
    서비스 셀렉터를 업데이트하여 파란색 버전의 파드를 선택하도록 설정합니다. 이로 인해 NGINX Gateway Fabric은 초록색 업스트림 서버를 NGINX에서 제거하고 파란색 업스트림 서버를 추가합니다. 이 방법은 HTTPRoute를 업데이트할 필요가 없습니다.
  2. 별도의 서비스 생성
    파란색 버전용으로 별도의 서비스를 생성하고, HTTPRoute에서 백엔드 참조를 해당 서비스로 업데이트합니다. 이 방법도 이전 방법과 동일한 결과를 초래합니다.

5. Canary 릴리스

카나리 릴리스(Canary Releases)는 애플리케이션의 새 버전을 제어된 방식으로 일부 노드에 점진적으로 도입하고, 트래픽을 기존 버전과 새(카나리) 버전 간에 분배하는 방법입니다. 이를 통해 전체 배포 전에 새 릴리스의 성능과 신뢰성을 모니터링하고 테스트할 수 있으며, 문제를 식별하고 해결할 수 있어 전체 사용자에게 영향을 미치지 않습니다.

카나리 릴리스를 지원하려면, 같은 서비스 뒤에 두 개의 배포(Deployment)를 구현할 수 있습니다(자세한 내용은 Kubernetes 문서의 Canary 배포 참고). 그러나 이 방법은 구버전과 카나리 버전 간의 트래픽 분배를 정확하게 정의하기에는 한계가 있습니다. 예를 들어, 구버전 파드 4개와 카나리 버전 파드 1개로 나누는 방식으로 영향을 미칠 수 있지만, NGINX Gateway Fabric은 random two least_conn 부하 분산 방법을 사용하므로 (예: 80/20 비율) 정확한 트래픽 분배를 보장하지 않습니다.

더 유연하고 정확한 방식으로 카나리 릴리스를 구현하려면 HTTPRoute에서 트래픽 분배를 구성하는 방법이 있습니다. 이 경우, 새 버전에는 별도의 배포와 서비스가 필요합니다. 예를 들어, 아래 규칙에 따라 NGINX는 95%의 트래픽을 구버전 엔드포인트로, 5%의 트래픽만 새 버전 엔드포인트로 프록시하게 됩니다.

- matches:
    - path:
        type: PathPrefix
        value: /
  backendRefs:
    - name: my-app-old
      port: 80
      weight: 95
    - name: my-app-new
      port: 80
      weight: 5

같은 클라이언트로부터 오는 모든 요청이 반드시 동일한 백엔드로 전달되는 것은 아닙니다. NGINX는 각 요청을 독립적으로 백엔드 참조들 간에 분배합니다.

규칙을 업데이트함으로써 새 버전이 받는 트래픽의 비율을 더 늘릴 수 있으며, 최종적으로 새 버전으로 완전히 전환할 수 있습니다.

- matches:
    - path:
        type: PathPrefix
        value: /
  backendRefs:
    - name: my-app-old
      port: 80
      weight: 0
    - name: my-app-new
      port: 80
      weight: 1

repository에서 트래픽 분배 예제를 확인하세요.