Grafana 기반 데이터 동기화 상태 모니터링 구축

고객사 on-premise DB가 바이너리 로그 변경분을 정상 수신·반영하는지 중앙에서 관측하는 Grafana 기반 체계를 재설계·구축

기간2026

소속래브라도랩스(LabradorLabs)

역할데이터 엔지니어링 리드

GrafanaVectorTimescaleDBMySQLnginxMonitoringDashboardAlerting

0작업자의 메모

Binlog shipping service 모니터링 v2는 대시보드 하나를 더 만든 작업이 아닙니다. 물리 서버 5대의 nginx 로그, MySQL 메타데이터, allowed_ips 파일, TimescaleDB, Grafana, Slack/Jira 알림이 이어져야 실제로 “동기화가 멈췄다”를 빨리 알 수 있었습니다.

Confluence 아키텍처에 남긴 것처럼 계산·알림·고객사 동기화 상태를 CronJob 단위로 쪼갰습니다. 운영자가 Grafana만 보고도 다음 행동을 정할 수 있게 만드는 것이 핵심이었습니다.

1배경

바이너리 로그 기반 데이터 동기화 체계는 외부 replica 연결을 두기 어려운 고객사 환경에 운영 데이터 변경분을 전달하는 핵심 경로입니다. 그러나 기존 모니터링으로는 고객사별 동기화 상태를 중앙에서 한눈에 관측하기 어려웠습니다.

기존 데이터 동기화 모니터링의 한계를 제기하고 관측 범위·구성을 전면 재설계
고객사 on-premise는 분산되어 있어, 문제 발생 시 중앙에서 선제적으로 인지할 수 있는 가시성이 필요

2구조

동기화 서버(nginx/MySQL)에서 통계를 수집해 통계 테이블에 적재하고 이를 Grafana 대시보드로 시각화하며 임계치 기반 알람을 연동했습니다.

물리 서버 5대에 분산된 동기화 서버 상태를 중앙 한곳에서 관측하도록 구성
수집 스택: 로그 수집기(Vector) → 시계열 DB(TimescaleDB/PostgreSQL) → Grafana 로 시계열 지표를 적재·시각화
파일 완료 판정 규칙: N+1번 파일이 존재하면 N번 파일은 쓰기 완료로 간주해 전송 중인 파일을 오탐 없이 구분

3대시보드 구성

수집 현황인스턴스별 바이너리 로그 현황, 도메인별 로그 수집 상태

고객사 현황업데이트 현황, API 버전 분포

에러 모니터링고객사별 에러 요약, 최근 24시간 상세

DB 용량일별 용량 추이

네 영역을 단일 관측 체계로 묶어 수집·고객사·에러·용량을 하나의 흐름에서 추적할 수 있도록 구성했습니다.

4임팩트

가시성 확보 — 분산된 고객사 환경의 동기화 상태를 중앙에서 관측

선제 대응 — 에러·용량 추이를 사전에 감지해 선제적 장애 대응이 가능

관측 체계화 — 수집·고객사·에러·용량을 단일 대시보드로 표준화

5역할

데이터 엔지니어링 리드로서 기존 모니터링의 한계 제기부터 관측 범위 재설계 → 대시보드 구축 → 알람 연동 → 산출물 문서화까지 단독으로 수행했습니다. 설계서·아키텍처·구축 런북·신규 고객사 등록 가이드를 함께 정리해 운영·확장 가능한 관측 체계를 확립했습니다.

고객사 on-premise 동기화 경로는 별도의 DB 업그레이드·복제 항목과도 맞닿아 있습니다.

🔄 바이너리 로그 동기화 시리즈 ④ — ① 스크램블링 · ② 모니터링·로그 수집기 · ③ 암호화 전환