ASP.NET을 이용한 이식성 높은 클라우드 서비스 개발하기

요즈음은 Infrastructure as a Service를 이용하여 VM의 Mobility를 통한 클라우드 서비스 사업자 간 이동 및 이전이 요즈음 주목 받고 있습니다. 익히 잘 알려진대로, Windows Azure의 경우 사설 혹은 기업 데이터센터 구축을 위하여 사용하는 Hyper-V 환경의 가상 PC를 Windows Azure로 진출시키거나 역으로 가져오는 등의 기능은 상당히 잘 알려져 있어서 많이들 이용하고 계실 것 같습니다.


그런데 Platform as a Service는 이런 부분에서 확실한 이동성을 보장하기 많이 어렵다는 것이 문제가 됩니다. 특히 비즈니스 로직을 내부에 많이 포함하고 있는 클라우드 응용프로그램일 수록 해당 클라우드 서비스에 종속적이기 때문에 클라우드 사업자간 이동이 훨씬 더 어렵습니다. 물론, 이를 극복하기 위하여 Dependency Injection이나 Inversion of Control을 이용하여 클라우드 사업자들이 제공하는 SDK의 공통 분모를 추출하여 그 대상으로 삼는 것도 가능한 전략이기는 하겠습니다만 사실 쉽지 않습니다.


좀 더 현실적이고 직관적인 방법이 없을까 많이들 고민하시는 데에 어느정도 도움이 될까 하여 한 가지 방안을 제시해 보겠습니다. 바로 ASP.NET과 Web Deploy를 이용한 개발입니다.


왜 ASP.NET과 Web Deploy를 사용하는가 – ASP.NET을 사용할 수 있는 환경의 다양성


PHP, Node.js, Ruby on Rails 등 웹 세계에서 유명한 프레임워크나 개발 환경이 많이 있습니다만 상대적으로 ASP.NET은 늘 저평가되어있습니다. 특히 ASP.NET을 버전 1.0~2.0 시절의 Web Form과 연결하여 선입견을 가지는 경우가 무척 많습니다. 그렇지만 이전부터 필자가 계속 강조해왔던 NuGet, Web Developer Express 등 다양한 OSS에 친화적인 기술들과의 결합과 ASP.NET MVC의 등장은 이 선입견에 묻혀서 거의 알려지지 않은 경우가 많습니다. (특히 국내에서는 더욱 그렇지요.)


그러나 이런 와중에 생각보다 ASP.NET의 입지는 넓습니다. Microsoft 기술과 가장 친화적이지 않을 것 같은 Amazon의 BeansTalk가 ASP.NET Web Deploy 패키지를 사용한 PaaS 배포 기법을 전면에서 지원하고 있으며, 사용 중인 환경이 Linux인 경우 다양한 방법으로 Mono ASP.NET 런타임과 결합하여 ASP.NET 웹 사이트를 호스팅할 수 있습니다. 그리고 Windows Azure는 Web Site와 Cloud Service를 이용하여 각각 웹 사이트를 호스팅할 수 있는 방법을 제공합니다. 멀리 가지 않아도 시중에 나와있는 웹 호스팅 서비스는 모두 FTP를 통한 ASP.NET 웹 사이트 배포까지 지원합니다. 수단은 얼마든지 많고, 남는 것은 전략의 수립에 관한 부분만이 남는 셈입니다.


왜 ASP.NET과 Web Deploy를 사용하는가 – 단일 코드 베이스 유지


ASP.NET을 이용하여 독립적으로 실행할 수 있는 Web Application Project를 만들어두면, Public Cloud만을 이용해서 서비스를 구축하였을 때 간간히 문제가 발생하는 특정 데이터센터, 혹은 특정 클라우드 서비스의 장애로 인해서 전체 서비스가 중단되는 사고로부터 좀 더 자유로워질 수 있습니다.


여러 위치에 분산된 응용프로그램을 배포하는 것은 기본적으로 매우 어려운 작업입니다. 그리고 이 어려운 작업의 난해함을 지수승으로 더 복잡하게 만드는 것은 바로 클라우드 서비스 사업자 간의 고유한 기능 집합 때문입니다. 이 문제를 해결하기 위해서는 사업자 간 이해 관계가 비교적 덜 연결되어있으면서도 구성의 차이가 거의 없는 기술을 택하는 것이 바람직한데, 여기에 들 수 있는 후보로는 ASP.NET을 포함하여 다수의 기술들이 있습니다. 그 중에서도 오늘 소개하려는 ASP.NET은 수준 높은 IDE 지원과 다양한 OSS 프로젝트와의 연계가 가능하기 때문에 유용한 점이 많습니다.


왜 ASP.NET과 Web Deploy를 사용하는가 – 배포 시의 문제점을 최소화


기능 상의 유용함 이외에도, 스스로 스케줄링을 해야 하는 Daemon Type의 서비스 프로세스가 아닌 RPC나 REST 형태의 시스템일 경우 ASP.NET을 사용하여 프로그래밍하고 Visual Studio의 지원을 받을 때의 큰 이점이 하나 더 있습니다. 바로 배포 시의 문제점을 최소화할 수 있다는 것입니다.


ASP.NET Web Deploy 및 관련 프로세스들은 패키지로 만들 때, 종속성에 관련된 모든 문제를 예방할 수 있도록, 웹 프로젝트와 연관성이 있는 모든 종속성 관계 상의 파일을 자동으로 복사하여 패키지에 포함시키는 정책을 사용합니다. 이러한 특징 때문에, ASP.NET MVC나 Razor의 최신 버전이 처음 .NET Framework가 배포된 이후에 바뀌더라도 최신 기능을 사용하면서도 배포 상의 DLL 버전 차로 인한 문제가 발생할 가능성이 높지 않습니다.


클라우드 서비스 별 배포 방법 – Amazon BeansTalk


우선 Amazon BeansTalk의 경우를 예로 들어보도록 하겠습니다. Amazon BeansTalk는 Visual Studio에 추가 기능으로 설치할 수 있는 Toolkit을 통한 배포/모니터링과 Management Console (Web)를 통한 패키지 파일 업로드 방식의 배포를 모두 지원합니다.


웹 프로젝트를 만들고, 아래 화면과 같이 배포 프로필을 Web Deploy 패키지로 만드는 것으로 설정한 다음, 지정된 위치에 패키지 파일을 만들도록 합니다. 패키지 파일은 ZIP 파일입니다.



만들어진 파일을 AWS Management Console로 이동하여 다음과 같이 업로드를 시작합니다.



업로드 완료 후 배포 프로세스가 시작되면 다음과 같이 진행 상황이 표시됩니다.



잠시 기다리면 다음과 같이 정상 배포가 완료되었음을 알리는 화면이 표시됩니다.



그리고 로드 밸런서 앞으로 부여된 FQDN 앞으로 접속하면 다음과 같이 로컬 개발 환경에서 개발할 때와 비슷한 응용프로그램이 실제 클라우드 서비스에서 실행 중인 것을 볼 수 있습니다.



BeansTalk의 멤버 노드로 참여하는 VM 인스턴스들이 있다면 여느 PaaS 플랫폼들과 마찬가지로 모든 배포를 자동화하여 처리하므로 배포 프로세스의 상당 부분을 쉽게 완료할 수 있습니다.


클라우드 서비스 별 배포 방법 – Azure Web Site


이번에는 Azure Web Site를 위한 배포 방법을 살펴보도록 하겠습니다. Visual Studio에서 앞의 경우와 마찬가지로 웹 게시 대화 상자를 띄운 다음, 가져오기 버튼을 클릭합니다.


 



처음 이 기능을 실행하면 배포 프로필을 한 번도 사용한 적이 없으므로 아래와 같이 빈 목록이 나타나게 됩니다. Windows Azure 구독 추가 링크 (드롭 다운 상자 아래)를 클릭합니다.


 



Windows Azure 구독 가져오기 대화 상자가 나타나면 구독 파일 다운로드 링크를 클릭합니다.


 



로그인 페이지에서 로그인을 완료하면 로그인한 Microsoft ID와 연결된 모든 Windows Azure Web Site 프로필 정보를 취합한 통합 프로필 파일의 다운로드를 시작하게 됩니다.


 



앞의 대화 상자로 되돌아와서, publishsettings 파일을 다시 지정하고, 가져오기 버튼을 클릭합니다. 잠시 기다리면 지정한 Live ID로 만든 여러 가입 상의 여러 Azure Web Site에 대한 정보가 한번에 나타납니다. 관리자 권한만을 가지고 있었다고 할지라도 여기에 한번에 나타나므로 손쉽게 배포를 진행할 수 있고, 이 과정 이후에 따로 웹 사이트를 새로 만들더라도 다시 이 대화 상자만 띄우면 목록이 새로 업데이트됩니다.


 



이와 같이 설정을 마무리하고 연결에 이상이 없는지 유효성 검사 버튼을 클릭하여 녹색 체크 마크가 나타나면 배포를 위한 연결이 성립된 것으로, 계속 진행해도 좋습니다.


 



클라우드 서비스 별 배포 방법 – Azure Cloud Service / Web Role


기존에 만들어진 ASP.NET 웹 사이트 프로젝트를 Web Role로 변환하여 내보내는 작업은 생각보다 어렵지 않습니다. 기술적인 고려 사항을 제외하면, Web Role용 프로젝트는 Beans Talk의 경우와 마찬가지로 Azure Cloud Service만을 위해서 무언가 꼭 추가해야 하거나 심각하게 변경해야 할 것이 전혀 없습니다.


Windows Azure Tools 최신 버전을 설치한 다음, 클라우드 서비스 프로젝트를 생성할 때 아래와 같이 아무것도 추가하지 않은 상태로 확인 버튼을 클릭합니다. 기존 프로젝트를 가져오기 위해서입니다.


 



그러면 멤버 역할이 없는 상태의 빈 클라우드 서비스 프로젝트가 만들어지게 됩니다. 이제 솔루션 탐색기의 역할 폴더를 오른쪽 버튼으로 클릭하고 아래 그림과 같은 순서로 팝업 메뉴를 접근합니다.


 



그러면 아직 지금 클라우드 서비스와 연결된 적이 없는 프로젝트의 목록이 나타나게 됩니다. 항목을 선택하여 클라우드 서비스 프로젝트로 가져옵니다.


 



정상적으로 가져오게 되면 다음과 같이 솔루션 탐색기의 클라우드 서비스 프로젝트 아래의 역할 폴더에 프로젝트 이름이 나타나면서 클라우드 서비스의 웹 역할로 등록됩니다.


 



이제 Azure Cloud Service로 배포하기 위하여 패키지를 만들 차례입니다. 패키지를 만들어서 Azure Management Portal을 이용하여 업로드를 해도 좋고, 사전에 인증서 및 계정 연동을 미리 구성하여 Visual Studio에서 진행해도 상관 없습니다. 여기서는 패키지 만들기 기능으로 배포를 해보겠습니다. 클라우드 서비스 프로젝트를 오른쪽 버튼으로 클릭한 다음 패키지 메뉴를 클릭합니다.


 



그러면 배포 대화 상자가 나타나게 됩니다. 각각의 드롭 다운 상자의 의미는 어렵지 않습니다. 서비스 구성이란 클라우드 서비스의 구성을 의미하는 것이고, 빌드 구성은 각 역할과 연결된 C#이나 VB.NET 프로젝트들의 빌드 구성을 의미하는 것으로 양쪽은 서로 독립적인 관계이므로 적절한 옵션을 선택합니다. 설정을 확인한 다음 패키지 버튼을 클릭합니다.


 


빌드 상의 오류가 없으면 탐색기 창이 열리면서 .CSCFG 파일과 .CSPKG 파일이 표시됩니다. 이 파일을 다루기 쉬운 위치로 이동시켜 Windows Azure Management Portal에서 클라우드 서비스를 만든 다음 게시합니다.


 



 

고려할 사항들


전통적인 웹 응용프로그램들과는 달리 클라우드 서비스들은 단일 인스턴스에서 실행하는 것 보다는 로드 밸런싱을 전제로 여러 인스턴스에서 실행하는 것을 기준으로 생각합니다. 그렇기 때문에, 전통적인 웹 기반 응용프로그램을 그대로 전환하는 것은 생각보다 쉽지 않습니다. 특히, 컴퓨터 자체적으로 업로드한 파일을 보관하거나, 서버 컴퓨터의 상태에 의존적인 웹 응용프로그램은 클라우드 기반의 서비스로 이동하기 전에 적절한 보완이 반드시 필요합니다.


그리고 여러 위치에 클라우드 서비스를 배포하고 관리하기 위해서는 자동화된 빌드, 배포, 모니터링 도구가 필요합니다. 각각의 개별 클라우드 서비스들이 제공하는 REST API를 이용하는 도구를 직접 만들 수도 있지만, 재미있는 것은 대다수의 클라우드 서비스 공급자들이 Windows에서는 PowerShell에 대응하는 모듈을 개발하여 배포하고 있다는 것이고, Unix나 Linux에서는 node.js의 클라이언트 기반 런타임을 개발하여 배포하는 일이 많다는 점입니다.


이러한 특징들을 이용하여, 여러 클라우드 서비스를 손쉽게 관리할 수 있는 노하우를 개발하여 여러분의 개발 및 운영 프로세스에 자연스럽게 통합시킬 수 있을 것으로 기대합니다.

댓글 남기기