프로젝트 개요
2025.03 — 2025.09
들어가며
서비스 안정성 문제는 때로 시스템 내부가 아니라, 서로 다른 목적을 가진 시스템 간의 강결합에서 비롯됩니다. 이 글은 마케팅 발송 모니터링 시스템이 분석 전용 플랫폼인 Hadoop에 직접 의존하면서 발생한 가용성 문제를 해결하는 과정을 SBI(Situation → Behavior → Impact) 구조로 정리한 기록입니다. 프로젝트 매니징 관점의 이해관계자 조율 이야기는 별도 포스팅에서 다룹니다.
Situation — 분석 플랫폼에 묶인 운영 도구
두 시스템의 SLA가 같을 수 없는데, 같은 것처럼 묶여 있었다
마케팅 운영팀이 발송 현황을 확인하는 어드민 시스템은 전사 분석용 플랫폼인 Hadoop(Hue)을 직접 바라보고 있었습니다. Hadoop은 대규모 데이터를 분석하기 위한 플랫폼으로, 실시간 응답과 고가용성을 보장하는 서비스용 DB와는 근본적으로 목적이 다릅니다. 그런데 운영 도구가 이 플랫폼에 의존하고 있었습니다.
이 구조적 불일치는 두 가지 방식으로 운영 현장에 영향을 미쳤습니다. 첫째, 주말에 Hadoop 장애가 발생하면 데이터팀 대응이 월요일에야 이루어지기 때문에, 마케팅 운영팀은 수십만 건 발송의 정상 여부를 알 수 없는 채로 주말 내내 기다려야 했습니다. 둘째, 데이터팀이 대규모 분석 쿼리를 실행할 때마다 어드민 응답 속도가 1초 이상으로 늘어지는 현상이 반복されました. 분석 업무와 운영 업무가 같은 자원을 두고 경쟁하는 구조였습니다.
Behavior — OLAP과 OLTP의 분리
1단계: 데이터 소스 분리 전략 수립
해결 방향은 명확했습니다. 분석(OLAP)과 서비스(OLTP)를 분리하고, 각 목적에 맞는 기술 스택으로 재구성하는 것이었습니다. 어드민용 실시간 조회 데이터는 MySQL로 이관하여 인덱싱 최적화와 안정적인 응답 속도를 확보하고, 전체 데이터 분석은 기존 Hadoop을 그대로 유지하되 이중 적재 파이프라인을 새로 설계했습니다.
2단계: Data Retention Policy 수립
마케팅 로그는 TB 단위로 쌓이는 대용량 데이터입니다. 이를 전부 MySQL에 담는 것은 비용과 성능 양쪽에서 비현실적이었습니다. 운영팀의 실제 조회 패턴을 확인한 결과, 모니터링 수요는 대부분 최근 5일 이내에 집중되어 있었습니다. DBA와 협의하여 최근 5일치 상세 데이터만 MySQL에 보관하고 이전 데이터는 자동 삭제하는 정책을 수립했습니다.
3단계: 배치 통계 테이블 설계
5일 이전 데이터에 대한 조회 요구는 상세 로그가 아닌 집계 수치로 충분했습니다. 새벽 배치 작업을 통해 과거 데이터를 요약 통계 테이블로 가공하도록 설계하여, 오래된 상세 로그를 삭제하더라도 집계 단위 조회는 지속될 수 있는 구조를 만들었습니다.
Impact — 응답 속도 80% 개선, 모니터링 가용성 100% 확보
데이터 소스를 분리한 이후 어드민 조회 응답 속도는 최대 1초 이상에서 0.1~0.2초 수준으로 개선되었습니다. 분석 쿼리와 자원을 공유하지 않는 독립적인 DB에서 서비스에 맞는 인덱스 최적화가 가능해진 결과였습니다. 무엇보다 Hadoop 장애 여부와 무관하게 마케팅 운영팀이 24시간, 7일 내내 발송 현황을 실시간으로 모니터링할 수 있게 되었습니다. 주말 Hadoop 장애가 운영팀의 업무를 막는 상황이 구조적으로 사라진 것입니다.
핵심 교훈
- 목적이 다른 시스템은 SLA도 다릅니다. 분석 플랫폼과 서비스 운영 도구를 같은 데이터 소스에 묶는 것은, 낮은 가용성을 높은 가용성이 요구되는 곳에 전이시키는 구조적 위험입니다.
- Retention Policy는 기술이 아닌 비즈니스 결정입니다. 5일이라는 기준은 임의적이지 않습니다. 운영팀의 실제 조회 패턴과 DBA의 용량 계획이 교차하는 지점에서 합의된 값입니다.
- 이중 적재는 두 세계를 잇는 다리입니다. Hadoop을 대체하는 것이 아니라, 각 저장소가 자신의 목적에 집중하도록 역할을 명확히 분리한 것이 핵심이었습니다.
정리하며
이 프로젝트의 기술적 해결책 자체는 단순했습니다. 어렵고 시간이 든 부분은 그 해결책을 실행 가능하게 만드는 과정, 즉 데이터 거버넌스 정책을 수립하고 여러 이해관계자의 합의를 구하는 일이었습니다. 좋은 아키텍처는 코드 이전에 사람들의 합의 위에서 만들어진다는 것을 다시 한번 실감한 경험이었습니다.