차세대 프로젝트에서 Oracle DB에서 PostgreSQL DB로 데이터 전환을 수행하며 CS-MIG2.0을 사용한 경험을 공유합니다.
기존 CS-MIG는 Oracle DB 동종 전환만 가능했지만, 업그레이드 된 CS-MIG2.0은 서로 다른 이기종 DB의 전환까지 지원하게 되었습니다.
제가 경험한 프로젝트는 CS-MIG2.0을 이기종 DB 전환에 활용한 첫 번째 사례였으며, TOBE기준 총 2TB 이상의 데이터 전환을 진행하였습니다.
1. 환경 구성
먼저, 데이터 전환을 위해 아래 그림과 같은 환경을 구성했습니다.
환경구성
전환 환경 내의 DB 흐름은 다음과 같습니다.
- a. ASIS Oracle DB : Legacy DB의 데이터를 Oracle Data Pump로 추출/적재한 DB.
- b. TOBE Oracle DB : 매핑 규칙이 반영되어 전환된 DB.
- c. TOBE PostgreSQL DB (Constraint X) : [b] Oracle DB를 PostgreSQL 이기종DB로 변환하기 위한 DB.(단, 전환 테스트 및 데이터 검증용이므로 Constraint는 제거)
- d. TOBE PostgreSQL DB (Constraint O) : 최종 Cloud DB의 모습을 복제한 모습. 개발 단계에서 접근이 용이하지 않은 Cloud DB 역할을 대신하기 위해 사용.
정확성을 위한 단계적 전환
작업순서
ASIS Oracle에서 TOBE PostgreSQL (a → c)로 한번에 전환하지 않고 단계별 전환을 택했는데, 그 이유는 다음과 같습니다.
이기종 전환에서는 ASIS와 TOBE 모델의 차이, 그리고 Oracle과 PostgreSQL이라는 DBMS의 차이가 존재합니다. 그렇기 때문에 데이터 전환의 정확성을 높이기 위하여 아래와 같이 순차적으로 전환을 진행하였습니다.
- ① ASIS Oracle to TOBE Oracle : 매핑 규칙에 의한 데이터 변환을 적용.
- ② TOBE Oracle to TOBE PostgreSQL : DBMS 차이에 따른 변환을 적용.
프로젝트 초기에는 ①-②-③ 순서로 전환을 진행했으며, 후반부에는 ①-② 순서로 전환 후 c 에 Constraint를 생성하는 방식으로 테스트를 진행해 나갔습니다.
DDL 생성 및 변환 처리
b부터 d까지 TOBE DB들은 모두 Cloud DB의 PostgreSQL 모델을 기반으로 DDL문을 생성하여 동일한 모습으로 현행화했습니다.
Oracle과 PostgreSQL 간에는 문법, 함수, 컬럼 타입 등의 차이가 발생합니다. 이러한 이기종 DB간 차이를 해결하기 위해 발견된 부분들을 Case 처리하여 아래 예시와 같이 DDL 문을 생성하여 사용했습니다.
PostgreSQL 모델을 읽어 Oracle DDL Script 생성시 컬럼타입 처리코드 예시
2. CS-MIG2.0을 사용한 데이터 전환
위 절차에서 보듯이 데이터 전환이 필요한 단계는 아래와 같습니다.
- ① ASIS Oracle to TOBE Oracle (동종 DB 전환)
- ② TOBE Oracle to TOBE PostgreSQL (이기종 DB 전환)
이 두 단계 모두에서 CS-MIG2.0을 사용하여 마이그레이션을 진행했습니다.
본격적인 전환을 진행하기 전, Oracle과 PostgreSQL의 DB 커넥션 정보에 따라 CS-MIG2.0의 DB 관리 정보를 설정하고 갭 분석을 통해 DB와 동기화를 해줍니다.
테이블/컬럼 매핑
테이블 매핑 설계 화면
컬럼 매핑 설계 화면
CS-MIG2.0의 테이블 매핑 설계 및 컬럼 매핑 설계 화면에서 아래와 같이 테이블과 컬럼 매핑을 진행하였습니다.
- ① ASIS Oracle → TOBE Oracle : 프로젝트에서 정의한 ‘매핑정의서 규칙’에 따라 테이블과 컬럼 매핑.
- ② TOBE Oracle → TOBE PostgreSQL : 이미 전환된 TOBE Oracle의 데이터를 옮기는 과정이므로, 테이블/컬럼명이 동일하도록 1:1 매핑.
동종/이기종 전환 상관없이 두 단계의 매핑 화면과 방식은 동일하며, 단순 매핑 외에도 힌트나 변환 규칙 등 필요한 조건을 화면을 보며 쉽게 입력하고 설정할 수 있습니다.
테이블 매핑 설계 화면에서 옆으로 스크롤 한 모습(Spark 설정 옵션)
CS-MIG2.0은 이기종DB의 전환 시 Spark 엔진을 사용하기 때문에 이와 관련된 조건을 입력할 수 있는 부분이 화면에 추가되었습니다. 프로젝트에서는 전환 속도에 영향을 줄 수 있는 PARALLEL수를 변경하여 사용하였습니다.
전환 프로그램 생성 및 실행
전환프로그램 생성 화면(SQL생성 및 전환 프로그램 실행 후)
전환 프로그램 생성 화면에서 옵션(Oracle/Spark)을 선택하고 SQL생성 버튼 클릭시 프로시저가 생성되며, 이를 컴파일하여 전환 프로그램을 만들고 실행할 수 있습니다. 또한 화면 하단 전환로그 부분에서는 전환프로그램 실행 상태를 확인할 수 있는데 이전 기록을 함께 볼 수 있어 비교가 용이합니다.
매핑처럼 전환 프로그램 실행도 동종/이기종 전환 화면이 다르지 않지만 SQL옵션의 차이가 있습니다.
- ① ASIS Oracle → TOBE Oracle : SQL생성 옵션을 Oracle로 선택.
- ② TOBE Oracle → TOBE PostgreSQL : 이기종 전환의 경우 Spark 엔진을 사용하므로, SQL생성 옵션을 Spark로 선택.
 |  |
Oracle to Oracle Oracle to PostgreSQL
이렇게 CS-MIG2.0을 활용해 순차적인 데이터 전환 프로그램을 개발하고 실행할 수 있습니다. 또한, 프로그램 개발 후 매핑 규칙이 변경될 경우에도 화면을 보며 수정할 수 있어 편리합니다.
초기 전환 프로그램 개발과 수정, 그리고 각각의 프로그램의 전환이 필요할 때 위와 같은 단계로 진행하였고, 한번에 여러 작업을 진행할 때는 다음에서 설명할 워크플로우 기능을 사용하였습니다.
3. 워크플로우 기능의 활용
CS-MIG2.0에는 CS-MIG에 없던 워크플로우 기능이 추가되었습니다.
이전 버전인 CS-MIG를 사용할 때는 생성한 프로시저를 개별로 실행하거나 묶어 실행하는 프로그램을 직접 작성해야하다보니 일괄적으로 작업을 구성하고 자동화 하는데는 어려움이 있었습니다.
하지만 CS-MIG2.0은 워크플로우 기능이 추가되면서 화면을 보며 원하는대로 일괄 작업을 구성하고 실행할 수 있어 편리해졌습니다.
워크플로우 목록 화면
워크플로우에서는 3가지 유형의 블록을 사용합니다.
- SQL블록 : 전환 프로그램 및 워크플로우 실행 전/후에 필요한 작업(CREATE,DROP,TRUNCATE 등)
- MIG블록 : 2에서 생성한 개별 전환 프로그램
- WF블록 : 다른 워크플로우
개발한 전환 프로그램들을 일괄 작업하기 위해 이 블록들로 아래 예시처럼 다양하게 워크플로우를 구성하여 활용하였습니다.
- Oracle to Oracle: MIG 블록만을 사용하고, 전환 프로그램이 순차적으로 진행되도록 구성.
- Oracle to PostgreSQL: SQL블록과 MIG블록을 함께 사용하며, 여러 전환 프로그램이 동시에 진행되도록 구성.
Oracle to PostgreSQL 워크플로우 예시
이렇게 전환 프로그램 여러 개를 목적에 맞게 묶어 일괄로 전환을 진행할 수 있으며, 아래처럼 이미 구성한 워크플로우를 다른 워크플로우에 담아 SQL 작업 및 다른 전환 작업들과 복합적으로 하나의 큰 흐름을 진행하는 것도 가능합니다.
- 복합 작업: SQL, MIG, WF블록 모두 활용하도록 구성.
모든 블록 유형을 활용한 워크플로우 예시
프로젝트 중/후반부에는 전환 프로그램 개발보다는 주로 테스트를 진행하여, 이때 워크플로우 기능을 가장 많이 활용했습니다. 클릭 한번으로 여러 작업을 순차/병렬로 자동 실행할 수 있고, 반복된 테스트를 진행하기에 꼭 필요한 기능이었습니다.
이런식으로 목적에 맞는 워크플로우를 구성하고 실행한다면 작업을 자동화하여 효율성을 높이고, 휴먼 에러를 최소화하여 작업의 정확도를 높일 수 있습니다.
4. 마무리하며
상기와 같이 CS-MIG2.0을 사용한 이기종DB 데이터 전환 사례를 보여드렸습니다. 내용에는 없지만 데이터 전환 모니터링 대시보드, 통합 검증 관리 기능 또한 유용하게 사용하였습니다.
데이터 전환 전용솔루션인 CS-MIG2.0 도입으로 더 편리한 데이터 전환 경험과 함께 데이터 전환 검증과 품질 향상에 집중해보시기 바랍니다.