NGINX Plus R27 발표

NGINX Plus 릴리스 27(R27)이 출시되어 기쁩니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus는 유일한 올인원 소프트웨어 웹 서버, 로드 밸런서, 역방향 프록시, 콘텐츠 캐시 및 API 게이트웨이입니다.

NGINX Plus R27 의 새롭고 향상된 기능은 다음과 같습니다.

• 상태 점검을 위한 Keepalive 연결 – 이전 릴리스에서는 NGINX Plus가 각 상태 점검에 대해 새로운 연결을 설정했습니다. HTTP health_check 지시문의 새로운 keepalive_time 매개변수는 상태 확인을 위한 keepalive 연결을 활성화하고 해당 연결의 수명을 설정합니다. 새로운 연결을 설정하는 것은 컴퓨팅 측면에서 비용이 많이 들기 때문에, 업스트림 서버가 많은 경우 연결을 재사용하면 CPU 사용량을 상당히 줄일 수 있습니다.
• 커널 TLS 지원 – NGINX Plus는 이제 이를 지원하기 위한 요구 사항을 충족하는 세 가지 운영 체제에서 커널 TLS(kTLS)를 지원합니다. FreeBSD 13, RHEL 9.0+ 및 Ubuntu 22.04 LTS .
• 업스트림 및 가상 서버에 대한 TLS 메트릭 – NGINX Plus는 이제 HTTPS를 통한 프록싱이 활성화된 경우 이전 릴리스에서 생성했던 글로벌 통계 외에도 개별 업스트림 및 가상 서버에 대한 TLS 통계를 생성합니다. TLS 핸드셰이크 문제를 해결할 때 클라이언트 측과 서버 측 모두의 메트릭을 갖는 것이 도움이 됩니다.
• JWT 검증 실패로 인한 오류 코드 사용자 정의 – NGINX Plus R25 및 R26 에서는 사용자 정의 JWT 검증 검사를 정의할 수 있지만 검증 실패에 대해 반환되는 오류 코드는 항상 다음과 같습니다. 401(허가되지 않음) . NGINX Plus R27은 auth_jwt_require 지시문에 error 매개변수를 도입하여 코드를 설정할 수 있도록 합니다.401 또는 403(금지됨) 인증 및 권한 부여 오류를 더 잘 구분하기 위해 각 검사에 대해 허용됩니다.
• NGINX JavaScript 및 Prometheus-njs 모듈 향상 – NGINX JavaScript 모듈 향상에는 ngx.fetch 함수의 동작을 미세 조정하기 위한 새로운 지시문과 njs 버전을 16진수로 보고하는 새로운 객체가 포함됩니다. Prometheus-njs 모듈은 이제 추가 NGINX Plus 메트릭을 Prometheus와 호환되는 형식, 즉 업스트림 및 가상 서버의 개별 HTTP 상태 코드 수를 보고하는 codes 필드와 Limit Connections 및 Limit Requests 모듈에서 생성된 메트릭으로 변환할 수 있습니다.

이번 릴리스의 특징은 NGINX Plus API 에 대한 새로운 버전 번호(8)와 Linux 커널에서 EPOLLEXCLUSIVE 모드를 사용할 때 연결을 보다 균등하게 분산시킨다는 것입니다.

행동의 중요한 변화

메모: NGINX Plus R26 이외의 릴리스에서 업그레이드하는 경우 현재 릴리스와 이번 릴리스 사이의 모든 릴리스에 대한 발표 블로그에서 중요한 동작 변경 사항 섹션을 확인하세요.

지원되는 새로운 운영 체제:

• 알파인 리눅스 3.16
• RHEL 9.0+ (최초 릴리스 후 NGINX Plus R26 에 추가됨)
• Ubuntu 22.04 LTS(최초 릴리스 후 NGINX Plus R26 에 추가됨)

제거된 이전 운영 체제 및 아키텍처:

• 2022년 5월 1일 수명 종료(EOL)에 도달한 Alpine 3.12
• 2021년 12월 31일 에 EOL에 도달한 CentOS 8.1+(RHEL 8.1+는 EOL 날짜가 다르기 때문에 계속 지원됨)
• Power 8 아키텍처(ppc64le; CentOS 및 RHEL에 영향을 미침)

NGINX Plus R28에서 더 이상 지원되지 않고 제거될 예정인 이전 운영 체제 및 아키텍처:

• 2022년 8월에 EOL이 되는 Debian 10

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

건강 검진을 위한 Keepalive 연결

NGINX Plus와 업스트림 서버 간의 Keepalive 연결은 역방향 프록시 및 부하 분산 사용 사례의 성능을 크게 향상시킵니다. 특히 HTTPS를 통한 프록시의 경우, 새로운 연결마다 필요한 전체 TLS 핸드셰이크의 계산 비용이 컴퓨팅 리소스에 부담을 줄 수 있으며, 특히 업스트림 서버가 많은 프로덕션 환경에서는 더욱 그렇습니다.

이전 릴리스에서는 NGINX Plus는 상태 확인을 위해 keepalive 연결을 사용하지 않고, 대신 모든 상태 프로브에 대해 새로운 연결을 설정했습니다. NGINX Plus R27은 HTTP 상태 확인을 위한 keepalive 연결을 도입했습니다. health_check 지시문의 새로운 keepalive_time 매개변수는 각 keepalive 연결의 수명을 설정하며, 수명이 지나면 새 연결이 설정됩니다. 테스트 결과, HTTPS를 통한 프록시의 경우 NGINX Plus 서버에서 Keepalive 연결을 사용하면 상태 검사를 위한 CPU 사용량이 10~20배 감소하는 것으로 나타났습니다. 또한 업스트림 서버의 CPU 리소스도 절약됩니다.

다음 예제에서는 60초 동안 keepalive 연결을 활성화합니다. 간격 매개변수로 설정된 1초의 상태 검사 빈도를 고려할 때, NGINX Plus는 60회의 상태 검사마다 TLS 핸드셰이크와 연결 설정 비용을 한 번만 발생시킵니다.

커널 TLS 지원

TLS(전송 계층 보안)는 인터넷의 데이터 암호화를 위한 사실상 표준 프로토콜입니다. 불행히도 데이터를 보호하면 지연 시간도 늘어납니다. 커널에 TLS를 구현하면(kTLS) 사용자 공간과 커널 간의 복사 작업 필요성이 크게 줄어들어 정적 콘텐츠를 제공할 때 성능이 향상됩니다.

kTLS와 sendfile() 시스템 호출을 결합하면 TLS 라이브러리를 사용하여 암호화를 위해 사용자 공간에 복사한 다음 전송하기 전에 커널 공간으로 다시 복사하는 대신, 네트워크 스택으로 전달하기 전에 데이터가 커널 공간에서 직접 암호화됩니다. 또한 kTLS는 TLS 처리를 하드웨어로 오프로드하는 기능을 제공하며, 여기에는 TLS 대칭 암호화 처리를 네트워크 장치로 오프로드하는 기능도 포함됩니다.

kTLS를 지원하기 위한 세 가지 요구 사항이 있습니다.

1. 운영체제 커널이 이를 지원합니다
2. 운영 체제 배포판에는 kTLS 지원으로 컴파일된 OpenSSL 3.0+ 암호화 라이브러리가 포함되어 있습니다.
3. NGINX Plus(또는 NGINX 오픈 소스)는 OpenSSL 3.0+ 암호화 라이브러리로 구축되었습니다.

2021년 10월에 요구 사항 1과 2를 충족하는 플랫폼에서 NGINX 오픈 소스 1.21.4에 kTLS에 대한 지원을 추가했습니다. 이제 다음 플랫폼의 NGINX Plus에서 kTLS에 대한 지원을 추가하고 있습니다.

• FreeBSD 13( NGINX Plus R26 이상)
• RHEL 9.0 이상
• 우분투 22.04

업스트림 및 가상 서버에 대한 TLS 메트릭

NGINX Plus를 리버스 프록시 또는 부하 분산 장치로 배포하는 경우 NGINX Plus API는 각 업스트림 및 가상 서버의 트래픽, 응답 코드, 지연 시간에 대한 풍부한 측정 항목을 제공하므로 고객은 서버 성능과 가용성을 관찰하고 모니터링할 수 있습니다.

이전 릴리스에서는 NGINX Plus가 NGINX Plus와 업스트림 서버 간에 HTTPS 연결이 사용될 때 시스템 전체 수준에서 TLS 활동 및 오류에 대한 메트릭 을 생성했습니다(각각 지시어에서 proxy_pass https: //path-to-upstream 및 proxy_ssl 을 사용하여 설정됨). 통계에는 핸드셰이크, 실패, 세션 재사용 ( proxy_ssl_session_reuse 지시문으로 구성)이 포함됩니다.

NGINX Plus R27은 구성에 zone 지시어가 포함된 개별 업스트림 서버와 구성에 status_zone 지시어가 포함된 가상 서버에 대해 해당 TLS 메트릭을 생성합니다. TLS 핸드셰이크 문제를 해결할 때 클라이언트 측과 서버 측 모두의 메트릭을 갖는 것이 도움이 됩니다.

다음 예제에서는 업스트림 서버 upstream1 과 해당 서버로 트래픽을 프록시하는 가상 서버에서 통계 수집을 활성화합니다.

이 출력은 첫 번째 업스트림 서버가 4개의 TLS 핸드셰이크와 2개의 재사용 세션에 참여했음을 나타냅니다(간결성을 위해 첫 번째 서버에 대한 부분 출력을 표시하고 다른 업스트림 서버에 대한 출력은 생략합니다).

$ curl http://127.0.0.1:8000/api/8/http/upstreams/upstream1 | jq { "피어": [ { "ID": 0, "서버": "127.0.0.1:8081", "이름": "127.0.0.1:8081", "백업": 거짓, "가중치": 1, "상태": "업", "활성": 0, "ssl": { "악수": 4, "악수_실패": 0, "세션 재사용": 2 } , "요청": 4, "헤더_타임": 4, "응답 시간": 4, ... } ... ] }

이 출력은 NGINX Plus가 7개의 TLS 핸드셰이크에 참여했음을 나타냅니다.

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq { "처리 중": 0, "요청": 7, "응답": { "1xx": 0, "2xx": 7, "3xx": 0, "4xx": 0, "5xx": 0, "코드": { "200": 7 }, "총": 7 }, "폐기됨": 0, "수신됨": 546, "보냄": 1134, "ssl": { "악수": 7, "악수_실패": 0, "세션 재사용": 0 } ... }

NGINX Plus API는 여전히 이전 NGINX Plus 릴리스에서 사용 가능한 글로벌 TLS 메트릭을 수집합니다.

$ curl http://127.0.0.1:8000/api/8/ssl | jq { "악수": 21, "악수_실패": 0, "세션 재사용": 6 }

JWT 검증 실패에 대한 오류 코드 사용자 지정

NGINX Plus R25는 JWT 검증 프로세스 중에 사용자 정의 검사를 정의하기 위해 auth_jwt_require 지시어를 도입했습니다 . NGINX Plus R25 및 R26 에서는 유효성 검사 실패에 대해 반환되는 오류 코드는 항상 다음과 같습니다. 401(허가되지 않음) .

NGINX Plus R27은 auth_jwt_require 지시문에 오류 매개변수를 도입하여 코드를 설정하는 데 사용할 수 있습니다.401 또는403 (금지됨) 각 지침에 대해 독립적으로 적용됩니다. 사용자의 액세스 요청이 실패하면 코드 선택을 통해 인증 실패(JWT가 유효하지 않음)와 권한 부여 실패(필수 클레임이 누락됨)를 구별할 수 있습니다. 또한 오류 코드에 대한 사용자 정의 처리기를 생성할 수 있습니다. 예를 들어, error_page 지시문을 사용하여 오류를 설명하는 특수 페이지를 반환하거나 추가 처리를 위해 이름이 지정된 내부 위치로 요청을 리디렉션할 수 있습니다.

기본 상태 코드는 그대로 유지됩니다.401 다음 유형의 JWT 검사에 실패한 경우:

• 항상 수행되는 (비사용자 지정) 검사
• auth_jwt_require 로 구성되었지만 오류 매개변수는 없는 사용자 정의 검사

위치 블록에 auth_jwt_require 지시문이 여러 개 있는 경우, 표시된 순서대로 평가됩니다. 첫 번째 실패 시 처리가 중단되고 지정된 오류 코드가 반환됩니다.

이 예에서 auth_jwt_require 지시문은 다음을 반환합니다.403 $req1 또는 $req2가 빈 값으로 평가되는 경우 또는0 (영).

NGINX JavaScript 및 Prometheus-njs 모듈에 대한 향상

NGINX Plus R27 에는 다음 버전이 통합되어 있습니다.0.7.3 그리고0.7.4 NGINX JavaScript 모듈의 기능 향상 및 다음과 같은 향상된 기능이 포함되어 있습니다.

njs Fetch API에 대한 추가 지침

NGINX Plus R24 에 통합된 NGINX Javascript 0.5.3은 TCP/UDP 연결 컨텍스트 내에서 간단한 HTTP 클라이언트를 인스턴스화하기 위한 ngx.fetch 함수(Fetch API라고도 함)를 도입했습니다. (해당 함수의 사용 사례에 대한 논의는 블로그의 간단한 HTTP 클라이언트를 이용한 TCP.htmlUDP에 대한 HTTP 서비스 활용을 참조하세요.)

NGINX Plus R27은 Fetch API의 동작을 미세 조정하기 위한 다음 지침을 도입합니다.

• js_fetch_buffer_size [ HTTP ][ 스트림 ] – 읽기 및 쓰기에 사용되는 버퍼의 크기를 설정합니다.
• js_fetch_max_response_buffer_size [ HTTP ][ 스트림 ] – Fetch API로 수신된 응답의 최대 크기를 설정합니다.
• js_fetch_timeout [ HTTP ][ 스트림 ] – 두 개의 연속적인 읽기 또는 쓰기 작업 사이의 읽기 및 쓰기에 대한 시간 제한을 정의합니다(전체 응답에 대한 시간 제한이 아님). 제한 시간 내에 데이터가 전송되지 않으면 연결이 닫힙니다.
• js_fetch_verify [ HTTP ][ 스트림 ] – HTTPS 서버 인증서의 검증을 활성화하거나 비활성화합니다.

16진수로 보고된 버전 번호

새로운 njs.version_number 객체는 njs 모듈 버전을 16진수로 보고합니다. (기존 njs.version 객체는 버전을 문자열로 반환합니다.)

Prometheus-njs 모듈은 추가 메트릭을 변환합니다.

NGINX Plus 메트릭을 Prometheus 호환 형식으로 변환하는 Prometheus-njs 모듈은 이제 다음 추가 엔드포인트에서 노출된 메트릭을 변환할 수 있습니다.

• /http/제한_연결
• /http/제한_요구사항
• /http/server_zones 및 /http/upstreams 아래의 코드 필드( 개별 HTTP 상태 코드<.htmla>의 개수를 보고함)
• /스트림/제한_연결

NGINX Plus R27의 기타 개선 사항

NGINX Plus API 버전 변경

NGINX Plus API 의 버전 번호는 7에서 8로 업데이트되어 업스트림 및 가상 서버에 대해 보고되는 메트릭에 ssl 필드가 추가되었음을 반영합니다. 이에 대한 내용은 업스트림 및 가상 서버에 대한 TLS 메트릭 에서 설명합니다. 이전 버전 번호는 계속 작동하지만 이후 API 버전에서 추가된 메트릭은 출력에 포함되지 않습니다.

Linux EPOLLEXCLUSIVE 모드에서 연결의 더 나은 분배

Linux 커널에서 EPOLLEXCLUSIVE 모드를 사용하면 NGINX Plus R27은 NGINX 작업자 프로세스 간에 연결을 더 균등하게 분산합니다. 일반적으로 이 모드에서는 커널은 EPOLL 인스턴스에 수신 소켓을 가장 먼저 추가한 프로세스에만 알립니다. 결과적으로 대부분의 연결은 첫 번째 작업자 프로세스에 의해 처리됩니다. 이제 NGINX는 다른 작업자 프로세스가 연결을 수락할 수 있는 기회를 제공하기 위해 주기적으로 소켓을 다시 추가합니다.

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

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

NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 체험판을 통해 시작해 보세요.