Flyway 로 스키마 관리
애플리케이션 개발을 하다보면 데이터베이스 스키마 변경은 매우 빈번하게 일어납니다. (우리 코드잽에서도 자주 스키마가 변경되기도 했었습니다..)
마이그레이션 도구를 사용하지 않았을 경우, 우리는 개발, 운영 환경에서 ddl-auto: none 또는 validate 로 옵션을 지정하곤 하는데요.
이는 애플리케이션 실행 시 Hibernate가 자동으로 데이터베이스 스키마를 변경하지 않도록 하기 위함입니다.
하지만 이렇게 되면 스키마가 변경될 때마다 DB 인스턴스에 접속하여, 수동 DDL 실행을 해주어야 합니다.
여러 환경이 분리된 상황에서 매 인스턴스에 접속할 수도 없고 우리는 캠퍼스 외에서 DB 인스턴스에 접근할 수 없기 때문에 대참사가 발생합니다........
이러한 문제들을 해결하기 위해 데이터베이스 마이그레이션 도구의 사용이 필요합니다.
Flyway는 데이터베이스 스키마 버전 관리 도구입니다.
SQL 스크립트를 사용하여 데이터베이스 변경사항을 추적하고 적용할 수 있게 해줍니다. 쉽게 말해 앞의 문제점을 해결해주는 도구라고 생각하면 됩니다.
이 Flyway를 사용하면 Flyway가 스크립트로 작성한 ddl을 알아서 날려주기 때문에 직접 데이터베이스에 접속하여 ddl을 날리지 않아도 됩니다.
Flyway를 본격적으로 적용하기 앞서 한가지 더 알아야 할 개념이 있습니다. Flyway의 Baseline은 기존 데이터베이스에 Flyway를 적용할 때 사용하는 중요한 기능입니다.
우리는 이미 기존 데이터베이스가 있는 상태에서 Flyway를 도입했습니다.
따라서 Baseline으로 지정된 버전을 시작점으로 표시하면, 이 지정된 버전 이전의 모든 마이그레이션은 이미 적용된 것으로 간주합니다.
이후의 마이그레이션만 실제로 적용됩니다. 따라서 현재 데이터베이스 상태를 유지하면서 Flyway 도입이 가능합니다. 본격적으로 도입 flyway 개념에 대해 알아보았으니 이제 spring-boot에 적용하는 것을 토대로 설정을 해봅시다.
- 의존성 추가
// build.gradle
implementation 'org.flywaydb:flyway-core'
implementation 'org.flywaydb:flyway-mysql' // MySQL 사용 시 - application.yml 설정
spring:
flyway:
enabled: true
baseline-on-migrate: true
locations: classpath:db/migration 각 옵션의 의미는 다음과 같습니다.
- spring.flyway.enabled=true
- Spring Boot 애플리케이션에서 Flyway를 활성화합니다.
- 애플리케이션 시작 시 Flyway가 자동으로 마이그레이션을 실행합니다.
- spring.flyway.baseline-on-migrate=true
- 비어있지 않은 데이터베이스에 대해 자동으로 baseline을 설정합니다.
- 기존 데이터베이스에 Flyway를 처음 적용할 때 발생할 수 있는 문제를 예방합니다.
- spring.flyway.locations=classpath:db/migration
- 마이그레이션 스크립트 파일의 위치를 지정합니다.
- 지정된 경로에서 마이그레이션 스크립트를 찾아 실행합니다.
자 이제 설정을 통해 Baseline이 지정되어 있기 때문에 flyway를 사용하려면 문법에 맞는 스크립트 파일을 작성해주면 됩니다.
Version은 차이점이 있는 마이그레이션 스크립트를 순차적으로 실행하고, Undo는 되돌리기(유료임), Repeatable는 매 스크립트 실행 완료 후 반복되는 스크립트의 옵션입니다.
(우리는 Undo와 Repeatable은 사용할 일이 많이 없기 때문에 넘어가도 될 것 같아요.)
프로젝트 초반부터 사용하지 않아서, 로컬에서 테스트를 해봤는데 다음과 같은 에러가 발생했었습니다.
IF NOT EXISTS와 같은 특정 데이터베이스 특화 문법은 주의해서 사용해야 합니다. 특정 데이터베이스에서만 동작하는 문법을 사용하면 다른 환경에서 마이그레이션이 실패할 수 있습니다.
큰 변경사항은 여러 개의 작은 마이그레이션으로 나누는 것이 좋은데요. 아래와 같은 이유를 참고하면 좋을 것 같습니다. 리스크 관리 작은 변경사항은 문제 발생 시 파악과 해결이 쉽습니다. 큰 변경사항 중 일부만 실패할 경우, 전체 롤백이 아닌 부분적 수정이 가능합니다. 따라서 문제 발생 시 특정 단계까지만 롤백하기 쉬워집니다.
스키마 히스토리 테이블에 문제가 생겼을 때, 이를 해결하기 위한 기능입니다.
실패한 마이그레이션 항목 제거 적용된 마이그레이션의 체크섬, 설명 및 유형을 사용 가능한 마이그레이션의 체크섬과 다시 정렬 누락된 모든 마이그레이션을 삭제된 것으로 표시 위와 같은 기능을 해결해주는데, repair는 마이그레이션이 실행될 때에 진행되어야 합니다.
스프링에서는 FlywayMigrationStrategy를 제공해주는데, Flyway 마이그레이션을 초기화하는 데 사용되는 전략으로, 사용자 정의 구현을 @Bean으로 등록하여 기본 migrate 동작을 재정의할 수 있습니다.
우리 애플리케이션에도 다음과 같이 적용되있습니다.
@Configuration
public class FlywayRepairConfiguration {
@Bean
public FlywayMigrationStrategy flywayMigrationStrategy() {
return flyway -> {
flyway.repair();
flyway.migrate();
};
}
}매 flyway의 migrate 작업이 실행되기 직전 repair를 해준다면 flyway에 문제가 발생해도 적절한 상태에서 migrate 가능합니다.