조회수 대시보드 확장하며 배운 설계 포인트

사내 여러 서비스의 트래픽을 한눈에 보기 위해 조회수 대시보드를 운영 중인데, 최근 life/name 서비스를 새롭게 추적 대상으로 추가했다. 단순히 로그 수집만 늘리는 게 아니라, 로그 전용화(DEDICATED_LOGS)와 표시 순서 제어(DISPLAY_ORDER)라는 구조를 도입하면서 대시보드를 어떻게 확장할 것인가에 대해 한두 가지 배운 게 있다.

왜 전용 로그인가

처음엔 모든 조회 이벤트를 하나의 통합 로그에 모으면 되지 않을까 싶었다. 하나의 로그 스트림에서 서비스별로 필터링하는 식으로. 하지만 서비스별 트래픽 규모가 달라지고, 로그 수집·저장·조회 속도를 서비스별로 다르게 튜닝해야 하는 순간 문제가 생긴다. 특정 서비스의 로그가 폭증했을 때 통합 스트림 전체가 영향받으면 다른 서비스 대시보드 업데이트도 지연된다.

그래서 life/name 조회수는 DEDICATED_LOGS를 지정해서 전용 로그 채널로 분리했다. 이렇게 하면 다음 같은 이득이 생긴다:

• 로그 수집 파이프라인을 이 서비스 특성에 맞게 튜닝 가능
• 저장 용량과 보관 기간을 별도로 관리
• 장애 격리: 다른 서비스의 로그 폭증이 이 서비스 모니터링을 망치지 않음

코드 상에서는 설정 파일에 이런 식으로 나타난다:

{
  "service": "life/name",
  "metric": "pageviews",
  "dedicated_logs": true,  # 전용 로그 채널 활성화
  "display_order": 2        # 대시보드 순서: 2번째에 표시
}

표시 순서를 명시한 이유

대시보드에 서비스를 추가할 때마다 자동으로 아래에 붙이는 방식도 있다. 하지만 운영 입장에서는 중요한 서비스부터 위에 봐야 한다. 예를 들어 핵심 도메인의 조회수가 떨어지는 건 즉시 눈에 띄어야 하지만, 부수 도메인은 한눈에 안 봐도 되는 경우가 많다.

DISPLAY_ORDER를 명시하면:

우리는 life/name을 display_order=2로 지정해서 대시보드의 두 번째 위치에 고정했다. 이건 단순해 보이지만 대시보드를 자주 보는 입장에서는 "항상 같은 위치에서 같은 메트릭을 찾을 수 있다"는 일관성이 중요했다.

확장성 고민

지금까지 다섯~여섯 개 서비스를 이 대시보드로 관리했는데, 열 개를 넘어가기 전에 이런 구조를 정했길 잘 했다고 생각한다. 로그 전용화를 하지 않았으면 서비스 개수가 늘어날수록 로그 수집 로직이 점점 복잡해졌을 거다. 테스트도 어렵고, 버그가 나면 all-or-nothing 장애가 된다.

비슷한 모니터링 시스템을 다른 팀에서도 쓰고 있어서, 이 설계 패턴이 재사용 가능한지도 생각해봤다. 결론은 DEDICATED_LOGS와 DISPLAY_ORDER는 로그 통합 대시보드를 짤 때마다 반복되는 패턴이라는 것. 처음부터 설정으로 제어 가능하게 만들어놓으니 다음에 다른 서비스를 추가할 때 스크립트를 건드리지 않고 config만 수정하면 된다.

끝.

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

• 4K모니터 쿠팡에서 보기 →
• 모니터암 쿠팡에서 보기 →
• 인체공학마우스 쿠팡에서 보기 →

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