🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개) · 출처: 설계/구축 산출물 2026-04
0한눈에
- 대상: Binlog shipping service — 운영 데이터를 고객사 on-premise까지 동기화하는 경로.
- 목표: 기존 모니터링 한계 해소, 고객사 동기화 상태를 중앙 관측.
- 버전:
v2.0.0 (2026-04), 데이터파트 파트리더 주도 (2026-01~).
1왜 v2로 갔나
기존 Binlog shipping service 모니터링은 분산된 고객사 on-premise 동기화 상태를 중앙에서 통합 관측하기 어려웠다. 한 곳의 수집 지연·에러가 하류 고객사 동기화로 번지므로, 인스턴스·도메인·고객사 단위 가시성이 필요했다. → 관측 범위·구성을 v2로 재설계.
2아키텍처
물리 서버 5대를 중앙에서 관측한다. 파이프라인은 Vector → TimescaleDB(PostgreSQL) → Grafana 대시보드(수집/고객사/에러/DB용량) + 알람.
- 각 Binlog shipping service 서버(nginx/MySQL)에서 Vector로 동기화·로그 통계 수집
- 수집한 통계를 TimescaleDB(PostgreSQL)에 집계·적재
- Grafana가 TimescaleDB를 조회해 대시보드로 시각화
- 임계치 기반 알람 연동으로 선제 대응
sealed 판정 규칙: N+1번째 파일이 존재하면 N번 파일을 sealed로 판정한다.
3대시보드 구성
- 수집 현황: 인스턴스별 binlog 현황, 도메인별 로그 수집 상태.
- 고객사 현황: 업데이트 현황, API 버전 분포.
- 에러 모니터링: 고객사별 에러 요약, 최근 24시간 상세.
- DB 용량: 일별 용량 추이.
네 영역을 단일 관측 체계로 묶어 수집·고객사·에러·용량을 하나의 흐름에서 추적.
4온보딩 포인트
- Binlog shipping service 경로: Binlog shipping service 서버 → 통계 수집 → 통계 테이블 → Grafana. 신규 패널은 통계 테이블 스키마를 먼저 확인.
- 신규 고객사 추가 시 신규 고객사 등록 가이드를 따라 등록 후 대시보드 반영 확인.
- 산출물(2026-04): v2 설계서, 아키텍처 문서, 구축 런북, 신규 고객사 등록 가이드.
5공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/binlog-shipping-monitoring-v2.html)은 내부 테이블/뷰명·호스트명/IP·고객사명·동료 이름 등 내부 식별자를 제거하고 배경·구조·대시보드·임팩트 중심으로 일반화했다. 이 내부 문서는 본인 참고/온보딩용.
🔄 바이너리 로그 동기화 시리즈 ④ — ① 스크램블링 · ② 모니터링·로그 수집기 · ③ 암호화 전환 · ④ 모니터링 v2