ETL: ELT(FlyData)와 ETL(Xplenty)를 결합한 순환형 데이터 통합 아키텍처

​

FlyData 소개

​

주요 특징

• 실시간 CDC 복제: 데이터베이스의 변경 사항을 즉시 캡처
• 간단한 설정: 비교적 적은 설정만으로 복제를 시작 가능
• 데이터 웨어하우스에 특화: 데이터 웨어하우스로의 동기화에 최적화된 설계

​

개요

​

아키텍처 설명

​

각 단계의 역할

• 단계 1: ELT — FlyData를 통한 데이터 수집
  • CDC(Change Data Capture) 방식으로 각 운영 DB의 변경 내용을 실시간 또는 준실시간으로 Snowflake에 연계
  • 데이터 변환 없이 원본(Raw) 데이터를 먼저 DWH에 저장(ELT의 핵심)
  • 여러 이종 데이터베이스를 하나의 DWH로 통합
• 단계 2: 분석·연산 — Snowflake 내에서의 처리
  • 수집한 원본 데이터를 바탕으로 SQL View, Stored Procedure, dbt 등을 활용해 **조정 데이터(Reconciled Data)**를 생성
  • 예: 재고 조정값, 정산 금액, 집계된 사용자 점수 등
• 단계 3: ETL — Xplenty를 통한 데이터 역배포
  • Xplenty의 비주얼 파이프라인으로 Snowflake의 가공 데이터를 읽어옴
  • 필요한 변환(필드 매핑, 타입 변환, 필터링) 적용 후
  • 각 운영 DB에 Merge(Upsert), Append, Truncate & Insert 등의 방식으로 역송신

​

사례: EC 플랫폼의 재고·정산 데이터 동기화

​

사례 배경

• 여러 리전(일본, 미국, 한국)에 개별 운영 DB를 보유한 EC 서비스
• 각 리전의 결제 데이터를 중앙에서 집계해 글로벌 결제 조정값을 계산
• 계산된 조정값을 각 리전의 DB에 반영해야 하는 요건이 존재

​

단계 1: FlyData로 각 리전 DB → Snowflake로 수집

• [일본 MySQL] → (CDC) → Snowflake: raw.jp_payments
• [미국 PostgreSQL] → (CDC) → Snowflake: raw.us_payments
• [한국 MySQL] → (CDC) → Snowflake: raw.kr_payments

​

단계 2: Snowflake에서 글로벌 결제 조정값 계산

-- 예: 전체 결제 평균을 기준으로 리전별 조정 금액을 계산
CREATE OR REPLACE VIEW analytics.adjusted_payments AS
SELECT
   payment_id,
   'JP' AS region,
   jp.amount - (global_avg.avg_amount * 0.3) AS adjusted_amount
...
...;
-- 미국, 한국에도 동일한 로직을 적용

​

단계 3: Xplenty로 조정 데이터 → 각 리전 DB로 역배포

[Snowflake Source]
 analytics.adjusted_payments
       ↓
[Filter 컴포넌트]
 region = 'JP' 로 필터링
       ↓
[Select 컴포넌트]
 payment_id, adjusted_qty 필드 매핑·타입 변환
       ↓
[Database Destination: JP MySQL]
 테이블: payment_adjustment
 모드: Merge(Upsert) by payment_id

• JP MySQL, US PostgreSQL, KR MySQL 각각에 개별 Xplenty 파이프라인을 구성하거나, 단일 파이프라인 내에서 분기 처리
• Xplenty 스케줄러에서 Snowflake의 계산이 완료된 후 자동 실행되도록 설정(의존 관계 체이닝)

​

장점과 단점

​

장점

​

단점

​

주의 사항

1. 데이터 루프 방지(가장 중요)
   • 역배포 데이터에는 출처를 식별할 수 있는 메타 컬럼(source_system, is_adjusted, updated_by 등)을 반드시 추가하십시오.
   • FlyData의 CDC 필터 설정 또는 Snowflake의 View 로직에서, 역배포 데이터를 재수집 대상에서 제외하는 처리를 반드시 구현하십시오.
2. 멱등성(Idempotency) 보장
   • Xplenty의 역배포 파이프라인이 중복 실행되더라도 데이터가 이중으로 삽입되지 않도록, 반드시 Merge(Upsert) 모드와 명확한 기본 키(PK)를 설정하십시오.
3. 실행 순서·의존 관계 관리
   • Snowflake의 연산(View 갱신, dbt run 등)이 완료된 이후에만 Xplenty 파이프라인이 실행되도록 스케줄 또는 의존 관계 트리거를 설정하십시오.
   • Xplenty의 Dependent Execution 또는 Webhook Trigger 기능을 활용할 수 있습니다.
4. 오류 발생 시 부분 롤백 전략
   • 역배포 도중 일부 DB에만 데이터가 반영되고 나머지에서 실패하면 데이터 불일치가 발생합니다.
   • Xplenty의 단일 트랜잭션 모드(Single Transaction Mode) 또는 Pre/Post-action SQL을 활용해 롤백 전략을 수립하십시오.
5. 모니터링과 알림 설정
   • FlyData와 Xplenty 양쪽에 장애 알림(Hook)을 설정해, 파이프라인의 어느 구간에서 오류가 발생하더라도 즉시 감지할 수 있도록 하십시오.
   • Xplenty의 Slack, PagerDuty, Email Hook을 활용하면 효과적입니다.
6. 민감 데이터 처리
   • 개인정보(PII)나 금융 정보가 포함된 데이터를 역배포하는 경우, Xplenty의 Select 또는 Filter 컴포넌트를 사용해 불필요한 민감 필드를 제외하거나 마스킹 처리하십시오.

​

정리