변경 데이터 캡처와 변경 로그 처리

변경 데이터 캡처(Change data capture, CDC)는 관계형 데이터베이스의 변경을 로그로 전달하는 데이터 통합 방식입니다. Foundry는 이 로그를 수집하고 처리하며 저장합니다. 데이터 스키마에 설정한 변경 로그 메타데이터를 사용해 같은 키의 여러 변경을 해석합니다.

변경 로그 메타데이터

변경 로그에는 다음 열이 필요합니다.

일반적인 변경 로그 해소는 기본 키별로 묶고, 순서 열의 값이 가장 큰 항목을 선택한 뒤, 그 항목의 삭제 열이 true이면 제거하는 순서로 수행합니다. 이렇게 하면 여러 변경을 현재 상태의 행 집합으로 축약할 수 있습니다. 다만 온톨로지 인덱싱은 아래에서 설명하는 도착 순서 제약이 있습니다.

Data Connection에서 수집

원천이 CDC 로그를 생성할 수 있다는 사실과 Foundry 커넥터가 그 로그의 직접 수집을 지원한다는 사실은 구분해야 합니다. MySQL을 포함한 여러 데이터베이스가 CDC 로그를 생성하지만, 직접 CDC 동기화를 제공하는 소스 유형은 Db2, Microsoft SQL Server, Oracle과 PostgreSQL입니다.

직접 CDC 동기화가 없는 원천도 Kafka 같은 스트리밍 중계 계층으로 변경 로그 형태의 데이터를 수집한 뒤 사용할 수 있습니다. Kafka, Kinesis, Amazon SQS 또는 스트림에 직접 밀어 넣는 데이터에는 Pipeline Builder의 Key By로 메타데이터를 적용합니다.

원천 데이터베이스 준비

로그 수집을 시작하기 전에 대상 테이블과 필요한 경우 데이터베이스 전체에서 CDC를 활성화합니다. 다음은 Microsoft SQL Server의 설정 형식을 보여 주는 예시입니다. <database>, <schema>, <table_name>은 실제 대상에 맞게 바꾸는 자리표시자입니다. 명령은 데이터베이스 설정을 변경합니다.

USE <database>
GO
EXEC sys.sp_cdc_enable_db
GO

각 대상 테이블에서도 CDC 기록을 활성화합니다.

EXEC sys.sp_cdc_enable_table
    @source_schema = N'<schema>'
  , @source_name = N'<table_name>'
  , @role_name = NULL
  , @capture_instance = NULL
  , @supports_net_changes = 0
  , @filegroup_name = N'PRIMARY';
GO

필요한 설정과 권한은 원천 시스템에 따라 다릅니다. Connection Details에 입력한 인증 정보는 원천의 권한을 사용합니다. 일반 수집에는 대상 데이터의 SELECT 권한이 필요하며, CDC에서는 대상 테이블과 스키마에 SELECT와 EXECUTE가 모두 필요할 수 있습니다.

소스와 동기화 생성

1. Data Connection에서 해당 데이터베이스 커넥터로 소스를 만듭니다.
2. 소스 개요의 CDC Syncs에서 Create CDC sync를 선택합니다.
3. 대상 테이블을 지정합니다. 커넥터가 출력 스트리밍 데이터셋의 스키마와 기본 키, 순서 열, 삭제 열을 도출합니다.
4. 예상 처리량과 출력 위치를 지정하고 저장합니다.
5. 출력 스트림을 시작하고 실시간 뷰에서 변경 로그를 확인합니다.

처리량은 동기화 생성 후 변경할 수 없습니다. 기본값은 5MB/s이며 예상되는 변경 로그 양에 맞춰 처음부터 설정합니다.

구성을 변경하면 CDC 실행 작업을 수동으로 다시 시작해야 합니다. 같은 소스의 CDC 동기화는 하나의 다중 출력 추출 작업으로 실행되므로, 피드를 추가하거나 제거할 때 기존 CDC 스트림도 잠시 중단해야 합니다. 중단 중 로그가 원천에 보존되어 있으면 재시작 후 해당 변경을 따라잡습니다.

소스별 Debezium 설정

Foundry는 Debezium을 사용해 원천 로그를 읽습니다. 소스 오른쪽 위의 CDC syncs를 열고 CDC settings를 펼쳐 연결 및 엔진 속성을 설정합니다. 소스 유형에 맞는 권장 항목 외에 Advanced Debezium configuration으로 추가 속성을 입력할 수 있습니다.

예를 들어 트랜잭션이 짧은 시간에 몰리면 max.batch.size를 높여 작은 배치 처리 횟수를 줄이는 구성을 검토할 수 있습니다. 일시적인 네트워크 오류에서는 error.max.retries를 늘려 자동 복구 시도 횟수를 조정합니다. offset.flush.interval.ms를 낮추면 오프셋을 더 자주 기록해 복구 시 다시 처리할 범위를 줄일 수 있습니다.

추가 Debezium 속성의 호환성과 동작은 구성자가 확인해야 합니다. 잘못된 설정은 예상하지 못한 동작이나 데이터 손실을 일으킬 수 있습니다. 특히 스냅샷 모드의 이름과 지원 여부는 커넥터에 맞춰 선택합니다.

공통 기본값

커넥터별 기본값

CDC settings에서 Edit를 선택하고 Advanced Debezium configuration의 Add property로 재정의합니다.

스냅샷 모드의 영향

기본 모드는 최초 데이터 전체를 읽기 위한 테이블 잠금과 원천 부하를 피하는 구성입니다. 기존 데이터의 자동 보충을 기대하면 안 됩니다. Debezium이 처리하기 전에 원천의 보관 로그가 제거되면 해당 로그의 데이터는 전체 스냅샷 없이 복구할 수 없습니다. Oracle의 오래된 redo 로그가 삭제되는 경우가 이에 해당합니다.

지원되는 커넥터에서는 다음 대안을 검토할 수 있습니다.

스트림의 실시간 뷰와 아카이브 뷰

변경 로그 메타데이터가 있는 스트림의 실시간 뷰(Live view)는 개별 로그 항목을 모두 보여 줍니다. 아카이브 뷰(Archive view)는 해소 전략으로 로그를 축약해 현재 상태를 보여 줍니다.

스키마 상세 화면에서는 기본 키 해소 전략으로 변경 로그 메타데이터를 확인할 수 있습니다.

스트림 아카이브 뷰는 데이터의 도착 순서가 뒤바뀌어도 지정한 순서 열을 사용합니다. 이 보장은 온톨로지 인덱싱의 도착 순서 동작과 다릅니다.

Pipeline Builder에서 처리

전체 CDC 스트림을 변환할 때 기본 키, 순서와 삭제 메타데이터 열을 변경하지 않으면 메타데이터가 출력으로 자동 전파됩니다. 해당 열을 변환하거나 입력에 메타데이터가 없다면 Key By 보드에서 출력의 변경 로그 메타데이터를 구성합니다.

일부 이력만 있는 스트림의 과거 데이터 보충

부분 CDC 스트림이 특정 시점 이후의 변경만 포함하면 과거 상태를 별도로 보충해야 합니다.

1. 같은 Data Connection 소스에서 과거 데이터의 스냅샷을 배치로 수집합니다.
2. 스냅샷에 변경 순서를 비교할 열을 마련하고 기존 변경 로그와 자료형 및 값의 의미를 맞춥니다. 기존 순서 열이 시각을 나타내고 원천에 해당 값이 없다면 CURRENT_TIMESTAMP() 같은 SQL 함수로 수집 시각을 만들 수 있습니다. 숫자형 시각을 쓰는 CDC 로그와 합칠 때에는 자료형과 시간 단위도 맞춥니다.
3. Pipeline Builder의 Union으로 보충 데이터와 진행 중인 CDC 스트림을 결합합니다.
4. Key By에서 CDC 모드를 활성화하고 원천과 같은 기본 키 및 삭제 열을 지정합니다. 배치나 아카이브의 중복 해소에 순서 열을 사용할 때에는 해당 열도 지정합니다. 스트리밍에서는 순서 열을 비워 두는 것이 권장됩니다.
5. 온톨로지로 보내기 전에 과거 상태가 최신 변경을 덮어쓰지 않도록 데이터의 실제 전달 순서를 확인합니다.

Key By는 키를 지정한 시점 이후의 키별 순서를 유지하며, 이미 섞인 순서를 되돌리지는 않습니다. Primary key ordering columns는 배치와 아카이브의 해소 순서를 정하는 메타데이터입니다. 스트리밍에서 이 필드를 비워 두면 가장 나중에 도착한 행이 우선합니다.

명시적인 삭제 정보가 없다면 연속된 스냅샷을 비교하는 등 삭제를 판별하는 로직이 필요할 수 있습니다. 삭제 이벤트를 만들지 않으면 이전 레코드가 삭제되었다는 사실을 변경 로그에서 알 수 없습니다.

온톨로지 인덱싱의 순서와 보존

Object Storage V2는 스트림 기반 객체 유형에 도착한 변경을 해소하고 인덱싱하여 조회 가능한 현재 객체 상태를 제공합니다. Workshop에서도 이 객체 상태를 사용합니다.

온톨로지는 변경 로그 메타데이터의 순서 열을 무시하고 기반 데이터소스에 도착한 순서로 인덱싱합니다. 가령 같은 키에 대해 순서 값 2, data_column=foo인 항목이 먼저 도착하고, 순서 값 1, data_column=bar인 항목이 나중에 도착하면 온톨로지에는 bar가 남습니다. 원천의 최신 상태가 foo여도 결과가 달라질 수 있습니다.

온톨로지에 연결하는 CDC 수집 경로에서는 같은 기본 키의 변경이 원천의 변경 순서대로 도착해야 합니다. 이 조건은 선택한 커넥터와 스트림 설정, 중간 변환까지 포함해 확인합니다. 스트리밍 동기화의 처리량 설정에서 Normal은 도착한 행의 순서를 보장하지만, Very high는 도착 순서를 보장하지 않습니다. 따라서 모든 Foundry 스트림 구성이 순서를 보장한다고 가정할 수 없습니다.

사용자 정의 수집 경로나 수동 과거 데이터 보충에서도 순서가 뒤섞일 수 있습니다. 선택한 경로가 같은 키의 변경 순서를 유지하지 못하면 Pipeline Builder에서 필요한 재정렬 처리를 적용하거나 스트림을 순서대로 다시 전달한 뒤 온톨로지에 동기화합니다. 아카이브 뷰가 순서 열로 올바른 최신 행을 선택하더라도 온톨로지의 도착 순서 문제를 자동으로 해결하지는 않습니다.

변경 로그 데이터소스에 보존 정책이 있으면 보존 기간 동안 갱신되지 않은 레코드가 온톨로지에서 사라질 수 있습니다. 변경이 드문 객체를 계속 유지해야 한다면 로그 보존 정책과 현재 상태 유지 요구를 함께 검토합니다.

Workshop 자동 새로고침

Workshop의 자동 새로고침은 온톨로지에서 갱신된 데이터를 열린 화면에 반영합니다. CDC와 함께 사용할 수 있지만 CDC 전용 기능은 아닙니다. 기반 데이터소스의 변경 로그 메타데이터 유무와 관계없이, 모듈을 열어 둔 동안 자주 바뀌는 객체를 표시하는 데 사용할 수 있습니다.

과거 데이터, 장애와 메타데이터 제거

기본 CDC 동기화는 시작 이후의 변경을 수집하며 과거 데이터를 자동으로 채우지 않습니다. 원천에서 CDC를 늦게 활성화했거나 로그 보존 기간이 지났으면 전체 과거 로그가 존재하지 않을 수 있습니다.

전체 초기 상태가 필요하면 앞으로의 변경을 받는 CDC 스트림을 먼저 구성하고, 배치 동기화로 과거 데이터를 추출합니다. 각 기본 키의 과거 행을 생성 레코드로 바꾼 뒤 스트림과 결합합니다. 온톨로지에 반영하기 전에 재정렬이나 재전달이 필요할 수 있습니다.

장애는 데이터베이스와 에이전트 사이의 연결, 에이전트 호스트와 Foundry 사이의 연결, Foundry, 데이터베이스 또는 에이전트 자체에서 발생할 수 있습니다. 원천 복제 로그와 변경 로그의 보존 기간이 예상 최대 장애 시간보다 길어야 복구 후 누락 없이 따라잡을 수 있습니다.

예를 들어 SQL Server 로그를 하루 보존하는 상태에서 Foundry 연결이 몇 시간 끊어졌다면, 연결을 복구한 뒤 보존된 로그를 처리할 수 있습니다. 누적 로그를 먼저 처리하므로 거의 실시간의 전달 속도로 돌아오기까지 추가 지연이 있습니다.

CDC 전용 수집을 사용하지 않은 스트림도 필요한 형태의 레코드와 메타데이터를 갖추면 CDC 워크플로에 사용할 수 있습니다. 스트림 프록시로 직접 밀어 넣거나 일반 Kafka 동기화로 받은 뒤 Key By를 적용하는 방식이 가능합니다.

변경 이력 자체를 분석하려면 해소 메타데이터를 제거할 수 있습니다. 메타데이터 열을 변환하거나 스트리밍 데이터셋 스키마에서 해소 전략을 수동으로 제거합니다. 이렇게 하면 현재 상태로 축약하는 동작과 개별 변경을 분석하는 동작을 구분할 수 있습니다.