무중단 NGINX 설정: NGINX Plus 동적 재구성

NGINX 설정 및 구성은 서비스 중단을 야기합니다. 반면 NGINX Plus는 동적 재구성을 지원하므로 WebSocket 애플리케이션의 재구성이 쉬워집니다.
대부분의 WebSocket 애플리케이션은 HTTP와 함께 사용되므로 NGINX Plus를 사용하여 둘 다 로드 밸런싱 할 수 있습니다.
이것은 확장성과 효율성을 높이며, 애플리케이션 배포 중에 발생하는 재구성을 간소화합니다.

기업이 애플리케이션에 새로운 기능을 구현하는 방식은 지난 몇 년간 크게 변화했습니다.
이전에는 기업들이 대규모의 새로운 기능을 동시에 제공하기 위해 기다렸으나, 이제는 코드가 준비되는 즉시 고객에게 기능을 제공하는 데 초점을 맞추고 있습니다.
일부 기업은 자동화와 강력한 툴 세트를 사용하여 하루에 50회 이상 자동화를 수행할 수 있습니다.

그러나 변경 사항을 자주 배포하면 각 배포에 구성 변경이 필요할 수 있으므로 애플리케이션 제공 인프라에 추가 요구 사항이 적용됩니다. 예를 들어 배포 중에 애플리케이션 서버를 업데이트하지 않고 삭제하고 교체하는 경우 로드 밸런서 구성도 업데이트해야 합니다.
또는 새로 배포된 기능이 다른 데이터베이스와 같은 추가 리소스에 액세스해야 하는 경우 보안 및 액세스 제어 구성도 업데이트 해야 합니다.
부정적인 측면에서 새 기능에서 버그를 발견하면 구성을 롤백해야 할 수도 있습니다.

전통적인 개발 환경에서는 IT팀이 배포를 관리하기 때문에 애플리케이션 배달 인프라에 대한 변경 사항을 만드는 것은 일반적으로 티켓을 작성하고 변경 창을 기다려야 합니다.
이는 때로는 몇 주가 걸리기도 합니다. 하루에 50회 이상 배포하는 경우 이러한 방식은 분명히 작동하지 않습니다.
구성 변경은 유연하고 자동화되며 쉽게 되돌릴 수 있어야 합니다. 또한 인프라는 지속적인 구성 변경을 겪으면서 온라인 상태를 유지하고 트래픽을 처리할 수 있어야 합니다.

NGINX와 NGINX Plus는 가장 요구 사항이 높은 환경에서 작동하는 애플리케이션 전달 플랫폼입니다. NGINX는 어떠한 다운 타임이나 트래픽 손실 없이 쉽게 다시 구성할 수 있으며, NGINX Plus는 추가적인 기능을 제공하여 구성 수정 프로세스를 자동화하고 간소화하는 데 도움이 되는 기능을 제공합니다.
이 포스트에서는 NGINX와 NGINX Plus 모두를 대상으로 동적으로 수정하고 자동화하는 구성 기술에 대해 다룹니다.

목차

1. NGINX 재구성
2. NGINX Plus를 사용한 DNS 기반 구성
3. NGINX Plus API를 사용한 Upstream 그룹 기반 구성
 3-1. NGINX Plus API 구성
 3-2. NGINX Plus API 사용
4. 결론

1. NGINX 설정 재구성

NGINX 구성은 구성 파일에 기록됩니다. 구성 파일을 변경하고 NGINX를 다시 시작하여 새 구성을 가져오면 “graceful restart” 가 수행됩니다. 이전 및 새 NGINX 사본이 잠시 동안 함께 실행됩니다.
이전 프로세스는 새 연결을 허용하지 않으며, 기존의 모든 연결이 종료되면 함께 종료됩니다.

NGINX 구성을 변경하는 가장 일반적인 이유 중 하나는 백엔드 서버를 추가하거나 제거하기 위해서 입니다.
앞서 언급한대로, 서버를 업데이트하는 대신 삭제하고 대체하는 경우 이러한 유형의 변경이 자주 발생할 수 있습니다.
또 다른 사용 사례는 스케일링입니다. 트래픽 급증을 처리하기 위해 서버를 추가하고, 트래픽이 줄어들면 서버를 제거합니다.

NGINX나 NGINX Plus의 설정 파일을 수정하고 다시 시작하는 것이 항상 편리하기만 한 것은 아닙니다.
예를 들어, 대규모 트래픽과 높은 부하를 경험하고 있는 경우, NGINX를 다시 시작하고 구성을 다시 로드하는 것은 시스템에 추가로 부하를 줄 수 있으며 일시적으로 성능을 저하시킬 수 있습니다.

NGINX Plus에는 백엔드 서버를 추가하거나 제거하는 일반적인 경우를 위해 NGINX Plus를 다시 시작하지 않고도 이러한 작업을 수행 할 수 있도록 NGINX Plus에 HTTP 기반 API와 DNS 기반 구성을 추가했습니다.

2. NGINX Plus를 사용한 DNS 기반 재구성

NGINX Plus를 사용하면 DNS 서버에서 upstream 그룹에 속하는 서버 목록을 유지할 수 있습니다.
DNS에서 사용 가능한 서버 목록을 업데이트하면 NGINX Plus가 변경 사항을 자동으로 감지합니다.

DNS 기반 동적 재구성을 사용하려면, Digital Ocean의 다음 예제와 같이 호스트명에 대한 다른 IP 주소를 갖는 여러 개의 A 레코드를 만들어야 합니다. 결과는 Round Robin DNS와 유사합니다.
단, 이 경우 NGINX Plus는 브라우저 클라이언트들이 하는 것처럼 DNS 목록에 있는 첫 번째 주소를 사용하지 않습니다.
대신 구성된 로드 밸런싱 알고리즘을 목록의 모든 서버에 적용합니다.
이는 Least Connections, Round Robin 또는 그 밖의 로드 밸런싱 알고리즘일 수 있습니다.
이렇게 함으로써 NGINX Plus는 DNS 서버를 업스트림 서버의 데이터베이스로 효과적으로 사용하고 있습니다.

NGINX Plus 구성은 다음과 같습니다.

http {
    upstream backend {
        zone backend 64k;
        server backend.example.com resolve;
    }
    resolver 192.168.1.50;
}

서버 호스트명 뒤에 resolver를 입력하면, NGINX는 해당 호스트명의 IP 주소 목록을 주기적으로 새로 고칩니다.
(NGINX Plus의 기본 동작은 초기화될 때 DNS 정보를 한 번만 가져오는 것입니다.)

resolver 지시문은 사용할 DNS 서버를 지정합니다. 기본적으로 NGINX Plus는 DNS에서 설정한 time-to-live (TTL)에 따라
DNS 항목을 새로 고칩니다. 기본 설정을 덮어쓰려면 다음 예와 같이 resolver 지시어에 valid 매개변수를 포함시키면 됩니다.

resolver 192.168.1.50 valid=30s;

위 예제에서 NGINX Plus는 DNS 항목을 새로고침 하기 전에 30초 동안 캐싱합니다.

3. NGINX Plus API를 사용한 Upstream 그룹 기반 구성

NGINX Plus API는 구성을 다시 로드하지 않고 Upstream(백엔드) 그룹의 서버를 동적으로 추가, 제거 및 수정하기 위한 HTTP 기반 인터페이스입니다.
이 기능은 자동 확장 및 유지 관리를 위해 서버를 일시적으로 중단하려는 경우에 유용합니다. NGINX Plus를 다시 시작하거나 구성을 다시 로드할 때 이 인터페이스를 사용하여 변경한 내용은 기본적으로 유지되지 않으므로 일시적인 변경에 특히 적합합니다.

3-1. NGINX Plus API 구성

NGINX Plus API를 사용하려면 가상 서버(server)의 구성 블록에 location 이라는 별도의 블록을 만들고 api 지시문을 포함합니다.
일반적으로 이 블록에 /api 라는 일반 이름을 사용합니다. 인터페이스 사용을 로컬 LAN의 관리자로 제한할 수 있는 allow 및 deny 지시문도 포함합니다.

server {
    listen 8080;          # Listen on a local port, which can be protected by a firewall

    location /api {
        api write=on;
        allow 10.0.0.0/8; # Allow access only from LAN
        deny all;         # Deny everyone else
    }
}

API는 서버 그룹에 대한 정보를 저장하기 위한 공유 메모리 영역을 필요로 하므로, Upstream 그룹의 예시인 backend 에 대한 구성에서와 같이 zone 지시문을 구성에 포함합니다.

upstream backend {
    zone backend 64k;
    server 10.2.2.90:8000;
    server 10.2.2.91:8000;
    server 10.2.2.92:8000;
}

3-2. NGINX Plus API 사용

backend Upstream 그룹에서 결함이 있는 서버를 제거하려고 합니다.
먼저, HTTP 도구와 함께 목록 요청을 보내 서버에 할당된 ID를 확인할 수 있고 curl을 사용하여 출력을
jq 유틸리티로 파이프링하여 각 서버의 이름 또는 주소와 ID만 필터링 합니다.

# curl -s http://localhost:8080/api/version/http/upstreams/backend/servers | jq -c '.peers[] | {server, id}'
{"server":"10.2.2.90:8000","id":0}
{"server":"10.2.2.91:8000","id":1}
{"server":"10.2.2.92:8000","id":2}

ID가 있으면 다음과 같이 ID로 제거할 ID를 지정할 수 있습니다.

# curl -X DELETE localhost:8080/api/version/http/upstreams/backend/servers/2

이제 Upstream 그룹에 서버를 더 추가하겠습니다. 다음과 같이 추가 요청을 통해 쉽게 이 작업을 수행할 수 있습니다.

# curl -X POST -d '{"server":"10.2.2.93:8000"}' http://localhost:8080/api/version/http/upstreams/backend/servers

이것은 NGINX Plus API로 할 수 있는 작업의 일부 샘플입니다. 서버를 draining 모드로 전환하거나 가중치를 수정하고 다른 방식으로 재구성하는 것도 가능합니다.

4. NGINX 설정 결론

NGINX를 사용하면 구성 변경을 하면서 Downtime 및 트래픽 처리에 중단이 없도록 할 수 있습니다. NGINX Plus는 구성 변경을 동적으로 수행하는 추가 방법을 제공합니다. Upstream 서버의 궁극적인 저장소로 DNS를 사용함으로써, NGINX Plus 구성 파일을 건드리지 않고 변경을 수행할 수 있습니다. HTTP 기반 API를 사용하여 일시적인 NGINX Plus 구성 변경을 쉽게 수행할 수 있으며, 이 또한 구성 파일을 건드리지 않고 수행됩니다.

NGINX Plus를 사용해 보려면 지금 무료 30일 평가판을 시작하거나 당사에 연락하여 사용 사례에 대해 논의하십시오 .