Consul 서비스 디스커버리 개요

Consul 서비스 디스커버리 개요

서비스 디스커버리는 '이 서비스가 지금 어디에 있지?'라는 질문에 답하는 작업이에요. Consul에 서비스를 등록해 두면 Consul DNS를 통해 애플리케이션 로드밸런싱과 정적 서비스 조회를 수행할 수 있고, 준비된 쿼리(prepared query)로 동적 조회와 서비스 장애 조치까지 처리할 수 있어요. 이번에는 Consul의 서비스 디스커버리가 어떤 원리로 동작하는지, 그리고 DNS 기반 조회가 왜 강력한지 차근차근 살펴볼게요.

출처: Discover services overview - HashiCorp Developer

본문

서비스가 Consul에 등록되면 카탈로그(catalog)가 그 서비스가 위치한 노드의 주소를 기록해요. 이어서 Consul은 자신이 수행한 각 헬스체크의 결과로 인스턴스의 카탈로그 항목을 갱신해요. Consul 에이전트들은 Raft 합의 프로토콜을 사용해 카탈로그 정보를 서로 복제하므로, 어떤 Consul 에이전트를 거치든 고가용성(high availability) 서비스 네트워킹이 가능해요.

Consul의 서비스 디스커버리 동작은 Consul DNS 주소를 사용해 정상(healthy) 서비스 인스턴스로 트래픽을 라우팅하고, Consul에 등록된 서비스 노드에 대한 정보를 돌려줘요.

애플리케이션 로드밸런싱

Consul은 카탈로그에 등록된 정보와 Consul DNS를 사용해 정상 서비스 인스턴스로 트래픽을 보내는 로드밸런서 역할을 해요. NGINX·HAProxy 같은 외부 로드밸런서와도 통합할 수 있어서, 기존 로드밸런싱 인프라와 함께 쓰기도 좋아요.

정적 조회

정적 조회(static lookup)는 알려진 서비스 인스턴스를 DNS 이름으로 직접 찾는 방식이에요. 별도의 쿼리 상태를 관리하지 않고도 이미 등록된 서비스의 주소를 얻을 수 있어서, 단순하고 빠르게 동작해요.

준비된 쿼리 (Prepared queries)

준비된 쿼리는 동적 서비스 조회와 장애 조치(failover)를 위해 미리 정의해 둔 쿼리예요. 쿼리를 실행하는 시점에 정상 인스턴스 중에서 트래픽을 보낼 대상이 결정되므로, 인스턴스 추가·제거가 잦은 환경에서 유용해요.

제약, 한계, 트러블슈팅

서비스 디스커버리 기능을 쓸 때 알아두면 좋은 제약 사항은 다음과 같아요.

  • Consul의 DNS와 서비스 디스커버리 기능은 기본적으로 활성화돼 있어요. Consul 서비스 메시를 활성화한 경우에는 Consul의 transparent proxy를 구성해 CoreDNS 같은 기존 DNS를 사용할 수도 있어요.
  • Consul 서비스 메시가 활성화된 경우, 서비스 디스커버리 동작에 추가로 영향을 주는 구성 항목(configuration entry)을 사용할 수 있어요.
    • service resolver 구성 항목으로 Consul의 로드밸런싱 정책을 직접 커스터마이즈할 수 있어요.

💡 참고: Consul을 Kubernetes나 AWS ECS에서 실행 중이고, 런타임이 제공하는 내장 서비스 디스커버리를 Consul의 서비스 메시 기능과 함께 쓰고 싶다면 transparent proxy 모드로 서비스를 온보딩하면 돼요.

더 알아보기