data-replication

Amazon S3 Tables를 위한 복 (새 탭에서 열림)

AWS가 Amazon S3 Tables를 위한 '인텔리전트 티어링(Intelligent-Tiering)'과 '복제(Replication)' 기능을 새롭게 출시했습니다. 이번 업데이트를 통해 사용자는 데이터 액세스 패턴에 따라 스토리지 비용을 자동으로 최적화하고, 별도의 복잡한 아키텍처 없이도 여러 리전 및 계정 간에 Apache Iceberg 테이블 복제본을 일관되게 유지할 수 있습니다. 결과적으로 대규모 정형 데이터 관리의 비용 효율성과 글로벌 데이터 가용성이 획기적으로 향상되었습니다. **S3 테이블 인텔리전트 티어링을 통한 비용 최적화** * 데이터 액세스 빈도에 따라 Frequent Access, Infrequent Access(40% 저렴), Archive Instant Access(IA보다 68% 저렴) 등 세 가지 저지연 계층으로 데이터를 자동 이동합니다. * 30일 동안 접근이 없으면 IA 계층으로, 90일이 지나면 AIA 계층으로 전환되며, 이 과정에서 애플리케이션 코드 수정이나 성능 저하가 발생하지 않습니다. * 테이블 압축(Compaction), 스냅샷 만료, 미참조 파일 제거와 같은 유지 관리 작업은 데이터의 액세스 계층에 영향을 주지 않고 수행됩니다. * 특히 압축 작업은 Frequent Access 계층의 데이터만 대상으로 실행되어, 활발하게 쿼리되는 데이터의 성능은 높이고 차가운(Cold) 데이터에 대한 불필요한 처리 비용은 줄입니다. * AWS CLI의 `put-table-bucket-storage-class` 명령을 사용해 테이블 버킷 수준에서 기본 스토리지 클래스를 설정할 수 있습니다. **리전 및 계정 간 S3 테이블 복제 지원** * 수동 동기화 없이도 AWS 리전 및 계정 간에 일관된 Apache Iceberg 읽기 전용 복제본(Read Replica)을 생성하고 유지합니다. * 소스 테이블에서 발생한 모든 업데이트를 시간 순서대로 복제하며, Iceberg 테이블의 핵심인 스냅샷의 부모-자식 관계를 그대로 보존합니다. * 소스 테이블이 업데이트된 후 몇 분 이내에 복제본에 반영되며, 각 복제본은 소스와 독립적인 암호화 설정 및 데이터 보존 정책을 가질 수 있습니다. * 전 세계에 분산된 팀들이 로컬 리전에서 복제된 데이터를 쿼리하게 함으로써 네트워크 지연 시간을 최소화하고 데이터 보호 및 규정 준수 요건을 충족합니다. 대규모 Iceberg 데이터셋을 운영하는 조직은 인텔리전트 티어링을 통해 운영 부담 없이 스토리지 비용을 절감하고, 복제 기능을 활용해 글로벌 규모의 데이터 메쉬 아키텍처를 보다 쉽게 구축할 수 있습니다. 특히 데이터가 늘어남에 따라 수동으로 비용을 관리하기 어려운 환경에서 이 두 기능은 필수적인 관리 도구가 될 것입니다.

6개월 만에 연간 수십조를 처리하는 DB CDC 복제 도구 무중단/무장애 교체하기 (새 탭에서 열림)

네이버페이는 차세대 아키텍처 개편 프로젝트인 'Plasma'의 최종 단계로, 연간 수십조 원의 거래 데이터를 처리하는 DB CDC 복제 도구인 'ergate'를 성공적으로 개발하여 무중단 교체했습니다. 기존의 복제 도구(mig-data)가 가진 유지보수의 어려움과 스키마 변경 시의 제약 사항을 해결하기 위해 Apache Flink와 Spring Framework를 조합한 새로운 구조를 도입했으며, 이를 통해 확장성과 성능을 동시에 확보했습니다. 결과적으로 백엔드 개발자가 직접 운영 가능한 내재화된 시스템을 구축하고, 대규모 트래픽 환경에서도 1초 이내의 복제 지연 시간과 강력한 데이터 정합성을 보장하게 되었습니다. ### 레거시 복제 도구의 한계와 교체 배경 * **유지보수 및 내재화 필요성:** 기존 도구인 `mig-data`는 DB 코어 개발 경험이 있는 인원이 순수 Java로 작성하여 일반 백엔드 개발자가 유지보수하거나 기능을 확장하기에 진입 장벽이 높았습니다. * **엄격한 복제 제약:** 양방향 복제를 지원하기 위해 설계된 로직 탓에 단일 레코드의 복제 실패가 전체 복제 지연으로 이어졌으며, 데이터 무결성 확인을 위한 복잡한 제약이 존재했습니다. * **스키마 변경의 경직성:** 반드시 Target DB에 칼럼을 먼저 추가해야 하는 순서 의존성이 있어, 작업 순서가 어긋날 경우 복제가 중단되는 장애가 빈번했습니다. * **복구 프로세스의 부재:** 장애 발생 시 복구를 수행할 수 있는 인원과 방법이 제한적이어서 운영 효율성이 낮았습니다. ### Apache Flink와 Spring을 결합한 기술 아키텍처 * **프레임워크 선정:** 저지연·대용량 처리에 최적화된 **Apache Flink(Java 17)**를 복제 및 검증 엔진으로 채택하고, 복잡한 비즈니스 로직과 복구 프로세스는 익숙한 **Spring Framework(Kotlin)**로 이원화하여 구현했습니다. * **Kubernetes 세션 모드 활용:** 12개에 달하는 복제 및 검증 Job을 효율적으로 관리하기 위해 세션 모드를 선택했습니다. 이를 통해 하나의 Job Manager UI에서 모든 상태를 모니터링하고 배포 시간을 단축했습니다. * **Kafka 기반 비동기 처리:** nBase-T의 binlog를 읽어 Kafka로 발행하는 `nbase-cdc`를 소스로 활용하여 데이터 유실 없는 파이프라인을 구축했습니다. ### 데이터 정합성을 위한 검증 및 복구 시스템 * **지연 컨슈밍 검증(Verifier):** 복제 토픽을 2분 정도 지연하여 읽어 들이는 방식으로 Target DB에 데이터가 반영될 시간을 확보한 뒤 정합성을 체크합니다. * **2단계 검증 로직:** 1차 검증 실패 시, 실시간 변경으로 인한 오탐인지 확인하기 위해 Source DB를 직접 재조회하여 Target과 비교하는 보완 로직을 수행합니다. * **자동화된 복구 흐름:** 일시적인 오류는 5분 후 자동으로 복구하는 '순단 자동 복구'와 배치 기반의 '장애 자동 복구', 그리고 관리자 UI를 통한 '수동 복구' 체계를 갖추어 데이터 불일치 제로를 지향합니다. ### DDL 독립성 및 성능 개선 결과 * **스키마 캐싱 전략:** `SqlParameterSource`와 캐싱된 쿼리를 이용해 Source와 Target의 칼럼 추가 순서에 상관없이 복제가 가능하도록 개선했습니다. Target에 없는 칼럼은 무시하고, 있는 칼럼만 선별적으로 반영하여 운영 편의성을 극대화했습니다. * **성능 최적화:** 기존 대비 10배 이상의 QPS를 처리할 수 있는 구조를 설계했으며, CDC 이벤트 발행 후 최종 복제 완료까지 1초 이내의 지연 시간을 달성했습니다. * **모니터링 강화:** 복제 주체(ergate_yn)와 Source 커밋 시간(rpc_time)을 전용 칼럼으로 추가하여 데이터의 이력을 추적할 수 있는 가시성을 확보했습니다. 성공적인 DB 복제 도구 전환을 위해서는 단순히 성능이 좋은 엔진을 선택하는 것을 넘어, **운영 주체인 개발자가 익숙한 기술 스택을 적재적소에 배치**하는 것이 중요합니다. 스트림 처리는 Flink에 맡기고 복잡한 복구 로직은 Spring으로 분리한 ergate의 사례처럼, 도구의 장점을 극대화하면서도 유지보수성을 놓치지 않는 아키텍처 설계가 대규모 금융 플랫폼의 안정성을 뒷받침합니다.