작업 완료 · 2024
DB 아키텍처 리엔지니어링 — 인스턴스 분리
변경량이 큰 파일 데이터와 나머지 데이터를 별도 인스턴스로 분리해 전달 지연을 줄였습니다.
기간2024
소속래브라도랩스(LabradorLabs)
역할데이터 엔지니어 · 재설계 주도
DB 아키텍처MySQLReplication
작업 요약
binlog 전달 이슈 일 1~2건 → 월 1~2건
파일 데이터의 부하가 다른 데이터에 영향을 줬습니다
파일 컴포넌트와 라이브러리·취약점·라이선스 데이터가 한 DB에 쌓이면서 부하와 장애가 서로 영향을 줬습니다.
파일 컴포넌트 계열을 별도 인스턴스로 분리해, 각 데이터의 부하를 확인하고 자원을 따로 늘릴 수 있도록 했습니다.
배경
수년간 데이터가 누적되며 역할이 다른 데이터가 한 인스턴스에 혼재된 구조로 운영되어 부하·장애가 서로 간섭하고 확장과 유지보수가 어려웠습니다.
Before
역할이 다른 데이터(원천/가공/배포용)가 한 인스턴스에 혼재 → 부하·장애 상호 간섭, 확장 병목After
역할·컴포넌트 단위로 인스턴스 분리 → 장애 격리, 독립 확장, 운영 대상 구분한 일
- 단일 DB를 데이터 성격 기준 2개 인스턴스 계열로 분리 — 대용량 파일 컴포넌트 계열과 그 외(라이브러리·취약점·라이선스) 계열로 나눠 핵심 DB의 부하·크기 부담 완화
- 각 계열을 master-replica 복제 구성으로 두어 읽기 부하 분산과 가용성을 확보
- 분리 스크립트를 직접 작성·테스트해 단계적으로 적용
- 복제 인스턴스 분리에 맞춰 다운로드 웹서버·동기화 모듈을 개선해 동기화 경로 정비
아키텍처 (토폴로지)
성격이 다른 대용량 데이터는 핵심 DB에서 분리해 별도 인스턴스로 운영.
결과
장애 격리한 컴포넌트의 부하/장애가 전체로 번지지 않는 구조
개별 자원 확장컴포넌트별로 리소스를 따로 늘릴 수 있는 구성
백업·모니터링 분리운영 대상이 나뉘어 백업·모니터링·변경이 단순화
역할
데이터 엔지니어로서 토폴로지 재설계와 인스턴스 분리, 동기화 경로 정비를 직접 수행했습니다. 분리 방안은 팀장·CTO 리뷰로 확정했고, 운영·고객사 동기화에 영향을 주는 변경이라 단계적으로 적용했습니다.
같은 해 MySQL 8.0→8.4 LTS 업그레이드, 바이너리 로그 암호화와 함께 진행한 DB 플랫폼 개선 작업의 일부.