NGINX 1.18 및 1.19 소개

오늘 NGINX Open Source의 최신 버전인 NGINX 1.19를 출시합니다. NGINX Open Source는 인터넷에서 가장 널리 사용되는 웹 서버입니다. 이번 릴리스는 지난달 NGINX 1.18 안정화 브랜치가 출시된 데 이어 NGINX 1.19 개발 브랜치의 시작을 알립니다.

이 블로그에서는 NGINX 버전 관리 체계를 살펴보고, NGINX 1.17 개발 주기 동안 있었던 일을 되짚어보며, NGINX 1.19에서 무엇이 새롭게 제공될지 알아봅니다.

NGINX 버전 관리 체계 알아보기

NGINX에서는 NGINX Open Source 코드 리포지토리에 다음과 같은 두 개의 브랜치를 유지 관리합니다: mainline 및 stable:

• Mainline은 최신 기능과 버그 수정 사항이 추가되는 활성 개발 브랜치입니다. 버전 번호의 두 번째 부분에 홀수를 사용하여 표시합니다. 예: 1.19.0.
• Stable은 심각도가 높은 버그에 대한 수정 사항은 적용되지만 새로운 기능으로 업데이트되지는 않습니다. 버전 번호의 두 번째 부분에 짝수를 사용하여 표시합니다. 예: 1.18.0.

‘안정 버전’이라는 것의 의미

NGINX Open Source에서 “stable”이라는 단어는 소프트웨어 품질이 아니라 기능 및 업데이트 빈도를 의미합니다. stable 브랜치에는 수명 주기 동안 새로운 기능이 추가되지 않으며, 일반적으로 심각한 버그 수정을 위한 업데이트만 한두 차례 제공됩니다.

안정화 브랜치의 수명 주기는 1년입니다. 매년 4월에 현재 안정화 브랜치의 지원을 종료하며, 이후에는 더 이상 버그 수정이 이루어지지 않습니다. 이에 따라 다음 두 가지가 진행됩니다:

1. 현재 메인라인 브랜치를 분기하여 다음 안정 브랜치를 만듭니다. 새 안정 브랜치는 지난 1년 동안 메인라인 브랜치에 반영된 모든 버그 수정, 기능 및 기타 변경 사항을 이어받습니다. 지난달에는 NGINX 1.17.10을 분기하여 NGINX 1.18.0을 만들었습니다. 새 메인라인 브랜치가 출시되기 전까지는 ‘안정’ 브랜치가 현재 메인라인 브랜치와 동일하며, 불과 며칠 전에 추가된 새 기능이 포함될 수도 있습니다(NGINX 1.18 브랜치의 경우 이러한 상태는 오늘 종료됩니다).
2. 메인라인 브랜치의 ‘버전이 상향’됩니다. 즉, 버전 번호의 두 번째 부분이 다음 홀수로 증가합니다. 지속적인 개발은 메인라인 브랜치에서 계속되며, 4~6주마다 메인라인을 기반으로 새 릴리스가 빌드됩니다. 오늘 NGINX 1.19.0이 출시되면서 NGINX 1.19 메인라인의 첫 번째 릴리스가 이루어졌습니다.

NGINX Open Source 브랜치의 연례 ‘버전 상향’ 2020년판

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

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

어떤 브랜치를 사용해야 하나요?

일반적으로 메인라인 브랜치를 사용하는 것이 좋습니다. 모든 새로운 기능, 성능 개선 사항 및 향상된 기능은 이 브랜치에 커밋됩니다. 메인라인 브랜치는 적극적으로 테스트하고 품질을 검증하며, NGINX Plus 빌드의 소스이므로 프로덕션 환경에서 사용하기에 충분히 적합합니다.

새로운 기능과 버그 수정 사항을 확인하기 위해 메인라인 브랜치를 지속적으로 모니터링하는 데 드는 부담이 우려된다면, 안정 브랜치를 사용하여 새로운 기능은 1년에 한 번만 검토하고 버그 수정 사항은 가끔씩만 확인하면 됩니다.

NGINX 1.17 돌아보기, 즉 NGINX 1.18 안정 브랜치의 새로운 기능

NGINX 1.17 개발 주기에는 몇 가지 새로운 기능과 개선 사항이 도입되었습니다. 여기에는 ngx_http_limit_req_module 및 ngx_http_limit_conn_module의 요청 속도 제한과 연결 제한 개선, ngx_http_core_module에 인증 지연 지시어 추가, grpc_pass 지시어의 변수 지원 도입, PROXY 프로토콜을 통해 서버 주소와 포트를 캡처하는 변수 도입 등이 포함됩니다. 주요 개선 사항을 자세히 살펴보기에 앞서, 수치로 보는 NGINX 1.17은 다음과 같습니다.

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

HTTP 요청 속도 및 연결 제한 기능 개선

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

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

드라이런 모드를 더욱 유용하게 활용할 수 있도록 NGINX 1.17.6에는 $limit_req_status 변수가 추가되었습니다. 이 변수를 액세스 로그 항목에 포함하면 요청 처리에 대한 속도 제한의 영향을 기록할 수 있습니다. 구체적으로는 요청이 다음 중 어디에 해당하는지 확인할 수 있습니다.

• 통과(지연 없이 백엔드 서버로 전달됨) [PASSED]
• 지연됨 [DELAYED]
• 거부됨 [REJECTED]
• 드라이런 모드에서 지연된 것으로 집계됨 [DELAYED_DRY_RUN]
• 드라이런 모드에서 거부된 것으로 집계됨 [REJECTED_DRY_RUN]

NGINX 1.17.6에서는 연결 제한을 위한 드라이런 모드도 limit_conn_dry_run 지시어와 함께 추가했으며, 연결 요청이 다음 상태일 때 이를 기록하기 위한 $limit_conn_status 변수도 추가했습니다:

• 통과(백엔드 서버로 전달됨) [PASSED]
• 거부됨 [REJECTED]
• 드라이런 모드에서 거부된 것으로 집계됨 [REJECTED_DRY_RUN]

구성 예시는 연결 제한 기능 개선을 참조하세요.

새로운 auth_delay 지시어

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

• 비밀번호(ngx_http_auth_basic_module 사용 시)
• 하위 요청의 결과(ngx_http_auth_request_module에서 사용 가능)
• JWT의 존재 여부(ngx_http_auth_jwt_module에서 사용 가능)

Variables Support for the grpc_pass 지시문의 변수 지원

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

추가 PROXY 프로토콜 변수

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

여러 계층 4 프록시를 배포한 경우, 클라이언트가 처음 연결한 프록시 서버의 IP 주소와 포트를 NGINX가 파악하는 것이 중요할 수 있습니다. PROXY 프로토콜 메타데이터에는 이 정보가 포함되며, NGINX 1.17.6에서는 이 정보를 캡처하기 위해 HTTP 및 Stream 모듈에 다음 변수가 추가되었습니다:

• $proxy_protocol_server_addr (HTTP | 스트림)
• $proxy_protocol_server_port (HTTP | 스트림)

참고: PROXY 프로토콜 처리를 활성화하려면 proxy_protocol 매개변수도 listen 지시문에 포함해야만 변수에 값이 설정됩니다.

변수 지원이 추가된 proxy_upload_rate 및 proxy_download_rate 지시어

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

Added Support for the ioctl(FIONREAD) 시스템 호출 지원 추가

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

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

NGINX 1.17.2 이상에서는 NGINX uri 모듈의 internal_redirect 함수에 전달되는 Perl 모듈 매개변수로 이스케이프된 URI 또는 명명된 위치를 사용할 수 있습니다.

NGINX 1.19의 새로운 기능

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

NGINX Plus의 향상된 기능을 사용해 보려면 지금 30일 무료 평가판을 시작하거나 사용 사례에 대해 논의하려면 문의해 주세요.

---