DNS

네트워크 위의 기계는 원래 숫자 주소로만 서로를 찾습니다. 사람이 외우기에는 나쁜 형태입니다. 전화번호 열 자리를 외우는 것과 비슷한데, 자주 쓰는 서비스가 스무 개면 숫자도 스무 개가 됩니다.

초기에는 이름과 숫자를 짝지은 목록 파일을 각자의 컴퓨터에 넣어 두는 방식으로 버텼습니다. 연결된 기계가 수백 대일 때는 그럭저럭 돌아갔습니다. 문제는 기계가 늘면서 생겼습니다. 어딘가에서 주소 하나가 바뀔 때마다 새 목록 파일을 모두에게 다시 나눠 줘야 했고, 받지 못한 쪽은 사라진 주소로 계속 연결을 시도했습니다.

그래서 서버를 옮기는 일이 통보 작업이 됐습니다. "다음 주에 서버를 옮기니 주소가 바뀝니다" 라고 공지를 돌리고, 공지를 못 본 고객은 옮긴 날부터 접속이 안 됩니다. 옮긴 쪽은 아무 문제가 없는데 쓰는 쪽에서만 안 되는 상황이라 원인을 찾는 데도 오래 걸렸습니다. DNS 는 이 목록을 각자가 들고 있는 대신 한 곳에 두고 필요할 때마다 물어보는 구조로 바꾼 것입니다.

DNS 가 실제로 없애 주는 문제는 셋입니다.

1. 숫자를 외우는 문제입니다. 사람은 이름만 알면 되고 숫자는 기계가 그때그때 찾습니다. 이름과 숫자를 잇는 대응표가 한 군데 있어서 가능한 일입니다.
2. 주소가 바뀔 때 전파하는 문제입니다. 서버를 다른 기계로 옮겨도 이름과 숫자를 잇는 줄 하나만 고치면 되고, 쓰는 사람은 아무것도 하지 않습니다. 공지도 필요 없습니다.
3. 이름 하나에 여러 서버를 두는 문제입니다. 같은 이름에 주소를 여러 개 걸어 두면 요청이 나뉘어 들어가고, 한 대가 죽으면 그 주소만 목록에서 빼면 됩니다. 접속한 사람의 위치에 따라 다른 주소를 돌려주는 것도 여기서 나옵니다.

이름을 물어 주소를 받는 과정은 네 단계로 이어집니다.

1. 기계가 자기 안에 저장해 둔 기록을 먼저 봅니다. 조금 전에 같은 이름을 물었다면 여기서 끝나고 바깥으로 나가지 않습니다.
2. 없으면 인터넷 사업자나 회사가 운영하는 중계 서버에 묻습니다. 이 서버가 대신 찾아다닙니다.
3. 중계 서버는 위에서부터 차례로 내려갑니다. 최상위 서버에서 .com 을 아는 서버를 안내받고, 거기서 다시 그 도메인을 실제로 관리하는 서버를 안내받습니다.
4. 마지막 서버가 숫자 주소를 돌려줍니다. 중계 서버는 이 답을 정해진 시간 동안 보관했다가 같은 질문이 오면 다시 찾지 않고 그대로 내어 줍니다.

4번의 보관 시간을 TTL 이라고 부르고 초 단위로 지정합니다. 3600 이면 한 시간입니다. 길면 바깥에 묻는 횟수가 줄어 빠르지만, 주소를 바꿨을 때 옛 주소를 들고 있는 곳이 그 시간만큼 남습니다. 그래서 서버 이전이 잡히면 며칠 전에 60 초로 낮춰 두고 옮긴 뒤에 다시 올립니다.

이 기록에는 주소만 적히지 않습니다. 이 도메인의 메일을 어느 기계가 받는지, 외부 서비스가 도메인 소유를 확인할 때 읽는 짧은 문구 같은 것도 같은 자리에 들어갑니다.

DNS 를 통째로 대신하는 것은 없습니다. 이름으로 서로를 찾는 방식 자체가 인터넷의 약속이라, 쓰지 않겠다는 선택은 바깥 세상과 연결을 끊겠다는 말과 같습니다. 대신 특정 상황에서만 DNS 자리를 비켜서는 방법이 있습니다.

1. 숫자 주소를 직접 쓰는 방법입니다. 내부 도구를 급히 띄울 때 쓰지만, 주소가 바뀌면 그 주소를 적어 둔 모든 곳이 한꺼번에 깨집니다.
2. 기계마다 이름과 숫자를 적어 두는 목록 파일입니다. 지금도 각 컴퓨터에 남아 있어서 개발 중인 서비스를 자기 기계에서만 다른 주소로 보내는 데 씁니다. 그 한 대에만 적용된다는 점이 용도이자 한계입니다.
3. 회사 내부망에서 쓰는 서비스 디스커버리입니다. 프로그램이 수시로 뜨고 사라지는 환경에서 지금 살아 있는 주소를 자동으로 알려 주는 장치인데, 바깥에서 들어오는 요청에는 관여하지 않습니다.

그래서 실무에서 고르는 것은 DNS 를 쓸지가 아니라 어디에 맡길지입니다. 도메인을 산 업체가 기본으로 주는 것을 쓸 수도 있고, 자원을 가까운 거점에서 내려 주는 배포망인 CDN 업체나 클라우드 업체가 주는 것을 쓸 수도 있습니다. 뒤쪽을 고르는 이유는 접속한 사람의 위치에 따라 다른 주소를 돌려주는 기능이나, 장애가 난 지역을 자동으로 빼는 기능이 붙어 있기 때문입니다.

"지금 DNS 전파 기다리는 중이에요. TTL 이 3600 이라 한 시간은 봐야 합니다."

주소는 이미 바꿨지만 옛 답을 보관 중인 곳이 남아 있어 아직 전부에게 반영되지 않았다는 뜻입니다.

"그거 서버 문제 아니고 DNS 예요. 우리 쪽은 멀쩡한데 이름이 옛 주소를 가리키고 있어요."

장애의 원인이 서비스가 아니라 이름과 주소를 잇는 설정에 있다는 구분입니다.

"도메인은 샀는데 네임서버를 아직 안 바꿔서 화면이 안 떠요."

그 도메인을 실제로 관리할 서버를 지정하지 않아 질문이 엉뚱한 곳으로 가고 있다는 말입니다.

페이지덱이 지난달에 서버를 옮길 때 태오가 가장 먼저 한 일도 TTL 낮추기였습니다. 사흘 전에 3600 에서 60 으로 내려 두면, 옮기는 날 주소를 바꿨을 때 옛 주소를 들고 있는 곳이 1 분 안에 정리됩니다. 이 준비를 빼먹으면 옮긴 뒤 한 시간 동안 어떤 고객은 새 서버로, 어떤 고객은 꺼진 옛 서버로 들어갑니다.

전환이 끝난 뒤에는 다시 3600 으로 올렸습니다. 60 으로 두면 같은 질문이 계속 바깥으로 나가 첫 접속이 느려집니다.

설정을 바꾸면 바로 반영된다고 생각하는 경우가 가장 많습니다. 화면에서 값을 고치면 저장됐다는 표시가 곧바로 뜨니 그렇게 읽기 쉽습니다. 하지만 바뀐 것은 원본 한 곳이고, 곳곳의 중계 서버는 TTL 이 끝날 때까지 옛 답을 내어 줍니다. 이걸 모르면 자기 노트북에서는 새 화면이 보이는데 고객 문의는 계속 들어오는 상황을 장애로 오해하고, 멀쩡한 서버를 뒤지느라 시간을 씁니다.

DNS 가 데이터를 실어 나른다고 생각하는 것도 흔합니다. 주소를 알려 주는 단계에만 관여하고, 답을 받은 뒤의 통신은 기계와 서버가 직접 합니다. 요청을 여러 대에 나눠 보내는 로드 밸런서나 요청을 대신 받아 뒤로 넘기는 리버스 프록시는 오가는 내용을 전부 거치지만 DNS 는 그렇지 않습니다. 그래서 DNS 때문에 느려지는 것은 첫 질문 한 번뿐이고, 화면 전체가 계속 느리다면 원인은 다른 데 있습니다.