Grafana 기반 고객사 동기화 상태 모니터링 구축
서버마다 흩어진 로그와 DB 지표를 모아 고객사별 동기화 상태를 한 화면에서 확인했습니다.
작업 요약
물리 서버 5대의 동기화 상태를 한곳에서 확인
서버 5대의 동기화 상태를 한곳에서 확인해야 했습니다
Binlog shipping service 모니터링 v2에서는 서버마다 흩어져 있던 전송·적재 상태를 모았습니다. 물리 서버 5대의 nginx 로그, MySQL 메타데이터, allowed_ips 파일, TimescaleDB, Grafana, Slack/Jira 알림이 이어져야 어느 고객사의 동기화가 멈췄는지 빨리 확인할 수 있었습니다.
Confluence 아키텍처에 남긴 것처럼 계산·알림·고객사 동기화 상태를 CronJob 단위로 쪼갰습니다. 운영자가 Grafana에서 실패 지점을 확인하고 대응할 수 있도록 구성했습니다.
배경
바이너리 로그 기반 데이터 동기화 체계는 외부 replica 연결을 두기 어려운 고객사 환경에 운영 데이터 변경분을 전달하는 핵심 경로입니다. 그러나 기존 모니터링으로는 고객사별 동기화 상태를 중앙에서 한눈에 관측하기 어려웠습니다.
- 기존 데이터 동기화 모니터링의 한계를 제기하고 관측 범위·구성을 전면 재설계
- 고객사 on-premise는 분산되어 있어, 문제 발생 시 중앙에서 선제적으로 인지할 수 있는 가시성이 필요
구조
동기화 서버(nginx/MySQL)에서 통계를 수집해 통계 테이블에 적재하고 이를 Grafana 대시보드로 시각화하며 임계치 기반 알람을 연동했습니다.
- 물리 서버 5대에 분산된 동기화 서버 상태를 중앙 한곳에서 관측하도록 구성
- 수집 스택: 로그 수집기(Vector) → 시계열 DB(TimescaleDB/PostgreSQL) → Grafana 로 시계열 지표를 적재·시각화
- 파일 완료 판정 규칙: N+1번 파일이 존재하면 N번 파일은 쓰기 완료로 간주해 전송 중인 파일을 오탐 없이 구분
대시보드 구성
수집 현황, 고객사별 상태, 에러, DB 용량을 같은 대시보드에서 확인하도록 구성했습니다.
결과
역할
기존 화면에서 보이지 않던 전송·적재 상태를 먼저 정리하고 Grafana 대시보드를 만들었습니다. 이후 장애 조건을 알람에 연결하고, 설계서와 구축 런북, 신규 고객사 등록 가이드까지 직접 작성했습니다.
고객사 on-premise 동기화 경로는 별도의 DB 업그레이드·복제 항목과도 맞닿아 있습니다.
바이너리 로그 동기화 시리즈 ④ — ① 스크램블링 · ② 모니터링·로그 수집기 · ③ 암호화 전환
근거 자료
아래 기록에 근거해 정리했습니다. 내부 원문 경로를 표시하며, 비공개 원문 파일은 이 페이지에서 제공하지 않습니다.
ai/sources/career/interviews/2026-09-03-general-numbers-01.mdai/wiki/people/career-timeline.md