ORACLE to Mysql DBMS로의 Migration 프로세스

ORACLE to Mysql DBMS로의 Migration 프로세스

1. 전환의 계기

a. DBMS운영 정책의 변경

사내에서 DBMS운영 정책을 저비용으로 변경을 결정

b. 경영진의 책임 있는 결정

주요 DBMS의 변경에 따른 리스크를 충분히 검토하고 대응책을 마련하고도 나올수 있는 리스크에 대한 경영진의 책임 있는 자세

c. 서비스 운영 비용의 절감

DBMS를 ORACLE에서 open source DBMS로 변경시 운영 비용의 절감 가능성 검토

2. open source DBMS 전환의 장해물

a. 안정성적인 측면의 리스크

서비스가 기존과 동일하게 원활하게 운영이 될 수 있을지에 대한 안정성 측면의 리스크 검토 필요

b. 작업에 대한 휴먼 리스크

전환 작업으로 인하여 발생되는 작업량과 새로운 DBMS 작업에 대한 부담에 따른 휴먼 리스크 검토 필요

c. 서비스 장애 발생 가능성

DBMS의 변경으로 인해 DBMS 자제적인 장애나 기타 다른 서비스들과의 연동 문제등으로 인한 장애가 발생 할 가능성의 검토 필요

3. open source DBMS 전환시 검토 사항

a. 전환 전후의 총비용

전환전과 전환후에 예상되는 비용의 비교 검토 필요

b. 전환 될 DBMS의 운영 능력

전환이 될 DBMS의 관리 및 운영 능력을 가지고 있는지에 대한 검토 필요

c. 전환 될 DBMS의 장애 대응 사례

전환 할 DBMS에 관련된 장애 케이스와 대응 사례 및 장애 대응에 걸리는 시간 및 비용에 대한 검토 필요

d. 서비스의 특성 (oltp, dw, olap)

전환할 서비스의 특성을 파악하여, 서비스에 맞는 DBMS의 선택과 설정 검토 필요

e. DBMS 고유 기능 의존성

ORACLE에서 제공하는 많은 기능과 stored function 등의 전환 가능성 검토 필요

4. DBMS 전환 단계

a. Discussion (논의)

논의 단계에서는 전환 서비스를 선정하고, 운영과 개발 방식과 형태를 고려해야 합니다.

표준에 대한 협의를 해야 하고, 전환에 따른 주의 사항을 공유 합니다.

b. Conversion (전환)

전환 단계에서는 전환 대상을 선정하고, 데이터 이관에 따른 저장소 선정 및 용량을 산정 하여야 합니다.

오라클에서는 트렌젝션 단위를 TPS로 산정 하지만, 전환 모델인 open source DBMS에서는 주로 QPS를 사용 합니다. 이에 따른 트렌젝션량을 고려 해야 합니다. 물론 ERD도 함께 As-is, To-be가 관리 되어야 하겠죠.

c. Development (개발)

개발 단계에서는 전환 대상이 되는 DB 및 Schema에 따른 부서별, 또는 팀별 Ownership을 결정 해야 합니다.

또한 As-is 시스템의 전체 소스에 대한 분석이 이루어 져야 합니다.

연관 되는 프로그램들에 대한 전환 개발도 이루어 져야 하겠죠. 여기에는 모니터링 툴이라던지 DB를 이용한 다양한 프로그램들이 있습니다.

또한 DBMS의 변경에 따른 변경 관리 및 새로운 기능에 대한 고도화도 함께 고려  하여 개발이 이루어져야 합니다.

마지막으로는 DBMS의 변경에 따른 없어진 기능에 대한 개발도 이루어 져야 합니다.

d. Migration (이관)

데이터 이관 단계에서는 기존 데이터에 대한 검증과 Cleansing이 먼저 선행 되어야 합니다.

이 과정에서 불필요한 데이터를 없애고, 다른 환경의 DBMS에 데이터가 잘 이관 될 수 있도록 수정 하는 과정이 필요 합니다.

그리고 데이터를 이관할때 Downtime을 가지고 이관을 할것 인지, 무중단으로도 이관이 가능 한것인지를 미리 결정 하여야 합니다.

데이터 이관시점 역시 결정을 하여야 하는데, 데이터의 성격과 쓰임에 따라서 As-is 와 To-be간의 서비스 변경 시점을 기준으로 선행하여 데이터를 이관 할지, 서비스 변경시점 이후에 데이터를 이관할지 결정 하여야 합니다.

또한 데이터의 변경 관리가 되야 하고, 동기화가 꼭 이루어 져야 합니다.

더불어 데이터 이관과 동시에 테이블이나 기타 Objects들에 대한 분석을 통해서 통폐합이 이루어 질 수 있습니다.

5. Migration 예제 (ORACLE to Mysql)

Oracle에서 Mysql로 데이터를 Migration 하는 방법은 수많은 방법이 있지만, 여기에서는 DB link와 open source ETL Tool을 이용하는 방법을 기준으로 소개해 드리겠습니다.

a. DB link 사용

ORACLE의 DB link를 사용하여 이기종 Migration을 하기 위해서 Oracle Database Gateway License 확인이 먼저 필요합니다. Oracle Support 문서를 확인 해보면 DG4ODBC에 관하여 License 추가 구매가 필요 없음을 알 수 있습니다. 다만 MSSQL이나 DB2등의 상업용 DBMS에 관해서는 License 비용이 발생 함을 확인 할 수 있습니다.

다음은 Mysql Connector/ODBC를 다운로드 하셔야 합니다.

#https://dev.mysql.com/downloads/connector/odbc

DB Link 설정은 아래 내용을 참고하시어 진행 하시면 됩니다.

* Mysql Connector의 odbc.ini 설정

* Oracle Database의 tnsnames.ora 설정

* Oracle Database의 listener.ora 설정

* Oracle Database의 dg4odbc사용을 위한 init.ora 설정

* Gateway를 통한 Mysql Database Connection Test

* Oracle Database에서 Mysql Database로의 DB link 생성

* Oracle Support 문서 참고 (Doc ID 1320645.1)

이렇게 DB link를 생성을 하였다면 데이터 Migration을 위한 Oracle Procedure를 생성하여 이관 할 수 있습니다.

아래 Oracle Procedule를 참고하여 각자의 환경에 맞게끔 수정/변형하여 사용 하시면 됩니다.

CREATE OR REPLACE PROCEDURE 프로시져명

CURSOR MYSQL_MIG IS SELECT 컬럼명... FROM 테이블명;

BEGIN

OPEN MYSQL_MIG

LOOP

FETCH MYSQL_MIG INTO V_컬럼명...;

EXIT WHEN MYSQL_MIG%NOTFOUND;

INSERT INTO 테이블명@dblink명 VALUES (V_컬럼명...);

COMMIT;

END LOOP;

CLOSE MYSQL_MIG;

b. open source ETL Tool 사용

open source를 사용하므로써 License 등 추가 비용이 없다는 장점이 있습니다.

소개해 드릴 open source ETL Tool은 Pentaho (PDI) 입니다.

#https://sourceforge.net/projects/pentaho

위 링크를 통해서 다운로드 받아서 사용 하실수 있습니다.

Oracle과 Mysql간에 데이터를 이관시에 앞서 소개해드린 DB Link를 이용하면 데이터간의 케릭터셋, 데이터타입을 하나하나 맞춰줘야 하는 번거로움이 있지만 Pentaho에서는 거의 대부분의 케릭터셋과 데이터타입을 자동으로 맞춰주는 기능이 있어 사용하기 편리 합니다.

다만 각각의 테이블 마다 데이터 이관용 템플릿(Transformation)을 아래와 같이 만들어서 적용해주어야 하기 때문에 손이 많이 가는 번거로움이 있습니다.

또한 별도의 셋팅이 없이 그냥 이관을 실행하게 되면 초당 2~3,000건의 데이터만 이관이 되기 때문에 시간이 오래 걸리는 단점이 있습니다. 이 속도를 높이기 위해서는 Mysql쪽에 스레드 갯수를 늘리거나, Mysql DB Connection 쪽에 아래 파라미터의 추가 셋팅이 필요 합니다.

이런 스레드와 파라미터쪽 튜닝과 셋팅을 통해서 기본 속도에 비해서 10배에서 100배 늘릴수 있습니다.

위에서 소개해드린 DB link와 open source ETL Tool인 Pentaho를 상황에 맞게 적절하게 나눠서 함께 사용 하면 시너지가 생길 수 있습니다.

6. Application Source 이중화

먼저 기존에 Oracle Source가 Oracle DB를 바라보고 있는 현 상태에서, Application Server에 Mysql을 바라보는 Mysql Source를 한벌 생성을 합니다.

이때, Mysql DB에는 위에서 언급했던 Migration 방법을 통해서 이미 데이터가 이관 되어 있는 상태가 되어야 할 것 입니다.

물론 개발 서버에서 진행이 되어야 할 것 입니다.

어느정도 Mysql 용 Source의 개발이 완료 되고 나면 Oracle Source와 Oracle DB에 들어오는 워크로드를 Mysql Source와 Mysql DB에도 똑같이 적용시켜 테스트를 진행 합니다.

위의 테스트를 통해서 Mysql의 부하를 체크하고 장비 스펙을 재산정 합니다. 물론 Mysql 쿼리도 함께 튜닝이 되어야 할 것 입니다.

Migration은 위에 나열한 일련의 과정을 한번씩 거치면 되는것이 아닙니다.

특정 단계는 수번 내지는 수십번 반복이 되어야 하고, 서비스를 최종적으로 올리고 운영 오픈을 할때까지 모든 과정은 다시 반복 될 여지를 가지고 있습니다.

흔히들 데이터 Migration을 그저 데이터만 형태에 맞게 옮기면 끝나는 작업이라고 생각을 하지만, 위에 나열한 내용들도 Migration과정을 상당히 러프하게 작성 하였기 때문에 실제 DB 와 서비스, 개발 까지 모두 Migration 하는것은 상당히 고도화 되고 집중력이 요구되는 큰 작업 입니다. DBA 그리고 개발자들에게도 부담이 되는 작업이기도 하구요.

모쪼록 위 포스트가 조금이나마 도움이 되시길 바랍니다.

※위 포스트 내용은 아래 youtube 영상을 참고로 텍스트화 하였습니다.

https://youtu.be/DXu3nbWa4AA

감사합니다.

by.sTricky