서론

최근 ELIV팀에서는 ELIV 도메인을 개발하면서, 사회공헌? 느낌으로 DNS 서비스를 만들어보자는 이야기가 나왔다

결론부터 말하지만 개발하고 빌드까지 마치는데 2일조차 안걸렸다

ELIV 팀원들은 파이썬, Node 계열(JS, TS)보다 PHP를 많이 사용해서
이번에도 PHP로 개발이 될뻔 했지만 DNS서버라는 특수성이 있어서 Go 언어로 만들기로 했다

이전의 ELIV DNS 구조

아직 블로그 사용법을 잘 몰라서 나름대로 열심히 표현을 해봤다

1차/2차 DNS 서버들이 KT IDC에 위치한 ELIV DNS 메인 서버와 통신하는 방식으로 Nginx Proxy를 통해 DNS에 사용되는 HTTP/HTTPS/TCP/UDP 통신을 모두 IDC로 보내도록 구성했다고 하는데 이 구조는 치명적인 문제가 있다

  1. KT IDC에 위치한 메인 서버의 의존도가 너무 높다
    혹여나 KT IDC에 문제가 발생한다면 모든 DNS 요청이 중지된다
    그러면 자연스럽게 ELIV DNS를 이용중인 디바이스들은 반오프라인 상태가 된다
  2. 일본 도쿄 <-> KT IDC (한국 서울)간의 거리가 있어서 레이턴시가 높다
    치명적인 문제는 아니지만 DNS의 레이턴시가 높다는건 인터넷이 느려졌다고 이용자들이 체감할 수 있게된다

가장 우려하는 문제가 첫번째 케이스인데, 이 문제가 실제로 일어났었다 (그래서 팀내부에서 구조를 바꾸자는 이야기가 나왔던거다)

새로운 구조 만들기 (+ 잡담)

새로운 구조를 팀 내부에서 생각을 해봤고 아래 두가지의 구조가 나왔다

  1. DNS 패스스루 (백업)
    ELIV DNS 서버가 다운된다면 1차 / 2차 DNS 서버는 ELIV DNS가 아닌 1.1.1.1 같이 안정성이 높은 DNS로 패스스루하는 구조
  2. 각 서버에서 단독적으로 ELIV DNS 가동
    각 1차 / 2차 DNS 서버에서 ELIV DNS를 직접 가동한다 (메인서버 없이 동작하게하자)

둘다 괜찮은 의견처럼 보이지만 두번째 구조는 큰 결함이 있다

ELIV DNS의 메인페이지는 지금까지 처리한 쿼리수를 표시하는데, DNS 서버를 나누면 이 기능을 구현하기 어렵다는것이다

그래서 두 구조를 하나로 합치기로 했다

평상시에는 ELIV DNS 메인서버와 통신을 하다가 ELIV DNS 메인서버에 문제가 발생하면 단독적으로 실행중인 ELIV DNS 애플리케이션으로 DNS를 패스루 하는 구조이다

사실 ELIV DNS는 Self Host가 가능한 Dedicated Application (단독 애플리케이션)을 계획했었고 실제로 개발이 끝난 상태였기때문에 각 서버에 적용하는건 무리가 없었다

ELIV DNS 단독 애플리케이션을 각 서버에 배포하고 1주일정도 지난 시점
자원을 얼마나 사용할까 궁금해서 확인해보니 메모리를 무려 6.44MB를 사용하고있었다

이번계기로 팀내부에서 Go언어를 많이 사용했으면 좋겠다

ELIV DNS 사용해보기