도메인 이전, 통계 로깅도 함께 정비
목차
도메인 마이그레이션 작업을 진행하면서 서버 통계 대시보드 스크립트를 업데이트했다. 구 도메인에서 새 도메인으로 넘어가는 과정에서 단순히 DNS를 변경하는 것만으로는 부족했다. 접근 로그 수집 파이프라인도 함께 정비해야 했는데, 이것이 생각보다 흥미로운 인프라 의사결정 지점이었다.
도메인 변경이 통계 시스템에 미치는 영향
처음엔 도메인 이전을 단순한 호스팅 변경 정도로 생각했을 수 있지만, 실제로는 모니터링과 데이터 추적 전체를 다시 정렬하는 일이었다. 특히 우리 팀은 여러 도메인을 함께 운영하고 있었는데, 기존 로깅 설정에서는 이들이 같은 access.log에 섞여 있었다. 새 도메인으로 이전하면서 이 기회에 로그를 분리하기로 결정했다.
왜 이게 중요한가? 통계 대시보드가 제대로 된 데이터를 보여주려면, 각 도메인의 트래픽을 명확히 구분할 수 있어야 한다. 혼합된 로그에서는 다음과 같은 문제가 발생한다:
- 어느 도메인의 트래픽이 증가했는지 추적 불가
- 성능 저하 시 원인 도메인 파악 어려움
- 도메인별 캐시 효율이나 응답 시간 분석 불가
- 오류율이 높아졌을 때 각 도메인의 상태를 개별 점검할 수 없음
통계 대시보드 스크립트의 변경
scripts/stats-dashboard.py를 수정하면서 한 작업은 크게 두 가지였다.
1) 새 도메인의 전용 access.log 경로 지정
기존에는 모든 도메인의 요청이 /var/log/nginx/access.log에 적재되었다. 이제 새로운 도메인은 자체 로그 파일 경로를 갖도록 설정했다. 예를 들어 /var/log/nginx/mingsblog-access.log 같은 형태로 분리함으로써, 대시보드 스크립트가 각각을 개별적으로 파싱할 수 있게 됐다.
2) 파이썬 스크립트 로직 업데이트
stats-dashboard.py는 여러 로그 파일을 읽어서 통계를 집계하는데, 새 로그 파일 경로를 추가로 등록하고 대응하는 도메인별 메트릭 집계 로직을 함께 추가했다.
# 변경 전: 단일 로그 파일만 처리
access_logs = ['/var/log/nginx/access.log']
# 변경 후: 도메인별 로그 파일 분리
access_logs = {
'werebridge': '/var/log/nginx/werebridge-access.log',
'mingsblog': '/var/log/nginx/mingsblog-access.log'
}
이렇게 하면 대시보드에서 "어느 도메인이 지금 얼마나 트래픽을 받고 있나"를 명확히 볼 수 있다.
이런 chore 작업에서 배운 점
지금 돌아보면, 이 작업은 겉으로는 단순한 '설정 변경'이었지만 팀의 데이터 품질을 좌우하는 중요한 의사결정이었다. 많은 개발팀이 이런 인프라 작업을 미루거나 대충 넘어가는 경향이 있다. "일단 도메인만 옮기고, 나중에 로그 분리는 해도 되지 않을까?" 라는 생각이 생기기 쉽기 때문이다.
하지만 '나중'은 보통 오지 않는다. 몇 개월 뒤에 "왜 이 도메인의 성능이 갑자기 떨어졌지?" 라고 물어봤을 때, 혼합된 로그에서는 원인을 찾기가 매우 어렵다. 반면 처음부터 로그를 분리해두면, 대시보드에서 각 도메인의 트렌드를 시각적으로 확인하고 문제를 빠르게 진단할 수 있다.
또 하나 느낀 점은, 이런 작업이 팀 전체의 신뢰도에 영향을 미친다는 것이다. 운영팀이나 마케팅팀이 대시보드의 수치를 믿고 의사결정을 할 때, 그 데이터가 정확하고 신뢰할 수 있어야 한다. 뒤죽박죽 섞인 로그에서 나온 숫자는 언제 터질지 모르는 시한폭탄이다.
이 변경을 통해 앞으로는:
- 각 도메인의 월별/일별 트래픽 추이를 명확히 추적 가능
- 성능 문제 발생 시 원인 도메인을 빠르게 특정
- 새로운 도메인 추가 시에도 동일한 구조로 확장 가능
다음번 도메인 마이그레이션이 있을 때는 이번 경험을 바탕으로 더 체계적으로 접근할 수 있을 것 같다.
🛒 이 글과 어울리는 추천 상품
*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.
댓글 0
첫 댓글 달아줘.