데이터 손실 없이 사이트 이름 변경하기
고객이 사이트 이름을 acme-staging에서 acme로 변경해 달라고 요청합니다. 앱에서 이름을 변경합니다. 갑자기 모든 데이터베이스 백업, 스크린샷, 썸네일이 사라집니다.
파일은 여전히 디스크에 존재합니다. 새 디렉토리는 그냥 비어 있습니다. 데이터가 이름 변경을 따라가지 않았습니다.
저희는 초기 설계에서 이 실수를 저질렀습니다. 파일 저장 위치를 결정할 때 사이트 이름을 사용했습니다.
만약 파일을 backups/acme-staging/에 저장한 뒤 사이트 이름을 acme로 변경하면, 앱은 backups/acme/를 찾습니다. 그러면 빈 폴더를 발견하게 됩니다. 기존 데이터는 이전 폴더에 그대로 남아 있지만, 앱은 이를 다른 사이트의 오래된 데이터로 취급합니다.
사이트 이름은 자주 바뀝니다. 고객이 오타를 수정하기도 하고, 팀이 스테이징 사이트를 운영 환경(production)으로 옮기기도 하며, 회사가 조직 개편을 하기도 합니다.
저희는 표시 이름(display name)과 안정적인 식별자(stable identifier)를 분리하여 이 문제를 해결했습니다.
이제 모든 사이트는 고유한 ID를 가집니다. site_a1b2c3d4e5f6와 같은 형태입니다. 이 ID는 절대 변하지 않습니다.
이제 이름 대신 ID를 사용하여 파일을 저장합니다. 디렉토리 경로는 backups/site_a1b2c3d4e5f6/와 같은 형태가 됩니다. 사이트 이름을 변경하더라도 경로는 그대로 유지됩니다. 데이터가 계속 연결되어 있는 것입니다.
기존 사용자를 이 시스템으로 이전하는 것이 가장 어려운 부분이었습니다. 저희는 멱등성(idempotent) 마이그레이션을 구축했습니다. 이는 시스템이 시작될 때 ID가 있는지 확인한다는 의미입니다. 사이트에 ID가 없으면 시스템이 하나를 할당합니다. 이미 있다면 시스템은 그대로 둡니다.
물리적 파일도 마이그레이션했습니다. 시스템이 사이트 이름으로 된 폴더를 발견하면, 이를 새로운 ID 형식으로 이름을 변경합니다.
로그까지 수정했습니다. 새로운 로그는 ID를 사용합니다. 오래된 로그는 사이트 이름을 사용합니다. UI에서는 이 둘을 결합하여 히스토리가 끊김 없이 이어져 보이도록 했습니다.
검증(validation)에 대해 뼈아픈 교훈을 얻었습니다. 업데이트 후, ID 형식을 확인하는 규칙을 추가했습니다. 규칙이 너무 엄격했습니다. 마이그레이션 과정에서 생성된 일부 오래된 ID들을 거부해 버렸습니다. 갑자기 사이트들이 다시 사라졌습니다.
교훈은 간단합니다. 새로운 규칙을 추가하기 전에 데이터를 먼저 감사(audit)하십시오.
사람이 보는 것과 시스템이 사용하는 것을 분리하는 것은 전형적인 패턴입니다. 출시 후에 이를 수행하는 것은 비용이 많이 들고 위험합니다. 이러한 함정을 피하려면 첫날부터 불변(immutable) ID를 사용하십시오.