이 문서는 Lakebase 섹션의 일부입니다.
왜 Data Sync가 필요한가요?
기업 환경에서 OLTP 데이터(주문, 결제, 재고 등)를 분석에 활용하려면, 전통적으로 ETL 파이프라인 을 별도로 구축해야 했습니다. 이 과정에서 다음과 같은 문제가 반복적으로 발생합니다.💡 Data Sync 는 Lakebase의 데이터를 자동으로 Delta Lake 테이블에 동기화 하는 기능입니다. 별도의 ETL 파이프라인 없이, Lakebase에서 INSERT/UPDATE/DELETE된 데이터가 Delta Lake 테이블에 자동 반영됩니다.
💡 CDC (Change Data Capture): 데이터베이스에서 발생하는 변경사항(삽입, 수정, 삭제)을 감지하여 다른 시스템에 전달하는 기술입니다. Data Sync는 내부적으로 CDC를 활용하여 변경분만 효율적으로 동기화합니다.
동기화 아키텍처
Data Sync는 PostgreSQL의 WAL(Write-Ahead Log) 을 기반으로 변경사항을 캡처합니다. 전체 데이터를 복사하는 것이 아니라, 변경분(Delta)만 증분 처리 하므로 네트워크 비용과 처리 시간이 최소화됩니다.
동기화 방향
Forward Sync (Lakebase → Delta Lake)
가장 일반적인 패턴으로, Lakebase의 OLTP 데이터를 Delta Lake로 동기화합니다. 웹 앱에서 생성된 운영 데이터를 분석 환경에서 바로 활용할 수 있습니다.Reverse Sync (Delta Lake → Lakebase)
분석 결과나 ML 추론 결과를 다시 Lakebase로 동기화하여, 웹 앱에서 즉시 활용할 수 있습니다.동기화 정책 (Sync Mode)
Data Sync는 세 가지 동기화 모드를 제공합니다. 비즈니스 요구사항에 따라 적절한 모드를 선택하시면 됩니다.⚠️ CONTINUOUS 모드 는 변경사항을 지속적으로 모니터링하므로 컴퓨팅 비용이 발생합니다. 실시간성이 반드시 필요한 테이블에만 사용하는 것을 권장합니다.
실습: 동기화 설정하기
1단계: Lakebase 데이터베이스와 테이블 준비
2단계: Forward Sync 설정 (SQL)
3단계: Python SDK를 사용한 동기화 설정
4단계: TRIGGERED 모드 수동 실행
스키마 변경 처리
Lakebase 테이블의 스키마가 변경되면, Data Sync가 자동으로 대응합니다. 다만 변경 유형에 따라 동작이 달라집니다.⚠️ 비호환 스키마 변경(예: VARCHAR → INTEGER)은 동기화를 중단시킬 수 있습니다. 대규모 스키마 변경 전에는 동기화를 일시 중지하고, 변경 후 SNAPSHOT 모드로 재동기화하는 것을 권장합니다.
동기화 모니터링
상태 확인
주요 메트릭
💡 모니터링 팁: lag_seconds가 지속적으로 증가하면 소스 테이블의 쓰기 속도가 동기화 처리 속도를 초과하는 것입니다. 이 경우 인스턴스 사이즈를 조정하거나, 동기화 대상 테이블을 분리하는 것을 검토하시기 바랍니다.
실패 복구 및 트러블슈팅
일반적인 문제와 해결 방법
동기화 재설정 (전체 재동기화)
문제가 지속되거나 대규모 스키마 변경 후에는 동기화를 삭제하고 재생성합니다.성능 고려사항
대용량 테이블 동기화
지연시간 최적화 팁
- 인덱스 설계: Lakebase 테이블에 적절한 인덱스가 있으면 변경 캡처가 빨라집니다
- 배치 크기 조정: 대량 INSERT 시 적절한 배치 크기(1,000~10,000행)를 사용합니다
- 핫 테이블 분리: 변경이 매우 빈번한 테이블은 별도의 동기화 설정을 합니다
- 불필요한 컬럼 제외: 분석에 필요 없는 대용량 컬럼(BLOB 등)은 동기화에서 제외합니다
💡 Exactly-once 보장: Data Sync는 exactly-once 시맨틱 을 보장합니다. 네트워크 오류나 일시적 장애가 발생하더라도 데이터가 중복되거나 누락되지 않습니다.
제한사항 및 주의사항
⚠️ 양방향 동기화 주의: Forward Sync와 Reverse Sync를 동시에 설정하면 데이터 충돌 이 발생할 수 있습니다. 양방향이 필요한 경우, 쓰기 권한을 한쪽에만 부여하여 충돌을 방지하시기 바랍니다.