Consul DNS 확장

DNS 조회에 대한 응답으로 캐시된 결과를 반환하는 과정을 설명해 드릴게요. Consul 에이전트는 DNS 캐싱을 사용하여 응답 시간을 줄일 수 있지만, 그 과정에서 오래된 정보를 제공할 수도 있어요.

출처: 문서

본문

이 페이지는 DNS 조회에 대한 응답으로 캐시된 결과를 반환하는 과정을 설명해요. Consul 에이전트는 DNS 캐싱을 사용하여 응답 시간을 줄일 수 있지만, 그 과정에서 오래된 정보를 제공할 수도 있어요.

확장 기법

기본적으로 Consul은 모든 DNS 결과를 0 TTL 값으로 제공하므로 가장 최신 정보를 반환해요. 대규모로 운영할 때는 서버가 모든 DNS 쿼리에 응답해야 하므로 이 구성이 추가 지연을 초래할 수 있어요. 데이터센터에서 이 부담을 분산하는 여러 전략이 있어요:

오래된 읽기 허용 (Allow Stale Reads). 쿼리를 리더로 전달하는 대신 리더 외의 다른 서버가 쿼리에 응답하도록 허용해요.
DNS TTL 구성. 노드 또는 서비스에 대한 DNS time-to-live(TTL) 값을 구성하여 컨테이너 운영 체제의 DNS 하위 시스템이 응답을 캐시할 수 있게 해줘요. 그러면 서비스가 외부 요청 없이 DNS 쿼리를 로컬에서 해결해요.
읽기 복제본 추가 (Add Read Replicas). 엔터프라이즈 사용자는 Raft 쿼럼에 참여하지 않고 클러스터 데이터를 복제하는 추가 Consul 서버인 읽기 복제본을 사용할 수 있어요.
서버 요청 방지를 위한 캐시 사용 (Use Cache). Consul 클라이언트가 에이전트 캐시를 사용하여 서비스 또는 노드에 대한 이벤트를 구독하도록 구성해요. watch를 설정한 후 로컬 Consul 클라이언트 에이전트는 Consul 서버에 쿼리하지 않고도 해당 서비스 또는 노드에 대한 DNS 쿼리를 해결할 수 있어요.

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

Scaling technique	Supported by client agents	Supported by dataplanes	Supported by Consul DNS Proxy
Configure DNS TTLs	✅	✅	✅
Allow Stale Reads	✅	✅	✅
Add Read Replicas	✅	✅	✅
Use Cache to prevent server request	✅	❌	❌

대규모로 운영하는 Consul 배포의 고려 사항에 대한 자세한 내용은 대규모 Consul 운영을 참고해 주세요.

TTL 값

에이전트 구성 파일에서 TTL 값을 구성하여 DNS 결과가 Consul 하류에서 캐시되도록 할 수 있어요. TTL 값이 높을수록 Consul 서버의 조회 수가 줄어들고 클라이언트의 조회 속도가 빨라지지만, 점점 더 오래된 결과를 제공하게 돼요. 기본적으로 모든 TTL은 0이라 캐싱을 방지해요.

HCL / JSON

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

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

캐싱 활성화

노드 조회의 캐싱을 활성화하려면 dns_config.node_ttl 값을 설정해 주세요. 예를 들어 10s로 설정할 수 있으며, 그러면 모든 노드 조회가 10초 TTL로 결과를 제공해요.

서비스 TTL은 더 세분화된 방식으로 지정할 수 있어요. 와일드카드 TTL을 기본값으로 하고 서비스별로 TTL을 설정할 수 있어요. 이는 dns_config.service_ttl 맵으로 지정해요. *는 모든 접두사의 끝에서 지원되며 정확한 일치(strict match)보다 낮은 우선순위를 가지므로, my-service-x가 my-service-*보다 우선해요. 와일드카드 일치를 수행할 때 가장 긴 경로가 고려되므로 my-service-* TTL이 my-* 또는 * 대신 사용돼요. 같은 규칙으로 다른 것이 일치하지 않으면 *가 기본값이에요. 일치하는 항목이 없으면 TTL은 0으로 기본 설정돼요.

예를 들어, 와일드카드 TTL과 특정 서비스에 대한 특정 TTL을 제공하는 dns_config는 다음과 같을 수 있어요:

HCL / JSON

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

{
  "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을 정의할 수 있으며, 쿼리 정의를 업데이트하여 즉시 변경할 수 있어요. 준비된 쿼리에 TTL이 구성되지 않으면 위에서 설명한 대로 Consul 에이전트에 정의된 서비스별 구성으로 대체되고, Consul 에이전트에서 서비스에 대해 TTL이 구성되지 않은 경우 궁극적으로 0으로 대체돼요.

오래된 읽기 (Stale reads)

오래된 읽기는 DNS 쿼리의 지연을 줄이고 처리량을 높이는 데 사용할 수 있어요. DNS 쿼리의 오래된 읽기를 제어하는 데 사용되는 설정은 다음과 같아요:

오래된 읽기를 활성화하려면 dns_config.allow_stale를 true로 설정해야 해요.
dns_config.max_stale는 DNS를 쿼리할 때 결과가 얼마나 오래되어도 되는지 제한해요.

이 두 설정으로 오래된 읽기를 허용하거나 방지할 수 있어요. 아래에서 두 가지의 장단점을 논의할게요.

오래된 읽기 허용

Consul 0.7.1부터 allow_stale이 기본적으로 활성화되며, 거의 무한에 가까운 임계값(10년)을 기본값으로 하는 max_stale 값을 사용해요. 이는 리더가 없는 장기 장애 시에도 DNS 쿼리가 계속 제공되도록 해줘요. 또한 에이전트가 5초 이상 오래된 DNS 쿼리를 제공하는 시점을 추적하는 새 텔레메트리 카운터 consul.dns.stale_queries가 추가됐어요.

HCL / JSON

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

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

참고

위의 예시는 기본 설정이에요. 명시적으로 설정할 필요는 없어요.

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

오래된 읽기 방지

오래된 읽기를 방지하거나 얼마나 오래되어도 되는지 제한하려면 allow_stale을 false로 설정하거나 max_stale에 더 낮은 값을 사용하면 돼요. 첫 번째를 수행하면 모든 읽기가 단일 리더 노드에 의해 처리되도록 보장해요. 그러면 읽기가 강력하게 일관적이지만 단일 노드의 처리량에 의해 제한돼요.

HCL / JSON

dns_config {
  allow_stale = false
}

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

부정 응답 캐싱

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

SOA 구성

Consul v1.3.0 이상에서는 SOA 응답을 조정하고 일부 리졸버의 부정 TTL 캐시를 수정할 수 있어요. 이는 soa 구성 내의 soa.min_ttl 구성을 사용하여 달성할 수 있어요.

HCL / JSON

dns_config {
  soa {
    min_ttl = 60
  }
}

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

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

Consul DNS 확장