MySQL 아키텍처 개선: DB 의존성 분리와 서버 역할 명확화
초기 구현 단계에서 API 서버와 Media 서버가 모두 MySQL에 직접 접근하는 구조를 채택했습니다. 이 과정에서 다음과 같은 문제점들이 발견되었습니다
-
데이터베이스 의존성 증가
- 두 서버 모두 DB 스키마에 강하게 결합됨
- DB 변경 시 양쪽 서버 모두 수정 필요
-
유지보수의 어려움
- 동일한 DB 관련 로직이 두 서버에 중복 존재
- 코드 수정 시 양쪽을 동시에 고려해야 함
-
장점
- 직접 DB 접근으로 인한 속도 향상
- API 서버 의존성 감소
-
단점
- DB 의존성 증가
- 데이터 일관성 관리의 어려움
- 코드 중복
-
장점
- DB 관련 로직 중앙화로 유지보수 용이
- 데이터 일관성 보장 용이
- 비즈니스 로직의 명확한 분리
-
단점
- API 서버에 대한 의존성 발생
- 추가적인 네트워크 홉(Network Hop) 발생
- DB 접근은 한 곳에서 관리하는 것이 일반적
- 같은 VPC 내에서는 성능 저하 미미
- 비즈니스 로직 중앙화의 이점이 더 큼
- API 서버의 부하는 크지 않을 것으로 예상
-
단일 책임 원칙 (SRP)
- API 서버만 DB 접근 권한 보유
- Media 서버는 미디어 처리에 집중
-
의존성 역전 원칙 (DIP)
- Media 서버와 API 서버 간의 결합도 감소
- 인터페이스를 통한 통신 구조 설계
- 기존 Media 서버의 서비스 로직을 API 서버로 이전
- 인터페이스 기반의 의존관계 설계
- API를 통한 데이터 접근 계층 구현
