버전이 지정된 서비스 업데이트를 통해 가동 중지 시간 제거

지금까지 관리자는 온-프레미스 소프트웨어를 업데이트하고 업그레이드하기 위해 서버를 오프라인으로 전환해야 했습니다. 그러나 가동 중지 시간은 글로벌 24×7 서비스에 대한 완전한 비스타터입니다. 많은 최신 클라우드 서비스는 사용자가 비즈니스를 실행하는 데 중요한 종속성입니다. 시스템을 중단하기에 좋은 시간이 없으므로 팀이 중요한 보안 및 기능 업데이트를 설치하는 동안 어떻게 지속적인 서비스를 제공할 수 있을까요?

버전이 지정된 업데이트를 사용하면 고객이 적극적으로 업데이트를 사용하는 동안 이러한 중요한 서비스를 한 버전에서 다른 버전으로 원활하게 전환할 수 있습니다. 모든 업데이트가 어려운 것은 아닙니다. 프런트 엔드 레이아웃 또는 스타일을 쉽게 업데이트할 수 있습니다. 기능 변경은 까다로울 수 있지만 마이그레이션 위험을 완화하기 위한 잘 알려진 방법이 있습니다. 그러나 데이터 계층에서 나오는 변경은 특별한 고려가 필요한 새로운 종류의 챌린지를 도입합니다.

레이어를 개별적으로 업데이트

여러 데이터 센터와 별도의 데이터 스토리지에 분산 온라인 서비스를 사용하면 모든 것이 동시에 변경될 수 있는 것은 아닙니다. 일반적인 서비스가 서로 독립적으로 버전 관리되는 애플리케이션 코드 및 데이터베이스로 분할되는 경우 이러한 측면 중 하나는 버전 관리 처리의 복잡성을 흡수해야 합니다.

버전 관리가 애플리케이션 코드에서 더 쉽게 처리되는 경우가 많습니다. 대개 대규모 시스템에는 데이터베이스 내에 있는 SQL과 같은 많은 레거시 코드가 있습니다. 이 SQL을 더 복잡하게 만드는 대신 애플리케이션 코드에서 복잡성을 처리해야 합니다. 특히 SQL 버전 관리 기능을 이해하는 팩터리 클래스 집합을 만들 수 있습니다.

모든 스프린트 동안 각 데이터베이스 버전과 일치하는 코드가 항상 있도록 해당 버전으로 새 인터페이스를 만듭니다. 배포하는 동안 이진 파일을 쉽게 롤백할 수 있습니다. 새 이진 파일을 배포한 후 문제가 발생하면 이전 코드로 되돌리기. 이진 배포가 성공하면 데이터베이스 서비스를 시작합니다.

그렇다면 실제로 어떻게 작동할까요? 예를 들어 팀이 현재 Sprint 123을 배포하고 있다고 가정합니다. 이진 파일은 Sprint 123 데이터베이스 스키마를 이해하고 Sprint 122 스키마를 이해합니다. 일반적인 패턴은 SQL 스키마의 버전/스프린트 N 및 N-1을 모두 사용하는 것입니다. 이진 파일은 데이터베이스를 쿼리하고, 통신하는 스키마 버전을 확인한 다음, 적절한 바인딩을 로드합니다. 그런 다음, 애플리케이션 코드는 새 데이터 스키마를 아직 사용할 수 없는 경우를 처리합니다. 새 버전을 사용할 수 있게 되면 애플리케이션 코드는 최신 데이터베이스 버전에서 사용하도록 설정된 새 기능을 사용하기 시작할 수 있습니다.

데이터 계층에서만 롤 포워드

데이터베이스가 업그레이드되면 문제가 발생하면 서비스가 롤 포워드 상황에 처하게 됩니다. 온라인 데이터베이스 마이그레이션은 복잡하고 종종 다단계이므로 롤 포워드는 일반적으로 문제를 해결하는 가장 좋은 방법입니다. 즉, 업그레이드가 실패하면 롤백도 실패할 수 있습니다. 팀에서 사용하지 않을 롤백 코드를 빌드하고 테스트하기 위한 노력에 투자하는 데는 거의 가치가 없습니다.

배포 시퀀스

데이터베이스에 열 집합을 추가하고 일부 데이터를 변환해야 하는 시나리오를 고려합니다. 이 전환은 사용자에게 보이지 않아야 합니다. 즉, 테이블 잠금을 최대한 방지한 다음 가능한 한 짧은 시간 동안 잠금을 유지하여 인식할 수 없도록 해야 합니다.

가장 먼저 수행하는 작업은 SQL 트리거를 사용하여 데이터를 동기화 상태로 유지하는 병렬 테이블에서 데이터를 조작하는 것입니다. 대용량 데이터 마이그레이션 및 변환은 여러 스프린트에서 여러 배포를 다단계로 수행해야 하는 경우가 있습니다.

추가 데이터 또는 새 스키마가 병렬로 만들어지면 팀은 애플리케이션 코드에 대한 배포 모드로 전환됩니다. 배포 모드에서는 코드가 데이터베이스를 호출할 때 먼저 스키마에 대한 잠금을 잡은 다음 저장 프로시저를 실행한 후 해제합니다. 데이터베이스 호출이 실행된 시간과 저장 프로시저가 실행되는 시점 사이에 데이터베이스는 변경할 수 없습니다.

업그레이드 코드는 스키마 작성기 역할을 하며 스키마에 대한 기록기 잠금을 요청합니다. 애플리케이션 코드는 판독기 잠금을 사용하는 데 우선 순위를 두고 업그레이드 코드는 기록기 잠금을 획득하려고 백그라운드에 있습니다. 기록기 잠금 아래에서는 테이블에서 매우 빠른 작업만 허용됩니다. 그런 다음 잠금이 해제되고 애플리케이션은 새 버전의 데이터베이스가 사용 중임을 기록하고 새 데이터베이스 버전과 일치하는 인터페이스를 사용합니다.

데이터베이스 업그레이드는 모두 마이그레이션 패턴을 사용하여 수행됩니다. 코드 및 스크립트 집합은 데이터베이스 버전을 살펴본 다음 증분 변경하여 스키마를 이전 버전에서 새 버전으로 마이그레이션합니다. 모든 마이그레이션은 릴리스 관리 서비스를 통해 자동화되고 롤아웃됩니다.

웹 UI도 사용자를 방해하지 않고 업데이트해야 합니다. JavaScript 파일, 스타일시트 또는 이미지를 업그레이드하는 경우 클라이언트에서 로드되는 이전 버전과 새 버전을 혼합하지 마세요. 이로 인해 사용자가 편집하는 필드와 같이 진행 중인 작업이 손실될 수 있는 오류가 발생할 수 있습니다. 따라서 배포와 연결된 모든 파일을 별도의 버전이 지정된 폴더에 배치하여 모든 JavaScript, CSS 및 이미지 파일의 버전을 지정해야 합니다. 웹 UI가 애플리케이션 계층을 다시 호출하면 지정된 버전이 있는 자산이 로드됩니다. 사용자 작업으로 인해 전체 페이지 새로 고침이 발생하는 경우에만 새 웹 UI가 브라우저에 로드됩니다. 사용자의 환경은 업그레이드로 인해 중단되지 않습니다.

다음 단계

Microsoft는 수십 년 동안 세계에서 가장 큰 소프트웨어 개발 회사 중 하나입니다. Microsoft가 DevOps를 사용하여 신뢰할 수 있는 시스템을 운영하는 방법을 알아봅니다.