NGINX Plus R20 발표

NGINX Plus 릴리스 20(R20)이 출시되어 기쁩니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 모두 갖춘 유일한 제품입니다. NGINX 오픈 소스를 기반으로 하는 NGINX Plus에는 독점적인 향상된 기능과 수상 경력에 빛나는 지원이 포함되어 있습니다.

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 또는 upstream_conf 지시문이 포함되어 있는 경우 R20으로 업그레이드하는 과정에서 이를 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 [오류] 57#57: *339 요청 제한, 초과: 0.600 by zone "my_limit", 클라이언트: 172.17.0.1, 서버: www.example.com, 요청: "GET / HTTP/1.0", 호스트: "www.example.com:80"

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

NGINX Plus API 의 속도 제한 메트릭

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

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

$ curl http://localhost/api/6/http/limit_reqs { "내_제한": { "지연됨": 540, "지연된 건조 실행": 12162, "통과": 804541, "거부됨": 63, "거부된 드라이 런": 1209 } }

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

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

실시간 메트릭은 NGINX Plus가 과도한 요청을 처리하는 경우 를 파악하는 데 매우 유용하지만, 그러한 요청을 생성하는 사람이 누구인지는 알려주지 않습니다. 이러한 과제를 해결하기 위해 NGINX Plus R20은 새로운 $limit_req_status 변수를 제공합니다. 요청의 속도 제한 상태를 기록합니다. 지연됨 , 지연_건조_실행 , 통과 , 거부됨 또는 거부_건조_실행 .

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

reject.log 파일의 샘플 항목:

time=1575289305.350 클라이언트=10.0.0.1 하위=adam uri=/ 상태=429 limit_req=거부됨time=1575289305.395 클라이언트=10.0.0.1 하위=adam uri=/ 상태=429 limit_req=거부됨
time=1575289305.402 클라이언트=10.0.0.1 하위=adam uri=/ 상태=429 limit_req=거부됨

연결 제한 기능 향상

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

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

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

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

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

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

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

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

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

$ curl -i -X POST --data '{"/images/":"max-age=3600", "/reports/":"no-cache"}' http://localhost:8080/api/6/http/keyvals/paths HTTP/1.1 201 생성 서버: nginx/1.17.6 날짜: 월, 2 Dec 2019 12:36:31 GMT 콘텐츠 길이: 0 위치: http://localhost:8080/api/6/http/keyvals/paths/ 연결: keep-alive

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

$ curl -I http://localhost/images/sample.jpg HTTP/1.1 200 OK 서버: nginx/1.17.6 날짜: 월, 2 Dec 2019 12:27:39 GMT 콘텐츠 유형: image/jpeg 콘텐츠 길이: 120847 연결: keep-alive 캐시 제어: max-age=3600

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

업스트림 그룹당 DNS 확인

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

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

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

최상위 http 컨텍스트와 server 및 location 블록에서 글로벌 리졸버를 정의할 수 있습니다. 업스트림 블록에 리졸버 지시어가 포함되어 있지 않으면 이전 릴리스와 마찬가지로 업스트림 그룹을 참조하는 proxy_pass 지시어가 포함된 컨텍스트나 블록의 리졸버 설정을 상속받습니다.

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

리졸버 활동에 대한 오류 및 기타 메트릭을 수집하기 위해 두 개의 리졸버 지시문에 status_zone 매개변수( NGINX Plus R19 에서 도입 )를 포함하고 있다는 점에 유의하세요.

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

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

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

• $프록시_프로토콜_서버_주소
• $프록시_프로토콜_서버_포트

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

HTTP/2의 보안 개선

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

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

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

NGINX Plus 에코시스템 업데이트

NGINX 자바스크립트 모듈

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

• Function() 생성자
• Object.assign() 메서드
• 숫자 메서드: toFixed() , toPrecision() 및 toExponential()
• Array.prototype.copyWithin() 메서드
• console.time() 메서드에 대한 레이블 매개변수

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

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

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

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

NGINX Plus를 사용해보지 않으셨다면 보안, 부하 분산, API 게이트웨이로 사용하거나 향상된 모니터링 및 관리 API를 갖춘 완벽히 지원되는 웹 서버로 사용해보시기 바랍니다. 오늘 무료 30일 체험판을 통해 시작해 보세요. NGINX Plus가 어떻게 귀하의 애플리케이션을 제공하고 확장하는 데 도움이 될 수 있는지 직접 확인해 보세요.