NGINX 및 NGINX Plus를 사용하여 서비스 검색을 위한 DNS 사용

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

마이크로서비스 아키텍처 의 가장 큰 장점 중 하나는 서비스 인스턴스를 얼마나 빠르고 쉽게 확장할 수 있는가입니다. 여러 서비스 인스턴스가 있는 경우 로드 밸런서가 필요하며, 사용 가능한 서비스 인스턴스 세트의 변경 사항을 빠르게 로드 밸런서에 알릴 방법이 필요합니다. 이것을 서비스 검색 이라고 합니다. 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 오픈 소스가 TTL을 어떻게 처리하는지에 대해서는 이 게시물의 후반부에서 논의하겠습니다.)

TCP를 통한 DNS

기본적으로 DNS 클라이언트와 서버는 UDP를 통해 통신하지만 도메인 이름이 많은 수의 백엔드 IP 주소로 확인되는 경우 전체 응답이 512바이트로 제한되는 단일 UDP 데이터그램에 맞지 않을 수 있습니다. UDP 대신 TCP를 사용하면 이러한 문제가 해결됩니다. 전체 레코드 세트가 하나의 데이터그램에 들어가지 않는 경우, 서버는 응답에서 잘림 플래그를 설정하여 클라이언트에게 모든 레코드를 가져오기 위해 TCP로 전환하라고 알립니다. DNS over TCP는 NGINX 버전 1.9.11 이상 및 NGINX Plus R9 이상에서 지원됩니다. 자세한 내용은 블로그의 NGINX 및 NGINX Plus를 사용하여 DNS 트래픽 부하 분산을 참조하세요.

SRV 레코드

DNS는 호스트 이름을 IP 주소로 변환하지만 포트 번호는 어떨까요? 예를 들어 Docker 컨테이너의 부하를 분산할 때 잘 알려진 포트 번호에 의존할 수 없는 경우가 있습니다. 대신 포트 번호가 동적으로 할당되기 때문입니다. DNS에는 포트 번호와 몇 가지 다른 매개변수를 포함하는 서비스( SRV ) 레코드 라는 특수한 유형의 레코드가 있습니다. R9 이상에서는 NGINX Plus가 SRV 레코드를 지원하여 해당 레코드에서 포트 정보를 추출할 수 있습니다.

편집자 - NGINX Plus R9의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R9 발표를 참조하세요.

NGINX 및 NGINX Plus를 위한 DNS를 사용한 서비스 검색 방법

이제 NGINX 및 NGINX Plus에서 서비스 검색을 위해 DNS를 사용하는 5가지 방법을 점점 더 정교해지는 순서대로 보여드리겠습니다. 처음 세 가지는 NGINX와 NGINX Plus에서 모두 사용할 수 있으며, 마지막 두 가지는 NGINX Plus에서만 사용할 수 있습니다.

이 서비스 검색 방법 조사에서는 IP 주소가 10.0.0.2인 example.com 영역에 대한 권한 있는 이름 서버가 있다고 가정합니다. 다음 nslookup 유틸리티 출력에서 볼 수 있듯이, 도메인 이름 backends.example.com 에 해당하는 백엔드 서버가 세 개 있습니다. 처음 네 가지 방법에서는 NGINX와 NGINX Plus가 DNS에 표준 A 레코드를 요청하고, 마지막 방법에서는 NGINX Plus가 대신 SRV 레코드를 요청합니다.

$ nslookup backends.example.com 10.0.0.2 서버:		10.0.0.2 주소:	10.0.0.2#53 이름: backends.example.com 주소: 10.0.0.11 이름: backends.example.com 주소: 10.0.0.10 이름: backends.example.com 주소: 10.0.0.12

NGINX를 사용하여 서비스 검색을 위한 DNS 사용

NGINX 오픈 소스 에서 DNS를 사용하는 세 가지 방법을 보여드리면서 시작하겠습니다(위에서 언급했듯이 NGINX Plus에서도 사용할 수 있습니다).

proxy_pass 지시문에서 도메인 이름 사용

업스트림 서버(백엔드) 그룹을 정의하는 가장 간단한 방법은 proxy_pass 지시문의 매개변수로 도메인 이름을 지정하는 것입니다.

서버 { 위치 / {
proxy_pass http://backends.example.com:8080;
}
}

NGINX가 시작되거나 구성을 다시 로드하면 backends.example.com을 확인하기 위해 DNS 서버를 쿼리합니다. DNS 서버는 위에서 설명한 세 개의 백엔드 목록을 반환하고, NGINX는 기본 라운드 로빈 알고리즘을 사용하여 이들 간의 요청 부하를 분산합니다. NGINX는 OS 설정 파일 /etc/resolv.conf 에서 DNS 서버를 선택합니다.

이 방법은 서비스 검색을 수행하는 가장 유연성이 낮은 방법이며 다음과 같은 추가적인 단점이 있습니다.

• 도메인 이름을 확인할 수 없으면 NGINX가 시작되지 않거나 구성을 다시 로드하지 못합니다.
• NGINX는 다음 재시작 또는 구성 재로드까지 DNS 레코드를 캐시하고 레코드의 TTL 값을 무시합니다.
• 다른 부하 분산 알고리즘을 지정할 수 없으며, 다음 섹션에서 설명할 서버 지시문의 매개변수로 정의된 수동 상태 검사나 다른 기능을 구성할 수도 없습니다.

업스트림 서버 그룹에서 도메인 이름 사용

NGINX가 제공하는 부하 분산 옵션을 활용하려면 업스트림 구성 블록에서 업스트림 서버 그룹을 정의할 수 있습니다. 하지만 개별 서버를 IP 주소로 식별하는 대신, 도메인 이름을 서버 지시문의 매개변수로 사용합니다.

첫 번째 방법 과 마찬가지로, NGINX가 시작되거나 구성을 다시 로드함에 따라 backends.example.com은 세 개의 백엔드 서버로 분석됩니다. 하지만 이제는 더 정교한 부하 분산 알고리즘인 최소 연결(Least Connections) 을 정의하고 max_fails 매개변수를 사용하여 수동적 상태 검사를 활성화하여 3개의 연속된 요청이 실패하면 NGINX가 서버를 다운으로 표시하도록 지정할 수 있습니다.

업스트림 백엔드 { least_conn;

서버 백엔드.example.com:8080 max_fails=3;
}

서버 {
위치 / {
proxy_pass http://backends;
}
}

이 방법을 사용하면 부하 분산 알고리즘을 선택하고 상태 검사를 구성할 수 있지만 시작, 다시 로드, TTL과 관련하여 이전 방법과 동일한 단점이 있습니다.

변수에 도메인 이름 설정

이 방법은 첫 번째 방법 의 변형이지만 NGINX가 도메인 이름을 다시 확인하는 빈도를 제어할 수 있습니다.

리졸버 10.0.0.2 유효=10초;
서버 {
위치 / {
$backend_servers backends.example.com 설정;
proxy_pass http://$backend_servers:8080;
}
}

proxy_pass 지시문에서 변수를 사용하여 도메인 이름을 지정하는 경우 NGINX는 TTL이 만료되면 도메인 이름을 다시 확인합니다. 이름 서버를 명시적으로 지정하려면 resolver 지시문을 포함해야 합니다(NGINX는 처음 두 가지 방법처럼 /etc/resolv.conf 를 참조하지 않습니다). resolver 지시문에 유효한 매개변수를 포함하면 NGINX가 TTL을 무시하고 대신 지정된 빈도로 이름을 다시 확인하도록 할 수 있습니다. 여기서는 NGINX에 10초마다 이름을 다시 확인하라고 지시합니다.

메모: TCP/UDP 부하 분산의 경우 proxy_pass 지시문에서 변수를 사용하는 이 방법은 NGINX 1.11.3 이상 및 NGINX Plus R10 이상에서 지원됩니다.

이 방법은 첫 번째 방법의 두 가지 단점을 제거합니다. 즉, 도메인 이름을 확인할 수 없어도 NGINX 시작 또는 다시 로드 작업이 실패하지 않으며, NGINX가 이름을 다시 확인하는 빈도를 제어할 수 있습니다. 하지만 이 방법은 업스트림 그룹을 사용하지 않기 때문에 서버 지시문에 부하 분산 알고리즘이나 다른 매개변수를 지정할 수 없습니다( 두 번째 방법 에서 한 것처럼).

NGINX Plus를 사용하여 서비스 검색을 위한 DNS 사용

이제 NGINX Plus에서만 제공되는 DNS 서비스 검색을 위한 두 가지 방법을 살펴보겠습니다.

NGINX Plus에서 A 레코드 사용

NGINX Plus를 사용하면 원하는 빈도로 DNS 이름을 다시 확인할 수 있으며 , 위에서 설명한 처음 세 가지 방법의 단점도 발생하지 않습니다. 이 기능을 사용하려면 다음이 필요합니다.

• 이전 방법과 마찬가지로 이름 서버를 지정하려면 resolver 지시문을 포함합니다.
• 공유 메모리 영역을 할당하려면 업스트림 구성 블록에 영역 지침을 포함합니다.
• 도메인 이름을 사용하는 서버 지시문에 resolve 매개변수를 추가합니다.

다음 예를 고려해 보세요.

resolver 10.0.0.2 valid=10s ; 업스트림 백엔드 { 존 백엔드 64k ; 서버 backends.example.com:8080 resolve ; } 서버 { 위치 / { proxy_pass http://backends; } }

기본적으로 NGINX Plus는 TTL을 준수하여 레코드가 만료되면 이름을 다시 확인합니다. NGINX Plus가 지정된 빈도로 이름을 다시 확인하도록 하려면 resolver 지시문에 유효한 매개변수를 포함합니다.

이 스니펫에서는 NGINX Plus가 10초마다 10.0.0.2의 이름 서버에 쿼리를 보내 backends.example.com을 확인합니다. 이름을 확인할 수 없는 경우 NGINX Plus는 시작 시, 구성을 다시 로드할 때 또는 런타임 중에 실패하지 않습니다. 대신 클라이언트는 표준을 봅니다.502 오류 페이지.

NGINX Plus에서 SRV 레코드 사용

NGINX Plus R9 이상에서는 DNS SRV 레코드를 지원합니다. 이를 통해 NGINX Plus는 이름 서버에서 IP 주소뿐 아니라 포트 번호, 가중치, 우선 순위도 가져올 수 있습니다. 이는 서비스의 포트 번호가 종종 동적으로 할당되는 마이크로서비스 환경에서 매우 중요합니다.

편집자 - NGINX Plus R9의 모든 새로운 기능에 대한 개요는 블로그의 NGINX Plus R9 발표를 참조하세요.

SRV 레코드는 서비스 이름, 서비스와의 통신을 위한 프로토콜, 도메인 이름의 3중 조합으로 정의됩니다. 네임 서버에 쿼리를 보낼 때는 세 가지 모두를 제공해야 합니다. 10.0.0.2 네임 서버에는 서비스 이름 http , 프로토콜 tcp , 도메인 이름 backends.example.com 의 세 개의 SRV 레코드가 있습니다. 이는 nslookup 유틸리티의 출력에서 볼 수 있습니다.

$ nslookup -query=SRV _http._tcp.backends.example.com 10.0.0.2 서버:		10.0.0.2 주소:	10.0.0.2#53 _http._tcp.backends.example.com 서비스 = 0 2 8090 백엔드-0.example.com. _http._tcp.backends.example.com 서비스 = 0 1 8091 백엔드-1.example.com. _http._tcp.backends.example.com 서비스 = 10 1 8092 백엔드-2.example.com.

각 SRV 레코드에서 호스트 이름을 쿼리하면 IP 주소를 얻습니다.

$ nslookup backend-0.example.com 10.0.0.2 ...
이름: backend-0.example.com 주소: 10.0.0.10 $ nslookup 백엔드-1.example.com 10.0.0.2 ...
이름: backend-1.example.com 주소: 10.0.0.11 $ nslookup 백엔드-2.example.com 10.0.0.2 ...
이름: backend-2.example.com 주소: 10.0.0.12

첫 번째 nslookup 명령에서 반환된 첫 번째 SRV 레코드의 정보를 더 자세히 살펴보겠습니다.

_http._tcp.backends.example.com 서비스 = 0 2 8090 backend-0.example.com.

• _http._tcp. – SRV 레코드의 이름과 프로토콜. NGINX Plus 설정 파일(아래 참조)에서 서버 지시문에 대한 서비스 매개변수 값으로 이것을 지정합니다.
• 0 – 우선순위. 값이 낮을수록 우선순위가 높습니다. NGINX Plus는 가장 높은 우선순위를 가진 서버를 기본 서버로 지정하고 나머지 서버는 백업 서버로 지정합니다. 이 레코드는 모든 레코드 중 가장 낮은 값(가장 높은 우선순위)을 가지므로 NGINX Plus는 해당 백엔드를 기본 서버로 지정합니다.
• 2 – 무게. NGINX Plus는 백엔드를 업스트림 그룹에 추가할 때 백엔드의 가중치를 이 값으로 설정합니다( 서버 지시문의 가중치 매개변수와 동일).
• 8090 – 포트 번호. NGINX Plus는 백엔드를 업스트림 그룹에 추가할 때 백엔드의 포트를 이 값으로 설정합니다.
• backend‑0.example.com – 백엔드 서버의 호스트 이름. NGINX Plus는 이 이름을 확인하고 해당 백엔드를 업스트림 그룹에 추가합니다. 이름이 여러 개의 레코드로 확인되는 경우 NGINX Plus는 여러 개의 서버를 추가합니다.

이제 SRV 레코드를 사용하도록 NGINX Plus를 구성하는 방법을 살펴보겠습니다. 샘플 구성 파일은 다음과 같습니다.

리졸버 10.0.0.2 유효=10초;

업스트림 백엔드 {
존 백엔드 64k;
서버 백엔드.example.com 서비스=_http._tcp 리졸브;
}

서버 {
위치 / {
proxy_pass http://backends;
}
}

서버 지시문에 서비스 매개변수를 사용하여 확인하려는 SRV 레코드의 이름과 프로토콜을 지정합니다. 우리의 경우에는 각각 _http 와 _tcp 입니다. 서비스 매개변수와 포트를 지정하지 않았다는 점을 제외하면 이전 섹션 의 구성 예와 동일합니다.

이 섹션의 첫 번째 nslookup 명령에서 반환된 값을 기반으로 NGINX 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를 통합하는 방법에 대한 이 블로그 게시물을 확인하여 전체 예를 자세히 살펴보세요.

• Consul의 DNS SRV 레코드를 사용한 NGINX Plus의 서비스 검색
• NGINX Plus를 사용한 Kubernetes 서비스 로드 밸런싱

향후 새로운 통합 옵션에 대해 더 자세히 설명하면 이 목록을 업데이트하겠습니다.

결론

NGINX Plus에서 완벽하게 사용할 수 있는 DNS를 통한 서비스 검색은 마이크로서비스 환경에서 로드 밸런서의 구성을 업데이트하는 간단한 방법을 제공합니다. 릴리스 9 이상에서 SRV 레코드에 대한 지원이 추가되면서 NGINX Plus는 더욱 강력해졌으며, 이를 통해 NGINX Plus는 IP 주소뿐만 아니라 백엔드의 포트 번호도 가져올 수 있게 되었습니다.

NGINX Plus의 DNS를 사용하여 서비스 검색을 시도하고 다른 향상된 기능을 사용해 볼 준비가 되셨나요? 오늘 무료 30일 체험판을 시작하거나, 사용 사례에 대해 논의하기 위해 저희에게 문의하세요 .