서론
Flyway란 무엇인가?
데이터베이스 스키마의 버전 관리는 애플리케이션 개발의 중요한 부분입니다. 특히, 여러 개발자가 함께 작업하거나 다양한 배포 환경을 관리할 때 더욱 중요합니다. Flyway는 이러한 데이터베이스 마이그레이션을 자동화하고 버전 관리를 체계적으로 수행할 수 있게 도와주는 도구입니다.
Flyway가 필요한 이유
- 형상 관리: Flyway는 데이터베이스 스키마를 코드와 동일하게 형상 관리할 수 있게 해줍니다. 이를 통해 소스 코드와 데이터베이스 스키마의 동기화를 유지할 수 있습니다.
- 자동화: Flyway는 마이그레이션을 자동으로 적용하고, 마이그레이션 순서와 의존성을 관리합니다.
- 일관성 유지: Flyway는 체크섬을 사용하여 마이그레이션 파일의 무결성을 검증합니다. 이를 통해 마이그레이션 파일이 변경되었는지 여부를 감지하고, 일관성을 유지할 수 있습니다.
- 다양한 데이터베이스 지원: Flyway는 PostgreSQL, MySQL, Oracle, SQL Server 등 다양한 데이터베이스를 지원합니다.
형상 관리
형상 관리는 소스 코드뿐만 아니라 데이터베이스 스키마에도 적용될 수 있습니다.
이로 인해 다음과 같은 이점을 얻을 수 있습니다:
- 변경 이력 추적: 각 마이그레이션 파일은 특정 버전 번호를 가지며, 이를 통해 모든 데이터베이스 변경 이력을 추적할 수 있습니다.
- 동시 개발 지원: 여러 개발자가 동시에 작업할 때 발생할 수 있는 충돌을 최소화하고, 마이그레이션 순서를 관리합니다.
- 롤백 지원: (유료 버전) Flyway는 특정 버전으로 롤백할 수 있는 기능을 제공합니다.
체크섬을 통한 무결성 검증
Flyway는 각 마이그레이션 파일에 대해 체크섬을 생성하여, 파일이 변경되었는지 여부를 확인합니다. 체크섬은 다음과 같은 방식으로 작동합니다:
- 체크섬 생성: 각 마이그레이션 파일이 처음 적용될 때 Flyway는 해당 파일의 체크섬을 생성하고, 이를 flyway_schema_history 테이블에 저장합니다.
- 무결성 검증: 이후 애플리케이션이 시작될 때, Flyway는 현재 파일의 체크섬과 flyway_schema_history 테이블에 저장된 체크섬을 비교하여 파일이 변경되었는지 여부를 확인합니다.
- 오류 처리: 만약 체크섬이 일치하지 않으면, Flyway는 마이그레이션을 중단하고 오류를 보고합니다. 이를 통해 데이터베이스의 일관성을 유지할 수 있습니다.
Flyway의 주요 개념
Prefix
- V : Versioned migration - 버전 관리된 마이그레이션 파일입니다.
- U : Undo migration (유료 버전만 적용 가능) - 마이그레이션을 되돌리는 파일입니다.
- R : Repeatable migration - 여러 번 실행 가능한 파일로, 주로 참조 데이터나 뷰를 정의할 때 사용합니다.
Version
- 유일해야 합니다: 각 버전은 유일하게 정의되어야 하며, 중복된 버전은 사용할 수 없습니다.
- 기존 버전보다 값이 커야 합니다: 버전 번호는 반드시 기존 버전보다 큰 값을 가져야 합니다. 예를 들어, V1 다음에는 V2가 와야 합니다.
- 날짜 형식을 사용: 주로 날짜 형식을 사용하여 버전을 관리하는 것이 일반적입니다. 예: V20240722201714__Initial_Schema.sql
의존성
implementation("org.flywaydb:flyway-core")
implementation ("org.flywaydb:flyway-database-postgresql")
저는 postgresql을 사용하니 위와같이 의존성을 추가해주었습니다.
주의! Seperator는 언더바가 두 개입니다!!
마이그레이션 파일을 작성할 때, 파일명에 언더바 두 개(__)를 사용하는 것을 잊지 마세요.
ex) v0__init.sql
spring:
...
flyway:
enabled: true
locations: classpath:db/migration
baseline-version: 20240722201714
baseline-on-migrate: true
url: jdbc:postgresql://localhost...
user:
password:
기본 경로는 resources/db/migration입니다.
@Configuration
class FlywayConfig {
@Configuration
class FlywayConfig {
@Bean
fun flyway(flywayProperties: FlywayProperties): Flyway {
val flyway = Flyway.configure()
.baselineOnMigrate(flywayProperties.isBaselineOnMigrate)
.baselineVersion(flywayProperties.baselineVersion)
.dataSource(flywayProperties.url, flywayProperties.user, flywayProperties.password)
.load()
flyway.repair()
flyway.migrate()
return flyway
}
@Bean
fun flywayProperties(): FlywayProperties {
return FlywayProperties()
}
}
}
Spring Boot와의 통합
- org.springframework.boot:spring-boot-starter-jdbc
- org.springframework.boot:spring-boot-starter-data-jpa
사실 FlywayConfig를 굳이 추가하지않더라도 위와 같은 JDBC 기반 Spring Boot 스타터 의존성을 추가하게 된다면, Spring Boot 애플리케이션이 시작될 때 자동으로 데이터베이스와 연결되어 마이그레이션을 수행합니다.
다만, 설정의 명확함과 직접 커스텀할 수도 있고 컨텍스트가 없는 개발자가 봐도 명확히 Config가 구성되어있다면 좋을 것 같다는 생각으로 추가해두었습니다.
주의사항
- 파일명 구분자: 마이그레이션 파일명을 정의할 때, 파일명 구분자로 언더바 두 개(__)를 사용해야 합니다.
- ex) V20240722201714__Initial_Schema.sql
- 버전 관리: 마이그레이션 파일의 버전은 반드시 이전 버전보다 커야 하며, 중복될 수 없습니다.
- 데이터베이스와의 연결: Flyway 설정 파일(application.yml)에 올바른 데이터베이스 연결 정보가 포함되어야 합니다.
- 데이터 타입 일관성: 외래 키 제약 조건을 설정할 때, 참조되는 컬럼의 데이터 타입이 일치하는지 확인해야 합니다.
- 플러그인 사용: IntelliJ IDEA의 Flyway Migration Creation 플러그인을 사용하면 마이그레이션 파일명을 자동으로 생성할 수 있습니다. 플러그인을 설치하고 사용하면, 파일명을 입력할 때 현재 날짜를 기준으로 버전을 자동으로 생성해줍니다.
- 자동 마이그레이션: Spring Boot와 Flyway를 통합할 때, Spring Boot 애플리케이션이 시작될 때 자동으로 마이그레이션이 수행됩니다. 불필요한 라이브러리를 추가하지 않도록 주의하고, 필요한 경우 설정 클래스를 통해 유연하게 Flyway를 구성할 수 있습니다.
마무리
Flyway는 데이터베이스 마이그레이션을 관리하는 데 매우 유용한 도구입니다. 설정을 명확하게 이해하고, 주의사항을 잘 준수하여 Flyway를 효율적으로 활용할 수 있습니다. 위 내용을 참고하여 Flyway를 설정하고, 데이터베이스 마이그레이션을 보다 체계적으로 관리해보세요.
참고
- Flyway 공식 문서
- IntelliJ IDEA Flyway Migration Creation 플러그인 (마이그레이션 파일 생성을 편리하게 이용할 수 있습니다)