chore: flyway 도입

[wibaek]

관련 이슈

• resolves: Flyway 도입 #70

작업 내용

production 디비 변경사항을 관리하고, 마이그레이션을 용이하게 하기 위하여 flyway를 도입하고자 합니다.

flyway 라이브러리를 추가하고, 이번에 추가/수정되어야 할 사항들을 V2__add_gpa_score_and_language_test_score.sql로 추가해두었습니다.

V2 마이그레이션 파일에는 #109 추가 기능을 위한 테이블/필드 뿐만 아니라 기존에 반영이 안되있었던 FK 도 포함되어 있습니다.

참고자료:

https://documentation.red-gate.com/fd/baseline-on-migrate-224919695.html

https://engineerinsight.tistory.com/206

특이 사항

22일 일요일 안으로 마이그레이션 테스트 후 결과 공유하겠습니다.

리뷰 요구사항 (선택)

[wibaek]

테스트 디비에서 마이그레이션 문제 없음 확인했습니다.

[nayonsoso]

궁금한 부분들에 대해 코멘트 남겼습니다😊

추가적으로, 전체 스키마를 생성하는 V1__init.sql과 같은 파일이 없어도 괜찮은 이유가 조금 헷갈리는데요😓
제가 이해하고 있는게 맞는지 확인 부탁드립니다.!

• 지금의 db : 기존 것들이 이미 만들어져있는 상태이므로 필요하지 않음
• 나중에 마이그레이션을 또 한다고 하더라도 : 기존 것을 dump 할 것이므로, 이미 만들어져있는 상태. 따라서 필요하지 않음

---

그리고 flyway 로 DB 형상 관리를 하는만큼,
application-db.yml 의 ddl-auto 설정을 prod 와 dev 모두 validate 로 바꾸는게 좋겠습니다.
Entity와 데이터베이스의 설정이 일치하지 않으면 실행조차 되지 않도록요!

[nayonsoso]

위백님 flyway 에 대해 이런 의견도 있더라고요..
https://www.inflearn.com/community/questions/1300099?focusComment=349706

정리하자면,
"DDL 은 트랜잭션이 적용되지 않으므로, 실패해도 결과가 롤백되지 않는다.
따라서 flyway와 같이 자동으로 스키마가 변경되게 하는 것은 위험하다"
는 의견입니다.

저는 물론 저 의견도 일리가 있지만 개발용 서버/DB 를 둬서 거기에 테스트하면
prod DB에 바로 DML 적용하는 것보다 훨씬 안전하다고 생각합니다.
prod DB에 바로 DML 적용하는게 더 휴먼에러가 있지 않을까요 ... ㅎㅎ
그리고 저 글에서 언급하신 'dev 와 prod의 db 가 다른 상황'도 저희 프로젝트 규모 상 없다고 생각하고요.

여기에 대해 위백님의 의견도 듣고 싶습니다.

[wibaek]

저도 확실히 이해한 것은 아니지만, V1__init.sql가 필요하지 않은 이유에 대해서 말해보자면, baseline-on-migrate: true 설정시 현재 디비가baseline-version(기본값 1)설정 값의 버전으로 지정이 됩니다. 즉 이미 운영중인 디비의 상태를 V1으로 하는 것입니다.

즉 이미 만들어져 있는 상태의 디비를 버전1로 하고, 여기서 쌓아올라가는 방식으로 진행하는 것이니 이해하신게 맞습니다!

추가적으로 초기 DB상태를 형성관리에 추가하기 위해 현재 디비 상태의 DML을 따서 V1파일로 생성해주는 것이 좋을 것 같습니다.
왜냐면 이후 dev 환경에서도 flyway를 사용한다고 할 때 flyway로 디비를 구축해 나가려면 초기 상태의 디비가 지정이 되어 있어야 하는데, 현재 production DB는 초기상태 디비가 이미 있지만 dev 환경에서는 V1 디비는 있지도 않은데 V2 변경사항만 있는 일이 발생하기 떄문입니다.

[wibaek]

위백님 flyway 에 대해 이런 의견도 있더라고요.. https://www.inflearn.com/community/questions/1300099?focusComment=349706

정리하자면, "DDL 은 트랜잭션이 적용되지 않으므로, 실패해도 결과가 롤백되지 않는다. 따라서 flyway와 같이 자동으로 스키마가 변경되게 하는 것은 위험하다" 는 의견입니다.

위 글에서는 Flyway를 사용하지 않고 DDL을 수동으로 실행해야 할 이유로 데이터가 DDL 자체에 문제가 있을경우 데이터가 유실되거나 장애가 발생할 수 있다는 이유를 드는데, 수동으로 마이그레이션을 한다해도 DDL 자체에 문제가 있을 경우에는 동일한 문제가 발생한다고 생각합니다. 수동으로 마이그레이션을 진행한다고 이를 막을 수 있다고 생각이 되지는 않고, 이를 방지하기 위해서는 stage 서버등에서 미리 테스트를 해보는 것이 필요할 것 같습니다.

배포시 DB 마이그레이션 문제 발생시에도 영향을 최소화 하려면 backward compatibility를 유지하면서 스키마를 변경하거나, 무중단 배포를 진행할 때 오류가 발생하면 인스턴스 전환을 취소하는 안정장치를 추가하는게 좋을 것 같습니다.

저는 물론 저 의견도 일리가 있지만 개발용 서버/DB 를 둬서 거기에 테스트하면 prod DB에 바로 DML 적용하는 것보다 훨씬 안전하다고 생각합니다. prod DB에 바로 DML 적용하는게 더 휴먼에러가 있지 않을까요 ... ㅎㅎ 그리고 저 글에서 언급하신 'dev 와 prod의 db 가 다른 상황'도 저희 프로젝트 규모 상 없다고 생각하고요.

여기에 대해 위백님의 의견도 듣고 싶습니다.

말씀하신대로 마이그레이션시 운영 서버에 바로 수동으로 DDL/DML을 적용하는 것보다 개발용 DB에 먼저 테스트를 해보는 것이 오류를 줄이는데 더 도움이 될 것 같습니다. 또한 저희는 성능 문제로 인해서 마이그레이션을 조정해서 실행해야 할 일도 없을 것 같습니다.

[wibaek]

그리고 flyway 로 DB 형상 관리를 하는만큼,
application-db.yml 의 ddl-auto 설정을 prod 와 dev 모두 validate 로 바꾸는게 좋겠습니다.
Entity와 데이터베이스의 설정이 일치하지 않으면 실행조차 되지 않도록요!

좋은 것 같습니다. 다만 배포 컨피그에는 마이그레이션 실패시(배포 실패시) 롤백하는 과정을 cd에 넣은 후에 적용하는 것이 좋을 것 같습니다.

[nayonsoso]

추가적으로 초기 DB상태를 형성관리에 추가하기 위해 현재 디비 상태의 DML을 따서 V1파일로 생성해주는 것이 좋을 것 같습니다.

동의합니다!
그럼 create if not exists 로 V1.1__init.sql를 사용하는 식으로 가면 될 것 같네요.
그런데 flyway 에서는 최신 버전보다 낮은 버전이 추가될 수 없으므로,
이 PR 이 머지되기 전에 V1과 V2사이의 init.sql을 추가해야 안전할 것 같아요🤔

---

다만 배포 컨피그에는 마이그레이션 실패시(배포 실패시) 롤백하는 과정을 cd에 넣은 후에 적용하는 것이 좋을 것 같습니다.

동의합니다🙆🏻‍♀️

[wibaek]

추가적으로 초기 DB상태를 형성관리에 추가하기 위해 현재 디비 상태의 DML을 따서 V1파일로 생성해주는 것이 좋을 것 같습니다.

동의합니다! 그럼 create if not exists 로 V1.1__init.sql를 사용하는 식으로 가면 될 것 같네요. 그런데 flyway 에서는 최신 버전보다 낮은 버전이 추가될 수 없으므로, 이 PR 이 머지되기 전에 V1과 V2사이의 init.sql을 추가해야 안전할 것 같아요🤔

다만 배포 컨피그에는 마이그레이션 실패시(배포 실패시) 롤백하는 과정을 cd에 넣은 후에 적용하는 것이 좋을 것 같습니다.

동의합니다🙆🏻‍♀️

늦어서 죄송합니다.

Flyway에서는 baseline 버전 이하의 버전은 "이미 적용 된 것"으로 간주하고 무시하는 것으로 알고 있습니다.

즉 현재 상황에서 prod에 baseline을 V1로 설정하고(기본값) V2파일을 적용시킨다면, 이후 V1파일이 추가되더라도 baseline 버전 이하의 버전이기에 무시됩니다. 즉 prod에서는 문제가 없습니다.

즉 V1.1을 굳이 추가할 필요 없이, V1__init.sql 파일을 추가하면 될 것 같습니다. V1__init.sql은 production 환경에서는 쓰이지 않고, 이후 dev 환경을 Flyway로 관리할 때를 대비한 파일인 것이죠.

create if not exists로 생성하는 것은 아주 좋은 아이디어 인것 같습니다. 참고해서 화요일까지 ddl 올려놓겠습니다.

[wibaek]

IntelliJ의 Flyway Init Schema Migration 기능을 이용해 V1__init.sql 추가했습니다. 생각보다 Flyway 지원이 잘 되어 있네요. 해당 기능 잘 사용해서 앞으로 마이그레이션에 사용해도 좋을 것 같습니다.

[wibaek]

운영 DB와 동일한 환경으로 디비 띄워 마이그레이션 시도하고 성공하는 것 확인완료했습니다.

위 이미지와 같이 V1__ 존재시에도 baseline 적용시 V1는 무시되는 걸 확인할 수 있습니다.

운영 디비에서 마이그레이션에 FK 문제가 되는 레코드도 수정해두었습니다.

[nayonsoso]

늦게 approve 드려 죄송합니다😭