Flyway 도입기, DB 목 데이터 관리

새코리입니다,, 국비에서 팀원들과 찾아냈던 방법은 sql로 목데이터를 주입하는 방법이었습니다. 근데 현장에 나와보니 DB도 두개나 연결해야할 일이 생기고(스프링 배치) 목데이터도 워낙 많아져 관리가 필요했습니다. 이에 찾아낸 방법이 flyway! DB 버전의 깃같은 느낌이었습니닿ㅎㅎㅎ 혼자 뒤적이다가 방법찾고 예쁘게 세팅했을 때 희열이 있을 것 같습니당,, 설정도 쉽고 관리도 쉽고! 꼭 써보세요~

1. Flyway 도입 배경

프로젝트에서 데이터베이스 스키마 변경 및 초기 데이터를 관리하는 방식으로 기존에는 data.sql, schema.sql 파일을 통해 초기화하고, ddl-auto 옵션을 활용하여 JPA가 자동으로 테이블을 생성하도록 설정했습니다. 하지만 다음과 같은 문제로 인해 Flyway를 도입하게 되었습니다.

데이터베이스 변경 이력 관리의 어려움
- 개발 중 스키마가 자주 변경되면서 데이터베이스 초기화 방식에 일관성을 유지하기 어려웠습니다.
- 이전 버전의 스키마 상태를 추적하거나 되돌릴 수 있는 수단이 없었습니다.
환경별 관리의 복잡성
- 개발 환경과 운영 환경에서 다른 방식으로 스키마를 관리하고 있었기 때문에, 환경 간 스키마 차이가 발생할 위험이 있었습니다.
데이터 마이그레이션 필요성
- 단순히 테이블을 생성하는 것뿐만 아니라, 기존 데이터에 대한 마이그레이션(데이터 변환, 새로운 테이블로 이동 등)이 필요해졌습니다.

2. Flyway 도입 목표

Flyway 도입을 통해 다음과 같은 목표를 달성하고자 했습니다.

스키마 변경 이력 관리 자동화
각 버전의 스키마 변경 사항을 SQL 파일로 관리하고, 변경 내역을 자동으로 기록하여 관리 용이성을 높입니다.
환경 간 일관성 유지
개발, 테스트, 운영 환경에서 동일한 마이그레이션 파일을 사용하여 스키마 변경을 적용함으로써, 환경 간 차이를 방지합니다.
데이터 마이그레이션 지원
스키마 변경뿐만 아니라 초기 데이터 삽입 및 데이터 변환도 Flyway 마이그레이션 파일로 관리합니다.

3. 도입 과정

Flyway 의존성 추가

dependencies {
    implementation("org.flywaydb:flyway-core")
    implementation("org.flywaydb:flyway-mysql")
}

build.gradle.kts에 다음과 같이 Flyway 의존성을 추가했습니다.

마이그레이션 파일 구조 설계
```
plaintext
코드 복사
src/main/resources/db/migration/target/
├── V1__init_schema.sql           # 초기 테이블 생성 파일
└── V2__insert_initial_data.sql   # 초기 데이터 삽입 파일
```
- V1__init_schema.sql: 테이블 및 제약 조건을 정의하는 SQL 스크립트.
- V2__insert_initial_data.sql: 플랫폼, 패턴, 사용자, 매장 등 초기 데이터를 삽입하는 SQL 스크립트.
  초기 스키마와 데이터를 별도의 파일로 분리하여 관리하도록 했습니다.

Flyway 수동 실행 설정

java
코드 복사
@Configuration
public class FlywayConfig {

    @Bean
    public CommandLineRunner flywayMigrateTarget(@Qualifier("targetDataSource") DataSource targetDataSource) {
        return args -> {
            Flyway.configure()
                  .dataSource(targetDataSource)
                  .locations("classpath:/db/migration/target")
                  .load()
                  .migrate();
        };
    }
}

Flyway는 수동으로 실행할 수 있도록 설정하여, 운영 환경에서도 제어된 방식으로 마이그레이션이 수행되도록 했습니다.

Spring Boot 설정 변경
기존 JPA의 ddl-auto 설정을 validate로 변경하여, Flyway가 데이터베이스 스키마를 관리하도록 했습니다.

4. Flyway 도입 후 효과

Flyway 도입 후 다음과 같은 효과를 얻을 수 있었습니다.

데이터베이스 스키마 관리 자동화
모든 스키마 변경이 버전 관리되고, 변경 이력을 쉽게 추적할 수 있게 되었습니다.
환경 간 일관성 보장
동일한 마이그레이션 파일을 사용하여 개발, 테스트, 운영 환경에서 일관된 스키마 상태를 유지할 수 있게 되었습니다.
데이터 마이그레이션 자동화
초기 데이터 삽입 및 기존 데이터를 새로운 스키마로 이전하는 작업을 자동화할 수 있었습니다.
변경 이력 추적 가능
Flyway가 자동으로 관리하는 flyway_schema_history 테이블을 통해 어떤 변경이 언제 적용되었는지 쉽게 추적할 수 있습니다.

5. 도입 과정에서의 어려움과 해결 방법

MariaDB 최신 버전 지원 문제
Flyway가 MariaDB 11.x 버전을 지원하지 않아 초기에는 오류가 발생했습니다. 이를 해결하기 위해 Flyway 최신 버전으로 업그레이드하여 문제를 해결했습니다.
초기 데이터 삽입 문제
초기에는 스키마 생성과 데이터 삽입을 하나의 파일에서 관리했으나, 데이터 삽입이 제대로 되지 않는 문제가 발생했습니다. 이를 해결하기 위해 스키마 생성 파일과 초기 데이터 삽입 파일을 분리하여 관리하도록 개선했습니다.

6. 향후 계획

운영 환경에서 자동 마이그레이션 활성화
운영 환경에서도 Flyway 자동 마이그레이션을 활성화하여, 스키마 변경을 자동으로 적용할 계획입니다.
마이그레이션 파일 관리 방식 고도화
데이터베이스 변경 내역과 주요 내용을 문서화하여 팀 내 공유를 강화할 예정입니다.

7. 결론

Flyway 도입을 통해 데이터베이스 스키마 관리 및 데이터 마이그레이션 작업이 훨씬 체계적이고 일관되게 이루어지게 되었습니다. 향후 지속적으로 마이그레이션 파일을 관리하고, 운영 환경에서의 Flyway 활용을 확대할 예정입니다.

새끼코딩오리