NGINX Plus R18 출시 발표

Liam Crilly제품 관리 부문 수석 이사

NGINX Plus 릴리스 18(R18)이 출시되었음을 기쁘게 알려드립니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 하나로 통합한 유일한 솔루션입니다. NGINX Open Source를 기반으로 하는 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 개선 사항 – 지원되는 OpenID Connect 참조 구현을 지속적으로 개선하고 있습니다. 이 구현은 NGINX Plus R15에서 처음 출시되었습니다. 이번 릴리스에서는 불투명 세션 토큰, 새로 고침 토큰 및 로그아웃 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 모듈을 활용한 모듈식 코드 구성과 공식 NGINX Ingress Controller for Kubernetes의 Helm 직접 설치 기능이 포함됩니다.

중요한 동작 변경 사항

• 더 이상 사용되지 않는 API – NGINX Plus R13(2017년 8월)에서는 메트릭 수집 및 업스트림 그룹의 동적 재구성을 위한 완전히 새로운 NGINX Plus API가 도입되어, 이전에 이러한 기능을 구현하던 Status 및 Upstream Conf 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 모듈에서 제거되었습니다. function(req,res) 구문을 사용하여 선언된 함수가 res 객체의 속성도 참조하는 경우 런타임 오류가 발생하며, HTTP 상태 코드 500과 해당 오류 로그 항목이 반환됩니다:

YYYY/MM/DD hh:mm:ss [error] 34#34: js exception: TypeError: cannot get property "return" of undefined

• 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입니다.
  • Debian 8.0은 NGINX Plus R19에서 제거될 예정입니다
  • Ubuntu 14.04는 NGINX Plus R19에서 지원이 중단됩니다

새로운 기능 상세 설명

동적 SSL/TLS 인증서 로딩

이전 버전의 NGINX Plus에서는 보안 사이트와 애플리케이션의 SSL/TLS 인증서를 관리할 때 일반적으로 각 호스트 이름마다 별도의 server 블록을 만들고 인증서와 연결된 개인 키를 디스크의 파일로 정적으로 지정했습니다. (가독성을 위해 이제부터는 인증서와 키의 쌍을 인증서라고 하겠습니다.) 그런 다음 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 핸드셰이크 중에 디스크에서 읽히고 파일 시스템 캐시를 통해 메모리에 캐시되므로 메모리 사용량이 더욱 줄어듭니다.

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

코드 예제를 로드하는 중…

이와 동일한 server 구성은 보안 사이트 수에 제한 없이 사용할 수 있습니다. 여기에는 두 가지 이점이 있습니다:

1. 각 호스트 이름마다 별도의 server 블록을 둘 필요가 없어 구성이 훨씬 간결해지고, 그에 따라 읽고 관리하기도 쉬워집니다.
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":"-----BEGIN RSA PRIVATE KEY-----\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에서 키를 가져오도록 하려면 engine:engine-name:key-id 매개변수를 ssl_certificate_key 지시문에 사용하십시오.

OpenID Connect 개선 사항

NGINX Plus는 당사의 참조 구현을 통해 백엔드 애플리케이션에 OpenID Connect 인증 및 통합 로그인을 지원합니다. 이제 변수를 사용하여 JavaScript 모듈에서 키-값 저장소를 직접 수정할 수 있게 되면서 이 기능이 더욱 간소화되고 향상되었습니다(아래 참조).

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

이제 OpenID Connect 참조 구현은 새로 고침 토큰도 지원하므로 사용자 상호 작용 없이 만료된 ID 토큰을 원활하게 갱신할 수 있습니다. NGINX Plus는 권한 부여 서버에서 전송한 새로 고침 토큰을 키-값 저장소에 저장하고 불투명 세션 토큰과 연결합니다. ID 토큰이 만료되면 NGINX Plus는 새로 고침 토큰을 권한 부여 서버로 다시 전송합니다. 세션이 여전히 유효하면 권한 부여 서버에서 새 ID 토큰을 발급하며, 이 토큰은 키-값 저장소에 원활하게 업데이트됩니다. 새로 고침 토큰을 사용하면 수명이 짧은 ID 토큰을 사용할 수 있으므로 사용자에게 불편을 주지 않으면서 보안을 강화할 수 있습니다.

이제 OpenID Connect 참조 구현에서 로그아웃 URL을 제공합니다. 로그인한 사용자가 /logout URI에 접속하면 키-값 저장소에서 ID 토큰과 새로 고침 토큰이 삭제되며, 이후 요청 시 다시 인증해야 합니다.

가상 서버의 포트 범위

일반적으로 server 블록에는 NGINX Plus가 수신 대기하는 단일 포트를 지정하는 listen 지시어가 하나 있으며, 여러 포트를 구성해야 하는 경우 각 포트마다 listen 지시어를 추가합니다. NGINX Plus R18부터는 개별 80‑90 지시어를 많이 지정하기 번거로운 경우 listen과 같은 포트 범위도 지정할 수 있습니다.

HTTP listen 지시문과 TCP/UDP(Stream) listen 지시문 모두에 포트 범위를 지정할 수 있습니다. 다음 구성에서는 NGINX Plus가 패시브 모드의 FTP 서버를 프록시하도록 설정하며, 데이터 포트는 광범위한 TCP 포트 중에서 선택됩니다.

코드 예제를 로드하는 중…

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

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

키-값 저장소를 사용하도록 설정하면 NGINX Plus는 입력 키(일반적으로 요청 메타데이터의 일부)를 기준으로 저장된 값에 대한 변수를 제공합니다. 이전에는 키-값 저장소의 값을 생성, 수정 또는 삭제하려면 NGINX Plus API를 사용해야만 했습니다. NGINX Plus R18부터는 값을 보유하는 변수를 설정하여 구성에서 직접 키의 값을 변경할 수 있습니다.

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

코드 예제를 로드하는 중…

The set 지시어(7행)는 각 클라이언트 IP 주소($last_uri)에 값($remote_addr)을 할당합니다. 항목이 없으면 새로 생성하고, 있으면 현재 요청의 $uri를 반영하도록 값을 수정합니다. 따라서 NGINX Plus API를 호출하면 최근 클라이언트와 이들이 요청한 URI의 현재 목록을 확인할 수 있습니다.

$ 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에서는 이 중요한 기능에 두 가지 기능이 추가되었습니다.

• 상태 확인에서 임의의 변수 테스트 지원
• 상태 확인 실패 시 TCP 세션을 종료하는 기능

상태 확인에서 임의 변수 테스트

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

더욱 복잡한 검사를 위해 NGINX Plus R18에서는 이제 모든 변수의 값을 테스트할 수 있는 require 지시어를 제공합니다. 여기에는 표준 NGINX 변수와 사용자가 선언한 변수가 모두 포함됩니다. 변수는 map 블록, 정규식, 심지어 스크립팅 확장 기능으로도 평가할 수 있으므로 상태 검사를 더욱 유연하게 정의할 수 있습니다.

The require 지시어는 match 블록 내에서 하나 이상의 변수를 지정하며, 테스트를 통과하려면 해당 변수의 값이 모두 0이 아니어야 합니다. 다음 샘플 구성에서는 응답을 캐시할 수 있음을 나타내는 헤더, 즉 값이 0이 아닌 Expires 헤더 또는 Cache-Control 헤더를 반환하는 업스트림 서버를 정상 서버로 정의합니다.

코드 예제를 로드하는 중…

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

상태 확인 실패 시 계층 4 연결 종료

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

NGINX Plus R18에 새로 추가된 proxy_session_drop 지시어를 사용하면 오프라인 서버에서 다음 패킷을 수신하거나 해당 서버로 전송하는 즉시 연결을 종료할 수 있습니다. 그러면 클라이언트가 강제로 다시 연결되며, 이때 NGINX Plus는 클라이언트의 요청을 정상 상태의 백엔드 서버로 프록시합니다.

이 지시어를 활성화하면 다음 두 가지 조건에서도 기존 연결이 종료됩니다. 능동 상태 확인에 실패한 경우와 어떤 이유로든 서버가 업스트림 그룹에서 제거된 경우입니다. 여기에는 백엔드 서버가 서비스 레지스트리에서 제공하는 것과 같이 여러 IP 주소를 가진 호스트 이름으로 정의되어 DNS 조회를 통해 제거되는 경우도 포함됩니다.

NGINX Plus R18의 기타 개선 사항

간소화된 클러스터링 구성

NGINX Plus는 NGINX Plus R15부터 클러스터 전체의 런타임 상태 동기화를 지원해 왔습니다. 현재 영역 동기화 모듈은 NGINX Plus 인스턴스로 구성된 클러스터형 배포 환경 전반에서 고정 세션, 요청 속도 제한, 키-값 저장소의 상태 데이터를 공유할 수 있도록 지원합니다.

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

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

새롭게 추가 및 업데이트된 동적 모듈

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

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

NGINX Plus 에코시스템 업데이트

NGINX JavaScript 모듈 개선 사항

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

다음 예제에서는 비교적 간단한 사용 사례에 필요한 코드를 구성하고 단순화하는 데 JavaScript 모듈을 활용하는 방법을 보여 줍니다. 여기서는 JavaScript를 사용하여 사용자 개인정보 보호를 위한 데이터 마스킹을 수행함으로써 실제 클라이언트 IP 주소 대신 해시 처리된(마스킹된) 주소가 로그에 기록되도록 합니다. 로그에서 특정 마스킹 IP 주소는 항상 동일한 클라이언트를 나타내지만, 실제 IP 주소로 되돌릴 수는 없습니다.

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

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

NGINX Plus R22 이상에서는 JavaScript import 및 export 모듈 외에도 njs js_import 지시어를 사용하여 JavaScript 코드를 기능별로 여러 파일에 나누어 구성할 수 있습니다.]

IP 주소 마스킹에 필요한 함수들을 단일 함수를 내보내는 JavaScript 모듈에 넣습니다. maskIp()입니다. 내보낸 함수는 모듈 내에서만 사용할 수 있고 다른 JavaScript 코드에서는 호출할 수 없는 비공개 함수에 의존합니다.

코드 예제를 로드하는 중…

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

코드 예제를 로드하는 중…

따라서 main.js는 매우 간단하며 NGINX 구성에서 참조하는 함수만 포함합니다. import 문은 모듈 파일의 상대 경로 또는 절대 경로를 지정합니다. 상대 경로를 지정하는 경우 새로운 js_path 지시어를 사용하여 검색할 추가 경로를 지정할 수 있습니다.

코드 예제를 로드하는 중…

새로운 기능은 특히 많은 수의 njs 지시문을 사용하거나 JavaScript 코드의 양이 많은 경우 가독성과 유지보수성을 크게 향상시킵니다. 이제 각 팀은 기본 JavaScript 파일에 복잡하게 병합할 필요 없이 자체 JavaScript 코드를 유지보수할 수 있습니다.

Kubernetes용 NGINX Ingress Controller를 Helm으로 직접 설치

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

주요 버그 수정 사항

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

이제 proxy_upload_rate 및 proxy_download_rate 지시어가 UDP 데이터그램에 올바르게 적용됩니다.

상태 확인과 함께 PROXY 프로토콜 TLV를 사용하면 NGINX가 비정상 종료됨

이전에는 NGINX Plus가 health_check 지시문이 $proxy_protocol_tlv_0xEA 변수를 참조하는 location에 포함된 경우(예: AWS PrivateLink 환경) 비정상 종료될 수 있었습니다.

최소 시간 부하 분산이 가장 느린 업스트림을 무시함

이전에는 업스트림 서버의 응답 속도가 장시간 매우 느린 경우, 지정된 시간 메트릭 값이 다른 업스트림 서버에 비해 지나치게 높아져 다시는 선택되지 않을 수 있었습니다. 이제는 새로운 측정값에 따라 이동 평균이 낮아지면서, 이전에 느렸던 업스트림 서버도 결국 로드 밸런서의 선택 프로세스에 다시 포함됩니다.

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

NGINX Plus로 업그레이드하거나 사용해 보기

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

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

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

작성자 소개

Liam Crilly제품 관리 부문 수석 이사

Liam Crilly의 다른 블로그 게시물