블로그 | NGINX

NGINX 1.18 및 1.19 소개

NGINX-F5-수평-검정-유형-RGB의 일부
리비 메렌 썸네일
리비 메렌
2020년 5월 26일 게시

오늘 우리는 인터넷에서 가장 인기 있는 웹 서버인 NGINX 오픈 소스의 최신 버전인 NGINX 1.19를 출시합니다. 이번 릴리스는 지난달 NGINX 1.18 안정 버전 출시에 이어 NGINX 1.19 개발 버전 출시를 알리는 신호입니다.

이 블로그에서는 NGINX 버전 관리 체계에 대해 논의하고, NGINX 1.17 개발 주기 동안 발생한 일을 되돌아보고, NGINX 1.19에서 어떤 일이 일어날지 기대해 보겠습니다.

NGINX 버전 관리 설명

NGINX에서는 NGINX 오픈 소스 코드 저장소에 mainlinestable 이라는 두 개의 브랜치를 유지 관리합니다.

  • 메인라인 은 최신 기능과 버그 수정이 추가되는 활발한 개발 브랜치입니다. 버전 번호의 두 번째 부분은 홀수로 표시됩니다. 예를 들어 1입니다.19.0.
  • Stable은 심각도가 높은 버그에 대한 수정 사항을 받지만, 새로운 기능으로 업데이트되지 않습니다. 버전 번호의 두 번째 부분은 짝수로 표시됩니다(예: 1).18.0.

"안정적"이라는 것이 의미하는 것

NGINX 오픈 소스의 경우 "안정적"이라는 단어는 소프트웨어 품질이 아닌 기능과 업데이트 빈도를 의미합니다. 안정적인 브랜치는 수명 주기 동안 새로운 기능을 추가하지 않으며 일반적으로 중요한 버그 수정을 위해 1~2개의 업데이트만 받습니다.

안정적인 지점은 1년의 수명 주기를 갖습니다. 매년 4월, 우리는 현재의 안정적인 브랜치를 폐기하고 그 이후로는 더 이상 버그 수정을 하지 않습니다. 이렇게 하면 두 가지 이벤트가 발생합니다.

  1. 현재의 메인라인 브랜치는 다음 안정적인 브랜치를 만들기 위해 포크되었습니다. 새로운 안정된 브랜치는 이전 해에 메인라인 브랜치에 적용된 모든 버그 수정, 기능 및 기타 변경 사항을 상속받습니다. 지난달, NGINX 1.17.10이 포크되어 NGINX 1.18.0이 탄생했습니다. 새로운 메인라인 브랜치가 출시될 때까지 "안정적"은 현재 메인라인 브랜치와 동일하며 며칠 전의 새로운 기능이 포함될 수 있습니다(이 상태는 오늘 NGINX 1.18 브랜치에서 종료됩니다).
  2. 메인라인 브랜치는 "버전 범프"를 받습니다. 즉, 버전 번호의 두 번째 부분이 다음 홀수로 증가합니다. 메인라인 브랜치에서는 지속적인 개발이 진행되고 있으며, 4~6주마다 메인라인에서 새로운 릴리스가 빌드됩니다. 오늘은 NGINX 1.19.0으로 NGINX 1.19 메인라인의 첫 번째 릴리스를 기념합니다.
NGINX 오픈 소스 브랜치를 위한 연례 "버전 범프"의 2020년 에디션

NGINX Plus는 어떤 브랜치를 사용하나요?

NGINX의 상용 버전인 NGINX Plus 는 별도의 비공개 코드 저장소에서 관리됩니다. 이는 항상 NGINX 메인라인의 최신 버전을 기반으로 하며, NGINX Plus의 추가적인 독점 기능 및 성능과 통합되었습니다. 이 글을 쓰는 시점에서 최신 버전은 NGINX 1.17.10을 기반으로 하는 NGINX Plus R21 입니다.

어떤 지점을 이용해야 하나요?

일반적으로 메인라인 브랜치를 사용하는 것이 좋습니다. 여기에 모든 새로운 기능, 성능 개선 및 향상이 포함됩니다. 우리는 메인라인 브랜치를 적극적으로 테스트하고 QA하며, NGINX Plus 빌드의 소스이므로 프로덕션 사용에 완벽하게 적합합니다.

새로운 기능과 버그 수정을 위해 메인라인 브랜치를 모니터링하는 데 드는 오버헤드가 걱정된다면, 안정적인 브랜치를 사용하면 1년에 한 번만 새로운 기능을 검토하고 버그 수정을 드물게 수행할 수 있습니다.

NGINX 1.17 리뷰, AKA NGINX 1.18 안정된 브랜치의 새로운 기능

NGINX 1.17 개발 주기에서는 몇 가지 새로운 기능과 향상된 기능이 도입되었습니다. 여기에는 ngx_http_limit_req_modulengx_http_limit_conn_module 에서 각각 요청 속도 및 연결 제한 기능이 향상되고, ngx_http_core_module 에 인증 지연 지시어가 추가되었으며, grpc_pass 지시어에 대한 변수 지원과 PROXY 프로토콜로 서버 주소 및 포트를 캡처하는 변수가 도입되었습니다. 가장 중요한 개선 사항을 더 자세히 살펴보기 전에 NGINX 1.17을 숫자로 살펴보겠습니다.

  • 10개의 메인라인 릴리스
  • 37개 버그 수정
  • 11개의 새로운 기능

HTTP 요청 속도 및 연결 제한 향상

limit_ratelimit_rate_after 지시어는 NGINX가 요청에 응답하는 대역폭(초당 바이트 수)을 제어합니다. NGINX 1.17.0 이상에서는 속도를 설정하는 매개변수를 변수로 지정할 수 있어 요청의 속성에 따라 동적으로 제어할 수 있습니다. 예를 들어 동적 대역폭 제어를 참조하세요.

NGINX 1.17.1에서는 limit_req_dry_run 지시어를 사용하여 요청 속도 제한을 위한 드라이런 모드가 추가되었습니다. 드라이런 모드에서 NGINX Plus는 속도 제한을 적용하지 않지만 공유 메모리 영역에서 과도한 요청 속도를 추적하고 구성된 제한을 초과하는 모든 요청에 대해 오류 로그에 항목을 기록합니다. 이를 통해 사이트의 트래픽 패턴에 적합한 요금 한도를 보다 쉽게 결정할 수 있습니다. 자세한 내용은 Dry‑Run 모드에서 속도 제한 테스트를 참조하세요.

드라이런 모드를 더욱 유용하게 만들기 위해 NGINX 1.17.6은 $limit_req_status 변수를 추가했습니다. 이 변수는 액세스 로그 항목에 포함되어 요청 처리에 대한 속도 제한의 효과를 포착할 수 있습니다. 특히, 요청이 다음과 같은지 여부입니다.

  • 통과(지연없이 백엔드 서버로 전달됨) [ 통과 ]
  • 지연되었습니다 [ DELAYED ]
  • 거부되었습니다 [ 거부됨 ]
  • 드라이런 모드에서 지연된 것으로 계산되었습니다. [ DELAYED_DRY_RUN ]
  • 드라이런 모드에서 거부된 것으로 계산되었습니다. [ REJECTED_DRY_RUN ]

NGINX 1.17.6은 또한 limit_conn_dry_run 지시어를 사용하여 연결 제한을 위한 드라이런 모드와 연결 요청 시 캡처하는 $limit_conn_status 변수를 추가했습니다.

  • 통과(백엔드 서버로 전달됨) [ 통과 ]
  • 거부되었습니다 [ 거부됨 ]
  • 드라이런 모드에서 거부된 것으로 계산되었습니다. [ REJECTED_DRY_RUN ]

샘플 구성은 연결 제한 향상을 참조하세요.

새로운 auth_delay 지시어

auth_delay 지시문(NGINX 1.17.10에 추가됨)은 상태 코드와 함께 승인되지 않은 요청의 지연된 처리를 가능하게 합니다. 401(승인되지 않은) 클라이언트에게 반환되었습니다. 이를 통해 액세스 요청을 처리할 때 타이밍 공격을 방지할 수 있습니다. 사용 가능한 인증 방법은 다음과 같습니다.

grpc_pass 지시문에 대한 변수 지원

NGINX 1.13.10에는 NGINX가 gRPC 요청을 전달하는 서버를 지정하는 grpc_pass 지시어를 포함하여 gRPC 트래픽에 대한 기본 지원이 추가되었습니다. NGINX 1.17.8에서는 업스트림 서버 그룹 간 검색을 지원하기 위해 서버 식별자에 도메인 이름을 포함하는 기능을 추가했습니다. 도메인 이름을 찾을 수 없으면 NGINX는 리졸버를 사용하여 서버 주소를 식별합니다.

추가 PROXY 프로토콜 변수

PROXY 프로토콜은 4계층 프록시가 요청을 처리하는 다음 프록시나 로드 밸런서에 원본 클라이언트 정보를 제공할 수 있도록 합니다. 이는 클라이언트의 IP 주소를 알아야 하는 사용 사례에 중요합니다. 예를 들어, least_conn 지시어를 사용하여 각 클라이언트에 대한 연결 수를 제한하려는 경우입니다. 이 데이터는 $proxy_protocol_addr 변수( HTTP | Stream )에서 사용할 수 있습니다.

여러 개의 레이어 4 프록시가 배포된 경우 NGINX에서 클라이언트가 원래 연결했던 프록시 서버의 IP 주소와 포트를 아는 것이 중요할 수 있습니다. PROXY 프로토콜 메타데이터에는 이 정보가 포함되어 있으며 NGINX 1.17.6은 이를 캡처하기 위해 다음 변수를 HTTP 및 스트림 모듈에 추가했습니다.

메모: 변수는 PROXY 프로토콜 처리를 활성화하기 위해 listen 지시문에 proxy_protocol 매개변수를 포함한 경우에만 채워집니다.

proxy_upload_rateproxy_download_rate 지시문에 변수 지원이 추가되었습니다.

Stream 모듈의 proxy_upload_rateproxy_download_rate 지시문은 NGINX가 클라이언트 또는 프록시 서버에서 각각 데이터를 읽는 속도를 제어합니다. NGINX 1.17.0 이상에서는 지시문이 가변 매개변수를 허용하므로 조건에 맞는 속도를 정의할 수 있습니다.

ioctl(FIONREAD) 시스템 호출에 대한 지원이 추가되었습니다.

Linux 시스템에서 ioctl() 시스템 호출은 호스트 장치에서 읽을 수 있는 바이트 수를 제공합니다. NGINX 1.17.5에서는 NGINX가 읽고 처리할 수 있는 것보다 더 빠르게 데이터가 소켓 버퍼에 추가되는 경우 루핑을 방지하기 위해 ioctl(FIONREAD) 가 추가되었습니다. 커널이 사용 가능한 바이트 수를 제공하지 않으면 ioctl(FIONREAD)를 사용하여 채워진 버퍼에서 이 정보를 가져올 수 있습니다.

Perl internal_redirect 함수에서 명명된 위치 지정

NGINX 1.17.2 이상에서 NGINX Perl 모듈internal_redirect 함수에 대한 uri 매개변수는 이스케이프된 URI나 명명된 위치가 될 수 있습니다.

NGINX 1.19에 추가되는 기능

NGINX 1.19 메인라인의 첫 번째 릴리스가 곧 출시됩니다. NGINX 1.19.0에는 클라이언트와 웹사이트, 애플리케이션, API 간 통신을 위한 전송 프로토콜의 차기 주요 업데이트인 QUIC (HTTP/3)에 대한 지원이 포함되어 있습니다.

NGINX Plus의 향상된 기능을 사용해보고 싶으시다면 오늘 무료 30일 체험판을 시작하시거나 저희에게 문의하여 사용 사례에 대해 논의해보세요 .


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