모두
모두콘텐츠
얼마 전 서버 이전을 도왔는데, 새 서버는 멀쩡한데도 일부 방문자에게만 예전 화면이 보였다. 원인은 서버 성능이 아니라 도메인연결 순서였다. DNS 기록을 바꾸기 전에 기존 기록과 캐시 시간을 확인하지 않아, 방문자마다 서로 다른 서버로 접속하고 있었다.
도메인을 서버에 연결하는 일은 주소를 한 칸 입력하고 끝나는 작업이 아니다. 누가 DNS를 관리하는지, 어떤 기록이 웹 요청을 보내는지, 서버가 그 도메인을 받아들이는지까지 맞아야 한다. 이 세 가지를 순서대로 확인하면 대부분의 오류는 금방 좁혀진다.
먼저 DNS 관리 위치와 기존 기록을 확인한다
도메인을 산 곳과 DNS를 관리하는 곳은 다를 수 있다. 등록업체 화면에서 네임서버가 어디를 가리키는지 먼저 확인한다. 실제로 적용되는 기록은 현재 지정된 네임서버 쪽에 있다. 엉뚱한 관리 화면에서 A 기록을 바꿔 놓고 몇 시간을 기다리는 일이 생각보다 흔하다.
기록을 수정하기 전에는 현재 DNS 기록을 저장해 둔다. 특히 메일을 쓰고 있다면 MX 기록, 발신 인증에 쓰는 TXT 기록을 함께 확인해야 한다. 웹 접속만 고치려다가 메일 수신이나 발신 인증을 끊는 사고가 난다. 네임서버 자체를 바꿀 계획이라면 새 DNS 관리 화면에 필요한 기록을 먼저 옮겨 놓는 편이 안전하다.
서버에 맞는 기록을 넣고 중복을 없앤다
서버의 고정 IPv4 주소로 연결할 때는 보통 A 기록을 쓴다. IPv6까지 운영한다면 AAAA 기록도 함께 설정한다. 다만 서버가 IPv6 요청을 받지 못하는데 AAAA 기록만 남아 있으면 접속 환경에 따라 오류가 날 수 있다. 호스팅업체가 별칭 대상을 안내했다면 하위 호스트에는 CNAME 기록을 쓰는 경우도 있다.
여기서 확인할 것은 루트 도메인과 앞에 별도 이름이 붙는 도메인을 각각 어떻게 처리할지다. 두 주소가 모두 필요하다면 각 주소의 DNS 기록과 서버 설정을 모두 확인한다. 한쪽을 대표 주소로 쓰고 싶다면 나머지 주소에서 대표 주소로 이동시키는 설정도 서버에서 따로 해야 한다. DNS 기록은 접속할 서버를 찾게 할 뿐, 주소 이동까지 처리하지는 않는다.
같은 이름에 예전 A 기록과 새 A 기록이 함께 남아 있으면 요청이 두 서버로 갈 수 있다. 의도한 분산 구성이 아니라면 오래된 기록을 지운다. 반대로 메일용 기록이나 소유권 확인용 TXT 기록은 웹 연결과 무관해 보여도 함부로 지우면 안 된다.
서버 설정과 SSL을 DNS와 따로 점검한다
DNS가 새 서버를 가리켜도 웹서버가 해당 도메인을 받도록 설정되지 않으면 기본 페이지가 뜨거나 다른 사이트가 보일 수 있다. 웹호스팅이라면 관리 화면에 도메인을 추가하고, VPS라면 웹서버의 호스트 설정과 문서 경로를 확인한다. 애플리케이션이 허용 호스트 목록을 쓰는 경우 그 설정도 맞춰야 한다.
SSL 인증서도 별도로 확인한다. 인증서에 실제 접속할 도메인 이름이 포함돼 있어야 브라우저 경고가 나지 않는다. 자동 발급 방식은 도메인이 서버를 가리키고 인증용 요청에 응답할 수 있어야 진행되는 경우가 많다. DNS 검증 방식을 쓴다면 요구된 TXT 기록이 정확히 등록됐는지 확인한다. 인증서 발급이 끝나기 전에 보안 접속 강제 설정부터 켜면 방문자에게 오류 화면만 보일 수 있다.
서버를 새로 마련하는 중이라면 도메인연결 때문에 상위 요금제를 살 필요는 없다. 같은 도메인 설정은 저가 호스팅에서도 가능하다. 용량과 성능은 실제 트래픽, 동시 요청 수, 애플리케이션 자원 사용량을 보고 결정한다. 연결 오류를 CPU나 메모리 부족으로 오인해 요금제부터 올리는 경우를 자주 봤다.
전환 시간과 확인 순서를 잡는다
서버를 이전한다면 변경 하루 전쯤 웹 기록의 TTL을 300초 정도로 낮춰 둘 수 있다. 다만 기존 기록을 이미 받아 간 DNS 캐시는 이전 TTL이 끝날 때까지 남는다. 변경 직전에 TTL만 낮춘다고 모든 방문자가 곧바로 새 서버로 오는 것은 아니다. 기존 서버는 접속 흐름을 확인할 때까지 유지하고, 글쓰기나 주문이 있는 사이트라면 전환 중 데이터가 양쪽에 갈라지지 않도록 운영 방법도 정해야 한다.
확인은 단계별로 한다. 먼저 현재 네임서버가 맞는지 보고, 그다음 도메인의 A·AAAA·CNAME 기록이 의도한 대상을 가리키는지 확인한다. 이어서 새 서버의 호스트 설정, 실제 화면, 인증서 상태를 본다. 내 컴퓨터에서만 안 열린다면 브라우저나 운영체제의 DNS 캐시, 사내망의 DNS 캐시도 의심할 만하다. 반면 여러 접속 환경에서 같은 오류가 난다면 서버 설정이나 DNS 기록부터 다시 보는 게 빠르다.
화면이 뜬다는 이유만으로 작업을 끝내지는 않는다. 로그인, 이미지, 관리자 화면처럼 자주 놓치는 경로를 열어 보고, 메일을 쓴다면 송수신도 확인한다. 문제가 생겼을 때 되돌릴 수 있도록 변경 전 기록과 기존 서버 상태를 남겨 두는 편이 좋다. 도메인연결에서 시간을 아끼는 방법은 서둘러 기록을 바꾸는 게 아니라, 바꾸기 전 상태를 정확히 적어 두는 것이다.
