Liquibase와 사용하며 느낀 점

1. 글을 작성하게 된 계기

신규 기능을 개발할 때, 새로 생성/추가/제거되는 스키마를 반영하지 않아 운영 서버에 문제가 발생한 적이 있었습니다. 이 과정에서 어떻게 효율적으로 스키마를 추적하고 관리할 지에 대해 학습하며 Liquibase를 알게 되었고, 이를 정리하기 위해 글을 작성하게 되었습니다.

2. Liquibase와 선택 이유

Liquibase는 데이터베이스 형상 관리를 도와주는 라이브러리로, 데이터베이스 스키마의 변경사항을 추적하고 버전을 관리를 도와줍니다.

Liquibase helps millions of developers track, version, and deploy database schema changes.

Liquibase는 RDB 뿐 아니라 NoSQL을 지원하기 때문에 이를 선택했습니다. 최근 NoSQL에 관심이 많기 때문에요. 다른 선택지로는 Flyway도 있지만 이는 NoSQL을 지원하지 않습니다. 이에 대한 비교글은 많기 때문에 한 번 쯤 읽어보실 것을 권장드립니다.

3. 내가 선택한 전략

다양한 관리 방법이 있겠지만, 저는 개발환경과 배포 버전을 기준으로 스키마를 추적/관리했습니다. 실제 운영되고 있는 환경과 개발중인 환경이 다를 수 있기 때문입니다.

각 개발 환경 db.changelog.xml 생성
각 배포 버전마다 폴더 및 .xml 생성
최종 반영 스키마 파일 생성

프로젝트 디렉토리 구조는 다음과 같습니다.

3-1. 각 개발 환경 db.changelog.xml 생성

먼저 각 개발환경 별 db.changelog.xml을 생성합니다.

db.changelog.xml는 각 개발환경별로 스키마를 추적/관리 합니다. 즉, 각 개발 환경마다 스키마를 추적/관리하며, 이를 통해 한 환경의 스키마가 변경되더라도 다른 환경에 영향을 미치지 않게 됩니다.

  
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
    <include file="/db/changelog/release-1.1.0/release-1.1.0.xml"/>
</databaseChangeLog>

3-2. 각 배포 버전마다 폴더 및 .xml 생성

다음은 각 배포 버전 별 폴더를 생성하고, release-${VERSION}.xml 파일을 만들어 변경된 스키마를 추적/관리합니다.

예를 들어, release-1.0.0 이라면, release-1.0.0.xml 파일을 만들고 변경된 스키마 내용을 포함시킵니다. 이때, .sql파일 또는 .xml 파일 형태로 스키마를 추적/관리할 수 있는데, 이는 본인이 편한 방법을 선택하시면 됩니다.

  
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
    <changeSet id="v1.0.0/datachangelog/table-create" author="jun" context="dev">
        <comment>데이터베이스 스키마 관리 테이블 생성</comment>
        <sqlFile path="databasechangelog.sql" relativeToChangelogFile="true"/>
    </changeSet>
    <changeSet id="v1.0.0/user/table-create" author="jun" context="dev">
        <comment>사용자 테이블 생성</comment>
        <sqlFile path="user-table-create.sql" relativeToChangelogFile="true"/>
    </changeSet>
    <changeSet id="v1.0.0/user/column-add/last-modified-at" author="jun" context="dev">
        <sqlFile path="add-last-modified-at.sql" relativeToChangelogFile="true"/>
    </changeSet>
    <changeSet id="v1.0.0/user/column-delete/last-modified-at" author="jun" context="dev">
        <sqlFile path="delete-last-modified-at.sql" relativeToChangelogFile="true"/>
    </changeSet>
</databaseChangeLog>

3-3. 최종 반영 스키마 파일 생성

마지막으로 최종 반영할 스키마 파일을 생성하고, 배포된 운영 환경에 반영해줍니다.

하나의 통합된 파일을 만든 것은 운영 환경을 자동 설정에 맡기면 문제가 생길 수 있기 때문입니다. 운영 환경에는 가급적 모아둔 파일을 직접 반영시켜주도록 합니다.

4. 주의사항

Liquibase를 사용하면서 몇 가지 주의할점이 생각났는데, 이는 철저히 주관적이므로 하나의 의견으로만 봐주세요.

prod에 스키마를 반영할 때는 신중을 가한다.
Rollback은 신중히 사용한다.
JPA가 생성한 스키마는 추적되지 않는다.

4-1. prod 스키마 적용

운영 환경에 변경된 스키마를 적용할 때는 신중을 가해야 합니다. 변경된 스키마로 인해 잘 동작하던 프로그램이 버그를 일으킬 수 있으니까요. 따라서 Liquibase가 제공하는 자동화 기능은 가급적 개발 환경( dev) 까지만 사용하고, 운영 환경에서는 개발자가 변경사항을 직접 반영하는 것을 권장드립니다.

  
<!--db.changelog-prod.xml는 가급적 사용하지 않는다.-->
<?xml version="1.0" encoding="UTF-8"?>
<databaseChangeLog
        xmlns="http://www.liquibase.org/xml/ns/dbchangelog"
        xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
        xsi:schemaLocation="http://www.liquibase.org/xml/ns/dbchangelog http://www.liquibase.org/xml/ns/dbchangelog/dbchangelog-3.1.xsd">
    <changeSet id="v1.0.0/datachangelog/table-create" author="jun" context="dev">
        <comment>데이터베이스 스키마 관리 테이블 생성</comment>
        <sqlFile path="databasechangelog.sql" relativeToChangelogFile="true"/>
    </changeSet>
</databaseChangeLog>

4-2. Rollback 사용

Rollback 사용은 신중을 가합니다. Liquibase에서는 Tag나 RollbackCount 옵션을 통해 특정 지점으로 스키마를 돌릴 수 있는데요, 이를 사용하면 중간에 어떤 변경 과정이 있었는지 추적하기 힘들어집니다. 즉, 변경 내역을 하나씩 Rollback하면 어떤 변경이 있었는지 과정을 추적할 수 있지만, 한 번에 2~3단계씩 Rollback이 진행되면 중간 과정을 알기 힘들어집니다. 따라서 Rollback을 사용할 땐 항상 주의를 기울입니다.

  
liquibase \
  --classpath=${CONNECTOR} \
  --changeLogFile=${CHANGELOG_FILE} \
  --url=${URL} \
  --username=${USERNAME} \
  --password=${PASSWORD} \
  rollback

4-3. JPA와 Liquibase

JPA가 DDL로 설정해 주는 정보는 추적하지 못합니다. 즉, DDL 설정을 했을 경우, liquibase가 이를 추적하지 못하므로, 이를 JPA Buddy나 다른 툴을 사용해야 합니다. Liquibase를사용하며며신경 써야야 할 부분을정리해 봤는데요요, 아무리 데이터베이스 형성 관리툴을을 사용하더라도 결국에는 개발자가 꼼꼼하게 체크를 해야 합니다. 따라서 변경 사항이 있다면 이를매번번 체크해서실수를 줄이도록도록 합시다.

  
spring:
  
  ......
  
  jpa:
    hibernate:
      ddl-auto: ${DDL}
    properties:
      hibernate:
        generate_statistics: true
        dialect: org.hibernate.dialect.MySQLDialect
        default_batch_fetch_size: 1000
        show_sql: false
        format_sql: false
    open-in-view: false
    show-sql: false

JPA DDL은 가급적 사용하지 않기 때문에 크게 신경쓸 부분은 아니라고 생각합니다.

5. 정리

데이터베이스를 형성 관리하는 것도 중요합니다. 스키마가 추가/변경되었는데 이를 관리하지 않고 배포하면, 운영 서버에 장애가 날 수도 있으니까요. 하지만 여기에 모든 것을 의존해서는 안되는데요, 이 또한 한계가 존재하기 때문입니다다.개발자가 꼼꼼하게 체크하고고, 보조적인 수단으로 이를 활용할 수 있도록 합시다. 😙