NGINX Plus R27 발표

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

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

• Health Check를 위한 Keepalive 연결  – 이전 릴리스에서 NGINX Plus는 각 건강 검진에 대해 새 연결을 설정했습니다. keepalive_timeHTTP health_check지시문에 대한 새 매개변수는 건강 검진을 위한 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 (Unauthorized). NGINX Plus R27은error 지시문 에 매개변수를 도입하여 각 검사에 대해 auth_jwt_require코드를  401또는 로 설정하여 403 (Forbidden)인증 및 권한 부여 오류를 더 잘 구분할 수 있습니다.
• NGINX JavaScript 및 Prometheus-njs 모듈 의 향상  - NGINX JavaScript 모듈의 향상에는 함수의 동작을 미세 조정하기 위한 새로운 지시문 ngx.fetch과 njs 버전을 16진수로 보고하는 새로운 객체가 포함됩니다. Prometheus-njs 모듈은 이제 추가 NGINX Plus 메트릭을 Prometheus 호환 형식으로 변환할 수 있습니다. codes필드(업스트림 및 가상 서버의 개별 HTTP 상태 코드 수를 보고함) 및 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

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

Health Check를 위한 Keepalive 연결

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

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

다음 예에서는 60초의 수명으로 keepalive 연결을 활성화합니다. interval매개변수로 설정된 1초의 상태 점검 빈도를 감안하면 NGINX Plus는 60회의 상태 점검마다 TLS 핸드셰이크와 연결 설정 비용을 한 번만 부담합니다.

커널 TLS 지원

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

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

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

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

2021년 10월에 요구 사항 1과 2를 충족하는 플랫폼에서 NGINX Open Source 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 연결이 사용되었을 때 http및 stream컨텍스트( 각각 및 지시어로 설정됨)에서 시스템 전체 수준에서 TLS 활동 및 오류에 대한 메트릭을 생성했습니다. 통계는 핸드셰이크, 실패 및 세션 재사용 (지시어로 구성됨 )을 포함합니다.proxy_pass https://path-to-upstreamproxy_ssl onproxy_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{
  "peers": [
    {
      "id": 0,
      "server": "127.0.0.1:8081",
      "name": "127.0.0.1:8081",
      "backup": false,
      "weight": 1,
      "state": "up",
      "active": 0,
      "ssl": {
        "handshakes": 4,
        "handshakes_failed": 0,
        "session_reuses": 2
      },
      "requests": 4,
      "header_time": 4,
      "response_time": 4,
      ...
    }
    ...
  ]
}

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

$ curl http://127.0.0.1:8000/api/8/http/server_zones/srv | jq{
  "processing": 0,
  "requests": 7,
  "responses": {
    "1xx": 0,
    "2xx": 7,
    "3xx": 0,
    "4xx": 0,
    "5xx": 0,
    "codes": {
      "200": 7
    },
    "total": 7
  },
  "discarded": 0,
  "received": 546,
  "sent": 1134,
  "ssl": {
    "handshakes": 7,
    "handshakes_failed": 0,
    "session_reuses": 0
  }
  ...
}

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

$ curl http://127.0.0.1:8000/api/8/ssl | jq{
  "handshakes": 21,
  "handshakes_failed": 0,
  "session_reuses": 6
}

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

NGINX Plus R25는 JWT 검증 프로세스 중에 사용자 정의 검사를 정의하기 위한 지시어를 도입했습니다 . NGINX Plus R25 및 R26 에서 검증 실패에 대해 반환되는 오류 코드는 항상  .auth_jwt_require401 (Unauthorized)

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

401다음 유형의 JWT 검사가 실패하면 기본 상태 코드가 유지됩니다  .

• 항상 수행되는 (비사용자 지정) 검사
• 매개변수가 auth_jwt_require아닌 사용자 정의 검사가 구성됨error

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

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

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

NGINX Plus R27은 NGINX JavaScript 모듈의 0.7.3 및  0.7.4 버전을 통합하며  다음과 같은 향상된 기능을 포함합니다.

njs Fetch API에 대한 추가 지침

NGINX Plus R24 에 통합된 NGINX Javascript 0.5.3은 ngx.fetchTCP/UDP 연결의 컨텍스트 내에서 간단한 HTTP 클라이언트를 인스턴스화하기 위한 함수(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/limit_conns
• /http/limit_reqs
• ( 개별 HTTP 상태 코드<.htmla>codes 의 개수를 보고하는) 필드는 다음 과 같습니다./http/server_zones/http/upstreams
• /stream/limit_conns

NGINX Plus R27의 기타 개선 사항

NGINX Plus API 버전 변경

NGINX Plus API 의 버전 번호는 TLS Metrics for Upstream and Virtual Serversssl 에서 설명한 대로 업스트림 및 가상 서버에 대해 보고된 메트릭에 필드 가 추가되었음을 반영하기 위해 7에서 8로 업데이트되었습니다 . 이전 버전 번호는 여전히 작동하지만 출력에는 이후 API 버전에서 추가된 메트릭이 포함되지 않습니다.

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

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

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

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R27 로 업그레이드하는 것을 강력히 권장합니다 . 또한 여러 가지 추가 수정 사항과 개선 사항을 얻을 수 있으며, 지원 티켓을 제기해야 할 때 NGINX가 도움을 줄 수 있습니다.