새 DB에 스냅샷을 복원한 뒤 앱에서 예전 데이터를 읽었습니다. 그런데 앱이 여전히 원본 DB 주소를 보고 있다면, 이 성공은 복원 검증일까요. Shakedown에서 백업을 확인할 때 가장 먼저 막아야 했던 거짓 성공입니다.
저는 복원한 새 대상의 주소로 앱을 바꾸고, 기존 데이터 조회와 새 쓰기를 모두 확인하는 것을 완료 조건으로 정했습니다. MySQL은 새 RDS 인스턴스에, MongoDB는 원본 replica set과 격리한 새 볼륨에 복원했습니다. 스냅샷이 있다는 사실에서 실제로 다시 사용할 수 있다는 증거까지 가는 과정입니다.
이 작업은 SoftBank Hackathon의 다중 DB 연결 보완 중 진행했습니다. 조사·구현·실험 실행에는 AI를 활용했으며, 저는 복원 대상의 격리와 앱 연결 확인을 요구하고 수동 복원·자동 백업의 완료 여부를 따로 판단했습니다. 이 글은 PR #29에 포함된 2026년 10월 10일의 전용 실험 기록입니다.
새 DB가 아니라 새 DB를 쓰는 앱을 확인했습니다
MySQL은 수동 RDS 스냅샷을 새 private·encrypted db.t3.micro 인스턴스로 복원했습니다. 원본 인스턴스에 덮어쓰지 않았습니다. 하지만 복원만으로 검증이 끝나지는 않습니다. 앱이 예전 URL Secret을 계속 사용하면, 정상 응답을 받아도 실제로는 원본 DB를 읽고 있을 수 있기 때문입니다.
그래서 DB만 만든 뒤 끝내지 않고 연결 설정까지 교체했습니다. 복원된 instance ID와 endpoint로 어댑터를 바꾸고 URL Secret을 다시 생성했습니다. 새 task definition은 그 Secret의 불변 버전을 참조하고, 앱은 같은 불변 이미지로 재배포했습니다. 앱 이미지가 아니라 연결 대상이 달라진 조건에서 기존 UUID·Unicode 행을 찾고 새 쓰기를 수행했습니다.
특히 응답에 나타난 DB 호스트도 함께 확인했습니다. 데이터가 같다는 검증과 읽은 대상이 바뀌었다는 검증이 있어야 원본 조회를 복원 성공으로 착각하지 않습니다.
| 확인 항목 | 필요한 이유 | 결과 |
|---|---|---|
| 기존 UUID·Unicode 행 조회 | 스냅샷의 데이터가 복원됐는가 | 확인 |
| 새 행 쓰기 | 읽기만 가능한 상태가 아닌가 | 확인 |
| 검증된 TLS 연결 | 복원 endpoint에도 연결 조건을 지키는가 | 확인 |
| 응답의 DB 호스트 변경 | 원본을 다시 읽는 거짓 성공이 아닌가 | 확인 |
실측 보고서는 자동 스냅샷이 available인 것도 기록합니다. 그러나 복원에 사용한 것은 수동 스냅샷입니다. 이를 자동 백업 복원이나 시점 복구(PITR) 성공으로 바꾸어 쓰지 않았습니다. RDS의 일반 복원 절차는 AWS 문서와 함께 확인할 수 있습니다.
MongoDB는 원본 replica set과 격리했습니다
MongoDB에서는 majority write 이후 선택한 secondary에 문서가 있는지 확인하고 해당 멤버를 정상 종료한 뒤 데이터 EBS를 스냅샷으로 남겼습니다. 원래 멤버는 다시 시작했습니다. 복원은 같은 AZ의 새 암호화 EBS 볼륨에서 진행했습니다.
복원 볼륨을 원래 replica set에 바로 합류시키면 스냅샷 자체를 읽은 결과와 기존 멤버의 복제 영향을 분리하기 어렵습니다. 먼저 복원 데이터만 독립적으로 읽을 수 있는지 확인하기로 했습니다.
XFS 파일시스템을 nouuid로 마운트하고, 별도 MongoDB 컨테이너에 볼륨을 연결했습니다. --network none으로 원본 replica set과 격리한 뒤 TLS와 맞는 관리자 자격으로 원래 문서를 읽고, 새 문서를 쓴 뒤 다시 읽었습니다.
여기서 확인한 것은 복원 볼륨의 데이터와 독립된 읽기·쓰기입니다. 전체 replica set을 다시 구성하거나 멤버를 자동 교체하는 검증이 아닙니다. 원본 볼륨을 교체하지 않았다는 점도 실험의 조건입니다.
자동 백업은 권한 경계에서 막혀 있었습니다
MongoDB 예약 스냅샷을 준비하는 과정에서 DLM 조회가 조직 SCP에 의해 명시적으로 거부됐습니다. SCP는 조직 차원에서 허용 권한의 경계를 정하는 정책입니다. 다른 스케줄러로 우회하거나 권한을 넓히는 작업은 하지 않았습니다. 따라서 MongoDB 자동 백업은 미활성·미검증 상태로 남았습니다. 복원 실험의 성공이 정기적으로 스냅샷을 남길 권한이나 동작까지 만들어 주지는 않습니다.
| 항목 | 이 실험으로 말할 수 있는 것 | 말할 수 없는 것 |
|---|---|---|
| MySQL | 새 RDS에 수동 스냅샷 복원, 앱 연결과 읽기·쓰기 | PITR, 장기 보관 정책의 검증 |
| MongoDB | 새 볼륨의 격리 standalone에서 데이터 확인 | 예약 백업 성공, 전체 replica set 복구 |
| 자동 테스트 | AWS 45개·로컬 12개 통과 | 실제 모든 장애나 서비스 E2E의 보장 |
실험 뒤에는 전용 실험에서 생성한 원본·복원 인스턴스, 스냅샷, Secrets의 제거를 별도로 확인했습니다. 앱 중지 API만 호출했다고 기반 자원이 정리되는 것은 아니기 때문입니다.
이번에 확보한 근거는 두 수동 복원 경로에서 기존 데이터를 읽고 새로 쓸 수 있다는 것입니다. 자동 백업과 전체 replica set 복구까지 완료한 것은 아닙니다. 처음의 질문으로 돌아가면, 복구 확인에는 “데이터를 읽었다”에 더해 “어느 대상에서 읽었는가”가 필요했습니다. MySQL의 DB 호스트 대조와 MongoDB의 격리 실행이 바로 그 질문에 답하는 장치였습니다.