• 카테고리

    질문 & 답변
  • 세부 분야

    데이터베이스

  • 해결 여부

    해결됨

하나의 디비를 여러 백엔드 서버가 필요로 할 때, flyway 관리

24.06.23 23:24 작성 조회수 118

1

  • 전제 및 요구사항

    • DB 하나에 종류가 다른 서버가 4개가 붙어있습니다. flyway를 통해서 DB version control을 하고 싶습니다. node의 nestjs와 typeorm을 사용할 때는 CICD 단계에서 typeorm-migration을 통해서 기존에 만들어둔 DDL 쿼리를 적용한 후 앱 빌드 후 배포해서 dev & prod 환경에서 문제가 없게끔 돌아갔습니다.

  • 질문

    • 스프링에서 CICD(ex github action) 단계 때 flyway가 실행되어서 테이블을 데브나 프로덕션 단계 때 마이그레이션 적용이 가능할까요?

    • (실습) Testcontainers + Flyway를 통해 DDL로 jOOQ DSL 만들기 에서 본 대로 이해한다면 각각 레포지토리마다 DB 폴더를 만들고 V1__init_tables.sql를 다 만들어야 dsl을 생성할 수 있어 보이는데, 그러면 프로젝트(레포지토리)가 4개나 되다 보니, table 버전 관리가 안 될 것 같고 이미 테이블을 생성 되었는데 또 테이블을 생성하는 .sql을 실행해야 할 것 같아서 문제가 생길 것 같은데, 방법이 있을까요?

답변 4

·

답변을 작성해보세요.

1

인프런 AI 인턴님의 프로필

인프런 AI 인턴

2024.06.25

안녕하세요, 인프런 AI 인턴입니다.

  • 스프링에서 CI/CD 단계(ex GitHub Actions) 때 Flyway 마이그레이션을 실행하는 것은 가능합니다. 프로젝트의 pom.xml이나 build.gradle 파일에 Flyway 플러그인을 구성하여 CI/CD 파이프라인 스크립트에서 마이그레이션 명령을 실행함으로써 개발(dev) 및 운영(prod) 환경에서의 데이터베이스 마이그레이션을 자동으로 적용할 수 있습니다.

  • 프로젝트(레포지토리)가 여러 개 있을 경우에도 Flyway를 사용하여 테이블 버전 관리를 할 수 있습니다. 이를 위해서는 모든 마이그레이션 스크립트를 중앙 집중식으로 관리하면서, 각 서비스마다 다른 마이그레이션 경로(spring.flyway.locations)를 지정하는 방법을 사용할 수 있습니다. 예를 들어, 공통된 데이터베이스 마이그레이션은 모든 프로젝트가 접근할 수 있는 중앙 리포지토리에서 관리하고, 각 서비스의 특성에 따른 추가 마이그레이션은 서비스별로 분리하여 관리할 수 있습니다.

또한, 테이블이 이미 존재하는데 마이그레이션이 실행되는 경우, Flyway는 별도의 버전 관리를 통해 이미 실행된 마이그레이션이 중복 실행되지 않도록 관리합니다. 각 마이그레이션 파일의 버전을 명시적으로 관리하고, 이전에 실행한 마이그레이션과 현재 실행하려는 마이그레이션 사이의 버전을 체크하여, 이미 적용된 마이그레이션은 건너뛰고, 새로운 마이그레이션만 실행하게 됩니다.

자세한 설정 방법이나 마이그레이션 전략을 수립하는 데 필요한 세부 정보는 Flyway 공식 문서를 참고하는 것이 좋습니다.

더 자세한 정보는 Spring Boot 공식 문서를 참고하세요.

0

해당질문 완료처리하도록 하겠습니다.

궁금한 부분있으면 추가적으로 댓글 부탁드려요

0

안녕하세요 해당 질문 답변드립니다.

 

  1. 스프링에서 CICD 단계 때 flyway로 데브나 프로덕션 단계 때 마이그레이션 적용 가능여부

해당 방식 여러가지 방법으로 가능합니다. 다만 이 방식 자체를 추천하지 않습니다.

maven 이나, gradle 에서 빌드 완료 시 실행 할 수도 있고, 배포 후 스프링에서 이렇게 실행을 할 수 도 있지만

이런 방식으로 DDL 자체를 dev나 prod에서 자동으로 실행하는건 너무나도 위험합니다.

 

DDL은 트랜잭션이 지원되지 않습니다.
실수로 빌드가 완료 된 후 DDL을 실행했는데 중간에 오타가 있다면 그 부분은 결국 또 수기로 처리해야합니다.

 

개발 페이즈에 만들었던 DDL을 운영에 그대로 반영하면 안되는 경우도 꽤 있습니다.

배포와는 별개로 사용자가 적은 시간대에 인덱스를 추가하거나, online DDL을 위해서 쿼리가 변경되서 반영되어야하는 경우가 예시 중 하나입니다.

 

데이터가 유실되거나 장애를 발생시킬 경우도 존재하기 때문에 운영 DDL은 자동화하면 안됩니다.

 

  1. 프로젝트(레포지토리)가 4개 경우에 code로 DDL 관리

4개의 프로젝트가 같은 DB를 바라보고있는걸로 보이는데요.

RDBMS의 role로 관리되고 있다면 해당 role 에 맞춰서 프로젝트별로 관리하면 되고,

 

DDL을 코드로 관리하기 전에 4개 프로젝트 모두 모든 DB 테이블에 접근 할 수 있나요?

만약 그렇다면 이부분부터 문제가 있다고 생각합니다.

만약 논리적인 구분없이 4개의 프로젝트 모두 DB 테이블에 접근이 가능하다면

4개의 프로젝트를 하나의 모노레포로 만들고 하위에 공통 모듈을 두어 거기서 DSL을 만들어 관리하게 하는 방법이 제일 적절해보입니다.

 

 

 

0

오늘안에 답변드리도록 하겠습니다.

채널톡 아이콘