NGINX Plus R31 발표

NGINX Plus 릴리스 31(R31)이 출시되어 기쁩니다. NGINXPlus는 NGINX 오픈 소스를 기반으로 하는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.

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

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

이번 릴리스의 핵심은 NGINX 오픈 소스에서 물려받은 새로운 기능과 버그 수정, NGINX JavaScript 모듈에 대한 업데이트입니다.

행동의 중요한 변화

메모: NGINX Plus R30이 아닌 다른 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이의 모든 릴리스에 대한 이전 발표 블로그 의 중요한 동작 변경 사항 섹션을 확인하세요.

OpenTracing 모듈의 사용 중단

NGINX Plus R18에서 도입된 OpenTracing 모듈은 이제 더 이상 지원되지 않습니다. NGINX Plus R34의 향후 릴리스부터 제거될 예정입니다. 이 패키지는 그때까지 모든 NGINX Plus 릴리스와 함께 제공될 예정입니다. NGINX Plus R29에서 도입된 OpenTelemetry 모듈을 사용하는 것이 좋습니다.

NGINX 사용 보고 안함에 대한 경고 메시지

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

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

플랫폼 지원 변경

지원되는 새로운 운영 체제:

• 프리BSD 14
• 알파인 3.19

제거된 이전 운영 체제:

• 2023년 11월 1일에 수명 종료(EOL)에 도달한 Alpine 3.15

NGINX Plus R32에서 더 이상 지원되지 않고 제거 예정인 이전 운영 체제:

• 2023년 12월 31일에 EOL에 도달하는 FreeBSD 12

새로운 기능에 대한 자세한 정보

네이티브 NGINX 사용 보고

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

기본적으로 NGINX Plus는 시작 시 nginx-mgmt.local 호스트 이름의 DNS 조회를 통해 NGINX Instance Manager를 검색하려고 시도합니다. 호스트 이름은 구성 가능하지만 단순화를 위해 로컬 DNS에 A 레코드를 추가하여 기본 호스트 이름을 NGINX Instance Manager를 실행하는 시스템의 IP 주소와 연결하는 것이 좋습니다. NGINX Plus는 NGINX Instance Manager에 TLS 연결을 설정하여 30분마다 버전 번호, 호스트 이름, 고유 식별자를 보고합니다.

보안을 강화하기 위해 선택적 mgmt 구성 블록을 사용하여 이 연결을 mTLS로 프로비저닝하는 것이 좋습니다. NGINX Instance Manager는 정기적으로 NGINX Plus 인스턴스의 총 사용량을 F5 서비스에 보고합니다.

NGINX Plus에서 nginx-mgmt.local 호스트 이름을 확인하거나 NGINX Instance Manager와 통신하는 데 문제가 발생하면 오류 로그에 경고 메시지가 표시됩니다.

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

2023/12/21 21:02:01 [경고] 3050#3050: 사용 보고서: 호스트를 찾을 수 없음, 엔드포인트 "nginx-mgmt.local” 확인

다음은 NGINX Plus 인스턴스가 NGINX Instance Manager와 통신하는 데 어려움을 겪고 있음을 나타내는 오류 메시지의 예입니다.

2023/12/21 21:02:01 [경고] 3184#3184: 사용 보고서: 연결 시간이 초과되었습니다.

mgmt 구성 블록 설정 사용자 정의

NGINX Plus 인스턴스가 NGINX Instance Manager와 통신하는 방식을 세부적으로 조정하려면 새로운 mgmt 구성 블록과 관련 지침을 사용할 수 있습니다. 이렇게 하면 사용자 정의 리졸버를 정의하고, IP 주소나 대체 호스트 이름을 사용하여 NGINX Instance Manager 시스템을 식별하고, TLS 옵션을 지정하고, 보안을 강화하기 위해 mTLS를 사용하고, 기타 사용자 정의 매개변수를 지정할 수 있습니다.

다음은 사용자 정의 구성의 샘플입니다.

mgmt {
사용 보고서 엔드포인트=인스턴스 관리자.로컬 간격=30m;
확인자 192.168.0.2; # 샘플 내부 DNS IP

uuid 파일 /var/lib/nginx/nginx.id;

ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers DEFAULT;

ssl_certificate 클라이언트.pem;
ssl_certificate_key 클라이언트.key;

ssl_trusted_certificate trusted_ca_cert.crt;
ssl_verify 켜짐;
ssl_verify_depth 2;
}

이러한 지침에 대한 추가 세부 사항은 제품 설명서를 참조하세요.

NGINX Instance Manager를 다운로드하고 설치하는 방법에 대한 자세한 내용은 설치 가이드를 참조하세요.

메모: 이전 버전의 NGINX Plus를 사용하고 있는 경우에도 다음 지침 에 따라 인스턴스를 보고할 수 있습니다.

SNI 구성 개선

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

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

NGINX Plus R31은 업스트림 서버별로 SNI를 구성할 수 있는 지원을 도입했습니다. 변수 $upstream_last_server_name은 선택된 업스트림 서버의 이름을 참조하며, 이 이름은 proxy_ssl_server_name 및 proxy_ssl_name 지시어를 사용하여 프록시 서버로 전달될 수 있습니다.

proxy_ssl_server_name을 켜서 서버 이름이 SNI를 통과할 수 있도록 하는 방법은 다음과 같습니다.
proxy_ssl_server_name이 켜짐;

proxy_ssl_name을 사용하여 선택된 업스트림 서버 이름을 전달하는 방법은 다음과 같습니다.
proxy_ssl_name $upstream_last_server_name;

NGINX JavaScript를 사용한 주기적 작업 실행

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

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

이 지시문은 위치 컨텍스트에서 사용할 수 있습니다.

example.conf:

location @periodics {

# 작업자 프로세스 1과 3에서 15분 간격으로 실행
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 함수 핸들러(들) {
let reply = await ngx.fetch('https://nginx.org/en/docs/njs/');
let body = await reply.text();

ngx.log(ngx.INFO, body);
}

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

더 나은 NGINX 스타트업 경험

NGINX 구성에 많은 수의 "위치"가 포함된 시나리오에서는 NGINX 시작 시간이 상당히 길어질 수 있습니다. 많은 경우 이는 허용되지 않을 수도 있습니다. 근본적인 문제는 위치 목록을 정렬하는 데 사용되는 정렬 알고리즘에 있습니다.

NGINX R31은 시간 복잡도가 O(n2) 인 삽입 정렬 을 시간 복잡도가 O(n*log n) 인 병합 정렬 로 바꾸는 향상된 기능을 도입했습니다.

20,000개 위치를 대상으로 한 테스트 구성에서 이 업데이트 이후 총 시작 시간이 8초에서 0.9초로 단축된 것으로 관찰되었습니다.

QUIC+HTTP/3 최적화 및 개선

NGINX Plus R31은 QUIC+HTTP/3 구현에 다음과 같은 여러 가지 향상 및 성능 최적화를 도입했습니다.

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

추가적인 성능 최적화로는 확인 패킷을 보낼 때 잠재적인 지연을 줄이고, 프레임 재전송과 ACK 프레임 전달 지연을 줄이기 위해 확인(ACK) 프레임을 대기열의 앞에 두고, 일반 분할 오프로드(GSO) 모드에서 혼잡 제어 동작을 개선하는 것이 있습니다.

NGINX Plus R31의 기타 개선 사항 및 버그 수정

추가 관리 모듈

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

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

MQTT 모듈의 버그 수정

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

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

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

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

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

NGINX 오픈 소스에서 상속된 변경 사항

NGINX Plus R31은 NGINX Open Source 1.25.3을 기반으로 하며 NGINX Plus R30이 출시된 이후(NGINX 1.25.2 및 1.25.3) 기능 변경, 특징 및 버그 수정을 계승했습니다.

특징

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

변화

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

버그 수정

• HTTP/2 자동 감지를 통한 고정 버퍼 관리 – 일반 TCP 연결에서 HTTP/2 자동 감지의 일부로 초기 데이터는 상태 예약이 없는 client_header_buffer_size 지시문으로 지정된 버퍼로 먼저 읽혀집니다. 이로 인해 상태를 저장하는 동안 버퍼가 과도하게 읽히는 문제가 발생했습니다. 현재 수정 사항에서는 고정된 버퍼 크기 대신 사용 가능한 버퍼 크기만 읽을 수 있도록 허용합니다. 이 버그는 NGINX 메인라인 버전 1.25.1(NGINX Plus R30)에서 처음 나타났습니다.
• OpenSSL 호환 모드에서 잘못된 전송 모드 - 이 릴리스 이전에는 클라이언트가 잘못된 전송 매개변수를 보낸 경우 OpenSSL 호환성 계층이 연결을 지연시켰습니다. 이 수정 프로그램은 잘못된 매개변수를 사용자에게 먼저 알리고 이후 연결을 닫음으로써 이러한 동작을 손쉽게 처리합니다.
• 이유 구문이 없는 tatus 헤더의 고정 처리 - 상태와 같이 비어 있는 "이유 구문"이 있는 상태 헤더: 404는 CGI(Common Gateway Interface) 사양에 따라 유효했지만 구문 분석 중에 마지막 공백이 손실되었습니다. 이로 인해 응답에 HTTP/1.1 404 상태 줄이 표시되는데, 이는 끝에 공백이 없기 때문에 HTTP 사양을 위반합니다. 이 버그 수정을 통해 이렇게 짧은 상태 헤더 줄에서는 상태 코드만 사용되므로, NGINX가 공백과 적절한 이유 구문(사용 가능한 경우)을 포함한 상태 줄을 직접 생성하게 됩니다.
• PCRE2로 구성을 다시 로드할 때 발생하는 고정 메모리 누수 - 이 문제는 NGINX가 버전 1.21.5 이상에서 PCRE2를 사용하도록 구성된 경우 발생했습니다.

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

NGINX JavaScript 모듈의 변경 사항

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

특징

• 콘솔 객체를 도입했습니다. error() , info() , log() , time() , timeEnd() , warn() 메서드가 도입되었습니다.
• http 와 stream에 대한 js_periodic 지시어를 도입하여 정기적인 간격으로 실행될 JS 핸들러를 지정할 수 있게 되었습니다.
• 공유 사전 의 items() 메서드를 구현했습니다. 이 메서드는 만료되지 않은 모든 키-값 쌍을 반환합니다.

변화

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

버그 수정

• “xml” 모듈을 수정했습니다. parse() 메서드에서 깨진 XML 예외 처리를 수정했습니다.
• 전역 정규 표현식(regexp)과 유니코드 입력을 사용하여 RegExp.prototype.exec()를 수정했습니다.
• 공유 사전 의 고정된 size() 및 keys() 메서드.
• 0.8.0에 도입된 r.internalRedirect() 의 잘못된 예외를 수정했습니다.
• Object.getOwnPropertyNames() 에서 키의 잘못된 순서를 수정했습니다.
• Fetch API에서 Content-Length가 큰 경우의 HEAD 응답 처리를 고정했습니다.
• 공유 사전에 대한 items() 메서드를 고정했습니다.

모든 기능, 변경 사항 및 버그 수정의 포괄적인 목록은 njs 변경 로그를 참조하세요.

업그레이드 또는 NGINX Plus를 사용해 보세요

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R31로 업그레이드하는 것을 적극 권장합니다. 모든 훌륭한 새로운 기능 외에도 여러 가지 추가 수정 사항과 개선 사항을 얻을 수 있으며, 최신 상태를 유지하면 지원 티켓을 제출해야 할 경우 NGINX에서 도움을 드릴 수 있습니다.

NGINX Plus를 사용해보지 않으셨다면, 꼭 확인해보시기 바랍니다. 보안, 부하 분산 및 API 게이트웨이 사용 사례에 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용할 수 있습니다. 오늘 무료 30일 체험판을 시작해 보세요.