당사의 주력 제품인 NGINX Plus의 열다섯 번째 버전이 출시되었음을 기쁘게 알려드립니다. 2013년 최초 출시 이후 NGINX Plus는 기능과 상업적 인지도 모두에서 크게 성장했습니다. 현재 [ngx_snippet name=’nginx-plus-customers’]곳이 넘는 고객이 NGINX Plus를 사용하고 있으며, [ngx_snippet name=’number-sites’]명의 사용자가 NGINX Open Source를 사용하고 있습니다.
NGINX Open Source를 기반으로 하는 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에서 OpenID Connect 인증 코드 흐름을 사용하고 클라이언트에 JSON 웹 토큰(JWT)을 발급하여 모든 웹 애플리케이션에 SSO(Single Sign-On)를 제공할 수 있습니다. 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 하위 요청을 실행할 수 있도록 지원합니다. 이는 API 게이트웨이 사용 사례에서 유용하며, JavaScript를 사용해 API 호출을 수정하고 통합할 수 있는 유연성을 제공합니다. 또한 이제 HTTP 및 TCP/UDP용 njs 모듈에는 일반적인 해시 함수를 구현할 수 있는 암호화 라이브러리가 포함됩니다.
이번 릴리스에는 이 밖에도 더 많은 새로운 기능이 추가되었습니다. 여기에는 새로운 ALPN 변수, 여러 동적 모듈 업데이트 등이 포함됩니다.
동작 변경 사항
- NGINX Plus R13에서는 완전히 새로운 NGINX Plus API가 도입되었습니다. 이 API는 업스트림 그룹의 동적 구성과 확장 메트릭을 비롯하여 이전에 별도의 API로 구현되었던 기능을 제공합니다. 기존 API는
upstream_conf및status지시문으로 구성되며 더 이상 사용되지 않습니다. 구성에 이러한 지시문이 있는지 확인하고 가능한 한 빨리 새로운api지시문으로 전환하시기 바랍니다(자세한 내용은 블로그의 NGINX Plus R13 발표 참조). 다음 릴리스인 NGINX Plus R16부터는 더 이상 사용되지 않는 API가 제공되지 않습니다. - 이번 릴리스에서 NGINX Plus API가 버전 3으로 업데이트되었습니다. 이전 버전도 계속 지원됩니다. API 클라이언트 업데이트를 고려하고 있다면 API 호환성 문서를 참조하세요.
- NGINX Plus packages available at the 공식 리포지토리에서 제공되는 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를 전송 메커니즘으로 사용하도록 규정합니다.
NGINX는 gRPC 트래픽을 라우팅하고 SSL을 종료합니다
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(왕복 시간, 요청과 응답에 걸리는 시간) 횟수를 줄여 더 빠르게 응답할 수 있습니다.
NGINX는 성능 향상을 위해 클라이언트에 리소스를 선제적으로 푸시할 수 있습니다.
HTTP/2 서버 푸시는 NGINX 오픈 소스 커뮤니티에서 많은 요청과 기대를 받아 온 기능으로, NGINX Open Source 1.13.9에서 처음 도입되었습니다. 이제 NGINX Plus R15에도 포함된 이 기능을 사용하면 서버가 클라이언트에서 이전에 시작한 요청을 완료하는 데 필요할 것으로 예상되는 데이터를 미리 전송할 수 있습니다. 예를 들어 브라우저가 웹사이트 페이지를 렌더링하려면 스타일시트, 이미지 등 다양한 리소스가 필요하므로, 브라우저가 해당 리소스를 명시적으로 요청할 때까지 기다리는 대신 클라이언트가 페이지에 처음 액세스할 때 즉시 전송하는 것이 효율적일 수 있습니다.
아래 구성 예에서는 클라이언트가 http2_push 지시어를 사용하여 demo 웹 페이지를 렌더링하는 데 필요한 스타일시트와 이미지를 미리 받도록 합니다:
코드 예제를 로드하는 중…
하지만 경우에 따라서는 클라이언트에 필요한 리소스의 정확한 집합을 파악할 수 없어 NGINX 구성 파일에 특정 파일을 나열하는 것이 현실적이지 않을 수 있습니다. 이 경우 NGINX는 HTTP Link 헤더를 가로채서 해당 헤더에서 preload로 표시된 리소스를 푸시할 수 있습니다. Link 헤더 가로채기를 활성화하려면 http2_push_preload 지시어를 on으로 설정합니다.
코드 예제를 로드하는 중…
자세한 내용은 블로그의 NGINX 1.13.9를 통한 HTTP/2 서버 푸시 소개를 참조하세요.
클러스터 전체에서 상태 공유
여러 NGINX Plus 서버를 고가용성 클러스터로 구성하면 애플리케이션의 복원력이 향상되고 애플리케이션 스택의 단일 장애 지점이 제거됩니다. NGINX Plus 클러스터링은 복원력과 고가용성이 무엇보다 중요한 미션 크리티컬 프로덕션 배포를 위해 설계되었습니다. NGINX Plus를 사용한 고가용성 클러스터링을 배포하는 방법은 다양합니다.
클러스터링 지원은 이전 NGINX Plus 릴리스에서 도입되었으며, 다음과 같은 두 가지 수준의 클러스터링을 제공합니다:
- keepalived 패키지를 사용한 네트워크 복원력 – NGINX Plus 서버가 중단될 경우 장애 조치를 처리합니다.
- Configuration synchronization using the
nginx-sync패키지를 사용한 구성 동기화 – 모든 NGINX Plus 서버에서 구성이 동기화되도록 합니다.
NGINX Plus R15에서는 클러스터링의 세 번째 계층인 런타임 중 상태 공유 기능을 도입하여 클러스터 노드 간에 공유 메모리 영역의 데이터를 동기화할 수 있습니다. 구체적으로, 이제 Sticky Learn 세션 지속성을 위해 공유 메모리 영역에 저장된 데이터를 TCP/UDP 트래픽용 새 zone_sync 모듈을 사용하여 클러스터의 모든 노드에서 동기화할 수 있습니다.
새로운 zone_sync 모듈
상태 공유에서는 기본 노드가 없으며, 모든 노드가 동등한 피어로서 풀 메시 토폴로지를 통해 데이터를 교환합니다. 또한 상태 공유 클러스터링 솔루션은 네트워크 복원력을 위한 고가용성 솔루션과 독립적입니다. 따라서 상태 공유 클러스터는 여러 물리적 위치에 걸쳐 구성할 수 있습니다.
NGINX Plus 상태 공유 클러스터는 다음 세 가지 요구 사항을 충족해야 합니다:
- 모든 클러스터 노드 간의 네트워크 연결
- 동기화된 시계
- 모든 노드의 구성에서 다음과 같이
zone_sync모듈을 활성화합니다.코드 예제를 로드하는 중…
The zone_sync 지시문은 클러스터 내 공유 메모리 영역의 동기화를 활성화합니다. zone_sync_server 지시문은 클러스터의 다른 NGINX Plus 인스턴스를 식별합니다. NGINX Plus는 DNS 서비스 검색을 지원하므로 호스트 이름으로 클러스터 구성원을 식별할 수 있으며, 이에 따라 모든 클러스터 구성원에 동일한 구성을 사용할 수 있습니다.
위의 최소 구성에는 프로덕션 배포 환경에서 동기화 데이터를 보호하는 데 필요한 보안 제어가 없습니다. 다음 구성 코드 조각에는 이러한 보호 조치가 몇 가지 적용되어 있습니다:
- 동기화 데이터의 SSL/TLS 암호화
- 클라이언트 인증서 인증을 통해 각 클러스터 노드가 다른 노드에 자신을 식별하도록 함(상호 TLS)
- IP 주소를 사용하는 액세스 제어 목록(ACL)을 통해 동일한 물리적 네트워크에 있는 NGINX Plus 노드만 동기화를 위해 연결할 수 있도록 합니다.
코드 예제를 로드하는 중…
Sticky Learn 세션 지속성을 위한 상태 공유
클러스터 전체에서 공유되는 상태 데이터를 사용하는 최초의 NGINX Plus 지원 기능은 Sticky Learn 세션 지속성입니다. 세션 지속성이란 클라이언트의 요청이 항상 해당 클라이언트의 첫 번째 요청을 처리한 서버로 전달되는 것을 의미하며, 세션 상태가 백엔드에 저장되는 경우 유용합니다.
다음 구성에서 sticky learn 지시문은 sessions라는 공유 메모리 영역을 정의합니다. sync 매개변수는 NGINX Plus가 공유 메모리 영역의 콘텐츠에 관한 메시지를 클러스터의 다른 노드에 게시하도록 하여 클러스터 전체에서 상태를 공유할 수 있게 합니다.
상태 데이터 동기화가 올바르게 작동하려면 클러스터의 모든 NGINX Plus 노드 구성에 동일한 upstream 블록과 sticky learn 지시문뿐만 아니라 zone_sync 모듈을 활성화하는 지시문도 포함되어야 합니다(위에서 설명).
코드 예제를 로드하는 중…
참고: 클러스터링 지원 및 Sticky Learn 세션 지속성 기능은 NGINX Plus에서만 제공됩니다.
OpenID Connect 통합
많은 기업이 ID 및 액세스 관리(IAM) 솔루션을 사용하여 사용자 계정을 관리하고 여러 애플리케이션에 SSO(Single Sign-On) 환경을 제공합니다. 또한 복잡성과 비용을 최소화하기 위해 신규 및 기존 애플리케이션 전반으로 SSO를 확장하고자 하는 경우가 많습니다.
“NGINX Plus에서 OpenID Connect를 사용함으로써 ID 공급자와 빠르고 손쉽게 통합하는 동시에 애플리케이션 아키텍처를 간소화할 수 있었습니다.” – Scott Macleod, 소프트웨어 엔지니어, NHS Digital
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 구현을 반영하기 위해 다음과 같이 업데이트되었습니다:
- 리팩터링된 세션(
s) 객체를 Stream 모듈에서 사용하도록 변경했습니다. 이 객체는 NGINX JavaScript 0.2.4에서 도입되었습니다. - 사용하려면
js_import지시문을 사용합니다. 이 지시문은js_include지시문을 NGINX Plus 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 변수 $ssl_preread_alpn_protocols는 NGINX Open Source 1.13.10에서 처음 도입되었으며, 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 매개변수를 server 지시문에 지정하여 정의할 수 있습니다. 그러면 queue 지시문은 연결 한도에 도달했거나 상태 확인에 실패하여 사용 가능한 백엔드가 없을 때 요청을 큐에 넣습니다.
이번 릴리스에서는 새로운 NGINX 변수 $upstream_queue_time가 도입되었습니다. NGINX Open Source 1.13.9에서 처음 도입된 이 변수는 요청이 대기열에서 머무는 시간을 기록합니다. 아래 구성에는 각 요청의 다양한 시간 측정값을 기록하는 사용자 지정 로그 형식이 포함되어 있으며, 이 측정값은 성능 튜닝의 일환으로 오프라인에서 분석할 수 있습니다. my_backend 업스트림 그룹에서 대기열에 추가할 수 있는 요청 수를 20개로 제한합니다. timeout 매개변수는 클라이언트에 오류 메시지가 반환되기 전까지 요청을 대기열에 유지할 시간을 설정합니다(기본값: 503). 여기서는 5초로 설정합니다(기본값은 60초).
코드 예제를 로드하는 중…
자세한 내용은 queue 지시어 문서를 참조하세요.
이스케이프 처리되지 않은 액세스 로그
이제 NGINX Plus 액세스 로그에서 이스케이프 처리를 비활성화할 수 있습니다. 새로운 escape=none 매개변수는 log_format 지시문에 사용되며, NGINX Open Source 1.13.10에서 처음 도입되었습니다. 이 매개변수를 지정하면 변수의 특수 문자에 이스케이프 처리가 적용되지 않습니다.
LDAP 인증 참조 구현 업데이트
LDAP 인증 시스템을 사용해 사용자를 인증하는 참조 구현이 문제를 해결하고 버그를 수정하도록 업데이트되었습니다. GitHub에서 확인해 보세요.
root 권한 없는 투명 프록시
NGINX Plus를 투명 프록시로 사용하려면 transparent 매개변수를 proxy_bind 지시문에 포함하면 됩니다. 이제 워커 프로세스가 마스터 프로세스로부터 Linux의 CAP_NET_RAW 기능을 상속할 수 있으므로 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/CentOSNGINX ModSecurity WAF 모듈 업데이트
NGINX ModSecurity WAF는 ModSecurity 3.0을 기반으로 하는 NGINX Plus용 동적 모듈로, 다음과 같은 개선 사항이 적용되었습니다:
- 성능 개선 사항:
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가 애플리케이션을 제공하고 확장하는 데 어떻게 도움이 되는지 직접 확인해 보세요.
작성자 소개

관련 블로그 게시물
시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.
F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.
Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.
진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.
NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.
Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.