스키마 마이그레이션
Schema migration소프트웨어 엔지니어링에서 스키마 마이그레이션(데이터베이스 마이그레이션, 데이터베이스 변경 관리)은 관계형 데이터베이스 스키마에 대한 증분, 되돌릴 수 있는 변경사항 및 버전 제어를 관리하는 것을 말한다.스키마 마이그레이션은 데이터베이스의 스키마를 최신 버전 또는 이전 버전으로 업데이트하거나 되돌릴 필요가 있을 때마다 데이터베이스에 대해 수행된다.
마이그레이션은 스키마 마이그레이션 도구를 사용하여 프로그래밍 방식으로 수행된다.지정된 원하는 스키마 버전과 함께 호출될 경우, 도구는 스키마 변경의 적절한 시퀀스 변경의 연속적인 적용 또는 역전을 원하는 상태로 가져올 때까지 자동화한다.
대부분의 스키마 마이그레이션 도구는 데이터베이스의 기존 데이터에 대한 스키마 변경의 영향을 최소화하는 것을 목표로 한다.그럼에도 불구하고, 일반적으로 데이터 보존은 보장되지 않는다. 왜냐하면 데이터베이스 열의 삭제와 같은 스키마 변경은 데이터를 파괴할 수 있기 때문이다(즉, 해당 표의 모든 행에 대해 해당 열에 저장된 모든 값은 삭제된다).대신, 도구는 데이터의 의미를 보존하거나 기존 데이터를 새로운 요구 사항을 충족하도록 재구성하는 데 도움이 된다.데이터 의미를 인코딩할 수 없는 경우가 많기 때문에 도구의 구성은 대개 수동 개입이 필요하다.
위험 및 유익성
스키마 마이그레이션을 통해 요구사항의 변화에 따라 오류를 수정하고 데이터를 조정할 수 있다.특히 민첩한 환경에서 소프트웨어 진화의 필수적인 부분이다(아래 참조).
프로덕션 데이터베이스에 스키마 마이그레이션을 적용하는 것은 항상 위험하다.개발 및 테스트 데이터베이스는 더 작고 깨끗한 경향이 있다.그 안에 있는 데이터는 더 잘 이해되거나, 만약 다른 모든 것이 실패한다면, 사람이 처리할 수 있을 만큼 데이터의 양이 작다.프로덕션 데이터베이스는 대개 거대하고 오래되었으며 놀라움으로 가득 차 있다.이러한 놀라움은 여러 가지 출처에서 발생할 수 있다.
- 이전 버전의 소프트웨어에서 작성되었지만 제대로 치료되지 않은 손상된 데이터
- 더 이상 아무도 모르는 데이터의 잠재된 종속성
- 지정된 도구를 사용하지 않고 데이터베이스를 직접 변경하는 사용자
- 스키마 마이그레이션 도구의 버그
- 데이터 마이그레이션 방법의 오류
이러한 이유로 마이그레이션 프로세스에는 높은 수준의 규율, 철저한 테스트 및 건전한 백업 전략이 필요하다.
스키마 마이그레이션을 완료하는 데 오랜 시간이 걸릴 수 있으며 24x7 연중무휴 운영되는 시스템의 경우 다운타임 없이 데이터베이스 마이그레이션을 수행할 수 있는 것이 중요하다.보통 기능 플래그와 지속적인 전달의 도움을 받아 수행된다.
신속한 변화를 위한 소프트웨어 개발의 스키마 마이그레이션
데이터베이스가 지원하는 소프트웨어 애플리케이션을 개발할 때 개발자들은 일반적으로 진화하는 데이터베이스 스키마와 함께 애플리케이션 소스 코드를 개발한다.코드는 일반적으로 데이터베이스 스키마와 상호 작용해야 할 때마다 데이터베이스 스키마에 어떤 열, 테이블 및 제약조건이 존재하는가에 대한 엄격한 기대를 가지고 있으므로, 코드를 개발한 데이터베이스 스키마의 버전만이 소스 코드의 해당 버전과 완전히 호환되는 것으로 간주된다.
소프트웨어 테스트에서 개발자는 단위 테스트를 위해 호환 가능한 데이터베이스 시스템의 존재를 조롱할 수 있지만, 이보다 높은 수준의 테스트(예: 통합 테스트 또는 시스템 테스트)는 개발자가 소스 코드 버전과 개략적으로 호환되는 로컬 또는 원격 테스트 데이터베이스에 대해 자신의 애플리케이션을 테스트하는 것이 일반적이다.고급 애플리케이션에서 마이그레이션 자체는 마이그레이션 테스트의 대상이 될 수 있다.
스키마 마이그레이션 기술을 통해 데이터 모델은 더 이상 전면적으로 설계할 필요가 없으며, 소프트웨어 개발 라이프사이클 전체에 걸쳐 변화하는 프로젝트 요구사항에 더 잘 적응할 수 있다.
개정 제어 시스템과의 관계
소프트웨어 개발자 팀은 보통 버전 관리 시스템을 사용하여 소스 코드의 변경 사항을 관리하고 협업한다.서로 다른 개발자들은 개발 중에 변경과 추가를 하기 위해 동일한 소스 코드의 서로 다르거나 비교적 오래되거나 새로운 분기에서 개발할 수 있다.
개발 중인 소프트웨어가 데이터베이스와 상호 작용한다고 가정할 때, 소스 코드의 모든 버전은 그것이 호환되는 적어도 하나의 데이터베이스 스키마와 연관될 수 있다.
좋은 소프트웨어 테스트 관행 하에서, 테스트 데이터베이스에서 스키마 마이그레이션을 수행하여 해당 스키마가 소스 코드에 호환되는지 확인할 수 있다.이 프로세스를 능률화하기 위해, 스키마 마이그레이션 도구는 대개 자동화된 테스트 단계의 전제조건으로 자동화된 소프트웨어 빌드의 일부로 호출된다.
스키마 마이그레이션 도구는 버전 제어 시스템이 소스 코드의 버전 관리 문제를 해결하듯이 데이터베이스 스키마의 버전 관리 문제를 해결한다고 말할 수 있다.실제로 많은 스키마 마이그레이션 도구는 스키마 변경의 버전 기록을 VCS 내의 프로그램 소스 코드와 함께 효과적으로 저장할 수 있도록 스키마 변경의 텍스트 표현(예: SQL 문을 포함하는 파일)에 의존한다.이 접근방식은 특정 코드 분기에 대해 호환되는 데이터베이스 스키마를 복구하는 데 필요한 정보를 소스 트리 자체에서 복구할 수 있도록 보장한다.이 접근방식의 또 다른 이점은 동시에 충돌하는 스키마 변경의 처리다. 개발자는 단순히 차이점을 조정하기 위해 일반적인 텍스트 기반 충돌 해결 도구를 사용할 수 있다.
스키마 진화와 관련
스키마 마이그레이션 툴링은 진화하는 스키마의 역사를 추적하는 시설로 볼 수 있다.
이점
개발자들은 새로운 테스트 데이터베이스를 처음부터 새로 만들기 위해 더 이상 전체 테스트 데이터베이스를 제거할 필요가 없다(예: DDL 생성 도구의 스키마 생성 스크립트 사용).또한, 테스트 데이터 생성에 많은 시간이 소요될 경우, 개발자는 스키마에 대한 작고 비파괴적인 변경에 대한 테스트 데이터의 재생을 피할 수 있다.
