NGINX Plus R27 출시 발표

Prabhat Dixit

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

NGINX Plus R27의 새로운 기능과 향상된 기능은 다음과 같습니다:

• 상태 확인을 위한 Keepalive 연결 – 이전 릴리스에서는 NGINX Plus가 상태를 확인할 때마다 새 연결을 설정했습니다. HTTP keepalive_time 지시문의 새로운 health_check 매개변수를 사용하면 상태 확인에 Keepalive 연결을 사용하고 연결 유지 시간을 설정할 수 있습니다. 새 연결을 설정하려면 많은 컴퓨팅 리소스가 필요하므로 업스트림 서버가 많을 때 연결을 재사용하면 CPU 사용량을 크게 줄일 수 있습니다.
• 커널 TLS 지원 – 이제 NGINX Plus는 커널 TLS(kTLS) 지원 요건을 충족하는 세 가지 운영 체제인 FreeBSD 13, RHEL 9.0 이상, Ubuntu 22.04 LTS에서 커널 TLS(kTLS)를 지원합니다.
• 업스트림 및 가상 서버의 TLS 메트릭 – 이제 NGINX Plus는 이전 릴리스에서 제공하던 전역 통계뿐만 아니라, HTTPS를 통한 프록시가 활성화된 경우 개별 업스트림 및 가상 서버에 대한 TLS 통계도 생성합니다. 클라이언트 측과 서버 측 모두의 메트릭을 확보하면 TLS 핸드셰이크 문제를 해결할 때 유용합니다.
• JWT 검증 실패 시 오류 코드 사용자 지정 – NGINX Plus R25 및 R26에서는 사용자 지정 JWT 검증 검사를 정의할 수 있지만, 검증 실패 시 반환되는 오류 코드는 항상 401 (인증되지 않음)입니다. NGINX Plus R27에서는 error 매개변수가 auth_jwt_require 지시문에 도입되어, 인증 오류와 권한 부여 오류를 더 명확하게 구분할 수 있도록 각 검사에 대해 코드를 401 또는 403 (금지됨)으로 설정할 수 있습니다.
• 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 이외의 릴리스에서 업그레이드하는 경우, 현재 사용 중인 릴리스부터 이 릴리스까지의 모든 릴리스에 대한 발표 블로그에서 중요한 동작 변경 사항 섹션을 반드시 확인하세요.

새롭게 지원되는 운영 체제:

• Alpine Linux 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와 업스트림 서버 간에 사용하면 리버스 프록시 및 부하 분산 사용 사례의 성능이 크게 향상됩니다. 특히 HTTPS를 통한 프록시의 경우, 새 연결마다 필요한 전체 TLS 핸드셰이크의 연산 비용으로 인해 컴퓨팅 리소스에 부담이 가중될 수 있으며, 업스트림 서버가 많은 프로덕션 환경에서는 특히 그렇습니다.

이전 릴리스에서는 NGINX Plus가 상태 확인에 연결 유지를 사용하지 않고 상태 프로브마다 새 연결을 설정했습니다. NGINX Plus R27에서는 HTTP 상태 확인에 연결 유지 기능이 도입되었습니다. 새로운 keepalive_time 매개변수는 health_check 지시문에서 각 연결 유지 연결의 수명을 설정하며, 이 시간이 지나면 새 연결이 설정됩니다. 테스트 결과, HTTPS를 통한 프록시의 경우 연결 유지를 사용하면 NGINX Plus 서버에서 상태 확인에 필요한 CPU 사용량이 10~20분의 1로 감소하는 것으로 나타났습니다. 또한 업스트림 서버의 CPU 리소스도 절약됩니다.

다음 예에서는 수명이 60초인 keepalive 연결을 활성화합니다. interval 매개변수로 설정된 상태 확인 주기가 1초이므로 NGINX Plus는 상태 확인 60회마다 한 번만 TLS 핸드셰이크 및 연결 설정에 따른 비용을 부담합니다.

코드 예제를 로드하는 중…

커널 TLS 지원

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

kTLS와 sendfile() 시스템 호출을 함께 사용하면, TLS 라이브러리를 사용해 암호화하기 위해 데이터를 사용자 공간으로 복사한 다음 전송 전에 다시 커널 공간으로 복사하는 대신, 네트워크 스택으로 전달되어 전송되기 전에 커널 공간에서 직접 암호화됩니다. 또한 kTLS를 사용하면 TLS 대칭 암호화 처리를 네트워크 장치로 오프로드하는 것을 비롯해 TLS 처리를 하드웨어로 오프로드할 수 있습니다.

kTLS를 지원하려면 다음 세 가지 요구 사항을 충족해야 합니다:

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

2021년 10월, NGINX Open Source 1.21.4에 대한 kTLS 지원을 추가했습니다. 이는 요구 사항 1과 2를 충족하는 플랫폼에서 제공됩니다. 이제 다음 플랫폼의 NGINX Plus에도 kTLS 지원을 추가합니다:

• FreeBSD 13(NGINX Plus R26 이상)
• RHEL 9.0+
• Ubuntu 22.04 LTS

업스트림 및 가상 서버의 TLS 메트릭

NGINX Plus를 리버스 프록시 또는 로드 밸런서로 배포하면 NGINX Plus API가 각 업스트림 서버와 가상 서버의 트래픽, 응답 코드 및 지연 시간에 관한 다양한 메트릭을 제공하므로 고객은 서버의 성능과 가용성을 관찰하고 모니터링할 수 있습니다.

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

NGINX Plus R27은 구성에 zone 지시문이 포함된 개별 업스트림 서버와 구성에 status_zone 지시문이 포함된 가상 서버에 대해 이러한 TLS 메트릭을 생성합니다. 클라이언트 측과 서버 측 모두의 메트릭을 확보하면 TLS 핸드셰이크 문제를 해결할 때 유용합니다.

다음 예에서는 업스트림 서버 upstream1 및 이 서버로 트래픽을 프록시하는 가상 서버에서 통계 수집을 사용하도록 설정합니다.

코드 예제를 로드하는 중…

이 출력은 첫 번째 업스트림 서버에서 TLS 핸드셰이크가 4회 수행되었고 세션이 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 검증 프로세스 중 사용자 지정 검사를 정의하기 위한 auth_jwt_require 지시문이 도입되었습니다. NGINX Plus R25 및 R26에서는 검증 실패 시 반환되는 오류 코드가 항상 401 (인증되지 않음)입니다.

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

다음 유형의 JWT 검사에 실패할 경우 기본 상태 코드는 계속 401입니다:

• 항상 수행되는 검사(사용자 지정 검사가 아닌 검사)
• Custom checks configured with auth_jwt_require로 구성되었지만 error 매개변수는 지정되지 않은 사용자 지정 검사

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

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

코드 예제를 로드하는 중…

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에서는 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][Stream] – Fetch API로 수신하는 응답의 최대 크기를 설정합니다.
• js_fetch_timeout[HTTP][Stream] – 연속된 두 읽기 또는 쓰기 작업 사이의 읽기 및 쓰기 제한 시간을 정의합니다(전체 응답에 대한 제한 시간이 아님). 제한 시간 내에 데이터가 전송되지 않으면 연결이 종료됩니다.
• js_fetch_verify[HTTP][Stream] – HTTPS 서버 인증서 확인을 활성화하거나 비활성화합니다.

16진수로 보고되는 버전 번호

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

Prometheus-njs 모듈에서 추가 메트릭 변환

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

• /http/limit_conns
• /http/limit_reqs
• The codes 필드(개별 HTTP 상태 코드<.htmla>의 수를 보고)는 /http/server_zones 및 /http/upstreams 아래에 있습니다
• /stream/limit_conns

NGINX Plus R27의 기타 개선 사항

NGINX Plus API 버전 변경

업스트림 및 가상 서버에 대해 보고되는 메트릭에 ssl 필드가 추가된 것을 반영하기 위해 NGINX Plus API 버전 번호가 7에서 8로 업데이트되었습니다. 자세한 내용은 업스트림 및 가상 서버의 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일 무료 평가판으로 시작할 수 있습니다.

작성자 소개

Prabhat Dixit

Prabhat Dixit의 다른 블로그 게시물