NGINX Plus R15 발표

저희의 주력 제품인 NGINX Plus의 15번째 버전이 출시되었다는 소식을 전해드리게 되어 기쁩니다. 2013년 최초 출시 이후 NGINX Plus는 기능 세트와 상업적 매력 측면에서 엄청나게 성장했습니다. 현재 NGINX Plus 고객은 [ngx_snippet name='nginx-plus-customers']명이 넘고 NGINX 오픈 소스 사용자는 [ngx_snippet name='number-sites'] 명이 넘습니다.

NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 모두 갖춘 유일한 제품입니다. NGINX Plus에는 수상 경력에 빛나는 지원과 더불어 현대적 애플리케이션을 설계할 때 복잡성을 줄이도록 설계된 독점적인 향상된 기능이 포함되어 있습니다.

NGINX Plus R15는 새로운 gRPC 지원, HTTP/2 서버 푸시, 개선된 클러스터링 지원, 향상된 API 게이트웨이 기능 등을 도입합니다.

• 기본 gRPC 지원 – gRPC는 Google에서 개발한 새로운 원격 프로시저 호출(RPC) 표준입니다. 이는 클라이언트와 서버가 통신하는 가볍고 효율적인 방법입니다. 이 새로운 기능을 사용하면 NGINX Plus에서 백엔드 서버로의 gRPC 트래픽을 SSL 종료, 라우팅하고 부하를 분산할 수 있습니다.
• HTTP/2 서버 푸시 – HTTP/2 서버 푸시를 사용하면 NGINX Plus는 클라이언트가 실제로 요청하기 전에 리소스를 전송하여 성능을 향상시키고 왕복 시간을 줄일 수 있습니다.
• 클러스터 간 상태 공유 – 이 릴리스에서는 Sticky Learn 세션 지속성에 사용되는 공유 메모리 데이터를 클러스터의 모든 NGINX Plus 인스턴스에서 공유할 수 있습니다. NGINX Plus의 다음 몇 차례 릴리스에서는 클러스터링 기능을 더욱 강화하고 새로운 클러스터 인식 기능을 도입할 예정입니다.
• OpenID Connect 통합 – 이제 NGINX Plus를 사용하여 모든 웹 애플리케이션에 SSO(Single Sign‑On)를 제공하고 OpenID Connect 인증 코드 흐름을 사용하고 클라이언트에 JSON 웹 토큰(JWT)을 발급할 수 있습니다. NGINX Plus는 CA Single Sign‑On(이전 SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity 및 기타 인기 있는 ID 공급자와 통합됩니다.
• NGINX JavaScript(njs) 모듈 향상 – njs 모듈(이전 nginScript)을 사용하면 NGINX Plus 요청 처리 중에 JavaScript 코드를 실행할 수 있습니다. HTTP용 njs 모듈은 이제 클라이언트 요청과 독립적이며 비동기적으로 HTTP 하위 요청을 발행할 수 있는 지원을 제공합니다. 이 기능은 JavaScript를 사용하여 API 호출을 수정하고 통합할 수 있는 유연성을 제공하여 API 게이트웨이 사용 사례에 유용합니다. HTTP와 TCP/UDP용 njs 모듈에는 이제 일반적인 해시 함수를 구현할 수 있는 암호화 라이브러리도 포함됩니다.

이번 릴리스에는 새로운 ALPN 변수, 여러 동적 모듈에 대한 업데이트 등 더 많은 새로운 기능이 추가되었습니다.

행동의 변화

• NGINX Plus R13에서는 완전히 새로운 NGINX Plus API가 도입되어, 업스트림 그룹의 동적 구성 및 확장된 메트릭을 비롯하여 이전에는 별도의 API로 구현되었던 기능을 사용할 수 있게 되었습니다. upstream_conf 및 status 지시어로 구성된 이전 API는 더 이상 사용되지 않습니다. 이러한 지침에 대한 구성을 확인하고 가능한 한 빨리 새로운 API 지침으로 변환하시기 바랍니다(자세한 내용은 블로그의 NGINX Plus R13 발표 참조). 다음 릴리스인 NGINX Plus R16 부터 더 이상 사용되지 않는 API는 제공되지 않습니다.
• 이번 릴리스에서는 NGINX Plus API가 버전 3으로 업데이트되었습니다. 이전 버전도 계속 지원됩니다. API 클라이언트 업데이트를 고려하고 있다면 API 호환성 문서를 참조하세요.
• 공식 저장소 에서 제공되는 NGINX Plus 패키지에는 이제 새로운 번호 매기기 체계가 적용되었습니다. NGINX Plus 패키지와 모든 동적 모듈은 이제 NGINX Plus 릴리스 번호를 표시합니다. 각 패키지 버전은 이제 NGINX Plus 버전과 일치하여 어떤 버전이 설치되어 있는지 더 명확하게 알 수 있고 모듈 종속성이 단순화되었습니다. 버전 번호로 패키지를 참조하는 자동화된 시스템을 사용하지 않는 한 이러한 변경 사항은 투명하게 적용됩니다. 그런 경우, 먼저 비생산 환경에서 업그레이드 프로세스를 테스트해 보세요.

NGINX Plus R15 기능 세부 정보

gRPC 지원

이 릴리스를 통해 NGINX Plus는 많은 조직이 이미 마이크로서비스와의 통신에 사용하고 있는 gRPC 트래픽을 프록시하고 로드 밸런싱할 수 있습니다. gRPC는 Google에서 고효율, 저지연 서비스 간 통신을 위해 설계한 오픈 소스, 고성능 원격 프로시저 호출(RPC) 프레임워크입니다. gRPC는 HTTP/2의 기능(흐름 제어, 멀티플렉싱, 저지연 양방향 트래픽 스트리밍)이 마이크로서비스를 대규모로 연결하는 데 이상적이기 때문에 HTTP 1.1이 아닌 HTTP/2를 전송 메커니즘으로 요구합니다.

gRPC에 대한 지원은 NGINX Open Source 1.13.10에서 도입되었으며 이제 NGINX Plus R15 에 포함되었습니다. 이제 gRPC 메서드 호출을 검사하고 라우팅하여 다음 작업을 수행할 수 있습니다.

• HTTP/2 TLS 암호화, 속도 제한, IP 주소 기반 액세스 제어 목록, 로깅을 포함한 NGINX Plus 기능을 게시된 gRPC 서비스에 적용합니다.
• 내부 서비스에 대한 gRPC 연결을 검사하고 프록시하여 단일 엔드포인트를 통해 여러 gRPC 서비스를 게시합니다.
• 추가 용량이 필요할 때 업스트림 백엔드 풀에 gRPC 연결 로드 밸런싱을 통해 gRPC 서비스를 확장합니다.
• NGINX Plus를 gRPC 및 RESTful 엔드포인트에 대한 API 게이트웨이로 사용하세요.

자세한 내용은 블로그의 NGINX 1.13.10에서 gRPC 지원 소개를 참조하세요.

HTTP/2 서버 푸시

첫인상은 중요하며, 페이지 로드 시간은 사용자가 웹사이트를 다시 방문할지 여부를 결정하는 데 중요한 요소입니다. HTTP/2 서버 푸시를 통해 사용자에게 더 빠른 응답을 제공하는 한 가지 방법은 사용자가 기다려야 하는 RTT(왕복 시간, 요청과 응답에 필요한 시간) 수를 줄이는 것입니다.

HTTP/2 서버 푸시는 NGINX 오픈 소스 커뮤니티에서 많은 요청을 받고 기대했던 기능으로, NGINX 오픈 소스 1.13.9에 도입되었습니다. 이제 NGINX Plus R15 에 포함되었으며, 이를 통해 서버는 이전에 클라이언트가 시작한 요청을 완료하는 데 필요할 가능성이 있는 데이터를 사전에 전송할 수 있습니다. 예를 들어, 브라우저는 웹사이트 페이지를 렌더링하기 위해 스타일 시트, 이미지 등 다양한 리소스가 필요하므로, 브라우저가 해당 리소스를 명시적으로 요청할 때까지 기다리기보다는, 클라이언트가 처음 페이지에 액세스할 때 즉시 해당 리소스를 보내는 것이 합리적일 수 있습니다.

아래 구성 예에서 http2_push 지시문을 사용하여 클라이언트에게 데모 웹 페이지를 렌더링하는 데 필요한 스타일 시트와 이미지를 제공합니다.

그러나 어떤 경우에는 클라이언트에 필요한 정확한 리소스 세트를 파악할 수 없어 NGINX 설정 파일에 특정 파일을 나열하는 것이 비실용적입니다. 이런 경우, NGINX는 HTTP 링크 헤더를 가로채서 해당 헤더에 미리 로드된 것으로 표시된 리소스를 푸시할 수 있습니다. Link 헤더 가로채기를 활성화하려면 http2_push_preload 지시문을 on 으로 설정합니다.

자세한 내용은 블로그의 NGINX 1.13.9와 함께 HTTP/2 서버 푸시 소개를 참조하세요.

클러스터 전체에서 상태 공유

여러 대의 NGINX Plus 서버를 고가용성 클러스터로 구성하면 애플리케이션의 복원력이 높아지고 애플리케이션 스택의 단일 장애 지점이 제거됩니다. NGINX Plus 클러스터링은 복원성과 고가용성이 가장 중요한 미션 크리티컬 프로덕션 배포를 위해 설계되었습니다. NGINX Plus를 사용하여 고가용성 클러스터링을 배포하기 위한 솔루션은 다양합니다.

클러스터링 지원은 NGINX Plus의 이전 릴리스에서 도입되었으며 두 계층의 클러스터링을 제공합니다.

• keepalived 패키지를 사용한 네트워크 복원력 – NGINX Plus 서버가 다운될 경우 장애 조치를 처리합니다.
• nginx-sync 패키지를 사용한 구성 동기화 – 모든 NGINX Plus 서버에서 구성이 동기화되도록 보장합니다.

NGINX Plus R15는 런타임 중 상태 공유라는 세 번째 계층의 클러스터링을 도입하여 클러스터 노드 간 공유 메모리 영역의 데이터를 동기화할 수 있게 해줍니다. 구체적으로, Sticky Learn 세션 지속성을 위해 공유 메모리 영역에 저장된 데이터를 이제 TCP/UDP 트래픽을 위한 새로운 zone_sync 모듈을 사용하여 클러스터의 모든 노드에서 동기화할 수 있습니다.

새로운 zone_sync 모듈

상태 공유를 사용하면 기본 노드가 없습니다. 모든 노드가 피어이며 전체 메시 토폴로지 에서 데이터를 교환합니다. 또한, 상태 공유 클러스터링 솔루션은 네트워크 복원력을 위한 고가용성 솔루션과 독립적입니다. 따라서 상태 공유 클러스터는 물리적 위치에 걸쳐 있을 수 있습니다.

NGINX Plus 상태 공유 클러스터는 세 가지 요구 사항을 충족해야 합니다.

• 모든 클러스터 노드 간의 네트워크 연결
• 동기화된 시계
• 모든 노드에서 구성하면 다음과 같이 zone_sync 모듈이 활성화됩니다.

zone_sync 지시어는 클러스터의 공유 메모리 영역 동기화를 활성화합니다. zone_sync_server 지시어는 클러스터의 다른 NGINX Plus 인스턴스를 식별합니다. NGINX Plus는 DNS 서비스 검색을 지원하므로 클러스터 멤버를 호스트 이름으로 식별할 수 있으며, 각 클러스터 멤버의 구성이 동일합니다.

위의 최소 구성에는 프로덕션 배포 시 동기화 데이터를 보호하는 데 필요한 보안 제어 기능이 부족합니다. 다음 구성 스니펫은 여러 가지 안전 장치를 사용합니다.

• 동기화 데이터의 SSL/TLS 암호화
• 클라이언트 인증서 인증, 즉 각 클러스터 노드가 다른 노드와 자신을 식별합니다(상호 TLS)
• IP 주소를 사용하는 ACL(액세스 제어 목록)을 통해 동일한 물리적 네트워크에 있는 NGINX Plus 노드만 동기화를 위해 연결할 수 있습니다.

Sticky Learn 세션 지속성을 위한 상태 공유

클러스터 전체에서 공유되는 상태 데이터를 사용하는 첫 번째 지원되는 NGINX Plus 기능은 Sticky Learn 세션 지속성 입니다. 세션 지속성은 클라이언트의 요청이 항상 클라이언트의 첫 번째 요청을 처리한 서버로 전달된다는 것을 의미하는데, 이는 세션 상태가 백엔드에 저장되어 있는 경우 유용합니다.

다음 구성에서, 스티키 학습 지시어는 세션 이라는 공유 메모리 영역을 정의합니다. sync 매개변수는 NGINX Plus가 공유 메모리 영역의 내용에 대한 메시지를 클러스터의 다른 노드에 게시하도록 지시하여 클러스터 전체 상태 공유를 활성화합니다.

상태 데이터 동기화가 제대로 작동하려면 클러스터 내의 모든 NGINX Plus 노드의 구성에 스티키 학습 지시어가 포함된 동일한 업스트림 블록과 zone_sync 모듈( 위에서 설명)을 활성화하는 지시어가 포함되어야 합니다.

메모 : 클러스터링 지원 및 Sticky Learn 세션 지속성은 NGINX Plus에서만 제공됩니다.

OpenID Connect 통합

많은 기업에서는 ID 및 액세스 관리(IAM) 솔루션을 사용하여 사용자 계정을 관리하고 여러 애플리케이션에 대한 SSO(Single Sign‑On) 환경을 제공합니다. 그들은 복잡성과 비용을 최소화하기 위해 새로운 애플리케이션과 기존 애플리케이션에 SSO를 확장하려고 하는 경우가 많습니다.

NGINX Plus R10에서는 OpenID Connect 토큰 검증 기능이 지원됩니다. 이번 릴리스에서는 NGINX Plus가 OpenID Connect 1.0 인증을 위한 권한 부여 코드 흐름을 제어하고, ID 공급자와 통신하고, 클라이언트에 액세스 토큰을 발급할 수 있도록 해당 기능을 확장했습니다. 이를 통해 CA Single Sign‑On(이전 SiteMinder), ForgeRock OpenAM, Keycloak, Okta, OneLogin, Ping Identity를 포함한 대부분 주요 ID 공급자와 통합이 가능합니다. 새로 확장된 기능을 사용하면 다음 작업도 수행할 수 있습니다.

• 해당 애플리케이션을 수정하거나 현대화하지 않고도 레거시 애플리케이션에 SSO를 확장합니다.
• 애플리케이션 코드에서 SSO 또는 인증을 구현하지 않고도 새 애플리케이션에 SSO를 통합합니다.
• 공급업체 잠금을 제거하면 애플리케이션과 함께 독점적인 IAM 공급업체 에이전트 소프트웨어를 배포하지 않고도 표준 기반 SSO를 얻을 수 있습니다.

NGINX Plus와 OpenID Connect 통합은 GitHub에서 참조 구현으로 제공됩니다. GitHub 저장소 에는 특정 사용 사례에 대한 설치, 구성 및 미세 조정에 대한 지침이 포함된 샘플 구성이 포함되어 있습니다.

NGINX JavaScript 모듈의 향상

[ 편집자 - 다음 예제는 NGINX JavaScript 모듈의 많은 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈의 사용 사례를 참조하세요.

이 섹션의 코드는 블로그가 처음 게시된 이후 NGINX JavaScript 구현의 변경 사항을 반영하기 위해 다음과 같이 업데이트되었습니다.

• NGINX JavaScript 0.2.4 에 도입된 Stream 모듈의 리팩토링된 세션( 들 ) 객체를 사용합니다.
• 사용하려면 js_import 지시문은 다음을 대체합니다. js_포함 지시문에 NGINX 플러스 R23 그리고 나중에. 자세한 내용은 NGINX JavaScript 모듈 의 참조 문서를 참조하세요. 예제 구성 섹션에서는 NGINX 구성 및 JavaScript 파일에 대한 올바른 구문을 보여줍니다.

]

NGINX JavaScript 모듈인 njs(이전의 nginScript)를 사용하면 NGINX 구성에 JavaScript 코드를 포함시켜 HTTP 또는 TCP/UDP 요청이 처리될 때 런타임에 평가할 수 있습니다. 이를 통해 트래픽을 보다 세부적으로 제어하고, 애플리케이션 전반에 걸친 JavaScript 기능을 통합하고, 보안 위협으로부터 방어하는 등 다양한 잠재적 사용 사례가 가능해집니다.

NGINX Plus R15 에는 njs에 대한 두 가지 중요한 업데이트, 즉 하위 요청 과 해시 함수가 포함되어 있습니다.

하위 요청

이제 클라이언트 요청과 독립적이며 비동기적으로 동시 HTTP 요청을 발행할 수 있습니다. 이를 통해 다양한 고급 사용 사례가 가능해졌습니다.

다음 샘플 JavaScript 코드는 두 개의 서로 다른 백엔드에 동시에 HTTP 요청을 보냅니다. 첫 번째 응답은 클라이언트로 전달하기 위해 NGINX Plus로 전송되고 두 번째 응답은 무시됩니다.

해당 NGINX Plus 구성의 js_import 지시문은 fastest_wins.js 에서 JavaScript 코드를 읽습니다. 루트 위치( / )와 일치하는 모든 요청은 sendFastest() 함수로 전달되고, 이 함수는 /server_one 및 /server_two 위치에 대한 하위 요청을 생성합니다. 쿼리 매개변수가 포함된 원래 URI는 해당 백엔드 서버로 전달됩니다. 두 하위 요청 모두 done 콜백 함수를 실행합니다. 하지만 이 함수에는 r.return()이 포함되어 있으므로 먼저 완료된 하위 요청만 클라이언트에 응답을 보냅니다.

해시 함수

HTTP와 TCP/UDP 트래픽을 위한 njs 모듈에는 이제 다음을 구현한 암호화 라이브러리가 포함됩니다.

• 해시 함수: MD5, SHA‑1, SHA‑256
• HMAC 사용: MD5, SHA‑1, SHA‑256
• 다이제스트 형식: Base64, Base64URL, 16진수

해시 함수의 샘플 사용 사례는 애플리케이션 쿠키에 데이터 무결성을 추가하는 것입니다. 다음 njs 코드 샘플에는 쿠키에 디지털 서명을 추가하는 signCookie() 함수와 서명된 쿠키의 유효성을 검사하는 validateCookieSignature() 함수가 포함되어 있습니다.

다음 NGINX Plus 구성은 njs 코드를 사용하여 들어오는 HTTP 요청의 쿠키 서명을 검증하고 검증에 실패하면 클라이언트에 오류 메시지를 반환합니다. NGINX Plus는 검증이 성공하거나 쿠키가 없는 경우 요청을 프록시합니다.

NGINX Plus R15의 추가 새로운 기능

스트림 모듈에 대한 ALPN 변수

ALPN(애플리케이션 계층 프로토콜 협상)은 TLS의 확장 기능으로, 클라이언트와 서버가 TLS 핸드셰이크 중에 연결에 사용할 프로토콜을 협상할 수 있으며, 지연 시간을 발생시키고 사용자 경험을 저하시킬 수 있는 추가적인 왕복을 방지합니다. ALPN의 가장 일반적인 사용 사례는 클라이언트와 서버가 모두 HTTP/2를 지원하는 경우 HTTP에서 HTTP/2로 연결을 자동으로 업그레이드하는 것입니다.

NGINX 오픈 소스 1.13.10에서 처음 도입된 새로운 NGINX 변수 $ssl_preread_alpn_protocols 는 ALPN 사전 읽기 단계에서 클라이언트가 ClientHello 메시지에서 광고하는 프로토콜 목록을 캡처합니다. 아래 구성을 사용하면 XMPP 클라이언트는 ALPN을 통해 자신을 소개할 수 있으며, NGINX Plus는 XMPP 트래픽을 xmpp_backend 업스트림 그룹으로, gRPC 트래픽을 grpc_backend 로, 다른 모든 트래픽을 http_backend 로 라우팅하여 모든 트래픽을 단일 엔드포인트로 전달할 수 있습니다.

NGINX Plus가 ClientHello 메시지에서 정보를 추출하여 $ssl_preread_alpn_protocols 변수에 채우려면 ssl_preread on 지시어도 포함해야 합니다.

자세한 내용은 ngx_stream_ssl_preread 모듈에 대한 설명서를 참조하세요.

대기 시간 변수

NGINX Plus는 업스트림 큐잉을 지원하므로 업스트림 그룹의 모든 서버가 새로운 요청을 수락할 수 없는 경우 클라이언트 요청을 즉시 거부할 필요가 없습니다.

업스트림 큐잉의 일반적인 사용 사례는 모든 서버가 바쁜 경우 요청을 즉시 거부하지 않고도 백엔드 서버를 과부하로부터 보호하는 것입니다. 서버 지시문에 max_conns 매개변수를 사용하여 각 업스트림 서버에 대한 최대 동시 연결 수를 정의할 수 있습니다. 그런 다음 대기열 지시문은 연결 제한에 도달하거나 상태 검사 에 실패하여 백엔드를 사용할 수 없는 경우 요청을 대기열에 넣습니다.

이번 릴리스에서는 NGINX 오픈 소스 1.13.9에서 처음 도입된 새로운 NGINX 변수 $upstream_queue_time 은 요청이 대기열에서 소비한 시간을 포착합니다. 아래 구성에는 각 요청에 대한 다양한 타이밍 측정 항목을 캡처하는 사용자 지정 로그 형식이 포함되어 있습니다. 이러한 측정 항목은 성능 튜닝의 일부로 오프라인에서 분석할 수 있습니다. my_backend 업스트림 그룹의 대기 요청 수를 20으로 제한합니다. 시간 초과 매개변수는 오류 메시지가 클라이언트에 반환되기 전에 요청이 대기열에 보관되는 시간을 설정합니다.503 기본적으로). 여기서는 5초로 설정했습니다(기본값은 60초).

자세한 내용은 대기열 지시문에 대한 설명서를 참조하세요.

이스케이프 없이 액세스 로그

이제 NGINX Plus 액세스 로그에서 이스케이프 기능을 비활성화할 수 있습니다. NGINX 오픈 소스 1.13.10에서 처음 도입된 log_format 지시문의 새로운 escape=none 매개변수는 변수의 특수 문자에 이스케이프가 적용되지 않음을 지정합니다.

LDAP 인증 참조 구현 업데이트

LDAP 인증 시스템을 사용하여 사용자를 인증하기 위한 참조 구현이 문제를 해결하고 버그를 수정하도록 업데이트되었습니다. GitHub에서 확인해보세요 .

루트 권한이 없는 투명 프록싱

proxy_bind 지시문에 transparent 매개변수를 포함하여 NGINX Plus를 투명 프록시로 사용할 수 있습니다. 이제 작업자 프로세스는 마스터 프로세스로부터 CAP_NET_RAW Linux 기능을 상속받을 수 있으므로 NGINX Plus는 더 이상 투명 프록싱에 대한 특별한 권한이 필요하지 않습니다.

메모 : 이 기능은 Linux 플랫폼에만 적용됩니다.

JWT 유예 기간

JWT에 시간 기반 클레임( nbf (날짜 이전), exp (만료 날짜) 또는 둘 다)이 포함되어 있는 경우 NGINX Plus의 JWT 검증에는 현재 시간이 지정된 시간 간격 내에 있는지 확인하는 작업이 포함됩니다. 그러나 ID 공급자의 시계가 NGINX Plus 인스턴스의 시계와 동기화되지 않으면 토큰이 예기치 않게 만료되거나 미래에서 시작되는 것처럼 보일 수 있습니다. 두 시계 사이의 최대 허용 오차를 설정하려면 auth_jwt_leeway 지시어를 사용합니다.

쿠키 플래그 동적 모듈

쿠키 플래그를 설정하기 위한 타사 모듈은 이제 NGINX 저장소의 Cookie-Flag 동적 모듈로 사용 가능하며, NGINX Plus 지원 계약이 적용됩니다. 패키지 관리 도구를 사용하여 설치할 수 있습니다.

$ apt-get install nginx-plus-module-cookie-flag # Ubuntu/Debian$ yum install nginx-plus-module-cookie-flag     # Red Hat/CentOS

NGINX ModSecurity WAF 모듈 업데이트

ModSecurity 3.0 기반의 NGINX Plus용 동적 모듈인 NGINX ModSecurity WAF가 다음과 같은 향상된 기능으로 업데이트되었습니다.

• libmodsecurity 의 성능 개선
• ModSecurity-nginx 에서 메모리 누수 수정

[ 편집자 - NGINX ModSecurity WAF는 2022년 4월 1 일부로 공식적으로 판매 종료 되었으며 2024년 3월 31일 부터 수명 종료 로 전환됩니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF가 수명 종료로 전환 중입니다<.htmla>를 참조하세요.]

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

NGINX Plus R15 에는 클라이언트 애플리케이션을 위한 향상된 인증 기능, 추가 클러스터링 기능, njs 향상 및 주요 버그 수정이 포함되어 있습니다.

NGINX Plus를 사용하고 계시다면 가능한 한 빨리 릴리스 15로 업그레이드하는 것을 적극 권장합니다. 여러 가지 수정 사항과 개선 사항을 적용할 수 있으며, 업그레이드하면 지원 티켓을 제출해야 할 때 도움을 드릴 수 있습니다. NGINX Plus R15 에 대한 설치 및 업그레이드 지침은 고객 포털 에서 확인할 수 있습니다.

업그레이드를 진행하기 전에 이 블로그 게시물에 설명된 새로운 기능 과 동작의 변경 사항 을 주의 깊게 검토하세요.

NGINX Plus를 사용해 본 적이 없다면 웹 가속, 부하 분산, 애플리케이션 전송을 위해 사용해볼 수도 있고, 향상된 모니터링과 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용할 수도 있으니 한번 사용해 보시기 바랍니다. 오늘 무료 30일 평가판을 통해 무료로 시작해보세요. NGINX Plus가 어떻게 귀하의 애플리케이션을 제공하고 확장하는 데 도움이 될 수 있는지 직접 확인해 보세요.