아는 사람만 아는 데이터 동기화 기술

(주)엔코아 남일원 책임 컨설턴트

아는 사람만 아는 데이터 동기화 기술

요즘 가장 핫한 키워드는 당연 빅데이터죠. 라디오의 한 코너를 맡을 정도니 말입니다. 기술이라는게 전문가의 전유물은 아니지만 일반 비관련 종사자들에게까지 친근하게 접근하는 걸 보면 참 신기하기도 합니다. 예전에 FTTH가 광고에 한참 나오던 시절 누군가가 한 말이 떠오르네요. “FTTH(Fiber To The Home)가 통신 기술 전문용어인데 전국민이 다 알고 있다.”. 주위를 둘러보면 3개 혹은 4개의 알파벳 으로 구성된 단어들이 무수히 많은데, 아는 단어들도 있지만 대충 느낌으로 넘어가거나 몰라도 될 것 같은 비주류 단어들도 있을 것입니다.CDC(Change Data Capture)도 누군가에겐 그런 부류의 단어일 수 있을 것 같습니다.

누군가로부터 CDC가 구체적으로 뭐하는 것이냐라고 질문을 받았을 때“뭐 특별한 것 없어 데이터 동기화하는 기술 중 하나지” 라고 말했었지만 이 자리를 빌려 좀 더 구체적인 얘기를 해 보겠습니다. 일반적 국내 구축/적용 사례와 개인적 경험을 기준으로 작성했기에 다소 주관적임을 양해해 주시기 바랍니다.

왜 지금 데이터 동기화 기술을 얘기하는가

매일 빅데이터 관련 기사가 쏟아져나오는 이순간에도 우리 비즈니스의 중심은 레거시/계정계라고 불리던 운영시스템일 것입니다. 그리고 실시간DW(Data Warehouse)로의 약진은 현재 진행형이기도 합니다. 한 때 RTBI(RealTime Business Intelligence) 혹은 RTDW(RealTime Data Warehouse)가 한참 화두였던 때가 있었습니다. 얼마 되지 않은 것 같은데 그 단어를 접한 지 벌써 10년이 넘었군요. RealTime 이라는 용어에 대한 시비가 생기기도 해서 Near라는 단어를 앞에 붙여서 사용하기도 했었습니다. CDC(Change Data Capture)라는 기술이 기술 용어로 부각되던 때도 그 때쯤 인 것 같군요. 실시간DW와 무관하게 이미 CDC나 Replication 기술은 데이터 동기화 수단으로 활용되고 있었습니다. 두 기술에 대한 얘기는 잠시 후 다시 하겠습니다.

CDC는 구체적으로 어떤것인가

CDC는 Change Data Capture의 약자로써 , 우리가 흔히 CDC라고 하는 것은 데이터베이스 로그 기반 CDC를 의미합니다. 데이터베이스 로그를 이용하지 않는 기술을 더 이상 CDC로 표현하지 않을 만큼 가장 최적의 변경데이터 추출 기법으로 자리를 잡은 듯 합니다. 말 그대로 데이터베이스의 트랜잭션 로그에서 변경 데이터를 추출합니다. 트랜잭션 로그는 오라클의 백업 용도로 저장하고 있는 리두로그와 아카이브 로그가 그 중 하나입니다. 원래 목적이 정확한 데이터 복구이기 때문에 트랜잭션의 데이터는 물론 세션정보, 시간정보 , Commit과 Rollback 단위의 트랜잭션 ID 등 모든 정보를 담고 있습니다.

메인프레임의 데이터베이스 백업 로그의 활용

CDC가 개방형 데이터베이스에만 적용되는 것은 아닙니다. 메인프레임도 저널링을 통해 백업로그를 남기고 있으며, 오래전부터 국내 대부분 사이트에서는 메인프레임의 백업로그를 이용하여 정보계 시스템으로 동기화를 하고 있었습니다. 이 때는 실시간DW를 위한 것이 아닌 폐쇄형 DB로 부터의 효율적 데이터 동기화를 위해 변경 데이터 만을 추출하는 용도로 활용하였습니다. 이제 국내에 메인프레임 시스템이 많이 사라진 상태군요.

CDC와 Replication 어떻게 다른가

CDC와 Replication은 DB간의 데이터 동기화라는 같은 목적을 두고 있습니다. Replication은 대부분 동질 데이터베이스간의 데이터 복제를 통해 백업용도에 최적화되어 데이터베이스 백업에 사용되었습니다. 주로 운영서버에 실행하기 부담스러운 쿼리들을 실행하는 조회 전용 데이터베이스로의 동기화가 좋은 예입니다. 통계DB라는 이름으로 많이들 사용하고 있습니다. 반면 CDC는 말 그대로 Change Data Capture로 데이터베이스의 변경 데이터를 추출하는 기술이므로 타겟 데이터베이스에 복제보다는 추출의 용도였습니다. 주로 파일형태로 저장하였으며 ETL과 같은 데이터 변경 및 적재 기술과 연계하거나 직접 데이터를 활용할 수 있게 제공하였습니다.

어느 순간 CDC가 ETL 의 데이터 변경/적재 기술로 확장되면서 Replication의 역할을 할 수 있게 되고 Replication에서도 파일로 저장하여 ETL과 연계할 수 있는 기술들을 선보이면서 두 기술의 경계가 애매해졌습니다. 하지만 단순 DB복제 목적인지 이기종 DB와의 동기화를 위한 다양한 연계 목적인지에 따라 장점이 부각되긴 한 것 같습니다. 솔루션들의 진화가 계속되어 CDC와 Replication을 구별하는 것은 큰 의미가 없습니다.두 기술 모두 변경 데이터 추출은 데이터베이스 로그에 기반을 두고 있는 유사한 기술로써 데이터 동기화의 구체적 용도에 따라 기술적 우위를 구별할 수 있어야 할 것입니다. 데이터 동기화의 기본 개념을 이해하고 기존 데이터 동기화 기술과의 비교를 통해 출현 배경을 이해한다면 기술의 본질의 알게 될 것 입니다.

델타 데이터 동기화

분석을 위한 정보계 시스템(DW시스템)은 운영 시스템의 데이터를 동기화해야 합니다. 데이터를 동기화하는 크게 두가지 방식이 있는데, 첫째는 특정 시점에 전체 데이터를 동기화 시키는 방법으로 동기화 초기에 꼭 한번 실시하므로 초기 적재라는 이름으로 불리기도 합니다. 전체 데이터를 읽고 쓰기 때문에 작업량이 많고 작업 시간이 길어지게 됩니다.

그리고 두 번째는 변경된 데이터만 동기화 시키는 방식인데 이 변경된 데이터를 델타데이터라고 하기도 합니다. 동기화 대상 데이터가 적으며 효율적 데이터 동기화를 가능하게 합니다. 델타 데이터 동기화는 변경 데이터 인식의 누락 시 데이터 무결성에 문제가 생기므로 데이터 양이 작은 테이블의 경우는 전체 데이터를 동기화 하기도 합니다. 주로 ETL(Extract Transformation Load) 도구들을 사용하며 업무 시스템의 영향도 때문에 업무시간 이후 야간 배치로 운영하게 됩니다. 정해진 짧은 시간에 일일 데이터를 동기화 해야 하기 때문에 델타 데이터 동기화가 주를 이루게 됩니다.

델타 데이터 추출 유형

델타 데이터 추출 유형은 크게 네 가지가 있습니다. 첫째는 전체 데이터를 동기화 후 다음 동기화 시점에 전체 데이터를 비교하여 변경된 데이터만 동기화하는 방법이 있습니다. 데이터 양이 적을 시 가능하며 주간/월간 작업으로 적당하나 비효율적이기 때문에 잘 사용하지 않습니다.

두번째는 데이터의 입력/수정/삭제 이벤트를입니다.
실시간 동기화에 적합한 기술이나 특수 업무에 적합하며 많은 테이블에 적용하기에는 개발/운영비용과 성능상의 이슈가 있습니다. 주로 EAI (Enterprise Application Integration) 도구나 직접 코딩하여 개발하게 됩니다.

그리고 세번째와 네번째는 마지막 수정일시 컬럼을 추가하여 관리하는 Timestamp 컬럼 활용 방법과 데이터베이스 로그 기반 CDC 기술을 활용하는 방법입니다. 메인프레임의 경우에는 CDC가 일반적이였습니다. 하지만 오라클과 같은 개발형 DB는 Timestamp 컬럼 방식이 훨씬 보편적이였으나 개방형 DB의 CDC 기술 진화와 실시간DW으로의 요구로 인해 기존 Timestamp 컬럼 방식에서 CDC로 전환하는 사례가 늘어나기 시작한 것 입니다. Timestamp 컬살펴보겠습니다.

Timstamp 컬럼 방식의 변경 데이터 동기화에서 CDC 도입하는 이유들

첫 번째, Timestamp 컬럼 관리
모든 테이블에 Timesamp 컬럼을 별도 추가 관리해야 하며, 모든 프로그램에서 데이터를 갱신 시 Timestamp 컬럼의 값을 갱신해야 합니다. DBA나 운영자가 직접 SQL로 데이터를 처리하는 경우 누락될 가능성이 많습니다. CDC를 사용시에는 Timestamp 컬럼이 필요 없게 됩니다. 공공기관 프로젝트에서 국내 대기업 SI사가 Timestamp 컬럼 추가에 따른 프로그램 수정 및 테스트 비용 대비 CDC 솔루션 도입 비용을 측정한 적이 있는데, CDC 솔루션 도입이 유리하다는 결론이 나왔으며 CDC 솔루션을 도입하였습니다. 물론 운영시스템 구축 시부터 Timestamp 컬럼을 철저하게 관리하고 있어 CDC 도입이 불필요하다고 판단하시는 사이트들도 많이 있습니다.

두 번째, 소스 시스템 부하
Timestamp 컬럼 기준으로 대상 테이블마다 별도의 SQL이 실행되며, 수백개의 SQL이 동시에 수행되지 않더라도 많은 세션이 작업하기 때문에 소스 시스템에 상당한 부하가 발생하게 됩니다. 변경 데이터 조회 성능을 위해 Timestamp 컬럼에 대한 인덱스를 따로 생성,관리하여야 하기도 합니다. 반면에 CDC는 운영시스템에는 최소 한 개 또는 적은 세션만으로 전체 테이블의 데이터를 추출합니다. 또한 데이터 파일을 접근하지 않기 때문에 DBMS내 자원 사용률도 적으며 소스 시스템 부하가 적게 발생합니다. 운영 시스템 업무 시간에 준실시간으로 변경 데이터 추출이 용이한 이유이기도 합니다.



세 번째, 삭제된 데이터 추출 불가
삭제된 데이터는 테이블에 존재하지 않기 때문에 추출할 수가 없습니다. 그래서 일부 시스템들은 삭제 플래그를 위한 컬럼을 관리하고 있습니다. 하지만 어떠한 이유에서든 삭제는 일어나며 삭제 데이터에 대한 동기화는 누락됩니다. 간혹 데이터 관리자들은 수백개의 테이블들이 철저하게 관리되고 있다고 착각하기도 합니다.

네 번째, 키 값 변경된 데이터 인식 문제
절대 발생하지 않는다고 믿기도 하고 발생하면 어쩔 수 없다고 여기는 것이 키 값이 변경되는 경우입니다. 키 값이 변경된 경우에는 기존 키의 없어진 것을 인식하지 못한 상태에서 신규 데이터가 입력된 것으로 인식하게 됩니다. 운영계에는 한건인데 정보계에는 두건이 존재하게 되는 것입니다. CDC에서는 변경 전 데이터와 변경 후 데이터를 모두 가지고 있기 때문에 키 값 변경을 인식하여 이전 데이터를 신규 키 값으로 대체하게 됩니다.

마지막으로 데이터 갱신시간과 Commit 시점의 시간 차이에 의한 변경 데이터 동기화 유실 발생
배치 작업의 경우 발생 가능성이 높은 현상으로 데이터가 발생한 시간과 Commit된 시간의 차이가 큰 경우 일자의 경계를 넘어갈 때 주로 발생하는 현상입니다. 동일한 Commit에 의한 트랜잭션이지만 발생 일시가 오래된 경우 변경데이터로 인지되지 못하는 경우가 있습니다. Commit이 지연되는 경우에는 변경 데이터를 추출중인 다른 세션에서는 해당 데이터가 보이지 않기도 합니다. 이에 해당 하는 데이터는 Timestamp 컬럼 조건으로 가져올 수 없게 됩니다. 추출 기준 일시를 일부 영역만큼 중첩하여 가져 올 수 있으나 상대적으로 얼마만큼의 시간을 중첩해야 할지 장담할 수 없습니다. 실제 사용자가 SQL 편집기에 장시간 동안 Commit하지 않는 경우나 배치 작업으로 인한 갱신이 장시간 소요되는 경우를 종종 보기도 하였습니다.



트랜잭션 A의 A1,A2,A3,A4 이벤트는 추출 기준 일시 이전 데이터 이기 때문에 유실됨
추출 기준 일시를 몇 시간을 중첩시키기도 하나 절대적으로 보장 가능한 시간은 존재하지 않음



CDC는 트랜잭션 단위로 데이터를 처리하므로 Commit 이벤트 기준으로 데이터를 처리

CDC 도입 시 주의할 사항

CDC 기술이 ETL만큼 확산되지 못한 것에는 timestamp 컬럼 기반 동기화에 대한 불만이 없기 때문이기도 했지만, 일부 CDC 솔루션들의 문제점으로 CDC 기술에 대한 불신도 한 몫 했다고 여겨집니다. 그리고 CDC 기술 자체가 가지고 있는 몇가지 취약점이 존재하기도 합니다. 아래 열거되는 요인으로 CDC 도입을 망설일 수도 있으나, 진화된 CDC 솔루션들은 대부분 관련 문제를 해결한 것으로 알고 있습니다.

No Logging 트랜잭션 대응
성능향상을 위해 No Logging 환경으로 데이터 처리시 CDC로 작업을 할 수가 없습니다. 하지만 이런 작업의 특성상 대규모 데이터 갱신이기 때문에 CDC로 처리하기 보다 전체 데이터 재 동기화가 효율적일 것입니다. 일반적으로 특수한 작업이기 때문에 작업자로부터 공지를 받을 수 있습니다. 만약 운영 업무 데이터를 no logging으로 처리한다면 그 의도를 확인해봐야 하겠습니다. 장애 복구 시 버려져도 되는 데이터 일까요

대량 데이터 처리 성능
대량 데이터 발생 시 데이터 동기화 지연이 발생하게 됩니다. CDC 솔루션에 따라 성능에 차이가 있으나 절대적인 양이 있기 때문에 평시 처리 성능과는 비교할 수 없을 것입니다. 작업 그룹을 별도로 관리할 수 있는 경우에는 대량 데이터 갱신이 자주 발생하는 테이블과 일반 속보성 동기화 테이블을 분리해서 운영하는 방법이 있습니다. 특히 대량 롤백 데이터는 운영 DBMS와 마찬가지로 CDC에도 큰 부담이 되는 트랜잭션이며 CDC 솔루션별 처리 기법에 따라 차별화가 되는 요소이기도 합니다.

테이블 구조의 변경 연계
CDC 솔루션들이 테이블 구조의 변경 시 데이터 동기화에 문제가 생기기도 합니다. 오라클의 경우 리두로그와 아카이브 로그에는 테이블명이나 컬럼명을 저장하지 않고, 딕셔너리 또한 최종 이미지만을 관리하기 때문입니다. 하지만 일부 CDC 솔루션들은 최근 테이블 구조 변경은 물론 시간이 많이 지난 과거 아카이빙된 로그들까지 추출 하여 동기화 가능하기도 합니다. 용도에 따라 확인해야 할 기능일 수 있습니다. 그렇지 않으면 자칫 테이블 구조 변경 때마다 CDC 작업에 오류가 발생할 수 있습니다.

암호화 데이터 처리
개인정보를 포함하는 데이터는 당연히 암호화되어야하는 시대가 되었습니다. 암호화 기술에 따라 리두로그 내부 데이터가 암호화 되어 있을 수도 있고 그렇지 않을 수도 있습니다. 암호화 되어 있다면 데이터 아키텍쳐 측면에서 데이터 동기화 시 반드시 복호화 해야 할지도 확인 해야 하며, 암호화 패키지를 이용한 경우에는 패키서 호출하거나 이후 처리단계어서 복호화 후 동기화를 진행할 수 있습니다. 일반적으로 암호화 데이터가 문제가 되지 않을 것이나 꼭 확인해야 하는 요소임은 분명합니다.

Supplemental Log 설정
일반적으로 DBA 분들이 가장 민감하게 생각하는 부분입니다. CDC를 사용하기 위해서는 Supplemental Log 설정을 변경해야 합니다. Supplemental Log를 설정하면 실제 데이터 처리에 사용되지 않은 컬럼 정보들도 리두 SQL에 표현되기 때문에 리두 SQL의 길이가 길어집니다.Insert나 Delete는 큰 변화가 없으나 Update의 경우에는 길이 정보의 변화가 클 수 있습니다. 하지만 걱정하는 것과는 달리 실제 적용 시 시스템 부하적인 측면에서 문제가 되지 않습니다. 그리고 대부분 Update SQL문장은 프로든 컬럼을 Update하고 있을 것입니다. 직접 테스트를 해서 사이즈의 증가와 부하로 인한 영향도를 확인 해 보는 것도 좋은 방법입니다.

양방향 동기화
간혹 양방향 동기화를 고민하는 프로젝트들이 있습니다. 장애 대응이나 복잡한 업무적 특성 등 이유는 다양하지만 양방향 동기화는 큰 무리 없이 가능합니다. 하지만 동일 테이블에 대해 양방향으로 동기화하는 것은 조심해야 합니다. 동일한 PK에 동기화 시 동기화 시점 차이나 운영상의 이슈나 지연으로 인해 과거 데이터 처리 시 , 마치 영화 “백 투더 퓨처＂처럼 과거와 미래가 꼬이듯 데이터가 뒤죽박죽이 될 수 있습니다. 꼭 필요하다면 논리적으로 구분이 되는 데이터 집합이 존재 시 적용하는 것이 좋습니다.

CDC의 과제, 신뢰성 유지

Commit 트랜잭션 후 데이터 동기화가 시작되는 CDC에 있어 실시간 데이터 검증은 불가능에 가깝습니다. 더욱이 실시간으로 데이터 동기화 도중에 전수 데이터 검증은 현실적일 수 없습니다. 전수 검증을 위해 시스템을 멈출 수는 없는 노릇입니다. 구간별로 데이터 검증이나 샘플링 검증이 가장 효율적인 데이터 검증이 될 수 있겠습니다. 과거 ETL 도구들도 유사한 시험을 치루었으나, 실시간이라는 CDC의 그것은 더 혹독합니다. 프로젝트 초기 핵심 테이블을 중심으로 설득력 있는 기준으로 증명해냄으로써 신뢰와 믿음을 보여주는 것이 가장 좋은 방법일 것이며, 수많은 환경적 요인에서 오는 오류 시 CDC 기술 자체에 대한 의심을 받지 않도록 최선을 다해 원인과 방안을 제시해야 할 것입니다.

빅데이터와 CDC

빅데이터로 인해 실시간 데이터 분석의 요건이 많아 지고 관련 분야의 규모가 커지지만, 우리 비즈니스의 중심은 여전히 운영 업무 시스템입니다. 한참 동안은그렇게 유지될 것입니다. 하둡이나 NoSQL DB들을 사용하더라도 비즈니스 중심이 되는 데이터의 실시간 연계를 위한 데이터 동기화 작업이 필요하며, 어플라이언스 DB들이 쏟아지기 시작했을 때처럼 빅데이터의 데이터 저장소를 위한 연계 작업이 많아 질 것이라 생각합니다. 다행히 빅데이터의 데이터 저장소들은 데이터 교환이 무척이나 자유롭고 오픈소스에서 상용에 이르기까지 다양한 데이터 처리 도구들과의 인터페이스로 해결 될 수도 있을 것입니다.

마무리하며, 기술의 진화와 반복

“급변하는 …” “비즈니스 혁신..” 이런 말을 무척 자주 접하는 시대를 살고 있습니다. 시대의 요구가 반복되어 예전 기술이 진화되어 나올 수도 있고, 획기적인 기술이 나오기도 하지만 기술자체가 중요한 것은 아닌 것 같습니다. 물론 기술로 먹고 사는 엔지니어가 기술을 등지면 안되지만, 시대의 요구를 정확히 읽을 정도까지는 아니더라도 최소한 주변이 변하고 있음을 인지해야 합니다. 무엇이 필요한지 왜 필요한지 호기심을 멈추지 말아야 할 것 같습니다. 그 와중에도 늘 갖추어야 할 기본에 충실해야 하는 이유는, 언젠가 익숙한 그것이 낯선 모습으로 다가올 것이기 때문입니다.