도메인 이전할 때 사이트를 끊기지 않게 하는 방법

얼마 전 서버를 옮긴 뒤 사이트는 잘 열리는데 주문 확인 메일이 사라졌다는 연락을 받았다. 웹서버는 멀쩡했다. 도메인의 DNS를 새로 설정하면서 메일 레코드를 빠뜨린 게 원인이었다. 이런 장애는 서버 사양을 올려도 해결되지 않는다. 이전 전에 무엇이 도메인에 연결돼 있는지 확인하는 편이 훨씬 중요하다.

먼저 무엇을 옮기는지 구분한다

도메인 이전이라는 말은 두 가지로 쓰인다. 도메인을 관리하는 등록업체를 바꾸는 일과, 같은 도메인으로 접속할 서버를 바꾸는 일이다. 서버만 교체한다면 대개 등록업체를 옮길 필요가 없다. 반대로 등록업체를 바꿔도 DNS 설정을 그대로 유지하면 웹서버는 바뀌지 않는다. 이 둘을 한날에 처리하면 장애가 났을 때 원인을 좁히기 어렵다.

사이트 이전 일정부터 잡았다면 등록업체 로그인, DNS 관리 권한, 서버 접속 권한을 각각 확인한다. 도메인이 누구 명의로 등록됐는지도 봐야 한다. 제작사가 대신 등록한 도메인은 담당자 퇴사나 계약 종료 뒤에 인증 메일을 받지 못하는 일이 있다. 자동 갱신이 켜져 있어도 결제 수단이 만료됐다면 안심할 수 없다.

비용도 기능별로 나눠 보면 된다. 도메인 등록비와 서버 비용은 별개다. 월 방문자가 적은 소개 사이트라면 도메인을 옮긴다는 이유만으로 비싼 VPS를 살 필요가 없다. 현재 서버의 CPU·메모리 사용량과 실제 동시접속을 보고 서버를 고르고, 도메인에는 갱신과 DNS 관리가 가능한지만 확인하면 된다.

DNS를 바꾸기 전에 현재 값을 남긴다

저는 이전 작업을 시작하면 DNS 화면부터 기록한다. 웹 접속에 쓰는 A와 AAAA, 별칭에 쓰는 CNAME, 메일 수신용 MX, 발신 인증에 쓰는 TXT를 빠짐없이 적는다. 메일 서비스를 쓰지 않는다고 생각했는데 문의 양식의 발신 인증 레코드가 남아 있는 경우도 있다. 화면 캡처만 남기지 말고 이름·종류·값·TTL을 표로 옮겨 두면 변경 전후를 비교하기 쉽다.

특히 네임서버를 통째로 바꿀 때 사고가 많다. 새 DNS 관리 화면에 웹 접속 값만 입력하면 사이트는 열려도 메일이나 소유권 인증이 실패할 수 있다. DNSSEC를 사용 중이라면 새 DNS 설정과 등록업체에 등록된 DS 정보가 맞는지도 확인해야 한다. 둘이 어긋나면 일부 이용자에게 도메인이 아예 조회되지 않을 수 있다.

변경 하루나 이틀 전에는 바꿀 레코드의 TTL도 확인한다. TTL은 조회 결과를 얼마나 오래 보관할지 나타내는 값이다. 예를 들어 1시간으로 설정돼 있었다면 변경 직전에 5분으로 낮춰도 이미 1시간짜리 값을 받아 간 곳에는 즉시 적용되지 않는다. 미리 낮춘 뒤 기존 TTL이 지날 시간을 확보해야 한다. 다만 TTL을 낮춘다고 모든 이용자가 정확히 5분 뒤 새 서버로 접속하는 것은 아니다.

새 서버는 연결을 바꾸기 전에 시험한다

새 서버에 파일과 데이터베이스를 복원한 다음, 도메인 연결을 바꾸기 전에 직접 접속 경로를 지정해 시험한다. 첫 화면만 보는 것으로는 부족하다. 로그인, 게시글 작성, 결제 직전 단계, 이미지 업로드, 문의 메일 발송처럼 데이터가 오가는 기능을 확인한다. 사이트 규모가 작아도 이 순서는 같다.

기존 서버의 백업은 파일과 데이터베이스를 함께 남긴다. 백업 파일이 있다는 사실보다 실제로 복원되는지가 중요하다. 저는 이전 전에 빈 환경에서 복원해 보고, 작업 직전에 데이터베이스를 한 번 더 백업한다. 주문이나 회원가입이 계속 발생하는 사이트라면 두 서버에 데이터가 갈라지지 않도록 쓰기 중단 시간이나 데이터 동기화 방법도 정해야 한다. DNS만 바꾸고 두 서버를 동시에 운영하면 새 서버에 들어온 주문과 옛 서버에 들어온 주문이 나뉠 수 있다.

SSL 인증서도 새 서버에서 준비한다. 기존 서버에서 접속이 안전했다고 새 서버까지 자동으로 안전해지는 것은 아니다. 인증서 발급 방식과 갱신 작업이 새 환경에서 동작하는지 확인하고, 웹 접속을 강제로 보안 연결로 보내는 설정도 시험한다. IPv6 주소를 가리키는 AAAA 레코드가 있다면 새 서버의 IPv6 연결까지 확인한다. A 레코드만 바꾼 뒤 일부 이용자만 옛 서버를 보는 원인이 되기도 한다.

전환 뒤에는 양쪽 서버를 함께 본다

준비가 끝나면 바꾸기로 한 DNS 레코드만 수정한다. 메일 서비스를 옮기지 않는다면 MX를 건드리지 않는다. 변경 직후에는 내 컴퓨터 한 대에서 접속된다는 사실만 믿지 말고, 여러 네트워크에서 웹 접속과 메일 송수신을 확인한다. 서버 로그에서 요청이 어느 쪽으로 들어오는지도 본다. 기존 서버는 바로 끄지 않고, 이전 전에 설정돼 있던 TTL과 실제 접속 기록을 고려해 유지한다.

장애가 나면 확인 순서가 중요하다. 도메인 등록 상태와 만료일을 보고, 네임서버가 맞는지 확인한 뒤, DNS 응답이 새 주소를 가리키는지 확인한다. 그다음 새 서버의 웹 서비스 상태, 방화벽, 인증서, 애플리케이션 로그를 본다. DNS가 아직 옛 주소를 가리키는데 새 서버의 메모리부터 늘리는 건 시간을 낭비하기 쉽다.

등록업체까지 옮긴다면 서버 전환이 안정된 뒤 별도 일정으로 진행하는 편이 낫다. 이전 승인 메일을 받을 수 있는지, 도메인 잠금 상태와 이전 가능 조건은 어떤지 등록업체 화면에서 확인한다. 이전 전후의 DNS 설정도 비교한다. 저는 갱신 알림을 두 사람 이상이 받게 하고 결제 수단을 확인한다. 사이트가 오래 살아남는 데는 큰 서버보다 이런 작은 운영 절차가 더 자주 도움이 됐다.