NGINX Status 모듈 비교: NGINX OSS vs NGINX Plus

NGINX status 정보를 확인하기 위해서는 대표적으로 내장되어 있는 모듈을 사용하여 확인을 할 수 있습니다. NGINX OSS의 경우 ngx_http_stub_status_module을, NGINX Plus의 경우에는 ngx_http_api_module이 있습니다.

이번 포스트에서는 NGINX OSS의 ngx_http_stub_status_module과 NGINX Plus의 ngx_http_api_module을 비교하여 NGINX status가 서로 어떻게 다른지 비교하는 내용을 다루겠습니다.

목차

1. 개요
1-1. ngx_http_stub_status_module의 NGINX Status 정보
1-2. ngx_http_api_module의 NGINX Status 정보
2. ngx_http_stub_status_module 구성
3. ngx_http_api_module 구성
4. NGINX Plus API 모듈의 이점
5. 결론

1. 개요

NGINX는 웹 서버 및 리버스 프록시 서버로 널리 사용되는 오픈 소스 소프트웨어입니다. NGINX OSS와 NGINX Plus는 기본적으로 동일한 아키텍처를 공유하지만, NGINX Plus는 여러 추가 기능을 제공합니다. 이 글에서는 NGINX OSS의 ngx_http_stub_status_module과 NGINX Plus의 ngx_http_api_module을 비교하여, 각 모듈의 주요 차이점과 NGINX 상태 정보를 어떻게 다루는지를 살펴보겠습니다.

1-1. ngx_http_stub_status_module의 NGINX Status 정보

이 모듈은 NGINX OSS에서 제공되는 기본 모듈이며, 간단하고 직관적인 NGINX status를 제공합니다. 이 모듈에서 제공하는 NGINX status는 아래와 같습니다.

• Active Connections – 현재 활성 클라이언트 연결 수입니다.
• accepts – 허용된 총 클라이언트 연결 수입니다.
• handled – 처리된 총 연결 수입니다. 일반적으로 리소스 제한(예: Worker_connection 제한)에 도달하지 않는 한 accepts와 동일합니다.
• request – 총 클라이언트의 요청 수입니다.
• Reading – NGINX가 요청 헤더를 읽는 현재 연결 수입니다.
• Writing – NGINX가 클라이언트에 응답을 다시 쓰는 현재 연결 수입니다.
• Wating – 요청을 기다리고 있는 현재 유휴 클라이언트 연결 수입니다.

이와 같이 NGINX OSS의 nginx_http_stub_status_module에서 제공하는 NGINX status 정보는 총 7개로 비교적 적은 정보를 나타냅니다.

1-2. ngx_http_api_module의 NGINX Status 정보

ngx_http_api_module의 경우 NGINX Plus에서 제공되는 고급 모듈입니다. 해당 모듈은 RESTful API를 통해 보다 상세한 NGINX status를 제공합니다. 실시간 NGINX status와 메트릭, 요청 및 연결 통계 등을 JSON 형식으로 제공합니다.

간단하게 workers에 대한 정보를 확인해보면 아래와 같이 JSON 형식으로 NGINX status가 출력됩니다.

이를 제외하고 nginx, processes, connections, slab, http, stream, resolvers, ssl, workers에 대한 상세한 NGINX status를 확인할 수 있습니다.

이에 대한 확인 방식은 Endpoint 방식으로 작동하며 사용할 수 있는 endpoint는 아래와 같습니다.

• /nginx
• /processes
• /connections
• /slabs/
• /slabs/{slabZoneName}
• /http/
• /http/requests
• /http/server_zones/
• /http/server_zones/{httpServerZoneName}
• /http/location_zones/
• /http/location_zones/{httpLocationZoneName}
• /http/caches/
• /http/caches/{httpCacheZoneName}
• /http/limit_conns/
• /http/limit_conns/{httpLimitConnZoneName}
• /http/limit_reqs/
• /http/limit_reqs/{httpLimitReqZoneName}
• /http/upstreams/
• /http/upstreams/{httpUpstreamName}/
• /http/upstreams/{httpUpstreamName}/servers/
• /http/upstreams/{httpUpstreamName}/servers/{httpUpstreamServerId}
• /http/keyvals/
• /http/keyvals/{httpKeyvalZoneName}
• /stream/
• /stream/server_zones/
• /stream/server_zones/{streamServerZoneName}
• /stream/limit_conns/
• /stream/limit_conns/{streamLimitConnZoneName}
• /stream/upstreams/
• /stream/upstreams/{streamUpstreamName}/
• /stream/upstreams/{streamUpstreamName}/servers/
• /stream/upstreams/{streamUpstreamName}/servers/{streamUpstreamServerId}
• /stream/keyvals/
• /stream/keyvals/{streamKeyvalZoneName}
• /stream/zone_sync/
• /resolvers/
• /resolvers/{resolverZoneName}
• /ssl
• /workers/
• /workers/{workerId}

2. ngx_http_stub_status_module 구성

ngx_http_stub_status_module을 구성하는 방법은 어렵지 않습니다.

server {
        listen 80;
        server_name example.com;

        location / {
                root /usr/share/nginx/html;
                index index.html;
        }

        location = /basic_status {
                stub_status;
        }
}

NGINX status를 확인할 경로의 location 블록을 생성한 뒤, 해당 location 내에 stub_status 지시문을 추가하면 됩니다. (1.7.5 이전 버전에서는 지수문 구문에 “stub_status on”과 같은 임의의 인수가 필요했습니다.)

위와 같이 구성 후, http://example.com/basic_status 경로에 접근하여 NGINX status를 확인합니다.

섹션 1-1의 첨부 사진처럼, 간단한 NGINX status 정보만 나타나는 것을 확인할 수 있습니다.

3. ngx_http_api_module 구성

ngx_http_api_module을 구성하는 방법 또한 어렵지 않습니다.

upstream backend {
        zone backend 64k;
        server example.com:8001;
        server example.com:8002;
}

server {
        listen 80;
        server_name example.com;

        location / {
                root /usr/share/nginx/html;
                index index.html;
        }

        location /api {
                api write=on;
        }
}

NGINX status를 확인할 location /api 블록을 생성한 뒤, api 지시문을 추가하여 활성화합니다. write 매개변수는 API가 read-only인지, read-write 인지 결정합니다.

위와 같이 구성 후, http://example.com/api 에 접근하여 NGINX status를 확인합니다.

http://example.com/api 에 접근 시 API version이 나타납니다.

http://example.com/api/9 로 접근하여 최신 버전의 NGINX status를 확인합니다.

다양한 endpoint가 나오는데, 이번 포스트에서는 http를 확인하겠습니다. (http://example.com/api/9/http)

Http에 관련된 다양한 NGINX status 정보들이 나타나는데, 이번 포스트에서는 upstreams를 확인하겠습니다. (http://example.com/api/9/http/upstreams)

위와 같이 JSON 형식으로 http/upstreams의 정보를 확인할 수 있습니다.

이렇게 endpoint를 추가하여 수많은 NGINX status 중에서 원하는 정보를 확인할 수 있습니다.

NGINX Plus에서 지원하는 대시보드 및 Prometheus 메트릭 또한, ngx_http_api_module에서 나타나는 NGINX status 정보를 사용하여 구성하게 됩니다.

4. NGINX Plus API 모듈의 이점

위와 같이 NGINX Plus의 ngx_http_api_module을 사용하면 수많은 NGINX Status 정보를 확인할 수 있습니다. 이를 제외하고, RESTful API를 사용하여 NGINX Plus의 구성도 변경할 수 있습니다.

RESTful API를 사용하여 NGINX Plus를 구성을 변경하는 예시를 간단히 보여드리겠습니다. 현재 구성되어 있는 backend라는 name의 upstream 서버는 아래와 같습니다.

현재 총 2개의 upstream 서버가 지정되어 있습니다. RESTful API를 사용하여 backend upstream에 서버를 추가할 수 있습니다.

아래는 Postman을 사용하여 upstream 서버를 추가하는 예시 입니다.

response를 확인해보면 status code 201 Created가 된 것을 확인할 수 있습니다. 이제 다시 backend upstream 정보를 확인해보면 API를 사용하여 추가한 123.123.123.123:123 서버가 추가된 것을 확인할 수 있습니다.

5. 결론

이번 포스트에서는 NGINX status를 확인하기 위한 모듈인 ngx_http_stub_status_module과 ngx_http_api_module을 구성해보며 NGINX status 정보를 확인했습니다.

각 모듈 별로 출력되는 결과에서 확인할 수 있듯이, NGINX OSS의 ngx_http_stub_status_module을 사용하면, NGINX status 정보를 볼 수는 있지만 제공하는 정보가 제한적이어서, 모니터링 및 분석에는 부족할 수 있습니다.

반면, NGINX Plus의 ngx_http_api_module은 더 많은 정보를 실시간으로 제공하며, 복잡한 모니터링 및 분석을 지원합니다. ngx_http_api_module에서 수집한 NGINX status 정보를 바탕으로 NGINX Plus Activity Dashboard도 구성할 수 있으며, 수많은 정보를 확인할 수 있습니다.

NGINX Plus에서 제공하는 NGINX Status를 확인하기 위한 ngx_http_api_module을 직접 사용해보고 싶으시다면, 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 논의하십시오.