NGINX Plus R20 발표

NGINX Plus R20은 R19에서 속도 제한 및 키-값 저장소에 적용한 개선 사항을 기반으로 구축되었습니다. 새로운 기능은 다음과 같습니다.

• 속도 제한 트래픽의 실시간 모니터링 및 로깅  - 속도 제한이 구성된 경우 NGINX Plus API 는 이제 얼마나 많은 요청이 즉시 전달되고, 지연되거나 거부되는지 보고합니다. 또한 개별 요청의 속도 제한 상태에 대한 정보를 포함하도록 액세스 로그를 구성할 수도 있습니다.
• 연결 제한 향상  – 속도 제한 향상은 R19에 도입되었으며 이 릴리스에서는 연결 제한까지 확장되었습니다.
• 키-값 저장소의 접두사 매칭  - 키-값 저장소의 키는 지정된 접두사(문자열의 시작 부분에 있는 문자)와 매칭될 수 있습니다. 중요한 사용 사례 중 하나는 동적 요청 라우팅입니다.
• 업스트림 그룹별 DNS 확인  – 이제 그룹의 백엔드 서버를 나타내기 위해 확인 가능한 호스트 이름을 사용하는 각 업스트림 그룹에 대해 다른 DNS 서버 세트를 지정할 수 있습니다.
• 추가 PROXY 프로토콜 변수  – 새로운 변수는 클라이언트가 원래 연결했던 프록시 서버의 IP 주소와 포트를 캡처합니다.
• HTTP/2 보안 개선  – 잘못된 클라이언트 동작이나 유효하지 않은 클라이언트 동작을 더 잘 감지하고 특정 지침을 보다 강력하게 구현하는 등 여러 가지 변경 사항을 통해 HTTP/2 트래픽의 전반적인 보안이 개선되었습니다.

행동의 중요한 변화

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

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

• 지원되는 새로운 운영 체제  –

  • 센트OS 8.0 이상
  • 프리BSD 12.1
  • 레드햇 엔터프라이즈 리눅스 8.1
  • 우분투 19.10 (“Eoan Ermine”)

지원되는 플랫폼에 대한 자세한 내용은 NGINX Plus 및 동적 모듈 에 대한 기술 사양을 참조하세요 .

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

속도 제한 트래픽의 실시간 모니터링 및 로깅

NGINX Plus R20은 운영 및 DevOps 팀이 실시간으로 속도 제한 활동을 모니터링하고 정확히 어떤 클라이언트가 속도 제한을 초과했는지 확인할 수 있는 기능을 도입합니다.
NGINX Plus는 항상 속도 제한할 클라이언트 요청 유형을 정의하는 방법과 과도한 요청을 처리하는 방법에 있어 많은 유연성을 제공했습니다. 각 요청은 다음 방법 중 하나로 처리됩니다.

• 지연 없이 통과됨 (요청 속도가 제한 미만이거나 구성된 버스트 크기 내에 있기 때문)
• 지연되어 통과할 때까지 속도 제한을 초과하지 않습니다( 제한 이라고도 함 )
• HTTP 오류 응답 코드로 거부됨

이전 릴리스에서는 오류 로그가 NGINX Plus가 요청이 지연되거나 거부되었다는 사실을 다음과 같은 표준화된 항목으로 기록한 유일한 곳이었습니다.

2019/12/02 11:42:12 [error] 57#57: *339 limiting requests, excess: 0.600 by zone "my_limit", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.0", host: "www.example.com:80"

오류 로그에서 유용한 정보를 추출하는 것은 어려울 수 있습니다. 메시지 형식이 구조화되지 않았고 구성할 수 없기 때문입니다. 또한 속도 제한이 오류 로그 항목에 기록된 것 외의 메시지 특성(예: HTTP 헤더 또는 ID 정보)에 따라 결정된 경우 액세스 로그에서 해당 항목을 찾아 속도 제한을 초과한 클라이언트를 정확히 파악해야 합니다. 새로운 기능은 이러한 문제를 해결합니다.

NGINX Plus API 의 속도 제한 메트릭

NGINX Plus API 의 새로운 엔드포인트인 는 지시문에 의해 정의된 각 영역에 대해 이루어진 속도 제한 결정에 대한 모든 결과에 대한 카운터를 유지합니다 . 이러한 카운터는 실시간으로 속도 제한 결정을 모니터링하는 데 사용할 수 있으며 APM 솔루션과 통합하여 속도 제한 활동에 대한 대시보드와 알림을 제공할 수 있습니다./api/version/http/limit_reqslimit_req_zone

다음 예에서는 my_limit 라는 하나의 정의된 영역이 있습니다 .

$ curl http://localhost/api/6/http/limit_reqs
{
 "my_limit": {
   "delayed": 540,
   "delayed_dry_run": 12162,
   "passed": 804541,
   "rejected": 63,
   "rejected_dry_run": 1209
 }
}

이러한 카운터에는 NGINX Plus R19 에서 도입된 드라이런 모드 에서 처리된 과도한 요청에 대한 항목도 포함되어 있습니다 .

액세스 로그에서 속도 제한 활동 로깅

실시간 메트릭은 NGINX Plus가 과도한 요청을 처리하는 시점을 이해하는 데 매우 유용하지만 누가 요청을 생성하는지 알려주지는 않습니다 . 이 과제를 해결하기 위해 NGINX Plus R20은 새로운 $limit_req_status변수를 제공합니다. 요청의 속도 제한 상태를 기록합니다: DELAYED, DELAYED_DRY_RUN, PASSED, REJECTED, 또는 REJECTED_DRY_RUN.

그런 다음 클라이언트, URI 및 기타 관련 정보를 고유하게 식별하는 로그 형식에 다른 변수를 포함할 수 있습니다. 다음 구성에서는 JSON 웹 토큰(JWT) 검증(줄 1)을 기반으로 각 클라이언트에 대해 초당 10개 요청의 엄격한 속도 제한이 적용됩니다. 과도한 요청은 거부(줄 16)되고 별도의 로그 파일에 기록되며(줄 21) 여기에는  클레임을$jwt_claim_sub 캡처하는 변수 (줄 4)도 포함됩니다.sub

reject.log 파일 의 샘플 항목 :

time=1575289305.350 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTEDtime=1575289305.395 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED
time=1575289305.402 client=10.0.0.1 sub=adam uri=/ status=429 limit_req=REJECTED

연결 제한 기능 향상

요청에 대한 속도 제한 외에도 NGINX Plus는 Limit Connections 모듈을 사용하여 클라이언트 연결에 대한 제한을 지원합니다 . 클라이언트가 NGINX Plus에 열 수 있는 개별 연결 수(또는 HTTP/2를 사용할 때 동시 요청 수)를 정의할 수 있습니다. 클라이언트는 일반적으로 원격 IP 주소(또는 $remote_addr변수 $binary_remote_addr)로 식별되지만 원격 IP 주소가 모호하거나 여러 클라이언트가 공유할 수 있는 경우 다른 변수(예: $jwt_claim_subJWT의 사용자 이름)를 사용할 수 있습니다.

NGINX Plus R20은 NGINX Plus R19 및 이번 릴리스 에서 도입된 속도 제한과 동일한 향상 기능으로 연결 제한을 확장합니다 .

• limit_conn_dry_run지시어 를 사용한 드라이런 모드
• NGINX Plus API 엔드포인트 에서 실시간 모니터링/api/version/http/limit_conns
• 각 요청( , , 또는 ) $limit_conn_status에 대한 연결 제한 결정을 캡처하는 새 변수는 액세스 로그에서 변수 에 대한 속도 제한 활동 로깅 에 설명된 대로 사용할 수 있습니다 .PASSEDREJECTEDREJECTED_DRY_RUN$limit_req_status

다음 구성은 10개가 넘는 동시 연결을 여는 클라이언트에 낮은 대역폭을 적용합니다.

키-값 저장소의 접두사 일치

NGINX Plus의 메모리 내 키 값 저장소를 사용하면 NGINX Plus API를 사용하여 요청의 속성에 따라 트래픽 관리를 동적으로 구성할 수 있습니다. 샘플 사용 사례로는 IP 주소의 동적 거부 목록 , 동적 대역폭 제한 및 인증 토큰 캐싱이 있습니다 .

NGINX Plus R20은 지정된 접두사(문자열의 시작 부분에 있는 문자)에 대한 키 일치를 지원하여 키-값 저장소에 대한 새로운 사용 사례 세트를 활성화합니다. 예를 들어 정확한 URI가 아닌 URI 접두사(기본 경로)에 대한 키 일치가 가능하므로 각 기본 경로를 업스트림 그룹에 매핑하는 동적 라우팅 테이블을 만들어 location지시문에서 정의한 정적 매핑을 대체하거나 보강할 수 있습니다.

type=prefix접두사 매칭을 활성화하려면 지시문 에 새 매개변수를 포함합니다 keyval_zone. 다음 구성에서 keyval지시문은 각 URI 접두사와 Cache-Control지시문(예: max-age또는 )을 연관시키고 지시문은 NGINX Plus가 요청을 업스트림 서버로 전달함에 따라 응답 헤더를 해당 값으로 설정합니다 .no-cacheadd_headerCache-Control

NGINX Plus API를 사용하여 키-값 저장소의 Cache-Control각 기본 경로(이 경우 /images/ 또는 /reports/ 로 시작하는 경로)에 대한 응답 헤더 값을 정의합니다 .

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/pathsHTTP/1.1 201 Created
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:36:31 GMT
Content-Length: 0
Location: http://localhost:8080/api/6/http/keyvals/paths/
Connection: keep-alive

키-값 저장소에 있는 기본 경로로 요청을 하면 응답에는 Cache-Control우리가 설정한 헤더가 포함됩니다.

$ curl -I http://localhost/images/sample.jpgHTTP/1.1 200 OK
Server: nginx/1.17.6
Date: Mon, 2 Dec 2019 12:27:39 GMT
Content-Type: image/jpeg
Content-Length: 120847
Connection: keep-alive
Cache-Control: max-age=3600

키-값 저장소는 NGINX Plus 인스턴스 클러스터에서 동기화 될 수 있으므로 각 API 호출을 하나의 인스턴스로만 해야 합니다. 이렇게 하면 클러스터 구성에 대한 변경을 자동화하는 프로세스가 구성 파일에 대한 변경을 조정하는 것 보다 훨씬 간단해집니다 .

업스트림 그룹당 DNS 확인

NGINX Plus를 사용하여 여러 업스트림 서버에서 로드 밸런싱을 수행하는 경우 여러 IP 주소로 확인되는 호스트 이름을 지정 하여 업스트림 그룹의 멤버를 정의할 수 있습니다 . 이는 업스트림 그룹의 멤버가 자주 변경될 수 있는 동적 또는 자동 확장 환경에서 특히 유용합니다.

이러한 동적 업스트림 그룹의 구성을 완료하려면 resolverNGINX Plus가 호스트 이름과 연관된 IP 주소를 쿼리하는 DNS 서버 또는 서버를 지정하는 지시어도 포함합니다. 이전 릴리스에서는 지시어가 지시어를 포함하는 컨텍스트( , , 또는 )에서 지시어가 resolver참조하는 모든 업스트림 그룹에 적용되었습니다 . NGINX Plus R20 에서는 이제 각 업스트림 그룹에 대해 다른 DNS 리졸버를 지정할 수 있습니다.proxy_passhttpserverlocation

새로운 유연성은 특히 DevOps 환경에서 유용합니다. 이를 통해 애플리케이션 팀은 중앙 집중식 공유 서비스에 의존하는 대신 DNS 서버 및 서비스 레지스트리를 포함하여 애플리케이션 제공 인프라를 더 많이 소유할 수 있습니다.

최상위 http컨텍스트와 server블록 에서 글로벌 리졸버를 정의할 수 있습니다 location. upstream블록에 지시문이 포함되지 않은 경우 이전 릴리스와 마찬가지로 업스트림 그룹을 참조하는 지시문이 포함된 컨텍스트 또는 블록의 설정을 resolver상속합니다 .resolverproxy_pass

다음 예에서 웹사이트 업스트림 그룹은 글로벌 리졸버를 사용하는 반면, mobile_app은 자체 리졸버를 사용합니다.

Resolver 활동에 대한 오류 및 기타 측정 항목을 수집하기 위해 두 지시어 모두에 status_zone매개변수( NGINX Plus R19 에서 도입 ) 를 포함하고 있다는 점에 유의하세요.

PROXY 프로토콜 서버 메타데이터에 대한 변수

PROXY 프로토콜은 레이어 4 프록시가 클라이언트 요청을 처리하는 다음 프록시 또는 로드 밸런서에 원래 클라이언트 연결에 대한 정보를 전달할 수 있는 메커니즘입니다. 이는 클라이언트의 IP 주소를 알아야 하는 사용 사례에 특히 중요합니다. 예를 들어, 각 클라이언트가 만든 연결 수를 제한하거나(지시문 사용 least_conn) 단순히 실제 클라이언트의 IP 주소를 기록하는 경우입니다. 이전 릴리스와 마찬가지로 변수 $proxy_protocol_addr는 이 정보를 캡처합니다.

애플리케이션 환경에 여러 레이어 4 프록시가 배포된 경우 NGINX Plus가 클라이언트가 원래 연결한 프록시 서버의 IP 주소와 포트를 아는 것도 중요합니다. PROXY Protocol 메타데이터에는 이 정보가 포함되어 있으며 NGINX Plus R20은 이를 캡처하기 위해 변수를 추가합니다.

• $proxy_protocol_server_addr
• $proxy_protocol_server_port

변수는 HTTP와 Stream(TCP/UDP) 모듈 모두에서 사용할 수 있으며, PROXY 프로토콜의 버전 1과 2를 모두 지원합니다. 변수를 사용하기 전에 proxy_protocol매개변수를 지시문에 추가하여 NGINX Plus가 PROXY 프로토콜을 처리하도록 명시적으로 활성화해야 합니다 listen.

HTTP/2의 보안 개선

NGINX Plus R18 P1은 8월에 발표된 HTTP/2의 세 가지 보안 취약점을 해결했습니다. NGINX Plus R20 에는 HTTP/2 구현의 전반적인 보안을 개선하는 추가 변경 사항이 포함되어 있습니다.

• 잘못된 클라이언트 동작이나 유효하지 않은 클라이언트 동작 감지 기능 향상
• 클라이언트 요청 본문이 읽히기 전에 HTTP/2 오류 응답을 보내는 기능이 향상되었습니다.
• worker_shutdown_timeout장기 HTTP/2 연결에 대한 지침 의 견고성 향상
• proxy_request_bufferingHTTP/2 클라이언트에 대한 지침 의 견고성 향상

NGINX Plus R18 (패치되지 않음) 또는 이전 버전을 사용하여 프로덕션에서 HTTP/2를 사용하는 경우 , 최대한 빨리 NGINX Plus R20 으로 업그레이드하는 것이 좋습니다.

NGINX Plus 에코시스템 업데이트

NGINX 자바스크립트 모듈

NGINX JavaScript 모듈(njs)이 0.3.7 버전으로 업데이트되어  더 많은 JavaScript 객체에 대한 지원이 추가되었습니다.

• Function()건설자
• Object.assign()방법
• Number방법: toFixed(), toPrecision(), 및toExponential()
• Array.prototype.copyWithin()방법
• console.time()메서드 에 대한 라벨 매개변수

njs에 대해 자세히 알아보려면 프로젝트 홈페이지 와 블로그<.htmla>를 확인하세요.

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

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