1. 데이터 마이그레이션, 왜 필요했는가?
서비스를 배포한 후 스키마가 구조가 변경되는 상황에 대한 대안이 필요했다.
프로젝트가 얼추 끝나갈 때 쯤, 기능을 추가하거나 변경하면서 테이블의 제약조건이나 필드가 변경되는 일이 생겼고 변경사항을 적용시키느라 DB를 드랍하는 일도 종종 생겼다.
서비스를 배포하면 일정 기간동안 유지보수를 하게 될텐데 사용자의 정보를 이런식으로 날리는건 있을 수 없는 일이었기 때문에 사용자 정보를 유지하면서 스키마를 변경할 방법이 필요했다.
2. DB migration tool 선택
spring boot로 개발하고 있었기 때문에 프레임워크 내에서 관리가 되는 툴을 원했다.
가장 유용하게 사용되는 것이 Liquibase, Flyway 두가지 였는데, 아래와 같은 이유로 flyway로 결정했다.
두가지 툴의 공통점으로는
- 데이터베이스 변경에 대한 마이그레이션 기반 접근 방식 사용
- 업데이트 시 두 도구 모두 변경 사항이 이미 배포되었는지 확인
- 명령줄 또는 Maven(gradle, xml...)에서 실행
- SQL 기반 마이그레이션 사용
- 반복 가능한 마이그레이션
등의 특징을 갖고 있다.
liquibase는 flyway에 없는 rollback 기능이 있지만 지금처럼 규모가 작은 프로젝트에서 중요한 역할은 아니었고 flyway가 작성한 버전 순서대로 착오없이 작동하고 liquibase보다 오류없이 안정적으로 작동한다는 점, 팀원과 공유하기 편리하게 한글로 작성된 자료가 많다는 점에서 flyway를 선택하게 되었다.
3. 결과
gradle 의존성을 추가해주고 hibernate의 ddl-auto를 none으로 설정한다.
resource/db/migration 디렉토리에 버전별로 변경할 쿼리문을 작성해주고 Entity에도 변경사항을 똑같이 적용시켜놓으면 별다른 에러없이 바로 변경되는 것을 볼 수 있다.
ALTER TABLE heart
ADD FOREIGN KEY (post_id)
REFERENCES post (id)
ON DELETE CASCADE;변경이 success 되면 아래와 같이 flyway_schema_history라는 히스토리 테이블이 생성돼서 지금까지 변경했던 내용들을 확인할 수 있다.
migration의 필요를 모르고 배포를 했었다면 스키마 변경시에 급한대로 DB에 직접 접근해서 table을 수정하는 번거로운 작업을 했을 수도 있고 그러다 어떤 실수를 저질렀을 수도 있다.
언제 어떻게 스키마가 변경되었는지 확인할 수 있도록 버전 관리까지 되니 잘 기억해두면 다음에 또 필요한 상황에서 유용하게 사용할 듯 하다.
