현재 데이터베이스에서 다른 데이터베이스로, 데이터를 옮기는 작업을 마이그레이션(Migration)이라고 한다. 실전에서는 ‘이행’이라는 용어를 많이 사용하기도 한다. 그러므로 이 문서에서는 마이그레이션과 이행을 같은 의미로 사용하며, 문맥에 따라 적절한 용어를 선택해서 사용할 예정입낟.
마이그레이션을 분류하고 마이그레이션을 진행하기 위해 필요한 것들을 고민해보자.
마이그레이션 분류
마이그레이션에는 다양한 케이스가 있다. 오라클에서 오라클로 옮기는 동기종 마이그레이션이 있으며, 오라클에서 MySQL과 같은 다른 DBMS 제품으로 옮기는 이기종 마이그레이션이 있다. 여기서는 오라클 11G에서 19C로 버젼업을 하는 마이그레이션도 동기종 마이그레이션으로 분류한다.
마이그레이션에는 테이블 구조 변경이 되는 경우와 아닌 경우가 있다. 소소하게 일부 컬럼이 추가되는 경우는 테이블 구조 변경을 N으로 분류한다.
각 유형별로 다음과 같이 마이그레이션을 분류해 볼 수 있다.
마이그레이션 | DBMS | 테이블 구조 변경 |
동기종 단순 이전 마이그레이션 | 동기종 | N |
동기종 데이터 변환 마이그레이션 | 동기종 | Y |
이기종 단순 이전 마이그레이션 | 이기종 | N |
이기종 리디자인 마이그레이션 | 이기종 | Y |
동기종 VS. 이기종
동기종 마이그레이션은 이기종에 비해 작업양이 적다. 이기종 마이그레이션은 심각하게 할일이 많다. 이기종 마이그레이션을 위해서는 다음의 내용들을 고려해야 한다.
•
SQL을 TO-BE DBMS에 맞게 문법을 수정해야 한다.
•
DBMS내 프로그램인 프로시저와 펑션을 TO-BE DBMS에 맞게 변경해야 한다.
◦
TO-BE DBMS의 지원 여부와 성능 이슈에 따라 프로시저와 펑션을 걷어내야 할 수도 있다.
•
기본적인 데이터 자료형이 DBMS 별로 다소 상이하므로 이를 고려해 재설계 필요
◦
오라클은 문자형 자릿수를 정할 때, BYTE 단위이지만, MySQL은 글자수이다. 이런 부분을 고려해 데이터 자료형을 잘 설계해야 한다.
•
TO-BE DBMS에 따라 성능이 좋아질 수도 있지만 나빠질 수도 있다.
◦
쿼리변환과 옵티마이져는 SQL 성능에 큰 영향을 미친다.
◦
DBMS가 변경된다면 SQL을 처리하는 내부적인 방식은 거의 달라질 수 있으며 이로 인해 심각한 성능 저하가 발생할 수 있다.
동기종 마이그레이션이라고 할 일이 적은 것은 아니다. DBMS가 설치된 장비 자체가 변경되어도 SQL 성능은 영향을 받을 수 있기 때문이다. 앞에서 버젼 업그레이드도 동기종으로 분류했다. 보통 버젼 업그레이드는 더 좋은 기능과 더 좋은 성능을 보장하지만, 실제로는 업그레이드 후 심각한 성능 저하가 발생하는 경우가 있다. 특히 오라클을 업그레이드하면서 New Feature 기능을 모두 OFF하고 쓰는 경우를 많이 목격할 수 있다. 시스템 특성상 성능이 매우 크리티컬 하다면 동기종 버젼 업그레이드도 튜너의 많은 지원이 필요하다.
테이블 구조 변경
테이블 구조 변경이 발생하는 마이그레이션은 제법 힘든 마이그레이션이다. 테이블 구조 변경에는 다양한 상황이 있다. 정리해보면 다음과 같다.
•
컬럼명, 테이블명 변경(표준화)
◦
AS-IS VS. TO-BE 모델 매핑이 필요하다. 모델 매핑을 관리하고 개발자에게 공유해야 개발도 진행할 수 있다.
•
테이블 구조 변경
◦
테이블 구조 변경에는 통합, 분할 등이 있다. 데이터 통합을 위해서는 키 구조를 변경해야 할 수도 있으며 그에 맞는 키맵 구조를 만들어 처리해야 문제가 없다. 통합과 분할은 모델 단계에서부터 AS-IS 데이터를 어떻게 통합하고 분할할지 상세하게 설계해 놓아야 한다. 그러한 생각없이 TO-BE만 생각하고 모델을 만들게 되면, 데이터 마이그레이션은 안드로메다로 가게 된다.
•
데이터 체계 변경
◦
보통은 테이블 구조 변경은 데이터 체계 변경을 발생시킨다. 간혹 테이블 구조 변경은 없지만 데이터 체계만 변경되는 경우도 있다. 예를 들어 예전에는 코드를 WAIT, COMP와 같은 유의미 방식으로 사용했지만 TO-BE에서는 01, 02와 같은 무의미 방식으로 변환하는 경우다. 데이터 체계 변경 역시 어려운 작업이다. 데이터 마이그레이션도 어렵지만 데이터 체계 변경을 고려해 프로그램도 변경해야 하는 어려운 작업니다. 특히 현업과 개발팀에서 변경되는 코드와 데이터 체계를 잘 정의하지 않으면… 이역시 마이그레이션은 안드로메다로 가게 된다.
컬럼명이나 테이블명만 변경이 되고 1:1로 이행되는 경우는 이행 개발자 입장에서는 매우 심플하다. 이런 이행은 정리만 잘하고, 중간에 프로그램만 잘 만들어 놓으면 혼자서 200개든 300개든 처리할 수 있다.
반면에 통합이나 분할(분리)과 같은 테이블 구조 변경이 있다면, 매우 어려운 이행 프로젝트가 된다. 어떤 기준으로 데이터를 통합하는지, 통합과정에서 PK는 어떻게 재정의하는지 등의 세세한 로직을 모두 이행 프로그램에 반영해야 한다. 데이터 체계 변경 역시 매우 어려운 이행 프로젝트다. 테이블 구조 변경과 데이터 체계가 변경되는 이행에는 현업과 운영팀의 적극적인 참여가 필요하다.