Windows Azure에 대해서 알아보자 (part 1)
Windows Azure란 퍼블릭 클라우드에 대한 마이크로소프트의 플랫폼입니다. 사실, 앞으로는 Azure란 단어가 공식 명칭에서 제외할 것으로 보이기에, 공식 호칭이 그냥 Windows Cloud가 될 것으로 예상되지만 말이죠. 하지만, 아직은 온 동네에서 Azure라고 부르니깐 이 컬럼에서도 일단은 Azure라고 부르도록 할게요. 여러분이 응용 프로그램을 개발할 경우, 수 많은 다양한 방식으로 Azure 플랫폼을 이용할 수 있는데요. 예를 들면, Azure 플랫폼을 통해서 마이크로소프트 데이터 센터에 데이터를 저장하는 웹 응용 프로그램을 만들어서 올려 볼 수 있습니다. 게다가, 온프레미스(on-premises, 즉, 퍼블릭 클라우드 외부, 일반적으로 자체 시스템)에서 구동되는 데이터를 사용하는 응용 프로그램을 만들어 Windows Azure에 올릴 수도 있습니다. 또한, 여러분만의 자체 응용 프로그램들을 Azure를 이용하여 서로 연결할 수도 있으며, 다양한 ID 정보 집합 등을 이용하여 시스템들을 연계할 수도 있습니다. 왜냐하면, Azure 플랫폼은 폭넓은 서비스들을 제공할 뿐만 아니라 그러한 모든 것들이 가능하도록 지원하고 있기 때문입니다.
다만, 그러한 다양한 작업들을 수행하기 위해서는 우선 기본적인 지식을 알아야 할 필요가 있습니다. 클라우드 컴퓨팅에 대해서 아는 것이 아무 것도 없다고 걱정하지 마세요. 이번 컬럼에서 Windows Azure에 대한 기본적인 지식을 알려드릴 테니 말입니다. 이번 컬럼의 목표가 바로 Windows Azure라는 클라우드 플랫폼을 이해하고 사용하기 위한 기초를 알려드리는 것이거든요.
목차
다만, 원래의 컬럼과는 달리 번역된 이번 컬럼은 상기 목자를 2 파트로 나누어서 진행했기 때문에, 파트 1 은 메시징까지 이야기할 것이고요. 다음에 올라올 파트 2에서 나머지를 모두 이야기할 예정입니다.
Windows Azure 구성요소들
Windows Azure가 무엇을 제공하는 지 살펴보려면, 우선 Azure의 서비스들을 각각의 카테고리 별로 그룹지어 보는 것이 좋습니다. 그림 1은 그렇게 나누어 놓은 모습을 보여주고 있습니다.
그림 1 : Windows Azure는 마이크로소프트 데이터 센터에서 구동되는 다양한 클라우드 서비스들을 제공하고 있습니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding01.png
Windows Azure를 이해하려면, 각각의 구성요소가 하는 일을 알아둘 필요가 있습니다. 이번 컬럼에서는 그림에서 보여진 각각의 기술들에 대해서 살펴볼 예정인데요. 각 요소들이 제공하는 기능은 무엇인지 그리고 언제 그 것들을 사용하면 좋은지에 대해서도 알아볼 예정입니다.
클라우드 응용 프로그램
Windows Azure 응용 프로그램은 여러분들의 자체 데이터 센터에서 동작하는 응용 프로그램과 거의 같다고 보면 됩니다. 즉, 여러분이 좋아하는 언어(C#, Java, PHP, Node.js 등)를 사용하여 코드를 작성한 다음, 윈도우 서버에서 구동되는 가상 머신에서 그 코드를 실행할 수 있다는 것이죠. 하지만, Windows Azure는 신뢰할 수 있고, 확장성이 높으며, 관리하기에도 용이한 응용 프로그램을 만드는 데에 도움이 되도록 설계되어 있기 때문에, Windows Azure 응용 프로그램을 만드는 것은 기존의 응용 프로그램을 만드는 것과는 약간 다릅니다. 물론, 여러분이 이미 알고 있는 소프트웨어 개발 관련 지식의 대부분이 Windows Azure에서도 동일하게 적용되긴 하지만, 별도로 알아 두어야 할 몇몇 새로운 내용도 존재한다는 것이죠.
Azure에서는 모든 응용 프로그램이 하나 이상의 Role(역할)로 구현되어야 하는데요. 각각의 Role(역할)은 응용 프로그램의 기능을 수행하는 데 필요한 코드와 구성 정보를 포함해야 합니다. 현재 Azure는 두 가지 유형의 Role을 제공하고 있는데요. Web Role(웹 역할)과 Worker Role(작업자 역할)이 바로 그것입니다. 실무에서는 한글로 번역된 명칭보다는 원래의 영어 명칭을 주로 사용하기 때문에 이 글에서도 가급적이면 영어 명칭을 사용하고 있습니다. Web Role은 웹 브라우저나 기타 HTTP 클라이언트와 직접적으로 상호작용하는 코드(이 코드는 주로 마이크로소프트의 웹 서버인 IIS를 사용합니다)를 위해서 설계되었습니다. 그리고, Worker Role은 좀 더 일반적인, 다양한 코드들을 실행하기 위해서 준비된 것입니다.
예를 들어, 여러분이 단순한 ASP.NET 혹은 PHP 응용 프로그램을 만들고자 한다면, 오직 Web Role만을 사용해도 충분할 겁니다. 하지만 좀 더 복잡한 응용 프로그램을 만들어야 한다면, 사용자와의 상호작용을 위해서는 Web Role을, 그러한 사용자들의 요청을 처리하기 위해서는 Worker Role을 사용해야 할 수도 있습니다. 또 어떤 경우에는 단지 Worker Role만을 사용해야 하는 경우도 있을 수 있는데요. 예를 들면, 수 많은 데이터를 병렬로 처리하는 응용 프로그램을 작성해야 하는 경우가 그렇습니다.
응용 프로그램에 어떤 Role을 적용하던지 간에, 각 Role의 코드는 [Role인스턴스] 안에서 실행됩니다. 사실, Role인스턴스라는 것은 윈도우 서버를 구동하고 있는 가상 머신(VM)인데요. Windows Azure 데이터 센터 안에서 운영되고 있어요. 그림 2는 두 개의 Web Role인스턴스를 실행하는 응용 프로그램이 데이터센터 안에 놓여져 있는 모습을 보여주고 있습니다.
그림 2 : 각각의 Windows Azure 응용 프로그램 코드는 여러 Role 인스턴스 안에서 실행되는데, 각각의 인스턴스는 사실 가상 머신입니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding02.png
위와 같은 경우, 각각의 Web Role 인스턴스는 동일한 윈도우 서버 상에서 동일한 응용 프로그램 코드의 복사본을 실행할 것입니다. 그리고, Windows Azure는 자동으로 로드 밸런싱(load balance, 부하 균형)을 수행하여 모든 사용자의 요청을 그러한 두 개의 인스턴스로 균등하게 배분해 주기도 합니다. 응용 프로그램을 배포하기 위해서 개발자가 명시적으로 가상 머신을 만들거나 할 필요는 없습니다. 단지, 응용 프로그램의 실행 파일을 Windows Azure에 올리기만 하면 됩니다. 어떤 종류의 Role 인스턴스를 사용할 것인지(web혹은 worker), 얼마나 많은 인스턴스가 필요한 지를 지정해서 말이죠. 그러면, Windows Azure는 각각의 Role에 대해서 여러분이 지정한 수 만큼 VM을 만들고, 각각의 VM 안에서 실행 파일의 복사본을 실행할 것입니다. 개발자는 단지 무엇을 얼마나 원하는 지를 알려주기만 하면 됩니다. 그러면, Azure 플랫폼이 알아서 모든 것을 다 해 준다는 거에요.
일단 응용 프로그램이 구동되면, Windows Azure는 그를 계속해서 감시하게 됩니다. 그러다가, 코드가 동작하지 않거나 혹은 실행중인 Role 인스턴스가 정지하는 경우, Windows Azure가 알아서 그 Role의 새로운 인스턴스(VM)를 자동으로 시작해 줍니다. 심지어 VM이 올라가 있는 물리적인 머신이 다운되는 경우에도 말이죠. 또한, Azure 플랫폼은 여러분의 응용 프로그램이 사용하고 있는 물리적 머신 및 가상 머신에 업데이트를 적용하는 것도 지원해 줍니다. 운영 체제의 새로 패치된 버전을 배포하는 작업까지도 포함해서 말이죠. 그렇기 때문에, Windows Azure 응용 프로그램은 일반적으로 각각의 Role에 대해 두 개 이상의 인스턴스를 실행하는 것이 바람직합니다. 그래야 응용 프로그램이 구동되고 있는 동안에도 플랫폼이 한번에 하나씩 차례대로 VM을 멈추고 업데이트할 수가 있기 때문입니다. 그리고, 이와 같은 서비스를 이미 내장하고 있기 때문에, Windows Azure는 PaaS(Platform as a Service) 클라우드 컴퓨팅 범주에 속한다고 이야기합니다.
만일, Windows Azure 응용 프로그램에 부하가 가중된다면(수많은 새로운 사용자들이 한번에 마구 몰려드는 경우에 이럴 수 있겠죠), 개발자 혹은 응용 프로그램은 단지 더 많은 인스턴스를 달라고 요구하기만 하면 됩니다. 그러다가, 부하가 줄어들면, 다시 인스턴스의 수를 줄여달라고 요청하면 되는 것이죠. Windows Azure는 각각의 인스턴스에 대해 시간 단위로 과금하기 때문에, 단지 필요한 용량 만큼만 비용을 지불하면 됩니다. 꽤 합리적이죠(가격 정책에 대해서 궁금하면 http://www.windowsazure.com/ko-kr/pricing/details를 참고하세요)
데이터 관리
모든 각각의 Windows Azure 응용 프로그램은 하나 이상의 Role 인스턴스 안에서 실행됩니다. 즉, 하나 이상의 VM 안에서 실행된다는 것이죠. 그리고, 각각의 VM은 응용 프로그램이 자유롭게 사용할 수 있는 로컬 저장소(하드 드라이브 등)를 가지고 있습니다. 하지만, 로컬에 파일이나 데이터를 저장하는 행동은 하지 않는 것이 좋습니다. Windows Azure는 관리 상의 이유로 주기적으로 인스턴스들을 종료하고 바꾸기 때문에, 로컬 저장소에 놓아 둔 데이터는 아무런 예고도 없이 사라져 버릴 수 있습니다. 그렇기 때문에, 응용 프로그램이 영구적으로 저장해야 하는 데이터들(거의 대부분의 데이터들이 그렇겠지만 말이죠)은 반드시 VM 외부에 저장되어야만 합니다. 이를 위해서, Windows Azure는 그림 3에서 보이는 것과 같이 3가지 종류의 데이터 관리 옵션을 제공하고 있습니다.
그림 3 : Windows Azure는 데이터 관리를 위해서 관계형 스토리지(SQL Azure), 확장 가능한 테이블(Tables) 그리고 자유 형식의 블랍(Blob)을 제공하고 있습니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding03.png
각각의 옵션은 서로 각각 쓰임새가 다릅니다. 하나는 관계형 스토리지이고, 다른 하나는 빠른 접근을 자랑하는 단순 형식 데이터 저장소(대용량 지원)이고, 남은 하나는 자유로운 형식의 blob 스토리지 이니까요. 3가지 중 그 어느 것을 사용하던, 고 가용성을 제공하기 위해서 데이터는 Windows Azure 데이터센터 안에 있는 서로 다른 3개의 컴퓨터에 자동으로 복제됩니다. 그림에서 보이는 것과 같이, 3가지 옵션 모두 Windows Azure 응용 프로그램에서도 접근이 가능할 뿐만 아니라 여러분의 자체 데이터 센터나 집에 있는 노트북, 핸드폰에서 실행되는 응용 프로그램에서도 접근이 가능합니다. 하지만, 그들을 사용하게 되면, 사용한 Azure 데이터 관리 서비스 모두에 대해서 사용한 만큼 비용을 지불해야 하며, 저장되어 있는 데이터에 대해서도 기가 단위로 월별 비용을 지불해야 한다는 점 기억하세요(비용에 대해서는 http://www.windowsazure.com/ko-kr/pricing/details를 참고하시기 바랍니다).
SQL Azure
Windows Azure는 관계형 저장소를 위해서는 SQL Azure를 제공하고 있습니다. SQL Azure는 클라우드 기반의 SQL 서버라고 생각하면 되는데요. SQL Azure는 관계형 데이터베이스 관리 시스템 즉, RDBMS의 핵심적인 기능을 모두 제공합니다. 예를 들면, 트랜잭션 관리를 제공하고, 다중 사용자의 동시 데이터 접근(데이터 무결성 보장)을 지원하며, ANSI SQL을 통해 질의할 수도 있게 합니다. SQL Azure는 엔티티 프레임워크, ADO.NET, JDBC를 이용한 Java 및 그 밖의 다양한 데이터 접근 기술을 사용하여 연결할 수 있습니다. 여러분은 SQL 서버를 대상으로 작업했던 것과 거의 똑같은 방식으로 SQL Azure를 사용할 수 있습니다. SQL Azure는 대부분의 T-SQL 언어를 지원할 뿐만 아니라 SSMS(SQL Server Management Studio) 도구나 SQL Server 데이터 도구들을 사용하여 접근할 수도 있기 때문입니다. 이미 SQL 서버에 익숙한 사람들이라면 심지어 SQL 서버가 아닌 그 밖의 관계형 데이터베이스에 익숙한 사람이라도 RDBMS를 다룰 줄 아는 사람이라면 SQL Azure를 사용하는 것은 매우 쉬울 겁니다.
하지만, SQL Azure가 단지 클라우드에 놓여있는 DBMS 이기만 한 것은 아닙니다. 아시겠지만, SQL Azure 또한 PaaS 서비스입니다. 여전히 여러분은 데이터를 제어할 수 있고, 데이터에 접근할 수 있는 사람들도 제어할 수 있습니다만, 그 밖에도 SQL Azure는 하드웨어 인프라를 관리해주고, 자동으로 운영 체제와 데이터베이스가 최신 상태로 유지되도록 해 주는 등 많은 일들을 수행해 줍니다. 다시 말하자면, SQL Azure는 일반적으로 관리하기 힘든 모든 작업들을 대신해 준다고 보면 됩니다.
만일 여러분이 관계형 저장소를 사용하는 Windows Azure 응용 프로그램을 만들고자 한다면, 현재는 SQL Azure가 최선의 선택입니다. 심지어 클라우드 외부에서 실행되는 응용 프로그램들도 이 서비스를 사용할 수 있기에 매우 다양한 시나리오가 가능합니다. 예를 들면, SQL Azure에 저장된 데이터는 다양한 클라이언트 시스템(데스크탑, 노트북, 타블렛, 폰 등)에서 쉽게 접근할 수 있습니다. 그리고, SQL Azure는 복제를 통한 고 가용성을 제공하기 때문에, SQL Azure 데이터베이스를 사용하면 시스템 장애시간(downtime)을 최소화 할 수 있습니다. 또한, SQL Azure는 데이터 동기화를 위한 SQL Azure Data Sync 서비스도 제공하고 있는데요. 이는 별도의 추가적인 프로그래밍 없이도 사용자가 자체(on-premises) SQL 서버 데이터베이스와 클라우드 기반의 SQL Azure 데이터베이스 간에 데이터를 동기화할 수 있게 해주는 서비스입니다.
Table
수백 기가의 단순 형식 데이터에 빠르게 접근할 필요가 있는 Windows Azure 응용 프로그램을 만들고자 하지만, 그러한 데이터에 대해 복잡한 SQL 질의를 수행할 필요는 없다고 가정해 보아요. 예를 들어, 각각의 사용자에 대해 사용자 프로필 정보를 저장할 수 있는 사용자 응용 프로그램을 만들었는데, 여러분의 앱이 갈수록 유명해지고 있어서, 더 많은 데이터를 사용해야 할 필요가 있다고 생각해 봐요. 하지만, 데이터를 저장한 다음에는 단순히 데이터를 가져오는 것 외에는 별다른 작업을 할 필요가 없는 시크한 앱이라고 상상 해 봅시다. 바로 이러한 경우가 Table이 가장 적절한 상황이라고 볼 수 있습니다.
이름으로 인해 헛갈려 하지 마세요. Table은 관계형 저장소를 제공하지 않습니다. 만일, 데이터 참조 무결성, 데이터베이스 트랜잭션, SQL 질의와 같은 RDBMS 기능이 필요하다면, 최선의 선택은 SQL Azure입니다. Table을 사용하는 경우에는 응용 프로그램은 string, integer, date 등 다양한 형식의 속성들을 저장할 수 있습니다. 그런 다음, 응용 프로그램은 특정 그룹에 대한 고유 키를 제공하여 속성들의 그룹을 가져올 수 있습니다. 조인과 같은 복잡한 작업은 지원되지 않지만, Table은 형식 데이터에 빠르게 접근할 수 있다는 장점이 있습니다. 더불어, 단일 테이블이 테라 바이트 규모의 데이터를 담을 수 있으며, 확장성도 대단히 높습니다. 그리고, 그러한 단순함에 걸맞게, Table은 일반적으로 SQL Azure의 관계형 저장소를 사용하는 것보다는 비용이 저렴합니다.
Blob
데이터 관리를 위한 Windows Azure의 세 번째 옵션은 Blob 인데요. 이는 구조적이지 않은 자유 형식의 이진 데이터를 저장하기 위해서 고안되었습니다. Table과 마찬가지로, Blob도 저렴할 뿐만 아니라, 단일 Blob이 테라 바이트만큼 커질 수도 있습니다. 예를 들면, 동영상을 저장하는 응용 프로그램 혹은 데이터를 백업하거나 기타 이진 정보를 저장하는 응용 프로그램이라면 간단하고 저렴한 스토리지인 Blob을 사용하는 것이 좋을 것 입니다. Windows Azure 응용 프로그램은 또한 Windows Azure 드라이브도 이용할 수 있는데요. 이 드라이브는 Blob를 통해서 Azure 인스턴스 안에 설치된 윈도우 파일 시스템에 영구적인 저장소를 제공할 수 있게 합니다.
비즈니스 분석
저장된 데이터를 사용하는 가장 보편적인 방법 중 하나는 그러한 데이터를 기반으로 보고서를 만드는 것입니다. SQL Azure에 있는 관계형 데이터를 가지고 보고서를 만들 수 있도록, Windows Azure는 SQL Azure Reporting을 제공하고 있습니다. SQL 서버에서 제공되는 리포팅 서비스의 서브셋인 SQL Azure Reporting은 Windows Azure 응용 프로그램에서 리포팅을 만들 수 있게 합니다. 생성되는 리포트는 HTML, XML, PDF, Excel 등 다양한 포맷이 될 수 있으며, 응용 프로그램안에 삽입되거나, 웹 브라우저를 통해서 보여질 수 있습니다.
SQL Azure 데이터를 분석하는 또 다른 방법으로는 비즈니스 인텔리전스 도구를 사용하는 것입니다. 클라이언트 입장에서는 SQL Azure나 SQL 서버나 크게 다를 바가 없습니다. 그렇기에, 비즈니스 인텔리전스 도구는 SQL Azure를 대상으로도 잘 동작합니다.
메세징(Messaging)
어떤 작업을 수행하던 지와 관계없이 코드는 종종 다른 코드와 통신을 해야 할 필요가 있습니다. 그렇게 하기 위한 일반적인 방법 중 하나는 큐를 사용하는 메시지(queued messaging)를 이용하는 것입니다. 물론, 다른 방법을 사용할 수도 있겠지만 말이죠. 별개의 응용 프로그램은 서로 다른 조건을 요구할 수 있기 때문에, Windows Azure는 그러한 통신을 위해 서로 다른 2가지의 기술 즉, 큐(Queues)와 서비스 버스(Service Bus)를 제공하고 있습니다.
Queue(큐)
Windows Azure에 의해 제공되는 서비스인 Queue는 이해하기가 쉽습니다. 말 그대로 큐 기능이거든요. 즉, 어떤 응용 프로그램이 메시지를 큐에 놓아두면, 다른 응용 프로그램이 그를 읽어가는 방식인 거죠. 현재 Queue를 사용하기에 가장 적합한 곳은 그림 4에서 보이는 것과 같이 Web Role 인스턴스가 Worker Role 인스턴스와 통신하는 경우입니다.
그림 4: 큐는 일반적으로 Web Role 인스턴스가 Worker Role 인스턴스와 통신할 수 있도록 하기 위해서 사용된다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding04.png
예를 들어, 동영상을 공유하는 Windows Azure 응용 프로그램을 만들었는데, 이 응용 프로그램은 사용자가 동영상을 업로드하고 시청할 수 있게 하는 PHP 코드로 개발된 Web Role과 업로드된 동영상을 다양한 포맷으로 변환하는 C#으로 구현된 Worker Role로 구성되어 있다고 가정해 봅시다. 그리고, 다음과 같은 방식으로 응용 프로그램이 동작한다고 가정해 보아요. 일단, 사용자가 새로운 동영상을 Web Role 인스턴스로 업로드 하게 되면, 우선 Blob에 동영상을 저장한 다음, 방금 업로드된 따끈따끈한 동영상을 어디서 찾을 수 있는지 알려주는 메시지를 큐를 통해서 Worker Role에게 전달하는 겁니다. 그러면, Worker Role은 큐로부터 그러한 메시지를 읽고 요청된 동영상의 변환을 백그라운드에서 수행하는 것이죠. 이런 방식으로 응용 프로그램을 구성하게 되면 비 동기 처리가 가능할 뿐만 아니라, 응용 프로그램을 확장하는 것도 대단히 쉽습니다. 수많은 Web Role 인스턴스와 Worker Role 인스턴스가 독립적으로 동작할 수 있으니까요.
서비스 버스(Service Bus)
큐에 더해서, Windows Azure는 서비스 버스도 지원하고 있습니다. 서비스 버스는 클라우드 안에서 소프트웨어를 연결하는 좀 더 일반적인 접근 방식이라고 볼 수 있는데요. 사실, 서비스 버스도 내부적으로는 큐 서비스를 제공하고 있어요. 하지만, 이 큐 서비스가 앞서 설명한 Queue를 말하는 것은 아닙니다. 둘은 차이가 많아요(둘 사이의 차이점을 자세히 알아보고 싶다면 http://msdn.microsoft.com/en-us/library/hh767287(v=vs.103).aspx를 참고하세요). 서비스 버스는 일반적으로 그림 5에서 보여지는 것과 같이 서로 다른 응용 프로그램을 연결하는 경우에 사용됩니다.
그림 5 : 서비스 버스는 큐를 통해서 혹은 직접적으로 응용 프로그램 간에 통신을 할 수 있게 합니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding05.png
서비스 버스를 통해서 통신하는 응용 프로그램은 Windows Azure 응용 프로그램 이거나 어떤 다른 클라우드 플랫폼에서 구동되는 소프트웨어일 수도 있습니다. 또는, 클라우드 외부에서 구동되는 응용 프로그램일 수도 있겠죠. 하지만, 자체 운영하는 데이터센터 안에 들어있는 컴퓨터에 예약 서비스를 구현해 놓은 항공사를 한번 생각해 봅시다. 이 항공사는 그들의 서비스를 다양한 클라이언트들(예를 들면, 공항에 있는 체크인 키오스크나 예약 에이전트 단말기, 또는 고객의 핸드폰 등)에 노출해야 할 필요가 있을 겁니다. 바로 이런 경우에 서비스 버스를 사용할 수 있습니다. 다양한 응용 프로그램 간에 느슨하게 연결된 상호작용을 제공하기 위해서 말이죠.
서비스 버스는 Windows Azure Queue와는 달리 [게시(publish)]와 [구독(subscribe)] 메커니즘을 제공합니다. 어떤 응용 프로그램은 하나 이상의 토픽으로 메시지를 보낼 수 있고, 다른 응용 프로그램은 특정 토픽으로 전달된 메시지만을 가져올 수 있습니다. 이로써 수 많은 응용 프로그램 사이에서 유연한 일-대-다(one-to-many) 통신이 가능해 지는 것이죠. 또한, 서비스 버스는 큐 방식만을 사용할 수 있는 것이 아닙니다. 방화벽을 통해 상호작용하도록 안전한 통신을 제공하는 릴레이(relay) 서비스를 통해서 직접적인 통신도 지원을 합니다.
다음 강좌에서 계속...
:{3} 
({4})