[2편] DB 마이그레이션, 안전하게 하려면?

 

안녕하세요, makeviibe입니다.

 

과거에 진행했던 프로젝트에서 EC2에 설치된 기존 DB를 AWS RDS로 이전하는 작업을 했습니다.

처음에는 AWS DMS(AWS Database Migration Service)를 이용해서 마이그레이션을 진행했고,

“기존 DB의 변경 사항을 실시간으로 새로운 DB에 반영”하는 방식이라 꽤 간단하게 끝날 줄 알았죠.

 

그런데 실제로 해보니, 이 방식에는 놓치기 쉬운 리스크들이 있었습니다.

오늘은 그 리스크를 짚어보고, 어떻게 보완하면 더 안전하게 마이그레이션할 수 있는지 공유하려고 합니다.

---

1. 기존 절차 요약

 

• 기존 DB는 EC2에 설치 (관리 불편)
• AWS RDS 신규 DB 세팅
• AWS DMS로 실시간 마이그레이션 진행 (CDC 방식)
• 마이그레이션 완료 후 데이터 테스트
• 이상 없으면 API 서버 DB 접속 정보 변경
• 문제가 있으면 롤백

 

겉으로 보면 깔끔하지만, 여기엔 여러 잠재 리스크가 숨어 있었습니다.

---

2. 발견된 리스크

 

• 스키마/제약 불일치
  • 마이그레이션 도구가 모든 인덱스, 제약 조건, 시퀀스를 완벽히 반영하지 못하는 경우가 있습니다.
• CDC 지연
  • 실시간 반영이라고 해도 네트워크 지연이나 부하로 최신 데이터 반영이 늦어질 수 있습니다.
• 대용량 데이터 타임아웃
  • 이미지, 대형 텍스트, JSON 필드에서 전송 실패나 누락이 발생할 수 있습니다.
• 트리거/배치 중복 실행
  • 신규 DB에서 동일 로직이 두 번 실행되거나, 반대로 빠질 수 있습니다.
• 타임존/Collation 차이
  • 날짜/문자열 정렬 결과가 달라질 수 있습니다.
• 세션/커넥션 전환 문제
  • API 서버 연결 풀이 오래 유지되면 일부 요청이 기존 DB로 가는 경우가 생깁니다.
• 권한·보안 설정 누락
  • 신규 DB 계정 권한, 파라미터, 보안 그룹 설정이 빠질 수 있습니다.
• 롤백 실효성 부족
  • 롤백해도 신규 DB에 쓰인 데이터는 되돌리기 어렵습니다.

---

3. 보완된 마이그레이션 전략

 

• 사전 정합성 검증 자동화
  • 테이블 건수, 체크섬(해시값), NULL 비율, FK 위반 여부를 자동 비교 스크립트로 확인합니다.
  • 대용량 테이블은 시간대별 샘플링 해시를 비교해 속도를 높입니다.
• Cutover 전 Read-only 모드
  • 전환 10~15분 전 서비스 일부를 읽기 전용으로 바꾸거나 업데이트를 잠시 막아 CDC 지연을 제거합니다.
• 캐시·검색 인덱스 초기화 계획
  • 전환 후 Redis 캐시 삭제, 검색엔진(Elasticsearch 등) 재색인을 바로 실행합니다.
• 세션 드레인
  • API 서버에서 기존 연결을 모두 종료하고, 새로운 연결이 무조건 신규 DB로 붙게 합니다.
• 환경 설정 동기화
  • 타임존, Collation, 파라미터 그룹, 인덱스 설정 등을 기존 DB와 동일하게 맞춥니다.
• 권한·보안 점검
  • 신규 DB의 사용자 권한, 보안 그룹, 모니터링 알람까지 체크리스트로 점검합니다.
• 롤백 리허설
  • DNS TTL을 미리 낮추고, 롤백 시 소요 시간을 사전 측정합니다.
  • 전환 후 신규 DB에 쓰인 데이터가 있다면 역마이그레이션 플랜도 준비합니다.
• 모니터링 강화
  • 마이그레이션 직후 48시간은 에러율, 슬로우 쿼리, CDC 지연 등을 집중 모니터링합니다.

---

4. 마이그레이션 흐름 예시

---

5. 마무리

 

DB 마이그레이션은 단순히 “데이터만 옮기는 작업”이 아니에요.

스키마, 환경, 실시간 변경분, 서비스 전환 타이밍까지 고려해야 완전하게 이전할 수 있습니다.

 

makeviibe 팀은 이런 과정을 자동화하고 문서화해서,

조금 더 안전하게 진행할 수 있도록 노력하고 있습니다.