모두
모두콘텐츠
얼마 전 카페24에서 산 도메인을 다른 서버로 옮긴다는 분이 네임서버부터 바꾸려 했다. 사이트는 옮길 수 있지만, 그 도메인으로 쓰던 업무 메일이 끊길 뻔했다. 14년간 이런 이전을 맡으며 본 장애는 서버 성능보다 DNS 기록을 빠뜨린 경우가 많았다. 카페24 도메인을 연결할 때도 먼저 확인할 것은 요금제가 아니라 지금 어디에서 주소를 관리하고 있는지다.
도메인을 산 곳과 DNS를 관리하는 곳부터 구분한다
도메인을 카페24에서 샀다고 해서 DNS 설정도 반드시 카페24에서 하는 것은 아니다. 등록 업체는 도메인의 소유와 갱신을 관리하고, 네임서버는 방문자가 접속할 서버를 찾을 때 참고할 DNS 기록의 관리 위치를 정한다. 현재 네임서버가 다른 업체를 가리킨다면 카페24 관리 화면에서 A 레코드를 고쳐도 실제 접속에는 반영되지 않는다.
카페24에서 구매한 도메인의 네임서버는 ‘나의 서비스 관리’의 도메인 관리 메뉴에서 확인하고 변경할 수 있다. 다른 업체에서 산 도메인이라면 구매한 업체의 관리 화면에서 바꿔야 한다. 카페24 안내도 웹호스팅, 서버호스팅, 쇼핑몰에 쓰는 네임서버를 구분한다. 예전에 메모해 둔 값을 그대로 넣지 말고 현재 이용 중인 서비스의 관리 화면에 표시된 값을 확인하는 편이 안전하다.
사이트만 다른 서버로 보내려는 경우에는 네임서버 전체를 바꿀 필요가 없을 수 있다. 현재 DNS 관리 위치를 유지한 채 웹 접속에 필요한 A 레코드만 새 서버 주소로 바꾸면 메일 설정을 건드리지 않고 이전할 수 있다. 다만 서버가 별도 도메인 연결 설정을 요구한다면 DNS 변경과 함께 그 설정도 끝내야 한다.
연결 전에 기존 기록을 빠짐없이 적어 둔다
DNS 화면을 열면 웹 접속에 쓰는 A·AAAA·CNAME 레코드만 보지 말고 MX와 TXT도 확인한다. MX는 메일 수신 경로, TXT에는 메일 발송 인증이나 외부 서비스 소유 확인 값이 들어갈 수 있다. 카페24 안내에도 네임서버를 바꾸면 기존 DNS 기록이 초기화되어 메일 등에 영향을 줄 수 있다고 적혀 있다. 메일을 쓰는 도메인이라면 이 부분이 사이트 접속보다 먼저다.
- 현재 네임서버와 A·AAAA·CNAME·MX·TXT 기록을 화면 캡처와 텍스트로 보관한다.
- 새 서버에 사이트 파일과 데이터베이스를 옮기고, 도메인 연결 설정을 미리 추가한다.
- 기본 도메인과 실제로 사용하는 보조 호스트가 모두 새 서버에서 열리는지 확인한다.
- SSL 인증서가 두 주소를 포함하는지, 새 서버에서 발급할 조건이 갖춰졌는지 확인한다.
카페24 웹호스팅으로 연결한다면 ‘나의 서비스 관리’의 도메인 연결관리에서 해당 도메인을 호스팅 계정에 붙여야 한다. DNS가 맞아도 호스팅 계정에 도메인이 등록되지 않으면 기대한 사이트가 뜨지 않을 수 있다. 반대로 도메인 연결만 해 두고 DNS가 예전 서버를 가리키면 방문자는 계속 예전 사이트로 간다. 두 설정은 따로 확인해야 한다.
이전 순서는 새 서버 준비부터 잡는다
운영 중인 사이트라면 이전 전날 DNS 기록의 TTL을 낮출 수 있는지 확인한다. 예를 들어 3,600초로 잡혀 있다면 300~600초로 낮춰 두는 방식이다. 이미 저장된 기록의 유효 시간이 지나야 효과가 있으므로 변경 직전에 낮춰도 즉시 빨라지지는 않는다. TTL을 조절할 수 없다면 기존 값이 유지되는 시간을 일정에 반영하면 된다.
파일과 데이터베이스를 복사한 뒤에는 새 서버에서 PHP나 웹서버 설정, 업로드 경로, 데이터베이스 접속 값을 확인한다. 게시판이나 쇼핑몰처럼 글과 주문이 계속 들어오는 사이트는 마지막 데이터 동기화 시점도 정해야 한다. 10분 동안 쌓인 주문이 이전 과정에서 빠지는 일이 DNS 전파보다 더 큰 사고가 될 수 있다. 가능하면 쓰기 작업을 잠시 멈추고 마지막 백업을 받은 다음 전환한다.
새 서버 준비가 끝나면 현재 DNS 관리 위치에서 필요한 레코드를 바꾼다. DNS 관리 주체 자체를 옮겨야 할 때만 네임서버를 변경하고, 기존 메일과 인증 기록을 새 관리 화면에 먼저 재현한다. 카페24 안내에서 DNS 레코드 변경은 대체로 30분~1시간, 네임서버 변경은 최대 24~48시간 정도를 잡는다. 이용자마다 예전 기록을 저장한 시간이 달라 잠시 서로 다른 서버로 접속할 수 있다. 그래서 옛 서버는 전환 직후 바로 해지하지 않는다.
접속이 안 되면 확인할 순서를 정해 둔다
장애가 나면 먼저 도메인 만료 여부와 현재 네임서버를 본다. 그다음 실제로 응답하는 A·AAAA 기록이 의도한 서버 주소인지 확인한다. 서버 주소가 맞다면 호스팅 계정의 도메인 연결, 웹서버 설정, SSL 인증서 순으로 본다. 브라우저에서 보안 경고가 뜬다면 DNS가 틀렸다고 단정하지 말고 인증서에 해당 주소가 포함됐는지 확인해야 한다.
메일만 끊겼다면 웹서버부터 다시 설정할 일이 아니다. MX 기록과 발송 인증용 TXT 기록을 이전 전 자료와 대조한다. 일부 이용자에게만 예전 화면이 보인다면 변경 시각과 TTL을 확인하고, 두 서버의 접속 기록을 함께 본다. 이런 식으로 범위를 좁히면 기다리면 풀릴 문제와 설정을 고쳐야 할 문제를 구별하기 쉽다.
도메인 이전에는 더 비싼 서버가 필요하지 않은 경우가 많다. 기존 서버가 트래픽을 감당하고 있다면 사양을 올리기 전에 백업 복원 가능 여부와 DNS 기록부터 챙기는 편이 낫다. 나는 이전 작업표에 서버 용량보다 메일 기록, 마지막 데이터 동기화, 옛 서버 해지 날짜를 먼저 적는다. 실제 장애를 막는 데는 그 세 줄이 더 자주 쓰였다.
