NGINX Plus R31 출시 발표

Prabhat Dixit

NGINX Plus 릴리스 31(R31)이 출시되었음을 기쁘게 알려드립니다. NGINX Open Source를 기반으로 하는 NGINX Plus는 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 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은 구성에 “location”이 많은 경우 전반적인 NGINX 시작 환경을 개선합니다.
• QUIC+HTTP/3 최적화 및 개선 – NGINX Plus R31은 경로 최대 전송 단위(MTU) 검색 지원, 혼잡 제어 개선, 전체 QUIC 세션에서 암호화 컨텍스트를 재사용하는 기능 등 QUIC 구현에 다양한 기능 개선과 성능 최적화를 추가합니다.

이번 릴리스에는 NGINX Open Source에서 이어받은 새로운 기능과 버그 수정 사항, 그리고 NGINX JavaScript 모듈 업데이트도 포함됩니다.

중요한 동작 변경 사항

참고: NGINX Plus R30 이외의 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이에 출시된 모든 릴리스에 대해 중요한 동작 변경 사항 섹션을 이전 릴리스 발표 블로그에서 반드시 확인하세요.

OpenTracing 모듈 지원 중단

NGINX Plus R18에서 도입된 OpenTracing 모듈은 이제 더 이상 사용되지 않을 예정입니다. 향후 NGINX Plus R34 릴리스부터 제거될 예정입니다. 그때까지 이 패키지는 모든 NGINX Plus 릴리스에서 제공됩니다. NGINX Plus R29에서 도입된 OpenTelemetry 모듈을 사용할 것을 강력히 권장합니다.

NGINX 사용량 미보고에 대한 경고 메시지

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

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

플랫폼 지원 변경 사항

새롭게 지원되는 운영 체제:

• FreeBSD 14
• Alpine 3.19

지원이 종료된 이전 운영 체제:

• 2023년 11월 1일에 지원 종료(EOL)된 Alpine 3.15

지원 중단되었으며 NGINX Plus R32에서 제거될 예정인 이전 운영 체제:

• 2023년 12월 31일에 지원이 종료되는 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 [warn] 3050#3050: 사용량 보고서: 엔드포인트 "nginx-mgmt.local”을 확인하는 중 호스트를 찾을 수 없음

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

2023/12/21 21:02:01 [warn] 3184#3184: 사용량 보고서: 연결 시간 초과

Customizing the mgmt 구성 블록 설정 사용자 지정

NGINX Plus 인스턴스가 NGINX Instance Manager와 통신하는 방식을 세부적으로 조정하려면 새로운 mgmt 구성 블록과 관련 지시문을 사용할 수 있습니다. 이를 통해 사용자 지정 리졸버를 정의하고, IP 주소나 대체 호스트 이름을 사용하여 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;
}

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

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

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

SNI 구성 개선 사항

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

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

NGINX Plus R31에서는 업스트림 서버별로 SNI를 구성할 수 있는 기능이 도입되었습니다. 변수 $upstream_last_server_name은 선택된 업스트림 서버의 이름을 나타내며, 이 이름은 proxy_ssl_server_name 및 proxy_ssl_name 지시어를 사용하여 프록시 대상 서버에 전달할 수 있습니다.

다음과 같이 proxy_ssl_server_name을 on으로 설정하여 서버 이름이 SNI를 통해 전달되도록 할 수 있습니다.
proxy_ssl_server_name on;

선택한 업스트림 서버 이름을 전달하려면 다음과 같이 proxy_ssl_name을 사용합니다.
proxy_ssl_name $upstream_last_server_name;

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

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

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

이 지시어는 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 문서를 참조하세요.

더 나은 NGINX 시작 환경

NGINX 구성에 많은 수의 “location”이 포함된 경우 NGINX를 시작하는 데 상당한 시간이 걸릴 수 있습니다. 많은 경우 이는 허용하기 어려울 수 있습니다. 근본적인 문제는 location 목록을 정렬하는 데 사용되는 정렬 알고리즘에 있습니다.

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

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

QUIC+HTTP/3 최적화 및 개선

NGINX Plus R31에서는 QUIC+HTTP/3 구현에 다음과 같은 여러 개선 사항과 성능 최적화가 도입되었습니다:

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

추가적인 성능 최적화에는 확인 응답 패킷 전송 시 발생할 수 있는 지연 감소, 프레임 재전송 및 ACK 프레임 전달 지연을 줄이기 위해 확인 응답(ACK) 프레임을 대기열 맨 앞에 배치하는 작업, 그리고 GSO(Generic Segmentation Offload) 모드에서의 혼잡 제어 동작 개선이 포함됩니다.

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

추가 mgmt 모듈

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

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

MQTT 모듈의 버그 수정

메시지 큐 텔레메트리 전송(Message Queuing Telemetry Transport, MQTT) 지원은 NGINX Plus R29에서 도입되었으며 이번 릴리스에는 MQTT 모듈에서 발견된 문제에 대한 몇 가지 버그 수정 사항이 포함되어 있습니다.

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

또 다른 버그 수정으로 메시지 길이가 수신된 바이트 수보다 짧은 경우 MQTT CONNECT 메시지의 구문 분석이 중단됩니다.

HTTP/3 server_tokens 변수 지원

NGINX Plus R31에서는 HTTP/3 연결에 누락되었던 server_tokens 변수 지원이 추가되었습니다. string 필드를 사용하여 오류 페이지의 서명과 “Server” 응답 헤더 필드 값을 명시적으로 설정할 수 있습니다. string 필드가 비어 있으면 “Server” 필드가 전송되지 않습니다.

NGINX Open Source에서 상속된 변경 사항

NGINX Plus R31은 NGINX Open Source 1.25.3을 기반으로 하며, NGINX Plus R30 출시 이후 NGINX 1.25.2 및 1.25.3에서 이루어진 기능 변경 사항, 새로운 기능 및 버그 수정을 포함합니다.

기능

• QUIC 사용 시 경로 MTU 검색 – 이전에는 모든 데이터그램에 기본 MTU 크기인 1200이 사용되었습니다. 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가 정의되어 있고 참인지 검사합니다. 이를 통해 추가 라이브러리 초기화 설정(특히 OPENSSL_INIT_set_config_appname() 호출)을 제공하지 않는 BoringSSL 및 LibreSSL에서는 이 인터페이스가 사용되지 않습니다.

변경 사항

• NGINX 큐 정렬 알고리즘 변경 – 위에서 자세히 설명한 대로, NGINX는 이제 병합 정렬을 사용하며, 시간 복잡도는 O(n*log n)입니다. 이를 통해 NGINX 시작 환경이 개선되며, 특히 구성에 “location”이 매우 많은 경우 더욱 효과적입니다.
• 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 호환성 계층으로 인해 연결이 지연되었습니다. 이번 수정에서는 먼저 사용자에게 잘못된 매개변수를 알린 후 연결을 종료하여 이 동작을 원활하게 처리합니다.
• 이유 구문이 없는 상태 헤더 처리 수정 – Status: 404처럼 “이유 구문”이 비어 있는 상태 헤더는 CGI(Common Gateway Interface) 사양에 따라 유효하지만, 구문 분석 중 후행 공백이 손실되었습니다. 이로 인해 응답에 HTTP/1.1 404 상태 줄이 생성되었으며, 후행 공백이 없어 HTTP 사양을 위반했습니다. 이번 버그 수정으로 이러한 짧은 Status 헤더 줄에서는 상태 코드만 사용되므로, NGINX가 공백과 가능한 경우 적절한 이유 구문을 포함한 상태 줄을 직접 생성합니다.
• PCRE2 사용 시 구성 다시 로드 과정에서 발생하던 메모리 누수 수정 – 이 문제는 NGINX 버전 1.21.5 이상에서 PCRE2를 사용하도록 구성한 경우 발생했습니다.

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

NGINX JavaScript 모듈 변경 사항

NGINX Plus R31에는 NGINX JavaScript(njs) 모듈 버전 0.8.2의 변경 사항이 반영되었습니다. 다음은 NGINX Plus R30 릴리스에 포함되었던 0.8.0 이후 njs에서 주목할 만한 변경 사항 목록입니다.

기능

• console 객체가 도입되었습니다. 다음 메서드가 추가되었습니다: error(), info(), log(), time(), timeEnd(), warn().
• 정기적인 간격으로 실행할 JS 핸들러를 지정할 수 있는 js_periodic 지시문이 http 및 stream에 도입되었습니다.
• Implemented 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일 무료 평가판으로 시작해 보세요.

작성자 소개

Prabhat Dixit

Prabhat Dixit의 다른 블로그 게시물