다운타임 없이 VPS를 새 업체로 옮기기

서버 이전 공포담에는 모두 같은 중간 부분이 있습니다. 누군가 DNS를 먼저 바꾸고 나서 복사를 시작한 것이죠. 이전 중 다운타임은 복사가 느려서 생기는 일이 거의 없습니다. 단계를 잘못된 순서로 밟아서 생깁니다.

다른 업체에서 넘어오든, 저희 요금제 사이에서 옮기든 통하는 순서는 이렇습니다.

1. 이틀 전: TTL 낮추기

바꿀 DNS 레코드(보통 A, AAAA, 그리고 이들을 가리키는 CNAME)를 찾아 TTL을 300초로 낮추세요. 그런 다음 최소한 예전 TTL만큼 기다립니다. TTL이 하루인 레코드는 변경 후에도 일부 리졸버가 하루 동안 예전 주소를 계속 내준다는 뜻이고, 서버에서 무엇을 해도 그걸 앞당길 수 없습니다.

사람들이 가장 많이 건너뛰는 단계이고, 5분이면 끝날 전환을 사용자 절반이 예전 서버를 보는 하루로 만드는 것도 바로 이 단계입니다.

2. 기존 서버 목록 만들기

이 머신을 다른 곳에 다시 세울 테니, 실제로 무엇을 하고 있는지 적어 두세요. 기억하는 것 말고, 실제로 하는 것을요.

ss -tlnp                                # what is listening, and which process
crontab -l; ls /etc/cron.d              # scheduled jobs
systemctl list-timers --all             # the scheduled jobs people forget
systemctl list-units --type=service --state=running

목록에 다음도 추가하세요. TLS 인증서와 갱신 방식, 비밀 값이 담긴 환경 파일, 방화벽 규칙, 사용자와 그들의 SSH 키, 데이터베이스와 그 크기, 그리고 IP 주소로 서버에 접근하는 모든 것. 마지막 그룹이 까다롭습니다. 파트너의 허용 목록, 결제 업체의 웹훅 설정, 모니터링 체크 같은 것들이죠.

3. 기존 서버 옆에 새 서버 세우기

새 서버를 주문하고 기존 서버는 그대로 두세요. VPS 목록에서 판매된 용량이 아니라 실제로 쓰는 양과 같거나 더 큰 디스크를 가진 요금제를 고르세요. 기존 머신이 들어오는 트래픽(웹사이트, 웹훅, API)을 조금이라도 받는다면 새 머신에는 전용 IPv4가 필요합니다. NAT 요금제는 SSH 포트로만 인바운드 연결을 받는데, 그게 왜 중요한지는 포워딩된 포트 하나로 할 수 있는 것과 없는 것에서 설명합니다.

접속해서 같은 패키지를 설치하고 사용자와 방화벽을 다시 만드세요. 키와 첫 로그인은 연결 가이드에 나와 있습니다.

4. 파일은 두 번 동기화하기

첫 동기화는 기존 서버가 계속 일하는 동안 모든 것을 복사합니다. 몇 시간이 걸려도 괜찮습니다.

rsync -aHAX --numeric-ids --info=progress2 /var/www/ root@203.0.113.10:/var/www/

--numeric-ids는 파일 소유자를 번호 그대로 유지해서, 두 시스템이 사용자를 다른 순서로 만들었을 때 생기는 고전적인 "모든 게 엉뚱한 사용자 소유" 사태를 막아 줍니다. SSH로 rsync를 써 본 적이 없다면 VPS로 파일 옮기기가 단계별로 안내합니다.

두 번째 동기화는 전환 직전에 하며, 첫 동기화 이후 바뀐 것만 복사합니다. 보통 몇 초면 끝납니다.

5. 데이터베이스는 신중하게 옮기기

파일은 쉽습니다. 쓰기를 받는 데이터베이스는 "다운타임 없음"에 작은 타협이나 추가 작업이 필요한 유일한 부분입니다.

간단한 방법: 테스트용으로 한 번 덤프해서 복원해 두고, 전환할 때 1분간 쓰기를 멈춘 뒤(앱을 읽기 전용으로 바꾸거나 중지), 새 덤프를 떠서 새 서버에 복원하고 거기서 앱을 시작합니다. 작은 프로젝트 대부분은 미리 공지한 1~2분의 중단이면 됩니다.

중단 없는 방법: 기존 데이터베이스에서 새 데이터베이스로 복제를 구성하고, 따라잡게 한 뒤 전환 시점에 새 쪽을 주 데이터베이스로 승격합니다. 준비가 더 들지만, 1분의 쓰기 손실도 받아들일 수 없다면 그럴 가치가 있습니다.

6. 다른 사람이 보기 전에 새 서버 테스트하기

DNS가 아직 기존 서버를 가리키고 있으니 새 서버는 조용히 테스트할 수 있습니다. 실제 도메인에 대한 요청을 새 주소로 보내세요.

curl --resolve example.com:443:203.0.113.10 https://example.com/health

인증서가 아직 없다면 같은 방식으로 HTTP로 테스트하거나, hosts 파일에 임시 줄을 넣고 브라우저로 사이트를 둘러보세요. 로그인, 업로드, 백그라운드 작업, 발신 메일을 확인하세요. 빠진 PHP 확장을 찾기에 가장 싸게 먹히는 순간입니다.

7. 전환하고, 기존 서버는 켜 두기

마지막 파일 동기화와 데이터베이스 단계를 마친 뒤 DNS 레코드를 바꾸세요. TTL이 300초면 트래픽 대부분이 몇 분 안에 넘어갑니다. 기존 서버의 접근 로그를 지켜보세요. TTL을 무시하는 리졸버와 클라이언트에서 여전히 요청이 조금씩 들어옵니다. 그대로 며칠 켜 두세요. 그다음 예전 IP를 가리키는 모든 것을 갱신합니다. 파트너 허용 목록, 웹훅 URL, 그리고 메일용으로 새 주소의 역방향 DNS(저희 전용 IP 요금제에서는 직접 설정합니다. 역방향 DNS 참고)와 SPF 레코드입니다.

가장 자주 망가지는 것

저희가 보는 빈도 순으로 대략 꼽으면 이렇습니다. 아무도 목록에 넣지 않은 systemd 타이머, 예전 IP가 하드코딩된 설정 파일, 엉뚱한 사용자 소유가 된 파일, 앱 자체 포트를 막는 방화벽, 기존 서버에서는 갱신되는데 새 서버에서는 갱신되지 않는 인증서, 그리고 새 주소에 아직 역방향 DNS가 없어서 스팸함으로 가는 메일.

이 체크리스트가 맞지 않는 경우

쓰기가 끊임없고 중단을 전혀 허용할 수 없는 바쁜 데이터베이스에는 블로그 체크리스트가 아니라 제대로 된 복제와 리허설이 필요합니다. Windows 서버는 rsync와는 다른 도구로 옮깁니다. 그리고 이전의 진짜 이유가 크기라면 이것부터 읽으세요. 여기서는 요금제를 그 자리에서 키울 수 있습니다. 같은 네트워크 유형의 더 큰 요금제로 바꾸면 이전 없이 재부팅 한 번으로 vCPU, 메모리, 디스크가 늘어납니다. 새 서버가 필요한 건 줄일 때뿐입니다. 머신이 충분히 큰지 확신이 없어서 옮기려는 거라면 정말로 64 GB 메모리가 필요할 때가 수고를 덜어 줄 수 있고, VPS가 맞는 선택인지 고민이라면 VPS, 공유 호스팅, 전용 서버, 클라우드 비교가 도움이 됩니다.