인수한 서비스 하나를 계약이 끝나는 옛 서버에서 새 서버로 옮기게 되어 전부 옮긴다고만 정하고 시작했다. 옮기고 나서 안 되는 것이 닷새 동안 하나씩 나왔다.
Table of contents
Open Table of contents
배경 — 전부가 무엇인지 몰랐다
uploads/ 가 빠져 있었고 crontab 의 예약 작업이 안 넘어갔으며 나가는 IP 가 바뀌어 상대가 막았고 /etc/cron.monthly 에서 월 한 번 도는 배치를 아예 몰랐다. 하나가 나올 때마다 그것만 옮기고 다음 것이 나오기를 기다리는 상태였다.
전부라는 말에는 무엇이 빠졌는지 판정할 기준이 없다. 목록이 없으면 남은 것을 셀 수 없으므로 언제 끝났는지도 알 수 없다.
해 본 것 — 명령으로 뽑은 목록
늦었지만 목록을 만들었고 그 뒤로는 새로 나오지 않았다. 코드와 MySQL 만 생각했는데 적어 보니 열두 항목이었다.
짐작으로 만들면 또 빠지므로 각 항목을 어디서 뽑았는지도 함께 적었다. 예약 작업은 crontab -l 을 계정마다 돌려 뽑고 서비스는 systemctl list-units --type=service 에서 뽑았다. 열려 있는 파일 경로는 lsof -p 로 뽑고 나가는 연결은 ss -tnp 로 뽑으니 짐작보다 정확했고 외부 연동 세 곳도 그렇게 찾았다.
검증 — 확인 방법과 되돌림 기간
항목마다 옮긴 뒤 무엇을 보면 되는지를 같이 적었다. 파일은 개수와 du -sb 총 크기를 양쪽에서 재서 비교했는데 심링크 때문에 복사 방식에 따라 개수가 달라진 적이 있었다. rsync 매뉴얼대로 -l 은 심링크를 심링크로 옮기고 -L 은 가리키는 실체로 바꿔 옮기므로 어느 쪽을 썼는지가 개수를 가른다.
되돌리는 방법과 되돌릴 수 있는 기간도 미리 적었다. 새 서버에서 쓴 데이터가 옛 서버에 없으므로 전환 뒤 한 시간이 지나면 되돌리는 것이 아니라 새 데이터를 옛 서버로 옮기는 작업이 된다는 것을 알렸다.
막힌 지점 — 남이 해 줘야 하는 것의 순서
순서를 정하면서 외부 연동의 IP 등록 요청을 앞으로 당기는 쪽을 골랐다. 이유는 상대 쪽 처리가 며칠 걸리므로 마지막에 두면 그만큼 전체가 밀려서다. 대신 등록이 끝난 뒤 전환일이 바뀌면 다시 요청해야 하는 것을 감수했다.
내가 하는 일은 내가 조절할 수 있지만 남이 해 줘야 하는 일은 그렇지 않다. 전환 뒤에도 옛 서버를 켜 두고 access.log 의 들어오는 요청이 0이 될 때까지 봤는데 그동안 빠뜨린 파일 하나를 가져올 수 있었다.
조치 — 다음 이관의 출발점
지난겨울 코로케이션으로 옮길 때 만든 목록이 있었는데 이번에는 그것을 꺼내지 않고 시작한 것이 실수였다. 이번 목록은 그 위에 항목을 지우거나 더한 것이고 처음부터 뽑는 것과 달랐다.
지난번에 놓쳐서 고생한 항목이 목록에 남아 있어서 같은 것을 두 번 놓치지 않았다. 목록은 한 번 쓰고 버리는 것이 아니라 다음 이관의 출발점이었다.
정리
- 전부라는 말에는 빠진 것을 판정할 기준이 없다
- 목록이 없으면 남은 것을 셀 수 없다
- 짐작으로 만들지 말고 명령으로 뽑는다
- 나가는 연결까지 봐야 외부 연동이 드러난다
- 항목마다 옮긴 뒤 확인 방법을 같이 적는다
- 되돌리는 방법과 되돌릴 수 있는 기간을 정하고 알린다
- 남이 해 줘야 하는 것을 먼저 요청한다
- 목록은 다음 이관의 출발점이 된다