블로그 | NGINX

NGINX Plus R18 발표

NGINX-F5-수평-검정-유형-RGB의 일부
리엄 크릴리 썸네일
리암 크릴리
2019년 4월 9일 게시


NGINX Plus 릴리스 18(R18)이 출시되어 기쁩니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 모두 갖춘 유일한 제품입니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus에는 독점적인 향상된 기능과 수상 경력에 빛나는 지원이 포함되어 있습니다. R18은 DevOps의 구성 워크플로를 간소화하고 대규모 애플리케이션의 보안과 안정성을 향상시킵니다.

현재 87%가 넘는 웹사이트가 SSL/TLS를 사용하여 인터넷 통신을 암호화하고 있는데, 이는 단 3년 전만 해도 66%에 불과했습니다. 종단간 암호화는 이제 웹사이트와 애플리케이션의 기본 배포 패턴이며, SSL/TLS 인증서의 폭발적 증가로 인해 일부 회사는 프로덕션 환경에서 수천 개의 인증서를 관리해야 합니다. 이를 위해서는 인증서 배포 및 구성에 대한 보다 유연한 접근 방식이 필요합니다.

이번 릴리스의 새로운 기능은 동적 인증서 로딩을 지원한다는 것입니다. 인증서가 수천 개이므로 디스크에서 로드하기 위해 구성에서 각각을 수동으로 정의하는 것은 확장성이 없습니다. 그 프로세스가 지루할 뿐만 아니라 구성이 관리할 수 없을 정도로 커지고 NGINX Plus의 시작 속도가 너무 느립니다. NGINX Plus R18을 사용하면 이제 구성에서 개별적으로 나열하지 않고도 SSL/TLS 인증서를 필요에 따라 로드할 수 있습니다. 자동화된 배포를 더욱 단순화하기 위해 인증서는 NGINX Plus API를 통해 프로비저닝될 수 있으며, 디스크에 보관할 필요도 없습니다.

NGINX Plus R18 의 추가 새로운 기능은 다음과 같습니다.

  • OpenID Connect 개선 사항 – NGINX Plus R15 에서 처음 출시된 지원되는 OpenID Connect 참조 구현을 지속적으로 개선해 나가고 있습니다. 이번 릴리스에서는 불투명 세션 토큰, 새로 고침 토큰 및 로그아웃 URL에 대한 지원이 추가되었습니다.
  • 가상 서버의 포트 범위 – NGINX Plus 가상 서버는 이제 80‑90 과 같은 다양한 포트에서 수신하도록 구성할 수 있습니다. 이를 통해 NGINX Plus는 포트 범위를 예약해야 하는 수동 FTP와 같은 더 광범위한 애플리케이션을 지원할 수 있습니다.
  • 구성의 키-값 정의 – NGINX Plus 키-값 저장소는 IP 주소의 동적 거부 목록 및 동적 DDoS 완화를 포함한 광범위한 사용 사례에 대한 솔루션을 지원합니다. 이제 NGINX Plus 구성에서 변수를 사용하여 키-값 쌍을 직접 생성할 수 있어 더 많은 사용 사례가 가능해졌습니다.
  • 활성 상태 검사를 위한 더 큰 유연성 – NGINX Plus의 활성 상태 검사는 백엔드 시스템의 상태를 모니터링하는 강력한 도구입니다. NGINX Plus R18을 사용하면 이제 모든 NGINX 변수의 값을 테스트하고, 실패한 서버에 대한 기존 TCP 연결을 자동으로 종료할 수 있습니다.

이번 릴리스의 핵심은 클러스터 환경을 위한 간소화된 구성과 새롭고 업데이트된 동적 모듈(Brotli 포함)입니다. NGINX Plus 생태계에 대한 업데이트에는 NGINX JavaScript 모듈을 통한 모듈식 코드 구성과 Kubernetes용 공식 NGINX Ingress Controller의 Helm 직접 설치가 포함됩니다.

행동의 중요한 변화

  • 폐기된 API – NGINX Plus R13 (2017년 8월)은 이전에 해당 기능을 구현했던 Status 및 Upstream Conf API를 대체하여 메트릭 수집 및 업스트림 그룹의 동적 재구성을 위한 완전히 새로운 NGINX Plus API를 도입했습니다. 당시 발표된 대로, 지원되지 않는 API는 NGINX Plus R16 에서 종료될 때까지 상당 기간 동안 계속 사용 및 지원되었습니다. 구성에 status 및/또는 upstream_conf 지시문이 포함되어 있는 경우 R18로 업그레이드하는 과정에서 이를 api 지시문으로 바꿔야 합니다.

    새로운 NGINX Plus API 로의 마이그레이션에 대한 조언과 지원이 필요하면 블로그의 전환 가이드를 참조하거나 당사 지원팀에 문의하세요.

  • 업데이트된 listen 지시문 – 이전에는 listen 지시문이 여러 IP 주소로 확인되는 호스트 이름을 지정한 경우 첫 번째 IP 주소만 사용되었습니다. 이제 반환된 모든 IP 주소에 대한 수신 소켓이 생성됩니다.

  • NGINX JavaScript 모듈(njs) 변경 사항 – 더 이상 사용되지 않는 req.response 객체가 NGINX JavaScript 모듈 에서 제거되었습니다. req,res 구문을 사용하여 선언된 함수가 res 객체의 속성을 참조하는 경우 런타임 오류가 발생하고 HTTP 상태 코드가 반환됩니다.500 그리고 오류 로그에 해당 항목이 있습니다.

    YYYY / MM / DD hh : mm : ss [오류] 34#34: js 예외: TypeError: 정의되지 않은 "return" 속성을 가져올 수 없습니다.

    JavaScript 코드는 런타임에 해석되므로 nginx -t 구문 검증 명령은 잘못된 개체와 속성의 존재를 감지하지 못합니다. NGINX Plus R18 로 업그레이드하기 전에 JavaScript 코드를 주의 깊게 검사하고 이러한 객체를 제거해야 합니다.

    또한, NGINX 상태를 나타내는 JavaScript 객체(예: r.headersIn )는 이제 주어진 속성에 대한 값이 없는 경우 빈 문자열 대신 undefined를 반환합니다. 이 변경으로 인해 NGINX 전용 JavaScript 객체가 이제 기본 제공 JavaScript 객체와 동일하게 동작하게 되었습니다.

  • 제거되었거나 제거될 예정인 이전 운영 체제:

    • Amazon Linux 2017.09는 더 이상 지원되지 않습니다. 현재 지원되는 가장 오래된 버전은 2018.03입니다.
    • CentOS/Oracle Linux/Red Hat Enterprise Linux 7.3은 더 이상 지원되지 않습니다. 가장 오래된 지원 버전은 현재 7.4입니다.
    • NGINX Plus R19 에서는 Debian 8.0이 제거됩니다.
    • NGINX Plus R19 에서 Ubuntu 14.04가 제거됩니다.

새로운 기능에 대한 자세한 정보

동적 SSL/TLS 인증서 로딩

이전 버전의 NGINX Plus에서는 보안 사이트와 애플리케이션의 SSL/TLS 인증서를 관리하는 일반적인 방법은 각 호스트 이름에 대해 별도의 서버 블록을 만들고 인증서와 관련 개인 키를 디스크의 파일로 정적으로 지정하는 것이었습니다. (읽기의 편의를 위해 지금부터는 인증서와 키의 쌍을 지칭할 때 '인증서 '라는 단어를 사용하겠습니다.) 그런 다음 NGINX Plus가 시작되면서 인증서가 로드되었습니다. NGINX Plus R18을 사용하면 인증서를 동적으로 로드하고, 선택적으로 디스크가 아닌 메모리 내 NGINX Plus 키 값 저장소에 저장할 수 있습니다.

동적 인증서 로딩에는 두 가지 주요 사용 사례가 있습니다.

두 경우 모두 NGINX Plus는 TLS 핸드셰이크의 일부로 서버 이름 표시(SNI)에서 제공된 호스트 이름을 기반으로 동적 인증서 로딩을 수행할 수 있습니다. 이를 통해 NGINX Plus는 단일 서버 구성에서 여러 개의 보안 웹사이트를 호스팅하고 들어오는 각 요청에 대해 필요에 따라 적절한 인증서를 선택할 수 있습니다.

디스크에서 SSL/TLS 인증서의 지연 로딩

"지연 로딩"을 사용하면 SSL/TLS 인증서는 요청이 도착하고 해당 호스트 이름을 지정할 때만 메모리에 로드됩니다. 이렇게 하면 구성이 간소화되고(호스트 이름별 인증서 목록이 없어짐) 호스트의 리소스 사용량이 줄어듭니다. 인증서의 수가 많으면(수천 개) 모든 인증서를 디스크에서 읽어 메모리에 로드하는 데 몇 초가 걸릴 수 있습니다. 게다가 NGINX 구성을 다시 로드하면 많은 양의 메모리가 사용됩니다. 새로운 작업자 프로세스 세트가 이전 작업자 세트에서 로드한 인증서와 함께 인증서의 새 사본을 메모리에 로드하기 때문입니다. 이전 인증서는 이전 구성에 따라 설정된 최종 연결이 완료되고 이전 워커가 종료될 때까지 메모리에 남아 있습니다. 구성이 자주 업데이트되고 클라이언트 연결이 장시간 지속되면 메모리에 인증서 사본이 여러 개 있을 수 있으며, 이는 잠재적으로 메모리 고갈로 이어질 수 있습니다.

디스크에서 인증서를 지연 로딩하는 방식은 인증서 수가 많은 배포나 구성을 자주 다시 로드하는 경우에 이상적입니다. 예를 들어, SaaS 회사는 일반적으로 각 고객에게 별도의 하위 도메인을 할당합니다. 새로운 고객을 온보딩하는 작업은 각 고객마다 새 가상 서버를 생성한 다음 새 구성과 고객의 인증서를 각 NGINX Plus 인스턴스에 복사해야 하기 때문에 어렵습니다. 지연 로딩을 사용하면 구성을 변경할 필요가 없습니다. 각 인스턴스에 인증서를 배포하기만 하면 됩니다.

지연 로딩을 지원하기 위해 ssl_certificate 및 ssl_certificate_key 지시어는 이제 가변 매개변수를 허용합니다. 변수는 SNI 처리 중에 사용할 수 있어야 하며, 이는 요청 줄과 헤더가 읽히기 전에 수행됩니다. 가장 일반적으로 사용되는 변수는 $ssl_server_name 으로, SNI 처리 중에 NGINX Plus가 추출한 호스트 이름을 보관합니다. 인증서와 키는 각 클라이언트 세션이 시작될 때 TLS 핸드셰이크 중에 디스크에서 읽혀지고 파일 시스템 캐시의 메모리에 캐시되어 메모리 사용률이 더욱 줄어듭니다.

보안 사이트 구성은 다음과 같이 간단해집니다.

동일한 서버 구성은 무제한의 보안 사이트에 사용될 수 있습니다. 이것에는 두 가지 이점이 있습니다.

  1. 각 호스트 이름에 대한 별도의 서버 블록을 제거하여 구성을 훨씬 더 작게 만들고 읽고 관리하기 쉽게 만듭니다.
  2. 새로운 호스트 이름을 추가할 때마다 구성을 다시 로드할 필요가 없습니다. 구성을 다시 로드해야 하는 경우 NGINX Plus가 모든 인증서를 로드하지 않기 때문에 훨씬 더 빠릅니다.

지연 로딩을 사용하면 디스크에서 인증서를 검색하는 데 필요한 파일 시스템 호출로 인해 TLS 핸드셰이크가 환경에 따라 20~30% 더 오래 걸립니다. 그러나 추가적인 지연은 핸드셰이크에만 영향을 미칩니다. TLS 세션이 설정되면 요청 처리에는 평소와 같은 시간이 걸립니다.

메모리 내 SSL/TLS 인증서 저장소

이제 SSL/TLS 인증서 데이터를 디스크의 파일뿐만 아니라 메모리, NGINX Plus 키-값 저장소 에도 저장할 수 있습니다. ssl_certificate 또는 ssl_certificate_key 지시문에 대한 매개변수가 data: 접두사로 시작하면 NGINX Plus는 해당 매개변수를 원시 PEM 데이터(실제로 데이터가 있는 키-값 저장소의 항목을 식별하는 변수 형태로 제공됨)로 해석합니다.

디스크가 아닌 키-값 저장소에 저장하는 것의 또 다른 이점은 배포 이미지와 백업에 더 이상 개인 키 사본이 포함되지 않는다는 것입니다. 공격자는 개인 키 사본을 사용하여 서버로 송수신되는 모든 트래픽을 해독할 수 있습니다. 고도로 자동화된 배포 파이프라인을 갖춘 회사는 NGINX Plus API를 사용하여 키-값 저장소에 인증서를 프로그래밍 방식으로 삽입할 수 있는 유연성의 이점을 얻습니다. 또한 개인 키 보호를 위한 실제 하드웨어 보안 모듈(HSM)이 없는 퍼블릭 클라우드 환경으로 애플리케이션을 마이그레이션하는 회사는 개인 키를 디스크에 저장하지 않음으로써 추가적인 보안 혜택을 누릴 수 있습니다.

키-값 저장소에서 인증서를 로드하기 위한 샘플 구성은 다음과 같습니다.

NGINX Plus API를 사용하여 인증서와 개인 키를 키-값 저장소에 업로드하는 한 가지 방법은 다음 curl 명령을 실행하는 것입니다(키 데이터의 맨 처음만 표시됨). curl 명령을 사용하는 경우 PEM 데이터의 사본을 만들고 모든 줄 바꿈을 \n 으로 바꿔야 합니다. 그렇지 않으면 줄 바꿈이 JSON 페이로드에서 제거됩니다.

$ curl -d '{"www.example.com":"-----RSA 개인 키 시작-----\n..."}' http://localhost:8080/api/4/http/keyvals/ssl_key

NGINX Plus의 클러스터형 배포 에는 인증서에 키-값 저장소를 사용하는 것이 이상적입니다. 인증서를 한 번만 업로드하면 클러스터 전체에 자동으로 전파되기 때문입니다. 인증서 데이터 자체를 보호하려면 zone_sync_ssl 지시문을 사용하여 클러스터 멤버 간 연결을 TLS로 암호화합니다. 키-값 저장소를 사용하는 것은 단기 인증서나 Let's Encrypt 및 Hashicorp Vault 와 같은 인증서 발급자와의 통합을 자동화하는 데에도 이상적입니다.

디스크에서의 지연 로딩과 마찬가지로 키-값 저장소에서 인증서를 로드하는 작업은 TLS 핸드셰이크를 수행할 때마다 발생하며, 이로 인해 성능이 저하됩니다. 가장 빠른 TLS 핸드셰이크를 위해 디스크에 있는 파일에 하드코딩된 매개변수와 함께 ssl_certificate 및 ssl_certificate_key 지침을 사용합니다. 또한 ECC 인증서는 RSA 인증서보다 빠릅니다.

키-값 저장소를 사용하면 디스크 저장소보다 공격자가 개인 키 파일을 얻는 것이 더 어렵지만 NGINX Plus 호스트에 대한 셸 액세스 권한이 있는 공격자는 여전히 메모리에 로드된 키에 액세스할 수 있습니다. 키‑값 저장소는 하드웨어 보안 모듈 (HSM)만큼 개인 키를 보호하지 않습니다. NGINX Plus가 HSM에서 키를 가져오게 하려면 ssl_certificate_key 지시문에 engine: engine-name : key-id 매개변수를 사용하세요.

OpenID Connect 향상

NGINX Plus는 참조 구현을 통해 백엔드 애플리케이션에 대한 OpenID Connect 인증 및 Single Sign‑On을 지원합니다. 이제 키-값 저장소를 JavaScript 모듈에서 변수를 사용하여 직접 수정할 수 있으므로 이 작업이 간소화되고 향상되었습니다( 아래 참조 ).

OpenID Connect 참조 구현은 이제 브라우저 쿠키 형태로 클라이언트에게 불투명 세션 토큰을 발급합니다. 불투명 토큰에는 사용자의 개인 식별 정보가 포함되지 않으므로 클라이언트에 민감한 정보가 저장되지 않습니다. NGINX Plus는 실제 ID 토큰을 키-값 저장소에 저장하고 이를 클라이언트가 제시하는 불투명 토큰으로 대체합니다. 모든 요청에 대해 JWT 검증이 수행되므로 만료되거나 유효하지 않은 토큰은 거부됩니다.

OpenID Connect 참조 구현은 이제 새로 고침 토큰도 지원하므로 사용자 상호 작용이 필요 없이 만료된 ID 토큰을 원활하게 새로 고칠 수 있습니다. NGINX Plus는 인증 서버에서 보낸 새로 고침 토큰을 키-값 저장소에 저장하고 이를 불투명 세션 토큰과 연결합니다. ID 토큰이 만료되면 NGINX Plus는 새로 고침 토큰을 권한 부여 서버로 다시 보냅니다. 세션이 여전히 유효한 경우 인증 서버는 키‑값 저장소에서 원활하게 업데이트되는 새 ID 토큰을 발급합니다. 새로 고침 토큰을 사용하면 단기 ID 토큰을 사용할 수 있으며, 이는 사용자에게 불편을 주지 않고 더 나은 보안을 제공합니다.

OpenID Connect 참조 구현은 이제 로그아웃 URL을 제공합니다. 로그인한 사용자가 /logout URI를 방문하면 해당 사용자의 ID와 새로 고침 토큰이 키-값 저장소에서 삭제되고 향후 요청을 할 때 다시 인증해야 합니다.

가상 서버의 포트 범위

일반적으로 서버 블록에는 NGINX Plus가 수신하는 단일 포트를 지정하는 하나의 listen 지시어가 있습니다. 여러 포트를 구성해야 하는 경우 각 포트에 대한 추가 listen 지시어가 있습니다. NGINX Plus R18을 사용하면 개별 수신 지시문을 많이 지정하기 불편한 경우 80‑90 과 같이 포트 범위를 지정할 수도 있습니다.

HTTP 수신 지시문과 TCP/UDP(스트림) 수신 지시문 모두에 대해 포트 범위를 지정할 수 있습니다. 다음 구성을 사용하면 NGINX Plus가 수동 모드에서 FTP 서버의 프록시 역할을 할 수 있으며, 여기서 데이터 포트는 광범위한 TCP 포트 중에서 선택됩니다.

이 구성은 연결이 들어온 동일한 포트에서 FTP 서버로 프록시 연결을 하는 가상 서버를 설정합니다.

변수를 통한 키-값 저장소 업데이트

키-값 저장소가 활성화되면 NGINX Plus는 입력 키(일반적으로 요청 메타데이터의 일부)를 기반으로 해당 저장소에 저장된 값에 대한 변수를 제공합니다. 이전에는 키-값 저장소에서 값을 생성, 수정 또는 삭제하는 유일한 방법은 NGINX Plus API를 사용하는 것이었습니다. NGINX Plus R18을 사용하면 값을 보관하는 변수를 설정하여 구성에서 직접 키의 값을 변경할 수 있습니다.

다음 예제에서는 키-값 저장소를 사용하여 최근에 사이트에 액세스한 클라이언트 IP 주소 목록과 해당 주소가 요청한 마지막 URI를 유지합니다.

set 지시문(7번째 줄)은 각 클라이언트 IP 주소( $remote_addr )에 값( $last_uri )을 할당하고, 해당 항목이 없으면 새 항목을 만들거나 현재 요청의 $uri를 반영하도록 값을 수정합니다. 따라서 최근 클라이언트의 현재 목록과 요청된 URI는 NGINX Plus API를 호출하여 사용할 수 있습니다.

$ curl http://localhost:8080/api/4/http/keyvals/recents { "10.19.245.68": "/blog/nginx-plus-r18-released/", "172.16.80.227": "/products/nginx/", "10.219.110.168": "/blog/nginx-unit-1-8-0-now-available" }

NGINX JavaScript 모듈(njs) 및 Lua 모듈과 같은 스크립팅 확장을 사용하면 더 강력한 사용 사례를 얻을 수 있습니다. njs를 활용하는 모든 구성은 키-값 저장소에서 지원되는 변수(예: r.variables.last_uri )를 포함하여 모든 변수에 액세스할 수 있습니다.

활성 건강 검진을 위한 더 큰 유연성

NGINX Plus의 활성 상태 검사는 백엔드 시스템을 정기적으로 테스트하므로, 트래픽이 상태가 좋지 않은 것으로 알려진 시스템으로 전송되지 않습니다. NGINX Plus R18은 이 중요한 기능에 두 가지 추가 기능을 추가했습니다.

건강 검진에서 임의 변수 테스트

백엔드 애플리케이션에 대한 상태 검사를 정의할 때 일치 블록을 사용하여 HTTP 상태 코드, 응답 헤더 및/또는 본문의 문자열을 포함한 응답의 여러 측면에 대한 예상 값을 지정할 수 있습니다. 응답에 예상 값이 모두 포함되어 있으면 백엔드는 정상인 것으로 간주됩니다.

훨씬 더 복잡한 검사를 위해 NGINX Plus R18은 이제 표준 NGINX 변수와 사용자가 선언한 변수 모두의 값을 테스트하는 require 지시문을 제공합니다. 변수를 맵 블록, 정규 표현식, 심지어 스크립팅 확장 기능으로도 평가할 수 있으므로 상태 검사를 정의할 때 더 많은 유연성을 얻을 수 있습니다.

match 블록 내의 require 지시문은 하나 이상의 변수를 지정하는데, 테스트를 통과하려면 모든 변수가 0이 아닌 값을 가져야 합니다. 다음 샘플 구성은 응답이 캐시 가능하다는 것을 나타내는 헤더(0이 아닌 값을 갖는 Expires 헤더 또는 Cache-Control 헤더)를 반환하는 정상적인 업스트림 서버를 정의합니다.

이런 방식으로 맵 블록을 사용하는 것은 OR 논리를 NGINX Plus 구성에 통합하는 일반적인 방법입니다. require 지시문을 사용하면 상태 검사에서 이 기술을 활용할 수 있고, 고급 상태 검사를 수행할 수도 있습니다. JavaScript 모듈(njs)을 사용하여 각 업스트림 서버의 응답에 대한 추가 속성(예: 응답 시간) 을 분석함으로써 고급 상태 검사를 정의할 수도 있습니다.

상태 검사에 실패할 경우 레이어 4 연결 종료

NGINX Plus가 TCP/UDP 애플리케이션에 대한 계층 4(L4) 로드 밸런서 역할을 하는 경우 클라이언트와 백엔드 서버 간에 설정된 연결에서 양방향으로 데이터를 프록시합니다. 활성 상태 검사는 이러한 구성의 중요한 부분이지만, 기본적으로 백엔드 서버의 상태는 새 클라이언트가 연결을 설정하려고 할 때만 고려됩니다. 백엔드 서버가 오프라인이 되면 기존 클라이언트가 서버로 데이터를 보낼 때 시간 초과가 발생할 수 있습니다.

NGINX Plus R18 의 새로운 proxy_session_drop 지시어를 사용하면 오프라인 서버에서 다음 패킷을 수신하거나 오프라인 서버로 전송할 때 연결을 즉시 닫을 수 있습니다. 클라이언트는 다시 연결해야 하며 이때 NGINX Plus는 요청을 정상적인 백엔드 서버로 프록시합니다.

이 지시어가 활성화되면 두 가지 다른 조건(활성 상태 검사 실패 및 어떤 이유로든 업스트림 그룹에서 서버 제거)도 기존 연결을 종료합니다. 여기에는 DNS 조회를 통한 제거가 포함되는데, 여기서 백엔드 서버는 서비스 레지스트리 에서 제공하는 것과 같은 여러 IP 주소를 포함하는 호스트 이름으로 정의됩니다.

NGINX Plus R18의 기타 개선 사항

단순화된 클러스터링 구성

NGINX Plus는 NGINX Plus R15 부터 클러스터 전체 런타임 상태 동기화를 지원해 왔습니다. 현재 Zone Synchronization 모듈은 NGINX Plus 인스턴스의 클러스터 배포에서 스티키 세션 , 속도 제한 및 키-값 저장소 에 대한 상태 데이터 공유를 지원합니다.

이제 클러스터의 모든 인스턴스에 단일 zone_sync 구성을 사용할 수 있습니다. 이전에는 각 멤버의 IP 주소나 호스트 이름을 명시적으로 구성해야 했기 때문에 각 인스턴스의 구성이 약간씩 달랐습니다. 이제 listen 지시문의 address : port 매개변수에 와일드카드 값을 지정하여 zone_sync 서버가 모든 로컬 인터페이스에서 수신하도록 할 수 있습니다. 이 기능은 특히 NGINX Plus를 동적 클러스터에 배포할 때 매우 유용합니다. 이 경우 배포 시점까지 인스턴스의 IP 주소를 알 수 없습니다.

모든 인스턴스에서 동일한 구성을 사용하면 동적 환경(예: 자동 크기 조정 그룹 또는 컨테이너화된 클러스터)에서의 배포가 크게 간소화됩니다.

새롭고 업데이트된 동적 모듈

이번 릴리스에서는 다음과 같은 동적 모듈이 추가되거나 업데이트되었습니다.

  • 새로운 Brotli 압축 모듈 – Brotli는 LZ77 알고리즘, 허프만 코딩 및 2차 컨텍스트 모델링의 변형을 사용하는 범용 무손실 데이터 압축 알고리즘입니다.
  • 새로운 OpenTracing 모듈 – 이제 Datadog, Jaeger, Zipkin과 같은 다양한 분산 추적 서비스에 대한 OpenTracing 호환 요청으로 NGINX Plus를 계측할 수 있습니다.
  • 업데이트된 Lua 모듈 – Lua는 NGINX Plus용 스크립팅 언어입니다. 이 모듈은 이제 LuaJIT 2.1을 사용합니다.

NGINX Plus 에코시스템 업데이트

NGINX JavaScript 모듈의 향상

NGINX JavaScript 모듈(njs) 이 버전 0.3.0 으로 업데이트되었습니다. 가장 주목할 만한 개선 사항은 JavaScript 가져오기 및 내보내기 모듈에 대한 지원으로, 이를 통해 JavaScript 코드를 여러 개의 기능별 파일로 구성할 수 있습니다. 이전에는 모든 JavaScript 코드가 하나의 파일에 있어야 했습니다.

다음 예제는 JavaScript 모듈을 사용하여 비교적 간단한 사용 사례에 필요한 코드를 구성하고 단순화하는 방법을 보여줍니다. 여기서는 사용자의 개인 정보 보호를 위해 JavaScript를 사용하여 데이터 마스킹을 수행하여 실제 주소 대신 클라이언트 IP 주소의 해시(마스킹) 버전이 기록됩니다. 로그에 표시된 마스크된 IP 주소는 항상 동일한 클라이언트를 나타내지만, 실제 IP 주소로 다시 변환할 수는 없습니다.

[ 편집자 - 이 섹션의 예는 NGINX JavaScript 모듈의 많은 사용 사례 중 하나일 뿐입니다. 전체 목록은 NGINX JavaScript 모듈의 사용 사례를 참조하세요.

코드는 다음을 사용하도록 업데이트되었습니다. js_import 지시문은 다음을 대체합니다. js_포함 지시문에 NGINX 플러스 R23 그리고 나중에. 자세한 내용은 NGINX JavaScript 모듈 의 참조 문서를 참조하세요. 예제 구성 섹션에서는 NGINX 구성 및 JavaScript 파일에 대한 올바른 구문을 보여줍니다.

NGINX Plus R22 이상에서는 JavaScript 가져오기 및 내보내기 모듈 외에도 njs js_import 지시문을 사용하여 JavaScript 코드를 여러 함수별 파일로 구성할 수 있습니다.

IP 주소 마스킹에 필요한 기능을 단일 함수인 maskIp()를 내보내는 JavaScript 모듈에 넣었습니다. 내보낸 함수는 모듈 내에서만 사용할 수 있는 개인 함수에 따라 달라지며, 다른 JavaScript 코드에서는 호출할 수 없습니다.

이제 이 모듈을 기본 JavaScript 파일( main.js )로 가져올 수 있으며, 내보낸 함수를 참조할 수 있습니다.

결과적으로 main.js는 매우 간단하며 NGINX 구성에서 참조하는 함수만 포함하고 있습니다. import 문은 모듈 파일에 대한 상대 경로나 절대 경로를 지정합니다. 상대 경로가 제공되면 새로운 js_path 지시어를 사용하여 검색할 추가 경로를 지정할 수 있습니다.

새로운 기능은 가독성과 유지 관리성을 크게 개선합니다. 특히, 사용되는 njs 명령어가 많거나 JavaScript 코드가 많은 경우에 유용합니다. 이제 각 팀은 복잡한 기본 JavaScript 파일 병합을 수행하지 않고도 자체 JavaScript 코드를 유지 관리할 수 있습니다.

Kubernetes용 NGINX Ingress Controller의 직접 Helm 설치

이제 Helm 차트 소스 파일을 다운로드하지 않고도 새로운 Helm 저장소에서 직접 Kubernetes용 NGINX Ingress Controller를 설치할 수 있습니다(다운로드도 계속 지원됩니다). 자세한 내용은 GitHub 저장소를 참조하세요.

주목할만한 버그 수정

UDP 애플리케이션의 대역폭 제한

proxy_upload_rate 및 proxy_download_rate 지시어가 이제 UDP 데이터그램에서 올바르게 작동합니다.

Health Check가 포함된 PROXY 프로토콜 TLV가 NGINX를 충돌시킴

이전에는 AWS PrivateLink 환경 내에서와 같이 $proxy_protocol_tlv_0xEA 변수를 참조하는 위치에 health_check 지시문이 포함되면 NGINX Plus가 충돌할 수 있었습니다.

최소 시간 로드 밸런싱 무시 가장 느린 업스트림

이전에는 업스트림 서버가 오랫동안 느리게 응답하는 경우 지정된 시간 메트릭에 대한 값이 다른 업스트림 서버에 비해 너무 높아서 다시는 선택되지 않는 경우가 있었습니다. 이전에 느렸던 업스트림 서버는 이제 새로운 측정을 통해 이동 평균이 줄어들면서 로드 밸런서 선택 프로세스에 다시 도입되었습니다.

이는 업스트림 응답 시간을 선택 지표로 사용하는 부하 분산 알고리즘, 특히 least_time 및 least_time 매개변수를 사용한 random 에 적용됩니다.

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

NGINX Plus를 사용하고 계시다면 가능한 한 빨리 NGINX Plus R18 로 업그레이드하실 것을 적극 권장합니다. 또한 여러 가지 추가적인 수정 사항과 개선 사항을 얻을 수 있으며, 이는 지원 티켓을 제출해야 할 때 NGINX, Inc.에서 도움을 드리는 데 도움이 됩니다.

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

NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 평가판 으로 시작해 보세요. NGINX Plus가 어떻게 귀하의 애플리케이션을 제공하고 확장하는 데 도움이 될 수 있는지 직접 확인해 보세요.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."