통계 대시보드 vhost 매칭·시간 경계·누락 사이트 버그 수정

통계 대시보드 스크립트에 누적된 버그 3가지를 한 번에 수정했다. 얼핏 서로 다른 문제처럼 보이지만, 자세히 들여다보니 모두 데이터 수집과 집계 로직의 경계 영역에서 발생한 전형적인 함정들이었다.

vhost 매칭: 같은 서버, 다른 도메인의 구분

처음 발견한 건 hedvion vhost 매칭 문제였다. 한 물리 서버에서 여러 개의 도메인을 호스팅하는 경우, 각 도메인(vhost)별로 트래픽과 통계를 따로 집계해야 한다. 그런데 기존 로직에서는 서버 IP 기반으로만 매칭하고 있어서, 같은 서버 위의 다른 도메인들이 섞여서 집계되고 있었다.

이를 수정하면서 깨달은 건, 통계 수집 로직에서 "서버 정체성"을 정의할 때 얼마나 신중해야 하는지였다. 초기 설계 당시엔 "물리 서버 = 통계 단위"라고 생각했을 수 있지만, 시간이 지나며 운영 구조가 더 복잡해진 거다. 다중 도메인 구조를 지원하려면:

• 서버 IP + vhost 헤더 조합으로 고유한 엔드포인트 식별
• 설정 파일에서 vhost → 서비스 이름 매핑 정의
• 로그 수집 시점에서 vhost 정보가 누락되지 않도록 검증

이런 식으로 단계별 매칭 로직을 보강했다.

시간 단위 순환과 누락된 사이트들

다음은 hourly lap 문제. 대시보드는 시간마다 데이터를 갱신하는데, 새로운 hour가 시작될 때 이전 hour의 집계를 마무리하고 새로운 기간용 버킷을 준비해야 한다. 이 "lap" 동작에서 몇몇 사이트들이 집계 대상에서 빠져나가고 있었다.

이건 전형적인 상태 관리 버그다. 통계 시스템은 메모리에 캐시된 사이트 목록과 DB의 실제 사이트 목록이 항상 동기화되어야 하는데, hourly lap 같은 "상태 전환" 시점에서 이 동기화가 깨지기 쉽다.

모니터링 시스템의 경계에서 발생하는 버그들

이번 수정을 통해 배운 패턴은, 통계/모니터링 시스템의 버그는 보통 다음 세 곳 중 하나에서 발생한다는 것:

1. 데이터 소스 → 수집 파이프라인: vhost 매칭처럼, 원본 데이터의 속성을 제대로 인식하지 못할 때
2. 시간 기반 상태 전환: hourly lap처럼, 시간이 바뀔 때 메모리 상태를 제대로 갱신하지 않을 때
3. 구성 변경 vs. 캐시: missing sites처럼, 운영 중 추가된 엔티티가 캐시된 목록에 반영되지 않을 때

stats-dashboard.py는 구조상 매분 또는 매시간 반복 실행되는 배치 작업 성격이라, 각 실행 시점마다 일관성 있는 상태를 유지하는 게 핵심이다. 초기화 단계에서 DB와 메모리 상태를 확실히 동기화하고, lap 같은 경계 지점에서 재검증하는 식으로 처리했다.

이런 류의 버그는 일반 비즈니스 로직 버그보다 찾기 어려운 이유가, 대부분의 시간엔 잘 작동하기 때문이다. 특정 조건(새 사이트 추가, 시간대 경계, 재시작 후)에서만 드러난다. 그래서 통계 시스템을 다룰 땐, 항상 "언제 이 가정이 깨질까?"를 한 번 더 생각하는 버릇이 중요하다.

🛒 이 글과 어울리는 추천 상품

• 모니터 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.