🔒 내부용 · 비배포 (포트폴리오에는 일반화 버전만 공개)
0한눈에
- 대상: 사내 마스터 DB의 on-premise 백업본 + Binlog shipping service의 updater / download proxy가 고객사 환경에 함께 배포된다.
- 책임자: 시스템 담당자(데이터 엔지니어, 2026~ 데이터파트 파트리더)가 운영·관리하고, 심층 이슈의 최종 해결자 역할을 한다.
- 특징: 고객사 환경마다 구성이 달라 설치·구성을 시나리오별로 맞춤 지원한다.
1전체 흐름
사내 마스터 DB → (백업본 + binlog) → 고객사 on-premise DB + Binlog shipping service. 고객사 측 updater가 변경분을 받아 DB에 반영하고, 직접 통신이 어려운 곳은 download proxy를 경유한다. 폐쇄망은 반입 파일을 Importer로만 반영한다.
고객사 환경 안에서 도는 시스템이므로, 문제 발생 시 원격 진단과 심층 분석이 필요하다. 1차 지원(기술지원팀/외주)에서 안 풀리는 이슈가 결국 데이터파트로 올라온다.
2배포 시나리오 (환경별 구성)
| 시나리오 | 구성 요점 |
|---|
| 기본 (다운로드 전용) | updater가 binlog를 받아 바로 DB에 반영 |
| 파일 검수 구성 | 고객사가 받은 binlog를 먼저 검사한 뒤 DB에 반영 |
| 접근 시간 제한 | 정해진 시간대에만 다운로드/반영 동작 허용 |
| 폐쇄망 (Importer-only) | 외부 통신 없이 반입된 파일만 Importer로 반영 |
| download proxy 필요 | 직접 통신이 막힌 고객사는 proxy를 통해 배포 |
3형상관리 · 지원 절차
- 고객사별 설치 형상 추적: DB 백업본 버전 · updater/download proxy 버전 · 설치일
- 신규 고객사 등록 절차에 따라 환경 파악 → 시나리오 선택 → 설치/구성
- 심층 이슈(DB · Binlog shipping service · 동기화/정합성 · 네트워크)는 시스템 담당자가 직접 진단·해결
- 설치 가이드 · 배포 시나리오 · 등록 절차를 문서화해 지원 표준화 및 온보딩에 활용
형상관리로 환경 차이를 체계화해 두면, 동일 증상이라도 고객사별 구성 차이를 빠르게 좁혀 진단할 수 있다.
4온보딩 포인트
- 핵심 구성요소: on-premise 백업본 DB, Binlog shipping service updater, download proxy, 폐쇄망 Importer.
- "환경마다 다르다"가 기본 전제 — 고객사 형상 기록(백업본/updater/proxy 버전·설치일)을 먼저 확인할 것.
- 최종 해결자 라인: 기술지원팀/외주 → (미해결) → 데이터파트 시스템 담당자.
- 연계 항목: 체계적 이슈 트래킹 & 장애 추적 — 지원 이슈의 기록/추적 측면에서 연결.
5공개(포트폴리오)와의 차이
공개 버전(human/portfolio/items/onprem-binlog-shipping-support.html)은 고객사명·내부 호스트명/IP·이미지명·티켓 ID·내부 테이블명 등 내부 식별자를 제거하고, on-premise·바이너리 로그 쉬핑·동기화 에이전트·다운로드 프록시·폐쇄망·파일 반입기 같은 일반 개념어만 유지해 일반화했다. 이 내부 문서는 본인 참고/온보딩용이며 내부 식별자를 포함할 수 있다.