NGINX Plus R19 발표

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

NGINX Plus Release 19(R19)가 출시되었음을 기쁘게 알려드립니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시, 웹 서버 및 API 게이트웨이를 하나로 통합한 유일한 솔루션입니다. NGINX Open Source를 기반으로 하는 NGINX Plus에는 독점적인 고급 기능과 수상 경력에 빛나는 지원 서비스가 포함되어 있습니다. 이번 릴리스에서는 모니터링에 중점을 두었으며, 더욱 세분화되고 유연한 새로운 기능을 통해 대규모 애플리케이션의 안정성을 향상합니다.

NGINX Plus R19의 새로운 기능은 다음과 같습니다:

• 더욱 유연한 모니터링 – NGINX Plus 에코시스템을 더욱 세밀하게 파악하고 쉽게 분석할 수 있도록 새로운 기능을 추가했습니다. 여기에는 location 블록별 메트릭을 선택적으로 별도 수집하는 기능, DNS 조회 활동에 관한 새로운 메트릭, JSON뿐만 아니라 Prometheus 형식으로 내보내는 기능이 포함됩니다. NGINX Plus 대시보드에는 새로운 location별 메트릭이 표시되며, DNS 메트릭과 NGINX Plus 클러스터 관련 메트릭을 위한 새 탭도 추가되었습니다.
• 속도 제한 테스트를 위한 드라이런 모드 – 프로덕션 트래픽에 적절한 속도 제한을 설정하는 것은 어렵고 위험 부담도 매우 큽니다. 잘못 설정하면 상당수 사용자의 사용자 경험에 심각한 영향을 줄 수 있습니다. 새로운 드라이런 모드를 사용하면 속도 제한을 실제로 적용하지 않고도 프로덕션 트래픽에 미치는 영향을 파악할 수 있습니다.
• 키-값 저장소 개선 사항 – 이제 키-값 저장소에 개별 IP 주소뿐만 아니라 IP 주소 범위도 저장하고, 각 항목에 만료 시간을 설정할 수 있습니다.
• 동적 대역폭 제어 – 이제 대역폭 제한을 구성할 때 속도를 변수로 설정하여 수신 트래픽의 모든 속성을 기준으로 서로 다른 제한을 적용할 수 있습니다.

중요한 동작 변경 사항

• 더 이상 사용되지 않는 API – NGINX Plus R13(2017년 8월 출시)에서는 메트릭 수집 및 업스트림 그룹의 동적 재구성을 위한 완전히 새로운 NGINX Plus API가 도입되어, 이전에 이러한 기능을 구현하던 Status 및 Upstream Conf API를 대체했습니다. 당시 공지한 대로, 더 이상 사용되지 않는 API는 상당 기간 계속 제공되고 지원되었으나 NGINX Plus R16부터 지원이 종료되었습니다. 구성에 status 및/또는 upstream_conf 지시문이 포함되어 있다면 R19로 업그레이드할 때 이를 api 지시문으로 교체해야 합니다. 새로운 NGINX Plus API로 마이그레이션하는 방법에 대한 안내와 도움이 필요하면 블로그의 전환 가이드를 참조하거나 지원팀에 문의하세요.
• 새롭게 지원되는 운영 체제 –
  • Alpine 3.10
  • Debian 10(“Buster”)
  • Ubuntu 19.04(“Disco”)
• 이전 운영 체제는 더 이상 지원되지 않음 –
  • Debian 8(“Jessie”)
  • Ubuntu 14.04(“Trusty”)
  • Ubuntu 18.10(“Cosmic”)

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

새로운 기능 상세 정보

새로운 기능으로 모니터링이 더욱 유연해집니다

NGINX Plus R19는 수집할 수 있는 메트릭의 종류와 이를 분석하는 방법을 모두 확장하여 모니터링을 한층 더 유연하게 해줍니다.

위치별 메트릭

NGINX Plus API는 가상 서버의 status_zone 블록에 server{} 지시문을 포함하면 해당 가상 서버에 대한 여러 카운터를 비롯해 다양한 실시간 모니터링 메트릭을 제공합니다. NGINX Plus R19부터는 location 블록에 server{} 지시문을 추가하여 상위 status_zone 블록뿐만 아니라(또는 그 대신) 개별 location 블록의 메트릭도 수집할 수 있습니다. 이처럼 세분화된 모니터링을 통해 웹사이트에서 오류를 발생시키는 정확한 부분을 더 빠르게 파악하여 문제를 더욱 효과적으로 해결할 수 있습니다.

다음 구성은 전체 웹사이트뿐만 아니라 /admin/로 시작하는 URI에 대한 모든 요청의 메트릭 수집도 활성화합니다.

코드 예제를 로드하는 중…

그런 다음 http/location_zones 엔드포인트에서 메트릭에 액세스할 수 있습니다.

$ curl http://localhost:8080/api/5/http/location_zones{
  "www_admin": {
    "requests": 3393,
    "responses": {
      "1xx": 0,
      "2xx": 3307,
      "3xx": 81,
      "4xx": 5,
      "5xx": 0,
      "total": 3393
    },
    "discarded": 0,
    "received": 15403,
    "sent": 835227
  }
}

It is also possible to place the status_zone 지시어를 if 블록 안에 배치할 수도 있습니다. 단, 지정된 location의 메트릭은 한 번만 집계되며, 요청 처리 중 마지막으로 발견된 status_zone 지시어를 기준으로 집계됩니다. 다음 구성은 /admin/ location에 대한 요청에 쿼리 문자열이 포함될 때마다 별도의 메트릭을 수집하도록 이전 예제를 확장한 것입니다.

코드 예제를 로드하는 중…

DNS 리졸버 메트릭

NGINX Plus API에는 DNS 조회 활동, 특히 DNS 요청 유형과 응답 상태를 추적하기 위한 메트릭도 추가되었습니다. NGINX Plus가 이름 조회를 위해 쿼리하는 DNS 서버 그룹에 대한 메트릭을 수집하려면 status_zone 매개변수를 resolver 지시문에 추가합니다.

코드 예제를 로드하는 중…

그런 다음 resolvers 엔드포인트에서 메트릭에 액세스할 수 있습니다.

$ curl http://localhost:8080/api/5/resolvers{
  "internal_dns": {
    "requests": {
      "name": 132,
      "srv": 0,
      "addr": 0
    },
    "responses": {
      "noerror": 130,
      "formerr": 0,
      "servfail": 0,
      "nxdomain": 0,
      "notimp": 0,
      "refused": 0,
      "timedout": 2,
      "unknown": 0
    }
  }
}

실시간 활동 모니터링 대시보드 업데이트

NGINX Plus 실시간 활동 모니터링 대시보드는 NGINX Plus API에서 수집한 메트릭을 추적할 수 있는 편리한 중앙 집중식 공간을 제공합니다. NGINX Plus R19에서는 위에서 설명한 새로운 리졸버 및 위치별 메트릭이 대시보드에 추가되었습니다. 또한 이제 영역 동기화 모듈을 통해 활성화되는 클러스터의 런타임 상태 공유 관련 메트릭도 표시합니다. 이전에는 이러한 메트릭을 NGINX Plus API를 통해서만 확인할 수 있었습니다.

이름이 변경된 탭 2개와 새 탭 2개가 있습니다:

• HTTP 영역은(는) 서버 영역 탭의 새 이름입니다. 이제 이 탭에는 location 블록뿐만 아니라 server 블록에 대한 메트릭도 표시됩니다.
• HTTP 업스트림은 업스트림 탭의 새로운 이름입니다. HTTP 모듈과 TCP/UDP 모듈이 모두 구성된 경우 이를 명확하게 구분할 수 있습니다.
• 새로운 클러스터 탭에는 NGINX Plus 클러스터의 상태 공유에 관한 메트릭이 표시됩니다.
• 새로운 리졸버 탭에는 DNS 조회 활동에 대한 메트릭이 표시됩니다.

새 대시보드를 살펴보려면 https://demo.nginx.com/을 방문하세요.

Prometheus 모니터링을 위한 새로운 모듈

NGINX Plus API는 외부 모니터링 및 애플리케이션 성능 관리(APM) 솔루션과 통합하기에 일반적이고 편리한 JSON 형식으로 메트릭을 반환합니다. 이제 Kubernetes 환경에서 특히 널리 사용되는 Prometheus 형식으로도 메트릭을 내보낼 수 있습니다.

Prometheus-njs 모듈은 Prometheus 메트릭을 제공합니다. 메트릭 내보내기를 활성화하려면 다음을 수행합니다:

1. Prometheus-njs 모듈을 설치합니다.
2. NGINX Plus API를 구성합니다.
3. NGINX Plus 구성 파일에서 Prometheus 메트릭 수집을 위한 전용 location을 구성합니다.

   코드 예제를 로드하는 중…

4. Prometheus 구성 파일의 scrape_config 섹션에 NGINX Plus 인스턴스의 네트워크 주소를 지정하여 Prometheus가 NGINX Plus에서 메트릭을 가져오도록 구성합니다.

드라이런 모드에서 요청 속도 제한 테스트

NGINX Plus는 속도 제한을 매우 유연하게 적용할 수 있는 방식을 제공합니다. 여러 속도 제한을 동시에 추적하고 적용할 수 있습니다. 적용 방식은 과도한 요청을 지연시키거나 즉시 거부하는 방식, 제한을 적용하기 전에 일시적으로 급증한 요청을 제한 없이 허용하는 방식 등 다섯 가지가 있으며, 이러한 방식을 조합할 수도 있습니다. 자세한 설명은 블로그에서 확인하세요.

이러한 유연성을 활용하면 속도 제한을 매우 정교하게 설정할 수 있지만, 애초에 트래픽에 적합한 속도 제한은 어떻게 결정할 수 있을까요? 계획한 속도 제한이 너무 높아 서버에 과부하가 걸릴지, 아니면 너무 낮아 사용자 경험에 영향을 미칠지 어떻게 미리 알 수 있을까요?

가장 유용한 정보는 NGINX Plus 오류 로그에서 확인할 수 있습니다. NGINX Plus가 요청을 지연시키거나 거부하면 다음과 같은 상세 항목이 생성됩니다:

2019/09/03 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.1", host: "www.example.com:80"

이 항목에서는 이 요청이 구성된 속도를 밀리초당 몇 개의 요청만큼 초과했는지(excess 필드), 어떤 제한을 초과했는지(zone 필드), 클라이언트의 IP 주소가 무엇인지(client 필드)와 같은 유용한 정보를 확인할 수 있습니다. 하지만 이 정보가 계획 수립에 유용하려면 트래픽에 실제로 제한을 적용하기 전에 정보를 확보할 수 있어야 합니다.

NGINX Plus R19에는 속도 제한을 위한 ‘드라이런’ 모드가 추가되어 이러한 예측 기능을 제공합니다. 로그 항목은 평소와 같이 생성되지만 속도 제한은 적용되지 않습니다. 드라이런 모드를 활성화하려면 새로운 limit_req_dry_run 지시어를 limit_req 지시어와 동일한 블록에 포함하세요.

다음 예제에서 limit_req_zone 지시문은 초당 10,000개 요청부터 초당 10개 요청까지 서로 다른 네 가지 요청 속도 제한을 정의합니다. 루트 limit_req 지시문을 사용하여 이러한 속도 제한을 location 블록(9~12행)에 적용하고, limit_req_dry_run 지시문을 함께 사용하여 제한이 적용되지 않도록 합니다.

코드 예제를 로드하는 중…

NGINX Plus는 지정된 속도 제한을 초과할 요청마다 dry run으로 명확히 표시된 로그 항목을 기록합니다. 그런 다음 로그를 분석할 때 zone 필드를 기준으로 항목을 필터링하여 어떤 속도 제한이 원하는 동작을 제공하는지 확인할 수 있습니다.

2019/09/03 11:56:26 [error] 142#142: *22282 limiting requests, dry run, excess: 1.000 by zone "1000rs", client: 172.17.0.1, server: www.example.com, request: "GET / HTTP/1.1", host: "www.example.com:80"

키-값 저장소 개선 사항

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

네트워크 범위 지원

NGINX Plus R19에서는 기존의 개별 IP 주소 지원에 IP 네트워크 범위(서브넷) 지원을 추가하여 키-값 저장소의 기능을 확장했습니다. 즉, 키-값 저장소의 단일 항목으로 네트워크 범위 내의 모든 IP 주소를 일치시킬 수 있으므로, 범위를 구성하는 주소를 하나씩 추가할 필요가 없어 구성이 간소화되고 시간이 절약됩니다. 키-값 저장소는 CIDR 표기법을 사용하여 네트워크 범위를 나타냅니다. 예를 들어 192.168.13.0/24는 192.168.13.0부터 192.168.13.255까지의 주소를 나타냅니다. IPv4 및 IPv6 주소와 범위를 모두 지원합니다.

네트워크 범위를 사용하려면 IP 주소를 동적으로 차단 목록에 추가하는 다음 구성과 같이 type=ip 매개변수를 keyval_zone 지시문에 새로 추가합니다. NGINX Plus가 조회를 수행할 때 키-값 저장소에 저장된 네트워크 범위 내의 모든 IP 주소가 일치 항목으로 반환됩니다.

코드 예제를 로드하는 중…

2행에서는 $in_denylist 변수가 denylist 키-값 저장소에서 $remote_addr(클라이언트 IP 주소)를 키로 사용하여 조회를 수행함으로써 평가되도록 지정합니다. 그런 다음 간단한 if 블록(8~10행)은 클라이언트 IP 주소가 거부 목록에 있으면 요청을 거부합니다.

다음 curl 명령은 NGINX Plus API를 호출하여 위에서 언급한 네트워크 범위에 대한 항목을 키-값 저장소에 생성합니다.

$ curl -X POST -d '{"192.168.13.0/24":"1"}' http://localhost:8080/api/5/http/keyvals/denylist

항목별 만료 시간 제한

이전 섹션에서 timeout=24h 매개변수는 keyval_zone 지시문에 지정되며, denylist.conf의 1번째 줄에 있습니다. 이는 거부 목록 키-값 저장소의 각 항목이 생성된 후 24시간이 지나면 만료되어 저장소에서 제거된다는 의미입니다.

NGINX Plus R19에서는 전체 키-값 저장소에 대해 timeout 매개변수로 설정된 기본 제한 시간을 개별 항목마다 다른 제한 시간으로 재정의할 수 있습니다. 개별 제한 시간은 기본값보다 길거나 짧게 설정할 수 있습니다.

기본값이 아닌 시간 제한을 사용하는 항목을 생성하려면 값을 두 개의 필드가 있는 JSON 객체로 지정합니다:

• value – 원하는 값으로 설정합니다. 이 경우에는 1로 설정하여 $in_denylist 변수를 채웁니다.
• expire – 값이 생성된 후 만료될 때까지의 시간(밀리초)을 설정합니다

다음 JSON은 1시간(3,600,000밀리초) 후에 만료되는 localhost(127.0.0.1)의 차단 목록 항목을 나타냅니다.

{
  "127.0.0.1": {
    "value": "1",
    "expire": 3600000
  }
}

다음 curl 명령은 키-값 저장소에 해당 항목을 생성합니다:

$ curl -X POST -d '{"127.0.0.1":{"value":"1","expire":3600000}}' http://localhost:8080/api/5/http/keyvals/denylist

동적 대역폭 제어

The limit_rate 지시문은 NGINX Plus가 HTTP 요청에 대한 응답을 전송하는 속도(초당 바이트 수)를 설정하고, limit_rate_after 지시문은 해당 제한이 적용되기 전에 NGINX Plus가 전송할 바이트 수를 설정합니다. NGINX Plus R19부터는 각 지시문의 매개변수에 정적 값 대신 변수를 사용할 수 있으므로 요청의 속성에 따라 대역폭 사용량을 동적으로 제어할 수 있습니다.

다음 구성 예제에서는 클라이언트가 사용하는 TLS 버전에 따라 대역폭을 설정하여, 최신 브라우저에 더 빠른 응답을 제공하는 효과를 냅니다.

코드 예제를 로드하는 중…

이전 NGINX Plus 릴리스에서는 $limit_rate 변수를 설정하여 대역폭을 제한할 수 있었지만, 이제는 이보다 간소화된 방법을 사용하는 것이 좋습니다. 자세한 내용은 limit_rate 지시어 설명서를 참조하세요.

TCP/UDP 트래픽에 대한 proxy_download_rate 및 proxy_upload_rate 지시문에서도 이제 변수 매개변수를 사용할 수 있습니다.

더욱 정교하게 대역폭을 제한하려면 NGINX JavaScript 모듈(njs)과 같은 스크립팅 확장 기능을 사용하여 특정 연결에 적합한 대역폭 제한을 결정하는 고급 사용자 지정 로직을 구현할 수 있습니다.

NGINX Plus 에코시스템 업데이트

NGINX JavaScript 모듈

NGINX JavaScript 모듈(njs)이 버전 0.3.5로 업데이트되었습니다. 이전 버전부터 누적된 주요 개선 사항은 다음과 같습니다:

• 화살표 함수 지원(洪志道[Hong Zhi Dao]와 Artem S. Povalyukhin의 기여)
• 전역 process 객체(특히 환경 변수를 읽을 때 유용함)
• String.prototype.trim 함수

NGINX Plus 업그레이드 또는 체험

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

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

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

작성자 소개

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

Liam Crilly의 다른 블로그 게시물