[Prometheus] dns_sd_config vs static config

 

dns_sd_config와 static config 차이는 정말 단순한데, 구글링을 해보면 마음에 드는 설명이 없어서 정리한다.

dns_sd_config와 static conifg의 차이를 이해하기 위해서는 먼저 service discovery에 대해 이해해야 한다.

 

보통 클라이언트와 서버가 있고, 클라이언트가 서버를 호출하는데 이 때 클라이언트는 서버의 ip를 반드시 알아야 한다. 따라서 보통 다른 서버를 호출해야하는 client 기능을 갖는 application의 config 파일에는 호출하는 대상 서버의 ip 리스트가 나열되어 있다. (springboot에서는 application.yaml 이라고 생각하면 됨 - 단순 예시이며, 사실 일반적인 springboot application의 경우 service discovery 메커니즘을 사용할 일이 거의 없음)

ex) A 서버가 B, C, D 셋 중에 하나를 호출할 경우, B, C, D의 ip를 config에 가지고 있어야 함.

그런데 서버를 운영하다가, E, F, G 등 호출해야하는 서버가 많아지면 어떻게 될까?

A 서버 입장에서는 그 때 마다 config 파일을 수정해줘야하고, 새롭게 빌드 혹은 배포를 그때마다 진행해줘야 한다.

특히 prometheus와 같이 pull 방식으로 메트릭을 수집하는 입장에서는 target service가 추가될 때 마다 이 작업을 해줘야하는데, 수 백개의 target service가 있는 prometheus를 운영하는 사람 입장에서는 이 과정이 힘들 수 밖에 없다.

따라서 중간에 B, C, D, E, F, G 등의 ip를 포함한 다양한 메타데이터를 제공하는 컴포넌트를 하나 두고, A 서버 입장에서는 주기적으로 해당 컴포넌트에게 request를 날려서(혹은 해당 컴포넌트에서 관리하는 메타데이터가 변경되는 경우 A 서버에게 알려줌), 데이터를 받고, 그 받은 데이터를 통해 B, C, D 등에게 request를 날리는 것이 service discovery 메커니즘이다.

 

간단히 서비스 플로우를 나타내면 아래와 같다.

A 서버 -> Service Discovery Component로 요청 (target service ip 및 메타데이터를 요청)

Service Discovery Component는 A 서버에서 B, C, D의 ip 및 메타데이터 리스트를 응답.

A 서버는 Service Discovery Component의 응답을 받아 까본 뒤 B, C, D에 다시 request.

B, C, D는 A 서버에서 자신의 데이터를 응답.

 

개인적으로 이것은 단순히 prometheus (여기서는 A) 서버의 담당자에게 귀찮음을 제거해주는 것 이상의 의미를 지닌다고 생각하는데, 우선은 target service를 추가해주는 것의 자동화와 그리고 책임(?)에 대한 분리이다. 중간에 service discovery를 제공하는 계층을 하나 두면서 prometheus는 prometheus의 역할에 충실하도록 하고, application이 각각 지니는 메타데이터를 tag 등을 활용해서 스스로 직접 변경할 수 있도록 한다는 것이다.

 예를 들어, application 마다 metric을 제공하는 path가 다를 수가 있는데, service discovery 및 tag 기능을 사용하지 않는 경우 이 path가 변경될 때 마다 전부 prometheus에서 작업을 하고 재배포를 해야 된다. 하지만 이 정보는 엄연히 application에 속하는 특징이므로, 원래는 prometheus가 변경되는 것은 없어야 맞다. 따라서 service discovery 및 tag (service discovery에 tag는 기본으로 따라다님)를 활용해서 책임을 완전히 분리시키는 것이다.

 

다시 처음으로 돌아와서, dns_sd_config는 프로메테우스에서 지원하는 수 많은 service discovery 메커니즘 중에 하나이다. dns_sd_config는 nslookup 혹은 dig로 특정 도메인 질의를 하였을때 단일 ip가 아닌 ip 리스트를 반환해주는데, 이 때 ip리스트를 받아서 모든 ip를 다 target으로 등록해주겠다는 얘기이다. 현재 내가 알기로 file_sd_config를 제외한 모든 service discovery는 이 리스트 정보가 변했는지 체크하는 작업을 prometheus에서 하고 있으며, interval 속성 값을 통해 조절할 수 있다. 

반면 staitc config는 static config에 도메인을 넣더라도, dns 서버가 리턴해주는 하나의 ip에 대해서만 요청한다.

그리고 당연히 sd_config에서는 저절로 추가되고 빠지는 target이 존재하지만, static에서는 무조건 고정이다.

 

추가)

이 개념은 prometheus의 설정 중 job을 구분하는 기준 및 up 메트릭과도 연관이 있다.

static config에서 단순히 하나의 서비스를 Job 단위로 하게 되면 service discovery를 사용하는 job 단위와 맥락이 맞지 않을 수 있다. 따라서 생각하는 것보다 더 큰 단위로 job을 구분지어야 할 것이다. (service discovery job이랑 맥락을 맞추려면)

또한 static config와 달리 service discovery는 up 메트릭이 사라졌다 추가됐다 한다. 따라서 sd를 사용할때 up 메트릭에 대한 false alert에 대해 잘 생각해보고 설정해야 한다.