NGINX Plus 로 백엔드 업그레이드, 1부 개요

이 포스트에서는 NGINX Plus 를 사용하여 가동 중지 시간 없이 백엔드 업그레이드 하는 방법에 대한 개요를 나타냅니다.

프로덕션 환경에서 백엔드 서버를 업그레이드하는 것은 개별 서버를 처리하든 새로운 서버 세트로 이동하여 애플리케이션을 업그레이드하든 관계없이 운영 또는 DevOps팀에게 어려운 일이 될 수 있습니다. Upstream 서버를 NGINX Plus 뒤에 배치하면 업그레이드 프로세스를 훨씬 더 관리하기 쉽게 만드는 동시에 다운타임을 제거하거나 크게 줄일 수 있습니다.

[참고 – 이 포스트는 원래 사용되었던 Upstream Conf 모듈을 대체하여 Upstream 그룹의 동적 구성에 NGINX Plus API를 사용하도록 업데이트되었습니다.]

총 세 파트로 구성된 포스트 시리즈에서는 NGINX Plus에 중점을 둘 것입니다. NGINX Plus는 NGINX Open Source의 기능을 능가하는 다양한 기능을 제공하며 다운타임 없이 업그레이드를 위한 보다 포괄적이고 제어 가능한 솔루션입니다. 이 첫 번째 기사에서는 백엔드 업그레이드에 사용할 수 있는 두 가지 NGINX Plus 기능(NGINX Plus API 및 상태 확인)에 대해 자세히 설명하고 이를 NGINX Open Source로 업그레이드하는 것과 비교합니다.

관련 문서에서는 두 가지 업그레이드 클래스에 대한 방법을 사용하는 방법을 설명합니다.

목차

1. NGINX Plus에서 업그레이드 방법 선택
2. NGINX Open Source로 업그레이드
3. NGINX Plus 업그레이드 방법 개요
3-1. NGINX Plus API로 업그레이드 하기
3-2. Application Health Checks로 업그레이드
4. 결론

1. NGINX Plus에서 업그레이드 방법 선택

NGINX Plus는 프로덕션 서버와 어플리케이션 버전을 동적으로 업그레이드하는 두 가지 방법을 제공합니다.

  • NGINX Plus API – NGINX Plus API를 사용하여 Upstream 그룹의 서버를 추가, 제거 또는 수정하는 HTTP 요청을 NGINX Plus에 보냅니다.
  • Application‑aware health checks – 로드 밸런싱 순환에서 제외하려는 서버를 의도적으로 실패시키고 트래픽을 다시 수신할 준비가 되면 상태 확인을 통과하도록 상태 확인을 정의합니다.

두 가지 방법은 여러 요인에 따라 다르므로 우선 순위에 따라 선택해야 합니다.

  • 변화의 속도 – API를 사용하면 변경 사항이 즉시 적용됩니다. 상태 확인을 사용하면 상태 확인이 실패할 때까지 변경 사항이 적용되지 않습니다(상태 확인의 기본 빈도는 5초임).
  • 초기 트래픽 – 상태 확인을 통해 slow start를 구성할 수 있습니다. 서버가 서비스로 돌아오면 NGINX Plus는 정의된 기간 동안 서버에 대한 부하를 천천히 증가시켜 애플리케이션이 “워밍업”(캐시 채우기, 타임 컴파일, 데이터베이스 연결 설정 등). 서버가 연결에 의해 압도되지 않아 시간이 초과되어 다시 실패한 것으로 표시될 수 있습니다. API를 사용하면 NGINX Plus는 기본적으로 서버에 전체 트래픽 공유를 즉시 보냅니다.
  • 자동화 및 스크립팅 – API를 사용하면 대부분의 업그레이드 단계를 자동화하고 스크립팅할 수 있으며 NGINX Plus 구성 내에서 수행할 수 있습니다. 상태 확인을 사용할 때 업그레이드를 자동화하려면 업그레이드 중인 서버에서 실행되는 스크립트도 생성해야 합니다(예: semaphore health checks에 사용되는 파일 조작).

일반적으로 변경 사항이 즉시 적용되고 API가 완전히 스크립트 가능하고 자동화 가능하기 때문에 대부분의 사용 사례에 대해 NGINX Plus API를 권장합니다.

2. NGINX Open Source로 업그레이드

먼저 NGINX Open Source에서 업그레이드가 작동하는 방식을 검토하고 몇 가지 가능한 문제를 살펴보겠습니다. 여기에서 Upstream 구성 블록을 편집하고 구성 파일을 다시 로드하여 Upstream 서버 그룹을 변경합니다. 새 구성을 활용하기 위해 새로운 Worker 프로세스 집합이 시작되고 기존 Worker 프로세스가 계속 실행되어 다시 로드가 발생할 때 열려 있던 연결을 처리하기 때문에 구성 다시 로드가 원활합니다. 모든 이전 Worker 프로세스는 모든 연결이 완료되는 즉시 종료됩니다. 이 디자인은 다시 로드하는 동안 연결이나 요청이 손실되지 않도록 보장하고 NGINX 자체를 한 버전에서 다른 버전으로 업그레이드할 때에도 다시 로드 방법을 적합하게 만듭니다.

뛰어 연결의 특성에 따라 모든 연결을 완료하는 데 걸리는 시간은 몇 초에서 몇 분까지 걸릴 수 있습니다. 구성이 자주 변경되지 않는 경우 짧은 시간 동안 두 세트의 Worker를 실행해도 일반적으로 나쁜 영향은 없습니다. 그러나 변경(및 결과적으로 다시 로드)이 매우 빈번한 경우 이전 Worker는 요청 처리를 완료하지 못하고 다음 다시 로드가 발생하기 전에 종료되어 여러 Worker 집합이 한 번에 실행될 수 있습니다. Worker가 충분하면 결국 메모리가 소진되고 CPU가 100%에 도달할 수 있습니다. 특히 서버를 거의 용량에 가깝게 실행하여 이미 리소스 사용을 최적화하고 있는 경우 더욱 그렇습니다.

애플리케이션 서버를 로드 밸런싱할 때 Upstream 그룹은 용량 확장 및 축소, 새 버전으로 업그레이드 또는 유지 관리를 위해 서버를 오프라인으로 전환하는 등 가장 자주 변경되는 구성의 일부입니다. 수백 대의 가상 서버를 실행하는 고객은 수천 대의 백엔드 서버에서 부하 분산 트래픽을 매우 자주 수정해야 할 수 있습니다. NGINX Plus의 API 또는 상태 확인을 사용하면 빈번한 구성 Reload 문제를 피할 수 있습니다.

3. NGINX Plus 업그레이드 방법 개요

두 개의 관련 기사에서 논의된 사용 사례는 때때로 보조 작업과 함께 다음 방법 중 하나를 사용합니다.

3-1. NGINX Plus API로 업그레이드하기

NGINX Plus API를 사용하여 Upstream 그룹의 서버를 관리하려면 다음 기본 URL에 대해 HTTP 메서드를 실행합니다. 우리는 API에 대한 일반적인 위치 이름인 /api를 사용하고 있지만 다른 이름을 구성할 수 있습니다(두 번째 또는 세 번째 기사의 기본 구성에 대한 섹션 참조).

http://NGINX-server[:port]/api/api-version/http/upstreams/upstream-group-name/servers

아래 명령에서 이 URL은 BASE-URL로 표시됩니다.

추가 매개변수 없이 curl 명령을 실행하면 다른 두 기사에서 다룰 사용 사례에 대한 이 예제에서와 같이 서버 및 해당 매개변수 목록이 반환됩니다. 여기에서 출력을 jq 유틸리티로 파이프하여 더 쉽게 읽을 수 있도록 각 필드를 자체 줄에 넣습니다.

$ curl -s BASE-URL | jq
[
  {
    "id": 0,
    "server": "172.16.210.81:80",
    "weight": 1,
    "max_conns": 0,
    "max_fails": 0,
    "fail_timeout": "10s",
    "slow_start": "10s",
    "route": "",
    "backup": false,
    "down": false
  },
  {
    "id": 1,
    "server": "172.16.210.82:80",
    "weight": 1,
    "max_conns": 0,
    "max_fails": 0,
    "fail_timeout": "10s",
    "slow_start": "10s",
    "route": "",
    "backup": false,
    "down": false
  }

출력을 추가로 필터링하여 각 서버의 호스트명 또는 IP 주소 및 내부 ID만 표시할 수 있습니다. 아래 지침과 같이 서버를 제거하거나 상태를 변경할 때 서버를 식별하려면 ID가 필요합니다.

$ curl -s BASE-URL | jq -c '.peers[] | {server, id}'
{"server":"172.16.210.81:80","id":0}
{"server":"172.16.210.82:80","id":1}

Upstream 그룹의 서버를 변경하려면 표시된 방법을 사용하십시오(반환될 수 있는 확인 또는 기타 메시지는 생략됨).

  • 서버 추가
$ curl -X POST -d '{"server":"address-or-hostname[:port]"}' BASE-URL

기본적으로 서버는 작동 상태로 표시되고 NGINX는 즉시 트래픽 전송을 시작합니다. 작동 상태로 표시할 준비가 될 때까지 트래픽을 수신하지 않도록 작동 중지 상태로 표시하려면 서버를 추가할 때 down 매개변수를 true로 설정하십시오.

$ curl -X POST -d '{"server":"address-or-hostname[:port]","down":true}' BASE-URL
  • 서버 제거 – NGINX Plus는 모든 연결을 즉시 종료하고 더이상 요청을 보내지 않습니다.
$ curl -X DELETE BASE-URL/server-ID
  • 서버를 다운으로 표시 – NGINX Plus는 서버에 대한 새 연결 열기를 중지하지만 기존 연결은 완료할 수 있습니다. NGINX Plus 라이브 활동 모니터링 대시보드 또는 API를 사용하면 서버에 더 이상 열린 연결이 없고 안전하게 오프라인 상태가 될 수 있는 시기를 확인할 수 있습니다.
$ curl -X PATCH -d '{"down":true}' BASE-URL/server-ID
  • 실행 중인 서버를 draining으로 표시 – NGINX Plus는 새 클라이언트에서 서버로 트래픽 전송을 중지하지만 서버와의 영구 세션이 있는 클라이언트가 계속 연결을 열고 요청을 보낼 수 있도록 허용합니다. 세션이 완료될 때까지 충분한 시간을 허용했다고 생각되면 서버를 다운된 것으로 표시하고 오프라인으로 전환할 수 있습니다. 완료된 세션 확인을 자동화하는 방법에 대한 설명은 (개별 서버 업그레이드를 위해 세션 지속성과 함께 API 사용 파트 2 server-api-persistence에 링)을 참조하십시오.
$ curl -X PATCH -d '{"drain":true}' BASE-URL/server-ID
  • 서버를 가동으로 표시 – NGINX Plus는 즉시 트래픽 전송을 시작합니다.
$ curl -X PATCH -d '{"down":false}' BASE-URL/server-ID
  • 서버 구성 변경 – 서버 추가 시 POST 방식 또는 기존 서버에 PATCH 방식으로 server 지시문의 모든 매개변수를 설정할 수 있습니다. 후속 포스트의 여러 사용 사례에서 이 기능을 사용하여 서버 가중치를 설정합니다.

3-2. Application Health Checks로 업그레이드하기

Application Health Checks 구성은 사이트에서 사용자 환경을 개선하는 쉬운 방법입니다. NGINX Plus가 백엔드 서버가 가동 중인지 지속적으로 확인하고 로드 밸런싱 순환에서 사용할 수 없는 서버를 제거함으로써 클라이언트에 표시되는 오류 수를 줄일 수 있습니다. API 대신(또는 추가로) 상태 확인을 사용하여 서버를 가동 및 중단할 수도 있습니다.

Health Check와 API 간에는 몇 가지 중요한 차이점이 있습니다.

  • NGINX Plus와 상호 작용하는 대신 백엔드 서버에서 작업을 수행하여 서버를 가동 및 중단합니다. 가장 일반적으로 서버에 특정 파일(예: healthcheck.html)이 있으면 성공하고 그렇지 않으면 실패하도록 상태 확인을 정의합니다. 서버를 중단시키려면 파일을 제거하거나 이름을 변경하여 상태 검사를 실패하게 만듭니다. 이를 불러오려면 파일을 복원하거나 이름을 다시 healthcheck.html로 변경하여 Health Check 성공시키십시오.
  • Health Check를 사용하면 변경 사항이 API와 같이 즉시 적용되지 않고 대신 Health Check 빈도에 따라 달라집니다. 기본적으로 Health Check는 5초마다 실행되며 한 번만 실패해도 서버가 비정상으로 간주됩니다. 따라서 기본 설정에서는 NGINX Plus가 서버 상태를 변경하는 데 최대 5초가 걸릴 수 있습니다.
  • API에 비해 Health Check의 장점은 서버가 상태로 돌아온 후 NGINX Plus가 서버의 부하를 점진적으로 증가시키는 기간을 지정할 수 있다는 것입니다(slow start 기능). 이는 서버가 공정한 로드 공유를 받을 준비가 되기 전에 “워밍업”해야 하는 경우에 유용합니다.
  • 세션 지속성을 사용할 때는 Health Check를 사용할 수 없습니다. NGINX Plus가 Health Check에 실패하여 서버가 다운된 것으로 표시하면 서버는 세션 지속성 메커니즘에 의해 연결된 클라이언트에서도 더 이상 새 연결을 수신하지 않습니다. (즉, Health Check를 사용하면 서버 상태를 API의 “down“:false 및 “down“:true와 동일하게 설정할 수 있지만 “drain“:true로 설정할 수는 없습니다.)

4. 결론

NGINX Plus는 운영 및 DevOps 엔지니어에게 개별 서버 및 서버 그룹 모두에 대한 업그레이드 프로세스를 관리하는 여러 옵션을 제공하는 동시에 다운타임을 방지하여 우수한 고객 경험을 계속 제공합니다. 특정 사용 사례에 대한 업그레이드 방법 사용에 대한 포괄적인 지침은 이 시리즈의 다른 두 문서를 참조하세요.

NGINX Plus를 직접 사용해보면 업그레이드 작업이 보다 쉽고 효율적일 수 있음을 확인할 수 있습니다. 오늘부터 무료 30일 체험을 시작하거나 사용 사례에 대해 상담을 원하시면 저희에게 문의해주세요.

사용 사례에 대해 최신 소식을 빠르게 전달받고 싶으시면 아래 뉴스레터를 구독하세요.