From Korea Architecture Journal

Jump to: navigation, search

장현춘, 김재우, 신현석 지음

Contents

요약

마이크로소프트의 클라우드 컴퓨팅 기술은 “소프트웨어 + 서비스(Software + Services, 줄여서 S+S)”라는 전략을 바탕으로:

  1. 윈도우 운영체제를 포함하여 여러 클라이언트 애플리케이션 플랫폼을 아우르는, 클라우드 클라이언트(Cloud Client) 또는 B2C 클라우드(B2C Cloud) 기술
  2. 다이나믹 데이터 센터(Dynamic Data Center)와 Windows Server AppFabric을 아우르는, 클라우드 서버(Cloud Server or Private Cloud) 기술
  3. 윈도우 애저(Windows Azure), SQL Azure, Windows Server AppFabric을 아울러 윈도우 애저 플랫폼(Windows Azure Platform)이라 통칭하는, 클라우드 서비스(Cloud Service or Public Cloud) 기술

위 세가지 기술의 총합이라 요약할 수 있다. 이 글에서는 이 가운데 클라우드 서비스에 해당하는 윈도우 애저 플랫폼 기술을 중점으로 살펴본다.

윈도우 애저 플랫폼

애저 서비스 플랫폼은 2008년 10월 말경 공식 발표되었다. 그 공식 명칭이 윈도우 애저 플랫폼으로 변경되었고 2009년 11월 17일, LA에서 진행된 PDC(Professional Developer Conference 2009)에서 상용 서비스 Launch 되었다. 윈도우 애저 플랫폼은 윈도우 애저(Windows Azure)라 이름하는 클라우드 운영체제 서비스를 기본으로, 여러 전문 어플리케이션 서비스 개발자 블록을 한 데 묶은 통칭이다. 이는 그간 하드웨어 업체를 중심으로 데이터 센터의 고도화된 인프라스트럭처(Infrastructure) 구성에 중점을 두고 클라우드 컴퓨팅의 가치를 해석하던 것과는 달리, 어플리케이션 개발의 편의성과 비용 측면에서 초점을 맞추어 “고성능의 SaaS 플랫폼(High-performance SaaS Platform)”을 실현하는데, 분산 운영체제와 웹 어플리케이션 플랫폼을 클라우드 서비스로 구성하였다는 점에서 차별성과 의의를 찾을 수 있다. 지금부터는 윈도우 애저 플랫폼의 구조와 개별 서비스 블록들이 갖춘 기능적 특성을 차례로 상세하게 설명한다.

역사

  1. 2008년 10월 말경, LA 컨벤션 센터에서 처음으로 Windows Azure 및 Azure Service Platform 공식 발표
  2. 2009년 4월 경, 라스베가스 MIX 2009 행사에서 SQL Service를 REST 만이 아닌 T-SQL로도 연동가능하도록 서비스 인터페이스를 확장
  3. 2009년 10월 경, Azure Service Platform을 Windows Azure Platform이란 이름으로 바꿈, SQL Service는 SQL Azure란 이름으로 바꿈
  4. 2009년 11월 17일 LA에서 진행된 PDC(Professional Developer Conference 2009)에서
    • 서비스 공식 출시일은 2010년 1월, 실제 과금은 2010년 2월 1일 기준.
    • 웹 서비스 어플리케이션 서비스 블록인 .NET Service와 자동화된 분산 캐쉬 기술 프로젝트 (코드명 "Velocity")의 연구 성과를 통합하여, Windows Azure AppFabric란 이름의 새로운 이름으로 포장하여 발표

윈도우 애저

Windows Azure는 두 가지 중요한 일, 애플리케이션을 구동(Compute), 데이터를 저장(Storage)하는 역할을 한다. Windows Azure는 마이크로소프트 데이터센터에 존재하는 수많은 서버를 통합 운영하여 강력한 프로세싱 파워를 낼 수 있는데, Fabric이라고 하는 개념을 기반으로 Compute & Storage서비스가 구축 되어 있다. Compute 서비스는 Windows Server 기반으로 이루어져 있고, 초기 CTP(Community Technology Preview) 버전에서는 .NET Framework 기반으로 구축된 애플리케이션만 구동되지만, Unmanaged 코드 역시 지원할 계획을 가지고 있다. CTP 버전에서는 ASP.NET 애플리케이션과 Windows Communication Foundation (WCF) 서비스 같은 .NET 기반의 소프트웨어를 만들 수 있는데 C#, 기타 다른 .NET 언어를 Visual Studio 2008 같은 개발 도구를 이용할 수 있다.

File:Windows Azure.gif

애플리케이션 구동 (Compute 서비스)

애플리케이션은 보통 여러 개의 Instance를 가지고 있고, 각 Instance는 독자적인 VM 안에서 구동 된다. 이 VM들은 64비트 Windows Server 2008 환경이고, Cloud에서 사용되도록 디자인된 Hypervisor에 의해 서비스 된다. Windows Azure 애플리케이션은 실제로 그 VM을 볼 수 없도록 설계되어 있다. CTP 버전에서는 Web Role, Worker Role Instance를 통해서 .NET 3.5 애플리케이션을 만들도록 구성되어 있다. Web Role Instance는 IIS7 웹서버를 경유하여 HTTP(HTTPs) 요청을 받아 들인다. Web Role은 ASP.NET, WCF, .NET Framework 기술을 통해 구현하는데 Web Role Instance 간에 요청을 분산시킬 수 있도록 Built-In 로드밸런싱을 지원한다. Worker Role Instance는 외부로부터 요청을 직접 받아들 일 수 없게 되어 있기 때문에 외부의 네트웍 커넥션은 허용되지 않고, 웹서버가 VM 내부에 구동 되지 않는다. 입력이 Web Role Instance로 부터 들어와서, Windows Azure Storage 내부의 Queue에 저장된 후 작업 결과 값이 Windows Azure Storage에 저장되거나 외부로 보내진다. Incoming HTTP 요청을 처리하고, 요청이 처리된 후 종료되는 Web Role과 다르게 Worker Role Instance는 배치 작업처럼 무한히 구동될 수 있다.

Windows Azure의 초기 배포 버전은 VM과 물리적 프로세서 코어 간에 1:1 관계를 유지하게 되어 있고 이 원칙을 통해 각 애플리케이션의 성능이 보장된다. 각 Web Role, Worker Role Instance는 자신에게 할당된 프로세서 코어가 있는 것이다. 애플리케이션의 성능을 증가시키기 위해, 소유자는 애플리케이션 설정 파일 안에 운영되는 Instance의 수를 증가시킬 수 있다. 그런 후에 Windows Azure Fabric이 새로운 VM을 생성한 후, 코어에 할당하고 이 애플리케이션에 더 많은 Instance를 구동하도록 한다. Fabric은 또한 Web Role, Worker Role Instance에 오류가 발생했을 때 새로운 Instance를 구동해주는 역할을 한다. Windows Azure의 Web Role Instance는 stateless 형태를 지원한다. 상태 정보를 처리하기 위해서는 Windows Azure Storage를 사용하거나 쿠키를 이용해야 한다. Web Role의 statelessness는 또한 Windows Azure의 Built-In Load Balancer에 의한 특징이다. 요청이 특정 웹 Role Instance에게만 보내지는 것이 허용되지 않기 때문이고, 한 사용자가 사용하는 여러 요청들이 동일 Instance로 보내진다는 보장이 없기 때문이다. Web Role과 Worker Role은 모두 표준 .NET 기술을 사용하여 구현되었다. 그러나, 현재 있는 .NET Framework 애플리케이션을 Windows Azure로 변경 없이 사용하도록 하는 것은 불가능하다. 애플리케이션이 스토리지를 접근하는 방식이 다르기 때문이다. Worker role Instance는 입력을 위해 Windows Azure 스토리지의 큐를 이용한다. 개발의 편의를 위해 제공되는 Windows Azure 소프트웨어 개발 Kit은 개발자의 데스크탑에서 구동할 수 있는 Windows Azure Environment를 포함하고 있다. 이 Windows Azure-in-a-box는 Windows Azure Storage, Windows Azure agent, 그리고 Cloud에서 애플리케이션이 구동되기 위해 필요한 것은 다 포함되어 있다. 개발자는 이 환경에서 애플리케이션 디버깅을 할 수 있고, 테스트가 완료됐을 때 실제 Windows Azure Cloud로 배포할 수 있다. Windows Azure fabric은 애플리케이션 실패를 감지하고, 결과를 보낼 수 있다. 또한, Windows Azure platform은 애플리케이션의 자원 소비량, 프로세서 시간, incoming & outcome 대역폭, 스토리지 등에 대한 상세한 정보를 제공한다.

데이터를 저장 (Storage 서비스)

애플리케이션은 데이터와 다양한 방식으로 동작한다. (Blob, Queues, Tables) Blobs은 가장 간단한 방식이다. Windows Azure Storage의 계정은 Container, 50기가 바이트의 크기까지 저장 가능한 Blob, 더 작은 단위인 Block으로 구성되어 있다. 만약 오류가 발생하면, 전체 Blob을 다시 보내는 것이 아니고 가장 최근의 Block을 다시 보내준다. Blobs은 JPEG 사진이 어디서 찍었고, MP3파일의 작곡가가 누구인지 등에 메타데이터 정보를 가질 수 있다.

또 다른 유형인 Tables의 경우 Entity의 계층 구조를 저장할 수 있다. 정해진 스키마를 가지고 있지 않고, 프로퍼티를 통해 다양한 유형의 데이터 타입, 문자열, Int, Bool, DateTime등을 가질 수 있다. 테이블은 여러 서버에 파티션으로 나뉘어 저장되기 때문에 수십억 개의 Entity를 저장할 수 있다.

Queues는 Web Role Instance가 Worker Role Instance와 통신할 수 있는 방법을 제공 한다. 사용자가 Windows Azure Web Role을 통해 구현된 웹 페이지에서 컴퓨팅을 많이 필요로 하는 작업을 요청할 경우 Web Role Instance가 어떤 작업이 이루어져야 하는지를 큐에 메시지로 넣고 Worker Role Instance가 이 큐 값을 읽어서 정해진 작업을 수행하고, 다른 큐를 통해 해당 결과 값을 돌려줄 수 있다. Blobs, Tables, Queues에 관계 없이 Windows Azure storage에 저장된 데이터는 Fault Tolerance를 위해 3번 복제 된다.

Windows Azure storage는 REST 방식을 사용한다. 모든 자원은 URI로 이름이 부여되고, 표준 HTTP 방식으로 처리된다. .NET 클라이언트는 ADO.NET 서비스나 LINQ를 사용할 수 있지만, Java 애플리케이션으로는 표준 REST 방식을 사용할 수 있다. Blob이 HTTP GET을 이용해, URI를 호출하는 방법은 아래와 같다. 

http://<StorageAccount>.blob.core.windows.net/<Container>/<Blobname>

<Storage Account>'는 새로운 Storage Account가 생성될 때 지정되는 식별자이다. <Container>, <Blobname>은 Container의 이름,이 요청이 접근할 Blob의 이름이다.

Tables, Queues 역시 유사한 방식을 사용한다. Windows Azure 플랫폼은 Compute와 Storage 자원을 개별적으로 비용을 책정하기 때문에 On-Premise 애플리케이션이 RESTful 방식으로 Windows Azure Storage를 사용할 수 있다.

Windows Azure Platform

Windows Azure와 함께 Windows Azure Platform을 구성하는 다른 한 축은 개발자가 사용할 수 있는 클라우드 스케일의 빌딩 블록 서비스 모음이라 할 수 있는 어플리케이션 플랫폼 서비스들이다. 아래 그림에서 보는 바와 같이, 클라우드 운영체제인 Windows Azure의 계산(Compute)과 저장(Storage) 서비스 수준을 넘어, 데이터베이스 서비스, 웹 서비스 어플리케이션 서비스, 자동 분산 처리 및 캐쉬 서비스 따위 기업형 n-tier 구조 어플리케이션 개발에 필요한 서비스를, 현재 Windows Azure AppFabric, SQL Azure 란 이름으로 출시하였다. 이후, Windows Live 서비스를 어플리케이션 플랫폼으로 발전시켜 불특정 일반 소비자 간의 Social Computing을 가능하게 하는 플랫폼이라 할 수 있는 Live Services, 기업 내의 동아리 컴퓨팅을 위한 플랫폼이라 할 수 있는 Sharepoint Services, 전문화된 기업형 어플리케이션 서비스인 Dynamic CRM Services 따위가 차차 개발 및 출시될 예정이다.

Windows Azure AppFabric

이 서비스는 기업형 웹 서비스 애플리케이션 개발에 필요한 미들웨어를 클라우드 서비스 형태로 확장한 것이라 할 수 있다. 곧 SOA(Service-Oriented Architecture) 기반의 인프라를 갖추기 위해 기업들은 ESB (Enterprise Service Bus)를 도입하여 표준 웹 서비스(Web Service)기반으로 기업내 다양한 애플리케이션간 서비스 연동을 지원하는데, ESB가 클라우드 스케일로 확장되어 기업간 애플리케이션간 서비스 연동을 제공하는 형태를 ISB(Internet Service Bus)를 갖출 수 있도록 하는 것이 이 기술의 목적이다.

따라서 이러한 클라우드 웹 서비스 블록에는:

  1. 클라우드 위의 애플리케이션 서비스 접속을 위한 포괄적인 사용자 인증 방법, 특히 서로 떨어져 방화벽으로 막혀 있는 서비스들 사이의 서로 다른 인증, 보안 기술을 연동하여 단일한 통합 인증 체계를 구축할 수 있도록 하는 기능,
  2. 클라우드 위의 워크플로우와 외부 웹 애플리케이션 서비스의 워크플로우와 하나의 논리적 워크플로우로 연동시키는 기능을 반드시 제공해야 한다.

그림과 같이 서비스 제공자는 마이크로소프트 데이터 센터에 개설한 자신의 계정에 서비스를 노출하고, 서비스 사용자는 http 프로토콜을 통해 일반 웹 서비스를 호출하는 방식으로 접근할 수 있는 방법을 제공한다. Access Control Services는 다양한 인증 체계를 가진 서비스들 사이에 SAML과 같은 합의된 Federation 표준 기반의 토큰 서비스를 통해 연동할 수 있는 방법을 제공한다.

SQL Azure

SQL Azure는 마이크로소프트의 SQL Server가 제공하는 각종 Relational한 기능들, 즉 리포팅, 분석, 데이터 동기화, Relational 쿼리 등을 클라우드 서비스로 제공하는 것이다. SQL Server 기반으로 구현되어 있는 SQL Azure는 TSQL 기반으로 구축되어 있기 때문에 일반적인 Relational한 데이터베이스 접근 방식을 그대로 제공하고, REST 및 SOAP 기반의 웹 서비스 인터페이스 방식도 제공하고 있다. 개발자들은 이미 보유하고 있는 지식과 기술을 그대로 활용할 수 있는 장점이 있다. 개발자가 SQL Server를 데이터 저장소로 활용하여 On-premise 애플리케이션을 개발할 때 클라이언트와 서버간의 통신을 위해 Tabular Data Stream(TDS) 프로토콜을 이용하는 ADO.NET, ODBC, JDBC, SQL Server driver for PHP 등을 사용한다. SQL Azure는 SQL Server와 같은 TDS를 제공하기 때문에 클라우드와 On-Premise 방식의 구현과 비교하여 차이가 없다.

SQL Azure를 사용하기 위해서는 우선 Windows Azure Platform 계정을 생성해야 한다. 이 계정을 가지고 Windows Azure Platform 내에 있는 모든 자원을 사용할 수 있고, 각 서비스에 대한 빌링이 이루어진다. 각 계정은 여러개의 SQL Azure Server를 보유할 수 있고, SQL Azure Server는 SQL Server 인스턴스가 아닌 논리적인 개념이라고 보는 것이 더 정확하다. 각 Server에 접근하기 위해기존 SQL Server와 마찬가지로 Logins(아이디/패스워드)이 필요하다. 이 SQL Azure Server에 SQL Azure 데이터베이스가 존재하는데 데이터베이스에는 여러개의 데이터베이스가 포함될 수 있다. 데이터베이스를 여러 물리적인 Server에 분산하여 저장할 수 있고, geo-location 기능을 통해 애플리케이션이 특정 지역에 있는 데이터만 사용하도록 사용할 수 있다. 테이블, 뷰, 저장 프로시저, 인덱스, 기타 객체등 기존에 사용하던 객체를 만들 수 있다. 저장된 데이터는 T-SQL로 접근 가능하다.

SQL Azure는 마이크로소프트 데이터 플랫폼의 일부로 설계되었고, SQL Azure와 Sync Framework을 이용하여 On-Premise 애플리케이션과 클라이언트 장치가 SQL Azure를 데이터 허브로 활용하여 동기화되도록 할 수 있다.

데이터베이스는 민감한 데이터를 보관하고 있기 때문에 접근 제어가 반드시 적절히 이루어져야 한다. SQL Azure는 멀티태넌트 환경으로 여러 고객이 함께 사용하는 구조이므로 데이터베이스를 사용자가 서로 격리되어, 다른 고객의 데이터베이스에 대한 접근을 하지 못하도록 해야 한다. SQL Azure는 SQL Server에서 적용된 보안 원칙 및 인증을 그대로 제공한다. SQL Server Logins: SQL Azure 서버 접근 권한을 부여하기 위함 Database Users: SQL AZure에 생성된 데이터베이스 접근 권한을 부여하기 위함 Database Roles: 사용자의 그룹(Role)에 데이터베이스 접근 권한을 부여하기 위함

SQL Azure를 이용하여 아주 작은 크기에서부터 수 테라바이트에 이르는 양의 데이터를 저장할 수 있다. 하지만, 개별 데이터베이스는 크기는 10GB로 제한되어 있다. 10GB를 초과하는 데이터를 저장하기 위해 여러 데이터베이스로 잘게 쪼개, 즉 파티션을 이용하면 되고 데이터에 대한 접근은 병렬 쿼리를 이용한다. 파티셔닝은 성능, 확장성과 비용효과를 보기 위해 여러 애플리케이션에서 사용되는 기술이다. 직접 데이터베이스를 구축할 때, 파티셔닝의 효과는 인정하지만 분산 데이터베이스를 구축하고 운영하는 것이 복잡하기 때문에 DBA가 꺼려하는 경우가 있지만 SQL Azure에서는 수십 대, 또는 수백 대로 분산되어 있는지에 대해 전혀 사용자가 느끼지 못하고, SQL Azure가 처리하기 때문에 전혀 고민할 필요가 없다. 확장성 및 탄력성이 필요한 데이터베이스를 구축할 때 SQL Azure의 장점은 극대화 된다.

SQL Azure에 데이터베이스를 생성하는 환경 역시 기존과 동일하다. Microsoft SQL Server Management Studio를 통해 T-SQL CREATE DATABASE 스크립트로 만들 수 있다. 마이크로소프트의 데이터센터는 글로벌하게 배치되어 있는데, SQL Azure 데이터베이스를 특정 지역에만 생성되도록 할 수 있다. SQL Azure Server를 생성 할 때 원하는 지역을 지정하면, 데이터는 그 지역에만 저장되는 방식이다.

Windows Azure내의 Storage 서비스와는 차별화된 서비스를 제공하게 된다.

Live Services

Live Services는 Windows Live Hotmail, Windows Live Messenger 등 기존에 마이크로소프트가 제공하던 각종 Windows Live 애플리케이션과의 원활한 연동을 제공하며 개발자는 Live Services가 제공하는 Live Framework을 통해 일관된 방식으로 마이크로소프트의 각종 Live 애플리케이션이 관리하는 데이터에 접근할 수 있다. 즉, 아래 그림에서 보듯이 Hotmail이나 Messenger에서 관리되고 제공되는 엄청난 양의 개인 정보, 지인 연락처 정보, 지인의 로그인 여부, 검색 서비스 등에 대해 접근할 수 있으며 이를 기반으로 애플리케이션을 개발할 수 있고 또한 내 애플리케이션이 사용하는 데이터를 다양한 디바이스간에 동기화 기능도 제공할 수 있다.

현재 Live Services를 이용하여 마이크로소프트가 제공하는 서비스로 Live Mesh (http://www.mesh.com) 가 있으며, 다양한 디바이스간 데이터 및 애플리케이션 동기화 기능을 제공하고 있다.

참고문헌

  1. Windows (R) Azure(TM) Platform, Microsoft, http://www.azure.com
  2. David Chappell, “Introducing The Azure Services Platform,” http://download.microsoft.com/download/e/4/3/e43bb484-3b52-4fa8-a9f9-ec60a32954bc/Azure_Services_Platform.pdf, 2008.10
  3. Microsoft, Azure Services Platform, http://www.microsoft.com/azure/windowsazure.mspx
  4. Microsoft, Azure Services Platform, http://msdn.microsoft.com/en-us/azure/default.aspx
  5. Microsoft, MSDN, http://msdn.microsoft.com/en-us/azure/cc994380.aspx
  6. Microsoft, Windows Azure Blog, http://blogs.msdn.com/windowsazure
  7. 신현석, “WOA, 전문가기고,” IT Today, 2008.12.21
  8. 신현석, “MS 클라우드 전략의 ‘코어’, 윈도우 애저,” 마이크로소프트웨어, 2009.01
Retrieved from "http://www.architecturejournal.org/wiki/Windows_Azure_Platform"