데이터베이스 스키마 관리의 필요성

최근에 회사에서 기존에 AWS에서 서비스하던 서비스를 ALI 클라우드에서 제공해야하는 일이 있었다. 따라서 데이터베이스 스키마와 마스터 데이터를 새로운 클라우드 환경으로 이전을 시켜줘야 했다.

비교적 규모가 큰 서비스는 아니여서, 덤프를 이용해서 간단하게 이전하였고, 데이터베이스 스키마 및 마스터 데이터를 쿼리문 형태로 만들어서 GIT으로 형상관리를 하였다.

이 정도로 모든 일이 마무리 되기는 하였지만, 어딘가 부족한 느낌이 들었다. 왜냐하면 개발을 하면서 DB 스키마가 변경할 일이 있는데 그럴 때마다 쿼리문으로 테이블 스키마를 변경하고, 스키마 파일을 업데이트 해야했기 때문이다. 문제는 변경해줘야 할 환경이 AWS, ALI 각각 DEV, EDU, STG, PROD이 존재하므로 8 개의 환경을 업데이트 해주어야 했습니다. 그리고 메일 서버가 바라보는 테이블까지 생각하면 서비스가 조금만 더 확장된다면 엄청나게 힘들어 질 것이다.

게다가 단순한 컬럼 값 추가, 삭제가 아니라 컬럼이 어떤 연산을 통해서 새로운 값을 가져야 하거나, 새로운 테이블을 만들어 기존 데이터를 옮기거나 하는 좀 더 복잡한 작업이 되면 엄청나게 복잡해 질 수 있다.

따라서 현대적인 애플리케이션 개발 환경에서는 단일 DB 스키마가 아니라, 변화를 다루는 마이그레이션 스크립트를 만들어서 사용한다. 소스 코드 저장소에 함께 포함을 시키고, 모든 환경에서 서버를 구동하기 전에 적용시키는 방법을 사용한다.

Flyway

• Flyway는 오픈소스 데이터베이스 마이그레이션 도구이다.
• 마이그레이션은 SQL 또는 Java로 작성할 수 있다.
• 일곱 가지의 간단한 명령어로 구성되어 있다. (Migrate, Clean, Info, Validate, Undo, Baseline, Repair)
• 다양한 패키지 및 빌드 도구에서 지원하며 플러그인 형태로도 이용할 수 있다.
• 많은 DBMS를 지원한다. (MySQL, Postgres, H2, …)

마이그레이션이 필요한 이유

• 애플리케이션의 경우, GIT과 같은 형상 관리 툴로, 재현 가능한 구조와 CI 환경을 구성할 수 있다.
• 릴리즈 및 배포 프로세스를 잘 정의함으로써, 이를 관리할 수 있다.

• 불행하게도 애플리케이션과 데이터베이스 간의 불일치가 발생할 수 있다.
• 하지만 여전히 많은 프로젝트가 수동으로 적용된 SQL 스크립트에 의존하고 있다.

데이터베이스 마이그레이션은 이러한 혼란을 제어할 수 있는 좋은 방법이다. 마이그레이션은 위와 같은 문제에 대해서 다음과 같은 이점을 제공합니다.

• 처음부터 데이터베이스 다시 만들기
• 데이터베이스가 어떤 상태인지 확인
• 현재 버전의 데이터베이스에서 새로운 데이터베이스로 마이그레이션

Flyway 작동 원리

가장 간단한 경우는 Flyway가 비어있는 데이터베이스를 가리킬 때입니다.

• 데이터베이스가 비어있으므로, Flyway는 데이터베이스를 찾지 못하고 대신 생성한다.

• 그리고 Flyway는 마이그레이션을 위해서 파일 시스템 및 응용 프로그램의 클래스 경로를 탐색하기 시작한다.

• 그런 다음에 마이그레이션은 버전 번호를 기준으로 정렬되고 순서대로 적용될 뿐이다.

• 각 마이그레이션이 적용될 때마다 스키마 기록 테이블이 업데이트 되며 이러한 이력 데이터로 특정 버전으로 쉽게 마이그레이션을 할 수 있습니다.

결론

현재 진행하는 프로젝트에 도입을 해도 괜찮을 것 같고, 마치 깃을 사용하는 것 같이 특정 버전의 스키마로 쉽게 돌아갈 수 있다는 것이 편리할 것 같다. 기존에는 특정 버전의 스키마를 보려면 깃으로 특정 버전의 스키마를 조회한 다음에 도커 가상 환경에서 마이그레이션을 하고 나서 테스트를 했다. 이렇게 진행하니까 테스트를 하기 위해서 준비해야할 것도 많고 번거로웠다. 지금 당장은 괜찮을지 몰라도 나중을 위해서 우선 시험삼아서 사용해보고 좋다면 팀원에게 소개를 해야겠다.

참고 문헌

Flyway, documentation