컨테이너 롤아웃 중 데이터베이스 마이그레이션을 앱 시작과 분리하는 방법

스키마 변경을 모든 앱 컨테이너 시작 시점에 실행하는 대신 하나의 명시적인 배포 단계로 처리하면 데이터베이스 마이그레이션 중복 실행을 더 쉽게 방지할 수 있습니다.

예방을 위한 설계는 새 복제본이 트래픽을 처리하기 전에 마이그레이션의 담당자, 인증 정보 세트, 완료 신호를 각각 하나씩 지정하는 것입니다. 웹 및 워커 컨테이너는 스키마 변경 권한을 획득하지 않고도 자유롭게 재시작할 수 있도록 하고, 성공적인 마이그레이션 작업이 완료될 때까지 롤아웃이 대기하도록 하며, 이전 버전과 새 앱 버전이 잠시 함께 실행될 수 있도록 스키마 변경을 설계하세요. 이렇게 하면 모든 복제본이 동일한 마이그레이션 기록을 먼저 확인하기를 막연히 기대하는 대신 경쟁 상태 자체를 제거할 수 있습니다.

일반 앱 시작 과정에서 마이그레이션 명령 제거

이미지 엔트리포인트, Compose 명령, 워커 명령, 상태 확인 래퍼, 배포 스크립트에서 자동 마이그레이션 호출을 확인하세요. 앱은 재시작만으로 스키마를 변경해서는 안 되며, 스키마 변경이 의도적으로 선택된 마이그레이션 단계일 때만 변경할 수 있어야 합니다.

Octopus의 배포 관련 글에서는 마이그레이션에 별도의 수명 주기가 필요하다고 설명하며, 이를 각 마이크로서비스 프로세스 시작 과정에 결합하지 말 것을 권장합니다.

필요한 위치에서 마이그레이션 바이너리를 사용할 수 있도록 유지하되, 웹 엔트리포인트와 두 번째 작업에서 동시에 호출하지 마세요. 프레임워크의 잠금 기능에 의존하는 여러 시작 경로보다 명시적인 담당자 하나를 두는 편이 감사하기 쉽습니다.

배포 전 마이그레이션 작업 하나 실행

릴리스와 동일한 마이그레이션 파일을 사용하는 일회성 작업을 생성하고, 대상 데이터베이스가 예상된 스키마 상태에 도달한 후에만 성공적으로 종료되도록 하세요. 앱 롤아웃이 해당 결과에 의존하도록 구성하세요.

최근 롤아웃 가이드에서는 모든 복제본이 시작 시 경쟁하는 대신 하나의 작업이 롤아웃 전에 실행되는 방식을 소개합니다.

앱 서비스처럼 마이그레이션 작업을 확장하지 마세요. 작업에는 대상 데이터베이스별 실행 담당자 하나, 제한 시간, 로그, 그리고 새 앱 버전을 차단하는 명확한 실패 상태가 있어야 합니다.

마이그레이션 성공 여부에 따라 앱 시작 제어

새 웹 및 워커 컨테이너가 마이그레이션 단계의 성공 보고를 받을 때까지 대기하도록 하되, 대기 중인 각 컨테이너가 마이그레이션을 다시 실행하도록 만들지는 마세요. 의존해야 하는 것은 스키마 변경을 다시 실행하는 것이 아니라 결과입니다.

Andrew Lock의 배포 패턴은 마이그레이션 로직을 중앙화한 상태에서 앱 파드가 마이그레이션을 기다리는 방식을 사용합니다.

소규모 홈 서버 스택에서는 전용 Compose 서비스와 제어된 배포 스크립트로 동일한 원칙을 구현할 수 있습니다. 마이그레이션이 실패하면 롤아웃이 눈에 띄게 중단될 만큼 메커니즘을 단순하게 유지하세요.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

겹치는 실행 기간에는 하위 호환 가능한 스키마 변경 사용

롤링 배포 중에는 이전 버전과 새 앱 버전이 하나의 데이터베이스를 대상으로 일시적으로 함께 실행될 수 있습니다. 이전 버전이 계속 사용하는 필드를 새 버전 배포 직후 삭제하거나 이름을 변경하는 마이그레이션은 피하세요.

최근 무중단 마이그레이션 가이드에서는 파괴적인 정리 작업보다 추가적인 스키마 작업을 먼저 적용할 수 있도록 축소하기 전에 확장하기를 권장합니다.

필요하다면 대규모 변경을 확장, 백필, 전환, 축소 단계로 나누세요. 이전 복제본이 계속 요청을 처리하는 동안 새 컨테이너만 이해할 수 있는 스키마를 마이그레이션 작업이 생성해서는 안 됩니다.

앱 복제본에서 마이그레이션 인증 정보 분리

가능한 경우 스키마 변경 권한이 있는 데이터베이스 계정은 일회성 마이그레이션 단계에서만 사용하세요. 일반 앱 컨테이너에는 앱 데이터에 필요한 더 제한적인 읽기 및 쓰기 권한만 부여해야 합니다.

Liquibase의 배포 관련 글에서는 데이터베이스 변경은 자동화에 포함되어야 한다고 설명하며, 제어되고 반복 가능한 방식으로 변경 사항을 적용할 것을 권장합니다.

이렇게 분리하면 앱 프로세스가 재시작되거나 복제되더라도 실수로 마이그레이션이 실행될 가능성이 줄어듭니다. 권한이 높은 인증 정보는 일반 장기 실행 서비스의 환경 변수가 아니라 배포용 시크릿 경로에 저장하세요.

롤아웃에서 배치가 두 번 적용되지 않는지 확인

폐기 가능한 데이터베이스나 복원한 스냅샷에서 여러 앱 복제본을 시작하고, 복제본을 재시작하며, 배포 명령을 다시 실행해 배포를 테스트하세요. 마이그레이션 단계는 기존 스키마 상태를 보고하되 두 번째로 변경해서는 안 됩니다.

JetBrains는 운영상의 원칙을 일반 앱 시작 전에 배포 단계로 마이그레이션 실행이라고 요약합니다.

앱 재시작으로 스키마를 변경할 수 없고, 마이그레이션 하나가 실패하면 릴리스가 차단되며, 롤아웃을 반복 실행해도 데이터베이스가 변경되지 않을 때 예방 정책이 완성됩니다. 이미 중복 실행이 발생했다면 중복 마이그레이션 진단에 관한 관련 ZimaSpace 문서를 복구 절차로 참고하세요.