웹 개발 해야지, 하고 마음먹으신 후 해야할 일들을 나열해 볼까요?
PC에 윈도우는 깔려있다고 가정해보죠. IIS 웹서버, DBMS, .NET Framework, 개발툴 등을 별도의 사이트를 찾아다니면서 다운로드 받아서 설치하셔야 하는데, 쉽게 말해 번거롭죠. 시간도 많이 걸리고.
결국 microsoft.com, download 사이트, codeplex.com 등 여기 저기 찾으셨어야 하죠.
마이크로소프트 웹 플랫폼 설치기 2.0 하나면 이런 고민이 다 해결됩니다.
Web Platform Installer 2.0
http://www.microsoft.com/web/downloads/platform.aspx
이런 웹 플랫폼 위에서 구동되는 다양한 애플리케이션들을 사용하실 수 있습니다.
http://www.microsoft.com/web/gallery/Categories.aspx
바로 위의 링크를 클릭하시면 찾아 보실 수 있죠.
제로보드, TextCube 등 우리나라에서 인기있는 애플리케이션은 어디 있냐고요?
http://www.windowslovephp.co.kr 에 가시면 매뉴얼을 확인하실 수 있습니다.
PHP on Windows, ASP, ASP.NET on Windows가 이제는 모두 가능하게 된거죠.
REST 아키텍처 스타일에 대해서는 앞의 글에서도 소개했었는데, 오늘은 WCF 서비스를 활용한 방법에 대해 이야기하려고 합니다. REST(Representational State Transfer)에 대해서는 많은 분들이 도대체 뭐야? 라는 반응을 보이십니다.
하지만, 앞으로 정말 많이, 여러번 듣게 되실 개념이기 때문에 꼭 이해가 필요합니다.
WOA(Web Oriented Architecture)가 결국은 RESTful 아키텍처를 의미합니다.
REST란?
아키텍처 스타일이란 말은 어떤 무엇인가를 구축할 때 적용되는 규약들의 집합이라고 이야기할 수 있습니다. 즉, 소프트웨어 시스템을 구현할 때 사용되는 가이드 정도로 이해하면 되겠습니다.
클라이언트가 서비스(Endpoint)를 요청할 때 사용되는 클라이언트 – 서버 아키텍처 스타일 중의 하나입니다.
HTTP 스펙을 만든 사람 중의 한 명인 Roy Fielding 교수가 박사학위 논문에서 사용한 개념 입니다.
Architectural Styles and the Design of Network-based Software Architectures
Web이 바로 REST 아키텍처 스타일을 그대로 따르고 있는 시스템 입니다. 원칙을 한 번 살펴보도록 하죠.
하나의 간단한 예제로 이해를 해보도록 하죠.
MSDN 매거진의 데이터을 처리하는 서비스를 만든다고 가정해보죠.
- 해당 서비스는 지금까지 발행된 모든 MSDN 매거진에 대한 정보를 알려줍니다.
매거진의 편집자가 이 서비스를 쓸 것이고 새로 발행되는 매거진에 대한 정보를 추가하고, 관리하는 등의 작업을 할
예정 입니다.
RESTful 서비스를 구축할 때 서비스 디자인 단계를 살펴보죠
RESTful endpoint를 만드는 기본적인 블럭들입니다. 자원, 그리고 표현 방법
자원: MSDN 잡지가 출간된 모든 년도, 매년 발행된 이슈, 매거진에 게재된 기사
해당 자원을 표현하기 위해 XML을 사용하기로 하죠, 하지만 RESTful서비스는 XML에 한정된 것은 아니고 여러 유형으로 표현 가능합니다.
이제 URI를 결정해보죠. 절대경로는 이 endpoint를 어떤 호스트에 배치할 것인지에 달라지기 때문에, 여기서는 상대경로로 표현하도록 하겠습니다.
모든 년도들의 리스트, 즉 서비스의 루트 URI로 / 를 사용합니다.
이 구문을 활용하면, /{year} 는 해당 년도에 발행된 모든 잡지들에 대한 정보를 리턴합니다.
/{year}/{issue}는 해당 년도에 발행된 특정한 이슈에 대한 값을 리턴하겠죠.
/{year}/{issue}/{article}은 해당 이슈의 기사에 대한 정보값을 리턴하는데, 각 기사는 1 .. n까지 번호가 매겨졌다고 가정하죠
자, 이제 해당 URI를 단일인터페이스 (HTTP 동사)와 연결해보죠. 해당 잡지의 히스토리는 읽기 전용이어야 하므로, 해당 root 자원은 GET 동사만 사용되어야 합니다. 새로운 년도는 추가될 수 있으므로 PUT을 통해 /{year}가 추가되고, PUT을 통해 수정도 이루어질 수 있습니다. POST 연산을 통해서는 해당 자원을 신규로 생성할 때 사용되는데 해당 이슈를 만드는, /{year}/{issue} 등으로 사용합니다.
예를들어, 2006년 1월 이슈의 모든 기사를 원한다면 HTTP GET /2006/January 라고 가져올 수 있을 것이고 2009년 3월 이슈를 만들려면 POST /2008/december라고 쓸 수 있다는 것이죠.
그렇다면 왜 REST에 대해 이야기를 할까요?
서비스를 사용하는 방법이 REST 밖에 없을까요? 그렇지 않습니다.
클라이언트 서버 스타링의 애플리케이션을 구현하는데 있어서 다른 아키텍처 스타일을 사용할 수 있습니다. .NET의 특화된 RPC(Remote Procedure Call), 즉 DCOM 및 .NET 리모팅 등을 사용하거나 상호운용성이 제공되는 ASMX를 사용하는 SOAP, WCF 등의 RPC 기술을 사용할 수 있었죠.
그런데, REST를 사용하면 첫째, 훨씬 간편하고 쉽게 서비스를 구현할 수 있고 둘째, 마이크로소프트가 RPC 기술(SOAP 포함)에 비해 REST 아키텍처 스타일을 훨씬 더 선호하고 있기 때문인데, 그 이유가 있다는 거죠. 마이크로소프트의 클라우드 컴퓨팅, 애저 서비스 플랫폼과 윈도 애저에서도 REST 스타일을 채택하고 있습니다.
장점
Caching HTTP 동사를 통해 RESTfu endpoint가 불리워 질 때, HTTP 동사 GET을 사용합니다. GET으로 불리워진 자원들은 여러 다양한 방법으로 캐싱이 가능합니다. 결국 속도와 확장성이 향상됩니다.
Scale-Out REST는 각 자원이 특정 요청에 필요한 모든 상태 값을 다 가지고 있기 때문에, 즉 stateless기 때문에 확장이 훨씬 용이합니다.
Idempotent GET을 이용해 자원을 요청할 때 추가적인 부작용이 벌어지지 않습니다 (즉, 다시 한 번 GET, DELETE 등을 불러도 두번 중복작업이 이루어지지 않음)
Interoperability SOAP이 클라이언트 서버 프로그램을 통해 상호운용성이 뛰어나다고 하지만, 몇 몇 언어 및 환경은 여전히 SOAP 툴킷을 갖고 있지 못하고, 툴킷을 가지고 있는 언어의 경우에도 최신 표중르 가진 다른 툴킷과 통신할 수 없는 경우가 종종 발생합니다. REST는 HTTP 동사만을 사용하기 때문에 어떤 언어, 플랫폼과도 상호운용이 가능합니다.
가능한 경우에 REST를 많이 사용하시기 바라고, 엔터프라이즈에서도 고려하고 있는 중입니다.
WCF and REST
WCF는 스타일, 프로토콜에 무관하게 통신이 가능한 분산 컴퓨팅 환경의 애플리케이션을 구축하는데 사용되는 마이크로소프트의 프레임웍 입니다. WCF 개념은 개발자가 한 프로그래밍 언어를 통해 다른 많은 분산 시스템을 사용 가능하도록 돕는 기술 입니다.
이전 버전의 WCF는 RPC(SOAP 등)를 이용하도록 사용되었는데, .NET Framwork 3.0부터는 REST 서비스를 사용할 수 있도록 지원하고 있었는데 REST 기반 서비스 프로그래밍이 가능한 모델 및 인프라 지원이 부족했는데, .NET Framwork 3.5 SP1에 프로그래밍 모델 및 기타 많은 부분이 개선되었습니다. 저도 조금 살펴봤는데 잘 만들어졌습니다.
프로그래밍 모델 중 두가지 속성, WebGetAttribute 과 WebInvokeAttribute, URI template 메커니즘이 주목할 만합니다.
URI, 메쏘드에 적용될 동사를 정의할 수 있도록 해주는 거죠. 인프라 영역에서는 WebHttpBinding 바인딩과 REST가 적절한 네트웍 스택을 사용할 수 있도록 WebHttpBehavior가 지원됩니다. 또한, 커스톰 ServiceHost (WebServiceHost) 와 ServiceHostFactory (WebServiceHostFactory)가 포함되어 있습니다.
WebGetAttribute 와 WebInvokeAttribute
WCF는 연결된 시스템 구축을 간단하게 해주는데, 네트웍 메시지를 여러분이 서비스를 구현하기 위해 정의한 클래스의 인스턴스로 라우팅해버린다. 결국, 네트웍 트랙픽을 처리하기 위한 인프라에 신경쓰지 않고, 코드의 로직에 집중할 수 있게 해주는 거죠. WCF와 인프라를 함께 사용할 때 기본 디스패처는 요청에서 사용하는 URI를 기준으로 라우팅을 진행합니다. 즉, 이 라우팅 방식을 사용하면 RESTful endpoint를 아주 쉽게 구현할 수 있고, 실제로 WebHttpDispatchOperationSelector를 사용합니다.
WebHttpBinding 와 WebHttpBehavior
Figure 1 HTTP Basic Authentication 예제 코드 사용하기
서비스를 만들고 구동하고 있다면, 어떤 클라이언트를 통해서도 root URI를 입력할 수 있습니다. 브라우저를 이용한 RESTful endpoint 테스트를 위해 아래와 같이 한 번 해보시죠.
Figure 2
.gif)
.gif)
.gif)
.gif)
지난 주 마이크로소프트의 Mix09 행사에서 Windows Azure 클라우드 플랫폼 관련하여 의미 있는 발표가 있었습니다.
첫째, PHP 애플리케이션 개발 지원
둘째, Native 코드와 Full Trust 기능 추가
Windows Azure는 클라우드 상의 운영체제라고 말씀 드렸었죠? 처음 발표 때는 .NET만 가능했지만, 이번에 PHP, 다음에는 Ruby, Java 등이 추가될 것으로 예상됩니다.
IIS7의 FastCGI 기능을 통해 PHP on Windows가 최적화 된 것처럼 Azure위의 PHP도 FastCGI가 지원되고, 스트레스 테스트가 완료된 상태입니다. 현재 보유하고 계신 PHP 기술과 애플리케이션을 Windows Azure위에 올려보시는 것 어떠세요? 나중에 글로벌 서비스가 가능해지면 막대한 비용을 버실 수도 있습니다. 우리나라 뿐 아닌 이웃 나라, 아니 먼 나라에 있는 고객에게 까지 다 서비스가 가능해지기 때문이죠.
종종 듣는 질문입니다. SQL Server 2005, SQL Server 2008이 Windows Server 2008 Hyper-V에서 정상적으로 구동되나요? 네, 당연히 지원됩니다. 그에 대한 해답은 아래 사이트에서 확인하실 수 있습니다.
http://www.microsoft.com/sqlserver/2005/en/us/support-options.aspx
“SQL Server 2005 is now supported on Hyper-V”라고 쓰여있죠?
“SQL Server 2005는 Hyper-V 가상머신에서 지원됩니다”
Windows Server 2008 R2에서는 호스트 서버, 가상 머신 배포가 정말로 간단해집니다.
1. 호스트 서버에 운영체제를 설치하는 것
2. 가상 머신에 운영체제를 설치하는 것
두 경우 다 경험해 보셨죠? 설치 방법이 똑 같은가요? 설치하는데 몇 분 정도 걸리시나요?
가상 머신의 경우 운영체제 이미지를 미리 다 만들어서 Library에 넣어 놓고, 관리도구를 통해 필요할 때 Provision 하는 방식을 선택하셨는데, 이것도 방법을 아는 분, 모르는 분에 따라 전혀 다르게 사용하시더군요
아시는 것처럼 가상머신의 파일 포맷은 VHD가 사용되고, de facto standard가 된 것 같습니다. Windows Server 2008 Hyper-V에서도 역시 VHD 형식을 사용했는데, R2 버전에서는 2가지 중요한 업데이트가 있습니다.
첫째, 관리자가 서버를 리부팅하지 않고 구동중인 VM의 SCSI Controller에 붙어 있는 pass-through disk를 추가 및 삭제 가능합니다. 스토리지가 급격히 증가하는 경우에 추가적인 다운타임 없이 관리할 수 있고 데이터센터 백업등의 시나리오에도 유연하게 대응할 수 있음을 의미합니다.
둘째, 로컬하드디스크에 저장된 .vhd 파일을 가지고 컴퓨터를 부팅할 수 있습니다. 미리 설정된 .vhd 파일을 가지고 호스트 서버, 가상머신을 배포할 수 있다는 것을 의미하죠. 실제 운영환경에 배포하기 전에 테스트환경에 쉽게 올려 놓고 검증 한 후 운영환경으로 간다면 관리의 패러다임이 많이 바뀌게 되는 거죠
Windows Server 2008 R2에서 더욱 강력해진 기능을 꼽으라면 Hyper-V라고 이야기하고 싶습니다.
Live Migration의 기능을 설명 드리겠습니다.
두 대의 호스트서버 A,B가 있습니다. 각 호스트서버에 가상머신 1,2가 구동중인데, 호스트 A에 구동중인 가상머신 1을 서비스 중단 없이 호스트 B로 보내는 것을 의미하죠. 가상머신 1에 연결된 사용자는 반응속도가 약간 떨어지는 것은 느낄지 모르지만, 물리적인 서버가 옮겨졌다는 것은 알지 못합니다.
그림1. Cluster Shared Volumes
Live Migration은 Windows Server 2008 R2에 포함된 Cluster Shared Volumes을 사용합니다. CSV는 같은 Failover Cluster안에 있는 여러 노드 들이 같은 LUN(Logical Unit Number)를 접근하도록 설계되어 있습니다. VM(가상머신) 관점에서는 각 VM이 자신만의 LUN을 가진 것처럼 보이지만 각 VM들은 같은 CSV Volume에 저장되어 있는 거죠.
CSV안에 있는 각 노드들은 같은 이름과 경로를 갖게 됩니다.
그림2. CSV안의 같은 네임스페이스를 사용하는 예
CSV Volumes (Volume1, Volume2, Volume3)은 ClusterStorage 폴더에 저장되어 있습니다. ClusterStorage가 E: 드라이브에 위치하고 있다면 각 CSV Volume은 아래와 같이 접근 가능합니다.
E:\ClusterStorage\Volume1\Root, …
별도의 툴을 사용할 필요도 없죠? 아주 간단합니다.
또한 장점은 위의 노드 간에 단절이 발생할 때 Redirection을 통해 장애를 극복 가능합니다. 예를들면 Cluster Node2가 SAN 접근하는 경로에 장애가 발생하면 Cluster Node1으로 연결이 이루어져 SAN 접근이 가능해지는 것이죠.
괜찮죠?
|
