**한국신용데이터-서비스플랫폼(광고플랫폼)
- 2025.04.14 -
카카오스타일(2년 10개월)-디스플레이시스템그룹**
- 2022.06.07 - 2025.04.09
🔥 담당 개발 기능
🧩 [2억 건 Audience 데이터 적재 시스템: ES → MySQL 마이그레이션 및 성능 최적화]
배경: 신규 광고 플랫폼의 타겟팅 시스템을 설계하며 기존 레거시 아키텍처를 분석하던 중, Elasticsearch(ES)의 사용 방식에 대한 의문점을 가지게 되었습니다.
당시 구 플랫폼은 ES의 핵심 기능인 전문 검색(Full-text Search)이나 복합 쿼리를 전혀 사용하지 않고, 단지 _id를 기반으로 사용자 정보를 조회하여 메모리에 적재하는 단순 Key-Value Store 용도로만 사용하고 있었습니다. 이는 ES의 높은 인프라 비용과 운영 복잡도를 고려했을 때 명백한 오버 엔지니어링이었습니다.
저는 이러한 데이터 접근 패턴을 고려할 때, 굳이 고비용의 검색 엔진을 유지할 필요가 없다고 판단했습니다. 이에 신규 광고플랫폼 전환 시 사용자 적재 스토리지를 MySQL로 전환하여 구조를 단순화하고 인프라 비용을 절감하는 설계를 주도했습니다.
목표: ES → mysql로 Audience 데이터를 마이그레이션 하고, 유저 Audience 데이터를 빠르고 정확하게 제공한다.
해결
1. 레거시 아키텍처 분석 및 기술 변경 근거 마련
우선 ES가 단순 조회 용도로 사용된 원인을 파악하기 위해 히스토리를 추적했습니다. 확인 결과, 과거 S2Graph(HBase/Zookeeper) 기반 시스템으로 구성되어 있었는데, 해당 시스템의 잦은 인프라 장애와 높은 운영 비용, Scala 인력 부족 등의 문제를 겪고 있었습니다. 당시 팀은 NoSQL 운영 경험이 부족한 상태에서, 익숙하고 빠르게 도입 가능한 ES를 차선책으로 선택했음을 확인했습니다.
결과적으로 구 광고 플랫폼에서만 es의 index를 사용하고 있었고, 현재 시점에서 ES가 단순 Key-Value Store로만 오용되고 있는것을 확인했고, 이를 근거로 비용 효율적인 MySQL로의 전환(Spec-out)을 결정했습니다.
2. 대용량(2억 건) 데이터 적재 파이프라인 구축 및 트랜잭션 최적화
데이터 플랫폼팀에서 제공해준 데이터를 기반으로 Databricks 환경에서 새로운 메타 데이터를 만들고 S3로 적재하였습니다. 이를 Spring Batch로 읽어 MySQL로 이관하는 파이프라인을 구축했습니다. 대상 데이터는 약 2억 건이었습니다.
[초기 시도 및 문제점]
Spring Batch에서 S3에 업로드된 파일을 읽어 DB에 Upsert 방식을 사용하여 업데이트를 진행했는데 약 4시간이 소요되었습니다. 긴 처리 시간 동안 구 데이터와 신규 데이터가 섞여 노출되는 데이터 불일치(Inconsistency) 문제와, 작업 중단 시 보상 트랜잭션 및 재처리(Retry) 전략의 복잡성이 리스크로 대두되었습니다.
[해결: 테이블 교체(Swap) 방식 적용] 이를 해결하기 위해 Blue/Green 배포와 유사한 테이블 교체 전략을 도입했습니다.
이 방식을 통해 데이터 정합성을 완벽하게 보장하고, 배치 실패 시에도 서비스 영향 없이 안전한 재시도가 가능한 구조를 완성했습니다.
성과
추가 자료
카카오스타일(2022.06.07 - 2025.04.09)