DB(데이터베이스)를 플랫폼을 옮겨서 마이그레이션할 때의 프로세스와 일정에 관한 간략한 예시입니다
ToC on/off
개요
DB(데이터베이스)를 사용하는 서비스를 유지하다보면, DB를 마이그레이션 해야 하는 경우가 있습니다.
DB 마이그레이션에는 여러 종류가 있지만, 여기서는 물리적인 위치나 플랫폼을 바꾸는 경우 예를 들어 아래와 같은 경우에 참고할 만한 내용을 정리해보겠습니다.
- IDC IDC
- IDC Cloud
- Cloud Cloud
- Cloud IDC
사전 설정
DB 마이그레이션은 애플리케이션 서버와 함께 마이그레이션 하는 경우가 대부분 이므로 그렇게 가정하고 정리해보겠습니다.
또한, MSSQL, MySQL 등의 DB 종류와 관계없이 일반적인 내용으로 정리하려고 합니다.
그리고, 디비 마이그레이션은 충분한 시간을 갖고 계획을 수립하고, 디비 백업 파일을 마이그레이션할 대상 플랫폼에 옮겨서 라이브 환경과 동일하게 테스트 환경을 갖추고, 충분한 기간 동안 스트를 진행한 후에 문제가 있으면 수정하는 등, 충분한 시뮬레이션을 거친 후에 진행하기를 추천합니다.
권장하는 구체적인 일정과 상세 내용은 다음과 같습니다.
마이그레이션 일정
- [추천] 6~8주전 마이그레이션 계획 수립 시작
- [추천] 4~5주전 마이그레이션 시뮬레이션 실행
2-1. [선택] 2주전 2차 마이그레이션 시뮬레이션 실행 - [
필수] 마이그레이션 실행
마이그레이션 계획 수립 시 필요한 사항
- 디비 사용자 계정 정리 (아이디, 패스워드, 용도 등)
- 디비 예약 작업 백업, 리스트 (일정, 용도 등) 정리
- 전체 백업 시에 스토어드 프로시저, 뷰, 트리거, 함수 등을 모두 포함해서 백업할 수 있게 설정
- 백업 전에 불필요한 공간을 줄일 수 있게 디비 축소 진행 (MSSQL)
- 시뮬레이션 진행 시에 필요한 체크리스트 준비
- 체크리스트는 1명이 준비할 경우 빠뜨리는 내용이 있을 수 있으므로 여러 명이 준비해서 함께 정리해야 함 (크로스 체크)
마이그레이션 시뮬레이션 진행 시 고려 사항
- 마이그레이션 대상 플랫폼 서버의 디스크는 백업 파일을 복사할 디스크와 복구될 디비 데이터를 저장할 디스크를 각각 별도로 생성
- 디비 백업 파일을 마이그레이션 대상 플랫폼으로 복사가 완료되기 까지 시간 측정, 기록
- 라이브 환경과 최대한 비슷하게 애플리케이션 서버와 연동해서 사전에 준비한 체크리스트에 맞춰 테스트 진행
일반적인 마이그레이션 절차
- 서비스 점검 시작
- 디비에 접근하는 애플리케이션 서비스 종료
- 디비 전체 백업
- 디비 백업 파일 마이그레이션 대상 플랫폼으로 복사
- 디비 복구 (계정, 예약 작업 등도 함께)
- 디비 데이터 이상유무 디비에서 확인
- 애플리케이션 서비스 실행
- 서비스 테스트
최소 4주전에 시뮬레이션을 진행해야 하는 이유
⁃ 시뮬레이션 진행 중에 문제가 발생했을 경우 문제를 수정할 시간을 확보하기 위해
⁃ 예약 작업은 일일, 주간, 월간으로 진행되는 경우가 많은데 최소 4주 전에 진행해야 월간 작업에 문제가 생기지 않는지 확인할 수 있음
⁃ 시뮬레이션 진행 중에 문제가 발생했을 경우 문제를 수정할 시간을 확보하기 위해
⁃ 예약 작업은 일일, 주간, 월간으로 진행되는 경우가 많은데 최소 4주 전에 진행해야 월간 작업에 문제가 생기지 않는지 확인할 수 있음
2차 마이그레이션 시뮬레이션
- 2차 시뮬레이션은 1차에서 문제가 발생해서 다시 한번 시뮬레이션 해봐야 하는 상황이 생겼을 경우 진행
- 2차 시뮬레이션에서도 문제가 발생할 경우 전체 마이그레이션 일정을 연기하고 다시 잡아야 함
마이그레이션 실행
- 서비스 점검은 시뮬레이션에서 예상된 시간보다 충분히 여유있게 잡아서 만일의 상황을 대비해야 함
- 마이그레이션에 문제가 생기거나 완료 후 테스트에서 문제가 발생했을 경우 이전 플랫폼에서 서비스를 재개할 수 있도록 준비도 필요