NGINX Plus R20 출시 발표

Liam Crilly제품 관리 부문 수석 이사

NGINX Plus 릴리스 20(R20)이 출시되었음을 기쁘게 알려드립니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 하나로 통합한 유일한 솔루션입니다. NGINX Open Source를 기반으로 하는 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로 마이그레이션하는 방법에 대한 안내와 도움이 필요하면 블로그의 전환 가이드를 참조하거나 지원팀에 문의하세요.
• 새롭게 지원되는 운영 체제 –
  • CentOS 8.0+
  • FreeBSD 12.1
  • Red Hat Enterprise Linux 8.1
  • Ubuntu 19.10(“Eoan Ermine”)

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

새로운 기능 상세 정보

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

NGINX Plus R20에는 운영 및 DevOps 팀이 속도 제한 활동을 실시간으로 모니터링하고 어떤 클라이언트가 속도 제한을 초과했는지 정확히 파악하기 쉽게 해주는 기능이 도입되었습니다.
NGINX Plus는 속도를 제한할 클라이언트 요청 유형을 정의하고 초과 요청을 처리하는 방식에서 항상 뛰어난 유연성을 제공해 왔습니다. 각 요청은 다음 방법 중 하나로 처리됩니다:

• 통과 지연 없이 처리됨(요청 속도가 제한 미만이거나 구성된 버스트 크기 이내이기 때문)
• 지연됨 — 요청을 통과시켜도 속도 제한을 초과하지 않을 때까지 지연됩니다(이를 스로틀링이라고도 함)
• 거부됨(HTTP 오류 응답 코드 반환)

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

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의 새로운 엔드포인트인 /api/version/http/limit_reqs는 limit_req_zone 지시문으로 정의된 각 영역에서 내려진 요청 속도 제한 결정의 모든 결과에 대한 카운터를 유지합니다. 이러한 카운터는 요청 속도 제한 결정을 실시간으로 모니터링하는 데 사용할 수 있으며, APM 솔루션과 통합하여 요청 속도 제한 활동에 대한 대시보드와 알림을 제공할 수도 있습니다.

다음 예시에는 정의된 영역이 하나 있습니다. 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) 검증을 기반으로 각 클라이언트에 초당 10개의 엄격한 요청 속도 제한을 적용합니다(1행). 한도를 초과한 요청은 거부되고(16행) 별도의 로그 파일에 기록되며(21행), 이 로그에는 $jwt_claim_sub 변수도 포함되어 sub 클레임을 캡처합니다(4행).

코드 예제를 로드하는 중…

Sample entries in the 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의 사용자 이름을 나타내는 $jwt_claim_sub)를 사용할 수 있습니다.

NGINX Plus R20에서는 연결 제한 기능이 확장되어, NGINX Plus R19 및 이번 릴리스에서 속도 제한에 도입된 것과 동일한 개선 사항이 적용되었습니다:

• Dry‑run mode with the limit_conn_dry_run 지시어를 사용하는 시험 실행 모드
• NGINX Plus API 엔드포인트에서 실시간 모니터링 /api/version/http/limit_conns
• 각 요청에 대한 연결 제한 결정을 기록하는 새로운 변수 $limit_conn_status(PASSED, REJECTED, 또는 REJECTED_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 또는 no-cache)을 연결하고, add_header 지시문은 NGINX Plus가 요청을 업스트림 서버로 전달할 때 Cache-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 주소로 확인되는 호스트 이름을 지정하여 업스트림 그룹의 구성원을 정의할 수 있습니다. 이는 업스트림 그룹의 구성원이 자주 변경될 수 있는 동적 환경이나 자동 확장 환경에서 특히 유용합니다.

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

이 새로운 유연성은 DevOps 환경에서 특히 유용합니다. 애플리케이션 팀이 중앙 집중식 공유 서비스에 의존하는 대신 DNS 서버와 서비스 레지스트리를 비롯한 애플리케이션 제공 인프라를 더 폭넓게 직접 관리할 수 있기 때문입니다.

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

다음 예에서 website 업스트림 그룹은 전역 리졸버를 사용하는 반면, mobile_app은 자체 리졸버를 사용합니다:

코드 예제를 로드하는 중…

두 status_zone 매개변수(“NGINX Plus R19에서 도입)를 양쪽 resolver 지시문에 모두 포함하여 리졸버 활동에 관한 오류 및 기타 메트릭을 수집한다는 점에 유의하세요.

PROXY 프로토콜 서버 메타데이터용 변수

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

애플리케이션 환경에 여러 계층 4 프록시가 배포된 경우, NGINX Plus에서도 클라이언트가 처음 연결한 프록시 서버의 IP 주소와 포트를 알아야 할 때가 있습니다. PROXY 프로토콜 메타데이터에는 이 정보가 포함되며, NGINX Plus R20에는 이를 캡처하는 변수가 추가되었습니다:

• $proxy_protocol_server_addr
• $proxy_protocol_server_port

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

HTTP/2 보안 개선 사항

NGINX Plus R18 P1에서는 HTTP/2의 보안 취약점 3건을 해결했으며, 이 취약점들은 8월에 발표되었습니다. 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 JavaScript 모듈

NGINX JavaScript 모듈(njs)이 버전 0.3.7로 업데이트되어 더 많은 JavaScript 객체를 지원합니다:

• Function() 생성자
• Object.assign() 메서드
• Number 메서드: toFixed(), toPrecision(), toExponential()
• Array.prototype.copyWithin() 메서드
• Label parameter to the console.time() 메서드의 레이블 매개변수

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

NGINX Plus로 업그레이드하거나 사용해 보기

NGINX Plus를 실행 중이라면 가능한 한 빨리 NGINX Plus R20으로 업그레이드하시기를 강력히 권장합니다. 업그레이드하면 여러 추가 수정 사항과 개선 사항도 적용되며, 지원 티켓을 제출해야 할 때 NGINX가 더 원활하게 지원하는 데 도움이 됩니다.

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

아직 NGINX Plus를 사용해 보지 않으셨다면 보안, 부하 분산, API 게이트웨이 용도로, 또는 향상된 모니터링 및 관리 API를 갖춘 완전한 기술 지원 웹 서버로 사용해 보시기 바랍니다. 지금 바로 30일 무료 평가판으로 시작해 보세요. NGINX Plus가 애플리케이션을 제공하고 확장하는 데 어떻게 도움이 되는지 직접 확인해 보세요.

작성자 소개

Liam Crilly제품 관리 부문 수석 이사

Liam Crilly의 다른 블로그 게시물