DB 아키텍처 리엔지니어링 — 컴포넌트별 인스턴스 분리

장기 운영으로 혼재된 단일 DB 구조를 역할·컴포넌트 단위 인스턴스로 분리해 확장성과 운영 책임을 명확히 한 재설계

기간2024

소속래브라도랩스(LabradorLabs)

역할데이터 엔지니어 · 재설계 주도

MySQLReplicationDB 아키텍처AWS / IDC

0작업자의 메모

하나의 DB에 모든 데이터가 오래 쌓이면 장애도 성능 문제도 한 덩어리로 보입니다. 이 작업은 테이블을 나누는 수준이 아니라 데이터 성격별로 책임 경계를 다시 잡은 재설계였습니다.

인스턴스 분리는 운영자가 “어디가 아픈지” 더 빨리 볼 수 있게 해줍니다. 파일 컴포넌트 계열과 그 외 데이터를 나눠 확장과 장애 격리의 출발점을 만든 이유가 여기에 있습니다.

수년간 데이터가 누적되며 역할이 다른 데이터가 한 인스턴스에 혼재된 구조로 운영되어 부하·장애가 서로 간섭하고 확장과 유지보수가 어려웠습니다.

역할이 다른 데이터(원천/가공/배포용)가 한 인스턴스에 혼재 → 부하·장애 상호 간섭, 확장 병목

역할·컴포넌트 단위로 인스턴스 분리 → 장애 격리, 독립 확장, 책임 경계 명확

단일 DB를 데이터 성격 기준 2개 인스턴스 계열로 분리 — 대용량 파일 컴포넌트 계열과 그 외(라이브러리·취약점·라이선스) 계열로 나눠 핵심 DB의 부하·크기 부담 완화
각 계열을 master-replica 복제 구성으로 두어 읽기 부하 분산과 가용성을 확보
분리 스크립트를 직접 작성·테스트해 단계적으로 적용
복제 인스턴스 분리에 맞춰 다운로드 웹서버·동기화 모듈을 개선해 동기화 경로 정비

성격이 다른 대용량 데이터는 핵심 DB에서 분리해 별도 인스턴스로 운영.

장애 격리 — 한 컴포넌트의 부하/장애가 전체로 번지지 않는 구조

독립 확장성 — 컴포넌트별로 리소스를 따로 키울 수 있는 토대

운영 명확성 — 책임 경계가 분명해져 백업·모니터링·변경이 단순화

데이터 엔지니어로서 토폴로지 재설계와 인스턴스 분리, 동기화 경로 정비를 직접 수행했습니다. 분리 방안은 팀장·CTO 리뷰로 확정했고, 운영·고객사 동기화에 영향을 주는 변경이라 단계적으로 적용했습니다.

같은 해 MySQL 8.0→8.4 LTS 업그레이드, 바이너리 로그 암호화와 함께 진행한 DB 플랫폼 개선 작업의 일부.