블로그 | NGINX

NGINX Plus R12 발표

NGINX-F5-수평-검정-유형-RGB의 일부
오웬 개렛 썸네일
오웬 개렛
2017년 3월 14일 게시

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

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

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

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

추가적인 개선 사항으로는 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 변수를 사용하세요.
  • 최대 연결 대기열 – 대기열 지시문은 NGINX Plus가 오버로드된 경우 업스트림 서버에 대한 연결을 대기열에 추가하도록 지시합니다. R12에서 메모리 및 성능 최적화의 결과로, 이제 queue 지시문은 부하 분산 알고리즘( 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에는 다음과 같은 향상된 기능이 포함되어 있습니다.

  • 스트림 모듈 의 사전 읽기 단계
  • ECMAScript 6 수학 메서드 및 상수
  • endsWith , includes , repeat , startsWith , trim 과 같은 추가 String 메서드
  • 범위

nginScript는 안정적이지만 더 많은 사용 사례와 JavaScript 언어 범위를 지원하기 위한 작업이 계속되고 있습니다. 블로그의 NGINX JavaScript 모듈<.htmla>을 사용하여 각 요청에 JavaScript의 강력함과 편의성을 활용하는 방법에 대해 자세히 알아보세요.

새로운 통계

NGINX Plus의 모니터링 및 계측 기능은 NGINX Plus와 업스트림 애플리케이션의 성능과 동작에 대한 심층적인 통찰력을 제공하는 중요한 부가가치입니다. 통계는 내장된 그래픽 대시보드를 통해 제공될 뿐만 아니라 JSON 형식으로도 제공되어 사용자가 선호하는 모니터링 도구로 내보낼 수 있습니다.

릴리스 12에 대한 업데이트가 포함된 NGINX Plus 라이브 활동 모니터링 대시보드
NGINX Plus R12에 대한 라이브 활동 모니터링 대시보드가 업데이트되었습니다.

NGINX Plus R12에서는 여러 가지 개선 사항이 추가되었습니다. 부하 분산 서버의 성능(응답 시간)에 대한 보다 자세한 정보, TCP 및 UDP 서비스의 작동에 대한 통찰력, 문제를 식별하고 NGINX Plus를 조정하여 성능을 최적화하는 데 도움이 되는 다양한 내부 데이터가 추가되었습니다.

NGINX Plus R12의 새로운 통계는 다음과 같습니다.

  • 업스트림 서버 응답 시간 – NGINX Plus R11 및 이전 버전에서는 최소 시간 부하 분산 알고리즘을 사용한 경우에만 업스트림 서버의 응답 시간이 계산되었습니다. NGINX Plus R12부터 모든 알고리즘에 대한 응답 시간이 측정되어 JSON 데이터와 내장 대시보드에 모두 보고됩니다.
  • 그래픽 대시보드의 TCP/UDP 업스트림에 대한 응답 코드 – TCP/UDP 부하 분산을 위한 스트림 모듈은 연결이 어떻게 닫혔는지 식별하기 위해 가상 상태 코드를 생성합니다.200 성공이라는 뜻이에요502 "업스트림을 사용할 수 없음" 등을 의미하며 이를 $status 변수에 보고합니다. NGINX Plus R12는 HTTP 가상 서버에 대해 이미 제공된 것과 같은 TCP 및 UDP 가상 서버의 응답 코드 수를 표시하는 일련의 열을 대시보드에 추가했습니다. 가상 상태 코드는 기존 로그 분석 도구와 통합하기 위해 기록될 수도 있습니다.
  • NGINX Plus 버전 정보 – 문제 해결을 돕기 위해 JSON 데이터는 이제 NGINX Plus 릴리스 번호를 nginx_build (예: nginx-plus-r12 )로 보고하고 NGINX 오픈 소스 버전 번호를 nginx_version (예:1.11.10 ). 대시보드에서는 두 값이 모두 기본 탭의 왼쪽 상단 상자에 표시됩니다.

  • 업스트림 호스트 이름 – JSON 데이터에서 서버 필드는 IP 주소와 포트를 통해 업스트림 그룹의 서버를 식별합니다. 새로운 이름 필드는 업스트림 구성 블록의 서버 지시문에 대한 첫 번째 매개변수를 보고합니다. 이는 도메인 이름이나 UNIX 도메인 소켓 경로일 수 있으며 IP 주소와 포트일 수도 있습니다. 대시보드에서 업스트림 및 TCP/UDP 업스트림 탭의 가장 왼쪽에 있는 이름 열은 이제 서버 필드(NGINX Plus R11 및 이전 버전에서 보고됨) 대신 이름 필드의 값을 보고합니다.

    새로운 메트릭을 사용하면 DNS 이름, 특히 여러 IP 주소로 확인되는 이름을 사용하여 정의하는 경우 JSON 데이터와 대시보드를 업스트림 서버와 더 쉽게 연관시킬 수 있습니다.

  • 확장 상태 데이터의 공유 메모리 영역 활용 – 공유 메모리 영역은 고정된 크기로 구성되며, 너무 크지 않은 크기(메모리가 할당되지만 사용되지 않음)나 너무 작지 않은 크기(메모리가 고갈되고 캐시된 항목이 삭제됨)를 선택하는 것이 어려울 수 있습니다.

    메트릭의 새로운 계측 기능은 각 공유 영역의 메모리 사용에 대한 자세한 내부 보고서를 제공하므로 메모리 사용과 NGINX 기술 지원을 모니터링하여 NGINX 구성을 최적화하는 데 대한 보다 정보에 입각한 조언을 제공할 수 있습니다.

  • NGINX Plus 액세스 로그에서 JSON 호환 이스케이프 – 일부 최신 로그 분석 도구는 JSON 형식의 로그 파일을 효율적으로 수집할 수 있으며, 형식이 지정되지 않은 로그 파일보다 더 쉽게 통찰력을 얻을 수 있습니다. 표준 NGINX Plus log_format 지시문에서 JSON 템플릿을 정의할 수 있으며, 지시문에 대한 새로운 선택적 이스케이프 매개변수는 JSON 호환 이스케이프를 적용하여 로그 줄이 올바르게 형식화되도록 합니다.

자세한 내용은 라이브 활동 모니터링을 참조하세요.

향상된 캐싱

NGINX Plus R12는 NGINX Plus 캐싱 엔진을 크게 향상시킵니다.

업데이트하는 동안 오래된 콘텐츠 제공

NGINX Plus R12는 RFC 5861 에 정의된 Cache-Control 확장, stale-while-revalidate 및 stale-if-error에 대한 지원을 추가합니다. 이제 NGINX Plus를 구성하여 이러한 Cache-Control 확장을 존중하고 클라이언트 요청에 지연 시간을 추가하지 않고 백그라운드에서 새로 고침하는 동안 캐시에서 만료된 리소스를 계속 제공할 수 있습니다. 마찬가지로 NGINX Plus는 업스트림 서버를 사용할 수 없는 경우 캐시에서 만료된 리소스를 제공할 수 있습니다. 이는 마이크로서비스 애플리케이션에서 회로 차단기 패턴을 구현하는 기술입니다.

Cache-Control 헤더를 무시하도록 구성되지 않은 경우 NGINX Plus는 이 예와 같이 RFC 5861 호환 Cache-Control 헤더를 반환하는 원본 서버의 오래된 타이머를 존중합니다.

캐시 제어: 최대 수명=3600, 재검증 중 오래된 시간=120, 오류 발생 시 오래된 시간=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; # 업데이트 시 오래된 콘텐츠 제공 proxy_cache_use_stale updating ; # 또한 업데이트를 트리거하는 첫 번째 요청을 차단하지 않고 # 백그라운드에서 업데이트 수행 proxy_cache_background_update on ; proxy_pass http://my_upstream; } }

proxy_cache_use_stale 업데이트 지시문은 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; # 10메가바이트를 넘는 바이트 범위 요청에 대한 캐시 우회 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는 이를 바로 정상 상태로 간주하고 해당 서버로 트래픽을 즉시 보냈습니다. health_check 지시문( HTTP 또는 TCP/UDP )에 새로운 필수 매개변수를 포함하는 경우, 새 서버는 NGINX Plus에서 트래픽을 보내기 전에 구성된 상태 검사를 통과해야 합니다. 느린 시작 기능과 결합하면 새로운 매개변수는 새로운 서버가 전체 트래픽 공유를 처리하라는 요청을 받기 전에 데이터베이스에 연결하고 "워밍업"할 수 있는 시간을 더 많이 제공합니다.

upstream my_upstream { zone my_upstream 64k; server backend1.example.com slow_start=30s ; } server { location / { proxy_pass http://my_upstream; # 트래픽을 수신하기 전에 새 서버가 상태 검사를 통과해야 함 health_check essential ; } }

여기에는 health_check 지시문에 대한 필수 매개변수와 server 지시문( HTTP 또는 TCP/UDP )에 대한 slow_start 매개변수가 모두 포함됩니다. API나 DNS 인터페이스를 사용하여 업스트림 그룹에 추가된 서버는 비정상으로 표시되고 상태 검사를 통과할 때까지 트래픽을 수신하지 못합니다. 상태 검사를 통과한 시점에서 30초 동안 점점 증가하는 양의 트래픽을 수신하기 시작합니다.

제로 구성 UDP 상태 확인

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

업스트림 udp_app { 서버 backend1.example.com:1234; 서버 backend2.example.com:1234; } 서버 { 수신 1234 udp; proxy_pass udp_app; # 기본 UDP 상태 검사 health_check udp ; }

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

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

$ssl_client_verify 변수에는 이제 실패한 클라이언트 인증 이벤트에 대한 추가 정보가 포함됩니다. 여기에는 "폐지됨" 및 "만료됨" 인증서와 같은 이유가 포함됩니다.

$ssl_client_i_dn 및 $ssl_client_s_dn 변수의 형식이 RFC를 준수하도록 변경되었습니다.2253 그리고4514 . 자세한 내용은 동작 변화를 참조하세요.

향상된 JWT 검증

NGINX Plus R10은 OAuth 2.0 및 OpenID Connect 사용 사례에 대한 기본 JSON 웹 토큰(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가 애플리케이션을 제공하고 확장하는 데 어떻게 도움이 될 수 있는지 직접 확인하세요.

F5 NGINX에 대한 더 많은 블로그 게시물 읽기 ›

"이 블로그 게시물에는 더 이상 사용할 수 없거나 더 이상 지원되지 않는 제품이 참조될 수 있습니다. 사용 가능한 F5 NGINX 제품과 솔루션에 대한 최신 정보를 보려면 NGINX 제품군을 살펴보세요. NGINX는 이제 F5의 일부가 되었습니다. 이전의 모든 NGINX.com 링크는 F5.com의 유사한 NGINX 콘텐츠로 리디렉션됩니다."