Windows Azure Compute의 업그레이드 메커니즘에 대한 이해

Windows Azure Platform에서 Compute 서비스가 차지하는 비중은 매우 큽니다. 그런 만큼, Compute 서비스가 어떤 방식으로 실행되고 동작하는지를 파악하는 것이 필요한데, 이에 대한 이야기를 블로그 글로 써보고자 합니다. 그 중에서도 이번 글은 웹 역할과 작업자 역할에 대한 업그레이드 메커니즘에 대한 이야기를 하고자 합니다.

1. 업그레이드 방법 #1 – VIP 교환 (VIP Swap)

가장 안전하다고 알려진 방법으로, Compute 서비스는 기본적으로 Production와 Staging이 한 벌이 됩니다. 여러분이 신청한 서비스의 실제 도메인 주소와 연결되는 것이 Production 환경이며, Staging 환경은 임의로 생성된 고유 ID 값을 식별자로 사용하는 FQDN 주소를 사용합니다. 만약 기존에 운영 중인 Production 서비스가 이미 있는 상황에서 프로젝트 파일의 구성에 큰 변화가 있을 때, 가령 SDK 버전의 변경, 최소 인스턴스 수 변경, 프로젝트 추가/제거로 인한 구성 변경 등에 해당되는 경우 VIP 교환 방식을 이용하는 것이 필요합니다.

VIP 교환 방식을 사용하면 Windows Azure는 네트워크 위치를 즉시 Production과 Staging을 서로 바꿉니다. 즉, Production에 있는 서비스 전체는 Staging으로 이동하고, Staging에 있는 서비스 전체는 Production으로 이동합니다. 스포츠 경기에서 자주 보는 선수 교체 같은 개념입니다. 🙂

VIP 교체 전/후로는 서비스 자체에 결함이 없는 한, 사용자가 변경되는 시점을 알아차리지는 못합니다. 하지만 완벽하게 Seamless한 서비스 업그레이드를 구현하기 위해서는 세션 상태를 별도의 저장소에 보관하여 이전에 구동중인 서비스에서 가지고 있던 세션을 새로운 서비스에서 이어받아 서비스할 수 있도록 설계하는 것이 필요합니다.

2. 업그레이드 방법 #2 – 패키지 업그레이드

CSPKG 파일과 CSCFG 파일을 Windows Azure SDK나 Visual Studio Tools for Windows Azure를 사용하여 완성하면 이를 Azure Storage나 Management API를 경유하여 직접 업로드하는 방법입니다. 이 방법은 프로젝트에 큰 변화가 없고 소스 코드나 웹 페이지의 일부와 같이 클라우드 응용프로그램의 일부만을 변경할 때에 사용할 수 있는 방법입니다. 효율적인 서비스 관리를 위하여, Windows Azure Storage를 같이 신청하여 비공개 컨테이너를 생성하고 이곳에 여러분의 서비스 패키지를 여러벌을 올려놓고 Management API를 사용하여 필요 시 교체할 수 있습니다.

패키지 업그레이드는 VM을 새로 생성하거나, 실행 중인 VM의 OS를 다시 시작시키지 않으며, Windows Azure Fabric Controller의 지시에 따라 내부적으로 기존에 사용중이던 가상 하드 디스크를 언마운트하고, 새로운 가상 하드 디스크를 생성하여 마운트를 합니다. 이전에 올렸던 Windows Azure의 파일 시스템에 대한 글 [Windows Azure Platform/Compute] – Windows Azure VM의 파일 시스템 구조 를 잠시 인용하면, C에는 Local Storage를 위한 공간으로 할당이 되고, D에는 Windows OS가 설치된 공간이며, E부터 Z까지는 동적으로 마운트하는 가상 하드 디스크들을 위한 공간으로 활용이 된다고 하였습니다. 여기서 보통은 E로 시작하여 업그레이드 때 마다 F나 E 드라이브로 다시 마운트 되며, Windows Azure Drive는 그 이후, 보통은 G 드라이브부터 가상 하드 디스크를 마운트하는 셈입니다.

보통은 패키지 내에서 실행되던 응용프로그램은 업그레이드와 함께 종료되고 다시 시작되지만, 패키지의 권한 밖에서, 관리 목적으로 열어놓은 문서 형식의 파일에 대해 명시적으로 Lock을 걸고 있는 경우 업그레이드가 실패할 가능성도 일부 있어보입니다. 지금 언급하는 방법으로 업그레이드에 실패하는 경우 원격 데스크톱으로 열어놓은 항목을 검토할 필요가 있을 것입니다.

3. 업그레이드 방법 #3 – 완전 삭제 후 다시 배포

이것은 업그레이드 메커니즘이라기보다 재설정이라고 하는 것이 정확합니다. 보통은 이 방법까지 오지 않고 VIP 교환으로 해결할 수 있고 또한 그럴 필요가 있습니다. 안타깝게도, Visual Studio Tools for Windows Azure에서 패키지를 배포하는 방법은 이 방법에 속합니다. 따라서, Visual Studio를 이용하여 배포할 때에는 도구 자체의 기능을 사용하여 Production Deploy를 수행하는 것은 위험하며, VIP 스왑을 위한 전초 단계로만 제한적으로 활용하는 것이 안전합니다.

댓글 남기기