NGINX Plus R10 출시 발표

NGINX | 2016년 8월 23일


[편집자 – NGINX Plus용 NGINX ModSecurity WAF 모듈은 2022년 4월 1일부로 공식 판매 종료되었으며, 2024년 3월 31일부로 지원 종료될 예정입니다. 자세한 내용은 블로그의 F5 NGINX ModSecurity WAF 지원 종료 전환 안내<.htmla>를 참조하세요.]

지금까지 가장 중요한 릴리스인 NGINX Plus 릴리스 10(R10)을 발표하게 되어 기쁩니다. NGINX Plus는 NGINX Open Source에 고급 기능과 수상 경력에 빛나는 지원을 더해 고객에게 완전한 애플리케이션 전송 솔루션을 제공합니다. 이번 릴리스에서는 NGINX Plus를 통해 제공되는 애플리케이션의 보안과 성능을 획기적으로 개선하는 여러 새로운 기능과 더불어, 네트워크 통합을 개선하고 스크립팅을 통한 NGINX Plus 사용자 지정을 지원하는 추가 기능을 제공합니다.

[편집자 – NGINX Plus R10의 주요 신기능에 대한 자세한 내용은 다음 관련 자료를 참조하세요:

]

NGINX Plus R10에는 당사의 웹 애플리케이션 방화벽(WAF),이 처음으로 탑재되었습니다. 이 방화벽은 ModSecurity를 기반으로 하며 NGINX, Inc.에서 전면 지원합니다. 지난 1년간 웹 애플리케이션 공격은 50% 증가했고, DDoS 공격은 두 배 이상 늘었습니다. 이는 Akamai에 따르면 그렇습니다. 이제 모든 애플리케이션이 공격 위험에 노출되어 있습니다. NGINX ModSecurity WAF는 악의적인 사용자로부터 웹 애플리케이션을 보호하고, 고객이 애플리케이션과 데이터를 안전하게 지킬 수 있도록 다용도 도구를 제공합니다.

NGINX ModSecurity WAF는 침입자를 차단합니다

NGINX ModSecurity WAF는 새로운 ModSecurity 3 소프트웨어를 기반으로 하며 NGINX Plus 내에서 네이티브로 실행됩니다. 동적 모듈 리포지토리에서 추가 비용 옵션으로 제공되고 NGINX, Inc.의 지원을 받으며, NGINX Plus와 함께 철저한 테스트를 거쳤습니다. 당사는 Trustwave와 협력하고 있으며, 기능을 추가하고 성능을 개선하며 문제를 해결하는 과정에서 테스트를 거친 업데이트를 지속적으로 제공할 예정입니다.

두 가지 새로운 추가 기능으로 NGINX Plus의 보안 기능이 한층 더 강화되었습니다:

  • JSON 웹 토큰 – 많은 고객이 NGINX Plus를 API 게이트웨이로 사용하며, NGINX Plus 계층에서 API 액세스를 인증할 수 있는 보편적이고 표준화된 방법을 요청해 왔습니다. 이러한 요구를 충족하기 위해 이번 릴리스에서는 JSON 웹 토큰(JWT)을 사용한 인증 지원을 추가했습니다. 이제 NGINX Plus는 클라이언트의 API 액세스를 허용하기 전에 JWT를 검증할 수 있습니다. 이 기능을 통해 애플리케이션 관리자는 개방형 표준으로 API 액세스를 보호하여 독점 표준에 대한 특정 공급업체 종속을 방지할 수 있습니다. 또한 기본 JWT 지원은 OAuth 2.0 호환 OpenID Connect 토큰 검증과 같은 인증 작업을 애플리케이션 서버에서 NGINX Plus로 이전하여 애플리케이션 관리자의 복잡성을 줄여 줍니다.
  • ECC 및 RSA 인증서에 대한 “듀얼 스택” 지원 – NGINX Plus R10에서는 RSA 및 ECC 인증서를 모두 사용하여 SSL/TLS 서비스를 제공할 수 있습니다. NGINX Plus는 각 클라이언트의 기능에 따라 최적의 인증서를 선택하므로, 기존의 RSA 전용 클라이언트를 계속 지원하면서 최신 클라이언트에는 더 빠른 ECC 인증서를 사용할 수 있습니다. ECC 인증서는 동일한 보안 강도의 RSA 인증서보다 최대 3배 빠를 수 있으며, 이에 따라 서버당 SSL/TLS 연결 수가 늘어나고 SSL/TLS 핸드셰이크 속도도 빨라집니다.

NGINX Plus R10에는 보안 기능 외에도 다음이 포함됩니다:

  • 투명 프록시 지원 – 많은 최신 HTTP 애플리케이션은 X-Forwarded-For 헤더를 사용하도록 구성할 수 있지만, 일부 레거시 애플리케이션과 기타 TCP 또는 UDP 서비스는 로깅, 보안 또는 인증을 위해 트랜잭션의 소스 IP 주소를 참조합니다. 이제 NGINX Plus는 업스트림 서버로 전달하는 HTTP 및 TCP 연결과 UDP 데이터그램의 소스 IP 주소와 포트를 ‘스푸핑’할 수 있습니다. 이를 통해 IP 투명성을 구현할 수 있습니다. IP 투명성은 NGINX Plus가 원격 클라이언트의 IP 주소로 패킷을 전송하여 업스트림 서버가 해당 패킷을 NGINX Plus 서버의 로컬 IP 주소가 아닌 원격 클라이언트의 주소에서 전송된 것으로 인식하게 하는 구성입니다. 이 기능을 사용하여 UDP 기반 프로토콜에 대해 DSR(Direct Server Return)을 활성화할 수도 있습니다.
  • NGINX JavaScript 모듈 지원 – NGINX JavaScript 모듈은 NGINX 및 NGINX Plus를 위한 차세대 구성 및 제어 언어로, 애플리케이션의 제공 및 보안 방식을 세밀하고 정교하게 제어할 수 있도록 지원합니다. 이번 프리뷰 릴리스에서는 NGINX JavaScript 모듈을 통해 HTTP, TCP 및 UDP 트래픽을 더욱 효과적으로 제어하고, 응답을 생성하며, 요청을 최적의 서버로 라우팅하기 위한 정밀한 결정을 내릴 수 있습니다.

NGINX Plus R10 자세히 알아보기

NGINX ModSecurity 웹 애플리케이션 방화벽

NGIN Plus R10의 핵심 기능은 널리 알려지고 신뢰받는 ModSecurity 기술을 기반으로 구축된 WAF의 첫 번째 릴리스입니다. ModSecurity는 2002년에 오픈 소스로 처음 출시된 이래 악의적인 사용자로부터 세계 최대 규모의 웹 자산을 보호하는 데 기여해 왔습니다. 보안 분야의 “Swiss Army® knife”라고도 불립니다. NGINX ModSecurity WAF는 추가 비용이 드는 옵션이며, 동적 모듈 리포지토리를 통해 구독자에게 제공됩니다.

NGINX ModSecurity WAF는 핵심 애플리케이션의 보안을 강화하는 데 꼭 필요한 솔루션입니다. 유연성이 부족하고 비용이 많이 드는 하드웨어 어플라이언스—예를 들어 F5, Citrix, Imperva에서 제공하는 제품—를 대체할 수 있는 비용 효율적인 솔루션이며, 소프트웨어의 유연성을 바탕으로 이러한 제품의 기능을 뛰어넘습니다. NGINX ModSecurity WAF는 온프레미스 서버는 물론 퍼블릭, 프라이빗 및 하이브리드 클라우드 등 모든 환경에 배포할 수 있습니다.

NGINX ModSecurity WAF는 DDoS 공격으로부터 보호하는 데 도움이 됩니다

WAF는 차단 및/또는 기록할 악성 동작을 정의하는 ‘규칙’ 데이터베이스를 기반으로 작동합니다. OWASP ModSecurity 핵심 규칙 세트(CRS)는 ModSecurity에서 가장 널리 사용되는 규칙 세트 중 하나입니다. NGINX ModSecurity WAF는 OWASP CRS를 사용하여 광범위한 애플리케이션 공격을 식별하고 차단하며, 다음과 같은 기능을 제공합니다:

  • 계층 7 공격 방어 – HTTP 위반, SQL 인젝션, XSS, RFI, LFI 공격 등 광범위한 공격으로부터 애플리케이션을 보호합니다.
  • DDoS 완화 – 정교한 애플리케이션 계층 DDoS 공격과 봇넷의 영향을 완화하고 줄여 지속적인 가동 시간을 유지합니다.
  • 실시간 차단 목록 – 평판을 기반으로 악성으로 알려진 IP 주소의 트래픽을 거부하여 알려진 악성 사용자를 자동으로 차단합니다.
  • PCI-DSS 6.6 규정 준수 – 안전한 온라인 거래를 위한 PCI-DSS 6.6 요구 사항 준수를 시작하세요.
  • 감사 로깅 – 상세 로그의 정보를 활용하여 공격 및 기타 비정상적인 애플리케이션 트래픽에 더욱 신속하게 대응할 수 있습니다.

다음과 같은 여러 공급업체에서도 추가 규칙 세트를 제공합니다. 예: TrustWave, 가격대는 다양합니다. 또한 강력한 ModSecurity 규칙 언어를 사용하여 현재 사용 중인 규칙 세트를 보완하는 사용자 지정 규칙을 직접 정의할 수 있습니다.

NGINX ModSecurity WAF에 대한 지원은 NGINX, Inc.에서 직접 제공합니다. 지원 팀은 WAF 및 OWASP 핵심 규칙 세트의 설치와 구성, 문제 디버깅을 도와드릴 수 있습니다.

NGINX ModSecurity WAF는 표준 패키지 관리 도구를 사용하여 설치할 수 있는 동적 모듈로 NGINX Plus 리포지토리에서 제공됩니다. 다음 명령은 Debian 기반 운영 체제용입니다:

# apt-get update# apt-get install nginx-plus
# apt-get install nginx-plus-module-modsecurity

NGINX ModSecurity WAF 모듈을 구매한 구독자와 액세스를 요청한 구독자 및 평가판 사용자만 nginx-plus-module-modsecurity 패키지를 다운로드할 수 있습니다.

NGINX ModSecurity WAF 모듈을 로드하려면 NGINX Plus 구성 파일의 최상위 “main” 컨텍스트에 load_module 지시어를 포함합니다:

코드 예제를 로드하는 중…

NGINX Plus에서 NGINX ModSecurity WAF를 활성화하려면 규칙 세트를 지정하는 modsecurity 지시문과 modsecurity_rules_file 지시문을 포함합니다:

코드 예제를 로드하는 중…

그런 다음 NGINX Plus 구성을 다시 로드합니다:

# nginx -t && nginx -s reload

OAuth 2.0 및 OpenID Connect를 위한 네이티브 JWT 지원

JSON 웹 토큰(JWT) 인증 표준을 기본 지원하는 NGINX Plus R10을 사용하면 애플리케이션과 API에 정교한 인증 솔루션을 손쉽게 추가할 수 있습니다.

JWT (pronounced “jot”) tokens, defined in RFC 7519에 정의된 JWT(“jot”으로 발음) 토큰은 OpenID Connect 표준에서 사용자 정보를 담는 기본 데이터 형식입니다. OpenID Connect는 OAuth 2.0 프로토콜을 기반으로 하는 표준 ID 계층입니다. API 및 마이크로서비스 배포자들도 JWT 표준의 단순성과 유연성 때문에 이를 채택하고 있습니다.

[편집자 – 기본 JWT 지원을 활용하는 사용 사례는 다음 블로그를 참조하세요:

]

NGINX Plus는 클라이언트의 액세스를 허용하기 전에 JWT를 검증합니다

As a 리버스 프록시 및 로드 밸런서 역할을 하는 NGINX Plus는 애플리케이션 앞단에 위치하므로, 각 HTTP 요청에 포함된 JWT의 검증을 대신 처리하여 애플리케이션 개발을 간소화하기에 이상적입니다. 여기에는 두 가지 이점이 있습니다. 첫째, NGINX Plus는 인증되지 않았거나 형식이 잘못되었거나 악의적인 요청이 애플리케이션에 도달하지 못하도록 차단하여, 이러한 요청을 처리하는 데 따르는 수고와 위험으로부터 애플리케이션을 보호할 수 있습니다.

두 번째 이점은 NGINX Plus가 서명 검증을 마친 JWT의 모든 필드에 액세스할 수 있으며, 구성 구문의 강력한 기능과 유연성을 활용하여 마이크로서비스와 API 모두에 정교한 인증 솔루션을 제공할 수 있다는 것입니다:

  • 마이크로서비스의 일반적인 사용 사례는 NGINX Plus가 JWT를 검증하고 인증된 사용자의 ID를 HTTP 헤더로 백엔드 애플리케이션에 전달하도록 하는 것입니다. 이렇게 하면 모든 마이크로서비스에서 동일한 인증 기능을 반복해서 구현할 필요가 없습니다.
  • API의 경우 NGINX Plus는 IP 주소와 최종 사용자 간의 부정확한 매핑에 의존하는 대신, 실제 사용자별로 액세스 속도를 제한할 수 있습니다.

다음 NGINX Plus 구성 예제에서는 JWT를 사용하여 웹사이트를 보호하는 방법을 보여 줍니다.

The auth_jwt 지시문은 NGINX Plus가 JWT를 사용하여 도메인(이 경우 myrealm)에 요청하는 사용자를 인증하도록 합니다. auth_jwt_key_file 지시문은 토큰 서명을 검증하는 데 사용할 JSON 웹 키(JWK)를 지정합니다. 이 키는 SSL/TLS 암호화의 공개 키와 같은 역할을 합니다. NGINX Plus에서 해당 파일 위치에 액세스할 수 있어야 합니다.

NGINX Plus는 토큰을 검증하고 구문 분석하면서 JWT의 “클레임”에 대한 NGINX 변수를 자동으로 생성합니다. 클레임은 JWT와 관련된 엔터티(예: 발급자, 토큰이 발급된 사용자, 의도된 수신자)를 나타냅니다. 변수 이름은 모두 $jwt_claim_로 시작합니다. 그런 다음 add_header 지시어를 사용하여 NGINX Plus가 클레임을 $jwt_claim_ 변수의 값으로 설정된 HTTP 헤더 형태로 백엔드 서버에 전달하도록 할 수 있습니다. 이 예에서 NGINX Plus는 JWT의 사용자 ID($jwt_claim_sub 변수에 해당하는 sub 클레임)를 통해 사용자 ID를 백엔드 애플리케이션에 전달합니다.

코드 예제를 로드하는 중…

In NGINX Plus R8에서는 OAuth2 지원의 기술 프리뷰를 출시했습니다. NGINX Plus R10 구현에는 고객의 피드백을 반영하여 사용자와 컴퓨터 인증이라는 복잡한 분야에서 가장 중요한 사용 사례를 지원하는 프로덕션 환경용 구현을 제공했습니다.

“듀얼 스택” RSA 및 ECC 인증서 지원

이제 모든 애플리케이션 트래픽에 SSL/TLS 암호화를 적용해야 할 이유는 충분합니다. Google은 SSL/TLS로 암호화된 사이트에 더 높은 검색 엔진 순위를 부여합니다. 또한 HTTP/2와 같은 최신 웹 표준에서는 모든 웹사이트에 SSL/TLS 암호화를 의무화하고 있습니다.

NGINX Plus R10에서는 RSA 인증서와 ECC 인증서를 모두 사용하여 SSL/TLS 서비스를 제공할 수 있습니다. 테스트 결과, ECC 인증서는 동등한 보안 강도의 RSA 인증서보다 최대 3배 더 빨랐습니다. 이는 서버당 더 많은 SSL/TLS 연결과 더 빠른 SSL/TLS 핸드셰이크로 이어집니다. NGINX Plus는 각 클라이언트의 기능에 따라 최적의 인증서를 선택하므로, 기존 RSA 전용 클라이언트도 계속 지원하면서 최신 클라이언트에는 더 빠른 ECC 인증서를 사용할 수 있습니다.

RSA 인증서와 ECC 인증서를 모두 지원하려면 가상 서버 구성에 다음 예와 같이 각 인증서 유형에 대한 ssl_certificate 및 ssl_certificate_key 지시어 쌍을 포함하기만 하면 됩니다.

코드 예제를 로드하는 중…

투명 프록시

더욱 폭넓은 애플리케이션과 배포 모델을 지원하기 위해 NGINX Plus에 TCP 및 UDP 부하 분산과 같은 기능을 지속적으로 추가하고 있습니다. NGINX Plus R10에는 NGINX Plus가 임의의 소스 IP 주소와 포트를 사용하여 업스트림 서버로 패킷을 전송할 수 있는 투명 프록시 기능이 추가되었습니다. 이를 통해 IP 투명성 및 DSR(Direct Server Return)과 같은 구성을 구현할 수 있습니다.

IP 투명성은 로드 밸런서(NGINX Plus)가 업스트림 서버로 보내는 패킷의 소스 IP 주소로 원격 클라이언트의 IP 주소를 사용하는 구성입니다. 즉, 업스트림 서버는 패킷이 로드 밸런서의 로컬 IP 주소가 아니라 원격 클라이언트의 IP 주소에서 전송된 것으로 인식합니다. 이는 애플리케이션이 로깅, 보안, 속도 제한 또는 인증을 위해 소스 IP 주소를 참조하는 경우에 중요합니다.

IP 투명성은 DSR(Direct Server Return)이라는 네트워크 부하 분산 기술의 구성 요소이기도 합니다. NGINX Plus는 UDP 기반 프로토콜(TCP 또는 HTTP 제외)에 DSR을 적용하여 반환 패킷이 부하 분산 장치를 완전히 우회하고 원격 클라이언트로 직접 전송되도록 할 수 있습니다.

DSR 모드에서는 백엔드 서버가 클라이언트에 직접 응답합니다.

IP 투명성과 DSR은 transparent 지시어의 새로운 매개변수를 사용하여 proxy_bind, fastcgi_bind, memcached_bind, scgi_bind, uwsgi_bind 지시어에 구성합니다. 다음 예에서는 DNS 백엔드에 DSR을 설정하는 방법을 보여 줍니다. proxy_responses 지시어는 NGINX Plus가 서버 응답을 확인할 필요가 없도록 지정합니다(DSR에는 0이 적절한 값입니다).

코드 예제를 로드하는 중…

DSR이 활성화된 경우 수동 상태 확인은 효과가 없다는 점에 유의하세요. 수동 상태 확인에서는 NGINX Plus가 서버가 클라이언트에 응답을 보냈는지 확인하기 때문입니다. DSR 구성에서는 능동형 애플리케이션 인식 상태 확인을 반드시 구성해야 합니다. 예시는 부하 분산된 DNS 서버에 이를 구성하는 방법에 대한 자세한 지침을 참조하세요.

IP 투명성 및 DSR 구성은 복잡하며, NGINX Plus 소프트웨어의 범위를 벗어나는 추가 라우팅 및 패킷 재작성 요구 사항이 있습니다. 전체 지침은 블로그의 투명 프록시로서 NGINX 및 NGINX Plus를 사용하는 IP 투명성 및 Direct Server Return을 참조하세요.

HTTP, TCP 및 UDP 기반 애플리케이션용 NGINX JavaScript 모듈

[편집자 – NGINX JavaScript 모듈은 이전에 nginScript라고 불렸습니다. 이 모듈은 NGINX Plus R12(및 NGINX 1.11.10)부터 정식으로 제공되었습니다.

다른 NGINX JavaScript 모듈 사용 사례에 대한 자세한 내용은 NGINX JavaScript 모듈 사용 사례를 참조하세요.

이 섹션의 코드는 다음을 사용하도록 업데이트되었습니다. js_import 지시문은 js_include 지시문을 NGINX Plus R23 이상에서 대체합니다. 자세한 내용은 NGINX JavaScript 모듈의 참조 문서를 확인하세요. 구성 예시 섹션에서는 NGINX 구성 파일과 JavaScript 파일의 올바른 구문을 보여 줍니다.]

NGINX Plus R10에는 새로운 NGINX JavaScript 구성 언어의 프리뷰 릴리스가 포함되어 있습니다. 아직 모든 기능이 완성된 것은 아니며, 지금까지의 작업에 대한 여러분의 의견을 기다립니다. NGINX JavaScript를 사용하면 JavaScript 코드로 HTTP, TCP 및 UDP 트래픽에 대해 복잡한 사용자 지정 작업을 수행할 수 있습니다. 이를 통해 애플리케이션의 제공 및 보안 방식을 제어하는 강력하고 새로운 방법을 활용할 수 있습니다. NGINX JavaScript로 다음과 같은 작업을 수행할 수 있습니다:

  • 강력한 JavaScript 프로그래밍 언어를 사용하여 NGINX Plus에서 직접 ‘서버리스’ 함수 작성
  • API 데이터의 형식을 지정하고 조작 및 변환
  • 시간 서버와 같은 간단한 TCP 서비스 제공
  • JavaScript를 사용하여 NGINX 변수를 설정하고, 사용자 지정 부하 분산 로직과 캐시 키 등을 생성

NGINX JavaScript 프리뷰는 당사의 동적 모듈 저장소에서 제공됩니다. 표준 패키지 관리 도구를 사용하여 설치할 수 있습니다. 다음 명령은 Debian 기반 운영 체제용입니다:

# apt-get update
# apt-get install nginx-plus
# apt-get install nginx-plus-module-njs

HTTP 및 TCP/UDP용 NGINX JavaScript 모듈을 로드하려면 NGINX Plus 구성 파일의 최상위 “main” 컨텍스트에 load_module 지시어를 포함합니다:

코드 예제를 로드하는 중…

그런 다음 NGINX JavaScript 모듈을 로드하도록 NGINX Plus 구성을 다시 로드합니다:

# nginx -t && nginx -s reload

NGINX Open Source 사용자는 당사의 오픈 소스 코드 저장소에서 NGINX JavaScript를 다운로드할 수 있습니다.

JavaScript 코드는 NGINX Plus 구성에 직접 포함되지 않습니다. 대신 js_import 지시어를 사용하여 읽어 들입니다. 이 예에서는 간단한 ‘서버리스’ 함수의 JavaScript 코드를 /etc/nginx/conf.d/functions.js에서 읽어 들입니다. js_content 지시어는 NGINX Plus가 JavaScript 함수를 호출하고 그 결과를 클라이언트에 반환하도록 합니다.

코드 예제를 로드하는 중…

다음 위치의 JavaScript 코드는 /etc/nginx/conf.d/functions.js 지정된 문자 집합으로 문자열을 채웁니다:

코드 예제를 로드하는 중…

추가 기능

NGINX Plus R10에는 완벽한 애플리케이션 제공을 지원하기 위한 다음과 같은 여러 추가 개선 사항이 도입되었습니다:

  • TCP/UDP load balancing, implemented in the Stream 모듈에 구현된 TCP/UDP 부하 분산은 이제 HTTP 부하 분산과 기능 면에서 더욱 유사해졌습니다. 새롭게 지원되는 모듈로는 A/B 테스트를 위한 Split Clients, 클라이언트의 지리적 위치를 기반으로 작업을 수행하는 GeoIP, IP 주소를 기반으로 변수를 정의하는 Geo가 있습니다. 추가 NGINX 변수를 통해 더 많은 정보를 확인할 수 있으며, 변수를 proxy_pass 지시문의 매개변수로 사용하여 라우팅을 결정할 수 있습니다.
  • 트래픽이 많은 애플리케이션에서 흔히 발생하는 문제는 임시 포트 고갈입니다. 이 문제는 OS에서 사용 가능한 포트 번호가 모두 소진되어 업스트림 서버에 대한 새 연결을 생성할 수 없을 때 발생합니다. 이를 해결하기 위해 NGINX Plus는 이제 사용 가능한 경우 IP_BIND_ADDRESS_NO_PORT 소켓 옵션을 사용합니다. 이 옵션을 사용하면 표준 ‘4-튜플’(소스 IP 주소, 대상 IP 주소, 소스 포트, 대상 포트)이 고유한 경우 업스트림 서버로 나가는 연결에 소스 포트를 재사용할 수 있습니다. 이 옵션은 Linux 커널 버전 4.2 이상 및 glibc 2.22 이상이 설치된 시스템에서 사용할 수 있습니다.
  • NGINX Plus는 새로운 변수인 $request_id를 새 HTTP 요청마다 자동으로 생성하여 요청에 고유한 ‘트랜잭션 ID’를 할당합니다. 이를 통해 애플리케이션 추적이 용이해지고 로그 분석 도구에서 APM 기능을 활용할 수 있습니다. 트랜잭션 ID는 백엔드 애플리케이션과 마이크로서비스로 프록시되므로 시스템의 모든 부분에서 각 트랜잭션에 대해 일관된 식별자를 기록할 수 있습니다.
  • 이제 proxy_request_buffering, fastcgi_request_buffering, scgi_request_buffering, uwsgi_request_buffering 지시어가 HTTP/2에서 작동하며 요청 버퍼링을 설정하거나 해제하는 데 사용할 수 있습니다.
  • 새로운 http2_body_preread_size 지시어를 사용하면 HTTP/2 클라이언트가 요청 본문 전송을 즉시 시작할 수 있습니다. 이 지시어는 NGINX Plus가 클라이언트 요청 본문을 읽기 시작하기 전에 사용하는 버퍼의 크기를 제어합니다.

NGINX Plus Extras 패키지는 더 이상 사용되지 않습니다

NGINX Plus R9 출시 당시 사전 공지한 바와 같이, R10은 NGINX Plus Extras 패키지가 포함되는 마지막 릴리스입니다.

지금 설치 및 구성 절차를 변경하여 nginx-plus 패키지를 사용하고, nginx-plus-extras 패키지에서 실제로 사용하는 모듈을 동적으로 로드할 것을 강력히 권장합니다. NGINX Plus R11부터는 nginx-plus 패키지에 기본 제공되지 않는 모듈을 사용할 수 있는 유일한 방법이 됩니다.

nginx-plus 패키지와 동적 모듈로 전환하려면 다음 단계를 수행합니다:

  1. nginx-plus-extras 패키지를 제거하고 nginx-plus 및 사용하려는 동적 모듈을 설치합니다. Debian 기반 시스템에서는 다음 명령어를 사용합니다:
# apt-get update
# apt-get remove nginx-plus-extras
# apt-get install nginx-plus
# apt-get install module-name
  1. In the main (top‑level) context in /etc/nginx/nginx.conf의 메인(최상위) 컨텍스트에 동적으로 로드되는 각 모듈에 대한 load_module 지시어를 추가합니다:

    코드 예제를 로드하는 중…

  2. 새 구성의 구문이 올바른지 확인한 후 다시 로드합니다:
# nginx -t && nginx -s reload

NGINX Plus로 업그레이드하거나 체험해 보기

NGINX Plus를 사용 중이라면 가능한 한 빨리 릴리스 10으로 업그레이드하시기를 적극 권장합니다. 여러 수정 사항과 개선 사항이 적용되며, 지원 티켓을 제출해야 할 경우 더 원활하게 지원받을 수 있습니다. 설치 및 업그레이드 지침은 NGINX Plus 고객 포털에서 확인할 수 있습니다.

참고: NGINX Plus R10은 nginx-plus-extras 패키지가 포함되는 마지막 릴리스입니다. 위의 「NGINX Plus Extras 패키지 지원 중단」을 참조하세요.

아직 NGINX Plus를 사용해 보지 않으셨다면 웹 가속, 부하 분산 및 애플리케이션 전송을 위해, 또는 향상된 모니터링 및 관리 API를 갖춘 완전한 지원이 제공되는 웹 서버로 사용해 보시기 바랍니다. 지금 무료 30일 평가판으로 시작하여 NGINX Plus가 애플리케이션을 전송하고 확장하는 데 어떻게 도움이 되는지 직접 확인해 보세요.

NGINX Plus R10에 대한 자세한 정보

NGINX Plus R10의 주요 새로운 기능에 대한 자세한 내용은 다음 관련 자료를 참조하세요:

[NGINX ModSecurity WAF는 2022년 4월 1일부로 공식 판매가 종료되었으며, 2024년 3월 31일부로 지원 종료로 전환됩니다. 자세한 내용은 블로그의 「F5 NGINX ModSecurity WAF 지원 종료 전환 안내」를 참조하세요.]


공유

작성자 소개

관련 블로그 게시물

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric
NGINX | 2023. 11. 30.

시청하기: KubeCon North America 2023에서의 NGINX Gateway Fabric

이 영상에서는 KubeCon의 NGINX 부스를 찾아가, 저희가 공개한 Kubernetes Gateway API 구현을 살펴봅니다.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법
NGINX | 2023. 03. 23.

F5 NGINX로 대규모 WAF 플릿을 확인하고 관리하는 2가지 방법

앱 보안을 강화하는 두 가지 방법을 소개합니다. NGINX Management Suite를 통해 WAF 운영에 대한 가시성을 높이고, NGINX App Protect WAF를 활용해 코드형 보안을 구현하는 것입니다.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션
NGINX | 2021. 09. 27.

Ingress 컨트롤러 선택 가이드, 4부: NGINX Ingress Controller 옵션

개발 주체, 개발 철학, 프로덕션 환경 준비도, 보안 및 지원을 기준으로 어떤 NGINX Ingress 컨트롤러가 가장 적합한지 알아보세요.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법
NGINX | 2021. 07. 06.

진화하는 공격 환경에 NGINX App Protect Denial of Service가 적응하는 방법

NGINX App Protect Denial of Service(DoS)가 계층 7 DoS 공격을 방어하기 위해 완화 방법을 실시간으로 조정하는 방식을 설명합니다. 정상적인 사용자 행동과 서버 상태에 대한 모델을 생성하여 공격을 나타내는 이상 징후를 감지하고 맞춤형 완화 시그니처를 적용할 수 있습니다.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리
NGINX | 2021. 06. 30.

NGINX Instance Manager를 활용한 대규모 구성 업데이트 및 인증서 관리

NGINX Instance Manager 버전 1.0에는 두 가지 새로운 기능이 도입되었습니다. NGINX 인스턴스에 태그와 사용자 역할을 지정하면 전체 그룹에 구성을 한 번에 적용할 수 있습니다. 인증서 검사는 만료 예정인 인증서를 감지하여 서비스 중단을 방지할 수 있도록 인증서를 교체할 수 있게 해줍니다.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유
NGINX | 2015. 03. 25.

Netflix가 자사 CDN의 핵심으로 NGINX를 선택한 이유

Netflix가 글로벌 콘텐츠 전송 네트워크인 Open Connect의 스트리밍 미디어 기술로 NGINX를 선택한 이유를 NGINX 개발자 Gleb Smirnoff에게서 알아보세요.