Sysnet, Azure를 만나다.
그동안 미루고 미루다... ^^ (Microsoft MVP로 인한) "MSDN 구독자" 혜택을 이용하여 제 개인 블로그를 Azure로 실습삼아 올려 보았습니다. (현재 이 웹 사이트는 Azure에서 호스팅 되고 있습니다.)
MSDN 구독자 Azure 월간 혜택
; https://www.windowsazure.com/ko-kr/pricing/member-offers/msdn-benefits/
Visual Studio Ultimate with MSDN 기준으로 다음과 같은 혜택
클라우드 서비스: 작은 인스턴스 1,500시간
CDN 트랜잭션: 2,000,000
CDN 데이터전송: 35GB 아웃바운드
저장소: 30GB
저장소 트랜잭션: 4,000,000
SQL 데이터베이스(Web Edition): 5GB
액세스 제어 트랜잭션: 500K
서비스 버스 메시지: 1,000,000
서비스 버스 릴레이 시간: 3,000
캐싱: 128MB 캐시
데이터 전송(전 세계): 35GB 아웃바운드, 인바운드 무제한
연간 절감액: 4,320,000원
"클라우드 서비스"에 "Small" 인스턴스로 1,500시간이니, 하루 24시간 * 31일 = 744이므로, 2개 정도의 클라우드 서비스를 무료로 운영하는 것이 가능합니다.
사실, sysnet 웹 사이트가 Hyper-V 가상 머신에 있었기 때문에 Azure의 "Virtual Machine" 서비스를 선택해서 그대로 올리는 것이 가장 편한 방법이긴 한데요. 아쉽게도, MSDN 구독자 혜택에는 VM이 없기 때문에 할 수 없이 ^^ 무료로 호스팅 하기 위해서는 sysnet 사이트를 "Cloud Services" 유형으로 마이그레이션 해야만 했습니다.
Azure의 "VM 서비스"는 IaaS라고 보시면 무난합니다. 즉, 기존 서버 호스팅 업체로부터 "물리적인 머신"을 운영하는 것과 유사하게 "가상 머신"을 할당받는 경우인 반면, "Cloud Services"의 경우에는 PasS로서 "응용 프로그램 플랫폼" 위에서 웹 사이트를 위한 코드만을 올리는 것입니다.
MSDN 구독자가 아닌 경우에는 3개월 무료 구독을 신청하시는 것이 좋을 텐데요. 이 방법은 다음의 글에서 자세하게 설명되고 있습니다.
Windows Azure 한국계정 등록하기(무료 평가판)
; http://taeyo.net/Columns/View.aspx?SEQ=409&PSEQ=33
그리고, 계정을 열었으면 간단한 웹 사이트 먼저 PaaS에 올려보는 테스트를 해보는 것이 좋은데 이에 대해서도 역시 다음의 글에 잘 설명되어 있습니다.
ASP.NET MVC 사이트를 Azure 웹 사이트에 배포하기
; http://taeyo.net/Columns/View.aspx?SEQ=425&PSEQ=33&IDX=1
이번 글은, 제가 sysnet 웹 사이트를 Azure로 올리는 과정을 간단하게 정리한 것입니다.
1. 개발 환경 구성
우선 Azure를 위한 개발자 툴 먼저 설치해야 하는데요. 개별적으로는 다음의 사이트에서 다운로드 받을 수 있습니다.
Windows Azure SDK for .NET - June 2012
; http://www.microsoft.com/en-us/download/details.aspx?id=29988
그런데, 위의 글에서도 나오지만,
Recommended: Install Windows Azure SDK for .NET using the Web Platform Installer x64 or x86. You can automate the installation with the WebPICmd Command-Line Tool using the AppID: WindowsAzureToolsVS2010_1_7 (for Visual Studio 2010 SP1) or WindowsAzureToolsVS2012 (for Visual Studio 2012 RC)
직접 도구를 다운로드 받기 보다는 간단하게 Web PI를 이용하시는 것이 좋습니다.
Web Platform Installer x64
; http://go.microsoft.com/fwlink/?LinkID=254663
Web Platform Installer x86
; http://go.microsoft.com/fwlink/?LinkID=254662
제 경우에는 VS 2010, VS 2012용 2개 모두 설치를 했습니다.
2. SQL DB를 Azure로 마이그레이션
그다음, Azure 관리 도구에서 sysnet 웹 사이트를 위한 "SQL Databases"를 생성해야 합니다.
위에서 설명했지만, 제가 구독한 MSDN은 최대 5GB Web Edition을 무료로 이용할 수 있는데요. 사실 5GB 면 좀 작긴 하지만, 다행히 sysnet용으로는 충분합니다. 거의 텍스트 위주의 컨텐츠만 보유하고 있기 때문에 오늘 기준으로 MDF 파일 사이즈가 27 MB에 불과하거든요. ^^
자... 이제 DB를 준비했으니, 기존 DB를 azure로 마이그레이션 해야 하는데요. 이에 대해서는 내용이 조금 길어져서 별도로 정리해 두었습니다.
sysnet DB를 SQL Azure 데이터베이스로 마이그레이션
; https://www.sysnet.pe.kr/2/0/1303
이렇게 DB가 올라갔으면, 일단 현재 운영중인 웹 사이트의 연결 문자열을 Azure에 배포된 DB로 바꿔도 정상 동작해야 합니다. 연결 문자열은 Azure 관리 홈페이지에서 아래와 같이 "Show connection strings" 링크를 누르면 ADO.NET, ODBC, PHP, JDBC용의 연결 문자열을 구할 수 있습니다.
물론, 외부에서 Azure로 연결하려면 방화벽 설정에 웹 애플리케이션이 운영되는 서버의 IP 주소가 등록되어야 합니다. 하지만, 저는 웹 애플리케이션도 Azure Cloud Services에 올릴 것이기 때문에 연결 문자열만 바꿔주고 IP 주소 등록은 하지 않았습니다.
3. 첨부 파일데이터를 Azure Storage에 마이그레이션
DB와 함께 기존 "파일 데이터"에 대한 마이그레이션을 빼놓을 수 없습니다. 이것 역시 내용이 다소 길어서 별도의 글로 정리했는데요.
sysnet 첨부 파일을 Azure Storage에 마이그레이션
; https://www.sysnet.pe.kr/2/0/1304
제가 가진 MSDN 구독 서비스로 총 30GB가 허용되는데, 다행히 sysnet에 그동안 누적된 첨부 파일들은 1GB가 채 넘지 않았습니다.
DB 마이그레이션 단계에서는 단순히 웹 응용 프로그램에서 '연결 문자열'만 변경해 주면 되었지만, 첨부 파일의 경우에는 Azure Storage에 대한 접근을 위해 첨부 파일을 업/다운로드하는 부분의 코드를 변경해 주어야 하므로 담당 개발자가 필요할 수 있습니다. 또한, 나중에 다시 On-premise 서버로 내려야 할 때를 대비해서 무작정 코드 변경을 하기 보다는 적절한 if 조건으로 처리하는 것이 좋을 것입니다. (물론, sysnet은 여차하면 다시 ^^ 집에 있는 서버로 내려오는 것이 가능하게 만들었습니다.)
4. 웹 애플리케이션 배포
DB와 파일 데이터를 마이그레이션 했으니, 이제 마지막으로 "웹 응용 프로그램"을 Azure의 클라우드 서비스로 올릴 차례입니다.
"
ASP.NET MVC 사이트를 Azure 웹 사이트에 배포하기" 글에서는 Azure의 "Web Sites"라는 기능을 이용한 예인데, 제 경우에는 "Cloud Services"로 배포하는 것이 목적이라서 설정 과정이 다소 다릅니다.
우선, 웹 사이트를 "Cloud Services"에 배포하기 위해서는 다음과 같이 "Cloud Services" 영역과 "Storage" 영역에 각각 한 개씩의 서비스를 만들어 두어야 합니다. (Storage 영역은 이전 단계에서 첨부 파일을 마이그레이션했다면 그 서비스를 함께 공유하셔도 됩니다.)
그다음, 여러분들이 만든 웹 사이트를 Azure 배포 프로젝트에 추가해 주어야 하는데, 이를 위해 Visual Studio에서 해당 웹 사이트를 오른쪽 버튼으로 눌러서 나오는 메뉴의 "Add Windows Azure Cloud Service Project"를 선택합니다.
그러고 나면, 웹 사이트 프로젝트에 Microsoft.WindowsAzure.Configuration, Microsoft.WindowsAzure.Diagnostics, Microsoft.WindowsAzure.ServiceRuntime, Microsoft.WindowsAzure.StorageClient 어셈블리들이 추가되고, "[웹 프로젝트].Azure"라는 이름의 Azure 프로젝트가 하나 생성됩니다.
새롭게 추가된 Azure 프로젝트를 다시 오른쪽 마우스 버튼으로 눌러서 "Package..." 메뉴을 누르면, 다음과 같은 창이 뜹니다.
위의 대화창에서 "Pakcage" 버튼을 눌러주면 "Cloud Services"에 올라갈 수 있는 패키지 파일들이 생성되고, 완료되면 탐색기가 뜨면서 "*.cscfg" 파일과 "*.cspkg" 파일이 생성된 폴더가 보여집니다. ([Azure 프로젝트]\bin\[빌드유형]\app.publish" 폴더)
이후, 패키징된 cscfg/cspkg 파일을 Azure에 배포를 해주어야 하는데요. 역시 "[웹 프로젝트].Azure" 프로젝트를 오른쪽 버튼으로 눌러서 "Publish..." 메뉴를 누르면 다음과 같은 배포 마법사가 활성화 됩니다.
위에서 "Sign in to download credentials" 링크를 눌러주면 "
ASP.NET MVC 사이트를 Azure 웹 사이트에 배포하기" 글에서 나왔던 것처럼 "*.publishsettings" 파일을 다운로드 할 수 있습니다. 그 파일을 그대로 "Import..." 버튼으로 선택해서 "Choose your subscription"으로 가져오기를 합니다.
계속 진행하면 다음과 같은 화면이 뜨는데요.
별달리 특별한 의도가 없으면 그냥 기본값으로 두고 "Publish" 버튼을 눌러주면 배포가 진행되는데, cspkg 파일의 크기와 네트워크 속도에 따라 배포 시간이 다소 걸릴 수 있습니다. 완료되고 나면 Visual Studio의 "Windows Azure Activity Log"에 다음과 같이 정상적으로 배포되었다는 내용을 볼 수 있습니다.
일단 이렇게 한번 배포에 성공한 다음부터는, 이후의 웹 애플리케이션의 변경 사항에 대해 단지 "Publish" 단계만 진행해 주면 됩니다. ("Publish"에는 웹 애플리케이션의 빌드 및 패키지 작업이 모두 포함되어 있습니다.)
그럼, 이제 서비스가 제대로 동작하는 지 확인을 해야 할 텐데요. Azure는 클라우드 서비스에 대해 외부에서 방문할 수 있는 도메인 이름을 기본적으로 제공해주고 있는데, sysnet의 경우에는 sysnet.cloudapp.net으로 할당받은 상태입니다. 물론, 웹 사이트 운영자가 "cloudapp.net"의 도메인을 좋아할리 만무합니다. sysnet이 그동안 www.sysnet.pe.kr로 외부에 알려졌던 것처럼, 각자 자신이 구매한 도메인 이름을 사용하고 싶을 텐데요. 이를 위해서는 여러분이 구매한 도메인 이름을 관리해 주고 있는 업체 측의 도움이 필요합니다. 이 내용 역시 별도의 글로 정리했으니 참고하세요. ^^
Azure 웹 사이트에 사용자 도메인 네임 연결하는 방법
; https://www.sysnet.pe.kr/2/0/1302
5. 가장 중요한, Troubleshooting
이상적인 경우, 마이그레이션을 하면 당연히 웹 사이트가 정상적으로 동작해야 겠지만, 현실은 그렇지 않은 경우가 많습니다. ^^ 오류가 발생해서 ASP.NET의 전형적인 예외 화면이 나온다면 어떤 것이 문제인지 찾아내기가 막막할 수밖에 없는데요. 재미있게도, Azure는 해당 웹 사이트가 배포된 가상 머신으로의 "RDP 연결"을 제공해 주어서 마치 자신이 운영하는 서버에서처럼 원인 파악을 할 수 있는 수단을 제공해 줍니다.
Enable Remote Desktop Connection for a Role in Azure Cloud Services (classic)
; https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-role-enable-remote-desktop-new-portal
Enable Remote Desktop Connection for a Role in Azure Cloud Services (classic) using Visual Studio
; https://docs.microsoft.com/en-us/azure/cloud-services/cloud-services-role-enable-remote-desktop-visual-studio
연결 방법은, "[웹 프로젝트].Azure" 프로젝트를 오른쪽 버튼으로 눌러서 "Configure Remote Desktop..." 메뉴를 선택하면 다음과 같은 창이 뜨는데,
인증서는 원하면 다른 것으로 선택해도 되지만, 제 경우는 그냥 "Automatic"으로 두고, "User name"과 "Password"는 임의의 문자열로 지정해 주었습니다. (해당 계정이 VM에 생성됩니다.)
위의 설정 사항은 cscfg 파일에 저장되므로, 다시 웹 사이트를 배포해 주어야만 RDP 연결이 가능해집니다. RDP 연결에 대한 설정을 포함한 배포를 완료했으면 이제 "Visual Studio"의 "Server Explorer" 창을 열고 다음과 같이 배포된 노드를 따라 가서 "Connect using Remote Desktop..." 메뉴를 선택해 주면 됩니다. (이후의 RDP 연결은 기존 mstsc.exe와 동일합니다.)
어떠세요? 생각했던 것보다 Azure 호스팅이 그다지 어렵지는 않습니다. 물론, 위의 예제는 지극히 소규모의 개인 웹 사이트를 마이그레이션 한 것에 불과할 뿐, 대상 응용 프로그램의 규모에 따라 얼마든지 더욱 복잡한 구성이 따라올 수 있음은 감안해야 합니다.
마이그레이션을 진행하면서... 다음 글이 생각나더군요.
넥슨아메리카 “클라우드 안 쓸 이유 없다”
; http://www.bloter.net/archives/114271
그리고, 새삼스럽게 느끼는 것이지만 진정한 클라우드 서비스라면 PaaS입니다. 운영체제/DB 라이선스 및 기타 호스팅 환경 고민할 필요 없이 오로지 '개발 코드' 자체에만 집중할 수 있기 때문입니다.
비록, 마이크로소프트도
아마존의 EC2에 대응되는 서비스가 필요해서 "Virtual Machine 서비스"를 내놓기는 했지만... Azure를 처음 시작했던 당시의 "클라우드 서비스" 유형이 기술적으로는 정확한 선택이었음을 깨닫게 됩니다. (재미있게도 ^^ 현실 속에서는 '클라우드 서비스'를 단지 '가상 PC'를 저렴하게 많이 할당받아서 쓰는 것으로 더욱 인기를 끌고 있지만!)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]