제가 마이크로소프트의 클라우드 컴퓨팅, Windows Azure, Azure Services Platform에 대해 공부하다가 작성하였습니다. 참고하시고 이해에 도움이 되시면 좋겠습니다. 이 글은 기본적인 개념을 잡는데 도움이 됩니다. 조금 더 구체적인 내용은 다음 글에 적도록 하겠습니다.
마이크로소프트의 클라우드 컴퓨팅은 크게 2개 영역으로 나뉘어져 있습니다. Windows Azure, 그리고 Azure Services Platform이 바로 그것이지요.
Windows Azure는 클라우드 상에 데이터를 저장하고, 윈도우 애플리케이션이 구동될 수 있는 환경을 제공하는 플랫폼입니다. Windows Azure 는 클라우드 애플리케이션에게 윈도우 기반의 컴퓨팅, 스토리지 서비스를 제공합니다.
Windows Azure
Windows Azure는 마이크로소프트 데이터센터에 위치한 수많은 서버 위에서 운영되는데, 인터넷을 통해 접근 가능합니다. Windows Azure Fabric Knit (잘 짜여진 Fabric)은 강력한 프로세싱 파워를 통합된 하나로 묶어 주는데, Windows Azure의 Compute & Storage서비스는 이 Fabric 위에 구축되었습니다.
Windows Azure Compute Service는 기본적으로 Windows 기반으로 이루어져 있고, 초기 버전 CTP(Community Technology Preview)는 .NET Framework 기반으로 구축된 애플리케이션만 구동되지만, Unmanaged 코드 역시 지원할 계획을 가지고 있습니다. (2009년 중에 발표 예정)
CTP 버전에서는 ASP.NET 애플리케이션과 Windows Communication Foundation (WCF) 서비스 같은 .NET 기반의 소프트웨어를 만들 수 있는데 C#, 기타 다른 .NET 언어를 Visual Studio 2008 같은 개발 도구를 이용할 수 있습니다. 웹 애플리케이션과 별도로 동작하는 백그라운드 프로세스를 지원합니다.
Windows Azure 애플리케이션, On-Premise 애플리케이션 모두 RESTful 접근을 통해 Windows Azure Storage 서비스를 이용할 수 있습니다. Windows Azure의 스토리지는 Microsoft SQL Server 기반이 아닙니다. Windows Azure Storage는 관계형 시스템이 아니고, 쿼리 언어도 SQL이 아닙니다. Storage 서비스는 Windows Azure 위에 구축된 애플리케이션을 위해 디자인됐고, 간단하고 확장 가능한 스토리지를 제공합니다. Blob(Binary Large Object), Windows Azure 애플리케이션 간의 커뮤니케이션을 위한 Queue를 지원하고, 직관적인 쿼리 언어를 사용하는 테이블을 지원합니다.
클라우드 서비스를 위해서는 효과적인 관리가 가능해야 하는데, Windows Azure의 각 애플리케이션은 설정 파일을 가지고 있고 이 파일을 수작업, 또는 프로그램을 통해 수정하면, 애플리케이션 개발자는 사용할 Windows Azure 인스턴스의 개수 변경 등의 정책을 통제할 수 있습니다. 또한, Windows Azure Fabric이 원하는 상태를 유지할 수 있도록 애플리케이션을 모니터링 합니다.
개발자가 개발, 설정, 모니터링 하는 등이 가능하도록 브라우저 기반의 포탈을 제공합니다. 애플리케이션을 구동하기 위한 호스팅 계정을 만들거나, 데이터를 저장하기 위한 스토리지 계정을 만드는 등의 작업이 가능합니다.
1. Start up, 즉 사업을 시작하는 회사가 웹사이트 구축(Facebook), 웹 서비스와 백그라운드 프로세스를 모두 구현 가능하므로 , 애플리케이션은 인터랙티브한 사용자 인터페이스를 제공합니다. (비동기 작업 가능) 인프라에 대한 걱정 없이, 사용자와 투자자에게 가치를 제공할 수 있는 코드 개발에 집중할 수 있습니다.
사용자가 적다면, 비용도 엄청 저렴할 것이고, 사용량이 늘어나면 Windows Azure가 자동 확장해주는데 이때는 매출이 발생할 것이기 때문에 비용을 지불하고도 수익을 낼 수 있는 구조 입니다.
2. 현재 On-premise 방식의 솔루션을 SaaS 버전으로 변경
Windows Azure가 표준 .NET 기반 환경이기 때문에 애플리케이션의 .NET 비즈니스 로직을 클라우드 플랫폼으로 변경하는 것이 그리 어렵지 않습니다. ISV가 비즈니스 로직에만 집중할 수 있습니다. (인프라에 대한 고민 No)
3. Enterprise
Windows Azure가 .NET 기반이기 때문에 기존의 기술이 있다면 개발이 어렵지 않습니다. 기존의 자산투자비용 -> 운영비용으로 개념이 바뀝니다. 크리스마스, 졸업 입학 선물 시즌 등의 사용량 증가를 고민할 필요가 없이, 클라우드 서비스 제공자에게 맡기면 됩니다.
Azure Services Platform
.NET Services
클라우드 상에 애플리케이션을 구동하는 것은 클라우드 컴퓨팅의 중요한 부분이긴 하지만, 그것보다 더 큰 영역이 있습니다. 클라우드 기반의 서비스를 On-Premise 애플리케이션과 Cloud 애플리케이션이 모두 이용할 수 있기 때문입니다. 이 두 영역간의 간격을 좁혀주는 역할을 .NET Services가 제공합니다.
분산 애플리케이션을 개발할 때 공통적으로 발생하는 어려움을 극복하기 위한 것이 .NET Services의 목적입니다.
Access Control: 애플리케이션에게 각 사용자의 정보를 담고 있는 클레임을 토큰 형태로 제공하는 것
즉, 애플리케이션이 이 클레임을 기준으로 어떤 일을 할 수 있는지 결정하도록 하는 것을 의미합니다.
여러 회사간에 이런 일이 가능 하려면 Identity Federation, 즉 한 Identity 영역에서 생성된 클레임이 다른 조직에서 받아들여질 수 있도록 하는 작업이 필요한데 이러한 역할을 Access Control이 담당합니다.
Service Bus: 인터넷 상에 애플리케이션 서비스를 노출시키는 것은 생각보다 쉽지 않습니다. Service Bus의 목표는 웹 서비스의 Endpoint를 노출시켜서 On-Premise, 클라우드 상의 다른 애플리케이션이 쉽게 접근할 수 있도록 하는 것입니다. 각 Endpoint에 대한 위치를 찾고 접근할 수 있도록 하는 것이지요. URI로 지정되어 있습니다. Service Bus는 또한 NAT(Network Address Translation), 노출된 애플리케이션이 새로운 포트를 열지 않고 방화벽을 통과하도록 하는 등의 역할을 제공합니다.
Workflow: 복잡한 애플리케이션을 개발하는 것, 즉 엔터프라이즈 애플리케이션 통합 등은 여러 부분의 상호작용을 조절하는 로직이 필요합니다. 이 로직은 오래 수행되는 프로세스들이 처리될 수 있도록 워크플로우를 사용하여 구현되는데,Windows Workflow Foundation(WF) 기반으로 구축되어 있습니다
몇 가지 예제
- 여러 다른 회사의 고객들이 사용하는 애플리케이션을 제공하는 ISV, Access Control 을 사용하여 애플리케이션
개발 및 운영 단순화
여러 회사에서 요구하는 다양한 클레임을 해석하는 컴포넌트를 제공함으로, 각 회사들은 독자적인 아이덴티티 기술을 그대로 사용하면서, ISV 애플리케이션은 일관된 형태로 대응하여 개발 가능합니다. 또한, Identity Federation을 사용하지 않고 클라우드 기반의 Access Control 서비스를 사용하여 ISV가 On-premise Federation S/W를 운영할 필요가 없어집니다.
- 엔터프라이즈가 거래처를 대상으로 애플리케이션 하나에 대한 접근을 허용하고자 할 때 이 애플리케이션의 기능을 SOAP, RESTful 웹서비스를 통해 노출시키고, Endpoint를 Service Bus로 등록합니다. 해당 거래처가 서비스 버스를 통해 Endpoint를 찾을 수 있고, 서비스에 접근하게 되는데, 이런 과정 중에 방화벽상에 포트를 개방 할 필요가 없기 때문에 애플리케이션을 노출시키는 위험성을 줄여줍니다. 해당 조직은 또한 Access Control 서비스를 사용할 수 있을 것이고, 이 Access Control은 Service Bus와 함께 사용할 수 있도록 디자인되었기 때문에 거래처에게 해당 Identity 정보를 보내는 것이 아주 용이해집니다.
- 위의 예제에서 거래처와의 비즈니스 프로세스가 일관되게 이루어져야 하는데, 이럴 때 WF 기반의 애플리케이션인 Workflow 서비스가 이용될 수 있습니다. 서비스 버스를 통해 통신하고, Access Control을 통해 Identity 정보를 교환하고, Workflow로 비즈니스 프로세스를 처리할 수 있게 되는 것이죠.
Windows Azure의 브라우저로 접근 가능한 포탈을 통해 Windows Live ID를 통해 .NET Services를 신청할 수 있습니다. .NET 서비스의 목표는 분명한데, 분산 애플리케이션을 위해 유용한 클라우드 기반의 인프라를 제공하는 것입니다
SQL Services
이 기술을 통해 On-premise, 클라우드 기반 애플리케이션이 마이크로소프트 데이터 센터내의 서버에 데이터를 저장하고, 접근할 수 있습니다. 사용한 만큼만 지불하고, 조직의 필요성의 증감에 따라 증가, 감소할 수 있다는 것을 의미하고, 디스크, DBMS, 운영 등의 자산 투자를 운영비용으로 바꿀 수 있게 되는 거죠. 가장 큰 용도는 여러 장치, 위치에 관계 없이 접근 가능하다는 것이고, 이를 위해 SOAP, RESTful 인터페이스를 통해 노출시켜 다양한 방법으로 접근할 수 있게 됩니다. 데이터가 표준 프로토콜을 통해 노출됨으로 SQL Data Services는 어떤 유형의 시스템으로부터도 사용될 수 있다. (Windows만의 기술이 아님)
Windows Azure Storage 서비스와 달리, SQL Data Services는 Microsoft SQL 서버 기반으로 구축됩니다. 하지만, 전통적인 관계형 인터페이스를 제공하지 않고, 계층적 데이터 모델을 제공합니다. 이 서비스에 저장된 각 아이템은 Name, Type, Value의 프로퍼티로 저장되고, 이 데이터를 쿼리하기 위해 Microsoft Language Integrated Query (LINQ)에 의해 C# Syntax로 정의된 언어이거나, RESTful 접근을 통해 사용할 수 있습니다.
왜 이전의 SQL Server를 다루던 방식을 사용하는 대신, 다른 형태의 SQL Services를 제공할까요? 새로운 방식이 데이터를 조직화하고, 검색하여 replication, 로드밸런싱을 제공하는 것을 더 쉽고 빠르게 하기 때문입니다.
예제
- 애플리케이션이 오래된 데이터를 SQL Data Services로 아카이브 할 수 있습니다. 빈번히 업데이트되는 RSS 피드를 생각해보면, 30일 이상 된 자료의 경우 거의 사용되지 않지만, 여전히 사용 가능해야 하는데 이러한 데이터를 SQL Data Services에 저장하면 저렴한 가격으로, 안정적인 서비스가 가능합니다.
- 딜러와 소비자에게 프로덕트 정보를 제공하려고 하는 제조업자가 있다고 가정하면, 이 데이터를 SQL Data Services에 넣는다면 딜러와 고객 웹사이트에서 모두 접근 가능하도록 할 수 있을 겁니다. 데이터가 RESTFul , SOAP 인터페이스로 접근 가능하므로, 어떤 플랫폼에서 구동되든, 어떤 기술을 사용하는 애플리케이션이든 관계없이 해당 서비스를 쓸 수 있게 되는거죠. SQL Data Services는 쓰기가 정말 쉽습니다. 웹 포탈에 가서, 필요한 정보를 입력하면 되는데, 데이터를 아카이빙 하는 것이든, 여러 위치에서 접근 가능한 애플리케이션을 만드는 것이든, 클라우드 데이터베이스는 매력적임에 분명합니다.
David Chappell이 쓴 백서를 기준으로 작성했습니다.
