NGINX Plus R31 발표

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

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

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

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

동작의 중요한 변경 사항

주: NGINX Plus R30 이외의 릴리스에서 업그레이드하는 경우, 현재 버전과 이 버전 사이의 모든 릴리스에 대해 이전 공지 블로그의 동작의 중요 변경 사항> 섹션에서 확인하시기 바랍니다.

OpenTracing 모듈의 사용 중단

NGINX Plus R18에 도입된 OpenTracing 모듈은 이제 더 이상 사용되지 않습니다. 이 모듈은 향후 출시될 NGINX Plus R34 릴리스부터 제거될 예정입니다. 이 패키지는 그때까지 모든 NGINX Plus 릴리스에서 사용할 수 있습니다. NGINX Plus R29에 도입된 오픈 텔레메트리 모듈를 사용할 것을 강력히 권장합니다.

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

NGINX Plus 사용자는 규정 준수를 위해 NGINX 사용량을 F5에 보고해야 합니다. NGINX Plus R31 릴리스에서는 < data-dl-uid="57">NGINX 인스턴스 관리자에 NGINX 사용량을 보고하는 기능이 기본적으로 제공되며 기본적으로 활성화되어 있습니다. 어떤 이유로든 NGINX 인스턴스가 NGINX 인스턴스 매니저에 사용량 정보를 제공할 수 없는 경우 경고 메시지가 기록됩니다.

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

플랫폼 지원 변경 사항

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

• FreeBSD 14
• Alpine 3.19

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

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

구형 운영 체제는 더 이상 사용되지 않으며 NGINX Plus R32에서 제거될 예정입니다:

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

새로운 기능 상세 정보

네이티브 NGINX 사용량 보고

NGINX Plus R31은 라이선스 규정 준수를 자동화하기 위해 네트워크에서 NGINX 인스턴스 매니저와의 네이티브 통신을 도입합니다. F5 Flex 소비 프로그램에 참여하는 경우, 더 이상 NGINX Plus 인스턴스를 수동으로 추적할 필요가 없습니다.

기본적으로 NGINX Plus는 시작 시 nginx-mgmt.local 호스트 이름의 DNS 조회를 통해 NGINX 인스턴스 매니저를 찾으려고 시도합니다. 호스트 이름은 구성할 수 있지만, 간단하게 하기 위해 로컬 DNS에 A 레코드를 추가하여 기본 호스트 이름을 NGINX 인스턴스 매니저를 실행하는 시스템의 IP 주소와 연결하는 것이 좋습니다. 그러면 NGINX Plus가 NGINX 인스턴스 매니저에 TLS 연결을 설정하여 30분마다 버전 번호, 호스트 이름, 고유 식별자를 보고합니다.

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

NGINX Plus가 nginx-mgmt.local 호스트 이름을 해결하거나 NGINX 인스턴스 매니저와 통신하는 데 문제가 있는 경우 오류 로그에 경고 메시지가 표시됩니다.

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

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

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

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

mgmt 구성 블록 설정 사용자 지정하기

NGINX Plus 인스턴스가 NGINX 인스턴스 매니저와 통신하는 방식을 미세 조정하려면 새로운 mgmt 구성 블록 및 관련 지시어를 사용하도록 선택할 수 있습니다. 이렇게 하면 사용자 지정 확인자를 정의하고, IP 주소 또는 대체 호스트 이름을 사용하여 NGINX 인스턴스 매니저 시스템을 식별하고, 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 인스턴스 매니저 다운로드 및 설치에 대한 자세한 내용은 설치 가이드를 참조하세요.

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

SNI 구성 개선 사항

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

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

NGINX Plus R31은 업스트림 서버별로 SNI를 구성할 수 있도록 지원합니다. $upstream_last_server_name 변수는 선택한 업스트림 서버의 이름을 참조합니다, 이 변수는 proxy_ssl_서버_이름 및 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 구성에 많은 수의 '위치'가 포함된 시나리오에서는 NGINX 시작 시간이 상당히 오래 걸릴 수 있습니다. 대부분의 경우 이는 허용되지 않을 수 있습니다. 근본적인 문제는 위치 목록을 정렬하는 데 사용되는 정렬 알고리즘에 있습니다.

NGINX R31은 기존 정렬 알고리즘을 시간 복잡도가 O(n2)인 insertion sort에서 시간 복잡도가 O(n*log n)인 merge sort로 바꾸는 향상된 기능을 도입했습니다.

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

QUIC+HTTP/3 최적화 및 개선 사항

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

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

추가 mgmt 모듈

MQTT 모듈의 버그 수정

HTTP/3 서버_토큰 변수를 사용한 지원

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

기능

변화

• 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)에서 처음 나타났습니다.
• 오픈SSL 호환 모드에서 잘못된 전송 모드 - 이 릴리스 이전에는 클라이언트에서 잘못된 전송 파라미터를 전송하는 경우 OpenSSL 호환 계층에서 연결이 지연되는 현상이 발생했습니다. 이 수정 사항은 먼저 사용자에게 잘못된 매개변수에 대해 알리고 이후 연결을 종료하여 이 동작을 손쉽게 처리합니다.
• <이유 구문이 없는 상태 헤더 처리 수정 - 상태와 같이 '이유 구문'이 빈 상태 헤더: 404와 같이 "이유 구문"이 비어 있는 상태 헤더는 CGI(일반 게이트웨이 인터페이스) 사양에 따라 유효하지만 구문 분석 중에 후행 공백이 손실되었습니다. 이로 인해 응답에 HTTP/1.1 404 상태 줄이 발생했으며, 이는 후행 공백이 누락되어 HTTP 사양을 위반하는 것입니다. 이 버그 수정에서는 이러한 짧은 상태 헤더 줄에서 상태 코드만 사용되므로 NGINX는 가능한 경우 공백과 적절한 이유 문구를 사용하여 상태 줄 자체를 생성합니다.
• PCRE2로 구성 재로드 시 메모리 누수 수정 - 이 문제는 버전 1.21.5 이상에서 NGINX가 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()가 추가되었습니다.
• JS 핸들러가 일정한 간격으로 실행되도록 지정할 수 있는 js_periodic 지시어를 http와 stream에 도입했습니다.
• 공유 사전의 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를 통해 완벽하게 지원되는 웹 서버로 사용할 수 있습니다. 

위 내용와 같이 NGINX Plus를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요