Consul DNS 동작 구성

Consul DNS 동작 구성

이 주제에서는 Consul DNS 기능의 기본 동작과 Consul이 쿼리를 수행하는 방식을 사용자 지정하는 방법을 설명해요. VM 환경에서 서비스 발견에 DNS를 사용하는 것이 좋으며, 다양한 튜닝 매개변수로 캐싱과 stale read를 조정할 수 있어요.

출처: 문서

본문

이 주제에서는 Consul DNS 기능의 기본 동작과 Consul이 쿼리를 수행하는 방식을 사용자 지정하는 방법을 설명합니다.

소개 (Introduction)

Consul DNS는 Consul 서비스 메시가 비활성화되고 네트워크가 비 Kubernetes 환경에서 실행될 때 레코드를 쿼리하는 기본 인터페이스입니다. Consul DNS를 사용하면 Consul에 HTTP API 요청을 하지 않고도 Consul에 등록된 서비스와 노드를 조회할 수 있습니다. VM(가상 머신) 환경에서는 네이티브 애플리케이션을 수정하지 않고도 Consul 서비스 발견 API를 사용할 수 있으므로 서비스 발견에 DNS를 사용하는 것이 좋습니다. DNS에는 여러 기본 구성이 있지만 서버가 조회를 처리하는 방식을 사용자 지정할 수 있습니다. 자세한 내용은 Configure Consul DNS behavior를 참조하세요.

Consul DNS 요청 형식에 대한 참조 정보는 Consul DNS reference를 참조하세요.

DNS 동작 구성

기본적으로 Consul DNS는 127.0.0.1:8600에서 쿼리를 수신하고 consul 도메인을 사용합니다. 서비스를 쿼리할 때 DNS 동작을 결정하려면 에이전트 구성에서 다음 매개변수를 지정하세요.

• client_addr
• ports.dns: 기본적으로 Consul은 일반적으로 DNS 리졸버의 기본 포트로 예약된 포트 53을 사용하지 않습니다. 포트 53에 바인딩하려면 승격된 권한이 필요하기 때문입니다.
• recursors
• domain
• alt_domain
• dns_config

WAN 주소 변환 구성

기본적으로 Consul DNS 쿼리는 원격 데이터센터에서 쿼리해도 노드의 로컬 주소를 반환합니다. Consul 에이전트의 다음 구성 필드에 주소를 지정하면 DNS가 데이터센터 외부에서 노드에 도달하도록 구성할 수 있습니다.

• advertise-wan
• translate_wan_addrs

사용자 지정 DNS 리졸버 라이브러리 사용

에이전트의 recursors 필드에서 주소 목록을 지정하면 Consul의 서비스 도메인 밖에 있는 쿼리를 재귀적으로 해석하는 업스트림 DNS 서버를 제공할 수 있습니다.

consul. 도메인 밖의 레코드를 쿼리하는 노드는 업스트림 DNS로 해석됩니다. IP 주소를 지정하거나 go-sockaddr 템플릿을 사용할 수 있습니다. Consul은 지정된 순서대로 IP 주소를 해석하고 중복을 무시합니다.

비 Consul 쿼리 활성화

노드의 DNS 서버로 Consul을 설정하고 recursors 구성을 제공하면 비 Consul 쿼리가 해석되도록 활성화할 수 있습니다.

에이전트로 쿼리 전달

기존 DNS 서버에서 consul. 도메인으로 전송된 모든 쿼리를 Consul 에이전트로 전달할 수 있습니다. 지침은 Forward DNS for Consul Service Discovery를 참조하세요.

대체 도메인 쿼리

기본적으로 Consul은 consul 도메인에서 DNS 쿼리에 응답하지만, domain 매개변수를 구성하여 DNS 쿼리에 응답할 특정 도메인을 설정할 수 있습니다.

또한 alt_domain 에이전트 구성 옵션에 추가 도메인을 지정할 수 있으며, 이는 Consul이 보조 도메인의 쿼리에 응답하도록 구성합니다. 예를 들어 DNS 마이그레이션 중이거나 내부 및 외부 쿼리를 구분해야 할 때 대체 도메인을 구성하는 것이 유용할 수 있습니다.

Consul의 DNS 응답은 쿼리와 동일한 도메인을 사용합니다.

다음 예시에서 에이전트 구성의 alt_domain 매개변수가 test-domain으로 설정되어 운영자가 도메인을 쿼리할 수 있습니다.

$ dig @127.0.0.1 -p 8600 consul.service.test-domain SRV
;; QUESTION SECTION:
;consul.service.test-domain.  IN  SRV

;; ANSWER SECTION:
consul.service.test-domain. 0 IN  SRV 1 1 8300 machine.node.dc1.test-domain.

;; ADDITIONAL SECTION:
machine.node.dc1.test-domain. 0 IN  A 127.0.0.1
machine.node.dc1.test-domain. 0 IN  TXT "consul-network-segment="

PTR 쿼리

<ip>.in-addr.arpa. 같은 포인터 레코드(PTR) 쿼리에 대한 응답은 항상 기본 도메인을 사용하며 대체 도메인은 사용하지 않습니다.

캐싱 (Caching)

기본적으로 Consul은 모든 DNS 결과를 0 TTL 값으로 제공합니다. 이는 캐싱을 방지합니다. 장점은 각 DNS 조회가 항상 다시 평가되므로 가장 시기적절한 정보가 제공된다는 것입니다. 그러나 각 조회마다 지연 시간이 추가되고 데이터센터의 쿼리 처리량을 소진시킬 수 있습니다. 이러한 이유로 Consul은 DNS 쿼리 처리 방식을 사용자 지정할 수 있는 여러 튜닝 매개변수를 제공합니다.

Stale reads

stale read를 사용하여 DNS 쿼리의 지연 시간을 줄이고 처리량을 높이세요. DNS 쿼리의 stale read를 제어하는 설정은 다음과 같습니다.

• dns_config.allow_stale는 stale read를 활성화하려면 true로 설정해야 합니다.
• dns_config.max_stale은 DNS 쿼리 시 허용되는 결과의 오래된 정도(staleness)를 제한합니다.

이 두 설정으로 stale read를 허용하거나 방지할 수 있습니다.

Stale reads 허용

allow_stale 필드는 기본적으로 활성화되어 있으며 거의 무한한 임계값(10년)을 기본값으로 하는 max_stale 값을 사용합니다. 이는 리더가 없는 장기간의 중단 상황에서도 DNS 쿼리가 계속 제공될 수 있도록 합니다. 또한 에이전트가 5초 이상 오래된(stale) DNS 쿼리를 제공할 때를 추적하는 새 텔레메트리 카운터 consul.dns.stale_queries가 추가되었습니다.

dns_config {
  allow_stale = true
  max_stale = "87600h"
}

stale read를 수행하면 모든 Consul 서버가 쿼리를 처리할 수 있지만, 비 리더 노드는 최신이 아닌 데이터를 반환할 수 있습니다. 데이터가 약간 오래되도록 허용하면 수평적 읽기 확장성을 얻을 수 있습니다. 이제 모든 Consul 서버가 요청을 처리할 수 있으므로 데이터센터의 서버 수만큼 처리량이 증가합니다.

Stale reads 방지

stale read를 방지하거나 오래된 정도를 제한하려면 allow_stale을 false로 설정하거나 max_stale에 더 낮은 값을 사용하세요. allow_stale을 false로 설정하면 모든 읽기가 단일 리더 노드에서 처리되도록 보장됩니다. 그러면 읽기는 강력하게 일관적이지만 단일 노드의 처리량에 의해 제한됩니다.

dns_config {
  allow_stale = false
}

음성 응답 캐싱 (Negative response caching)

일부 DNS 클라이언트는 음성 응답을 캐싱합니다. Consul은 서비스가 존재하지만 정상 엔드포인트가 없기 때문에 "not found" 스타일 응답을 반환합니다. 실제로 이는 DNS를 서비스 발견에 사용할 때 캐시된 음성 응답으로 인해 해당 서비스가 실제로 사용 불가능한 시간보다 더 오래 "다운"된 것처럼 보일 수 있음을 의미합니다.

SOA 구성

soa 구성 내의 soa.min_ttl 구성을 사용하여 SOA 응답을 튜닝하고 일부 리졸버의 음성 TTL 캐시를 수정하세요.

dns_config {
  soa {
    min_ttl = 60
  }
}

한 가지 일반적인 예는 Windows가 기본적으로 음성 응답을 15분 동안 캐싱하는 것입니다. DNS 포워더도 동일한 효과로 음성 응답을 캐싱할 수 있습니다. 이 문제를 피하려면 클라이언트 운영 체제와 클라이언트와 Consul 사이 경로의 DNS 포워더에 대한 음성 응답 캐시 기본값을 확인하고 캐시 값을 적절히 설정하세요. 많은 경우 "적절히"는 서비스가 다시 사용 가능해질 때 최상의 복구 시간을 얻기 위해 음성 응답 캐싱을 끄는 것을 의미합니다.

TTL 값

TTL 값을 설정하여 DNS 결과를 Consul 다운스트림에서 캐싱할 수 있습니다. 더 높은 TTL 값은 Consul 서버의 조회 수를 줄이고 클라이언트의 조회를 빠르게 하지만, 결과가 점점 더 오래될 수 있습니다. 기본적으로 모든 TTL은 0이므로 캐싱이 방지됩니다.

dns_config {
  service_ttl {
    "*" = "0s"
  }
  node_ttl = "0s"
}

캐싱 활성화

노드 조회(예: "foo.node.consul")의 캐싱을 활성화하려면 dns_config.node_ttl 값을 설정하세요. 예를 들어 노드 TTL을 10s로 설정하면 모든 노드 조회가 10초 TTL로 결과를 제공합니다.

서비스 TTL은 더 세밀하게 지정할 수 있습니다. dns_config.service_ttl 맵을 사용해 와일드카드 TTL을 기본값으로 서비스별 TTL을 설정하세요.

*는 모든 접두사 끝에서 지원되며 정확한 일치보다 우선순위가 낮으므로 my-service-x가 my-service-*보다 우선합니다. 와일드카드 일치를 수행할 때 가장 긴 경로가 고려되므로 my-service-* TTL이 my-* 또는 * 대신 사용됩니다. 같은 규칙으로 다른 것이 일치하지 않을 때 *가 기본값입니다. 일치하는 항목이 없으면 TTL은 0으로 기본 설정됩니다.

이 예시는 와일드카드 TTL과 서비스별 특정 TTL을 제공하는 dns_config를 보여줍니다.

dns_config {
  service_ttl {
    "*" = "5s"
    "web" = "30s"
    "db*" = "10s"
    "db-master" = "3s"
  }
}

이렇게 하면 "web.service.consul"에 대한 모든 조회가 30초 TTL을 사용하도록 설정되고, api.service.consul 조회는 와일드카드의 5초 TTL을 사용합니다. db\*와 일치하는 모든 조회는 10초 TTL을 얻지만, db-master는 3초 TTL을 갖습니다.

Prepared queries

Prepared Queries는 TTL에 대한 추가 수준의 제어를 제공합니다. 쿼리와 함께 TTL을 정의할 수 있으며 쿼리 정의를 업데이트하여 즉석에서 변경할 수 있습니다. prepared query에 TTL이 구성되지 않으면 Consul 에이전트에 정의된 서비스별 구성으로 폴백되고, 결국 Consul 에이전트에서 서비스에 대해 TTL이 구성되지 않으면 0으로 폴백됩니다.

더 알아보기 (Learn more)

• Consul DNS 참조
• 에이전트 DNS 설정