Windows Azure에 대해서 알아보자 (part 2)
목차
네트워킹(Networking)
Windows Azure는 현재 8 개(2012년 6월 현재)의 데이터 센터에서 돌아가고 있습니다. 미국에 4개(최근에 2개 추가되었죠), 유럽에 2개, 아시아에 2개가 있죠. 여러분이 Azure를 사용할 경우, 여러분은 응용 프로그램을 실행시킬 데이터 센터를 6 군데 중에서 선택할 수 있습니다. Windows Azure는 이러한 데이터 센터들 간에 요청을 전달하기 위해서 트래픽 관리자(Traffic Manager)를 제공하고 있기도 합니다. 또한, 자체 온-프레미스 서버에서 특정 데이터 센터에 존재하는 응용 프로그램에 연결하기 위해서, Azure는 Connect(연결) 서비스도 제공합니다. 이번 절은 이러한 기술들에 대해서 살펴보도록 할게요.
트래픽 관리자(Traffic Manager)
일부 지역의 몇 안 되는 사용자들이 이용하는 응용 프로그램은 아마도 단일 데이터 센터 안에서 해당 Role 인스턴스를 실행해도 충분할 겁니다. 하지만, 전 세계적으로 수 많은 사용자들이 이용하는 응용 프로그램은 다양한 데이터 센터에서, 가급적 8 군데(2012년 6월 현재) 모두에서 Role 인스턴스를 실행하는 것이 효과적일 거에요. 대부분의 경우, 여러분은 각각의 사용자들이 그들에게서 가장 가까운 데이터 센터로 접근하게 되기를 바랄 겁니다. 당연히 그게 가장 빠를테니까요. 하지만, 특정 데이터 센터에 놓여진 응용 프로그램이 과부하 걸려서 멈춰버리면 어떻게 될까요? 그런 경우에는 사용자들이 자동으로 다른 데이터 센터로 연결될 수 있으면 좋을 겁니다. 그렇죠? 바로 그런 역할을 Windows Azue의 트래픽 관리자가 한다는 것이에요. 멋지죠? 그림 6은 이러한 모습을 보여주고 있어요.
그림 6 : 만일, 응용 프로그램이 여러 데이터 센터에서 실행되고 있다면, Windows Azure 트래픽 관리자가 중간에서 현명하게 사용자의 요청을 조율합니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding06.png
응용 프로그램 작성자는 사용자 요청이 데이터 센터로 어떻게 전달되어야 하는 지를 정의할 수 있어요. 그리고 나면, 트래픽 관리자가 그러한 규칙을 수행해 주는 겁니다. 예를 들어, 사용자는 일반적인 경우 가장 가까운 Windows Azure 데이터 센터로 접근하게 될 겁니다. 하지만, 그 데이터 센터의 응답 시간이 허용 범위를 넘어선다면, 다른 데이터 센터로 보내지게 되는 것이죠. 수많은 사용자가 사용할 범 세계적인 응용 프로그램을 계획하고 있다면, 이러한 문제를 알아서 해결해주는 내장 서비스가 있을 경우 대단히 유용할 겁니다. 바로 Azure 플랫폼 말입니다.
연결(Connect)
Windows Azure 응용 프로그램 작성자의 또 다른 고민거리는 자체 온프레미스 시스템과 연결하는 것입니다. 예를 들어, Windows Azure에서 실행되는 응용 프로그램을 작성하고 있지만, 이 응용 프로그램이 사용하는 데이터는 자체 조직 내 윈도우 서버 안에 있는 데이터베이스에 저장되어 있다고 가정해 봅시다. 이런 경우에는 어떻게 해야 할까요? 바로 이런 경우를 위해서 Windows Azure는 연결(Connect) 서비스라는 것을 제공합니다. 그림 7에서 보이는 것과 같이 말이죠.
그림 7 : Windows Azure의 Connect는 온프레미스 서버와 Windows Azure 응용 프로그램 사이에 안전한 링크를 매우 쉽게 맺을 수 있도록 합니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding07.png
Connect는 Windows Azure 응용 프로그램과 윈도우 서버를 구동하는 컴퓨터 사이에 안전한 IPSec 연결을 맺을 수 있도록 하는 간결한 방안입니다. 개발자는 단지 온프레미스 서버에 Connect 소프트웨어를 설치하고(네트워크 관리자를 부를 필요도 없습니다), Windows Azure 응용 프로그램의 설정을 조정하기만 하면 됩니다. 그렇게 하고 나면, 응용 프로그램은 그 컴퓨터와 직접적으로 통신을 할 수 있게 되요. 마치 동일한 로컬 네트워크에 존재하는 것처럼 해당 머신에 있는 데이터베이스에 접근할 수도 있다는 것이죠.
Caching(캐싱)
응용 프로그램은 동일한 데이터를 반복해서 접근하곤 합니다. 성능을 향상시키는 한가지 방법은 그 데이터를 응용 프로그램 가까이에 캐시하여 데이터를 가져오는 시간을 최소화 하는 것입니다. Windows Azure는 2 가지 유형의 캐시 서비스를 제공하고 있는데요. 하나는 Windows Azure 응용 프로그램에서 사용되는 데이터를 메모리 상에 캐시하는 in-memory 캐싱이고요. 다른 하나는 사용자에게 가까운 디스크 상에 blob 데이터를 캐시하는 것입니다.
In-Memory 캐시(Caching)
Windows Azure의 데이터 관리 서비스(SQL Azure, Table, 또는 Blob)에 저장되어 있는 데이터에 접근하는 것은 상당히 빠릅니다. 그렇다 해도, 당연히 메모리 상에 저장되어 있는 데이터에 접근하는 것만큼 빠르지는 않겠죠. 그렇기에, 자주 접근하는 데이터를 메모리에 복사해두는 것은 응용 프로그램의 성능을 향상시킬 수 있는 지름길입니다. 그리고, 그를 위해서 Windows Azure는 그림 8에서 보이는 것과 같이 In-Memory 캐시를 지원하고 있습니다.
그림 8 : In-Memory 캐시를 사용하면, Windows Azure 응용 프로그램이 자주 사용되는 데이터에 빠르게 접근할 수 있습니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding08.png
응용 프로그램은 캐시에 데이터를 저장할 수 있고, 데이터베이스와 같은 영속적인 저장소에 접근하지 않고도 데이터를 바로 가져올 수 있습니다. 더 나은 성능과 신뢰성을 위해서, 캐시는 분산 서비스로 구현되어 있습니다. 즉, 데이터가 Windows Azure 데이터 센터에 속해 있는 수많은 컴퓨터에 넓게 퍼져 있다는 것이죠.
예를 들면, 제품 카탈로그를 반복적으로 읽는 응용 프로그램은 In-Memory 캐시를 사용하면 꽤나 이익을 볼 수 있을 겁니다. 필요한 데이터를 훨씬 빠르게 사용할 수 있을테니까요. Azure가 제공하는 캐시 기술은 잠금 기능도 지원합니다. 즉, 읽기/쓰기가 가능한 것 뿐만 아니라 읽기 전용 방식도 지원한다는 의미입니다. 그리고, ASP.NET 응용 프로그램은 구성 설정이 변경되는 경우에 세션 데이터를 저장하기 위한 용도로 캐시를 사용할 수도 있을 겁니다.
CDN(Content Delivery Network)
전 세계의 사용자들이 이용하게 될 가능성이 높은 Blob 데이터를 저장할 필요가 있다고 가정해 봅시다. 예를 들면, 이는 최근의 월드컵 경기 동영상이거나 소녀시대의 신곡(응?), 혹은 최신 드라이버 업데이트일 수 있고요. 또는 유명한 e-book 일수도 있을 겁니다. 그러한 전 세계적인 데이터의 복사본은 전 세계의 Windows Azure 데이터 센터 전부(현재는 8 곳)에 저장해두는 것이 좋을 겁니다. 하지만, 정말 아주 엄청나게 많은 사용자가 데이터에 접근한다면, 그것만으로는 부족할 수도 겠죠. 그런 경우에는 더 나은 성능을 제공하기 위해서, 그림 9에서 보이는 것과 같이 Windows Azure CDN을 사용하는 것을 고려해볼 수 있습니다.
그림 9 : Windows Azure CDN은 세계적으로 아주 많은 위치에 blob의 복사본을 저장합니다. 다양한 국가의 사용자들이 좀 더 빠르게 blob에 접근할 수 있도록 말이죠.
출처 : http://www.windowsazure.com/media/net/chappell_understanding09.png
CDN은 세계적으로 대단히 많은 사이트를 가지고 있습니다. 각각의 CDN 사이트는 Windows Azure 블랍(blob)의 복사본을 저장하는 역할을 합니다. 어떤 나라의 사용자가 처음 특정 blob에 접근하게 되면, 그러한 정보와 데이터가 Windows Azure 데이터 센터에서 사용자와 지리적으로 가까운 곳에 위치한 CDN 지역 저장소로 복사됩니다. 그 다음에 같은 나라의 사용자가 또 접근하게 되면 그때부터는 지역 CDN에 캐시된 복사본이 사용되는 것이죠. 더 이상 사용자가 가장 가까운 Windows Azure 데이터 센터로 찾아갈 필요가 없게 되는 겁니다. 캐시되는 데이터에는 만료시간을 설정할 수도 있어서, 일정 시간이 지나면 새로운 복사본이 CDN 지역 저장소로 전송되도록 구성할 수도 있습니다. 결과적으로, 전 세계 어디에서나 사용자가 자주 접근하는 데이터는 더욱 빠르게 접근할 수 있게 되는 것이죠.
고성능 컴퓨팅(HPC, High-Performance Computing)
클라우드 플랫폼이 주는 가장 큰 매력 중 하나는 바로 병렬 처리(parallel processing)입니다. 일반적으로 HPC 즉, 고성능 컴퓨팅이라고 알려져 있는 이 방식은 동시에 수 많은 머신에서 코드를 실행시키는 것을 말합니다. Windows Azure의 입장에서 바라보면, 이는 동시에 수 많은 Role 인스턴스를 실행시킨다는 것을 의미합니다. 즉, 어떤 과제를 해결하기 위해서 모든 인스턴스가 병렬로 작업을 수행한다는 것이죠. 하지만, 이것이 가능하려면, 응용 프로그램을 스케줄링하기 위한 어떤 방법이 필요하게 됩니다. 즉, 작업을 여러 인스턴스에 걸쳐 분배할 수 있어야 한다는 것이죠. 바로 이러한 부분을 지원하기 위해서 Windows Azure는 HPC 스케쥴러를 제공하고 있는데요. 그림 10은 HPC 스케쥴러의 간단한 구성을 보여주고 있습니다.
그림 10 : HPC 스케쥴러는 수 많은 Role 인스턴스에서 동시에 실행되는 병렬 응용 프로그램의 일정을 조절하는 역할을 합니다.
출처 : http://www.windowsazure.com/media/net/chappell_understanding10.png
이 서비스는 산업 표준 MPI(Message Passing Interface , 메시지 전달 인터페이스)를 사용하여 구축된 HPC 응용 프로그램과도 잘 동작합니다. 자동차 충돌 시뮬레이션과 같이 유한 요소 분석(FEA, finite element analysis)을 수행하는 소프트웨어가 이러한 유형의 응용 프로그램 중 하나이며, 그 밖에도 상당히 많은 예들이 존재하고 있습니다. HPC 스케쥴러는 또한 몬테 카를로 시뮬레이션과 같이 소위 [처치 곤란 병렬(embarrassingly parallel)] 부하를 다루는 응용 프로그램과도 사용될 수 있습니다. 어떠한 문제를 마주하게 되던지 간에, 이 구성요소가 제공하는 것은 항상 동일합니다. 즉, 수 많은 Windows Azure Role 인스턴스에 걸쳐 병렬 컴퓨팅 작업의 스케쥴을 조정하는 복잡한 문제를 처리해 준다는 것입니다.
상거래(Commerce)
SaaS(Software as a Service)가 주목을 받으면서 응용 프로그램을 만드는 방식이 바뀌어 가고 있을 뿐만 아니라, 응용 프로그램을 판매하는 방법도 바뀌어 가고 있습니다. SaaS 응용 프로그램은 클라우드 안에 존재하기 때문에, 잠재적 고객들도 온라인 상에서 해답을 찾아야 하는 상황이 되는 것은 당연합니다. 이러한 변화는 응용 프로그램 뿐만 아니라 데이터에도 적용됩니다. 그러니, 사람들이 상업적으로 이용 가능한 데이터들을 찾기 위해서 클라우드를 살펴보는 것은 당연하지 않을까요?
마이크로소프트는 이에 대한 대답으로 Windows Azure 마켓플레이스를 제시하고 있습니다. 즉, 잠재적 고객들은 마켓 플레이스를 검색하여 자신에게 필요한 Windows Azure 기반의 응용 프로그램을 찾을 수 있고요. 원하는 것을 찾았다면, 응용 프로그램의 제작자를 통해서든 혹은 직접적으로 마켓플레이스를 통해서든 해당 응용 프로그램을 사용하겠다고 서명할 수 있습니다. 또한, 고객은 상업적인 데이터들(예를 들면, 인구통계 데이터나 재무 데이터 등)을 얻기 위해서도 마켓플레이스를 검색할 수 있습니다. 마음에 드는 데이터를 찾았다면, 해당 업체를 통해서든 혹은 직접적으로 마켓플레이스를 통해서든 데이터에 접근할 수가 있게 됩니다. 데이터를 제공하는 업체는 그러한 정보를 자체적으로 보유하고 있을 수도 있고, Windows Azure 상에 저장해 둘 수도 있습니다.
신원 증명(Identity)
신원 증명(Identity)을 다루는 것은 대부분의 응용 프로그램이 필수적으로 다루는 부분입니다. 사용자가 누구인지를 알아야만 응용 프로그램이 그 사용자와 어떻게 상호작용을 해야 하는지를 결정할 수가 있기 때문입니다. 이를 지원하기 위해서, 마이크로소프트는 Windows Azure 액티브 디렉토리를 제공하고 있습니다.
시간이 지남에 따라, 이러한 디렉토리 서비스는 광범위한 기존의 신원 증명 서비스를 포함하도록 확장될 것입니다. 하지만, 현재 제공되고 있는 서비스는 ACS(Access Control Service)로서, 이는 특정 신원 증명 문제만을 다루고 있습니다. 그 내용은 다음과 같습니다.
- ACS는 편리하게 Facebook, Google, Windows Live ID 및 그 밖의 유명한 인증정보 제공자로부터 신원 정보를 가져와서 응용 프로그램에서 사용할 수 있도록 도와줍니다. ACS를 사용하면, 각각의 인증 정보 제공자에서 사용되는 서로 다른 데이터 포맷과 프로토콜을 일일이 응용 프로그램에서 직접 다룰 필요가 없습니다. ACS가 그 모두를 단일 공용 토큰 포맷으로 변환해 주니까요.
- ACS는 응용 프로그램이 하나 이상의 액티브 디렉토리 도메인으로 로그인을 수행할 수 있게 합니다. ACS가 다양한 인터넷 신원 증명 제공자로부터 제공되는 신원 정보를 합리적으로 맞춰준 것과 마찬가지로, 기업 액티브 디렉토리 신원 증명에 대해서도 동일한 서비스를 제공할 수 있습니다. 예를 들면, SaaS 응용 프로그램을 제공하는 업체가 ACS를 사용하여 고객사의 사용자들에게 응용 프로그램에 대해 싱글 사인온(single sign-on)을 수행하도록 할 수 있습니다.
- ACS는 사용자의 신원 정보를 응용 프로그램의 외부에서 접근하거나 변환하려 할 때 따라야 할 규칙을 응용 프로그램의 소유자가 정의할 수 있도록 해 줍니다. 예를 들면, ACS는 접근 자체가 거부되도록 설정할 수 있을 뿐만 아니라 인증 정보를 응용 프로그램이 요구하는 특정 포맷으로 변환할 수 있습니다.
SDK
Windows Azure는 윈도우 서버 기반의 환경이긴 합니다만, .NET 만으로 제한되어 있지는 않습니다. 다시 말해서, 수 많은 다른 언어로도 Windows Azure 응용 프로그램을 개발할 수 있다는 것입니다. 마이크로소프트는 현재 .NET, Java, PHP 그리고 Node.js에 대해 각각의 언어에 특화된 SDK를 제공하고 있습니다. 또한, C++이나 Python과 같은 언어에 대해서도 기본적인 지원을 제공하는 Windows Azure SDK를 제공하고 있습니다. 이러한 SDK는 비주얼 스튜디오와 이클립스(Eclipse)와 함께 사용될 수 있으며, 마이크로소프트의 Windows Azure 웹 사이트(http://www.windowsazure.com/en-us/develop/net)나 Github 사이트(https://github.com/WindowsAzure)에서 구할 수 있습니다. Windows Azure는 또한 개발자가 기타 편집기나 개발 환경에서 사용할 수 있도록 명령줄 도구도 제공합니다. 여러분이 선호하는 언어와 도구가 무엇이던지 간에, Windows Azure는 관리 편의성과 신뢰성, 확장성 있는 플랫폼을 제공합니다.
Windows Azure 응용 프로그램을 만드는데 도움을 주는 것에 더하여, SDK는 또한 Windows Azure 서비스를 사용하지만 클라우드 외부에서 실행되는 응용 프로그램을 만드는 것에 대해서도 지원을 하고 있습니다. 예를 들면, Windows Azure의 Blob 서비스를 사용하지만 호스팅 업체에서 실행되는 응용 프로그램을 만들 수도 있고요. Azure 플랫폼의 관리 인터페이스를 통해서 Windows Azure 응용 프로그램을 자동으로 배포하는 도구를 만들 수도 있습니다.
이제 시작해 보아요
이제 여러분 모두 전반적인 큰 그림을 이해했으리라 생각합니다. 다음 단계는 직접 Windows Azure 응용 프로그램을 만들어 보는 것이겠죠? 좋습니다. 다음 강좌에서 그것을 한번 해보도록 할게요. 우선, 마음 속으로 프로그래밍 언어를 선택하시고, 그와 관련된 SDK를 다운로드 받아서 설치하세요. 개발도구로는 가급적 Visual Studio 가 있으면 더더욱 좋을 겁니다.
이제 시작해 보아요. 클라우드 컴퓨팅이 "디폴트"가 되고 있으니까요.
:{3} 
({4})