Datadog은 지난 18개월간 마이크로서비스 아키텍처의 구성 정보 배포와 서비스 디스커버리를 위해 Consul을 핵심 기술로 활용해 왔습니다. Consul 클러스터의 안정성을 유지하기 위해서는 Raft 합의 알고리즘을 뒷받침할 충분한 CPU 자원 확보와 dnsmasq를 활용한 쿼리 부하 분산이 필수적이며, 모든 변경 사항은 감사 가능한 구조로 관리해야 합니다.

Consul 서버의 CPU 리소스 확보

Consul 서버는 Raft 프로토콜을 통해 리더를 선출하며, 500ms 동안 리더의 응답이 없으면 새로운 리더 선출 과정(leadership transition)이 시작됩니다.
빈번한 리더 교체는 시스템 불안정의 신호이므로, 시간당 1회 이상 발생한다면 서버의 CPU 성능을 높여야 합니다.
에이전트 노드 수에 따른 권장 사양은 300대 기준 m3.large, 500대 기준 c3.xlarge, 800대 기준 c3.2xlarge 수준입니다.

감사 가능한 구성 변경 관리

Consul의 KV(Key-Value) 스토리지에 데이터를 직접 저장할 경우 변경 이력을 추적하기 어렵다는 위험이 있습니다.
Datadog은 git2consul을 사용하여 Git 저장소의 내용을 Consul에 동기화함으로써, 누가 언제 무엇을 변경했는지에 대한 감사 추적(Audit trail)을 유지합니다.
이를 통해 클러스터 전체의 구성 변경을 60초 이내에 안전하고 신속하게 수행합니다.

ACL과 Watch를 이용한 부하 및 보안 관리

ACL(Access Control List) 기능을 활용하여 권한이 있는 프로세스만 데이터를 수정하도록 제한하고, 실수로 인한 데이터 삭제 범위를 국소화해야 합니다.
Consul은 Redis처럼 초당 수십만 건의 읽기/쓰기를 처리하도록 설계되지 않았으므로, 변경 사항을 효율적으로 감지하기 위해 'Watch' 기능을 활용해야 합니다.
다만 Watch가 예기치 않게 과도하게 실행되는 것을 방지하기 위해 sifter와 같은 도구를 병용하는 것이 좋습니다.

dnsmasq를 통한 DNS 부하 경감

서비스 디스커버리를 위해 Consul DNS 인터페이스를 직접 쿼리하면 부하가 집중될 수 있으므로, 각 노드에 dnsmasq를 설치하여 캐시 레이어로 활용해야 합니다.
Consul의 DNS TTL을 짧게(예: 10초) 설정하고, dnsmasq가 먼저 요청을 처리한 뒤 모르는 정보만 Consul에 묻도록 구성합니다.
매우 높은 트래픽 환경에서는 Consul 데이터를 로컬 호스트 파일로 캐싱하여 dnsmasq에 로드함으로써, Consul 직접 쿼리 수를 초당 400건 수준으로 유지하면서도 전체 DNS 요청은 초당 10만 건 이상 처리할 수 있습니다.

Consul 모니터링 필수 지표

리더 선출 상태를 확인하는 consul.consul.leader.reconcile.count와 리더 교체 주기를 알 수 있는 consul.serf.events.consul_new_leader를 모니터링해야 합니다.
리더와의 마지막 통신 시간을 나타내는 consul.raft.leader.lastContact와 Consul로 직접 들어오는 DNS 쿼리 양도 주요 관찰 대상입니다.
서버 노드의 CPU와 네트워크 사용량을 실시간으로 추적하여 인프라 병목 현상을 사전에 방지해야 합니다.

성공적인 Consul 운영을 위해서는 단순히 설치하는 것에 그치지 않고, 인프라 규모에 맞는 적절한 CPU 사양 선택과 캐싱 전략을 통한 부하 관리가 선행되어야 합니다. 특히 설정값 관리에 있어서는 git2consul과 ACL을 결합하여 보안과 이력 관리라는 두 마리 토끼를 모두 잡는 방식을 추천합니다.