NGINX Plus R12 출시 발표

Owen Garrett제품 관리 부문 수석 이사

[편집자 주 – 이 게시물은 원본에서 설명한 별도의 동적 구성 및 상태 모듈을 대체하고 더 이상 사용되지 않도록 하는 NGINX Plus API를 참조하도록 업데이트되었습니다.]

오늘 NGINX Plus R12가 모든 NGINX Plus 구독자에게 무료 업그레이드로 제공된다는 소식을 기쁘게 알려드립니다. NGINX Plus는 로드 밸런서, 콘텐츠 캐시 및 웹 서버를 포함하는 고성능 소프트웨어 애플리케이션 전송 플랫폼입니다. NGINX Plus R12는 클러스터링, 사용자 지정 및 모니터링에 중점을 둔 새로운 기능이 추가된 주요 릴리스입니다.

NGINX Plus R12에 대해 자세히 알아보려면 주문형 웨비나를 시청하세요.

엔터프라이즈 사용자는 NGINX Plus 서버의 고가용성 클러스터 관리 프로세스를 간소화하는 새로운 클러스터링 기능을 활용할 수 있습니다. 또한 모든 사용자는 NGINX 구성에 직접 내장되는 가볍고 성능이 뛰어난 스크립팅 언어인 nginScript의 공식 지원을 활용할 수 있습니다. 모니터링 및 계측, 캐싱, 상태 확인 기능이 개선되어 애플리케이션의 안정성과 성능이 향상됩니다.

• 구성 공유 – 지원되는 구성 공유 스크립트를 사용하면 기본 NGINX Plus 인스턴스의 구성을 여러 피어에 안정적으로 배포할 수 있습니다. 이 프로세스는 구성을 적용하고 피어의 nginx 프로세스를 다시 로드하기 전에 백업을 수행하고 각 원격 피어에서 구성이 유효한지 확인합니다.
• NGINX JavaScript 모듈의 정식 출시 – NGINX JavaScript 모듈<.htmla>을 사용하면 익숙한 JavaScript 구문으로 NGINX Plus에서 정교한 트래픽 처리 솔루션을 만들 수 있습니다. [이 모듈은 이전에 nginScript라고 불렸으며, 이 게시물에서는 두 이름을 혼용합니다.] JavaScript 코드를 NGINX Plus 구성에 삽입하여 HTTP, TCP 및 UDP 트래픽에 대한 사용자 지정 작업을 수행할 수 있습니다.
• 새로운 통계 – 애플리케이션을 안정적이고 높은 성능으로 유지하려면 가시성이 중요합니다. NGINX Plus R12는 서버 응답 시간, 공유 메모리 영역 사용률, TCP/UDP 서비스의 오류 코드 등 추가 메트릭을 통해 애플리케이션 성능에 대한 가시성을 높여 줍니다. 새로운 통계는 기본 제공되는 실시간 활동 모니터링 대시보드에서 확인하거나 JSON 형식으로 내보내 선호하는 모니터링 도구에서 사용할 수 있습니다.
• 향상된 캐싱 – 캐시 성능을 한층 더 높일 수 있습니다. NGINX Plus R12는 stale-while-revalidate 및 stale-if-error 캐시 확장 기능을 지원합니다. 이러한 기능은 RFC 5861에 정의되어 있습니다. 캐시 재검증을 백그라운드에서 수행할 수 있으므로 사용자는 원본 서버와의 왕복 요청이 완료될 때까지 기다릴 필요가 없습니다.
• 상태 점검 개선 – NGINX Plus API 또는 DNS를 사용하여 부하 분산 풀에 새 서버를 추가하면, NGINX Plus는 해당 서버가 구성된 정기 상태 점검을 통과할 때까지 트래픽 전송을 보류한 다음, 느린 시작 기능을 적용하여 트래픽을 점진적으로 늘릴 수 있습니다. 또한 새롭게 간소화된 UDP 상태 점검을 통해 사용자에게 안정적인 UDP 서비스를 더욱 쉽게 제공할 수 있습니다.

추가 개선 사항으로는 TCP 서비스의 클라이언트 인증서 인증, OAuth JWT의 사용자 지정 필드 검사 기능, 이미지 필터 모듈의 WebP 형식 지원, 그리고 다양한 성능 및 안정성 개선이 포함됩니다.

모든 구독 고객은 이번 릴리스에서 향상된 성능, 기능 및 안정성을 활용할 수 있도록 NGINX Plus R12로 즉시 업데이트하시기 바랍니다. 업데이트를 수행하기 전에 다음 섹션에 나열된 동작 변경 사항을 반드시 검토하십시오.

동작 변경 사항

NGINX Plus R12에서는 기본 동작과 NGINX Plus 내부 구조가 일부 변경되므로 업그레이드할 때 다음 사항에 유의해야 합니다:

• 캐시 메타데이터 형식 – 내부 캐시 메타데이터 헤더의 형식이 변경되었습니다. NGINX Plus R12로 업그레이드하면 디스크 캐시가 무효화되며, NGINX Plus가 필요에 따라 캐시를 자동으로 새로 고칩니다. 이전 캐시 항목은 자동으로 삭제됩니다.
• SSL “DN” 변수 – $ssl_client_s_dn 및 $ssl_client_i_dn 변수의 형식이 변경되었습니다. 이제 쉼표( , )가 슬래시( / ) 대신 필드 구분자로 사용되며 RFC 2253 및 4514에 따라 이스케이프됩니다. 슬래시를 필드 구분자로 사용하는 X509_NAME_oneline 형식을 계속 사용하려면 $ssl_client_s_dn_legacy 및 $ssl_client_i_dn_legacy 변수를 사용하십시오.
• 최대 연결 대기열 – queue 지시문은 업스트림 서버가 과부하 상태일 때 해당 서버로의 연결을 대기열에 추가하도록 NGINX Plus에 지시합니다. R12의 메모리 및 성능 최적화로 인해 이제 queue 지시문은 upstream 블록에서 부하 분산 알고리즘을 지정하는 지시문 아래에 배치해야 합니다(hash, ip_hash, least_conn 또는 least_time).
• 타사 동적 모듈 – 동적 모듈 중 NGINX, Inc.에서 개발하거나 인증한 모듈은 당사 리포지토리에서 제공됩니다. 타사 모듈을 NGINX Plus R12에서 계속 사용하려면 NGINX Open Source 버전 1.11.10에 맞춰 다시 컴파일해야 합니다. 자세한 내용은 NGINX Plus 관리 가이드를 참조하세요.
• 지원 종료 OS 버전을 위한 최종 릴리스 – Ubuntu는 Ubuntu 12.04 LTS의 지원 종료를 발표했으며, Red Hat은 Red Hat Enterprise Linux 5.10+의 프로덕션 단계 지원을 2017년 3월 31일부로 종료한다고 발표했습니다. NGINX Plus R12는 이러한 OS 버전과 CentOS 5.10+ 및 Oracle Linux 5.10+용 패키지와 지원을 제공하는 마지막 릴리스입니다. NGINX Plus R12 이후에도 업데이트와 지원을 계속 받으려면 지원되는 OS 버전으로 업데이트하십시오.

NGINX Plus R12 기능 상세 소개

구성 공유

NGINX Plus 서버는 고가용성과 확장성을 위해 두 개 이상의 인스턴스로 구성된 클러스터에 배포되는 경우가 많습니다. 이를 통해 서버 장애의 영향으로부터 서비스를 보호하여 안정성을 높이고, 수평 확장을 통해 대량의 트래픽을 처리할 수 있습니다.

NGINX Plus는 이미 클러스터 전체에 트래픽을 분산하는 공식 지원 방식을 제공하며, 액티브-패시브 또는 액티브-액티브 방식으로 구성할 수 있습니다. NGINX Plus R12에는 클러스터 전체의 구성을 동기화하는 또 다른 공식 지원 방식이 추가되었습니다. 이 구성 동기화 기능을 사용하면 관리자가 단일 위치에서 NGINX Plus 서버 “클러스터”를 구성할 수 있습니다. 이러한 서버는 구성의 공통 하위 집합을 공유합니다.

NGINX Plus 구성이 기본 서버에서 피어 서버로 푸시됩니다

구성을 동기화하는 방법은 다음과 같습니다:

1. 클러스터에서 하나 이상의 “기본” 노드를 지정합니다.
2. 기본 노드에 새 nginx-sync 패키지를 설치합니다.
3. 기본 노드에 구성 변경 사항을 적용합니다.
4. nginx-sync 패키지에 포함된 구성 동기화 프로세스인 nginx-sync.sh를 실행하여 클러스터의 다른 각 서버(피어)를 업데이트합니다. 동기화 프로세스는 각 피어에서 다음 단계를 수행합니다:
   1. 업데이트된 구성을 피어에 ssh 또는 rsync를 통해 푸시합니다.
   2. 구성이 피어에 유효한지 확인하고, 유효하지 않으면 롤백합니다.
   3. 구성이 유효하면 이를 적용하고 피어의 NGINX Plus 서버를 다시 로드합니다.

이 기능은 NGINX Plus가 내결함성을 갖춘 서버 쌍(또는 더 많은 수의 서버)에 배포된 경우 특히 유용합니다. 이 방법을 사용하면 클러스터 내에 구성을 안정적으로 배포하는 작업을 간소화하거나 스테이징 서버에서 프로덕션 서버 클러스터로 구성을 푸시할 수 있습니다.

자세한 지침은 NGINX Plus 관리자 가이드를 참조하세요.

NGINX JavaScript 모듈 정식 출시

NGINX Plus R12 출시와 함께 NGINX JavaScript 모듈이 이제 NGINX Open Source와 NGINX Plus 모두에서 안정적인 모듈로 정식 제공됨을 기쁘게 알려드립니다. [이 모듈은 이전에 nginScript라고 불렸으며, 이 게시물에서는 두 명칭을 혼용합니다.] nginScript는 NGINX Plus 구독자에게 완전한 지원을 제공합니다.

nginScript는 NGINX 및 NGINX Plus를 위한 독자적인 JavaScript 구현<.htmla>으로, 서버 측 사용 사례와 요청별 처리를 위해 특별히 설계되었습니다. JavaScript 코드로 NGINX Plus 구성 구문을 확장하여 정교한 구성 솔루션을 구현할 수 있습니다.

nginScript를 사용하면 복잡한 로직으로 사용자 지정 변수를 기록하고, 업스트림 선택을 제어하며, 부하 분산 알고리즘을 구현하고, 세션 지속성을 사용자 지정할 수 있을 뿐만 아니라 간단한 웹 서비스까지 구현할 수 있습니다. 앞으로 몇 주 동안 이러한 솔루션 중 일부에 대한 전체 지침을 블로그에 게시하고, 제공되는 대로 여기에 해당 링크를 추가할 예정입니다.

구체적으로 NGINX Plus R12에는 다음과 같은 향상된 기능이 포함되어 있습니다:

• 사전 읽기 단계(Stream 모듈
• ECMAScript 6 Math 메서드 및 상수
• 다음과 같은 추가 String 메서드: endsWith, includes, repeat, startsWith, trim
• 스코프

nginScript는 안정적이지만, 더 다양한 사용 사례와 JavaScript 언어 기능을 지원하기 위한 작업은 계속되고 있습니다. 자세한 내용은 블로그의 NGINX JavaScript 모듈로 각 요청에서 JavaScript의 강력함과 편리함 활용하기<.htmla>에서 확인하세요.

새로운 통계

NGINX Plus의 모니터링 및 계측 기능은 NGINX Plus와 업스트림 애플리케이션 모두의 성능과 동작을 심층적으로 파악할 수 있게 해 주는 중요한 부가 가치입니다. 통계는 기본 제공 그래픽 대시보드뿐만 아니라 선호하는 모니터링 도구로 내보낼 수 있는 JSON 형식으로도 제공됩니다.

실시간 활동 모니터링 대시보드가 NGINX Plus R12용으로 업데이트되었습니다

NGINX Plus R12에는 여러 가지 개선 사항이 추가되었습니다. 부하 분산 서버의 성능(응답 시간)에 대한 더욱 자세한 정보, TCP 및 UDP 서비스의 작동 방식에 대한 인사이트, 문제를 식별하기 위한 문제 해결과 성능 최적화를 위한 NGINX Plus 튜닝에 도움이 되는 다양한 내부 데이터가 제공됩니다.

NGINX Plus R12에 새로 추가된 통계는 다음과 같습니다:

• 업스트림 서버 응답 시간 – NGINX Plus R11 이하에서는 Least Time 부하 분산 알고리즘을 사용할 때만 업스트림 서버의 응답 시간이 계산되었습니다. NGINX Plus R12부터는 모든 알고리즘에서 응답 시간이 측정되며, JSON 데이터와 기본 제공 대시보드 모두에 표시됩니다.
• 그래픽 대시보드의 TCP/UDP 업스트림 응답 코드 – TCP/UDP 부하 분산용 Stream 모듈은 연결이 종료된 방식을 식별하기 위해 의사 상태 코드를 생성합니다(200은 “성공”, 502는 “업스트림 사용 불가” 등을 의미). 이 코드는 $status 변수에 기록됩니다. NGINX Plus R12에서는 기존에 HTTP 가상 서버용으로 제공되던 것과 마찬가지로 TCP 및 UDP 가상 서버의 응답 코드 수를 표시하는 일련의 열이 대시보드에 추가되었습니다. 기존 로그 분석 도구와 통합할 수 있도록 의사 상태 코드를 로그에 기록할 수도 있습니다.
• NGINX Plus 버전 정보 – 문제 해결에 도움이 되도록 이제 JSON 데이터에서 NGINX Plus 릴리스 번호를 nginx_build(예: nginx-plus-r12)로, NGINX Open Source 버전 번호를 nginx_version(예: 1.11.10)로 보고합니다. 대시보드의 기본 탭 왼쪽 상단 상자에 두 값이 모두 표시됩니다.
• 업스트림 호스트 이름 – JSON 데이터에서 server 필드는 업스트림 그룹의 서버를 IP 주소와 포트로 식별합니다. 새로운 name 필드는 upstream 구성 블록에 있는 server 지시문의 첫 번째 매개변수를 보고합니다. 이 매개변수에는 IP 주소와 포트뿐만 아니라 도메인 이름이나 UNIX 도메인 소켓 경로도 사용할 수 있습니다. 이제 대시보드의 Upstreams 및 TCP/UDP Upstreams 탭에서 가장 왼쪽에 있는 Name 열에는 server 필드(NGINX Plus R11 이하에서 표시됨) 대신 name 필드의 값이 표시됩니다. 새로운 메트릭을 사용하면 업스트림 서버를 DNS 이름, 특히 여러 IP 주소로 확인되는 이름을 사용하여 정의한 경우 JSON 데이터 및 대시보드와 업스트림 서버를 더 쉽게 연관 지을 수 있습니다.
• 확장 상태 데이터의 공유 메모리 영역 사용률 – 공유 메모리 영역은 고정된 크기로 구성되므로, 너무 크지도(메모리가 할당되지만 전혀 사용되지 않음) 너무 작지도(메모리가 고갈되어 캐시된 항목이 삭제됨) 않은 크기를 선택하기가 어려울 수 있습니다. 메트릭에 새로 추가된 계측 기능은 각 공유 영역의 메모리 사용량에 대한 상세한 내부 보고서를 제공하므로, 사용자는 메모리 사용량을 모니터링할 수 있고 NGINX 기술 지원팀은 NGINX 구성 최적화에 관해 더욱 정확한 조언을 제공할 수 있습니다.
• NGINX Plus 액세스 로그의 JSON 호환 이스케이프 처리 – 일부 최신 로그 분석 도구는 JSON 형식의 로그 파일을 효율적으로 수집하고, 형식이 지정되지 않은 로그 파일보다 더 쉽게 인사이트를 도출할 수 있습니다. 표준 NGINX Plus log_format 지시문에서 JSON 템플릿을 정의할 수 있으며, 이 지시문의 새로운 선택적 escape 매개변수는 JSON 호환 이스케이프 처리를 적용하여 로그 행의 형식이 올바르게 지정되도록 합니다.

자세한 내용은 실시간 활동 모니터링을 참조하세요.

향상된 캐싱

NGINX Plus R12에서는 NGINX Plus 캐싱 엔진이 크게 향상되었습니다.

업데이트 중 오래된 콘텐츠 제공

NGINX Plus R12에서는 Cache-Control 확장 기능인 RFC 5861의 stale-while-revalidate 및 stale-if-error를 지원합니다. 이제 NGINX Plus가 이러한 Cache-Control 확장 기능을 준수하도록 구성하여, 클라이언트 요청의 지연 시간을 늘리지 않고 백그라운드에서 만료된 리소스를 새로 고치는 동안 캐시에서 해당 리소스를 계속 제공할 수 있습니다. 마찬가지로 업스트림 서버를 사용할 수 없는 경우에도 NGINX Plus는 캐시에서 만료된 리소스를 제공할 수 있습니다. 이는 마이크로서비스 애플리케이션에서 서킷 브레이커 패턴을 구현하는 기법입니다.

무시하도록 구성하지 않는 한 Cache-Control 헤더를 무시하도록 구성하지 않는 한, NGINX Plus는 RFC 5861을 준수하는 stale 타이머가 포함된 Cache-Control 헤더를 반환하는 오리진 서버의 설정을 따릅니다. 예시는 다음과 같습니다:

Cache-Control: max-age=3600 stale-while-revalidate=120 stale-if-error=900

백그라운드 새로 고침을 지원하는 Cache-Control 확장 기능을 활성화하려면 강조 표시된 지시문을 포함하세요:

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;

server {
    # ...
    location / {
        proxy_cache my_cache;

        # Serve stale content when updating
        proxy_cache_use_stale updating;
        
        # In addition, don’t block the first request that triggers the update
        # and do the update in the background
        proxy_cache_background_update on;

        proxy_pass http://my_upstream;
    }
}

The proxy_cache_use_stale updating 지시어는 콘텐츠가 업데이트되는 동안 NGINX Plus가 오래된 버전의 콘텐츠를 제공하도록 합니다. 이 지시어만 포함하면 오래된 콘텐츠를 처음 요청한 사용자는 “캐시 미스”로 인한 지연을 감수해야 합니다. 즉, NGINX Plus가 원본 서버에서 콘텐츠를 가져와 캐시할 때까지 콘텐츠를 받지 못합니다. 업데이트 중인 오래된 콘텐츠를 이후에 요청하는 사용자들은 캐시에서 즉시 콘텐츠를 받지만, 첫 번째 사용자는 업데이트된 콘텐츠를 가져와 캐시할 때까지 아무것도 받지 못합니다.

새로운 proxy_cache_background_update 지시어를 사용하면 NGINX Plus가 백그라운드에서 콘텐츠를 새로 고치는 동안 첫 번째 사용자를 포함한 모든 사용자에게 오래된 콘텐츠가 제공됩니다.

새로운 기능은 FastCGI, SCGI, uwsgi 모듈에서도 사용할 수 있습니다.

바이트 범위 요청

캐싱 엔진이 한층 더 개선되어, 캐시되지 않은 파일의 시작 지점에서 구성된 바이트 수보다 더 뒤에서 시작하는 바이트 범위 요청의 경우 NGINX Plus가 캐시를 우회할 수 있습니다. 따라서 동영상 콘텐츠와 같은 대용량 파일에서 파일의 깊숙한 위치에 있는 바이트 범위를 요청하더라도 클라이언트 요청에 지연 시간이 추가되지 않습니다. 이전 버전의 NGINX Plus에서는 NGINX Plus가 파일 시작 지점부터 요청된 바이트 범위까지의 모든 콘텐츠를 가져와 캐시에 기록할 때까지 클라이언트가 요청한 바이트 범위를 수신하지 못했습니다.

새로운 proxy_cache_max_range_offset 지시어는 파일 시작 지점부터의 오프셋을 지정하며, 이 값을 초과하는 바이트 범위 요청은 NGINX Plus가 오리진 서버로 직접 전달하고 응답을 캐시하지 않습니다. (이 새로운 기능은 FastCGI, SCGI, uwsgi 모듈에서도 사용할 수 있습니다.)

proxy_cache_path /path/to/cache levels=1:2 keys_zone=my_cache:10m max_size=10g inactive=60m use_temp_path=off;
server {
    location / {
        proxy_cache my_cache;

        # Bypass cache for byte range requests beyond 10 megabytes
        proxy_cache_max_range_offset 10m;

        proxy_pass http://my_upstream;
    }
}

이러한 개선 사항을 통해 NGINX Plus는 애플리케이션 전송 가속부터 완전한 기능을 갖춘 콘텐츠 전송 네트워크(CDN) 구축에 이르기까지 모든 환경에 적합한 고성능 표준 준수 캐싱 엔진으로서의 입지를 더욱 공고히 합니다.

향상된 상태 확인

NGINX Plus R12에서는 NGINX Plus의 능동 상태 확인 기능이 더욱 향상되었습니다.

새로 추가된 서버의 상태 점검

컨테이너화된 환경과 자동 확장 애플리케이션 그룹의 도입이 증가함에 따라, 로드 밸런서가 선제적인 애플리케이션 수준의 상태 점검을 수행하고 새 서버가 정상적으로 가동되기 전에 내부 리소스를 초기화할 시간을 확보하도록 하는 것이 필수적입니다.

NGINX Plus R12 이전에는 새 서버를 로드 밸런싱 풀에 추가하면(NGINX Plus API 또는 DNS 사용) NGINX Plus가 해당 서버를 즉시 정상 상태로 간주하고 곧바로 트래픽을 전송했습니다. mandatory라는 새로운 매개변수를 health_check 지시문(HTTP 또는 TCP/UDP)에 포함하면 새 서버가 구성된 상태 검사를 통과해야 NGINX Plus가 해당 서버로 트래픽을 전송합니다. 이 매개변수를 slow‑start 기능과 함께 사용하면 새 서버가 전체 트래픽 할당량을 처리하기 전에 데이터베이스에 연결하고 준비를 마칠 수 있는 시간을 더 확보할 수 있습니다.

upstream my_upstream {     zone my_upstream 64k;
     server backend1.example.com slow_start=30s;
}

server {
    location / {
        proxy_pass http://my_upstream;
  
        # Require new server to pass health check before receiving traffic
        health_check mandatory;
    }
}

여기에는 mandatory 매개변수가 health_check 지시문에, slow_start 매개변수가 server 지시문(HTTP 또는 TCP/UDP)에 각각 포함되어 있습니다. API 또는 DNS 인터페이스를 사용하여 업스트림 그룹에 추가된 서버는 비정상 상태로 표시되며 상태 검사를 통과할 때까지 트래픽을 수신하지 않습니다. 상태 검사를 통과하면 30초에 걸쳐 점진적으로 증가하는 트래픽을 수신하기 시작합니다.

구성 없는 UDP 상태 확인

완전히 작동하지 않는 서버로 프로덕션 트래픽이 전송되지 않도록 하려면 HTTP 및 TCP 서버와 마찬가지로 UDP 서버에도 애플리케이션 수준의 상태 검사를 구현하는 것이 중요합니다. NGINX Plus는 UDP에 대한 능동 상태 검사를 지원하지만, NGINX Plus R12 이전에는 전송할 데이터와 예상 응답을 정의하는 match 블록을 생성해야 했습니다. 즉, send할 데이터와 expect할 응답을 지정해야 했습니다. 바이너리 프로토콜이나 복잡한 핸드셰이크를 사용하는 프로토콜에서는 적절한 값을 결정하기가 어려울 수 있습니다. 이러한 애플리케이션을 위해 NGINX Plus R12부터는 send 및 expect 문자열을 정의하지 않고도 애플리케이션의 가용성을 테스트하는 UDP용 ‘제로 구성’ 상태 검사를 지원합니다. 기본 UDP 상태 검사를 사용하려면 udp 매개변수를 health_check 지시문에 추가합니다.

upstream udp_app {    server backend1.example.com:1234;
    server backend2.example.com:1234;
}

server {
    listen 1234 udp;
    proxy_pass udp_app;

    # Basic UDP health check
    health_check udp;
}

SSL 업데이트 – TCP 서비스용 클라이언트 인증서, 업데이트된 변수

SSL 클라이언트 인증서는 일반적으로 보호된 웹사이트에서 사용자를 인증하는 데 사용됩니다. NGINX Plus R12는 기존 HTTP 지원에 더해 SSL로 보호되는 TCP 서비스에 대한 인증을 지원합니다. 이는 일반적으로 최종 사용자 로그인과 달리 시스템 간 인증에 사용되며, 레이어 4 프로토콜의 부하를 분산할 때 NGINX Plus를 SSL 종료와 클라이언트 인증에 모두 사용할 수 있게 해줍니다. MQTT 프로토콜을 사용해 통신하는 IoT 기기를 인증하는 경우가 그 예입니다.

이제 $ssl_client_verify 변수에는 클라이언트 인증 실패 이벤트에 대한 추가 정보가 포함됩니다. 여기에는 인증서가 “해지됨” 또는 “만료됨”과 같은 사유가 포함됩니다.

The format of the $ssl_client_i_dn 및 $ssl_client_s_dn 변수의 형식이 RFC 2253 및 4514를 준수하도록 변경되었습니다. 자세한 내용은 동작 변경 사항을 참조하세요.

향상된 JWT 검증

NGINX Plus R10에서는 OAuth 2.0 및 OpenID Connect 사용 사례를 위한 기본 JSON Web Token(JWT) 지원이 도입되었습니다. 주요 사용 사례 중 하나는 NGINX Plus가 JWT를 검증하고, JWT의 필드를 검사한 후, 이를 HTTP 헤더로 백엔드 애플리케이션에 전달하는 것입니다. 이를 통해 애플리케이션은 토큰 검증을 NGINX Plus에 맡기고 HTTP 헤더를 읽어 사용자 ID 정보를 가져오는 방식으로 OAuth 2.0 통합 인증(SSO) 환경에 손쉽게 참여할 수 있습니다.

NGINX Plus R10 이상에서는 JWT 사양에 정의된 필드를 검사할 수 있습니다. NGINX Plus R12에서는 JWT 지원이 확장되어 JWT의 모든 필드(사용자 지정 필드 포함)에 NGINX 변수로 액세스할 수 있으므로, 해당 필드를 프록시하거나 로깅하거나 권한 부여 결정에 사용할 수 있습니다.

NGINX Plus 업그레이드 또는 체험

NGINX Plus를 사용 중이라면 가능한 한 빨리 릴리스 12로 업그레이드하시기를 강력히 권장합니다. 여러 수정 사항과 개선 사항이 적용되며, 지원 티켓을 제출해야 할 경우 더 원활하게 도움을 받으실 수 있습니다. 설치 및 업그레이드 지침은 고객 포털에서 확인할 수 있습니다.

업그레이드를 진행하기 전에 위에서 설명한 동작 변경 사항을 참조하세요.

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

작성자 소개

Owen Garrett제품 관리 부문 수석 이사

Owen Garrett의 다른 블로그 게시물