Consul DNS 확장하기

Consul DNS 확장하기 (Scale Consul DNS)

이 문서는 DNS 조회에 응답할 때 캐시된 결과를 반환하는 과정을 설명해 드릴게요. Consul 에이전트의 DNS 캐싱으로 응답 시간을 줄이는 방법과 TTL·stale read 설정을 배울 수 있어요.

출처: 문서

본문

이 페이지는 DNS 조회에 응답할 때 캐시된 결과를 반환하는 과정을 설명합니다. Consul 에이전트는 DNS 캐싱을 사용하여 응답 시간을 줄일 수 있지만, 그 과정에서 오래된(stale) 정보를 제공할 수 있습니다.

확장 기법 (Scaling techniques)

기본적으로 Consul은 모든 DNS 결과를 0 TTL 값으로 제공하여 가장 최근 정보를 반환합니다. 규모가 커질 때 이 구성은 서버가 모든 DNS 쿼리에 응답해야 하므로 추가 지연이 발생할 수 있습니다. 데이터센터에서 이 부담을 분산하기 위한 몇 가지 전략이 있습니다:

Stale Reads 허용 [/consul/docs/discover/dns/scale#stale-reads]. 리더로 전달하는 대신 리더가 아닌 다른 서버가 쿼리에 응답하도록 허용합니다.
DNS TTL 구성 [/consul/docs/discover/dns/scale#ttl-values]. 노드 또는 서비스에 대한 DNS time-to-live(TTL) 값을 구성하여 컨테이너 운영 체제의 DNS 하위 시스템이 응답을 캐시하도록 합니다. 그러면 서비스가 외부 요청 없이 DNS 쿼리를 로컬에서 해석합니다.
Read Replicas 추가 [/consul/docs/manage/scale/read-replica]. Enterprise 사용자는 Raft 쿼럼에 참여하지 않고 클러스터 데이터를 복제하는 추가 Consul 서버인 read replica를 사용할 수 있습니다.
Cache를 사용하여 서버 요청 방지 [/consul/docs/reference/agent/configuration-file/dns#dns_use_cache]. Consul 클라이언트가 에이전트 캐시를 사용하여 서비스 또는 노드에 대한 이벤트를 구독하도록 구성합니다. 감시(watch)를 설정한 후 로컬 Consul 클라이언트 에이전트는 Consul 서버를 조회하지 않고 서비스 또는 노드에 대한 DNS 쿼리를 해석할 수 있습니다.

다음 표는 클러스터 리더에서 클라이언트 에이전트, dataplane 또는 DNS 프록시로 DNS 요청을 오프로드하도록 Consul을 구성했는지에 따른 각 확장 기법의 가용성을 설명합니다.

| | 확장 기법 | 클라이언트 에이전트 지원 | dataplane 지원 | Consul DNS 프록시 지원 | | DNS TTL 구성 | ✅ | ✅ | ✅ | | Stale Reads 허용 | ✅ | ✅ | ✅ | | Read Replicas 추가 | ✅ | ✅ | ✅ | | Cache를 사용하여 서버 요청 방지 | ✅ | ❌ | ❌ |

규모에 따라 작동하는 Consul 배포에 대한 고려 사항에 대해 자세히 알아보려면 대규모 Consul 운영 [/consul/docs/manage/scale]을 참조하세요.

TTL 값 (TTL values)

에이전트 구성 파일 [/consul/docs/reference/agent/configuration-file]에서 TTL 값을 구성하여 DNS 결과가 Consul 아래에서 캐시되도록 할 수 있습니다. 더 높은 TTL 값은 Consul 서버에서 조회 수를 줄이고 클라이언트 조회 속도를 높이지만, 점점 더 오래된 결과를 가져옵니다. 기본적으로 모든 TTL은 0이며 캐싱을 방지합니다.

HCL

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

JSON

{
  "dns_config": {
    "service_ttl": {
      "*": "0s"
    },
    "node_ttl": "0s"
  }
}

캐싱 활성화 (Enable caching)

노드 조회의 캐싱을 활성화하려면 dns_config.node_ttl [/consul/docs/reference/agent/configuration-file/dns#node_ttl] 값을 설정합니다. 예를 들어 10s로 설정할 수 있으며, 모든 노드 조회는 10초 TTL로 결과를 제공합니다.

서비스 TTL은 더 세밀하게 지정할 수 있습니다. 와일드카드 TTL을 기본값으로 하여 서비스별로 TTL을 설정할 수 있습니다. 이는 dns_config.service_ttl [/consul/docs/reference/agent/configuration-file/dns#service_ttl] 맵으로 지정됩니다. *는 모든 접두사 끝에서 지원되며 정확한 매칭보다 우선 순위가 낮으므로 my-service-x가 my-service-*보다 우선합니다. 와일드카드 매칭 시 가장 긴 경로가 고려되므로 my-* 또는 * 대신 my-service-* TTL이 사용됩니다. 같은 규칙으로 다른 것이 매칭되지 않으면 *가 기본값입니다. 매칭이 없으면 TTL은 기본적으로 0입니다.

예를 들어 와일드카드 TTL과 특정 서비스 TTL을 제공하는 dns_config [/consul/docs/reference/agent/configuration-file/dns#dns_config]는 다음과 같을 수 있습니다:

HCL

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

JSON

{
  "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 [/consul/api-docs/query]는 TTL에 대한 추가 제어 수준을 제공합니다. TTL을 쿼리와 함께 정의할 수 있고, 쿼리 정의를 업데이트하여 즉시 변경할 수 있습니다. prepared query에 TTL이 구성되지 않은 경우 위에서 설명한 대로 Consul 에이전트에 정의된 서비스별 구성으로 폴백(fallback)하고, 궁극적으로 Consul 에이전트에서 서비스에 TTL이 구성되지 않으면 0으로 폴백됩니다.

Stale reads

Stale reads는 DNS 쿼리의 지연 시간을 줄이고 처리량을 높이는 데 사용할 수 있습니다. DNS 쿼리의 stale reads를 제어하는 데 사용되는 설정 [/consul/docs/reference/agent/configuration-file]은 다음과 같습니다:

dns_config.allow_stale [/consul/docs/reference/agent/configuration-file/dns#allow_stale]은 stale reads를 활성화하려면 true로 설정해야 합니다.
dns_config.max_stale [/consul/docs/reference/agent/configuration-file/dns#max_stale]은 DNS를 조회할 때 결과가 얼마나 오래될 수 있는지 제한합니다.

이 두 설정으로 stale reads를 허용하거나 방지할 수 있습니다. 아래에서 두 경우의 장단점을 설명하겠습니다.

Stale reads 허용 (Allow stale reads)

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

HCL

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

JSON

{
  "dns_config": {
    "allow_stale": true,
    "max_stale": "87600h"
  }
}

참고

위 예시는 기본 설정입니다. 명시적으로 설정할 필요가 없습니다.

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

Stale reads 방지 (Prevent stale reads)

stale reads를 방지하거나 얼마나 오래될 수 있는지 제한하려면 allow_stale을 false로 설정하거나 max_stale에 더 낮은 값을 사용할 수 있습니다. 첫 번째 방법을 수행하면 모든 읽기가 단일 리더 노드 [/consul/docs/concept/consensus]에 의해 처리되도록 보장합니다. 그러면 읽기는 강하게 일관되지만 단일 노드의 처리량에 의해 제한됩니다.

HCL

dns_config {
  allow_stale = false
}

JSON

{
  "dns_config": {
    "allow_stale": false
  }
}

부정 응답 캐싱 (Negative response caching)

DNS 클라이언트는 부정 응답을 캐시하지만, Consul은 서비스가 존재하는데 정상 엔드포인트가 없을 때 "not found" 스타일 응답을 반환합니다. 서비스 디스커버리에 DNS를 사용할 때 캐시된 부정 응답으로 인해 실제로 사용할 수 없는 시간보다 더 오래 서비스가 다운된 것처럼 보일 수 있습니다.

SOA 구성 (Configure SOA)

Consul v1.3.0 이상에서는 SOA 응답을 튜닝하고 일부 리졸버의 부정 TTL 캐시를 수정할 수 있습니다. 이것은 soa [/consul/docs/reference/agent/configuration-file/dns#soa] 구성 내의 soa.min_ttl [/consul/docs/reference/agent/configuration-file/dns#soa_min_ttl] 구성을 사용하여 달성할 수 있습니다.

HCL

dns_config {
  soa {
    min_ttl = 60
  }
}

JSON

{
  "dns_config": {
    "soa": {
      "min_ttl": 60
    }
  }
}

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

Consul DNS 확장하기