고민의 시작
지금 회사의 아키텍쳐는 마이크로서비스 아키텍쳐 구조로 되어 있으며,
DB는 한 개를 사용하고 있고,
서비스 간 통신은 gRPC로 하고 있다.
문제는...!!
DB 변경사항은 노션 공통 페이지에 수기로 기록하고 있었다.
여기서 고민이 시작되었다.
- 현재 DB history를 수동으로 기록 → 놓치는 부분 발생
- DB의 변경사항이 생길때마다 기록 자동화 필요
- 개발을 하다보면 컬럼을 수정하거나 테이블을 수정하는 일 발생
- 배포하는 db에 직접 테스트 하게되는 경우 위험 → 치명적인 오류 발생 가능성 매우 높음
➡️ 따라서 나의 로컬 db에서 테스트 한 후 개발이 완료되어 원격서버에 배포할 때 데이터베이스 변경 사항 적용되도록
문제점
고민…
- 프로젝트에 어떻게 적용하면 좋을까?
- 프로젝트는 여러개, db는 한개 → 버전이 각 프로젝트마다 적용되는거 아닌가?
- 프로젝트에 적용해볼때 개발 db에 테스트를 해볼 수 있는건가..?
MSA 서비스에 적용 시
프로젝트마다 migrate 적용 시, versioning 문제에 부딪히게 된다.
lama 서비스에서는 version 1을 업데이트 했는데 Hyena 서비스에서는 version 3 를 업데이트하게 된다면
버전은 1 → 3로 바뀌게 된다.
해결책?
DB migration을 서비스로 따로 만든다면?
versioning은 순차적으로 쉽게 될것이다.
하지만, 서비스를 개발하다가 DB를 변경해야할 때, db migration 서비스를 따로 push 해야 한다.
이것은 DB를 직접 건들이지 않고 자동수정 되도록 하는 방식이므로
결국, entity를 수정하여 DB에 반영시키는 gorm auto migration 과 다를게 없다.
versining을 숫자가 아닌 ‘서비스명_날짜’ 이런식으로 네이밍한다면?
불가능! 숫자로된 버전명만 테이블에 입력된다.
→ 날짜로 versionging 하는 방법 뿐
migrate create -ext sql -dir db/migrations -tz UTC time
어떤 서비스를 위해, 누가 migration 작업을 했는지는
서비스마다의 sql 파일이 적재되고, 코드 히스토리가 남기때문에 해결
그러나...
DB 형상관리에 좀더 초점을 두자면,, DB 서비스르 따로 두는 것이 낫겠다고 판단.!
2탄에서 더 이야기를 이어가 보겠다.
참고
