NGINX Plus R16 출시 발표

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

[ngx_snippet name=’table-style-blog’]
NGINX Plus 릴리스 16(R16)이 출시되었음을 기쁜 마음으로 알려드립니다. 이번 릴리스는 NGINX의 기술 비전을 실현하는 데 있어 가장 중요한 릴리스 중 하나입니다. R16부터 NGINX Plus는 모든 애플리케이션을 위한 단일 탄력적 인그레스 및 이그레스 계층으로 작동합니다. 즉, 로드 밸런서, API 게이트웨이 및 WAF의 기능을 모든 클라우드 환경에서 사용할 수 있는 단일 소프트웨어 패키지로 통합할 수 있습니다.

오늘날 저희가 대화를 나누는 많은 기업은 이러한 구성 요소를 모두 갖추고 있지만, 각 구성 요소를 서로 다른 공급업체로부터 도입한 경우가 많습니다. 이로 인해 운영팀이 각각의 개별 솔루션을 따로 관리해야 하므로 비용과 복잡성이 증가합니다. 또한 홉이 하나씩 추가될 때마다 지연 시간과 장애 지점이 늘어나 성능과 안정성도 저하됩니다.

NGINX Plus R16의 새로운 기능을 활용하면 인프라를 통합하고 간소화하는 동시에 레거시 및 최신 애플리케이션 모두를 위한 탄력적인 인그레스/이그레스 계층을 설계하는 방향으로 나아갈 수 있습니다. NGINX Plus R16에는 새로운 클러스터링 기능, 향상된 UDP 부하 분산, DDoS 완화 기능이 포함되어 있어 고가의 F5 BIG-IP 하드웨어 및 기타 부하 분산 인프라를 더욱 완벽하게 대체할 수 있습니다. 새롭게 지원되는 전역 속도 제한 기능 덕분에 NGINX Plus는 다양한 API 게이트웨이 솔루션을 대체할 수 있는 경량 옵션이기도 합니다. 마지막으로, 새롭게 지원되는 Random with Two Choices 부하 분산을 통해 NGINX Plus는 Kubernetes와 같은 확장형 또는 분산 환경에서 마이크로서비스 트래픽을 부하 분산하는 데 이상적인 선택이 됩니다.

NGINX Plus R16의 새로운 기능 요약

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

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

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

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

NGINX Plus R16 및 NGINX에 관한 모든 내용을 NGINX Conf 2018에서 자세히 알아보세요. 모든 새로운 기능을 심층적으로 살펴볼 수 있도록 전용 세션과 데모를 마련하고 전문가도 배치할 예정입니다.

중요한 동작 변경 사항

• 통합 NGINX Plus API로 대체되어 더 이상 사용되지 않는 Upstream Conf 및 Status API가 제거되었습니다. 2017년 8월, NGINX Plus R13에서는 업스트림 그룹의 동적 재구성과 메트릭 모니터링을 위한 완전히 새로운 NGINX Plus API를 도입하여 이전에 이러한 기능을 구현했던 Upstream 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 및 동적 모듈의 기술 사양을 참조하세요.
• The NGINX New Relic 플러그인이 업데이트되었습니다. 이제 새로운 NGINX Plus API를 사용하며 오픈 소스 프로젝트로 제공됩니다. 업데이트된 플러그인은 R13 이후의 모든 NGINX Plus 버전에서 작동하지만, 더 이상 NGINX, Inc.에서 지원하거나 유지 관리하지 않습니다.

새로운 기능 상세 정보

클러스터 인식 속도 제한

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

처음으로 동기화된 기능은 sticky‑learn 세션 지속성이었습니다. NGINX Plus R16에서는 상태 공유가 요청 속도 제한 기능으로 확장되었습니다. 이제 클러스터로 배포된 NGINX Plus는 요청이 클러스터의 어느 구성원 노드에 도착하든 관계없이 수신 요청에 일관된 속도 제한을 적용할 수 있습니다. 일반적으로 전역 속도 제한이라고 하는 이 방식은 클러스터 전체에 일관된 속도 제한을 적용하며, 특히 API 게이트웨이 사용 사례에서 중요합니다. 이를 통해 클라이언트가 지정된 속도 제한을 초과하지 않도록 하는 서비스 수준 계약(SLA)에 따라 API를 제공할 수 있습니다.

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

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

stream {    resolver 10.0.0.53 valid=20s;

    server {
        listen 10.0.0.1:9000;
        zone_sync;
        zone_sync_server nginx-cluster.example.com:9000 resolve;
    }
}

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

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

limit_req_zone $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware
server {
    listen 80;
    location / {
        limit_req zone=per_ip; # Apply rate limit here
        proxy_pass http://my_backend;
    }
}

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

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

NGINX Plus R13에서는 네이티브 NGINX 모듈로 경량 인메모리 키-값 저장소를 도입했습니다. 이 모듈은 NGINX Plus에 기본으로 포함되어 있어 추가 소프트웨어 구성 요소를 설치하지 않고도 간단한 데이터베이스 저장소가 필요한 솔루션을 구성할 수 있습니다. 또한 키-값 저장소는 NGINX Plus API를 통해 제어되므로 REST 인터페이스를 통해 항목을 생성, 수정 및 삭제할 수 있습니다.

NGINX Plus 키-값 저장소의 사용 사례로는 동적 IP 주소 차단 목록 관리, 동적 대역폭 제한, 그리고 인증 토큰 캐싱이 있습니다.

NGINX Plus R16부터 키-값 저장소가 클러스터를 인식하여 항목이 클러스터의 모든 노드에서 동기화됩니다. 따라서 NGINX Plus 키-값 저장소를 사용하는 솔루션을 액티브-패시브, 액티브-액티브 및 광범위한 분산 환경을 비롯한 모든 종류의 클러스터 환경에 배포할 수 있습니다.

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

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

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

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

• 클러스터를 인식하는 요청 속도 제한 기능은 요청을 수신하는 NGINX Plus 노드와 관계없이 초당 100개가 넘는 요청을 보내는 클라이언트를 감지합니다.
• 클라이언트가 속도 제한을 초과하면 NGINX Plus API를 호출하여 해당 클라이언트의 IP 주소를 “sin bin” 키-값 저장소에 추가합니다. sin bin은 클러스터 전체에서 동기화됩니다.
• 차단 목록에 포함된 클라이언트의 후속 요청은 어느 NGINX Plus 노드에서 수신하든 매우 낮은 대역폭 제한이 적용됩니다. 요청을 완전히 거부하면 DDoS 완화 조치가 시행 중임을 클라이언트에 명확히 알리게 되므로, 대역폭을 제한하는 편이 더 바람직합니다.
• 10분이 지나면 클라이언트는 자동으로 제한 대상 목록에서 제거됩니다.

다음 구성은 이 동적 DDoS 완화 솔루션을 간소화하여 구현한 예를 보여줍니다.

limit_req_zone   $remote_addr zone=per_ip:1M rate=100r/s sync; # Cluster-aware rate limitlimit_req_status 429;

keyval_zone zone=sinbin:1M timeout=600 sync; # Cluster-aware "sin bin" with 
                                             # 10-minute TTL
keyval $remote_addr $in_sinbin zone=sinbin;  # Populate $in_sinbin with 
                                             # matched client IP addresses

server {
    listen 80;
    location / {
        if ($in_sinbin) {
            set $limit_rate 50; # Restrict bandwidth of bad clients
        }

        limit_req zone=per_ip;            # Apply the rate limit here
        error_page 429 = @send_to_sinbin; # Excessive clients are moved to 
                                          # this location
        proxy_pass http://my_backend;
    }

    location @send_to_sinbin {
        rewrite ^ /api/3/http/keyvals/sinbin break; # Set the URI of the 
                                                    # "sin bin" key-val
        proxy_method POST;
        proxy_set_body '{"$remote_addr":"1"}';
        proxy_pass http://127.0.0.1:80;
    }

    location /api/ {
        api write=on;
        # directives to control access to the API
    }
}

두 가지 선택지를 사용하는 무작위 부하 분산

애플리케이션 및 API 제공 환경 모두에서 확장형 또는 분산형 부하 분산 계층을 사용하여 클라이언트 요청을 수신하고 공유 애플리케이션 환경으로 전달하는 방식이 점점 보편화되고 있습니다. 여러 로드 밸런서가 동일한 백엔드 서버 집합으로 요청을 전달하는 경우, 개별 백엔드 서버에 의도치 않게 과부하가 발생하지 않도록 적절한 부하 분산 방식을 사용하는 것이 중요합니다.

액티브-액티브 구성으로 배포된 NGINX Plus 클러스터나 진입점이 여러 개인 분산 환경은 각 로드 밸런서가 백엔드 서버로 전송된 모든 요청을 완전히 파악할 수 없기 때문에 기존 로드 밸런싱 방식으로 처리하기 어려운 대표적인 시나리오입니다.

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

두 개 중 무작위 선택 부하 분산의 이점을 누리는 클러스터 토폴로지

워크로드의 변동성은 분산 로드 밸런싱의 효과에 큰 영향을 미칩니다. 각 요청이 백엔드 서버에 동일한 부하를 주는 경우, 각 서버가 이전 요청에 얼마나 빠르게 응답했는지를 측정하면 다음 요청을 보낼 위치를 효과적으로 결정할 수 있습니다. NGINX Plus에서만 제공되는 최소 시간 로드 밸런싱 방식이 바로 이러한 원리로 작동합니다. 하지만 백엔드 서버의 부하가 가변적인 경우(예: 읽기 작업과 쓰기 작업이 모두 포함되는 경우)에는 과거 성능만으로 향후 성능을 제대로 예측하기 어렵습니다.

분산 환경에서 부하를 분산하는 가장 간단한 방법은 백엔드 서버를 무작위로 선택하는 것입니다. 시간이 지나면 부하가 고르게 분산되지만, 이 방식은 다소 단순하여 때때로 특정 서버에 트래픽이 급증할 가능성이 있습니다.

무작위 부하 분산을 간단히 변형한 방법이면서 부하 분산을 개선하는 것으로 입증된 방법은 두 개의 백엔드 서버를 무작위로 선택한 다음 부하가 더 낮은 서버로 요청을 보내는 것입니다. 두 개의 무작위 선택지를 비교하는 목적은 최적의 결정을 내리지는 못하더라도 잘못된 부하 분산 결정을 피하는 데 있습니다. 부하가 더 높은 백엔드 서버를 피함으로써 각 부하 분산 장치는 독립적으로 작동하면서도 개별 백엔드 서버에 트래픽이 급증하는 상황을 방지할 수 있습니다. 따라서 이 방법은 무작위 부하 분산의 장점과 계산 효율성을 유지하면서도 부하를 확실히 더 고르게 분산합니다.

NGINX Plus R16에서는 새로운 두 가지 부하 분산 방식인 Random과 Random with Two Choices를 도입했습니다. 후자의 경우 선택된 두 백엔드 중 어느 쪽이 요청을 받을지 결정할 때 NGINX Plus에서 비교할 부하 지표를 추가로 지정할 수 있습니다. 다음 표에는 사용 가능한 지표가 나와 있습니다.

* 모든 시간 기반 메트릭은 NGINX Plus에서만 제공됩니다

다음 코드 조각은 두 가지 무작위 선택(Random with Two Choices) 부하 분산 구성을 보여 주는 간단한 예로, random two 지시어를 사용합니다(HTTP, Stream).

upstream 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; # Choose the quicker response time from two random choices
}

server {
    listen 80;
    location / {
        proxy_pass http://my_backend; # Load balance to upstream group
    }
}

두 가지 무작위 선택(Random with Two Choices) 방식은 여러 로드 밸런서가 동일한 백엔드 집합으로 요청을 전달하는 분산 환경에만 적합합니다. NGINX Plus가 단일 호스트에 배포되거나 액티브-패시브 방식으로 배포된 경우에는 이 방식을 사용하지 마십시오. 이러한 경우 단일 로드 밸런서가 모든 요청을 전체적으로 파악할 수 있으므로 라운드 로빈(Round Robin), 최소 연결(Least Connections), 최소 시간(Least Time) 방식이 최상의 결과를 제공합니다.

향상된 UDP 부하 분산

NGINX Plus R9에서는 UDP 트래픽 프록시 및 부하 분산을 지원하기 시작하여 NGINX Plus를 DNS, syslog, NTP, RADIUS와 같은 널리 사용되는 UDP 애플리케이션 앞에 배치함으로써 애플리케이션 서버의 고가용성과 확장성을 확보할 수 있게 되었습니다. 초기 구현은 서버와 상호 작용할 때마다 클라이언트에서 단일 UDP 패킷을 전송하는 UDP 애플리케이션으로 제한되었습니다.

NGINX Plus R16에서는 여러 수신 패킷을 지원하므로 더 복잡한 UDP 애플리케이션도 프록시 및 부하 분산할 수 있습니다. 여기에는 OpenVPN, VoIP, 가상 데스크톱 솔루션 및 데이터그램 전송 계층 보안(DTLS) 세션이 포함됩니다. 또한 단순하거나 복잡한 모든 UDP 애플리케이션을 NGINX Plus에서 처리하는 속도도 크게 향상되었습니다.

NGINX Plus는 가장 널리 사용되는 네 가지 웹 프로토콜인 UDP, TCP, HTTP 및 HTTP/2를 동일한 인스턴스에서 동시에 부하 분산할 수 있는 유일한 소프트웨어 로드 밸런서입니다.

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의 Network Load Balancer(NLB)를 통해 중계되는 연결입니다. 이러한 연결은 로드 밸런서의 프라이빗 IP 주소에서 시작된 것처럼 보일 수 있습니다. NLB는 각 연결 앞에 클라이언트 연결의 실제 소스 IP 주소와 포트를 식별하는 PPv2 헤더를 추가합니다. 실제 소스는 $proxy_protocol_addr 변수에서 가져올 수 있으며, realip 모듈을 사용하여 NGINX의 내부 소스 변수를 덮어쓸 수 있습니다. 이때 PPv2 헤더의 값이 사용됩니다.

AWS PrivateLink에서 PPv2 사용

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

대부분의 경우 공급자 서비스는 각 연결의 출처를 알아야 하지만, PPv2 헤더의 소스 IP 주소는 클라이언트 VPC 내부의 라우팅 불가능한 주소에 해당하므로 사실상 의미가 없습니다. AWS PrivateLink NLB는 PPv2 TLV 레코드 소스 VPC ID를 사용하여 헤더에 0xEA를 추가합니다.

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

NGINX Plus R16의 기타 새로운 기능

OpenID Connect 불투명 세션 토큰

The NGINX Plus OpenID Connect 참조 구현은 불투명 세션 토큰을 지원하도록 확장되었습니다. 이 사용 사례에서는 JWT ID 토큰이 클라이언트로 전송되지 않습니다. 대신 NGINX Plus 키-값 저장소에 저장되고, 그 자리에 임의의 문자열이 전송됩니다. 클라이언트가 임의의 문자열을 제시하면 해당 문자열을 JWT로 교환한 후 검증합니다. 이제 키-값 저장소의 항목에 제한 시간 값을 설정하고 클러스터 전체에서 동기화할 수 있게 됨에 따라, 이 사용 사례는 프로토타입/실험 단계에서 프로덕션 수준으로 향상되었습니다.

암호화된 세션 동적 모듈

The Encrypted Session 커뮤니티 모듈은 MAC이 적용된 AES‑256을 기반으로 NGINX 변수의 암호화 및 복호화를 지원합니다. 이제 NGINX Plus 저장소에서 공식 지원되는 NGINX Plus용 동적 모듈로 제공됩니다.

NGINX JavaScript 모듈 개선 사항

R16의 NGINX JavaScript 모듈에는 JavaScript 언어 지원 범위를 확장하는 여러 기능이 포함되어 있습니다. HTTP JavaScript 모듈이 간소화되어 이제 단일 객체인 (r)이 각 요청과 관련된 요청 및 응답 속성에 모두 액세스합니다. 이전에는 요청 객체(req)와 응답 객체(res)가 별도로 존재했습니다. 이러한 간소화를 통해 HTTP JavaScript 모듈은 단일 세션 객체(s)를 사용하는 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 Controller 개선 사항

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

NGINX Plus는 Kubernetes 트래픽의 SSL을 종료하고, 라우팅하고, 부하를 분산할 수 있습니다

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는 ConfigMap을 사용하여 NGINX 구성을 포함하거나 기본 템플릿을 편집하는 방식으로 추가 확장할 수 있으므로, 사용자는 Kubernetes에서 실행되는 애플리케이션의 트래픽 관리 정책을 만들 때 NGINX의 모든 기능을 활용할 수 있습니다.

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

NGINX Plus 업그레이드 또는 체험

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

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

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

작성자 소개

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

Liam Crilly의 다른 블로그 게시물