NGINX Plus 릴리즈 R31 향상된 기능 소개

NGINX Plus Release 31(R31)의 출시를 발표하게 되어 기쁘게 생각합니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 all-in-one 소프트웨어 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API Gateway 입니다.

NGINX Plus R31의 새롭고 향상된 기능은 다음과 같습니다:

• 기본 NGINX 사용량 보고 – NGINX Plus는 이제 조직 전반의 NGINX 배포에 대한 보고를 기본적으로 지원하여 NGINX Instance Manager에서 NGINX 인프라를 통합적으로 볼 수 있습니다. 이 기능을 통해 규정 준수를 위해 NGINX 인스턴스에 대한 거버넌스를 강화할 수 있습니다.
• SNI 구성 개선 – 이전에는 SNI(Server Name Identification)를 통과하는 서버 이름이 proxy_ssl_name 지시문을 사용했으며 upstream 그룹의 모든 서버에서 사용되었습니다. NGINX Plus R31에서는 이 SNI를 선택한 upstream 서버로 설정할 수 있습니다.
• NGINX JavaScript를 사용한 주기적 작업 실행 – NGINX JavaScript는 주기적인 간격으로 콘텐츠를 실행할 수 있도록 js_periodic 지시문을 도입했습니다. 이 향상된 기능 덕분에 cron 작업을 설정할 필요가 없으며, 최적의 성능을 위해 모든 worker 프로세스 또는 특정 worker 프로세스에서 실행되도록 구성할 수 있습니다.
• 더 나은 NGINX 시작 환경 – NGINX Plus R31은 구성에 “location”이 많은 경우 전반적인 NGINX 시작 환경이 개선되었습니다.
• QUIC + HTTP/3 최적화 및 개선 – NGINX Plus R31은 Maximum Transmission Unit(MTU) discovery, 혼잡 제어 개선, 전체 QUIC 세션에서 암호화 컨텍스트를 재사용하는 기능 등 QUIC 구현에 많은 개선 사항과 성능 최적화를 추가합니다.

이번 릴리스의 마지막에는 NGINX 오픈 소스에서 상속된 새로운 기능과 버그 수정, NGINX JavaScript에 대한 업데이트가 포함되어 있습니다.

목차

1. NGINX Plus 행동의 중요한 변화
1-1. NGINX Plus OpenTracing 모듈 지원 중단
1-2. NGINX Plus 사용량 미보고에 대한 경고 메시지
1-3. 지원 플랫폼 변경 사항
2. NGINX Plus 새로운 기능 자세히 보기
2-1. 네이티브 NGINX Plus 사용량 보고
2-2. mgmt 구성 블록 설정 사용자 정의하기
2-3. SNI 구성 개선
2-4. NGINX JavaScript를 사용한 주기적 작업 실행
2-5. 더 나은 NGINX 시작 환경
2-6. QUIC+HTTP/3 최적화 및 개선 사항
3. NGINX Plus 기타 향상된 기능 및 버그 수정
3-1. 추가 mgmt 모듈
3-2. MQTT 모듈의 버그 수정
3-3. 변수를 사용한 HTTP/3 server_tokens 지원
3-4. NGINX 오픈 소스에서 상속된 변경 사항
3-5. NGINX JavaScript 모듈 변경 사항
4. NGINX Plus를 업그레이드하거나 사용해 보세요.

1. NGINX Plus 행동의 중요한 변화

참고: NGINX Plus R30 이외의 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이의 모든 릴리스에 대한 이전 공지 포스트의 동작의 중요한 변경 사항 섹션을 확인하세요.

1-1. NGINX Plus OpenTracing 모듈 지원 중단

NGINX Plus R18에 도입된 OpenTracing 모듈은 이제 더 이상 사용되지 않습니다. 이 모듈은 향후 출시될 NGINX Plus R34부터 제거될 예정입니다. 이 패키지는 그때까지 모든 NGINX Plus에서 사용할 수 있습니다. NGINX Plus R29에 도입된 OpenTelemetry 모듈을 사용할 것을 강력히 권장드립니다.

1-2. NGINX Plus 사용량 미보고에 대한 경고 메시지

NGINX Plus 사용자는 규정 준수를 위해 NGINX 사용량을 NGINX에 보고해야 합니다. NGINX Plus R31 릴리스에서는 NGINX Instance Manager에 NGINX 사용량을 보고하는 기능이 기본적으로 제공되며, 기본적으로 활성화 되어 있습니다. 어떤 이유로든 NGINX 인스턴스가 NGINX Instance Manager에 사용량 정보를 제공할 수 없는 경우 경고 메시지가 기록됩니다.

사용자 환경에서 이 기능을 구성하는 방법에 대한 자세한 내용은 기본 NGINX 사용량 보고 섹션을 참조하세요.

1-3. 지원 플랫폼 변경 사항

새로운 운영 체제가 지원됩니다:

• FreeBSD 14
• Alpine 3.19

이전 운영체제는 제거되었습니다:

• 2023년 11월 1일에 단종(EOL)된 Alpine 3.15

NGINX Plus R32에서 더이상 사용되지 않으며, 제거 예정인 이전 운영체제:

• 2023년 12월 31일에 EOL되는 FreeBSD 12

2. NGINX Plus 새로운 기능 자세히 보기

2-1. 네이티브 NGINX Plus 사용량 보고

NGINX Plus R31은 라이선스 규정 준수를 자동화하기 위해 네트워크에서 NGINX Instance Manager와의 기본 통신을 도입했습니다. F5 Flex Consumption Program에 참여하는 경우 더 이상 NGINX Plus 인스턴스를 수동으로 추적할 필요가 없습니다.

기본적으로 NGINX Plus는 시작 시 nginx-mgmt.local hostname의 DNS 조회를 통해 NGINX Instance Manager를 검색하려고 시도합니다. Hostname은 구성할 수 있지만, 간단히 하기 위해 기본 hostname을 NGINX Instance Manager를 실행하는 시스템의 IP 주소와 연결하는 것이 좋습니다. 그러면 NGINX Plus가 NGINX Instance Manager에 TLS 연결을 설정하여 30분마다 버전 번호, hostname, 고유 식별자를 보고합니다.

추가 보안 계층을 위해 선택 사항인 mgmt 구성 블록을 사용하여 구성 블록을 사용하여 mTLS로 이 연결을 프로비저닝하는 것도 좋습니다. 그런 다음 정기적으로 NGINX Instance Manager가 NGINX Plus 인스턴스의 총사용량을 NGINX에 보고합니다.

NGINX Plus가 nginx-mgmt.local hostname을 확인하거나 NGINX Instance Manager와 통신하는 데 문제가 발생하면 error log에 경고 메시지가 표시됩니다.

다음은 NGINX Plus 인스턴스가 nginx-mgmt.local을 확인할 수 없음을 나타내는 오류 메시지의 예입니다:

2023/12/21 21:02:01 [warn] 3050#3050: usage report: host not found resolving endpoint "nginx-mgmt.local”

다음은 NGINX Plus 인스턴스가 NGINX Instance Manager와 통신하는 데 문제가 있음을 나타내는 오류 메시지의 예입니다:

2023/12/21 21:02:01 [warn] 3184#3184: usage report: connection timed out

2-2. mgmt 구성 블록 설정 사용자 정의하기

NGINX Plus 인스턴스가 NGINX Instance Manager와 통신하는 방식을 미세 조정하려면 새로운 mgmt 구성 블록과 관련 지시문을 사용하도록 선택할 수 있습니다. 이렇게 하면 사용자 지정 resolver를 정의하고, IP 주소 또는 대체 hostname을 사용하여 NGINX Instance Manager 시스템을 식별하고, TLS 옵션을 지정하고, 보안 강화를 위해 mTLS를 사용하고, 기타 사용자 지정 매개 변수를 지정할 수 있습니다.

다음은 사용자 지정 구성 샘플입니다:

mgmt {
    usage_report endpoint=instance-manager.local interval=30m;
    resolver 192.168.0.2; # Sample internal DNS IP
    uuid_file /var/lib/nginx/nginx.id;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers DEFAULT;
    ssl_certificate          client.pem;
    ssl_certificate_key      client.key;
    ssl_trusted_certificate  trusted_ca_cert.crt
    ssl_verify               on;
    ssl_verify_depth         2;

}

이러한 지시문에 대한 자세한 내용은 제품 설명서를 참조하세요.

2-3. SNI 구성 개선

이 릴리스 이전에는 upstream 그룹의 모든 서버가 동일하다고 가정했습니다. 즉, 동일한 요청에 응답하고, 동일한 SNI 이름(proxy_ssl_server_name 사용 시)에 응답하고, 동일한 이름과 일치하는 SSL 인증서를 반환할 수 있어야 했습니다.

그러나 이 동작이 충분하지 않은 시나리오가 존재합니다. 예를 들어 upstream 서버 뒤에서 여러 가상 서버가 공유되고 있고 특정 리소스로 요청을 라우팅하기 위해 다른 SNI and/or 호스트 헤더로 구분해야 하는 경우입니다. 또한 upstream 그룹의 모든 서버에서 동일한 인증서를 사용할 수 없거나 upstream 서버를 별도의 upstream 그룹에 넣는 데 제한이 있을 수 있습니다.

NGINX Plus R31은 upstream 서버별로 SNI를 구성할 수 있는 기능을 지원합니다. 변수는 선택한 upstream 서버의 이름을 가리키며, 이 이름은 proxy_ssl_server_name 및 proxy_ssl_name 지시문을 사용하여 프록시 서버에 전달할 수 있습니다.

다음은 서버 이름이 SNI를 통과할 수 있도록 proxy_ssl_server_name을 on으로 설정하는 방법입니다:

proxy_ssl_server_name on;

다음은 proxy_ssl_name을 사용하여 선택한 upstream 서버 이름을 전달하는 방법입니다:

proxy_ssl_name $upstream_last_server_name;

2-4. NGINX JavaScript를 사용한 주기적 작업 실행

NGINX JavaScript v0.8.1은 http 및 stream 컨텍스트에서 모두 사용할 수 있는 새로운 지시문 js_periodic 을 도입했습니다. 이 지시문을 사용하면 JavaScript 콘텐츠 핸들러를 정기적으로 실행하도록 지정할 수 있습니다. 이는 사용자 정의 코드가 주기적으로 실행되어야 하고 NGINX 변수에 대한 액세스가 필요할 수 있는 경우에 유용합니다. 콘텐츠 핸들러는 세션 객체를 인수로 받고 전역 객체에도 액세스할 수 있습니다.

기본적으로 콘텐츠 핸들러는 worker 프로세스 0에서 실행되지만, 특정 또는 모든 worker 프로세스에서 실행되도록 구성할 수 있습니다.

이 지시문은 location 컨텍스트에서 사용할 수 있습니다:

example.conf:

location @periodics {

    # to be run at 15 minute intervals in worker processes 1 and 3
    js_periodic main.handler interval=900s worker_affinity=0101;

    resolver 10.0.0.1;
    js_fetch_trusted_certificate /path/to/certificate.pem;

}


example.js:

async function handler(s) {
    let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
    let body = await reply.text();
    ngx.log(ngx.INFO, body);
}

구문 및 구성에 대한 자세한 내용은 NGINX JavaScript 문서를 참조하세요.

2-5. 더 나은 NGINX 시작 환경

NGINX 구성에 많은 수의 “location”이 포함되어 있는 시나리오에서는 NGINX 시작 시간이 상당히 오래 걸릴 수 있습니다. 대부분의 경우 이는 허용되지 않을 수 있습니다. 근본적인 문제는 location 목록을 정렬하는 데 사용되는 정렬 알고리즘에 있습니다.

NGINX R31은 기존 정렬 알고리즘을 시간 복잡도가 O(n2)인 삽입 정렬에서 시간 복잡도가 O(n*log n)인 병합 정렬로 대체하는 개선 사항을 도입했습니다.

20,000개의 location이 포함된 테스트 구성에서, 이 업데이트 후 총 시작 시간이 8초에서 0.9초로 단축된 것으로 확인되었습니다.

2-6. QUIC+HTTP/3 최적화 및 개선 사항

NGINX Plus R31은 다음과 같은 몇 가지 개선 사항과 성능 최적화를 QUIC+HTTP/3 구현에 도입했습니다:

• QUIC+HTTP/3 사용 시 Maximum Transmission Unit(MTU) discovery – 경로 MTU는 네트워크를 통해 전송할 수 있는 가장 큰 크기의 프레임 또는 데이터 패킷을 바이트 단위로 측정한 값입니다. 이 변경 이전에는 모든 데이터그램에 대해 1200 바이트의 경로 MTU를 사용했습니다. 이제 NGINX Plus는 모든 발신 데이터그램에 사용되는 경로 MTU 크기를 검색할 수 있도록 지원합니다.
• 전체 QUIC 세션에서 암호화 컨텍스트 재사용 – 이 최적화는 QUIC 패킷의 암호화 및 복호화 동작과 관련이 있습니다. 이전에는 각 암호화 또는 복호화 작업에 별도의 암호화 컨텍스트가 생성되었습니다. 이제 전체 QUIC 세션에서 동일한 컨텍스트가 사용되므로 성능이 향상됩니다.

추가적인 성능 최적화에는 acknowledgement 패킷 전송 시 잠재적 지연 감소, 프레임 재전송 및 ACK 프레임 전달 지연을 줄이기 위해 acknowledgement(ACK) 프레임을 대기열 앞쪽에 배치, 모든 발신 데이터그램에 대한 GSO(Generic Segmentation Offload) 모드의 혼잡 제어 동작 개선 등이 포함됩니다.

3. NGINX Plus 기타 향상된 기능 및 버그 수정

3-1. 추가 mgmt 모듈

NGINX Plus R31에서는 ngx_mgmt_module을 사용하여 NGINX 사용 정보를 NGINX Instance Manager에게 보고할 수 있습니다. 이 정보에는 NGINX hostname, NGINX 버전, 고유 인스턴스 식별자가 포함됩니다.

이 모듈은 NGINX 인스턴스가 NGINX Instance Manager와 통신하는 방법을 미세 조정할 수 있는 여러 지시문을 제공합니다. 사용 가능한 지시문 및 구성 옵션의 전체 목록은 NGINX 문서를 참조하세요.

3-2. MQTT 모듈의 버그 수정

Message Queuing Telemetry Transport(MQTT) 지원은 NGINX Plus R29에 도입되었으며, 이번 릴리스에는 MQTT 모듈에서 관찰된 문제에 대한 몇 가지 버그 수정이 포함되어 있습니다.

중요한 수정 사항 중 하나는 비밀번호를 제공하지 않았을 때 CONNECT 메시지가 거부되는 문제를 해결한 것입니다. 이전에는 무조건 사용자 이름 필드 다음에 비밀번호가 올 것으로 예상했습니다. 하지만 익명 인증과 같이 비밀번호 제공이 필수가 아닌 특수한 경우(예: 익명 인증)가 MQTT 사양에 명시되어 있습니다. 이 수정은 패킷의 cflags 필드를 확인하여 비밀번호가 예상되는지 여부를 조건부로 확인합니다. 플래그가 설정되어 있지 않으면 비밀번호가 필수가 아니라는 의미입니다.

또 다른 버그 수정은 메시지 길이가 수신된 바이트 수보다 작을 때 MQTT CONNECT 메시지의 구문 분석을 중지합니다.

3-3. 변수를 사용한 HTTP/3 server_tokens 지원

NGINX Plus R31은 HTTP/3 연결에 대해 누락된 server_tokens 변수에 대한 지원을 추가합니다. 문자열 필드는 오류 페이지의 서명과 “Server” 응답 헤더 필드 값을 명시적으로 설정하는 데 사용할 수 있습니다. 문자열 필드가 비어 있으면 “Server”필드의 배출이 비활성화됩니다.

3-4. NGINX 오픈 소스에서 상속된 변경 사항

NGINX Plus R31은 NGINX 오픈 소스 1.25.3을 기반으로 하며, NGINX Plus R30 출시(NGINX 1.25.2 및 1.25.3) 이후 적용된 기능 변경 사항, 특징 및 버그 수정을 상속합니다.

Features

• QUIC 사용 시 경로 MTU discovery – 이 전에는 모든 데이터그램에 기본 크기인 1200 MTU가 사용되었습니다. QUIC+HTTP/3 개선의 일환으로, 모든 발신 데이터그램에 사용되는 경로 MTU 크기를 검색할 수 있는 지원이 추가되었습니다.
• QUIC의 성능 최적화 – NGINX mainline 버전 1.25.2에서는 전체 QUIC 세션에 대한 암호화 컨텍스트를 재사용하기 위해 QUIC 구현에 최적화를 도입했습니다. 이를 통해 ACK 패킷 전송 지연이 줄어들고 ACK 프레임을 대기열의 앞쪽에 배치하여 프레임 재전송과 ACK 프레임 전달 지연이 줄어듭니다.
• HTTP/3 사용 시 TLS_AES_128_CCM_SHA256 암호화 모음 지원 – 이 개선 사항으로 현재 NGINX QUIC 구현에서 지원하지 않는 유일한 암호화 모음인 TLS_AES_128_CCM_SHA256 지원이 QUIC에 추가됩니다. 이 기능은 OpenSSL에서 기본적으로 비활성화되어 있으며, 다음 지시문을 사용하여 활성화할 수 있습니다: ssl_conf_command Ciphersuites TLS_AES_128_CCM_SHA256;
• OpenSSL 구성을 로드하는 동안 nginx 앱 이름 제공 – OPENSSL_init_ssl() 인터페이스를 사용할 때 OPENSSL_INIT_LOAD_CONFIG가 정의되어 있고 true인지 테스트합니다. 이렇게 하면 추가 라이브러리 초기화 설정(특히 OPENSSL_INIT_set_config_appname() call)을 제공하지 않는 BoringSSL 및 LibreSSL에서 인터페이스가 사용되지 않도록 보장할 수 있습니다.

Changes

• NGINX 대기열 정렬 알고리즘 변경 – 위에서 설명한 대로 이제 NGINX는 시간 복잡도가 O(n*log n)인 병합 정렬을 사용합니다. 이는 특히 구성에 “location”이 매우 많은 경우 더 나은 NGINX 시작 환경을 제공합니다.
• HTTP/2 반복 stream 처리 제한 – 이 개선 사항은 하나의 이벤트 루프에 도입할 수 있는 새 stream의 수에 제한을 두어 NGINX에 대한 플러드 공격을 조기에 감지할 수 있도록 합니다. 이 제한은 값의 두 배이며 http2_max_concurrent_streams를 사용하여 구성됩니다. 요청을 전송한 직후 stream이 재설정되는 경우를 고려하여 허용되는 동시 stream의 최대 임계값에 도달하지 않더라도 적용됩니다.

Bug Fixes

• HTTP/2 자동 감지를 통한 버퍼 관리 수정 – 일반 TCP 연결에서 HTTP/2 자동 감지의 일부로, 초기 데이터는 상태 예약이 없는 client_header_buffer_size 지시문으로 지정된 버퍼로 먼저 읽혀집니다. 이로 인해 상태를 저장하는 동안 버퍼를 덮어쓸 수 있는 문제가 발생했습니다. 현재 수정으로 고정 버퍼 크기 대신 사용 가능한 버퍼 크기만 읽을 수 있습니다. 이 버그는 NGINX mainline 버전 1.25.1(NGINX Plus R30)에서 처음 나타났습니다.
• OpenSSL 호환 모드에서 잘못된 전송 모드 – 이 릴리스 이전에는 클라이언트에서 잘못된 전송 매개변수를 전송하는 경우 OpenSSL 호환 계층에서 연결이 지연되는 문제가 있었습니다. 이 수정 사항은 먼저 사용자에게 잘못된 매개변수에 대해 알린 다음 연결을 종료하여 이 동작을 손쉽게 처리합니다.
• 이유 문구가 없는 status 헤더 처리 수정 – Status header: 404와 같이 “reason phrase”가 없는 status header는 CGI(Common gateway Interface) 사양에 따라 유효했지만 구문 분석 중에 후행 공백이 손실되었습니다. 이로 인해 응답해 HTTP/1.1 404 status line이 표시되었으며, 이는 누락된 후행 공백으로 인해 HTTP 사양을 위반했습니다. 이번 버그 수정을 통해 짧은 status header line에서 status code만 사용되므로 NGINX는 공백 및 적절한 이유 문구(사용 가능한 경우)가 포함된 status line 자체를 생성합니다.
• PCRE2로 구성을 다시 로드할 때 메모리 누수 수정 – 이 문제는 버전 1.21.5 이상에서 PCRE2를 사용하도록 NGINX를 구성했을 때 발생했습니다.

최근 릴리스에서 상속된 새로운 변경 사항, 기능, 버그 수정 및 해결 방법의 전체 목록은 NGINX CHANGES 파일을 참조하세요.

3-5. NGINX JavaScript 모듈 변경 사항

NGINX Plus R31에는 NGINX JavaScript(njs) 모듈 버전 0.8.2의 변경 사항이 통합되었습니다. 다음은 0.8.0(NGINX Plus R30 릴리스의 일부) 이후 njs에서 눈에 띄는 변경 사항 목록입니다.

Features

• 콘솔 객체가 도입되었습니다. error(), info(), log(), time(), timeEnd(), warn() 메서드가 도입되었습니다.
• 일정한 간격으로 실행되도록 JS 핸들러를 지정할 수 있는 http 및 stream 용 js_periodic 지시문을 도입했습니다.
• Share dictionary의 items() 메서드를 구현했습니다. 이 메서드는 만료되지 않은 모든 key-value를 반환합니다.

Changes

• “fs” 모듈을 확장했습니다. existsSync() 메서드를 추가했습니다.

Bug Fixes

• “xml” 모듈을 수정했습니다. parse() 메서드에서 broken XML 예외 처리를 수정했습니다.
• 전역 정규식(regexp) 및 Unicode 입력을 사용하는 RegExp.prototype.exec()를 수정했습니다.
• Share dictionary의 size() 및 keys() 메서드를 수정했습니다.
• 0.8.0에 도입된 r.internalRedirect()의 잘못된 예외를 수정했습니다.
• Object.getOwnPropertyNames()의 잘못된 키 순서를 수정했습니다.
• fetch API에서 Content-Length가 큰 HEAD 응답 처리를 수정했습니다.

모든 기능, 변경 사항 및 버그 수정에 대한 전체 목록은 njs 변경 로그를 참조하세요.

4. NGINX Plus를 업그레이드하거나 사용해 보세요.

NGINX Plus를 실행 중인 경우 가능한 한 빨리 NGINX Plus R31로 업그레이드할 것을 강력히 권장합니다. 모든 훌륭한 새 기능 외에도 몇 가지 추가 수정 및 개선 사항이 적용되며, 최신 버전으로 유지하면 지원 티켓을 제출해야 할 때 NGINX에서 도움을 받을 수 있습니다.

아직 NGINX Plus를 사용해 보지 않았다면 꼭 확인해 보세요. 보안, 로드 밸런싱, API Gateway 사용 사례에 사용하거나 향상된 모니터링 및 Management API 를 통해 완벽하게 지원되는 웹 서버로 사용할 수 있습니다. 30일 무료 체험판을 신청하거나, NGINX STORE에 연락하여 논의하십시오.

NGINX에 대한 최신 정보들을 빠르게 전달받고 싶으시다면, 아래의 뉴스레터를 구독하세요.

NGINX STORE를 통한 솔루션 도입 및 기술지원 무료 상담 신청

* indicates required

Email Address *

핸드폰 번호

이름

문의내용

당신이 인간이라면 이 필드를 비워두세요: