통합 프로젝트: 다중 DB 동시 이행 전략 가이드

1. DA의 고민: 왜 다중 DB 이행은 복잡한가?

통합 프로젝트에서 DA(Data Architect)가 마주하는 가장 큰 난관은 각기 다른 원천 DB(Tibero, MySQL 등)를 하나의 타겟으로 모으는 과정에서 발생하는 '데이터의 이질성'과 '제한된 이행 시간'입니다.

 

단순히 옮기는 것을 넘어, 체계적인 이행 로드맵이 필요한 이유입니다.

---

2. 원천 DB별 맞춤형 이행 전략 (Tailored Strategy)

동시에 여러 DB를 이행할 때는 각 DB의 특성에 맞는 '전용 전술'을 구사해야 합니다.

■ Oracle(Tibero) → MySQL (이기종 이행)

• 핵심 과제: 데이터 타입 매핑 및 함수 호환성 해결
• DA 체크포인트: * Tibero의 NUMBER 타입을 MySQL의 DECIMAL 또는 BIGINT 중 어디로 보낼 것인가?
  • Empty String('')을 NULL로 처리할 것인가, 공백으로 유지할 것인가?
• 추천 방식: 데이터 변환 로직이 포함된 ETL 방식

■ MySQL → MySQL (동기종 이행)

• 핵심 과제: 물리적 복제 속도 극대화 및 캐릭터셋 일치
• DA 체크포인트: * Source와 Target의 Character Set(예: utf8mb4)이 일치하는가?
  • Lower_case_table_names 설정 등 OS 레벨의 DB 설정값이 동일한가?
• 추천 방식: Native Dump(Mydumper) 또는 Replication 활용

---

3. 성능 최적화: 시간 제한을 돌파하는 3대 기술

시간이 촉박할 때 일반적인 INSERT 구문만 고집하면 오픈 일정을 맞출 수 없습니다.

1. Bulk Load (LOAD DATA INFILE): SQL 파싱 단계를 건너뛰고 텍스트 파일을 직접 엔진에 로드하여 일반 INSERT 대비 5~10배 속도를 향상시킵니다.
2. 제약 조건 사후 생성 (Post-Index Strategy): 데이터 적재 시에는 모든 인덱스(Index)와 외래키(FK)를 제거하거나 비활성화합니다. 적재가 끝난 후 병렬(Multi-thread)로 인덱스를 다시 생성하는 것이 훨씬 빠릅니다.
3. 세션 파라미터 튜닝: 이행 작업 중에만 innodb_flush_log_at_trx_commit = 0 설정을 적용하여 디스크 I/O 병목을 제거합니다.

---

4. Apache Airflow: 이행의 관제탑(Orchestration)

여러 DB를 동시에 제어하기 위해 Apache Airflow를 도입하면 다음과 같은 운영적 이점을 얻을 수 있습니다.

• 의존성 관리: 마스터 성격의 공통 코드 DB를 먼저 이행한 후, 트랜잭션 DB가 돌도록 순서를 보장합니다.
• 병렬성 제어: 타겟 DB 서버의 CPU/Memory 부하에 맞춰 동시 실행 태스크(Worker) 수를 유연하게 조절합니다.
• 자동 재시도 및 알람: 이행 중 네트워크 순단으로 실패할 경우, 실패한 지점부터 자동으로 재시도하고 담당자에게 알람을 보냅니다.
• 검증 자동화: 이행 태스크 직후에 'Source vs Target 건수 비교' 태스크를 배치하여 무결성을 즉시 확인합니다.

---

5. 마치며: DA의 시선에서 본 이행의 본질

마이그레이션은 기술적인 '복사' 과정이 아니라, 데이터 자산을 **'재정비'**하는 과정입니다. 데이터 규모가 작다면 ETL로 정밀하게 정제하고, 규모가 크다면 CDC나 Native 도구로 속도를 챙기는 유연함이 필요합니다.

무엇보다 '매핑 정의서'라는 설계 도면이 완벽해야 이행 후 애플리케이션 장애를 막을 수 있다는 점을 잊지 말아야 합니다.