NGINX Unit 의 새롭지만 익숙한 기능

fallback 라우팅 옵션은 NGINX try_files 지시문과 유사하며, upstream 오브젝트는 전용 백엔드 서버 그룹에서 요청의 라운드 로빈 로드 밸런싱 을 도입하는 등 NGINX Unit 의 기능 중 두 가지는 NGINX 오픈 소스 및 NGINX Plus 팬들에게 친숙한 기능입니다.

많은 분들과 마찬가지로 NGINX Unit팀도 코로나19 팬데믹 기간 동안 집에 웅크리고 앉아 있었습니다. 그럼에도 불구하고 버전을 출시하며 꾸준한 릴리스 주기를 유지할 수 있었습니다.

목차

1. fallback 라우팅 옵션
2. upstream을 통한 라운드 로빈 로드 밸런싱
3. NGINX Unit 기타 개발
4. NGINX Unit 다음 단계

1. fallback 라우팅 옵션

첫 번째 기능은 어떤 이유로 정적 파일을 제공할 수 없는 경우에 대한 대체 라우팅 작업을 정의할 수 있는 기능입니다. 이 로직을 단순한 파일 시스템 누락 이상으로 확장하는 방법을 쉽게 상상할 수 있지만, 이를 첫 번째 사용 사례로 다루기로 결정했습니다. 따라서 fallback action의 초기 구현은 NGINX Unit 1.11.0에 도입된 share action과 짝을 이룹니다. 어떻게 구현되었는지 살펴보겠습니다.

새로운 대체 옵션은 어떤 이유로든 share 디렉터리에서 요청된 파일을 제공할 수 없을 때 NGINX Unit이 수행하는 작업을 정의합니다. 다음 action 객체를 생각해 보세요.

{

    "action": {

        "share": "/data/www/",

        "fallback": {

            "pass": "applications/php_blog"

        }

    }

}

이 작업이 수행되면 NGINX Unit 은 /data/www/ 디렉터리의 파일로 요청을 제공하려고 시도합니다. 그러나 요청된 파일을 사용할 수 없는 경우(찾을 수 없음, 권한 부족 등) NGINX Unit 은 fallback 작업을 수행합니다. 여기서는 요청을 PHP 블로그 애플리케이션으로 전달하는 전달 작업을 수행하지만, proxy 또는 다른 share도 구성할 수 있습니다(후자에 대해서는 아래에서 자세히 설명합니다).

이는 사실상 NGINX Unit 이 기존 정적 파일을 서비스하는 동시에 다른 모든 요청을 애플리케이션으로 전달하므로 추가 라우팅 단계의 필요성이 줄어든다는 의미입니다. 구성이 적으면 실수할 가능성도 줄어듭니다.

또한, 여러 share 작업을 중첩하여 정교한 요청 핸들러를 만드는 것을 막는 것은 없습니다.

{

    "action": {

        "share": "/data/www/",

        "fallback": {

            "share": "/data/cache/",

            "fallback": {

                "pass": "applications/php_blog"

            }

        }

    }

}

이 스니펫은 이전 코드 조각에서와 동일한 애플리케이션으로 요청이 전달되기 전에 fallback 체인에 또 다른 파일 위치인 /data/cache/ 를 추가함으로써 이전 스니펫을 기반으로 구축됩니다. 이 초기 구현에서 fallback은 share와만 사용할 수 있으며, pass 또는 proxy의 대안으로 지정할 수 없었습니다.

이 구성 옵션의 로직은 단순해 보일 수 있지만, 이를 통해 이전에는 추가 소프트웨어 계층이 필요했던 많은 강력한 애플리케이션을 NGINX Unit 이 단독으로 실행할 수 있습니다. 예를 들어, 새로운 옵션을 사용하여 구성 오버헤드를 크게 줄이도록 WordPress, Bugzilla, NextCloud에 대한 사용법을 이미 업데이트 했습니다.

2. upstream을 통한 라운드 로빈 로드 밸런싱

이번에 소개하는 또 다른 주요 기능은 upstream 객체입니다. 이 객체는 구성 섹션 내에서 listener, applications, routes 및 setting 객체의 피어로 존재합니다. NGINX에 익숙하지 않은 분들을 위해 설명하자면, upstream은 관리 및 모니터링을 간소화하기 위해 여러 서버를 단일 논리적 엔티티로 그룹화하는 추상화입니다. 일반적으로 upstream 내에서 워크로드를 분산하고, 다양한 역할을 할당하고, 개별 서버의 속성을 미세 조정할 수 있지만 외부에서 볼 때는 단일 엔티티처럼 보이고 작동합니다.

NGINX Unit 에서 upstream은 다음과 같이 구성됩니다:

{
    "listeners": {
        "*:80": {
            "pass": "upstreams/rr-lb"
        }
    },

    "upstreams": {
        "rr-lb": {
            "servers": {
                "192.168.0.100:8080": { },
                "192.168.0.101:8080": {
                    "weight": 2
                }
            }
        }
    }
}

애플리케이션이나 경로와 마찬가지로 upstream은 listener와 routes 객체 모두에서 전달 작업의 대상이 될 수 있습니다. 각 upstream의 정의에는 이름(rr-lb on line 9)과 명명된 upstream의 각 서버에 대한 구성 객체를 포함하는 필수 서버 객체가 포함되며, 서버의 IP 주소와 포트 및 선택적으로 다른 특성을 지정합니다. 초기 구현에서 지원되는 유일한 옵션은 로드 밸런싱에 사용되는 서버의 정숫값 가중치입니다.

NGINX Unit 은 가중치에 따라 upstream 오브젝트의 서버 간에 요청을 라운드 로빈 방식으로 자동 분배합니다. 위의 예에서 두 번째 서버는 첫 번째 서버보다 약 2배 많은 요청을 수신합니다(기본 가중치가 1이라는 것을 유추할 수 있습니다). 다시 한번 말씀드리지만, 라운드 로빈은 여러 가지 로드 밸런싱 방법 중 하나일 뿐이며 향후 다른 방법과 결합될 것입니다.

upstream이 도입되면서 NGINX Unit 의 기능 범위가 크게 향상되었습니다. 원래는 앱 관리를 위한 견고한 독립형 빌딩 블록이었지만, 전체 app-delivery infrastructure의 다재다능하고 풍부한 기능을 갖춘 구성 요소로 꾸준히 성장하고 있습니다. 애플리케이션 엔드포인트, 리버스 프록시, 로드 밸런서, 정적 캐시 서버 또는 기타 다양한 방식으로 사용할 수 있습니다.

3. NGINX Unit 기타 개발

이제 새로운 로드맵을 통해 좋아하는 기능이 곧 구현될지 여부를 확인하고, 사내 이니셔티브에 대해 평가하고 의견을 제시할 수 있습니다. GitHub의 리포지토리에 새로운 이슈를 개설하고 개선에 대한 아이디어를 자유롭게 공유하세요. 언젠가 로드맵에 반영될지도 모릅니다!

컨테이너화 이니셔티브가 어떻게 되었는지 궁금하신 분들을 위해 말씀드리자면, 이 이니셔티브는 여전히 살아있습니다. NGINX Unit .14.0 에서는 NGINX Unit 데몬이 권한 없는 사용자로 실행될 때 격리된 애플리케이션의 사용자 및 그룹 설정을 변경할 수 있는 기능을 도입했습니다(권장 방법은 루트로 실행하는 것임을 기억하세요). 물론 이것이 끝이 아닙니다. 앞으로 몇 달 안에 더 많은 기능이 추가될 예정입니다.

4. NGINX Unit 다음 단계

앞으로의 계획에 대해 말씀드리자면, NGINX Unit 을 좀 더 견고하게 만들기 위해 IPC 또는 메모리 버퍼 관리와 같은 몇 가지 내부 개선 작업을 진행하고 있습니다. 사용자 측면에서는 로드 밸런싱 개선, 라우팅 중 사용자 지정 HTTP 응답 상태 코드를 반환하는 기능, 지정된 파일 시스템 디렉토리 내에서 실행 중인 앱을 제한하는 rootfs 옵션 등이 현재 진행 중입니다. 대체로 NGINX Unit은 여전히 바쁜 공사장이므로 안전모를 챙기는 것을 잊지 마세요!

NGINX Plus를 직접 사용해 보시려면 30일 무료 평가판을 신청하거나 NGINX STORE에 연락하여 논의하십시오.