NGINX Plus R26 출시 발표

Robert Haynes기술 마케팅 매니저

NGINX Plus 릴리스 26(R26)이 출시되었음을 기쁘게 알려드립니다. NGINX Open Source를 기반으로 하는 NGINX Plus는 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이 기능을 모두 제공하는 유일한 올인원 소프트웨어입니다.

NGINX Plus R26의 새로운 기능과 향상된 기능은 다음과 같습니다:

• JSON Web Key Set 캐싱을 통한 더 빠른 JWT 검증 – 최근 몇 차례의 릴리스에서 추가된 JSON Web Token(JWT) 지원 개선 사항에 이어, JSON Web Key Set(JWKS)의 인메모리 캐싱을 도입하여 JWT 검증에 따른 오버헤드를 크게 줄였습니다.
• 강화된 TLS 핸드셰이크 – 클라이언트가 ALPN을 통해 설정 중인 세션의 NGINX 구성 컨텍스트와 일치하지 않는 통신 프로토콜을 제안하는 경우(예: http{} 컨텍스트의 가상 서버에 IMAP 이메일 프로토콜을 제안하는 경우), NGINX Plus는 TLS 핸드셰이크를 거부합니다.
• NGINX JavaScript 모듈 개선 사항 – 이제 async 및 await 키워드와 Promise 객체를 사용하는 비동기 함수가 지원되며, 난수 생성이나 쿠키 암호화와 같은 암호화 작업을 위한 WebCrypto API도 구현되었습니다.

이번 릴리스에는 이 밖에도 IBM System Z(s390x) 아키텍처 지원, TCP 연결의 각 방향을 독립적으로 종료하는 기능, Perl 호환 정규식(PCRE) 라이브러리 버전 2 지원이 포함됩니다.

중요한 동작 변경 사항

NGINX JavaScript 모듈에서 더 이상 js_include을 지원하지 않음

As announced at the release of NGINX Plus R23 출시 당시 발표한 바와 같이, NGINX JavaScript 모듈 버전 0.4.0에서는 js_import 지시문이 js_include 지시문을 대체했습니다. js_include 지시문은 당시 더 이상 사용되지 않는 것으로 지정되었으며, 이번 릴리스부터는 더 이상 지원되지 않습니다.

NGINX Plus R26으로 업그레이드하기 전에 NGINX 구성 파일에서 js_include를 js_import로 바꾸고, NGINX 구성에서 참조되는 함수가 포함된 JavaScript 파일에 export 문도 추가합니다. 다음 단계를 따르세요:

1. NGINX 구성 파일을 편집합니다. 예를 들어 다음을 변경합니다:

js_set $foo myFunction;

1. 다음으로:

js_set $foo module_name.myFunction;

• Replace js_include를 js_import로 바꾸고 암시적 module_name(지시문에 전달되는 JavaScript 파일 이름 매개변수에서 .js 확장자를 제외한 값)을 기록해 둡니다.
• JavaScript 함수를 참조하는 각 지시문에서 함수 이름 앞에 module_name을 붙입니다. 함수 이름은 다음 지시문의 첫 번째 매개변수입니다. 단, js_set[HTTP][Stream] 지시문에서는 두 번째 매개변수입니다.
  • js_body_filter
  • js_content
  • js_filter
  • js_header_filter

1. NGINX 구성 파일에서 참조되는 함수를 정의하는 JavaScript (module_name.js) 파일을 편집합니다. 참조되는 함수의 이름을 지정하여 다음과 같은 export 문을 각 파일에 추가합니다.

export default { myFunction, otherFunction }

1. export 문은 .js 파일의 어느 위치에나 작성할 수 있지만, 관례상 함수 바로 위나 파일 끝에 배치합니다.

Cookie-Flag 모듈은 더 이상 사용되지 않음

타사 Cookie‑Flag 모듈은 NGINX Plus R23에서 더 이상 사용되지 않는 것으로 지정되었으며, 당시 발표한 바와 같이 이번 릴리스부터 NGINX 모듈 리포지토리에서 더 이상 제공되지 않습니다.

NGINX Plus R26으로 업그레이드하기 전에 NGINX 구성을 편집하여 더 이상 사용되지 않는 모듈에 정의된 set_cookie_flag 지시문의 모든 항목을 기본 제공 proxy_cookie_flags 지시문으로 바꾸십시오.

TLS 협상에서 더 이상 NPN 프로토콜을 지원하지 않음

NGINX가 TLS 및 HTTP/2 연결을 설정하는 방식이 업데이트되었습니다. NGINX와 클라이언트(일반적으로 브라우저) 간의 TLS 핸드셰이크 과정에서 양측은 핸드셰이크를 통해 설정되는 세션에 사용할 통신 프로토콜을 협상합니다(대부분의 경우 이 협상을 통해 세션이 HTTP 1.x에서 HTTP/2로 업그레이드됩니다). TLS의 NPN(Next Protocol Negotiation) 확장은 이러한 용도로 처음 사용된 방식이지만, 현재 NPN은 더 이상 사용되지 않는 것으로 간주되며 RFC 7301로 발표된 ALPN(Application-Layer Protocol Negotiation) 확장으로 대체되었습니다.

NGINX Plus R26에서는 더 이상 NPN을 지원하지 않으므로, 이제 클라이언트는 ALPN만 사용해야 합니다.

또한 ALPN 구현을 확장하고 보안을 강화했습니다. 자세한 내용은 강화된 TLS 핸드셰이크를 참조하세요.

이전 NGINX Plus 소프트웨어 저장소는 더 이상 업데이트되지 않습니다

At the release of NGINX Plus R24 출시와 함께 모든 NGINX 소프트웨어의 패키지 리포지토리가 재구성되면서 NGINX Plus 설치 절차가 변경되었습니다.

NGINX Plus를 설치하거나 업그레이드하면 운영 체제의 패키지 관리자(apt, yum, 또는 이에 상응하는 도구)에 NGINX Plus 소프트웨어 저장소가 구성됩니다.

기존 plus-pkgs.nginx.com 리포지토리를 사용하도록 구성된 시스템(NGINX Plus R23 이하를 실행하는 시스템)에서 NGINX Plus R26으로 업그레이드하는 경우, 패키지 관리자가 새 pkgs.nginx.com/plus 리포지토리를 참조하도록 업데이트해야 합니다. 자세한 지침은 F5 기술 자료에서 확인하세요.

NGINX Plus R26을 처음 설치하는 경우 NGINX Plus 설치에 관한 자세한 내용은 NGINX Plus 관리 가이드를 참조하세요.

NGINX Plus R26은 이전 리포지토리에서 사용할 수 없습니다., 해당 리포지토리에는 더 이상 업데이트가 제공되지 않습니다.

NGINX Plus API용 OpenAPI 사양에 대한 액세스 변경

NGINX Plus 소프트웨어 패키지에는 더 이상 YAML 형식의 OpenAPI 사양 및 Swagger UI가 NGINX Plus API용으로 포함되지 않습니다. 이제 NGINX Plus 관리 가이드에서 해당 항목에 액세스할 수 있습니다.

플랫폼 지원 변경 사항

새롭게 지원되는 운영 체제 및 아키텍처:

• Alpine Linux 3.15 (x86_64, arm64)
• CentOS 8.1+, RHEL 8.1+ 및 Ubuntu 20.04를 사용하는 IBM Z 플랫폼(s390x). 자세한 내용은 IBM Z s390x 아키텍처 지원

이전 운영 체제 지원 종료:

• Alpine Linux 3.11(지원되는 가장 오래된 버전은 3.12)

지원 중단이 예정되어 있으며 NGINX Plus R27에서 제거될 이전 운영 체제 및 아키텍처:

• Power8 아키텍처(ppc64le)
• CentOS 8.1+
• Alpine Linux 3.12

새로운 기능 상세

JSON 웹 키 세트 캐싱을 통한 더 빠른 JWT 검증

JSON 웹 토큰을 검증할 때 NGINX는 JSON 웹 키 세트(JWKS)를 사용하여 토큰의 서명을 확인하거나 토큰을 복호화합니다. JWKS는 구성 파일에 저장하거나 HTTP 요청을 통해 외부 서비스에서 가져올 수 있습니다. 또한 JWKS를 메모리에 캐싱하면 다음과 같은 여러 이점이 있습니다:

• CPU 사용량 대폭 감소
• 요청 지연 시간 감소
• 캐싱 프로세스의 일부로 JWKS 키가 JSON에서 암호화 작업에 최적화된 바이너리 형식으로 변환되므로 JWT 검증이 간소화됩니다.

JWKS를 메모리에 캐시하려면 새로운 auth_jwt_key_cache 지시어를 포함하고 각 키 세트의 만료 시간을 지정합니다(이 예에서는 3시간):

코드 예제를 로드하는 중…

외부 서버에서 JWK를 가져오는 경우 표준 콘텐츠 캐싱을 구성하고 proxy_cache_use_stale 지시어를 포함하는 것도 권장합니다. 이 지시어는 만료된 JWKS가 백그라운드에서 갱신되는 동안 NGINX Plus가 해당 JWKS를 계속 제공하도록 합니다.

코드 예제를 로드하는 중…

JWKS 캐싱과 더불어 콘텐츠 캐싱을 사용하면 다음과 같은 두 가지 이점이 있습니다:

• 복원력 – JWKS는 만료된 후에도 캐시에서 가져올 수 있습니다. 따라서 JWKS 공급자를 일시적으로 사용할 수 없는 경우에도 복원력이 향상되지만, 보안 위험이 커질 수 있다는 상충 관계가 있습니다.
• 권한 부여 서버에 미치는 영향 – 캐시된 JWKS의 만료는 JWKS 캐싱을 단독으로 사용하는지, 콘텐츠 캐싱과 함께 사용하는지에 따라 권한 부여 서버에 서로 다른 영향을 미칩니다:
  • JWKS 캐싱만 사용하는 경우, 만료된 JWKS의 새 버전으로 캐시가 다시 채워질 때까지 수신되는 모든 권한 부여 요청이 인증 서버로 전달됩니다. 인증 서버의 응답이 느리면 JWKS에 대한 HTTP 요청이 갑자기 반복적으로 증가할 수 있습니다. 이러한 추가 부하로 인해 인증 서비스가 과부하되어 문제가 더욱 악화될 수 있습니다.
  • 만료된 JWKS 제공과 함께 콘텐츠 캐싱을 사용하도록 설정하면 JWKS에 대한 요청 하나만 인증 서버로 전달되고, 이후 요청은 콘텐츠 캐시가 채워져 NGINX가 처리할 수 있을 때까지 대기열에 추가됩니다. 그 결과 인증 서비스에 대한 요청이 줄어들어 리소스 사용량도 감소합니다.

강화된 TLS 핸드셰이크

TLS를 노리는 공격(예: ALPACA)이 증가하고 있습니다. 익스플로잇을 선제적으로 방어하기 위한 지속적인 노력의 일환으로 NGINX의 TLS 연결 처리 보안을 강화했습니다.

애플리케이션 계층 프로토콜 협상(ALPN)은 TLS 핸드셰이크의 선택적 확장 기능으로, 클라이언트와 서버가 TLS 핸드셰이크 중에 핸드셰이크를 통해 설정된 암호화 세션에서 사용할 계층 7 프로토콜을 선택하는 데 사용됩니다. ALPN의 가장 일반적인 사용 사례는 브라우저와 웹 또는 애플리케이션 서버 간 세션에서 HTTP/1.x에서 HTTP/2로의 업그레이드를 협상하는 것입니다.

이제 NGINX Plus는 클라이언트가 ALPN을 통해 제안한 프로토콜이 설정 중인 세션의 NGINX 구성 컨텍스트와 일치하지 않으면 TLS 핸드셰이크를 거부합니다. 예를 들어, http{} 컨텍스트에 정의된 가상 서버에는 HTTP용 ALPN 프로토콜 ID가 필요하고, mail{} 컨텍스트의 가상 서버에는 SMTP, POP 또는 IMAP용 프로토콜 ID가 필요합니다.

NGINX Plus R26에는 협상된 프로토콜을 캡처하는 $ssl_alpn_protocol[HTTP][스트림] 변수가 도입되었습니다. (stream{} 컨텍스트에서 $ssl_preread_alpn_protocols 변수가 도입된 NGINX Plus R15는 여전히 핸드셰이크 중 클라이언트가 알린 모든 프로토콜의 목록을 캡처합니다.)

이 코드 조각은 alpn 로그 형식을 정의하며, $ssl_alpn_protocol을 사용하여 액세스 로그 항목의 alpn= 필드에 프로토콜을 포함합니다.

코드 예제를 로드하는 중…

새로운 ssl_alpn 지시문은 stream{} 컨텍스트에서 NGINX Plus가 허용할 프로토콜을 정의합니다. 클라이언트가 제시하는 모든 프로토콜을 NGINX Plus가 고려하도록 하려면 이 지시문을 생략합니다.

코드 예제를 로드하는 중…

NGINX JavaScript 모듈 개선 사항

NGINX Plus R26에는 NGINX JavaScript 모듈(njs) 버전 0.7.2가 통합되었으며, 다음 두 가지 개선 사항이 포함되어 있습니다:

• 비동기 함수 지원 강화(ECMAScript 6에 도입된) async 및 await 키워드와 Promise 객체
• WebCrypto API 구현

참고: 이 섹션은 독자가 비동기 및 암호화 작업을 위한 JavaScript 구문을 이해하고 있다고 가정합니다. 코드 스니펫에 대한 전체 분석은 이 블로그의 범위를 벗어납니다.

[편집자 – 이 섹션에서 설명하는 사용 사례는 NGINX JavaScript 모듈의 수많은 사용 사례 중 일부에 불과합니다. 전체 목록은 NGINX JavaScript 모듈 사용 사례를 참조하세요.]

비동기 함수 지원 강화

PHP와 같이 널리 사용되는 많은 스크립팅 언어에서는 명령과 함수가 동기식으로 실행됩니다. 즉, 스크립트가 함수를 호출하면 해당 함수가 결과를 반환할 때까지 일시 중지됩니다(실행을 멈춥니다).

JavaScript는 비동기 방식으로도 작동할 수 있습니다. 함수를 비동기적으로 호출하면 스크립트는 함수의 결과가 반환될 때까지 기다리지 않고 계속 실행됩니다.

다음 예제 스크립트를 살펴보세요:

코드 예제를 로드하는 중…

njs 런타임은 설정된 타임아웃이 경과할 때까지 기다리지 않으므로 빈 응답을 반환합니다(기다렸다면 출력은 b,a가 됩니다):

$ curl http://127.0.0.1/
$ 

의도한 결과를 얻으려면 비동기 작업을 올바르게 처리하는 것이 매우 중요합니다. JavaScript는 이를 위한 여러 가지 방법을 제공하지만, 일반적인 NGINX 사용 사례에서는 실행 흐름이 동기적으로 이루어지도록 비동기 함수를 래핑하는 방식이 적합한 경우가 많습니다. 이때 Promise 객체와 async 및 await 키워드가 사용됩니다.

ECMAScript 6(JavaScript용 ECMA‑262 언어 사양의 제6판)에서는 Promise 객체를 비동기 함수의 반환 형식으로 정의합니다. 이 객체는 다음 세 가지 상태 중 하나로 존재합니다:

• 이행됨 – 작업이 성공적으로 완료됨
• 거부됨 – 작업이 실패했습니다
• 대기 중 – 초기 상태(이행되지도 거부되지도 않은 상태)

JavaScript 함수를 async 키워드로 정의하면 함수의 반환 유형이 Promise로 설정됩니다. async 및 await 키워드는 Promise 객체를 처리하는 njs 함수를 작성할 때 중요합니다.

다음 예를 살펴보세요:

코드 예제를 로드하는 중…

The fs.readFile 함수(12번째 줄)는 Promise를 반환합니다. 이 함수는 파일 이름이 async 함수로 감싸져 있으며, 이 함수는 파일 이름이 fs.readFile()일 때만 user.text가 호출되도록 합니다. await 키워드로 인해 래핑 함수는 Promise가 완료될 때까지 기다린 후 데이터를 반환합니다.

Wrapping fs.readFile()를 다른 함수로 감싸면 오류를 더 쉽게 포착할 수 있습니다. async 함수에서 예외가 발생하면 Promise의 상태가 rejected로 설정됩니다. 또 다른 방법은 9번째 줄을 거부된 Promise를 반환하는 문으로 바꾸는 것입니다:

코드 예제를 로드하는 중…

또한 Promise 객체를 직접 사용할 수도 있습니다. 다음 예제에서 Promise.resolve 함수는 p1과 p2 각각에 대한 Promise를 반환합니다. Promise.all 함수는 결과를 반환하기 전에 p1과 p2의 프로미스가 모두 이행될 때까지 기다립니다.

코드 예제를 로드하는 중…

이제 curl 명령의 출력은 우리가 원하는 대로입니다(b는 타임아웃 값이 더 짧기 때문에 먼저 반환됩니다):

$ curl http://127.0.0.1/b,a
$ 

WebCrypto API를 활용한 새로운 암호화 함수

이제 NGINX JavaScript에서 향상된 암호화 기능을 WebCrypto API를 통해 사용할 수 있습니다. 일반적인 njs 암호화 사용 사례는 다음과 같습니다:

• 세션 ID용 보안 난수 생성
• 메시지, 데이터 및 쿠키 암호화 및 복호화
• 대칭 및 비대칭 암호화 알고리즘을 사용하여 디지털 서명을 생성하거나 검증하기

이 njs 코드는 난수를 생성합니다:

코드 예제를 로드하는 중…

그리고 다음 NGINX Plus 구성은 njs 코드를 호출합니다:

코드 예제를 로드하는 중…

함수의 출력값은 다음과 같은 난수입니다:

$ curl 127.0.0.123225320050,3668407277,1101267190,2061939102,2687933029,2361833213,32543985,4162087386

WebCrypto의 getRandomValues 함수는 안전한 난수와 WebCrypto 전반을 처음 접하기에 좋은 출발점입니다. 구현이 매우 간단하며, 이 함수는 Promise를 반환하는 대신 결과를 직접 반환합니다.

하지만 연산량이 더 많은 일부 WebCrypto 암호화 함수는 비동기 방식으로 작동합니다. 예를 들어, documentation for сrypto.subtle.digest() 관련 문서에는 다음과 같이 명시되어 있습니다:

주어진 데이터의 다이제스트를 생성합니다. 사용할 다이제스트 알고리즘의 식별자와 다이제스트를 생성할 데이터를 인수로 받습니다. 다이제스트가 생성되면 이행되는 Promise를 반환합니다.

따라서 сrypto.subtle.digest()를 직접 호출하면 async 함수로 래핑하지 않는 한 다음 단계에서 결과를 사용할 수 있다고 보장할 수 없습니다. 여기서는 함수가 반환되기 전에 hash 변수에 결과가 할당되도록 async 및 await 키워드를 사용한 함수로 래핑합니다:

코드 예제를 로드하는 중…

이 NGINX Plus 구성의 js_set 지시어는 $hosthash 변수를 setReturnValue 함수가 반환한 값으로 설정합니다(host_hash 함수로 래핑됨):

코드 예제를 로드하는 중…

다음은 호스트 이름 example.com을 해시하는 예시입니다.

$ curl -H "Host: example.com" 127.0.0.1#
e8e624a82179b53b78364ae14d14d63dfeccd843b026bc8d959ffe0c39fc4ded1f4dcf4c8ebe871e657a12db6f11c3af87c9a1d4f2b096ba3deb56596f06b6f4

NGINX Plus R26의 기타 개선 사항

IBM Z(s390x) 아키텍처 지원

최신 애플리케이션이 사용 가능한 모든 디지털 환경으로 확산됨에 따라 NGINX와 같은 필수 지원 구성 요소도 함께 제공되는 것이 중요합니다. 이에 따라 CentOS 8.1+, RHEL 8.1+, Ubuntu 20.04가 설치된 IBM Z(s390x) 아키텍처에서 NGINX Plus를 지원하게 되어 기쁘게 생각합니다. 기존 메인프레임 자산에서 최신 애플리케이션을 호스팅하려는 조직은 이제 NGINX와 NGINX Plus를 소프트웨어 기반 웹 서버, 로드 밸런서, 리버스 프록시, 콘텐츠 캐시 및 API 게이트웨이로 배포할 수 있습니다.

스트림 모듈의 TCP 하프 클로즈 지원

새로운 proxy_half_close 지시어를 사용하면 TCP 연결의 각 방향을 독립적으로 종료할 수 있어 stream{} 컨텍스트에서 효율성이 더욱 향상됩니다.

PCRE2 라이브러리 지원

이전 버전의 NGINX Plus에서는 NGINX 구성에 사용되는 정규식을 평가하기 위해 Perl 호환 정규식(PCRE) 라이브러리(버전 1)를 사용합니다. 이 주요 오픈 소스 프로젝트는 최근 지원이 종료되었으며 PCRE2로 대체되었습니다. NGINX Plus는 PCRE2로 빌드되지만, 기본 운영 체제에서 제공되는 버전을 사용하여 PCRE 및 PCRE2로 빌드된 동적 모듈을 모두 지원합니다. 구성 변경은 필요하지 않습니다.

NGINX Plus 업그레이드 또는 체험

NGINX Plus를 사용 중이라면 가능한 한 빨리 NGINX Plus R26으로 업그레이드할 것을 강력히 권장합니다. 업그레이드하면 여러 추가 수정 사항과 개선 사항도 적용되며, 지원 티켓을 제출해야 할 때 NGINX가 더 원활하게 지원하는 데 도움이 됩니다.

아직 NGINX Plus를 사용해 보지 않으셨다면 보안, 부하 분산, API 게이트웨이 용도로, 또는 향상된 모니터링 및 관리 API를 갖추고 완전한 지원이 제공되는 웹 서버로 사용해 보시기 바랍니다. 지금 바로 30일 무료 평가판으로 시작할 수 있습니다.

작성자 소개

Robert Haynes기술 마케팅 매니저

Robert Haynes의 다른 블로그 게시물