Legacy Monitoring Foundation
리팩토링이 필요했던 레거시 시스템에 모니터링을 먼저 구축해, 장애를 측정하고 이후 구조 개선의 기준을 만들었다.
Overview
MAU 50만 규모 부동산 서비스의 레거시 시스템에서, 본격적인 리팩토링에 앞서 모니터링 기반을 구축한 프로젝트다. 당시 시스템은 서버 단위 결합 구조와 부족한 로그/메트릭 때문에 장애 원인과 영향 범위를 설명하기 어려웠다. 그래서 구조 변경보다 먼저 시스템을 관측 가능한 상태로 만드는 데 집중했다.
Problem
리팩토링이 필요한 것은 분명했지만, 무엇이 실제 병목이고 어떤 순서로 개선해야 하는지 판단할 근거가 부족했다. 서버 단위 결합 구조, instance store 기반 DB 리스크, 배치와 사용자 요청의 DB 경합, 서비스 간 강결합 문제가 있었지만 모니터링과 로그가 부족해 장애 시점과 원인을 함께 보기 어려웠다.
Constraints
- 서비스 운영을 유지한 채 개선해야 했다.
- 구조 개선 전에 현재 상태를 측정 가능한 형태로 만들어야 했다.
- 전체 재작성 없이 후속 리팩토링의 기준을 마련해야 했다.
Approach
Linux 리소스, MySQL 연결 수, 서비스 이벤트를 시계열로 수집하는 모니터링 체계를 먼저 구축했다. 서비스 이벤트는 DB 집계를 통해 메트릭화했고, 시스템 지표와 함께 볼 수 있게 만들었다. 보안 대응과 실행 환경 정리도 병행해 이후 리팩토링 판단의 기준으로 삼았다.
Key Decisions
구조 개선보다 Observability 확보를 먼저 진행했다.
리팩토링이 필요했지만, 먼저 문제를 측정할 수 있어야 우선순위를 정할 수 있었다. 장애 시점, 원인, 영향 범위를 설명할 수 있는 상태를 만드는 것이 선행 과제였다.
- 전체 재작성부터 진행
- 병목 구간만 국소적으로 수정
시스템 지표와 서비스 이벤트를 같은 시계열로 통합했다.
인프라 메트릭만으로는 사용자 영향과 병목을 설명하기 어려웠다. 서비스 이벤트를 DB 집계 기반 메트릭으로 함께 수집해야 시스템 상태와 서비스 영향의 관계를 해석할 수 있었다.
- 시스템 메트릭만 수집
- 로그 분석 중심으로 운영
Tech Stack
- Prometheus
- Grafana
- MySQL
- Docker
- Linux
Result & Impact
장애 발생 시점, 원인, 영향 범위를 함께 추적할 수 있는 상태를 만들었고, 시스템 리소스와 서비스 이벤트를 기반으로 병목을 분석할 수 있게 됐다. 또한 비정상 트래픽 차단과 실행 환경 정리를 통해 이후 리팩토링 우선순위를 정할 수 있는 기준도 확보했다.
Learnings
- 리팩토링이 필요할수록 먼저 관측 가능성을 확보해야 한다.
- 시스템 지표와 서비스 이벤트를 함께 봐야 병목을 정확히 설명할 수 있다.
Architecture Notes
Before
- 애플리케이션, DB, 스토리지가 서버 단위로 결합된 구조
- 서버별 독립 DB와 강결합 서비스 구성
- 모니터링과 로그 부재로 장애 원인 추적 어려움
After
- 시스템 지표와 서비스 이벤트를 통합한 시계열 관측 체계 구축
- 서비스 이벤트를 DB 집계 기반 메트릭으로 수집
- HTTP endpoint scraping 구조와 IP whitelist 적용
- SQL Injection 점검 및 rate limit + fail2ban 기반 운영 대응
- 실행 환경과 설정을 외부화할 수 있는 기반 확보
- 이후 리팩토링 우선순위를 판단할 수 있는 기준 확보
What I Would Improve Next
이후 단계는 데이터/서비스 분리와 실행 흐름 정리 같은 본격적인 리팩토링이다. 이 프로젝트는 그 리팩토링을 시작하기 전에 필요한 모니터링 기반을 마련한 작업으로 보는 편이 맞다.