NGINX Plus R25 출시 발표

Zach Westall수석 제품 마케팅 매니저

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

NGINX Plus R25의 새로운 기능은 다음과 같습니다:

• 더욱 다양하고 고급화된 JSON 웹 토큰 사용 사례 – NGINX Plus R25는 NGINX Plus R24에서 도입된 암호화된 JSON 웹 토큰(JWE) 지원을 한층 강화합니다.
• HTTP 응답 코드에 대한 더욱 세분화된 보고 – NGINX Plus API는 이제 HTTP 응답 코드를 개별적으로 집계할 뿐만 아니라 클래스별로도 집계합니다. 메모리 할당량을 늘려야 할 수 있습니다; 시작 오류 방지를 위한 충분한 메모리 할당을 참조하세요.
• 프록시 연결을 위한 SSL/TLS 클라이언트 인증서 동적 로드 – 변수를 사용하여 NGINX Plus와 백엔드 서버 간의 mTLS 연결에 사용할 인증서를 동적으로 선택할 수 있습니다.
• HTTP 요청 처리를 위한 보안 강화 – NGINX Plus는 잠재적인 공격으로부터 애플리케이션을 보호하기 위해 HTTP 요청에 대해 몇 가지 추가 검사를 수행합니다.
• TCP/UDP 애플리케이션의 구성 다시 로드 시 상태 확인 결과 유지 – 이제 TCP/UDP 서버에 대한 필수 상태 확인 결과가 구성을 다시 로드한 후에도 유지됩니다.
• NGINX JavaScript 모듈 개선 – JavaScript ES6와의 호환성이 강화되었습니다.

중요한 동작 변경 사항

업스트림 영역의 메모리 요구량 증가

As described in detail in HTTP 응답 코드에 대한 더욱 세분화된 보고에서 자세히 설명한 것처럼, NGINX Plus R25는 개별 상태 코드의 수뿐만 아니라 클래스별 집계 수도 제공합니다. NGINX Plus를 리버스 프록시 또는 로드 밸런서로 구성한 경우 업스트림 ‘피어’(백엔드 서버)가 20개를 초과하면 이를 모니터링하는 데 사용되는 공유 메모리 영역의 크기를 늘려야 할 수 있습니다.

공유 메모리 영역이 충분히 프로비저닝되지 않으면 NGINX Plus R25가 시작되지 않아 업그레이드에 실패합니다. 업그레이드하기 전에 각 업스트림 영역의 메모리 사용량을 확인해야 합니다. 메모리 할당을 확인하고 조정하는 방법은 시작 실패를 방지하기 위한 충분한 메모리 할당을 참조하십시오.

NGINX Plus 리포지토리 구성 및 설치 절차 변경 사항

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

NGINX Plus를 설치하거나 업그레이드하면 운영 체제의 패키지 관리자(apt, yum 또는 이에 상응하는 도구)가 NGINX Plus 소프트웨어 저장소를 사용하도록 구성됩니다. 이전 저장소를 사용하도록 구성된 기존 시스템(NGINX Plus R23 이하를 실행하는 시스템)에서는 패키지 관리자가 새 저장소를 참조하도록 업데이트해야 합니다. 자세한 지침은 F5 기술 자료에서 확인하세요.

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

참고: 새 소프트웨어 리포지토리를 사용해야 합니다. 이전 리포지토리는 더 이상 업데이트되지 않으며 향후 설치 및 업그레이드 시 오류가 발생할 수 있습니다.

지원 중단된 쿠키 플래그 모듈

As announced at the release of NGINX Plus R23 출시 당시 발표한 바와 같이, 타사 Cookie‑Flag 모듈은 더 이상 사용되지 않으며 NGINX Plus R26에서 동적 모듈 저장소에서 제거될 예정입니다. 이 모듈에 정의된 set_cookie_flag 지시문은 기본 제공되는 proxy_cookie_flags 지시문으로 대체됩니다. 구성에 있는 모든 set_cookie_flag 지시문을 가능한 한 빨리 proxy_cookie_flags 지시문으로 교체하는 것이 좋습니다.

플랫폼 지원 변경 사항

• 새롭게 지원되는 운영 체제:
  • Debian 11 (x86_64, aarch64)
  • Alpine Linux 3.14 (x86_64, aarch64)
• 이전 운영 체제 지원 종료:
  • Alpine Linux 3.10; 지원되는 가장 오래된 버전은 3.11입니다
  • Amazon Linux 1(2018.03 이상): Amazon Linux 2 LTS로 전환
  • FreeBSD 11.4+; 지원되는 가장 오래된 버전은 12.1+
  • Ubuntu 16.04 LTS; 지원되는 가장 오래된 버전은 18.04 LTS입니다
• 지원 중단되었으며 NGINX Plus R26에서 제거될 예정인 이전 운영 체제:
  • Alpine Linux 3.11

새로운 기능 상세

추가 JSON 웹 토큰 사용 사례 및 기능

NGINX Plus R24는 초기 지원을 도입하여 가장 널리 사용되는 클라이언트 인증 방식 중 하나인 암호화된 JSON 웹 토큰(JWE)에 데이터 기밀성을 더했습니다. NGINX Plus R25는 이 기능을 기반으로, 서명된 토큰(JWS)과 암호화된 토큰(JWE) 모두에서 JWT 기반 인증의 보안을 강화하는 추가적인 고급 인증 사용 사례를 지원합니다. 이러한 개선 사항은 개인 식별 정보(PII)의 유출 위험을 줄이는 동시에 유연성을 높입니다. NGINX Plus의 새로운 JWT 기능 및 개선 사항은 다음과 같습니다.

• 복호화된 JWE 암호문을 위한 새로운 변수
• 중첩 JWT 지원
• JWE를 위한 비대칭 암호화
• 다중 소스 JSON Web Key 지원
• 추가 사용자 지정 JWT 검증 규칙

복호화된 JWE 암호문을 위한 변수

JWT는 HTTP 요청의 상태 비저장 인증(즉, 토큰 기반 인증)에 널리 사용되며 신뢰받는 방식입니다. JWT는 토큰 페이로드에 최종 사용자 속성을 담아 전송함으로써 요청의 보안을 강화합니다. 그러나 보안 연구자와 DevSecOps 실무자들은 암호화되지 않은 개인 식별 정보(PII)를 웹 클라이언트에 저장할 때 발생하는 위험이 시급히 해결해야 할 문제라는 데 동의합니다. 이에 따라 JSON Web Encryption 표준(RFC 7516)이 개발되었으며, 이 표준은 암호화된 토큰을 구현하기 위한 지침을 제공합니다.

NGINX Plus R24에서는 JWE 지원이 도입되어 전체 클레임 집합의 데이터 무결성과 기밀성을 보장합니다. 암호화된 토큰 내에 PII를 인코딩하면 JWT 사용 시 데이터 유출 위험을 크게 줄일 수 있습니다.

NGINX Plus R25는 초기 JWE 지원을 기반으로 새로운 변수인 $jwt_payload를 도입했습니다. 이 변수를 사용하면 NGINX Plus가 JWE와 암호문을 복호화한 후 HTTP 요청을 처리하는 동안 평문에 액세스할 수 있습니다. 이 새로운 기능은 고급 액세스 제어 정책과 요청 라우팅 결정을 구현하는 데 사용할 수 있으며, 사용자가 NGINX Plus를 백엔드 애플리케이션용 JWE 복호화 계층으로 배포할 수도 있게 해줍니다.

중첩 JWT 지원

JWE 토큰은 PII를 효과적으로 보호하며, 암호문을 통해 CDN 및 기타 TLS 종료 프록시를 거치는 경우에도 기밀성을 유지할 수 있습니다. 하지만 암호화는 양날의 검과 같아서 JWE가 애플리케이션 환경을 복잡하게 만들 수 있습니다. 이 문제를 해결하는 한 가지 방법은 중첩 JWT를 사용하는 것입니다.

중첩 JWT의 구조

중첩 JWT는 JWS를 JWE의 암호문으로 포함합니다. NGINX Plus R25에서는 JWS와 JWE를 동시에 지원하여 중첩 JWT를 HTTP 요청 인증 방식으로 사용할 수 있습니다. 이제 NGINX Plus는 한 번의 작업으로 JWE의 암호문을 복호화하고, 그 결과로 생성된 평문을 JWS로 검증한 다음, 포함된 토큰의 exp(만료 시간) 및 nbf(유효 시작 시간) 클레임을 사용하여 토큰의 유효성을 확인할 수 있습니다. 따라서 기존 JWS를 JWE로 래핑하여 페이로드 암호화 기능을 추가할 수 있습니다.

다음 구성 스니펫은 이 프로세스를 보여 줍니다. nested 지시어의 새로운 auth_jwt_type 매개변수는 NGINX Plus가 JWE 복호화와 JWS 검증을 모두 수행하도록 합니다. 또한 JWT 헤더 및 JWT 클레임의 변수가 평가되는 방식에도 영향을 줍니다:

• The auth_jwt_header_set 지시어는 외부 JWE 헤더에 적용됩니다.
• 중첩된 JWS 클레임에는 auth_jwt_claim_set 지시문이 적용됩니다.
• $jwt_header_name 변수에는 외부 JWE 헤더 속성이 포함됩니다.
• $jwt_claim_name 변수에는 중첩된 JWS 클레임이 포함됩니다.

코드 예제를 로드하는 중…

다음 구성을 사용하면 NGINX Plus가 추가 HTTP 요청 헤더를 생성하여 백엔드 애플리케이션으로 전송합니다. JWE 헤더의 암호화 알고리즘($jwt_header_enc 변수)과 JWS 페이로드의 JWT 주체 클레임($jwt_claim_sub 변수)은 원래 요청과 함께 프록시됩니다. 따라서 애플리케이션은 암호화 코드나 라이브러리를 구현할 필요 없이 HTTP 헤더를 사용하는 것만으로 JWE 기반 인증을 활용할 수 있습니다.

코드 예제를 로드하는 중…

제로 트러스트 아키텍처를 사용하는 사용자의 경우, 다음 구성을 통해 백엔드 애플리케이션에서 $jwt_payload 변수에 캡처된 JWS 토큰을 검증할 수 있습니다. 이 변수에는 JWE 암호문을 복호화한 평문이 포함됩니다. 중첩된 JWT가 있는 경우 JWS를 전달자 토큰으로 백엔드 애플리케이션에 전달할 수 있습니다.

코드 예제를 로드하는 중…

본질적으로 중첩 JWT를 사용하면 NGINX Plus가 보안 토큰을 복호화하는 동시에 검증하고, 백엔드 애플리케이션용으로 서명된 ‘일반 JWT’ 토큰을 파싱하거나 프록시할 수 있으므로 운영이 간소화되고 애플리케이션 보안이 강화됩니다.

JWE를 위한 비대칭 암호화

NGINX Plus R24에서는 AES 표준을 사용한 토큰의 대칭 암호화 지원이 도입되었습니다. NGINX Plus R25에서는 RSA 키 쌍을 사용할 때 비대칭 암호화를 지원합니다. 비대칭 암호화는 암호화와 복호화에 서로 다른 키(공개 키와 개인 키)를 사용하며, 이 키들은 RSA(Rivest–Shamir–Adleman) 알고리즘을 통해 수학적으로 서로 연결됩니다. 이는 클라이언트와 서버 간 HTTPS 트래픽의 SSL/TLS 암호화에 사용되는 것과 동일한 메커니즘입니다.

NGINX Plus R25는 최적 비대칭 암호화 패딩(OEAP)이 적용된 RSA를 키 관리 알고리즘으로 지원하며, NGINX Plus 측에서 별도로 구성할 필요가 없습니다. JWS alg(알고리즘) 헤더에 지원되는 값은 RSA-OAEP, RSA-OAEP-256, RSA-OAEP-384, RSA-OAEP-512입니다.

다음 구성은 JWE에 비대칭 암호화를 구현하려면 RSA 비공개 키(래핑 해제 키)가 포함된 JSON 웹 키(JWK) 파일을 auth_jwt_key_file 지시문의 매개변수로 지정하기만 하면 된다는 것을 보여 줍니다(auth_jwt_key_request 지시문을 사용할 수도 있음).

코드 예제를 로드하는 중…

다중 소스 JWK 지원

중첩 JWT를 활용하면 관련 JWK가 둘 이상의 소스에서 제공될 가능성이 높습니다. NGINX Plus R25는 동일한 컨텍스트에서 여러 auth_jwt_key_file 및 auth_jwt_key_request 지시어를 지원합니다. NGINX Plus는 지정된 모든 소스에서 키를 로드하고 통합된 키 집합에서 일치하는 검증 키를 찾습니다. 이는 외부 ID 공급자가 발급한 JWS가 별도의 프로세스로 암호화된 JWE 내부에 중첩된 경우에 매우 유용합니다.

이 기능은 API 게이트웨이로 배포된 NGINX Plus에 더욱 향상된 유연성, 보안 및 성능을 제공합니다.

사용자 지정 JWT 검증 규칙

NGINX Plus를 API 게이트웨이로 배포할 때는 세분화된 액세스 제어를 구현하기 위해 JWT 클레임을 검사하는 것이 일반적입니다. 이로 인해 구성이 복잡해질 수 있습니다. 이전 NGINX Plus 릴리스에서는 if 구성 블록을 사용하여 JWT 클레임을 평가할 수 있었지만, 이 방식은 다소 제한적이었으며 암호화된 토큰에는 사용할 수 없었습니다.

NGINX Plus R25는 JWT 검증 프로세스 중에 토큰을 추가로 검사할 수 있는 기본 기능을 제공하여 이러한 한계를 해결합니다. auth_jwt_require 지시문은 JWT 검증 프로세스에 선택적으로 사용자 지정할 수 있는 단계를 추가합니다. 이 지시문은 공백으로 구분된 문자열 목록을 받으며, JWT 검증에 성공하려면 모든 문자열이 비어 있지 않고 0(0)과 같지 않아야 합니다. 이를 통해 JWT 검증 프로세스의 유연성이 크게 향상됩니다.

JWT 표준은 어떤 클레임이 필수인지 규정하지 않으므로, auth_jwt_require를 사용하여 각 환경에 적합한 클레임을 나열할 수 있습니다.

다음 구성은 모든 토큰에 exp 및 sub 클레임이 모두 포함되도록 합니다.

코드 예제를 로드하는 중…

더 복잡한 사용 사례는 map 블록 또는 NGINX Plus 키-값 저장소를 사용하여 auth_jwt_require 지시문에 부울 값을 전달하도록 구성할 수 있습니다. 또한 NGINX JavaScript 모듈을 사용하여 상호 TLS(mTLS) 클라이언트 인증서에 바인딩된 액세스 토큰(RFC 8705에 정의됨)과 같은 고급 인증 솔루션을 구현할 수 있습니다.

다음 구성은 클라이언트 인증서 인증(mTLS)과 JWT 검증을 모두 수행합니다. 14번째 줄의 auth_jwt_require 지시문은 $thumbprint_match 변수를 평가하도록 하며, 이 변수의 값이 0이 아닌 경우에만 JWT 검증에 성공합니다. 이 변수는 2번째 줄에서 호출된 JavaScript 함수를 실행하여 평가됩니다.

코드 예제를 로드하는 중…

다음은 이전 코드 조각의 2번째 줄에서 호출된 validate 함수의 코드입니다:

코드 예제를 로드하는 중…

HTTP 응답 코드에 대한 더욱 세분화된 보고

모니터링과 가시성은 애플리케이션 성능, 가용성 및 보안의 초석입니다. HTTP 응답 코드는 애플리케이션 상태를 파악하는 데 가장 중요한 정보 소스 중 하나입니다. NGINX Plus API는 NGINX와 클라이언트 간의 상호 작용뿐만 아니라 NGINX와 업스트림 서버 간의 상호 작용에 대한 HTTP 응답 코드도 추적하며, 집계된 수치는 NGINX Plus 실시간 활동 모니터링 대시보드의 관련 탭에 표시됩니다.

이전 버전의 NGINX Plus API에서는 HTTP 응답 코드 수를 클래스별로 집계했습니다(2xx, 4xx 등). 이제는 코드별 수도 개별적으로 집계합니다(200, 404, 503 등). 이를 통해 애플리케이션에서 정확히 어떤 일이 발생하는지 더 자세히 파악할 수 있으며, 인증 실패 급증(403)과 콘텐츠 누락(404)처럼 원인이 매우 다른 오류를 구분할 수 있습니다. 메트릭 수집 구성에 대한 자세한 내용은 NGINX Plus 관리 가이드를 참조하세요.

NGINX Plus API의 최신 버전(버전 7)은 NGINX Plus R25와 함께 출시되었으며, 개별 HTTP 응답 코드를 집계할 수 있도록 codes 객체를 responses 객체 내에 포함합니다. 집계된 응답도 계속 사용할 수 있으며, codes 객체가 포함되지 않은 이전 버전의 NGINX Plus API도 NGINX Plus R25에서 계속 사용할 수 있습니다. 다음은 새로운 메트릭 세트의 예입니다.

$ curl -s http://localhost:8080/api/7/http/server_zones/www.example.com | jq{
  "processing": 31,
  "requests": 63192,
  "responses": {
    "1xx": 0,
    "2xx": 54368,
    "3xx": 8454,
    "4xx": 330,
    "5xx": 9,
    "codes": {
      "200": 54368,
      "302": 8454,
      "401": 30,
      "404": 200,
      "429": 100,
      "503": 9
    },
    "total": 63161
  },
  "discarded": 0,
  "received": 693436,
  "sent": 13843478
}

시작 실패를 방지하기 위해 충분한 메모리 할당

중요 참고 사항: NGINX Plus를 리버스 프록시 또는 로드 밸런서로 구성하면 개별 코드 집계로 인해 각 업스트림 그룹의 공유 메모리 영역 사용량이 증가합니다. 업스트림 그룹에 20개가 넘는 피어가 있는 경우, zone 지시문에 설정된 메모리 크기를 늘려야 할 수 있습니다.

업스트림 영역에 할당된 용량이 부족하면 NGINX Plus R25가 시작되지 않아 업그레이드에 실패합니다.

다음은 업스트림 그룹의 공유 메모리 영역에 대한 일반적인 구성입니다:

코드 예제를 로드하는 중…

NGINX Plus R25로 업그레이드하기 전에 기존 업스트림 존의 메모리 사용량을 확인해야 합니다. 이를 위해 다음 방법 중 하나를 사용하기 전에 NGINX Plus API가 활성화되어 있는지 확인하십시오.

• Check the HTTP 업스트림 탭에서 확인합니다. 다음은 demo.nginx.com의 실시간 활동 모니터링 대시보드에 표시된 예로, 사용률은 54%입니다.
  
• 다음 명령을 실행하여 호스트에서 직접 NGINX Plus API를 사용합니다. 먼저:

$ API=http://localhost:8080/api; for i in `curl -s $API/1/http/upstreams | jq -r '.[].zone | @uri'`; do echo -n $i; curl -s $API/1/slabs/$i | jq -r '.pages | 100*(.used / (.used + .free)) | " \(round)% used"'; done

• 필요한 경우 jq 유틸리티를 설치하세요
• Set the API 지시문이 활성화된 위치로 api 변수를 설정합니다

현재 사용률이 40%를 초과하는 경우(스크린샷 참조), zone 지시문의 두 번째 매개변수(크기)를 최소 2.5배로 늘리세요. 예를 들어 위의 구성 코드 조각에서 64k를 160k로 늘리는 것이 좋습니다.

프록시를 위한 동적 SSL/TLS 클라이언트 인증서 로드

상호 TLS(mTLS)는 클라이언트와 서버 양쪽의 ID를 확인하는 일반적인 인증 방식입니다. NGINX Plus에서는 업스트림 그룹의 서버를 동적으로, 그리고 변수를 사용하여 정의할 수 있습니다. 따라서 NGINX Plus가 해당 업스트림 서버에 자신의 ID를 증명하는 데 사용하는 TLS 인증서도 동적으로 선택할 수 있어야 할 수 있습니다.

NGINX Plus R25에서는 백엔드 서버에 대한 mTLS에 사용되는 구성 지시문이 인증서를 나타내는 변수를 허용하도록 확장되었습니다. 이 변수는 다음 중 하나를 참조할 수 있습니다:

• 디스크의 파일
• 앞에 data: 접두사가 붙은 PEM 형식의 원시 데이터

이를 통해 NGINX Plus는 인증서와 개인 키를 동적으로 선택할 수 있으며, 지속적으로 변화하는 최신 애플리케이션 환경에 유용합니다. 인증서와 개인 키를 NGINX Plus 키-값 저장소에 저장할 수 있으며, 개인 키가 디스크가 아닌 메모리에 저장되므로 보안이 강화됩니다. 또 다른 사용 사례로는 API 호출을 사용하여 키-값 저장소의 인증서를 업데이트하는 자동 인증서 교체가 있습니다.

다음 구성에서 NGINX Plus는 호스트 이름을 기준으로 요청을 서로 다른 업스트림 그룹으로 라우팅합니다. 프록시 연결에는 mTLS가 사용되며, 각 업스트림에 적합한 클라이언트 인증서가 동적으로 선택됩니다.

코드 예제를 로드하는 중…

다음 지시어는 업스트림 서버와의 mTLS를 위한 동적 인증서 로드를 지원합니다:

• grpc_ssl_certificate
• grpc_ssl_certificate_key
• proxy_ssl_certificate
• proxy_ssl_certificate_key
• uwsgi_ssl_certificate
• uwsgi_ssl_certificate_key

HTTP 요청 처리를 위한 보안 강화

NGINX 철학의 핵심 원칙 중 하나는 특히 보안 측면에서 지속적으로 개선하는 것입니다. 이를 위해 보안 연구원과의 협업, 업계를 선도하는 F5의 보안 기술을 제품에 통합하는 작업, 내부 개발 활동 등 가용한 모든 자원을 활용합니다.

마지막 항목의 예로, NGINX Plus R25는 다음과 같은 잠재적 공격으로부터 애플리케이션을 보호하기 위해 HTTP 요청에 대해 몇 가지 추가 검사를 수행합니다. 예: 요청 스머글링. 다음 조건에 해당하면 오류를 반환합니다:

• HTTP/1.0 요청에 Transfer-Encoding 헤더가 포함된 경우
• The Transfer-Encoding 및 Content-Length 헤더가 모두 존재합니다
• 요청 줄 또는 헤더 이름에 공백이나 제어 문자가 있습니다
• There are spaces or control characters in the Host 헤더에 공백이나 제어 문자가 있습니다
• The CONNECT 메서드가 사용됩니다

또한 이제 프록시된 URI에서는 다음 문자가 항상 이스케이프됩니다: ", <, >, \, ^, `, {, |, }.

이러한 변경 사항은 선제적인 보안 강화 조치이며, 알려진 취약점에 대응하기 위해 이루어진 것이 아닙니다.

TCP/UDP 애플리케이션 재로드 시 필수 상태 확인 상태 유지

NGINX Plus는 필수 상태 확인을 사용하여 업스트림 그룹에 새로 추가된 서버가 클라이언트 요청을 프록시하기 전에 테스트를 거쳐 정상 상태인지 확인합니다. NGINX Plus R23 및 이전 버전에서는 구성 다시 로드 전의 상태와 관계없이 구성 다시 로드 후 업스트림 서버가 비정상 상태로 간주되었습니다. 따라서 NGINX Plus는 첫 번째 필수 상태 확인을 통과할 때까지 해당 서버로 요청을 보내지 않았습니다.

NGINX Plus R24에서는 HTTP 애플리케이션을 대상으로 구성 다시 로드 시 필수 상태 확인 상태를 선택적으로 유지하는 기능이 도입되었습니다. 다시 로드하기 전 마지막 필수 상태 확인에 성공했다면 NGINX Plus는 다시 로드 후 필수 상태 확인이 성공할 때까지 기다리지 않고 서버에 즉시 요청을 보낼 수 있습니다.

NGINX Plus R25에서는 이 기능이 TCP/UDP 애플리케이션(stream 컨텍스트 내)으로 확장되었습니다. HTTP의 경우와 마찬가지로 persistent 매개변수를 health_check 지시문에 mandatory 매개변수와 함께 추가합니다.

코드 예제를 로드하는 중…

NGINX JavaScript 모듈 개선 사항

NGINX JavaScript 모듈(njs)이 여러 버그 수정과 JavaScript ES6와의 호환성을 강화하는 일부 기능 개선 사항을 포함한 버전 0.6.2로 업데이트되었습니다.

Variable Declaration with the let and const 키워드를 사용한 변수 선언

이제 NGINX JavaScript에서는 let 및 const 키워드를 사용하여 범위가 지정된 변수를 선언할 수 있습니다. 이전 버전의 NGINX Plus와 njs에서는 변수를 선언하고 할당할 때 var 키워드만 지원했습니다. 이 방식으로는 특정 block 문의 범위로 제한되는 변수를 사용할 수 없었지만, 이러한 변수는 서로 다른 프로젝트, 프로그래밍 언어 및 엔지니어링 팀이 공유 코드베이스나 라이브러리에서 협업할 때 흔히 발생하는 복잡성을 처리하는 데 필요합니다.

JavaScript ES6는 범위가 지정된 변수를 정의하기 위해 let 및 const 키워드를 제공합니다:

• let 변수의 범위는 해당 변수가 사용된 블록 문이나 표현식으로 제한됩니다. 반면 var 키워드는 변수를 전역으로 선언하거나, 블록 범위와 관계없이 함수 전체의 지역 변수로 선언합니다.
• const 변수는 let 키워드를 사용해 선언한 변수와 마찬가지로 블록 범위를 가집니다. 상수의 값은 재할당을 통해 변경할 수 없으며 다시 선언할 수도 없습니다.

모든 Promise 생성자 메서드 지원

With the addition of the Promise.all(), Promise.allSettled(), Promise.any(), Promise.race() 생성자 메서드가 추가됨에 따라, 이제 njs는 JavaScript ES6 표준에 정의된 모든 생성자 메서드를 지원합니다.

NGINX Plus 업그레이드 또는 체험

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

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

작성자 소개

Zach Westall수석 제품 마케팅 매니저

Zach Westall의 다른 블로그 게시물