운영 중인 서비스의 ISMS-P 인증 취득을 위해 도쿄 리전의 전체 인프라를 서울 리전으로 이전하는 대규모 프로젝트를 수행했습니다. 기존 RDS의 리전 간 스냅샷 공유 방식은 TB 단위의 데이터 규모와 암호화 적용 필요성으로 인해 최소 2시간 이상의 다운타임이 예상되는 상황이었습니다.
이는 전체 점검 시간 내에서 타 서비스들의 배포를 지연시키는 병목 구간이 될 리스크가 컸기에, 가용성을 극대화할 수 있는 DMS CDC 기반의 실시간 마이그레이션 방식을 선택했습니다.
DMS 운영 과정에서 트랜잭션이 집중되는 대용량 테이블의 경우 CDC Task가 중단되는 현상이 발생했습니다. 이를 해결하기 위해 **고부하 테이블 전용 Task와 복제 인스턴스를 별도로 분리(Isolation)**하여 리소스 경합을 방지했으며, 작업 일주일 전부터 정합성 검증(Validation)을 병행하여 데이터 신뢰도를 확보했습니다.
그 결과, 작업 당일 데이터 엔드포인트 라우팅 변경만으로 전환을 완료하여 다운타임을 10분 내외로 단축할 수 있었으며, 서비스 재개 직전 안정적으로 마이그레이션을 마무리하여 성공적인 리전 이전과 ISMS-P 인증 취득에 기여했습니다.
운영 중인 DB 시스템의 보안 감사를 위해 기존에는 RDS Audit Log를 활성화하여 관리하고 있었으나, 모든 데이터베이스 행위를 기록하는 특성상 CloudWatch Log 적재 비용이 월 $12,000(약 1,600만 원)에 달하는 심각한 비용 효율 저하가 발생했습니다. 또한, 로그의 양이 방대해짐에 따라 실시간 조회가 불가능하고 익일에서야 조회가 가능한 운영상의 제약이 존재했습니다. 이를 해결하기 위해 기존 CloudWatch 기반 로그 적재 방식을 폐기하고, Aurora Database Activity Stream(DAS) 기반의 자체 감사 로그 파이프라인을 설계했습니다.
구축 초기에는 DAS에서 발행되는 이벤트 스트림을 AWS Kinesis와 Lambda를 통해 S3에 Hive Format(Parquet)으로 실시간 적재했습니다. 그러나 월 100억 건에 달하는 방대한 로우가 실시간으로 기록되면서 수많은 Small File이 생성되었고, 이로 인해 Athena를 통한 쿼리 성능이 마비되는 기술적 난관에 부딪혔습니다. 이를 극복하기 위해 먼저 데이터 파티션 전략을 기존 일 단위에서 시간(Hour) 단위로 세분화했습니다. 감사 로그의 특성상 특정 시점의 행위를 추적하는 케이스가 대다수라는 점에 착안하여, 스캔 범위를 최소화함으로써 조회 성능을 극대화했습니다.
또한, 실시간으로 유입되는 작은 Parquet 파일들을 최적화하기 위해 Airflow를 활용한 일 단위 Merge(Compaction) 프로세스를 도입했습니다. 이를 통해 파편화된 파일들을 적정 크기의 데이터 블록으로 재구성함으로써, 100억 건 규모의 대용량 데이터 내에서도 원하는 로그를 1분 이내에 탐색할 수 있는 고성능 분석 환경을 구현했습니다.
결과적으로 기존 대비 월 $12,000의 운영 비용을 전액 절감하는 혁신적인 FinOps 성과를 거두었으며, 데이터 적시성 또한 크게 개선되었습니다. 이전에는 확인이 불가능했던 실시간 트랜잭션 레벨의 쿼리 모니터링이 가능해짐에 따라, 장애 발생 시 애플리케이션 레벨에서 파악하기 어려운 정교한 DB 이슈들을 실시간으로 추적하고 해결할 수 있는 강력한 운영 가시성을 확보했습니다.
리멤버의 급격한 서비스 성장으로 인해 기존 분석 아키텍처는 구조적 한계에 직면해 있었습니다. 매일 새벽 Amazon EMR과 Sqoop을 이용해 수십억 건의 데이터를 S3에 전량 적재(Full Refresh)하는 방식은 데이터 볼륨이 커질수록 Aurora MySQL과 S3 모두에 과도한 I/O 부하를 일으켰으며, 운영 비용 또한 가파르게 상승했습니다. 무엇보다 운영 DB(Reader)를 직접 조회하는 실시간 분석 쿼리가 서비스 트랜잭션의 응답 지연을 유발하는 등 OLTP와 OLAP 리소스 공유로 인한 안정성 문제 해결이 시급했습니다.
이러한 문제를 근본적으로 해결하기 위해 관리형 Iceberg 테이블인 Amazon S3 Tables를 도입하여 현대적인 실시간 데이터 레이크하우스 아키텍처를 설계했습니다. 기존의 배치 구조를 탈피하여 Debezium과 Amazon MSK를 활용한 CDC(Change Data Capture) 파이프라인을 구축했으며, 이를 통해 데이터 동기화 주기를 기존 1일에서 10분 단위로 단축하여 비즈니스 데이터의 신선도를 획기적으로 개선했습니다.
프로덕션 환경에서의 안정적인 운영을 위해 S3 Tables의 유지 관리(Maintenance) 기능을 적극 활용했습니다. 특히 CDC 환경에서 빈번하게 발생하는 Small File 문제를 해결하고자 Auto Compaction 전략을 수립하고, 파일 크기를 512MB로 최적화하여 쿼리 성능 향상과 S3 API 비용 절감을 동시에 달성했습니다. 또한 테이블의 용도에 따라 Snapshot Management 정책을 차등 적용하여, 시점 조회가 필요한 테이블은 30일간 보관하고 실시간 분석용 테이블은 메타데이터 크기를 최소화하는 방식으로 스토리지 효율을 극대화했습니다.