Azure(애저) 정리

Article
11/17/2008

이름들이 뭐가 그리 많은지…다 아시는 내용들이겠지만 한번 정리해봤습니다. 내부에서 사용하는 공개되지 않은 용어들은 배제했습니다. 일반 사용자가 사용할 내용은 실제 Azure을 사용하여 만든 서비스에 국한되고 아래의 내용은 대부분 개발자들을 위한 내용입니다.

Azure

마케팅 브랜드 우산(umbrella)으로 정확히 하면 Azure™입니다. 마이크로소프트 전체 클라우드 관련 내용들은 대부분 애저(Azure)라는 브랜드 아래에 들어갑니다. 통상 Azure라고 하면 Azure Services Platform이라고 하는 플랫폼을 지칭하는데 같은 이야기입니다. 이를 ASP라고 줄여 부르면 기존 용어와 완전 대혼란일게 뻔하기 때문에 ASP가 아니고 그냥 Azure입니다. 사이트의 정의를 살짝 베껴오면:

The Azure™ Services Platform (Azure) is an internet-scale cloud services platform hosted in Microsoft data centers, which provides an operating system and a set of developer services that can be used individually or together.

Azure는 일반적으로 3가지로 구분되어있습니다. 가장 기반이 되는 Azure Runtime(Windows Azure), 이들을 사용하여 확장한 Azure Services들 그리고 이들을 사용하여 만든 외부 서비스.

Windows Azure

코드명이 유출되면 불편한 것이 실제 브랜드명과 헷갈리게 된다는 것인데, 전에 Red Dog이라는 코드명으로 알려져 있어서 조금 아시는 분들은 아직 헷갈리고 있는 것 같습니다. 게다가 도중에 Stratus라는 브랜드를 사용하려고 했다가 브랜드 충돌이 있어서 Windows Azure로 바뀌었습니다. 가장 흔히 쓰이는 그림으로 살펴보면 다음과 같습니다:

The Cloud Computing and Services Platform Diagram

Azure는 클라우드를 위한 OS(운영체제)라고 표현하기도 하는데 이해를 위해 컴퓨터와의 Analogy를 사용한 것입니다. 말그대로 다른 서비스들을 제공하기 위해서 기반이 되는 구성요소들이 되겠습니다. 데이타베이스나 파일등을 위한 스토리지라든가 호스팅 기반이라든가 혹은 컴퓨팅/관리를 위한 인프라등등이 여기에 해당됩니다. 위의 그림에서 각각의 흰 네모들은 Azure Services라고 하고 이들을 엮은 전체를 Azure Services Platform이라고 합니다. 윗쪽 Azure Services를 헷갈리지만 Cloud Services라고 부르기도 합니다. 맨 아랫단에 Windows Azure가 있고 이를 Azure Runtime이라고 부르기도 하며 이는 Windows Azure SDK를 사용하여 접근할 수 있습니다.

컴퓨터에 올려진 OS의 경우에는 응용프로그램(Application)과 API 호출 혹은 IPC나 syscall같은 방법을 사용하지만, (당연하지만) 애저에서는 REST방식이나 SOAP혹은 XML, 또는 다른 HTTP를 사용한 프로토콜들을 포함하는 인터넷 프로토콜들을 사용합니다. 물론 Azure Services Platform과 외부 서비스와의 통신도 동일한 방법을 사용합니다. 위의 그림에서는 Windows Live, Office Live등의 마이크로소프트 서비스들을 보여줬지만, 실제로는 Azure를 사용한 다양한 사이트들이 생겨나겠죠.

Live Services

Live Services는 이름에서 유추할 수 있듯이 기존의 Windows Live에서 API로 제공하던 내용들을 하나의 이름 아래에 통합한 것입니다. Live Services SDK 문서를 보면 Live Services API들의 목록을 볼 수 있습니다. 예를 들어 Live ID를 사용하기 위한 API들이라든가 Virtual Earth를 사용하기 위한 API라든가 등등이 포함되어있습니다. 이들은 Windows Live에서 분리하여 사용할 수 있는 것들이죠.

Live Mesh는 여러 디바이스/클라우드/기계들의 데이타를 자연스럽게(?) 동기화하는 응용프로그램으로 시작하여 서비스로 확장한 Live Framework이 되었습니다. 데이타를 동기화하는 시나리오는 굉장히 많은데 Synchronizing Life라는 제목의 프로모션 비디오를 참고하시면 나름 어떤 느낌인지 와닿을 것 같습니다. Live Framework은 단순히 파일을 동기화하는 것이 아니라 여러가지 리소스 모델들을 동기화합니다. 파일 이외에 데이타베이스처럼 테이블의 데이타라든가, 혹은 피드들도 동기화할 수 있습니다. 앞으로 차차 Live Services에서 Live Framework이 중심 프레임웍으로 전환될 예정입니다.

SQL Services

기존의 데이타베이스가 하던 여러가지 기능들이 온라인으로 제공되는 서비스들에 사용하는 브랜드입니다. 이 이름 아래에 있는 서비스들 중에서 현재 공개된 서비스는 이전에 SSDS(SQL Server Data Service)라고 불리던 SDS(SQL Data Services)입니다. SDS는 기존의 관계형 데이타베이스 형태로 관리되는 데이타를 위한 스토리지 서비스로 SQL Server를 기반으로 만들어졌습니다. 클라우드를 생각하지 않더라도 세상에는 데이타를 관리하는 솔루션은 다양하고, 마찬가지로 SDS도 여러가지 관리 방법 중에서 SQL Server의 기능에 집중한 서비스입니다. 헷갈릴 수도 있겠지만, 이런 이유로 이외에도 다양한 다른 방식의 스토리지 서비스들이 Azure에 존재합니다.

SQL Services에서 제공될 다른 서비스들은 여기서 보실 수 있습니다. 모두 새로 오픈한 SQL Services Lab에서 인큐베이팅 중입니다.

.NET Services

굳이 이름을 .NET Services로 했지만, .NET에 국한되기 때문에 이런 이름을 사용한 것이 아니라 .NET의 기능에 맞게 분류했기 때문에 이 이름을 사용한 것 같습니다. 이전에는 BizTalk Labs에서 Biztalk Services라는 이름으로 연구개발을 하던 서비스들로 Azure 아래로 통합되었습니다. 보시면 Java나 Ruby용 SDK도 제공하고, 굳이 SDK를 사용하지 않고 직접 호출해서 사용할 수도 있습니다.

.NET Services에서 현재 제공하는 서비스들은 이전과 비슷하게 다음과 같습니다:

Access Control(접근 제어) – 사용자를 확인하고 할 수 있는 일들을 구분해줍니다.
Service Bus – 응용프로그램들을 연결해주는 매개역할을 합니다.
Workflow Service – 클라우드에서 워크플로를 사용할 수 있도록 합니다.

다시 Windows Azure

Windows Azure 서비스들을 사용하거나 보완하여 위에서 설명한 여러 Azure Services들이 동작하지만, 그렇다고 Windows Azure이 가려져있는 것은 아닙니다. 사용할 수 있는 Windows Azure는 다음의 여러 서비스들로 이뤄져 있습니다:

Windows Azure Storage Services – 파일과 같은 바이너리(Blobs), 서비스간의 메시징 큐(Queues), 데이타베이스와 같은 테이블(Windows Azure Tables)등의 서비스를 제공합니다.
Compute 서비스 – 실제로 CPU를 소비하는 로직을 위한 서비스입니다. 개발된 응용프로그램이 데이터센터로 배포되어 통신을 담당하는 부분과 작업을 담당하는 두부분으로 나뉘어 동작하게 됩니다. (아래 “기타”에 설명되는 Azure Fabric에 해당하는 부분입니다.)

내부적으로는 fabric이라는 용어를 사용합니다.

기타

이름이 무슨무슨 Services이기 때문에 Azure의 내용 같아서 헷갈릴 수 있는 것으로 ADO.NET Data Services가 있습니다. 이전에 Astoria라는 코드명으로 불리던 것으로 Azure Services의 컴포넌트로가 아니라 이런 REST 기반의 서비스를 쉽게 만들 수 있도록 해주는 (WCF를 사용하여 만들어진) 기반 기술입니다. Azure Services가 ADO.NET Data Services로 만들어져 있을 수도 있고, 혹은 ADO.NET Data Services를 염두에 두고 만들어진 서비스라면 연동이 될 수도 있을 것일테죠.

웹에 호스팅되는 서비스를 만드는 회사들은 일반적으로 로컬 개발 –> 테스트 호스팅 환경 –> 운영 환경(운영계)의 단계로 만든 서비스를 확인하면서 최종 배포를 하게 되는데, 이를 Staging이라고 합니다. Azure 서비스를 만들때에도 같은 방식을 사용하게 됩니다. 우선 Windows Azure Tools for Visual Studio를 사용하여 시뮬레이션을 하면서 개발을 합니다. 이때 데이터센터에 있는 서비스들을 직접 사용하는 것이 아닌 시뮬레이션 되는 환경을 Development Fabric이라고 합니다. 반대로 개발된 내용을 운영 환경으로 올린(배포/퍼블리싱) 경우에 실제로 사용하는 환경을 Windows Azure Fabric 혹은 Hosted Services Fabric이라고 합니다. Development Fabric에서는 시뮬레이션만 하지만 Windows Azure Fabric을 통해서는 서버간 배포와 버져닝, 로드 밸런싱이나 복구와 관리등의 작업들이 이루어집니다.

대표적으로 비교되는 타사 서비스라고 한다면 Amazon Web Services나 Google App Engine(Python)이나 Heroku(Ruby) 혹은 Ning(PHP)같을 것을 들 수 있겠습니다. 혹은 위에서 소개한 각각의 서비스와 경쟁하는 회사 서비스들도 있습니다. 각기 다른 비즈니스 모델과 수익 모델을 생각하기 때문에 비슷하게 대응되는 서비스들이 있기도 하고 없기도 합니다. 대충 클라우드 컴퓨팅 플랫폼이라고 하는 다가오는 환경의 맛보기라고나 할까요.

혹자 우리가 사용하는 모든 웹서비스들과 bittorrent나 SETI@home같은 아키텍쳐를 포함하여 클라우드 컴퓨팅이라고 한다고 미래의 다른 가능성도 포함하여 정의하지만 산업 전반을 이야기하는 용어로 사용하기보다는 여기서는 플랫폼으로서의 클라우드 컴퓨팅으로 개인적으로 인프라/플랫폼등을 포함한 “기능을 (호스팅 기반의) 인터넷 기반의 서비스로 제공하는 모델”이라고 보는 것이 일단은 무난하지 않나 생각됩니다. 어떤 경우든 클라우드 컴퓨팅의 시대가 도래했다는 것은 맞는 말이겠지만요.

위에서 정리한 Azure 서비스들은 앞으로 계속해서 나올 서비스들의 흐름을 보여주는 것으로, Windows Live 자체도 위의 모델로 바뀌어 갈 것이고 위의 서비스들의 모양들로 유추할 수 있듯이 기존 소프트웨어의 강력함을 계속 가져가는 S+S(Software plus Services) 모델도 계속해서 마이크로소프트의 한 축으로 계속될 것이라 생각됩니다.