문서요약 - 데이터 마이그레이션 개념과 도전 과제 by Pick

제목: 데이터 마이그레이션 개념과 도전 과제(Data Migration Concepts & Challenges)

저자: Gershon Pick, 브라질

문서유형: 화이트 페이퍼(총 15페이지), 2001년

 

통신사업자의 고객 관리&청구 시스템(Customer Care & Billing systems)의 실제 마이그레이션을 통해 파악된 데이터 마이그레이션 관련 기술적 어려움을 기술한 자료

---

데이터 마이그레이션

• 소스 시스템으로부터 데이터를 도출하고, 데이터의 에러를 수정하고, 재형식(reformat) 또는 재구조화(restructure)를 하고, 대체할 타겟 시스템에 이 데이터를 로드하는 작업이다.
• 목적이 분명하고 단순한 작업이지만 구 시스템을 대체하는 신규 시스템 구현 실패의 가장 흔한 원인이 되기도 한다.

기술적 도전 과제(Technical Challenges)

아래는 데이터 마이그레이션 프로젝트 관련 기술적 어려움을 기술하고 있다.

 

소스 동기화(Source Synchronization)

대개 하나 이상의 소스 애플리케이션에서 데이터가 나오는데 이들의 업데이트 주기가 달라 소스가 일관적이지 않은 경우가 있다. 마이그레이션을 위해 이런 차이를 해소하는 트랜잭션(catch-up transactions)을 사용하여 소스 데이터를 동기화할 필요가 있을 수 있다. 또한 소스에 불일치가 있을 때 이를 적절하게 처리(추정)하기 위한 규칙이 필요할 수도 있다.

 

소스 안정화(Source Stabilization)

소스 데이터를 정제하는 동안에도 비즈니스 오퍼레이션을 계속 할 수 있도록 소스 애플리케이션이 가능한 최대로 안정적이어야 한다. 이를 위해 마이그레이션 수행 전 준비 기간 동안 추가적인 투자나 임시 절차가 필요할 수도 있다.

 

기계화되지 않은 데이터(Non-Mechanized Data)

마이그레이션에 수작업 데이터 입력(manual data entry)이 포함될 수 있는데 이런 데이터는 마이그레이션 시에 검증을 거쳐 기계화된 소스와 동기화되어야 한다. 수작업으로 입력된 데이터 양이 큰 경우 이 데이터의 검증, 업데이트, 수정을 위한 임시 절차 및 소프트웨어가 마이그레이션 수행 전 준비 기간 동안 필요할 수도 있다.

 

데이터 정제(Data Purification)

종종 마이그레이션은 데이터를 깨끗하게 할 수 있는 기회로 여겨지며 아래 그림처럼 마이그레이션 수행 전과 후에 데이터 정제 작업이 이루어진다. 마이그레이션 프로세스 자체는 데이터 정제를 위한 수작업 개입(manual intervention)을 포함하지 않은 채 최대한 빠르고 단순한 형식을 유지해야 한다. 데이터 검증 소프트웨어는 단지 데이터가 문법적으로 정확하고 일관성(syntactically correct and consistent) 있는지 만을 체크할 수 있으므로 적합한(“valid”) 데이터로 판명된 고객 레코드도 잘못된 이름, 생일, 우편번호, 계정 잔액을 가질 수 있다(고객이 불만 전화를 걸기 전에는 이런 에러를 알아채지 못 할 수도 있음). 즉, 마이그레이션에서 발견된 모든 에러를 수정했다고 해도 실제 부정확한 데이터의 10% 정도만 수정되었을 가능성이 높다.

에러 수정(Error Correction)

마이그레이션 솔루션은 타겟 애플리케이션에서 문제를 야기하는 부적절한 값 또는 관계를 체크하며 이런 문제를 보고하고 타겟 시스템이 받아들일 수 있는 디폴트 값으로 대체한다. 마이그레이션 단순화를 위해 마이그레이션 솔루션은 타겟 시스템에 문제를 일으키지 않는 한 데이터를 수정하지 않는다(수정 하는 경우 수백 건의 데이터 항목의 데이터 타입, 허용치, 유관값, 통제 목적의 총계, 중복키 등을 솔루션이 체크해야 함). 마이그레이션 후에 에러 로그를 이용하여 타겟 시스템이 직접 정확한 값을 입력 하도록 하거나 타겟 시스템 시험 가동의 결과를 소스 데이터 정제에 활용하는 방법도 가능하다.

 

주의 전환(Diversion)

일부 데이터 수정이 문제를 야기 할 수 있으므로 단순 에러 보고 차원을 넘어 클린업 그룹(a clean-up group)이 수정된 레코드를 처리/관리할 필요가 있을 수 있다. 예를 들어 알려지지 않은 제품 코드가 고객 레코드에서 발견된 경우 이를 디폴트 값으로 대체하지만 청구서(bills)는 클린업 그룹으로 보내져 처리하게 한다. 클린업 그룹은 이 에러를 수정하고 타겟 시스템이 최초로 생성하는 청구서 대신 수작업 청구서를 준비하여 이런 문제와 수정 내용이 고객에게 드러나지 않게 한다.

타겟 구성(Target Configuration)

마이그레이션 솔루션(패키지)의 주요 입력이 되는 타겟 구성의 예로 아래와 같은 것들이 있다.

• 사용자 정의 값(Customer-defined value sets): 통화(currency), 고객 카테고리(customer category) 같은 애트리뷰트의 값 범위(value sets)를 사용자가 직접 정의하는 것을 타겟 시스템이 허용할 수 있으므로, 마이그레이션 솔루션은 소스 시스템의 애트리뷰트 값이 타겟 시스템의 적절한 사용자 정의 애트리뷰트 값으로 매핑되도록 해야 한다.
• 사용자 정의 애트리뷰트(Customer-defined attributes): 산업 카테고리(industry category) 또는 소득 범위(income range) 같은 키워드/값 형태의 변수 애트리뷰트를 사용자가 직접 정의하도록 타겟 시스템이 지원할 수 있으므로, 마이그레이션 솔루션은 정확한 사용자 정의 키워드 규칙과 검증 규칙을 사용하여 이런 애트리뷰트들을 생성해야 한다
• 사용자 정의 구조(Customer-defined structures): 타겟 시스템의 데이터 구조를 어떻게 가져갈지 사용자가 직접 선택할 수 있다. 예를 들어 제품을 패키지로 그룹화하고 제품 특징을 정의하는데 사용자에게 여러 다른 옵션이 주어질 수 있다. 마이그레이션 솔루션은 소스 구조를 타겟 시스템에서 사용자가 선택한 구조로 변환시켜야 한다(매핑 로직은 사용자가 어떤 구조를 선택했는지에 달려 있음).

 

고아 데이터(Orphan Data)

소스 시스템의 일부 데이터 항목이 타겟 시스템에서는 마땅한 자리가 없는 경우가 있다. 이 경우 데이터를 넣을 만한 적절한 장소를 찾거나 또는 타겟 시스템을 커스토마이징 해야 할지 고민하는데 시간을 소비할 수 있다. 반대로 타겟 시스템의 필수 데이터의 소스가 존재하지 않는 경우도 있는데, 이 경우는 타겟의 고아 데이터에 표준 디폴트 값을 주면 되므로 해결이 비교적 쉽다. 

값 변환(Value Transformation)

소스와 타겟 시스템의 공통 데이터 항목의 형식이나 코드 집합이 달라 이를 변환하기 위한 테이블 기반 규칙이나 로직이 필요할 수 있다.

 

데이터/구조 분석(Data/Structure Analysis)

소스와 타겟 시스템에 대한 많은 문서가 존재한다 할지라도 정보가 부정확하거나 불완전할 수 있다. 따라서 데이터 마이그레이션 솔루션 공급업자는 문서에만 의존하지 않고 실제 테이블들의 관계(table relationships), 값 집합(value sets), 값들간의 관계(value relationships)를 결정하기 위해 특수한 구조 및 콘텐츠 분석 도구를 사용한다. 이 때 숨겨진 데이터를 찾는 경우가 자주 있으며 이런 분석 단계를 생략하면 테스팅 단계나 실제 운영 단계에 가서야 명세 에러(specification errors)가 드러나게 된다.

 

자유 형식 데이터(Free-form data)

마이그레이션 솔루션이 패턴 분석을 통해 이름, 주소 같은 자유 형식 텍스트 데이터로부터 데이터 항목을 축출하고 패턴에 부합하지 않는 값들은 보고할 필요가 있을 수 있다. 이런 종류의 알고리즘 규칙을 정의하는 일은 대개 납득 가능한 수준의 정확성에 도달할 때까지 소스 파일에 작업을 반복하고 알고리즘을 점차 수정해 나가는 시행착오(trial and error) 방식을 취한다. 소스의 자유 형식 데이터가 타겟 보다 더 긴 경우 단순히 끝 부분을 잘라내는 것은 적절하지 못하며 소스 텍스트의 단어를 짧은 형태로 변환하는 로직이 필요할 수 있다.

<예: 브라질의 거리 명> 아래 예처럼 브라질의 거리 이름은 타겟 시스템이 허용하는 것보다 길이가 훨씬 긴 경우가 많다. LOTEAMENTO INDUSTRIAL NOSSA SENHORA DE FATIMA CINQUENTA E DOIS (JARDIM NOVA GUARATIBA) 이를 아래와 같이 단순하게 25자로 자르면 의미가 없어지게 된다. LOTEAMENTO INDUSTRIAL NOS CINQUENTA E DOIS (JARDIM NO 아래처럼 짧은 형식의 주소를 적절하게 생성해 내는 정교한 알고리즘이 필요하다. LOT. IND. NS DE FATIMA 52 (JD. NOVA GUARATIBA)

구조 충돌(Structure Clashes)

소스와 타겟의 데이터 구조가 다를 수 있으므로 매핑 규칙은 소스 구조에서 타겟 구조로 어떻게 전환할지를 나타내야 한다(아래 그림은 단순한 구조 전환 요구사항의 예). 이와 관련된 이슈로 타겟 시스템 엔터티를 위한 새로운 내부 키(internal keys) 집합 생성, 타겟 데이터베이스의 여러 다른 테이블에 새로운 계정 번호 또는 청구서 번호 적용 등이 있다. 데이터 구조 충돌 해결과 키 변경은 데이터 마이그레이션 프로젝트에서 직면하는 가장 큰 어려움이다.

인터페이스(Interfaces)

타겟 시스템에서 새로운 내부 키(internal keys)가 필요하지만 외부 조직(예, 은행)과 인터페이스가 있는 시스템은 이런 키를 즉시 도입하는 것이 불가능할 수 있다. 이 경우 기존 키(the original keys) 재현을 위해 마이그레이션 팀과 인터페이스 팀이 임시 알고리즘 또는 테이블을 구현해야 한다.

 

타겟 로딩(Target Loading)

대부분의 데이터 마이그레이션 업체는 타겟 시스템 형식으로 플랫 파일(대개 라인당 하나의 레코드를 포함하는 단순 텍스트 파일 또는 텍스트와 바이너리가 섞인 혼합 파일)을 생성하며, 이 파일은 Oracle’s SQL Loader 같은 유틸리티에 의해서 또는 벤더가 공급한 로딩 프로그램에 의해 로드 된다. 

[유틸리티 로드 vs. 벤더의 로드 프로그램 로드]

성능(Performance)

대부분의 마이그레이션 프로젝트는 성능에 크게 의존한다. 제한된 시간 동안만 소스 시스템 동결이 가능하므로(그 시간 동안 발생한 업데이트 요청은 수작업으로 기록/관리), 이 시간 내에 데이터를 마이그레이션하고 체크하는 것이 불가능하다면 하역(unload) 후에 소스에 가해진 변경을 반영하기 위해 타겟 시스템 데이터베이스를 동기화하는 복잡하고 위험 높은 프로세스가 필요하게 된다. 또한 엄격한 성능 요구사항을 충족해야 하는 점도 어려운 과제이다.