NGINX Plus R16 발표

[ngx_snippet 이름='테이블 스타일 블로그']
NGINX Plus 릴리스 16(R16) 이 출시되어 기쁩니다. 오늘의 릴리스는 NGINX의 기술적 비전을 발전시키는 데 있어 가장 중요한 릴리스 중 하나입니다. R16을 사용하면 NGINX Plus가 모든 애플리케이션에 대한 단일하고 탄력적인 수신 및 송신 계층으로 작동합니다. 즉, 로드 밸런서, API 게이트웨이, WAF의 기능을 모든 클라우드에 걸쳐 단일 소프트웨어 패키지로 통합할 수 있다는 의미입니다.

오늘날 우리가 만나본 많은 회사는 이러한 구성요소를 모두 보유하고 있지만, 종종 서로 다른 공급업체를 이용하고 있습니다. 운영팀이 각 포인트 솔루션을 별도로 관리해야 하므로 비용이 증가하고 복잡성이 증가합니다. 또한, 홉을 하나 더 추가하면 지연 시간과 장애 지점이 늘어나 성능과 안정성도 떨어집니다.

NGINX Plus R16 의 새로운 기능을 사용하면 인프라를 통합하고 단순화하여 기존 애플리케이션과 최신 애플리케이션 모두에 대한 탄력적인 수신/송신 계층을 설계할 수 있습니다. NGINX Plus R16 에는 새로운 클러스터링 기능, 향상된 UDP 부하 분산, DDoS 완화 기능이 포함되어 있어 비용이 많이 드는 F5 BIG-IP 하드웨어 및 기타 부하 분산 인프라를 보다 완벽하게 대체할 수 있습니다. 글로벌 속도 제한에 대한 새로운 지원으로 NGINX Plus는 많은 API 게이트웨이 솔루션에 대한 가벼운 대안이 되었습니다. 마지막으로, Two Choices 로드 밸런싱을 통한 Random에 대한 새로운 지원으로 인해 NGINX Plus는 Kubernetes와 같은 확장 가능하거나 분산된 환경에서 마이크로서비스 트래픽의 로드 밸런싱을 위한 이상적인 선택이 되었습니다.

새로운 NGINX Plus R16 기능 요약

NGINX Plus R16 의 새로운 기능은 다음과 같습니다.

• 클러스터 인식 속도 제한 – NGINX Plus R15 에서 상태 공유 모듈을 도입하여 NGINX Plus 클러스터 전체에서 데이터를 동기화할 수 있게 되었습니다. 이 릴리스에서는 상태 공유가 속도 제한 기능까지 확장되어 NGINX Plus 클러스터 전체에서 글로벌 속도 제한을 지정할 수 있습니다. 글로벌 속도 제한은 API 게이트웨이의 중요한 기능이며 NGINX Plus의 매우 인기 있는 사용 사례입니다.
• 클러스터 인식 키-값 저장소 – NGINX Plus R13 에서 동적 IP 주소 거부 목록을 만들거나 HTTP 리디렉션을 관리하는 데 사용할 수 있는 키-값 저장소를 도입했습니다. 이번 릴리스에서는 키-값 저장소를 클러스터 전체에서 동기화할 수 있으며 새로운 시간 초과 매개변수가 포함되어 개별 키-값 쌍을 자동으로 제거할 수 있습니다. 새로운 동기화 지원을 통해 이제 키‑값 저장소를 사용하여 동적 DDoS 완화를 제공하고, 인증된 세션 토큰을 배포하거나 분산 콘텐츠 캐시(CDN)를 구축할 수 있습니다.
• 두 가지 선택이 있는 무작위 로드 밸런싱 – 로드 밸런서를 클러스터링할 때, 실수로 개별 백엔드 서버에 과부하를 일으키지 않는 로드 밸런싱 알고리즘을 사용하는 것이 중요합니다. 두 가지 선택 사항이 있는 무작위 로드 밸런싱은 확장된 클러스터에 매우 효율적이며 Kubernetes용 NGINX Ingress Controller의 다음 릴리스에서 기본 방법이 될 것입니다.
• 향상된 UDP 부하 분산 – NGINX Plus R9 에서 처음으로 UDP 부하 분산을 도입했습니다. 이러한 초기 구현은 서버와의 각 상호작용에 대해 클라이언트로부터 단일 UDP 패킷을 기대하는 UDP 애플리케이션(예: DNS 및 RADIUS)으로 제한되었습니다. NGINX Plus R16은 클라이언트로부터 여러 UDP 패킷을 처리할 수 있으므로 OpenVPN, VoIP(Voice over IP), VDI(Virtual Desktop Infrastructure)와 같은 보다 복잡한 UDP 프로토콜을 지원할 수 있습니다.
• AWS PrivateLink 지원 – AWS PrivateLink 는 가상 사설 클라우드에 안전한 VPN 터널을 생성하기 위한 Amazon 기술입니다. 이 릴리스를 사용하면 이제 AWS PrivateLink 데이터 센터 내에서 트래픽을 인증, 라우팅, 부하 분산하고 트래픽 흐름을 최적화할 수 있습니다. 이 기능은 PROXY 프로토콜 v2 에 대한 새로운 지원을 기반으로 구축되었습니다.

추가 개선 사항 으로는 OpenID Connect 불투명 세션 토큰 지원, 암호화된 세션 동적 모듈, NGINX JavaScript 모듈 업데이트 등이 있습니다. NGINX Plus R16은 NGINX Open Source 1.15.2를 기반으로 하며 오픈 소스 릴리스의 모든 기능을 포함합니다.

NGINX Plus R16 을 개발하는 동안 NGINX Plus의 중요한 사용 사례인 Kubernetes용 공식 NGINX Ingress Controller에 여러 가지 중요한 개선 사항을 추가했습니다.

NGINX Conf 2018 에서 NGINX Plus R16 과 NGINX에 대한 모든 내용을 자세히 알아보세요. 새로운 기능에 대해 자세히 알아보기 위해 전담 세션, 데모 및 전문가를 배치할 예정입니다.

행동의 중요한 변화

• 통합 NGINX Plus API 로 대체되고 더 이상 사용되지 않는 Upstream Conf 및 Status API가 제거되었습니다. 2017년 8월, NGINX Plus R13은 업스트림 그룹의 동적 재구성과 모니터링 메트릭을 위한 완전히 새로운 NGINX Plus API를 도입했으며, 이는 이전에 해당 기능을 구현했던 업스트림 Conf 및 Status API를 대체합니다. 당시 발표된 대로, 더 이상 지원되지 않는 API는 상당 기간 동안 계속 사용 및 지원되었지만, 현재는 그 기간이 끝났습니다. 구성에 upstream_conf 및/또는 status 지시문이 포함되어 있는 경우 R16으로 업그레이드하는 과정에서 이를 api 지시문으로 바꿔야 합니다.

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

• 수명이 끝난 OS 버전 에 대한 지원 중단 – NGINX Plus는 더 이상 Ubuntu 17.10(Artful) , FreeBSD 10.3 또는 FreeBSD 11.0에서 지원되지 않습니다.

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

• NGINX New Relic 플러그인은 새로운 NGINX Plus API를 사용하도록 업데이트되었으며 이제 오픈 소스 프로젝트가 되었습니다. 업데이트된 플러그인은 R13 이상의 모든 버전의 NGINX Plus에서 작동하지만 NGINX, Inc.에서는 더 이상 지원이나 유지 관리를 하지 않습니다.

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

클러스터 인식 속도 제한

NGINX Plus R15는 클러스터 내 모든 NGINX Plus 노드에서 런타임 상태를 공유할 수 있게 하는 zone_sync 모듈을 도입했습니다.

첫 번째 동기화 기능은 스티키러닝 세션 지속성 이었습니다. NGINX Plus R16은 상태 공유 기능을 속도 제한 기능까지 확장했습니다. NGINX Plus를 클러스터에 배포하면 이제 요청이 클러스터의 어느 멤버 노드에 도착하든 관계없이 들어오는 요청에 일관된 속도 제한을 적용할 수 있습니다. 전역 속도 제한 으로 널리 알려진 이 기능은 클러스터 전체에 일관된 속도 제한을 적용하는 데 특히 적합하며, 클라이언트가 지정된 속도 제한을 초과하지 못하도록 하는 서비스 수준 계약(SLA)에 따라 API를 제공합니다.

NGINX Plus 상태 공유에는 기본 노드가 필요하지 않으며 이를 활용하지도 않습니다. 모든 노드는 피어이며 전체 메시 토폴로지에서 데이터를 교환합니다. NGINX Plus 상태 공유 클러스터는 세 가지 요구 사항을 충족해야 합니다.

• 모든 클러스터 노드 간의 네트워크 연결
• 동기화된 시계
• 다음 스니펫과 같이 zone_sync 모듈을 활성화하는 모든 노드에서 구성합니다.

스트림 { 리졸버 10.0.0.53 유효=20초; 서버 { 수신 10.0.0.1:9000; zone_sync ; zone_sync_server nginx-cluster.example.com:9000 확인; } }

zone_sync 지시어는 클러스터의 공유 메모리 영역 동기화를 활성화합니다. zone_sync_server 지시어는 클러스터의 다른 NGINX Plus 인스턴스를 식별합니다. NGINX Plus는 DNS 서비스 검색을 지원하므로 호스트 이름으로 클러스터 노드를 식별하고 모든 노드에서 동일한 구성을 만들 수 있습니다. 이는 프로덕션 배포에 필요한 보안 제어 기능이 없는 최소 구성입니다. 자세한 내용은 NGINX Plus R15 발표 및 zone_sync 모듈 에 대한 참조 문서를 확인하세요.

이 구성이 모든 노드에 적용되면 limit_req_zone 지시문에 새 동기화 매개변수를 추가하는 것만으로 클러스터 전체에 속도 제한을 적용할 수 있습니다. 다음 구성에서 NGINX Plus는 클라이언트의 IP 주소를 기반으로 각 클라이언트에 초당 100개 요청의 속도 제한을 적용합니다.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync ; # 클러스터 인식 서버 { listen 80; location / { limit_req zone=per_ip; # 여기에 속도 제한 적용 proxy_pass http://my_backend; } }

또한, 상태 공유 클러스터링 솔루션은 네트워크 복원력을 위한 keepalived 기반 고가용성 솔루션 과 독립적입니다. 따라서 해당 솔루션과 달리 상태 공유 클러스터는 물리적 위치에 걸쳐 존재할 수 있습니다.

클러스터 인식 키-값 저장소

NGINX Plus R13은 기본 NGINX 모듈로 가벼운 메모리 내 키-값 저장소를 도입했습니다. 이 모듈은 NGINX Plus와 함께 제공되어 추가 소프트웨어 구성 요소를 설치하지 않고도 간단한 데이터베이스 저장소를 구성해야 하는 솔루션을 구현할 수 있습니다. 또한 키-값 저장소는 NGINX Plus API 를 통해 제어되므로 REST 인터페이스를 통해 항목을 생성, 수정, 삭제할 수 있습니다.

NGINX Plus 키‑값 저장소의 사용 사례로는 동적 IP 주소 거부 목록 , 동적 대역폭 제한 , 인증 토큰 캐싱 등이 있습니다.

NGINX Plus R16 에서는 키-값 저장소가 이제 클러스터를 인식하므로 클러스터의 모든 노드에서 항목이 동기화됩니다. 즉, NGINX Plus 키-값 저장소를 사용하는 솔루션은 액티브-패시브, 액티브-액티브, 그리고 광범위하게 분산된 모든 종류의 클러스터 환경에 배포될 수 있습니다.

다른 클러스터 인식 기능과 마찬가지로, 이미 상태 공유를 위해 구성된 클러스터에 대해 keyval_zone 지시문에 sync 매개변수를 추가하는 것만으로 키-값 저장소의 동기화를 구성할 수 있습니다( zone_sync 및 zone_sync_server 지시문 사용).

키-값 저장소도 확장되어 키-값 저장소에 추가된 각 키-값 쌍에 대해 시간 초과 값을 설정하는 기능이 추가되었습니다. 이러한 항목은 지정된 시간 초과 기간이 지나면 자동으로 만료되고 키-값 저장소에서 제거됩니다. 동기화된 키‑값 저장소를 구성할 때 시간 초과 매개변수는 필수입니다.

동적 DDoS 보호를 위한 NGINX Plus 키-값 저장소 사용

NGINX Plus의 새로운 클러스터링 기능을 결합하여 DDoS 공격으로부터 보호하는 정교한 솔루션을 구축할 수 있습니다. NGINX Plus 인스턴스 풀이 액티브-액티브 클러스터에 배포되거나 광역 네트워크에 분산된 경우 악성 트래픽이 해당 인스턴스 중 하나에 도착할 수 있습니다. 이 솔루션은 다음과 같이 동기화된 속도 제한과 동기화된 키-값 저장소를 사용하여 DDoS 공격에 동적으로 대응하고 그 영향을 완화합니다.

• 클러스터 인식 속도 제한은 요청을 수신하는 NGINX Plus 노드에 관계 없이 초당 100개가 넘는 요청을 보내는 클라이언트를 포착합니다.
• 클라이언트가 속도 제한을 초과하면 NGINX Plus API 를 호출하여 해당 IP 주소가 "sin bin" 키-값 저장소에 추가됩니다. sin bin은 클러스터 전체에서 동기화됩니다.
• sin bin에 있는 클라이언트의 추가 요청은 어떤 NGINX Plus 노드가 수신하는지에 관계없이 매우 낮은 대역폭 제한의 적용을 받습니다. DDoS 완화가 적용되고 있다는 것을 클라이언트에게 명확하게 알리지 못하기 때문에, 요청을 완전히 거부하는 것보다 대역폭을 제한하는 것이 더 바람직합니다.
• 10분이 지나면 클라이언트는 자동으로 죄함에서 제거됩니다.

다음 구성은 이 동적 DDoS 완화 솔루션의 단순화된 구현을 보여줍니다.

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # 클러스터 인식 속도 제한limit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # 클러스터 인식 "sin bin" with 
# 10분 TTL
keyval $remote_addr $in_sinbin zone=sinbin; # $in_sinbin을 
# 일치하는 클라이언트 IP 주소로 채웁니다.

server {
listen 80;
location / {
if ($in_sinbin) {
set $limit_rate 50; # 불량 클라이언트의 대역폭 제한
}

limit_req zone=per_ip; # 여기에 속도 제한 적용
error_page 429 = @send_to_sinbin; # 과도한 클라이언트가 
# 이 위치로 이동됩니다.
proxy_pass http://my_backend;
}

location @send_to_sinbin {
rewrite ^ /api/3/http/keyvals/sinbin break; # URI를 설정합니다. 
# "sin bin" 키-val
proxy_method POST;
proxy_set_body '{"$remote_addr":"1"}';
proxy_pass http://127.0.0.1:80;
}

location /api/ {
api write=on;
# API에 대한 액세스를 제어하는 지시문
}
}

두 가지 선택이 있는 무작위 로드 밸런싱

애플리케이션 제공 및 API 제공 환경 모두에서 확장형 또는 분산형 부하 분산 계층을 사용하여 클라이언트 요청을 수신하고 이를 공유 애플리케이션 환경으로 전달하는 것이 점점 더 일반화되고 있습니다. 여러 로드 밸런서가 동일한 백엔드 서버 세트에 요청을 전달하는 경우, 실수로 개별 백엔드 서버에 과부하를 일으키지 않는 로드 밸런싱 방법을 사용하는 것이 중요합니다.

활성-활성 구성으로 배포된 NGINX Plus 클러스터 또는 여러 진입점이 있는 분산 환경은 각 로드 밸런서가 백엔드 서버로 전송된 모든 요청을 완전히 알 수 없기 때문에 기존 로드 밸런싱 방법에 어려움을 겪을 수 있는 일반적인 시나리오입니다.

컨테이너화된 클러스터 내부의 부하 분산은 확장된 액티브-액티브 배포와 동일한 특성을 갖습니다. Ingress 리소스의 여러 인스턴스가 있는 복제본 세트에 배포된 Kubernetes Ingress 컨트롤러는 클러스터의 각 서비스를 제공하는 포드에 부하를 효과적으로 분산하는 방법이라는 과제에 직면합니다.

작업 부하 분산은 분산형 부하 분산의 효율성에 큰 영향을 미칩니다. 각 요청이 백엔드 서버에 동일한 부하를 주는 경우, 각 서버가 이전 요청에 얼마나 빨리 응답했는지 측정하는 것은 다음 요청을 어디로 보낼지 결정하는 효과적인 방법입니다. NGINX Plus만의 독점적인 기능은 바로 이러한 작업을 수행하는 최소 시간 부하 분산 방법입니다. 하지만 백엔드 서버의 부하가 가변적인 경우(예를 들어, 읽기와 쓰기 작업이 모두 포함된 경우) 과거 성과는 미래 성과를 나타내는 지표로 사용하기에 적합하지 않습니다.

분산 환경에서 부하를 분산하는 가장 간단한 방법은 백엔드 서버를 무작위로 선택하는 것입니다. 시간이 지남에 따라 부하는 평균화되지만 이는 때때로 개별 서버에 트래픽이 급증할 가능성이 있는 원시적인 접근 방식입니다.

무작위 로드 밸런싱의 간단한 변형으로, 로드 분산을 개선하는 것으로 입증된 방법 중 하나는 무작위로 두 개의 백엔드 서버를 선택한 다음 로드가 가장 낮은 서버로 요청을 보내는 것입니다. 두 개의 무작위 선택을 비교하는 목적은, 내린 결정이 최적이 아니더라도 잘못된 부하 분산 결정을 내리는 것을 방지하는 것입니다. 부하가 큰 백엔드 서버를 피함으로써 각 로드 밸런서는 독립적으로 작동하면서도 개별 백엔드 서버로 트래픽 급증을 보내는 것을 피할 수 있습니다. 결과적으로 이 방법은 무작위 부하 분산의 이점과 계산 효율성을 가지면서 입증된 더 나은 부하 분산을 제공합니다.

NGINX Plus R16은 Random 및 Two Choices Random이라는 두 가지 새로운 부하 분산 방법을 도입했습니다. 후자의 경우, NGINX Plus가 두 개의 선택된 백엔드 중 어느 백엔드가 요청을 수신할지 결정하기 위해 어떤 부하 표시 메트릭을 비교할지 추가로 지정할 수 있습니다. 다음 표에는 사용 가능한 측정 항목이 나열되어 있습니다.

* 모든 시간 기반 메트릭은 NGINX Plus에만 국한됩니다.

다음 스니펫은 random two 지시문( HTTP , Stream )을 사용하여 Two Choices 로드 밸런싱 구성을 사용한 Random의 간단한 예를 보여줍니다.

업스트림 my_backend { zone my_backend 64k; server 10.0.0.1; server 10.0.0.2; server 10.0.0.3; #... random two least_time=last_byte; # 두 개의 무작위 선택지에서 더 빠른 응답 시간을 선택합니다. } server { listen 80; location / { proxy_pass http://my_backend; # 업스트림 그룹으로 부하 분산 } }

두 가지 선택 사항이 있는 무작위 방법은 여러 로드 밸런서가 동일한 백엔드 세트에 요청을 전달하는 분산 환경에만 적합합니다. NGINX Plus가 단일 호스트에 배포되거나 액티브-패시브 배포로 배포되는 경우 사용하지 마세요. 이러한 경우, 단일 로드 밸런서는 모든 요청을 전체적으로 볼 수 있으며 라운드 로빈, 최소 연결 및 최소 시간 방법이 가장 좋은 결과를 제공합니다.

향상된 UDP 부하 분산

NGINX Plus R9는 UDP 트래픽의 프록싱 및 부하 분산 지원을 도입하여 NGINX Plus가 DNS, syslog, NTP, RADIUS와 같은 인기 있는 UDP 애플리케이션을 앞세워 애플리케이션 서버의 높은 가용성과 확장성을 제공할 수 있게 되었습니다. 최초 구현은 서버와의 각 상호작용에 대해 클라이언트로부터 단일 UDP 패킷을 기대하는 UDP 애플리케이션으로 제한되었습니다.

NGINX Plus R16을 사용하면 여러 개의 수신 패킷이 지원되므로 보다 복잡한 UDP 애플리케이션을 프록시하고 부하를 분산할 수 있습니다. 여기에는 OpenVPN, VoIP, 가상 데스크톱 솔루션, DTLS(Datagram Transport Layer Security) 세션이 포함됩니다. 게다가 NGINX Plus는 간단하든 복잡하든 모든 UDP 애플리케이션을 처리하는 속도가 훨씬 빠릅니다.

NGINX Plus는 UDP, TCP, HTTP, HTTP/2 등 가장 인기 있는 4가지 웹 프로토콜의 부하를 동일한 인스턴스에서 동시에 분산하는 유일한 소프트웨어 로드 밸런서입니다.

PROXY 프로토콜 v2 지원

NGINX Plus R16에서는 PROXY 프로토콜 v2(PPv2) 헤더 에 대한 지원이 추가되었으며, 헤더에서 사용자 정의 TLV (유형-길이-값 ) 값을 검사하는 기능이 추가되었습니다.

PROXY 프로토콜은 NGINX Plus 및 Amazon 로드 밸런서와 같은 7계층 프록시가 다른 7계층 프록시 또는 NAT 장치 뒤에 위치한 업스트림 서버로 연결 정보를 전송하는 데 사용됩니다. 소스 IP 주소와 포트와 같은 일부 연결 정보는 프록시가 연결을 릴레이할 때 손실될 수 있고, HTTP 헤더 주입에만 의존하여 이 정보를 전송하는 것이 항상 가능한 것은 아니기 때문에 이는 필요합니다. 이전 버전의 NGINX Plus는 PPv1 헤더를 지원했으며, NGINX Plus R16에서는 PPv2 헤더에 대한 지원이 추가되었습니다.

Amazon Network Load Balancer와 함께 PPv2 사용

PPv2 헤더의 한 가지 사용 사례는 Amazon의 네트워크 로드 밸런서(NLB)에서 릴레이된 연결인데, 이는 로드 밸런서의 개인 IP 주소에서 시작된 것처럼 보일 수 있습니다. NLB는 클라이언트 연결의 실제 소스 IP 주소와 포트를 식별하는 PPv2 헤더를 각 연결에 접두사로 붙입니다. 실제 소스는 $proxy_protocol_addr 변수에서 얻을 수 있으며, realip 모듈을 사용하면 NGINX의 내부 소스 변수를 PPv2 헤더의 값으로 덮어쓸 수 있습니다.

AWS PrivateLink와 함께 PPv2 사용

AWS PrivateLink는 가상 사설 클라우드(VPC)에 안전한 VPN 터널을 만드는 Amazon의 기술입니다. 일반적으로 공급자 서비스(공급자 VPC에서 실행)를 게시하고 하나 이상의 클라이언트 VPC에서 사용할 수 있도록 하는 데 사용됩니다. 공급자 서비스에 대한 연결은 공급자 VPC에서 실행되는 NLB에서 시작됩니다.

많은 경우, Provider Service는 각 연결이 어디에서 시작되었는지 알아야 하지만 PPv2 헤더의 소스 IP 주소는 본질적으로 의미가 없으며 클라이언트 VPC의 내부 라우팅 불가능한 주소에 해당합니다. AWS PrivateLink NLB는 PPv2 TLV 레코드 0xEA를 사용하여 헤더에 소스 VPC ID를 추가합니다.

NGINX Plus는 PPv2 TLV 레코드를 검사하고 $proxy_protocol_tlv_0xEA 변수를 사용하여 AWS PrivateLink 연결에 대한 소스 VPC ID를 추출할 수 있습니다. 이를 통해 AWS PrivateLink 데이터 센터에서 트래픽을 인증, 라우팅 및 제어할 수 있습니다.

NGINX Plus R16의 기타 새로운 기능

OpenID Connect Opaque 세션 토큰

NGINX Plus OpenID Connect 참조 구현이 불투명 세션 토큰을 지원하도록 확장되었습니다. 이 사용 사례에서는 JWT ID 토큰이 클라이언트로 전송되지 않습니다. 대신 NGINX Plus 키‑값 저장소에 저장되고 그 대신 무작위 문자열이 전송됩니다. 클라이언트가 임의의 문자열을 제시하면 이는 JWT와 교환되어 검증됩니다. 이 사용 사례는 프로토타입/실험 수준에서 프로덕션 수준으로 업그레이드되었습니다. 이제 키-값 저장소의 항목에 시간 초과 값을 지정할 수 있으며 클러스터 전체에서 동기화할 수 있습니다.

암호화된 세션 동적 모듈

Encrypted Session 커뮤니티 모듈은 MAC을 사용하는 AES‑256 기반 NGINX 변수에 대한 암호화 및 복호화 지원을 제공합니다. 이제 NGINX Plus 저장소에서 NGINX Plus에 대한 지원되는 동적 모듈 로 사용할 수 있습니다.

NGINX JavaScript 모듈 향상

R16의 NGINX JavaScript 모듈에는 JavaScript 언어 지원 범위에 대한 여러 가지 확장이 포함되어 있습니다. HTTP JavaScript 모듈이 간소화되어 이제 단일 객체 ( r )가 각 요청과 관련된 요청 및 응답 속성에 모두 액세스할 수 있습니다. 이전에는 요청( req )과 응답( res ) 객체가 별도로 있었습니다. 이러한 단순화로 인해 HTTP JavaScript 모듈은 단일 세션( 들 ) 개체를 갖는 Stream JavaScript 모듈과 일관성을 유지할 수 있습니다. 이러한 변경 사항은 이전 버전과 완벽하게 호환됩니다. 즉, 기존 JavaScript 코드는 그대로 계속 작동합니다. 그러나 이러한 단순화의 이점을 활용하고 향후 작성하는 코드에서도 사용하려면 기존 JavaScript 코드를 수정하는 것이 좋습니다.

JavaScript 언어 지원에는 이제 다음이 포함됩니다.

• 문자열 메서드: bytesFrom () , padStart() 및 padEnd()
• 추가 메서드: getrandom() 및 getentropy()
• 이진 리터럴

JavaScript 모듈의 변경 사항 전체 목록은 변경 로그 에 기록되어 있습니다.

새로운 $ssl_preread_protocol 변수

새로운 $ssl_preread_protocol 변수를 사용하면 TCP(스트림) 프록시를 사용하여 트래픽을 전달할 때 SSL/TLS와 다른 프로토콜을 구분할 수 있습니다. 변수에는 클라이언트가 지원하는 가장 높은 SSL/TLS 프로토콜 버전이 포함되어 있습니다. 이것은 (예를 들어) 동일한 포트에서 SSL/TLS와 SSH 서비스를 실행하여 방화벽 제한을 피하려는 경우에 유용합니다.

자세한 내용은 블로그의 동일한 포트에서 SSL 및 비 SSL 프로토콜 실행을 참조하세요.

Kubernetes Ingress 컨트롤러 향상

NGINX Plus는 광범위한 환경에서 트래픽을 관리할 수 있으며, 주요 사용 사례 중 하나는 Kubernetes용 Ingress 로드 밸런서 로 사용하는 것입니다. NGINX는 NGINX Plus를 자동으로 구성하는 Ingress 컨트롤러 솔루션을 개발하며, 이 통합은 모든 NGINX Plus 구독자에게 완벽하게 지원됩니다. (모든 NGINX 오픈 소스 사용자와 NGINX Plus 고객은 GitHub에서 오픈 소스 구현을 찾을 수 있으며, 공식 릴리스는 주기적으로 이루어집니다.)

NGINX Plus R16 개발 중에 Kubernetes용 공식 NGINX Ingress Controller에 여러 가지 중요한 개선 사항이 추가되었습니다.

• Prometheus 지원을 통해 사용자는 NGINX 및 NGINX Plus 메트릭을 Kubernetes의 Prometheus로 직접 내보낼 수 있습니다.
• Helm 차트를 지원하므로 Ingress 컨트롤러의 설치 및 관리가 간소화됩니다.
• gRPC 트래픽에 대한 부하 분산 지원은 gPRC 기반 애플리케이션에 높은 가용성과 확장성을 제공합니다. (1.2.0 릴리스에 추가됨)
• Kubernetes Pod의 활성 상태 검사를 통해 Pod와 네트워크 연결의 오류를 신속하게 감지합니다.
• 다중 테넌트, 병합 가능한 구성을 통해 관심사를 분리할 수 있으므로 팀은 동일한 웹 애플리케이션의 여러 경로를 독립적으로 관리할 수 있으며, 운영 팀은 프런트엔드 리스너와 SSL 구성에 대한 제어권을 유지합니다.
• 경로별 세분화된 JWT 인증을 통해 다양한 애플리케이션에 대한 인증을 더욱 심층적으로 제어할 수 있습니다.
• 구성 템플릿을 직접 관리하면 NGINX 구성에 대한 사용자 정의 변경 사항을 개발하고 테스트하기가 훨씬 쉬워집니다.

NGINX Ingress Controller는 ConfigMaps (NGINX 구성을 내장)를 사용하거나 기본 템플릿을 편집하여 더욱 확장할 수 있으며, 이를 통해 사용자는 Kubernetes에서 실행되는 애플리케이션에 대한 트래픽 관리 정책을 생성할 때 모든 NGINX 기능에 액세스할 수 있습니다.

자세한 내용은 블로그의 Kubernetes 릴리스 1.3.0용 NGINX Ingress Controller 발표를 참조하세요.

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

NGINX Plus R16 에는 추가 클러스터링 기능, 글로벌 속도 제한, 새로운 부하 분산 알고리즘 및 여러 버그 수정이 포함되어 있습니다. NGINX Plus를 사용하고 있다면 가능한 한 빨리 R16으로 업그레이드하는 것을 적극 권장합니다. 여러 가지 수정 사항과 개선 사항을 얻을 수 있으며, 이는 지원 티켓을 제출해야 할 때 NGINX, Inc.에서 도움을 드리는 데 도움이 됩니다.

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

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