네임서버, 어떻게 만들어야 할까?
설치가 없는 트래픽 모니터링 서비스를 제공하기 위해, 저희 서비스는 네임 서버를 구현해 제공합니다. 🔗 상세한 동작 원리 확인하기
이 글에서는 저희가 네임서버를 구현하기 위해 고민한 점과, 결과적으로 채택된 기술을 간략히 설명합니다.
처음 기획 단계에서 필요한 기능은 간단해 보였습니다. DNS Query에 대해 항상 저희 프록시 서버의 IP만 응답하는 것입니다.
그러나 개발을 진행하고 실제 서비스 운영을 대비하면서 점점 많은 점을 고려하게 되었고, 다음과 같은 요소들을 포함하게 되었습니다.
cf. 네임서버 인스턴스 구성
-
2개의 서버 컨테이너와 Nginx
다른 서비스가 의존하게 되는 네임서버(프록시서버도 마찬가지)는 제로-다운타임이 특히 중요합니다.
이를 위해 2개의 컨테이너와 Nginx로 Blue-Green 배포를 수행합니다.
추가로, Nginx를 도입하면서 Least-Connection Load-Balanacing도 적용해 안정성을 높였습니다.
-
캐싱
아래에 설명하겠지만, 프록시 서버 헬스체크 실패시 가져올 원본 클라이언트 IP를 캐싱해두기 위해 Redis를 사용합니다.
두개 컨테이너의 캐시 동기화가 필요하기에 Redis를 채택했습니다.
위의 그림 "네임서버 인스턴스 구성"을 보면 알 수 있듯, 복잡한 프레임워크 대신 NodeJS만을 사용하였습니다. 초기 기획에서는 많은 기능이 예상되지도 않았기에 단순한 구조로 풀어낼 수 있겠다 기대하였습니다. 이에, 추상화 정도가 낮은 node:dgram 모듈과 dns-packet 등의 모듈만을 사용해 구현하기로 하였습니다.
Authoritative DNS Server로서 동작하기 위해 DNS 응답 패킷의 구조를 분석하였습니다. 이후, 필요한 Flag를 비트 연산으로 계산하고, Builder Pattern으로 응답 패킷을 만들어 dgram으로 전송합니다.
언제나 프록시 서버 IP만을 던져주면 편했겠지만, 서비스 안정성을 위해서 하나의 기능이 추가로 필요했습니다. 바로 헬스 체크(Health-Check) 기능입니다.
비동기적으로 & 주기적으로 프록시 서버에 간단한 GET /health-check 요청을 보내며 상태를 확인합니다.
프록시 서버가 정상 동작 중이 아니라면 Redis에 캐싱하는 서비스 제공자의 원본 IP로 응답해, 보통의 네임서버와 같은 역할을 합니다.
이를 통해 "왓치덕스의 프록시서버가 다운되면 모든 서비스가 마비되는 것 아닌가요?" 라는 질문에 자신 있게 답할 수 있게 되었습니다.
-
dgram과 dns-packet 라이브러리 선택의 이유?
-
헬스체크 도입 과정 및 결과가 궁금하다면?
-
DNS 패킷과 ClickHouse를 뜯어보며 DAU를 구현해본 경험이 궁금하다면? (프로젝트에서 제거됐지만..)