스프링 프로젝트를 진행하면서 나는 DB 테이블을 한 번에 다 생성하고 시작하는 것이 아닌 필요한 것을 만들어가면서 진행하고 있었다. 그러고 Front를 만들지 않기 때문에 DB data를 직접 mysql을 열어 넣어주고 수정하는 작업을 반복하게 되었다. 참 비효율적이라 생각했다. 그러던 도중 Flyway라는 Tool을 알게 되었다.
새로운 기술을 마주하면 항상 낯선 기분이지만 DDL을 자바에서 직접 관리를 하게 해주는 툴이라는 것을 알게 되었고, 나처럼 스키마의 잦은 변경이 일어날 경우에 사용해보면 좋겠다는 생각이 들었다. 그래서 한번 정리해보고 사용해 볼 생각이다.
혹시나 해서
Schema 가 뭐야?
데이터베이스의 구조와 제약조건에 관해 전반적인 명세를 기술한 것!
1. 개념 스키마 - 전체적인 뷰
2. 내부 스키마 - 물리적인 저장장치에서 DB가 저장되는 방법을 기술한 것
3. 외부 스키마 - 서브 스키마, 사용자 뷰
=> 쉽게 말해서 DB내에 어떤 구조로 데이터가 저장되었는지를 나타내는 구조를 일컫는다.
참조 : https://itkjspo56.tistory.com/94
Migration 이 무엇인가?
한 운영 환경으로부터 다른 운영 환경으로 옮기는 작업 (말 그대로 이주하다 라는 뜻인 듯)
그럼 DB Migration 은?
DB에서 DB Migration이란 DB 스키마의 버전을 관리하기 위한 방법 (데이터의 전환)
실무에서는 스키마의 변경이 정말 잦다고 한다.
ex) 테이블 생성 변경, 시스템 이전 작업 등등등.. => 생각만 해도 끔찍하다.
하여 DB Migration이란 개별 SQL 파일을 Mysql 같은 DMBS 콘솔에서 직접 실행하지 않고 프레임워크의 특정 명령을 통해 실행하고 그 결과를 별도의 테이블에 버전 관리(형상 관리)를 하는 방법이다!
Flyway를 사용해야 하는 이유
아직 나는 유지보수까지 경험해본 적이 없는 자바를 공부하는 학생이다. 근데 왜 공부를 해야 할까?
앞서 말했듯 자주 변경되는 스키마를 migration 하기 위해서는 mysql 콘솔에서 직접 관리해야 한다. 이는 참 번거로운 작업이다. 완벽한 사람이 아닌 이상 혼자 프로젝트를 하는 경우에도 스키마의 변경이 정말 잦을 수밖에 없을 것이다.
이를 찾아 매번 일일이 작업하는 것은 실수하기에도 딱 좋다.
코드를 관리하는 것처럼 DB 변경 사항을 직접 관리하면 좋지 않을까?
=> 그래서 나온 툴이 Flyway
특징
- 직접 DB에 접속해서 sql을 수정할 필요가 없다.
- SQL을 변경사항을 버전 관리하듯 파일로서 IDE에서 직접 관리 가능하다.
적용 과정
=> 그리고 서버를 실행!
서버 실행 시 SQL 파일을 (변경 사항)을 읽어 SQL을 실행한다.
다시 서버 실행!
Flyway는 만능인 걸까?
DBMS 서버를 왔다 갔다 안 해도 순수히 쿼리 파일로 스키마를 변경할 수 있다는 장점이 있지만, 협업에서는 또 다른 얘기가 된다.
- 내가 짠 코드는 문제없다는 것을 보증해야 함
- 내가 짠 코드를 얼마든지 남들이 반영할 수 있어야 함
- 어떤 코드가 DB 변경에 영향을 주었는지 찾을 수 있어야 함
- 앱은 이전 버전과 신규 버전이 공존할 수 있다.
=> 결국 규칙이 제일 중요
특히, Production Level 즉 배포 단계에서는 그리 좋은 선택은 아니다.
어떤 DDL은 dB 건수와 DB에 따라 수십 시간 정도 걸릴 수도 있다. 건수가 적은 경우는 서비스 영향이 미미하지만 데이터 단위가 커지면 단순한 칼럼 추가도 수십 분 걸릴 수 있다.
-> 이는 서비스에 영향을 주게 된다.
대안 : 프로덕션에서는 마이그레이션 기능을 수동으로 수행한다. (별도의 위키 페이지로 반영 여부를 체크하고 관리)
참조 : https://sabarada.tistory.com/193