다운타임 없이 역외 호스팅으로 이전하기

재미로 라이브 사이트를 옮기는 사람은 없다. 옮기게 되는 이유는 대개 이렇다. 지금 쓰는 호스트가 갑자기 여권 사진을 요구하거나, 24시간 시한이 붙은 신고 메일을 그대로 전달하거나, 데이터센터가 있는 나라가 더 이상 데이터를 맡길 만한 곳으로 보이지 않게 되었기 때문이다. 무엇이 등을 떠밀었든 위험한 부분은 이전 그 자체다. 사이트가 먹통이 될 수 있는 유일한 순간이자, 부주의한 한 걸음이 벗어나려던 그 신원을 새 서버에 그대로 못박아 버릴 수 있는 유일한 순간이기 때문이다.

두 위험 모두 같은 처방으로 해결된다. 도구가 아니라 순서다. 순서를 제대로 지킨 마이그레이션에는 사이트가 응답하지 않는 구간이 아예 없다. 두 서버가 동시에 살아 있고 DNS는 가장 마지막에 옮기기 때문이다. 순서를 그르친 마이그레이션은 장애와 흔적을 한꺼번에 남긴다. 지금부터 다루는 것이 바로 그 순서이며, 흔한 대형 공급자 사이를 오가는 경우가 아니라 KYC 없는 역외 호스트로 옮기는 사람을 염두에 두고 썼다 — 절차 자체는 같지만 그 뒤에 남는 뒷정리는 전혀 다르다.

"무중단"이 실제로 의미하는 것

이 표현은 느슨하게 쓰이며, 사람들이 다치는 지점도 바로 그 느슨함이다. 두 대의 머신에서 동시에 HTTP를 서비스하는 것은 쉽다. 두 머신이 동시에 서비스하는 동안 상태를 일관되게 유지하는 것이 어려운 부분이며, 데이터를 잃는 유일한 부분이기도 하다. 그러니 무엇을 계획하기 전에 지금 자신이 실제로 다루는 대상이 이 둘 중 무엇인지부터 정하라. 그 답이 그날 밤 전체의 모양을 결정하기 때문이다.

공짜인 것은 첫 번째 행뿐이라는 점에 주목하라. 그 외에는 모두 "무중단"이 "아무도 티켓을 올리지 않을 만큼 짧은 쓰기 동결"을 의미할 뿐이다. 새벽 4시의 읽기 전용 2분은 오차 범위지만, 두 데이터베이스에 걸친 두 시간짜리 쓰기 분열은 주말을 통째로 잡아먹는 대사 작업이다. 동결 구간을 선택하라.

이전 예정일 며칠 전에 DNS TTL부터 낮춰라

선행 시간이 필요한 단계는 이것 하나뿐이다. 그래서 가장 먼저 나오고, 그래서 사람들이 가장 많이 건너뛴다. TTL — 즉 생존 시간(time to live) — 은 인터넷의 모든 리졸버에게 다시 묻기 전까지 레코드를 얼마나 캐시해도 되는지 알려주는 값이다. A 레코드의 TTL이 86400이라면, 한 시간 전에 조회한 리졸버는 등록기관에서 무엇을 바꾸든 상관없이 앞으로 23시간 더 예전 IP를 계속 내려준다.

결정적인 함정은 TTL을 낮추는 행위 자체도 기존 TTL의 지배를 받는다는 점이다. 리졸버는 캐시해 둔 예전 값이 만료되어야만 새로 짧아진 값을 알게 된다. 그러므로 TTL을 300초로 낮추는 시점은 전환 최소 한 번의 기존 TTL 주기 이전이어야 한다 — 하루짜리 TTL이었다면 24~48시간 전에 미리 낮춰야 한다는 뜻이다. 그러면 변경 후 5분 안에 전 세계가 새 레코드로 수렴하고, 전환은 더 이상 마음 졸이는 사건이 아니게 된다.

이전 후 며칠이 지나면 TTL을 다시 합리적인 값으로 올려 두라. 300초짜리 TTL은 도구로는 훌륭하지만 영구 설정으로는 나쁘다. 쿼리량을 몇 배로 늘리고, DNS 공급자를 훨씬 더 날카로운 단일 장애점으로 만들어 버린다.

기억이 아니라 실제로 옮길 것의 목록을 만들어라

실패한 마이그레이션의 사후 분석은 늘 똑같다. 아무도 목록에 적지 않은 무언가가 복사되지 않았다는 것이다. 웹 루트와 데이터베이스는 누구나 기억하는 두 가지이고, 아래 목록은 그 나머지다. 기억에 의존하지 말고 말 그대로 하나씩 짚어 볼 가치가 있다.

• 예약 작업. 모든 사용자에 대해 crontab -l을 확인하고, systemd 타이머도 함께 본다. 갱신 훅과 야간 작업이 여기 숨어 있다.
• 서비스 정의. 직접 작성한 systemd 유닛, 웹 서버 vhost, PHP-FPM 풀, supervisor 설정 전반.
• 시크릿과 환경 변수. .env 파일, API 키, 데이터베이스 비밀번호, 애플리케이션 salt — 이들은 그냥 복사만 할 것이 아니라 교체해야 한다는 점도 기억하라.
• TLS 자료. 인증서, 그리고 그보다 더 중요한 ACME 계정과 갱신 설정.
• 메일 신원. DKIM 개인 키, SPF와 DMARC 레코드. 여기서 어긋나면 요란하게 깨지지 않는다. 그저 조용히 메일이 스팸함으로 향할 뿐이다.
• 업로드된 미디어. 흔히 웹 루트 바깥에 있고, 흔히 가진 것 중 가장 용량이 크다.
• 당신의 IP를 신뢰하는 외부의 모든 것. 결제 게이트웨이 허용 목록, 웹훅 수신지, 데이터베이스 방화벽, IP 제한이 걸린 서드파티 API. 새벽 3시에 "사이트는 되는데 결제만 안 된다"는 사태의 원인 1순위다.
• 패키지 목록. dpkg --get-selections 또는 그에 준하는 명령으로, 새 서버가 "거의 같은" 확장 모듈과 라이브러리가 아니라 "완전히 같은" 것을 갖추게 한다.

복사를 시작하기 전에 이 목록부터 적어 두라. 이 목록은 나중에 테스트 계획이 되기도 한다 — 목록의 각 줄은 DNS가 새 서버의 존재를 알기 전에 그 서버에서 반드시 확인해야 할 항목이다.

새 서버부터 만들고, 무언가를 담기 전에 먼저 하드닝하라

목적지 서버는 일찍 주문해서 하루 이틀 정도는 빈 채로 그냥 돌아가게 두라. 겹치는 기간에 드는 비용은 사실상 없고 — 작은 역외 VPS는 한 달에 몇 달러면 된다 — 동결된 데이터베이스가 기다리는 시간 압박 속에서 서버를 구축하지 않아도 된다는 가치는 상당히 크다.

예전 환경을 의도적으로 맞춰라. 같은 배포판과 메이저 버전, 같은 PHP나 Node나 Python의 메이저 버전, 같은 데이터베이스 메이저 버전. 이 김에 현대화하고 싶은 유혹은 상당히 크지만 철저히 뿌리쳐야 한다. 전환 후 사이트가 망가진다면 바뀐 변수가 딱 하나이기를 바랄 것이다. 스택 업그레이드는 2주쯤 뒤, 롤백이 가능한 상태로, 아무 일 없는 어느 오후에 하라.

아직 비어 있을 때 하드닝하라. 키 전용 SSH, 기본 거부 방화벽, 자동 보안 업데이트 — 첫 시간 하드닝 체크리스트가 정확히 이 목록이며, 아무것도 없는 서버에 적용하는 편이 훨씬 쉽다. 데이터가 관할권을 옮길 만큼 민감하다면, 저장 데이터 암호화를 결정하기에도 바로 지금이 적기다. 나중에 손보려면 또 한 번의 마이그레이션이 필요해지기 때문이다.

데이터는 두 번 복사한다: 느린 1차, 빠른 2차

직관적으로는 모든 것을 전환 창 안에서 복사하고 싶어진다. 반대로 하라. 예전 사이트가 아무 문제 없이 트래픽을 처리하는 동안 며칠 전에 전체 복사를 한 번 돌리고, 전환 시점에는 바뀐 것만 옮기는 2차 복사를 돌려라. 1차 복사는 여섯 시간이 걸려도 아무도 눈치채지 못한다. 2차는 90초면 끝나며, 그것이 곧 당신의 다운타임 예산 전부다.

파일은 rsync -aHAX --numeric-ids가 권한, 소유권, 하드링크, 확장 속성을 그대로 보존한다. --numeric-ids 플래그가 중요한 이유는 새로 구축한 두 머신 사이에서 UID가 일치하는 경우가 드물기 때문이다. 이 명령을 미리 한 번 돌리고, 전환 직전에 같은 인자로 다시 한 번 돌려라 — 두 번째 실행은 델타만 전송한다.

데이터베이스도 같은 2단계 처리가 필요하지만 도구는 다르다. mysqldump --single-transaction이나 pg_dump를 쓰면 구축과 테스트의 기준이 될 일관된 초기 스냅숏을 얻는다. 전환 시점에는 짧은 쓰기 동결 동안 두 번째 덤프를 뜨거나 — 짧은 동결조차 부담스러운 큰 데이터베이스라면 — 며칠 전에 미리 새 서버를 예전 서버의 복제본으로 세팅해 따라잡게 한 뒤 승격시키는 방법도 있다. 복제를 쓰면 동결 시간이 초 단위로 줄어든다. 다만 두 시간짜리 마이그레이션이 이틀짜리 프로젝트로 늘어나기도 하니, 규모가 정말로 그것을 요구할 때만 쓰라.

DNS가 존재를 알기 전에 새 서버부터 테스트하라

공개 레코드를 단 하나도 바꾸지 않고도 새 IP에서 실제 호스트네임을 서비스해 볼 수 있으며, 반드시 그렇게 해야 한다 — 이것이 전환을 아무 사건 없이 끝내는 비결이다. 로컬 /etc/hosts에 도메인을 새 IP로 가리키는 줄을 추가하거나, 그마저 생략하고 요청 하나만 curl이 대신 처리하게 하라.

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

이제 목록을 하나씩 짚어 가라. 첫 페이지와 하위 페이지 세 곳을 열어 본다. 로그인한다. 폼을 제출한다. 파일을 업로드한다. 데이터베이스 연결이 새 로컬 연결이지 인터넷 너머 예전 호스트를 여전히 가리키고 있지는 않은지 확인한다 — 이 실수는 예전 서버를 해지하는 순간까지 완벽하게 작동해 버린다. cron 작업을 손으로 직접 실행해 출력을 읽는다. 리다이렉트를 확인하고, 존재하지 않는 URL이 200이 아니라 여전히 404를 반환하는지 확인한다.

TLS 인증서는 전환 후가 아니라 지금, 전환 전에 발급하라. DNS-01 챌린지를 쓰면 TXT 레코드로 도메인 소유를 증명하므로 A 레코드가 아직 예전 서버를 가리키는 동안에도 발급이 된다. DNS 변경 후에 HTTP-01 검증을 기다리면 그 공백 동안 초기 방문자 전원이 인증서 경고를 보게 된다 — 지키려던 바로 그 전환 창 안에서 스스로 만든 장애다.

전환, 순서대로

여기까지 왔다면 새 서버는 이미 구축되고, 하드닝되고, 데이터가 채워지고, 실제 호스트네임으로 테스트를 마쳤으며, 유효한 인증서까지 갖고 있다. 전환 자체는 이제 짧고 지루한 목록일 뿐이며, 그것이 목표다.

1. 사이트에 의존하는 다른 사람이 있다면 전환 창을 미리 공지한 뒤, 예전 사이트를 읽기 전용이나 유지보수 모드로 전환한다.
2. 예전 호스트의 cron과 백그라운드 워커를 끈다. 새 호스트에서 그것들을 시작하기 전에 반드시 먼저 해야 하며, 절대 나중이어서는 안 된다.
3. 마지막 rsync 델타 패스와 마지막 데이터베이스 덤프를 실행하고, 그것을 임포트한다.
4. 새 서버에서 애플리케이션을 시작하고, 최종 데이터를 대상으로 --resolve를 통해 스모크 테스트를 다시 돌린다.
5. A와 AAAA 레코드를 새 IP로 바꾼다. TTL이 300초라면 5분 안에 전 세계가 따라온다.
6. 새 호스트에서 cron과 워커를 켠다.
7. 두 접속 로그를 나란히 지켜본다. 트래픽이 예전 서버에서 빠져나가 새 서버에 나타나며, 예전 서버가 조용해지면 전환이 끝난 것이다.
8. 예전 서버는 일주일 동안 그대로 켜 두고 서비스하게 두고 건드리지 않는다. 그것이 곧 당신의 롤백이다.

사람들이 가장 많이 생략하는 것이 여덟 번째 단계이며, 목록 전체를 통틀어 가장 값싼 보험이기도 하다. 단돈 몇 달러로 DNS를 다시 되돌릴 수 있는 능력 — 5분이면 끝나는 복구 — 을 확신이 설 때까지 계속 쥐고 있을 수 있다.

마이그레이션이 남기고 가는 것

여기부터는 흔한 마이그레이션 가이드가 빼먹는 부분이며, 가격이 아니라 프라이버시 때문에 옮긴 경우라면 가장 중요한 부분이다. 사이트를 옮긴다고 그 이력이 지워지지는 않는다. 예전 구성에 대한 여러 공개·반공개 기록이 이전 후에도 영구히 남으며, 그것이 무엇인지 아는 것이 진짜 단절과 단절했다는 착각의 차이를 만든다.

정직하게 요약하면, 마이그레이션은 과거를 다시 쓸 수 없다 — 더 이상 보태지 않게 막을 수 있을 뿐이다. 그것만으로도 상당한 가치가 있지만, 이는 결정 자체를 바꿔 놓는다. 만약 위협 모델상 어떤 관찰자도 새 사이트와 예전 사이트를 연결할 수 없어야 한다면, 같은 도메인을 새 호스트로 옮기는 것만으로는 그것을 이룰 수 없으며, 전환 중에 아무리 조심해도 마찬가지다. 그런 경우라면 새 이름과 완전히 새로운 시작이 필요하며, 이는 다음 절에서 다룬다. 반대로 목표가 오늘 이후로 신원을 드러내는 기록을 더 만들지 않는 것, 그리고 법적 소재지를 스스로 고른 관할권으로 옮기는 것이라면, 이 이전은 정확히 그 목표를 달성한다. 이후에도 깨끗한 상태를 유지하는 습관은 서버 OpSec 가이드에서 다룬다.

도메인을 어떻게 할 것인가: 그대로 가져갈까, 새로 시작할까?

사이트와 도메인은 서로 독립적인 결정이지만, 둘을 하나로 뭉뚱그리는 경우가 흔하다. 호스팅은 오늘 옮기고 등록기관은 영원히 그대로 둘 수 있다. 서버를 바꾼다고 해서 도메인을 건드려야 할 이유는 전혀 없다. 그래야 하는지 여부는 전적으로 그 도메인이 이미 당신에 대해 무엇을 알고 있는지에 달려 있다.

• 도메인은 유지하고 등록기관만 바꾼다. 도메인에 가치가 있을 때 — 링크, 랭킹, 사람들이 직접 입력하는 이름 — 합리적인 선택이다. WHOIS 레코드의 이력이 아니라 미래만 바로잡으며, 모든 랭킹 신호를 그대로 유지한다. 대부분의 상업용 사이트에는 이것이 정답이다.
• 도메인은 그대로 두고 호스트만 바꾼다. 익명성이 아니라 관할권, 가동률, DMCA 대응 방침 때문에 옮기는 경우라면 더할 나위 없이 합리적이다. 가장 단순한 이전이며 SEO 위험도 전혀 없다.
• 새 도메인을 쓰고 예전 도메인은 리다이렉트한다. 랭킹은 보존되지만, 두 이름을 공개적으로 그리고 영구히 연결해 버린다. 연속성을 위해서는 선택할 수 있어도 프라이버시를 위해서는 절대 선택하지 마라 — 리다이렉트 자체가 곧 연결 고리다.
• 새 도메인으로 완전히 단절한다. 연결 고리를 진짜로 끊어내는 유일한 선택지이지만, 그동안 쌓은 모든 랭킹과 인바운드 링크를 대가로 치른다. 처음부터 비공개로 등록하라. 도메인의 익명성은 딱 최초 등록만큼만 보장되기 때문이다. 암호화폐로 익명 도메인 등록하기 가이드에서 이를 제대로 하는 방법을 다룬다.

신중하게 고르되, 전환 도중이 아니라 전환 전에 결정하라. DNS를 옮긴 뒤에 도메인에 대한 마음을 바꾸면 가장 까다로운 부분을 두 번 해야 한다.

예전 호스트를 제대로 폐기하라

전환 후 한두 주가 지나 새 서버의 로그는 지루해지고 예전 서버의 로그는 텅 비면, 예전 계정을 정리할 때가 된 것이다. 반드시 이 순서대로 하라. 곧바로 해지 버튼부터 누르고 싶은 유혹이 바로 당신의 데이터를 남의 디스크 위에 그대로 남겨 두는 지름길이기 때문이다.

1. 아직도 예전 IP를 가리키는 것이 없는지 확인한다. 서드파티 웹훅, 허용 목록, 모니터링에 하드코딩된 주소가 없는지, 그리고 mail이나 cpanel 같은 서브도메인처럼 깜빡 잊고 남겨 둔 DNS 레코드가 없는지 점검한다.
2. 그 머신에 있었던 모든 시크릿을 교체한다 — 데이터베이스 비밀번호, API 키, 애플리케이션 salt, DKIM 키, SSH 키. 이것들을 그대로 가져오지 마라.
3. 예전 서버에서 자신의 SSH 공개 키와 모든 지원 접근 권한을 제거한다.
4. 애플리케이션과 덤프, 백업을 삭제한 뒤 여유 공간을 덮어써서, 재활용된 볼륨을 대충 읽어도 아무것도 나오지 않게 한다.
5. 그런 다음에야 비로소 서비스를 해지하고, 예전 계정에 저장된 결제 수단을 모두 제거한다.

전체 순서를 한 페이지에

이유를 다 걷어내면 호스트 마이그레이션은 아홉 단계로 줄어들며, 그중 시급한 것은 단 두 가지뿐이다.

1. 이틀 전: DNS TTL을 300초로 낮춘다.
2. 이틀 전: 목적지 서버를 주문하고 하드닝하며, 예전 스택과 버전을 하나하나 맞춘다.
3. 며칠 전: 목록을 작성한다 — cron, 시크릿, TLS, 메일 키, 미디어, IP 허용 목록, 패키지.
4. 며칠 전: 호스트 간 첫 전체 데이터 복사를 실행한다.
5. 전환 창 전: DNS-01로 인증서를 발급하고 --resolve로 모든 것을 테스트한다.
6. 전환 창(분 단위): 쓰기를 동결하고, 예전 cron을 끄고, 델타 복사와 마지막 덤프를 실행한 뒤 새 앱을 시작한다.
7. 전환 창(초 단위): A 레코드를 바꾸고, 새 호스트에서 cron을 켠다.
8. 그다음 한 주: 예전 서버를 롤백용으로 계속 살려 두고, 두 로그 파일을 함께 지켜본 뒤 TTL을 다시 올린다.
9. 그 이후: 시크릿을 교체하고, 지우고, 해지한다 — 그리고 이 이전으로도 지울 수 없었던 것이 무엇인지 기억해 둔다.

이 목록에서 어려운 것은 하나도 없다. 아프게 되는 단계는 모두 순서를 어긴 단계다 — 당일 밤에야 낮춘 TTL, DNS 변경 후에야 발급한 인증서, 더 이상 정본이 아닌 머신 위에 여전히 무장된 채 남은 cron 작업. 순서만 제대로 지키면 마이그레이션에서 흥미로운 부분은 이전 그 자체가 아니라 서버를 어디에 둘지 고르는 일이 된다. 아직 정하지 못했다면 관할권 가이드에서 시작하라.