마이크로서비스 아키텍처 의 가장 큰 장점 중 하나는 서비스 인스턴스를 얼마나 빠르고 쉽게 확장할 수 있는가입니다. 여러 서비스 인스턴스가 있는 경우 로드 밸런서와 사용 가능한 서비스 인스턴스 세트의 변경 사항을 빠르게 알릴 수 있는 방법이 필요합니다. 이를 서비스 검색 이라고 합니다 . NGINX Plus는 서비스 검색 시스템과 통합하기 위한 두 가지 옵션, 즉 NGINX Plus API 와 도메인 이름 시스템(DNS) 재확인을 제공합니다 . 이 블로그 게시물은 후자에 초점을 맞춥니다.
가상 머신(VM)이나 컨테이너를 추가하거나 제거하여 서비스 인스턴스(이 블로그 게시물에서는 백엔드 라고 부름 )를 확장할 때 로드 밸런서의 구성을 변경하여 백엔드 세트의 모든 변경 사항을 반영해야 합니다. 확장은 애플리케이션에 따라 하루에 여러 번, 한 시간에 한 번 또는 분에 한 번 발생할 수 있습니다. 구성 변경 빈도가 높으므로 자동화해야 하며 이를 달성하는 방법 중 하나는 DNS를 통한 서비스 검색입니다.
오늘날 애플리케이션을 실행하는 많은 플랫폼(예: Kubernetes) 은 DNS를 사용하여 서비스 검색을 지원합니다. 이 블로그 게시물의 끝부분에는 DNS를 사용하는 인기 있는 플랫폼 및 서비스 검색 도구와 NGINX Plus를 통합하는 방법을 설명하는 기사에 대한 링크가 제공됩니다.
주요 DNS 기능에 대한 간략한 검토
DNS를 통한 서비스 검색을 구성하는 방법을 설명하기에 앞서, 특히 관련성이 높거나 편리한 DNS 프로토콜의 몇 가지 기능을 간략히 살펴보겠습니다.
수명(Time‑to‑Live)
DNS 클라이언트가 오래된 정보를 사용하지 못하도록 DNS 레코드에는 클라이언트가 레코드를 유효하다고 간주할 수 있는 기간을 정의하는 TTL(수명) 필드가 포함됩니다. DNS 표준을 준수하기 위해 클라이언트는 레코드가 TTL을 초과하면 DNS 서버에 업데이트를 쿼리해야 합니다. NGINX Plus는 기본적으로 TTL을 존중하지만 레코드의 "수명"에 대한 보다 세부적인 제어도 제공합니다. NGINX Plus를 구성하여 TTL을 무시하고 대신 지정된 빈도로 레코드를 업데이트할 수 있습니다. (NGINX Open Source가 TTL을 처리하는 방법은 이 게시물의 후반부에서 설명합니다.)
TCP를 통한 DNS
기본적으로 DNS 클라이언트와 서버는 UDP를 통해 통신하지만 도메인 이름이 많은 수의 백엔드 IP 주소로 확인되는 경우 전체 응답이 512바이트로 제한된 단일 UDP 데이터그램에 맞지 않을 수 있습니다. UDP 대신 TCP를 사용하면 이 문제가 해결됩니다. 전체 레코드 세트가 하나의 데이터그램에 맞지 않으면 서버는 응답에 잘림 플래그를 설정하여 클라이언트에게 모든 레코드를 가져오기 위해 TCP로 전환하라고 알립니다. TCP를 통한 DNS는 NGINX 버전 1.9.11 이상 및 NGINX Plus R9 이상에서 지원됩니다. 자세한 내용은 블로그에서 NGINX 및 NGINX Plus로 DNS 트래픽 로드 밸런싱을 참조하세요.
SRV기록
DNS는 호스트 이름을 IP 주소로 변환하지만 포트 번호는 어떨까요? Docker 컨테이너의 부하 분산과 같이 잘 알려진 포트 번호에 의존할 수 없는 경우가 있습니다. 포트 번호는 대신 동적으로 할당되기 때문입니다. DNS에는 포트 번호와 몇 가지 다른 매개변수를 포함하는 Service( SRV) 레코드 라는 특수한 유형의 레코드가 있습니다. R9 이상에서 NGINX Plus는 레코드를 지원 SRV하므로 레코드에서 포트 정보를 추출할 수 있습니다.
편집자 - NGINX Plus R9의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R9 발표를 참조하세요.
NGINX 및 NGINX Plus를 위한 DNS를 사용한 서비스 검색 방법
이제 NGINX와 NGINX Plus에서 DNS를 사용하여 서비스 검색을 수행하는 다섯 가지 방법을 정교함의 순서대로 보여드리겠습니다. 처음 세 가지는 NGINX와 NGINX Plus에서 모두 사용할 수 있으며, 마지막 두 가지는 NGINX Plus에서만 사용할 수 있습니다.
이 서비스 검색 방법 조사에서, 우리는 IP 주소가 10.0.0.2인 example.com 영역에 대한 권한 있는 이름 서버가 있다고 가정합니다. 유틸리티 의 다음 출력에서 볼 수 있듯이, 도메인 이름 backends.example.comnslookup 에 해당하는 백엔드 서버가 세 개 있습니다 . 논의할 처음 네 가지 방법에서는 NGINX와 NGINX Plus가 ADNS에서 표준 레코드를 요청합니다. 마지막 방법에서는 NGINX Plus가 SRV대신 레코드를 요청합니다.
$ nslookup backends.example.com 10.0.0.2Server: 10.0.0.2
Address: 10.0.0.2#53
Name: backends.example.com
Address: 10.0.0.11
Name: backends.example.com
Address: 10.0.0.10
Name: backends.example.com
Address: 10.0.0.12
NGINX를 사용하여 서비스 검색을 위한 DNS 사용
NGINX 오픈 소스 에서 DNS를 사용하는 세 가지 방법을 보여드리면서 시작하겠습니다 (위에서 언급했듯이 NGINX Plus에서도 사용할 수 있습니다).
proxy_pass지침 에서 도메인 이름 사용
업스트림 서버(백엔드) 그룹을 정의하는 가장 간단한 방법은 지시문의 매개변수로 도메인 이름을 지정하는 것입니다 proxy_pass.
server { location / {
proxy_pass http://backends.example.com:8080;
}
}NGINX가 시작되거나 구성을 다시 로드할 때 DNS 서버에 쿼리하여 backends.example.com을 확인 합니다. DNS 서버는 위에서 설명한 세 개의 백엔드 목록을 반환하고 NGINX는 기본 라운드 로빈 알고리즘을 사용하여 요청을 로드 밸런싱합니다. NGINX는 OS 구성 파일 /etc/resolv.conf 에서 DNS 서버를 선택합니다 .
이 방법은 서비스 검색을 수행하는 가장 유연성이 낮은 방법이며 다음과 같은 추가적인 단점이 있습니다.
- 도메인 이름을 확인할 수 없으면 NGINX가 시작되지 않거나 구성을 다시 로드하지 못합니다.
- NGINX는 다음 재시작 또는 구성 재로드까지 DNS 레코드를 캐시하고, 레코드의 TTL 값은 무시합니다.
- 다른 부하 분산 알고리즘을 지정할 수 없으며, server다음 섹션에서 설명할 지시문의 매개변수로 정의된 수동 상태 검사나 다른 기능을 구성할 수도 없습니다.
업스트림 서버 그룹에서 도메인 이름 사용
NGINX가 제공하는 로드 밸런싱 옵션을 활용하려면 upstream구성 블록에서 업스트림 서버 그룹을 정의할 수 있습니다. 그러나 IP 주소로 개별 서버를 식별하는 대신 도메인 이름을 지시문의 매개변수로 사용합니다 server.
첫 번째 방법 과 마찬가지로 backends.example.com은 NGINX가 구성을 시작하거나 다시 로드할 때 세 개의 백엔드 서버로 해결됩니다. 하지만 이제 우리는 더 정교한 부하 분산 알고리즘인 Least Connections를 정의 하고 매개변수를 사용하여 수동 max_fails상태 검사를 활성화하여 NGINX가 세 개의 연속 요청이 실패하면 서버를 다운으로 표시하도록 지정할 수 있습니다.
upstream backends { least_conn;
server backends.example.com:8080 max_fails=3;
}
server {
location / {
proxy_pass http://backends;
}
}이 방법을 사용하면 부하 분산 알고리즘을 선택하고 상태 검사를 구성할 수 있지만 시작, 다시 로드, TTL과 관련하여 이전 방법과 동일한 단점이 있습니다.
변수에 도메인 이름 설정
이 방법은 첫 번째 방법 의 변형 이지만 NGINX가 도메인 이름을 다시 확인하는 빈도를 제어할 수 있습니다.
resolver 10.0.0.2 valid=10s;
server {
location / {
set $backend_servers backends.example.com;
proxy_pass http://$backend_servers:8080;
}
}지시문에서 변수를 사용하여 도메인 이름을 지정하면 proxy_passNGINX는 TTL이 만료되면 도메인 이름을 다시 확인합니다. 지시문을 포함하여 이름 서버를 명시적으로 지정해야 합니다 (NGINX는 처음 두 방법에서처럼 /etc/resolv.confresolver 를 참조하지 않습니다 ). 지시문 에 매개변수를 포함하면 NGINX가 TTL을 무시하고 대신 지정된 빈도로 이름을 다시 확인하도록 할 수 있습니다. 여기서는 NGINX가 10초마다 이름을 다시 확인하도록 합니다.validresolver
참고: TCP/UDP 부하 분산의 경우 지시문에서 변수를 사용하는 이 방법은 proxy_passNGINX 1.11.3 이상 및 NGINX Plus R10 이상에서 지원됩니다.
이 방법은 첫 번째 방법의 두 가지 단점을 제거합니다. 즉, 도메인 이름을 확인할 수 없을 때 NGINX 시작 또는 다시 로드 작업이 실패하지 않고 NGINX가 이름을 다시 확인하는 빈도를 제어할 수 있습니다. 그러나 업스트림 그룹을 사용하지 않기 때문에 지시문에 부하 분산 알고리즘이나 다른 매개변수를 지정할 수 없습니다 ( 두 번째 방법server 에서 한 것처럼 ).
NGINX Plus를 사용하여 서비스 검색을 위한 DNS 사용
이제 NGINX Plus에서만 제공되는 DNS 서비스 검색을 위한 두 가지 방법을 살펴보겠습니다.
NGINX Plus로 A 레코드 사용
NGINX Plus를 사용하면 원하는 빈도로 DNS 이름을 다시 확인할 수 있으며 , 위에서 설명한 처음 세 가지 방법의 단점은 없습니다. 이 기능을 사용하려면 다음이 필요합니다.
- resolver이전 방법과 마찬가지로 이름 서버를 지정하는 지침을 포함합니다 .
- 공유 메모리 영역을 할당하려면 구성 블록 zone에 지침을 포함하세요 .upstream
- 도메인 이름을 사용하는 지시문 resolve에 매개변수를 추가합니다 .server
다음 예를 고려해 보세요.
resolver 10.0.0.2 valid=10s;
upstream backends {
zone backends 64k;
server backends.example.com:8080 resolve;
}
server {
location / {
proxy_pass http://backends;
}
}기본적으로 NGINX Plus는 TTL을 준수하여 레코드가 만료되면 이름을 다시 확인합니다. 대신 NGINX Plus가 지정된 빈도로 이름을 다시 확인하려면 지시문 valid에 매개변수를 포함합니다 resolver.
스니펫에서 NGINX Plus는 10초마다 10.0.0.2의 이름 서버에 쿼리하여 backends.example.com을502 확인합니다. 이름을 확인할 수 없는 경우 NGINX Plus는 시작 시, 구성을 다시 로드할 때 또는 런타임 중에 실패하지 않습니다. 대신 클라이언트는 표준 오류 페이지를 봅니다 .
NGINX Plus로 SRV 레코드 사용
NGINX Plus R9 이상은 DNS SRV레코드를 지원합니다. 이를 통해 NGINX Plus는 이름 서버에서 IP 주소뿐만 아니라 포트 번호, 가중치 및 우선순위도 가져올 수 있습니다. 이는 서비스의 포트 번호가 종종 동적으로 할당되는 마이크로서비스 환경에서 중요합니다.
편집자 - NGINX Plus R9의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R9 발표를 참조하세요.
SRV레코드는 서비스 이름, 서비스와의 통신을 위한 프로토콜, 도메인 이름의 세 가지로 정의됩니다. 이름 서버를 쿼리할 때 세 가지를 모두 제공해야 합니다. 10.0.0.2 이름 서버에는 서비스 이름 http , 프로토콜 tcp , 도메인 이름 backends.example.comSRV 의 세 가지 레코드가 있으며 , 이는 유틸리티의 이 출력에서 볼 수 있습니다 .nslookup
$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2Server: 10.0.0.2
Address: 10.0.0.2#53
_http._tcp.backends.example.com service = 0 2 8090 backend-0.example.com.
_http._tcp.backends.example.com service = 0 1 8091 backend-1.example.com.
_http._tcp.backends.example.com service = 10 1 8092 backend-2.example.com.
각 레코드에서 호스트 이름을 쿼리하면 SRVIP 주소를 얻습니다.
$ nslookup backend-0.example.com 10.0.0.2...
Name: backend-0.example.com
Address: 10.0.0.10
$ nslookup backend-1.example.com 10.0.0.2
...
Name: backend-1.example.com
Address: 10.0.0.11
$ nslookup backend-2.example.com 10.0.0.2
...
Name: backend-2.example.com
Address: 10.0.0.12
SRV첫 번째 명령에서 반환된 첫 번째 레코드의 정보를 더 자세히 살펴보겠습니다 nslookup.
_http._tcp.backends.example.com service = 0 2 8090 backend-0.example.com.
- _http._tcp. – 레코드의 이름과 프로토콜 . NGINX Plus 구성 파일(아래 참조)의 지시문 에 대한 매개변수 SRV값으로 지정합니다 .serviceserver
- 0 – 우선순위. 값이 낮을수록 우선순위가 높습니다. NGINX Plus는 우선순위가 가장 높은 서버를 기본 서버로 지정하고 나머지 서버는 백업 서버로 지정합니다. 이 레코드는 모든 레코드 중에서 가장 낮은 값(가장 높은 우선순위)을 가지므로 NGINX Plus는 해당 백엔드를 기본 서버로 지정합니다.
- 2 – 가중치. NGINX Plus는 백엔드를 업스트림 그룹에 추가할 때 백엔드의 가중치를 이 값으로 설정합니다( 지시문 weight의 매개변수 와 동일 server).
- 8090 – 포트 번호. NGINX Plus는 백엔드를 업스트림 그룹에 추가하면서 백엔드의 포트를 이 값으로 설정합니다.
- backend‑0.example.com – 백엔드 서버의 호스트 이름. NGINX Plus는 이 이름을 확인하고 해당 백엔드를 업스트림 그룹에 추가합니다. 이름이 여러 레코드로 확인되면 NGINX Plus는 여러 서버를 추가합니다.
이제 NGINX Plus를 구성하여 레코드를 사용하는 방법을 살펴보겠습니다 SRV. 샘플 구성 파일은 다음과 같습니다.
resolver 10.0.0.2 valid=10s;
upstream backends {
zone backends 64k;
server backends.example.com service=_http._tcp resolve;
}
server {
location / {
proxy_pass http://backends;
}
}service지시문 에 대한 매개변수를 사용하여 , 우리는 해결하고자 하는 레코드 server의 이름과 프로토콜을 지정합니다 . 우리의 경우, 각각 _http 와 _tcp 입니다 . 매개변수와 포트를 지정하지 않는다는 사실을 제외하면 , 이전 섹션 의 구성 예와 동일하게 보입니다 .SRVservice
이 섹션의 첫 번째 명령에서 반환된 값을 기준으로 nslookupNGINX Plus는 세 개의 백엔드 서버로 구성됩니다.
- 10.0.0.10 – 포트 8090, 가중치 2를 갖는 기본 서버.
- 10.0.0.11 – 포트 8091, 가중치 1을 가진 기본 서버.
- 10.0.0.12 – 포트 8092, 가중치 1을 가진 백업 서버.
NGINX Plus에 대한 라이브 활동 모니터링을 구성하면 내장 대시보드에서 해당 백엔드를 볼 수 있습니다.
요청이 지정된 가중치에 따라 어떻게 분배되는지 주목하세요. 10.0.0.11:8091 서버(가중치 1)는 요청의 1/3을 받는 반면, 10.0.0.10:8090 서버(가중치 2)는 2/3을 받습니다. 백업 서버인 10.0.0.12:8092 서버는 다른 두 서버가 다운되지 않는 한 요청을 받지 않습니다.
주의사항
NGINX Plus에서 서비스 검색을 위해 DNS를 사용할 때 염두에 두어야 할 몇 가지 사항이 있습니다.
- DNS 서버는 고가용성이어야 하거나 백업 서버가 있어야 합니다. DNS 서버를 사용할 수 없게 되면 NGINX Plus는 업데이트를 받지 못합니다. 기존 백엔드는 구성에 유지되고(다시 시작하거나 구성을 다시 로드하지 않는 한) 해당 레코드의 TTL 값은 무시합니다.
- 지시문 으로 여러 개의 네임 서버를 지정할 수 있으며 resolver, 그 중 하나가 다운되면 NGINX Plus는 다른 네임 서버를 시도합니다.
- 소개에서 언급했듯이 NGINX Plus에서 서비스 검색을 위한 DNS 대신 사용할 수 있는 NGINX Plus API를 사용하면 간단한 HTTP 요청을 통해 업스트림 그룹에 서버를 추가하거나 제거할 수 있습니다.
예시
DNS를 사용하는 서비스 검색 플랫폼과 NGINX 및 NGINX Plus를 통합하는 방법에 대한 전체 예제를 살펴보려면 다음 블로그 게시물을 확인하세요.
- SRVConsul의 DNS 레코드를 사용한 NGINX Plus의 서비스 검색
- NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱
향후 새로운 통합 옵션에 대한 자세한 내용이 공개되면 이 목록을 업데이트하겠습니다.
결론
NGINX Plus에서 완벽하게 제공되는 DNS를 통한 서비스 검색은 마이크로서비스 환경에서 로드 밸런서의 구성을 업데이트하는 간단한 방법을 제공합니다. SRV릴리스 9 이상의 레코드 지원은 NGINX Plus를 더욱 강력하게 만들어 NGINX Plus가 IP 주소뿐만 아니라 백엔드의 포트 번호도 얻을 수 있게 해줍니다.
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
마이크로서비스 아키텍처 의 가장 큰 장점 중 하나는 서비스 인스턴스를 얼마나 빠르고 쉽게 확장할 수 있는가입니다. 여러 서비스 인스턴스가 있는 경우 로드 밸런서와 사용 가능한 서비스 인스턴스 세트의 변경 사항을 빠르게 알릴 수 있는 방법이 필요합니다. 이를 서비스 검색 이라고 합니다 . NGINX Plus는 서비스 검색 시스템과 통합하기 위한 두 가지 옵션, 즉 NGINX Plus API 와 도메인 이름 시스템(DNS) 재확인을 제공합니다 . 이 블로그 게시물은 후자에 초점을 맞춥니다.
가상 머신(VM)이나 컨테이너를 추가하거나 제거하여 서비스 인스턴스(이 블로그 게시물에서는 백엔드 라고 부름 )를 확장할 때 로드 밸런서의 구성을 변경하여 백엔드 세트의 모든 변경 사항을 반영해야 합니다. 확장은 애플리케이션에 따라 하루에 여러 번, 한 시간에 한 번 또는 분에 한 번 발생할 수 있습니다. 구성 변경 빈도가 높으므로 자동화해야 하며 이를 달성하는 방법 중 하나는 DNS를 통한 서비스 검색입니다.
오늘날 애플리케이션을 실행하는 많은 플랫폼(예: Kubernetes) 은 DNS를 사용하여 서비스 검색을 지원합니다. 이 블로그 게시물의 끝부분에는 DNS를 사용하는 인기 있는 플랫폼 및 서비스 검색 도구와 NGINX Plus를 통합하는 방법을 설명하는 기사에 대한 링크가 제공됩니다.
주요 DNS 기능에 대한 간략한 검토
DNS를 통한 서비스 검색을 구성하는 방법을 설명하기에 앞서, 특히 관련성이 높거나 편리한 DNS 프로토콜의 몇 가지 기능을 간략히 살펴보겠습니다.
수명(Time‑to‑Live)
DNS 클라이언트가 오래된 정보를 사용하지 못하도록 DNS 레코드에는 클라이언트가 레코드를 유효하다고 간주할 수 있는 기간을 정의하는 TTL(수명) 필드가 포함됩니다. DNS 표준을 준수하기 위해 클라이언트는 레코드가 TTL을 초과하면 DNS 서버에 업데이트를 쿼리해야 합니다. NGINX Plus는 기본적으로 TTL을 존중하지만 레코드의 "수명"에 대한 보다 세부적인 제어도 제공합니다. NGINX Plus를 구성하여 TTL을 무시하고 대신 지정된 빈도로 레코드를 업데이트할 수 있습니다. (NGINX Open Source가 TTL을 처리하는 방법은 이 게시물의 후반부에서 설명합니다.)
TCP를 통한 DNS
기본적으로 DNS 클라이언트와 서버는 UDP를 통해 통신하지만 도메인 이름이 많은 수의 백엔드 IP 주소로 확인되는 경우 전체 응답이 512바이트로 제한된 단일 UDP 데이터그램에 맞지 않을 수 있습니다. UDP 대신 TCP를 사용하면 이 문제가 해결됩니다. 전체 레코드 세트가 하나의 데이터그램에 맞지 않으면 서버는 응답에 잘림 플래그를 설정하여 클라이언트에게 모든 레코드를 가져오기 위해 TCP로 전환하라고 알립니다. TCP를 통한 DNS는 NGINX 버전 1.9.11 이상 및 NGINX Plus R9 이상에서 지원됩니다. 자세한 내용은 블로그에서 NGINX 및 NGINX Plus로 DNS 트래픽 로드 밸런싱을 참조하세요.
SRV기록
DNS는 호스트 이름을 IP 주소로 변환하지만 포트 번호는 어떨까요? Docker 컨테이너의 부하 분산과 같이 잘 알려진 포트 번호에 의존할 수 없는 경우가 있습니다. 포트 번호는 대신 동적으로 할당되기 때문입니다. DNS에는 포트 번호와 몇 가지 다른 매개변수를 포함하는 Service( SRV) 레코드 라는 특수한 유형의 레코드가 있습니다. R9 이상에서 NGINX Plus는 레코드를 지원 SRV하므로 레코드에서 포트 정보를 추출할 수 있습니다.
편집자 - NGINX Plus R9의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R9 발표를 참조하세요.
NGINX 및 NGINX Plus를 위한 DNS를 사용한 서비스 검색 방법
이제 NGINX와 NGINX Plus에서 DNS를 사용하여 서비스 검색을 수행하는 다섯 가지 방법을 정교함의 순서대로 보여드리겠습니다. 처음 세 가지는 NGINX와 NGINX Plus에서 모두 사용할 수 있으며, 마지막 두 가지는 NGINX Plus에서만 사용할 수 있습니다.
이 서비스 검색 방법 조사에서, 우리는 IP 주소가 10.0.0.2인 example.com 영역에 대한 권한 있는 이름 서버가 있다고 가정합니다. 유틸리티 의 다음 출력에서 볼 수 있듯이, 도메인 이름 backends.example.comnslookup 에 해당하는 백엔드 서버가 세 개 있습니다 . 논의할 처음 네 가지 방법에서는 NGINX와 NGINX Plus가 ADNS에서 표준 레코드를 요청합니다. 마지막 방법에서는 NGINX Plus가 SRV대신 레코드를 요청합니다.
$ nslookup backends.example.com 10.0.0.2Server: 10.0.0.2 Address: 10.0.0.2#53 Name: backends.example.com Address: 10.0.0.11 Name: backends.example.com Address: 10.0.0.10 Name: backends.example.com Address: 10.0.0.12NGINX를 사용하여 서비스 검색을 위한 DNS 사용
NGINX 오픈 소스 에서 DNS를 사용하는 세 가지 방법을 보여드리면서 시작하겠습니다 (위에서 언급했듯이 NGINX Plus에서도 사용할 수 있습니다).
proxy_pass지침 에서 도메인 이름 사용
업스트림 서버(백엔드) 그룹을 정의하는 가장 간단한 방법은 지시문의 매개변수로 도메인 이름을 지정하는 것입니다 proxy_pass.
server { location / { proxy_pass http://backends.example.com:8080; } }NGINX가 시작되거나 구성을 다시 로드할 때 DNS 서버에 쿼리하여 backends.example.com을 확인 합니다. DNS 서버는 위에서 설명한 세 개의 백엔드 목록을 반환하고 NGINX는 기본 라운드 로빈 알고리즘을 사용하여 요청을 로드 밸런싱합니다. NGINX는 OS 구성 파일 /etc/resolv.conf 에서 DNS 서버를 선택합니다 .
이 방법은 서비스 검색을 수행하는 가장 유연성이 낮은 방법이며 다음과 같은 추가적인 단점이 있습니다.
업스트림 서버 그룹에서 도메인 이름 사용
NGINX가 제공하는 로드 밸런싱 옵션을 활용하려면 upstream구성 블록에서 업스트림 서버 그룹을 정의할 수 있습니다. 그러나 IP 주소로 개별 서버를 식별하는 대신 도메인 이름을 지시문의 매개변수로 사용합니다 server.
첫 번째 방법 과 마찬가지로 backends.example.com은 NGINX가 구성을 시작하거나 다시 로드할 때 세 개의 백엔드 서버로 해결됩니다. 하지만 이제 우리는 더 정교한 부하 분산 알고리즘인 Least Connections를 정의 하고 매개변수를 사용하여 수동 max_fails상태 검사를 활성화하여 NGINX가 세 개의 연속 요청이 실패하면 서버를 다운으로 표시하도록 지정할 수 있습니다.
upstream backends { least_conn; server backends.example.com:8080 max_fails=3; } server { location / { proxy_pass http://backends; } }이 방법을 사용하면 부하 분산 알고리즘을 선택하고 상태 검사를 구성할 수 있지만 시작, 다시 로드, TTL과 관련하여 이전 방법과 동일한 단점이 있습니다.
변수에 도메인 이름 설정
이 방법은 첫 번째 방법 의 변형 이지만 NGINX가 도메인 이름을 다시 확인하는 빈도를 제어할 수 있습니다.
resolver 10.0.0.2 valid=10s; server { location / { set $backend_servers backends.example.com; proxy_pass http://$backend_servers:8080; } }지시문에서 변수를 사용하여 도메인 이름을 지정하면 proxy_passNGINX는 TTL이 만료되면 도메인 이름을 다시 확인합니다. 지시문을 포함하여 이름 서버를 명시적으로 지정해야 합니다 (NGINX는 처음 두 방법에서처럼 /etc/resolv.confresolver 를 참조하지 않습니다 ). 지시문 에 매개변수를 포함하면 NGINX가 TTL을 무시하고 대신 지정된 빈도로 이름을 다시 확인하도록 할 수 있습니다. 여기서는 NGINX가 10초마다 이름을 다시 확인하도록 합니다.validresolver
참고: TCP/UDP 부하 분산의 경우 지시문에서 변수를 사용하는 이 방법은 proxy_passNGINX 1.11.3 이상 및 NGINX Plus R10 이상에서 지원됩니다.
이 방법은 첫 번째 방법의 두 가지 단점을 제거합니다. 즉, 도메인 이름을 확인할 수 없을 때 NGINX 시작 또는 다시 로드 작업이 실패하지 않고 NGINX가 이름을 다시 확인하는 빈도를 제어할 수 있습니다. 그러나 업스트림 그룹을 사용하지 않기 때문에 지시문에 부하 분산 알고리즘이나 다른 매개변수를 지정할 수 없습니다 ( 두 번째 방법server 에서 한 것처럼 ).
NGINX Plus를 사용하여 서비스 검색을 위한 DNS 사용
이제 NGINX Plus에서만 제공되는 DNS 서비스 검색을 위한 두 가지 방법을 살펴보겠습니다.
NGINX Plus로 A 레코드 사용
NGINX Plus를 사용하면 원하는 빈도로 DNS 이름을 다시 확인할 수 있으며 , 위에서 설명한 처음 세 가지 방법의 단점은 없습니다. 이 기능을 사용하려면 다음이 필요합니다.
다음 예를 고려해 보세요.
resolver 10.0.0.2 valid=10s; upstream backends { zone backends 64k; server backends.example.com:8080 resolve; } server { location / { proxy_pass http://backends; } }기본적으로 NGINX Plus는 TTL을 준수하여 레코드가 만료되면 이름을 다시 확인합니다. 대신 NGINX Plus가 지정된 빈도로 이름을 다시 확인하려면 지시문 valid에 매개변수를 포함합니다 resolver.
스니펫에서 NGINX Plus는 10초마다 10.0.0.2의 이름 서버에 쿼리하여 backends.example.com을502 확인합니다. 이름을 확인할 수 없는 경우 NGINX Plus는 시작 시, 구성을 다시 로드할 때 또는 런타임 중에 실패하지 않습니다. 대신 클라이언트는 표준 오류 페이지를 봅니다 .
NGINX Plus로 SRV 레코드 사용
NGINX Plus R9 이상은 DNS SRV레코드를 지원합니다. 이를 통해 NGINX Plus는 이름 서버에서 IP 주소뿐만 아니라 포트 번호, 가중치 및 우선순위도 가져올 수 있습니다. 이는 서비스의 포트 번호가 종종 동적으로 할당되는 마이크로서비스 환경에서 중요합니다.
편집자 - NGINX Plus R9의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R9 발표를 참조하세요.
SRV레코드는 서비스 이름, 서비스와의 통신을 위한 프로토콜, 도메인 이름의 세 가지로 정의됩니다. 이름 서버를 쿼리할 때 세 가지를 모두 제공해야 합니다. 10.0.0.2 이름 서버에는 서비스 이름 http , 프로토콜 tcp , 도메인 이름 backends.example.comSRV 의 세 가지 레코드가 있으며 , 이는 유틸리티의 이 출력에서 볼 수 있습니다 .nslookup
$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2Server: 10.0.0.2 Address: 10.0.0.2#53 _http._tcp.backends.example.com service = 0 2 8090 backend-0.example.com. _http._tcp.backends.example.com service = 0 1 8091 backend-1.example.com. _http._tcp.backends.example.com service = 10 1 8092 backend-2.example.com.각 레코드에서 호스트 이름을 쿼리하면 SRVIP 주소를 얻습니다.
$ nslookup backend-0.example.com 10.0.0.2... Name: backend-0.example.com Address: 10.0.0.10 $ nslookup backend-1.example.com 10.0.0.2 ... Name: backend-1.example.com Address: 10.0.0.11 $ nslookup backend-2.example.com 10.0.0.2 ... Name: backend-2.example.com Address: 10.0.0.12SRV첫 번째 명령에서 반환된 첫 번째 레코드의 정보를 더 자세히 살펴보겠습니다 nslookup.
_http._tcp.backends.example.com service = 0 2 8090 backend-0.example.com.이제 NGINX Plus를 구성하여 레코드를 사용하는 방법을 살펴보겠습니다 SRV. 샘플 구성 파일은 다음과 같습니다.
resolver 10.0.0.2 valid=10s; upstream backends { zone backends 64k; server backends.example.com service=_http._tcp resolve; } server { location / { proxy_pass http://backends; } }service지시문 에 대한 매개변수를 사용하여 , 우리는 해결하고자 하는 레코드 server의 이름과 프로토콜을 지정합니다 . 우리의 경우, 각각 _http 와 _tcp 입니다 . 매개변수와 포트를 지정하지 않는다는 사실을 제외하면 , 이전 섹션 의 구성 예와 동일하게 보입니다 .SRVservice
이 섹션의 첫 번째 명령에서 반환된 값을 기준으로 nslookupNGINX Plus는 세 개의 백엔드 서버로 구성됩니다.
NGINX Plus에 대한 라이브 활동 모니터링을 구성하면 내장 대시보드에서 해당 백엔드를 볼 수 있습니다.
요청이 지정된 가중치에 따라 어떻게 분배되는지 주목하세요. 10.0.0.11:8091 서버(가중치 1)는 요청의 1/3을 받는 반면, 10.0.0.10:8090 서버(가중치 2)는 2/3을 받습니다. 백업 서버인 10.0.0.12:8092 서버는 다른 두 서버가 다운되지 않는 한 요청을 받지 않습니다.
주의사항
NGINX Plus에서 서비스 검색을 위해 DNS를 사용할 때 염두에 두어야 할 몇 가지 사항이 있습니다.
예시
DNS를 사용하는 서비스 검색 플랫폼과 NGINX 및 NGINX Plus를 통합하는 방법에 대한 전체 예제를 살펴보려면 다음 블로그 게시물을 확인하세요.
향후 새로운 통합 옵션에 대한 자세한 내용이 공개되면 이 목록을 업데이트하겠습니다.
결론
NGINX Plus에서 완벽하게 제공되는 DNS를 통한 서비스 검색은 마이크로서비스 환경에서 로드 밸런서의 구성을 업데이트하는 간단한 방법을 제공합니다. SRV릴리스 9 이상의 레코드 지원은 NGINX Plus를 더욱 강력하게 만들어 NGINX Plus가 IP 주소뿐만 아니라 백엔드의 포트 번호도 얻을 수 있게 해줍니다.
위 내용과 같이 NGINX Plus 를 활용하여 Demo 가 필요하시면 하단의 전문가에게 상담받기 버튼을 클릭해주세요
전문가에게 상담받기