Apache Hadoop to a Windows Azure

저번에 블로깅(http://redju.tistory.com/128)에 이어 Developer Preview 메일을 받았습니다.

HadoopOnAzure.com에 로그인해서 좀 더 구체적으로 Apache Hadoop on Windows Azure를 살펴볼 수 있게 되었습니다.

직접 경험해보실 분들은 https://www.hadooponazure.com/ 사이트의 Invitation을 클릭해보십시오~

관련 링크는 아래를 참조하실 수 있습니다.

l General Overview: http://social.technet.microsoft.com/wiki/contents/articles/apache-hadoop-on-windows.aspx

l Apache Hadoop-based Services for Windows Azure How-To and FAQ Guide:http://social.technet.microsoft.com/wiki/contents/articles/apache-hadoop-based-services-for-windows-azure-how-to-and-faq-guide.aspx

l Microsoft Hadoop Distribution Documentation Plan: http://social.technet.microsoft.com/wiki/contents/articles/microsoft-hadoop-distribution-documentation-plan.aspx

How to를 통해서 처음 설정부터 Hadoop을 이용한 BI 내용까지 쭉 진행해보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure 에서의 비즈니스 연속성(Business Continuity)

BCP(Business Continuity Plan)에 대한 내용은 RTO, RPO에 대한 내용을 다루게 됩니다. 클라우드 환경에서는 BCP에 대한 내용은 어떻게 접근해야 할까요?

아래 링크를 참조하시면 SQL Azure에서의 비즈니스 연속성에 대한 내용에 대한 부분이 잘 정리된 것을 확인 가능합니다.

http://msdn.microsoft.com/en-us/library/hh852669.aspx

SQL Azure 데이터 보호

l 별도 서버나 장치

l 잘못된 삭제나 수정

l 데이터 센터 장비 문제

3가지 내용 중에서 잘못된 삭제나 수정에 대한 부분은 Copy Of 구문을 통해 구성할 수 있는데 SNAPSHOT 과 유사하며 COPY 백업과도 유사합니다.

데이터 센터 장비 문제로부터의 보호는 별도로 백업하는 것과 유사한 방법입니다.

BACPAC을 이용하는 것이죠, 차후 좀더 자세히 다루어보기로 하겠습니다만 예전부터 데이터 계층 응용프로그램과 데이터 내보내기/가져오기에서 계속 얘기했던 내용입니다.

위 링크의 아래 그림을 참고하십시오.

BACPAC을 Windows Azure Storage로 내보내기 하고 이를 다른 서버나 데이터 센터에서 가져오기를 해서 하거나 로컬 On-Premise의 SQL 서버로 가져오기 가능합니다.

BACPAC과 데이터 계층 응용프로그램에 대한 내용은 별도로 추가로 다루어보도록 하겠습니다. 또한 데이터 동기화 (SQL Azure Data Sync) 에 대한 내용도 다루겠습니다.

위 링크를 참조하시면 클라우드의 SQL Azure에서도 다양한 방법으로 비즈니스 연속성을 제공한다는 것을 알 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Apache Hadoop On Windows

Apache Hadoop On Windows 에 대한 위키 페이지는 아래를 참고하십시오.

http://social.technet.microsoft.com/wiki/contents/articles/6204.hadoop-based-services-for-windows.aspx

제한된 CTP에 대한 내용은 아래 링크를 클릭해서 등록하시면 됩니다.

https://connect.microsoft.com/SQLServer/Survey/Survey.aspx?SurveyID=13697

여러 링크가 있어 Hadoop에 대한 내용을 살펴볼 수 있을 것 같습니다.

Getting Started with Hadoop-based Services for Windows

•On-Premise Deployment of Hadoop-based Services for Windows

•Windows Azure Deployment of Hadoop-based Services for Windows

•Windows Azure Deployment of Hadoop-based Services on the Elastic Map Reduce (EMR) Portal

Windows Azure에 대한 내용은 얼른 구성을 해서 살펴보겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure 가격 변경 (2012년 2월)

SQL Azure의 경우 가격이 상당히 많이 인하되었습니다. 약 50% 가량 인하되었습니다.

또한 100MB 데이터베이스도 제공이 되어 테스트나 데모 등에 사용하면 비용 절감에 도움이 될 것 같습니다.

아래 링크를 참조하시면 보다 더 구체적인 가격 변경에 대한 내용을 알 수 있습니다.

http://blogs.msdn.com/b/windowsazure/archive/2012/02/14/announcing-reduced-pricing-on-sql-azure-and-new-100mb-database-option.aspx

GB	Previous Pricing	New Pricing	New Price/GB	Total % Decrease
5	$49.95	$25.99	$5.20	48%
10	$99.99	$45.99	$4.60	54%
25	$299.97	$75.99	$3.04	75%
50	$499.95*	$125.99	$2.52	75%
100	$499.95 *	$175.99	$1.76	65%
150	$499.95*	$225.99	$1.51	55%

현재까지는 Windows Azure Management Portal에서 데이터베이스 생성시 데이터베이스 선택에서 100MB 는 나오지 않았습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Q2 2011 Service Release

SQL Azure 에 대한 Service Release에 대한 내용을 정리합니다. 여러 가지 업데이트 된 것이 많이 있으니 참고하시기 바랍니다.

l SQL Azure의 @@version

SQL Azure 로 연결하여 @@version 을 확인해 보시면 11점대로 변경된 것을 확인 가능합니다. 제가 사용하는 SQL Server 2008 R2 는 버전이 10.50.1617.0 입니다만 SQL Azure의 버전을 실행한 결과는 아래와 같습니다.

l SQL Azure Import/Export Hosted Service CTP

Windows Azure Management Portal에 로그온 하면 아래와 같은 리본 메뉴를 보실 수 있습니다.

또한 관련 내용은 아래 링크를 참조하실 수 있습니다.

http://sqldacexamples.codeplex.com/wikipage?title=Import Export Service Client

이후 블로깅에서 보다 더 자세한 내용을 다루도록 하겠습니다.

l SQL Server Data Tools “Juneau”

새로운 SQL Server Data Tools 인 코드명 “Juneau” CTP가 7월에 릴리즈 되었습니다. Juneau 에서도 SQL Azure 에 대한 내용을 지원해주고 있습니다. 데이터베이스 디자인, 개체 생성과 편집 등을 SQL Azure 에도 진행할 수 있습니다.

또한 다음 블로깅에서 구체적으로 SQL Azure를 대상으로 알아보도록 하겠습니다.

l 관리도구(SSMS) 업데이트 필요할 수 있음

데이터센터의 업그레이드로 기존 관리도구(SSMS)의 업데이트가 필요할 수 있습니다. 혹시 연결에서 오류가 발생한다면 아래 주소를 참조해서 업데이트하시면 됩니다.

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26727

l SQL Azure Management Portal

Database Manager 도구는 사라질 예정이며 SQL Azure Management Portal 에서 새로운 작업을 진행할 수 있습니다. 아래 두 내용에 대해서 좀 더 구체적으로 다루도록 하겠습니다.

- 관리: Database Life Cycle

- 디자인: Database Schema and Data

l Spatial 데이터 형식

데이터 형식 지원이 더 강화되었습니다. 지원되는 데이터 형식과 spatial 데이터 형식에 대한 내용은 아래 링크를 참조하시기 바랍니다.

http://msdn.microsoft.com/ko-kr/library/windowsazure/ee336233.aspx

l 공동 작업자 관리

여러 명의 작업자를 지정할 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Data Sync (3) – 고려사항

SQL Azure Data Sync에 대한 고려사항을 한번 뽑아보았습니다.

l 비용

현재 SQL Azure Data Sync는 CTP2 이며 현재 시점에서는 별도 비용은 없습니다. SQL Azure Data Sync는 Hub 데이터베이스로 반드시 SQL Azure가 필요합니다. SQL Azure 데이터베이스의 비용은 제쳐두더라도 데이터 동기화 때문에 네트워크 트래픽이 발생하므로 트래픽 비용은 발생하게 됩니다.

l 데이터 형식

자세한 정보는 아래 주소를 참고하시면 됩니다.

http://social.technet.microsoft.com/wiki/contents/articles/1922.aspx

구분	내용
Exact Numbers	Supported: bigint, bit, decimal, int, money, numeric, smallint, smallmoney, tinyint.
Approximate Numbers	Supported: float, real.
Date and Time	Supported: date, datetime2, datetime, datetimeoffset, smalldatetime, time.
Character Strings	Supported: char, varchar, text.
Unicode Character Strings	Supported: nchar, nvarchar, ntext.
Binary Strings	Supported: binary, varbinary, image.
Spatial	Supported: no supported spatial data types
Other Data Types	Supported: sql_variant, table, uniqueidentifier, xml.
Spatial Data Types	Not supported: geography, geometry.
FileStream	Not supported
CLR UDT	Not supported
SQL UDT	Not supported
XML Data Types	Not supported: XmlSchemaCollection
Other Data Types	Not supported: cursor, timestamp, hierarchyid

l 백업과 복원

SQL Azure Data Sync 는 백업 용도는 아닙니다. 저장 프로시저와 같은 SQL 개체를 백업해주시는 않습니다. 속도도 빠르지 않습니다. 물론 복원도 마찬가지 입니다.

l 데이터 보안

데이터 암호화: 암호화된 연결이 기본

데이터 액세스 인증: SQL 계정만 지원

에이전트 인증: HTTPS로 통신, Management Portal에서 생성된 토큰을 통해 인증

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Data Sync (2) – Sync Group

전 편에 이어 Sync Group을 생성해서 SQL Server - SQL Azure로 동기화를 해보도록 하겠습니다.

SQL Azure Data Sync CTP2 에 로컬의 데이터베이스를 등록했으며 이제 SQL Azure를 등록하도록 하겠습니다.

Sync Group은 SQL Azure Data Sync Service에 의해 상호 동기화되도록 구성된 SQL Azure와 SQL Server 데이터베이스의 모음으로 볼 수 있습니다. 하나의 HUB 데이터베이스(SQL Azure 데이터베이스)와 여러 Member 데이터베이스로 구성되어 있습니다.

자 로컬의 Demo 데이터베이스와 동기화 하기 위해 SQL Azure 데이터베이스에 연결하여 빈 데이터베이스를 생성합니다.

로컬의 데이터베이스는 SQL Azure Sync Services를 통해 등록하고 SQL Azure 데이터베이스는 SQL Azure Data Sync CTP2 사이트를 통해 등록합니다. SQL Azure Data Sync CTP2 사이트에서 Databases 탭을 클릭하고 Add를 클릭해서 위에서 생성한 SQL Azure Database를 등록합니다.

등록 정보가 이상 없다면 아래와 같이 등록된 것을 확인 가능합니다.

여러 데이터베이스를 등록할 수 있지만 여기서는 SQL Azure, SQL Server 데이터베이스 두 개만 등록합니다. 이제 Sync Group을 생성해보도록 하겠습니다.

SQL Azure Data Sync CTP2 사이트에서 Sync Groups 탭을 클릭하고 New Sync Group를 클릭해서 위에서 SQL Azure Database를 등록합니다.

New Sync Group의 이름은 “HJ” 로 입력하고 Registered Databases 를 통해 등록된 데이터베이스를 추가합니다. 그리고 SQL Azure 데이터베이스 중 하나를 선택해서 “Set HUB”를 클릭해서 Hub 데이터베이스로 지정합니다.

Next 를 클릭해서 동기화할 테이블과 스케쥴링을 아래와 같이 설정합니다. 동기화할 테이블은 하나만 있으며 시간은 5분으로 지정하겠습니다.

아래와 같이 새로운 Sync Group 이 생성된 것을 확인 가능합니다.

Sync Logs 에 보면 진행, 대기, 완료한 작업 등을 알 수 있으며 처음 동기화 작업이 처리된 것을 확인 가능합니다.

실제 SQL Azure Hub 데이터베이스를 보면 아래와 같이 테이블 스키마와 데이터가 동기화된 것을 확인 가능합니다.

n SQL Azure

기본적으로 변경 사항은 양 방향성격으로 Member 데이터베이스로부터의 변경 사항은 hub 데이터베이스로 전파되고 Hub 데이터베이스에서 Member 데이터베이스로 다시 전파되게 됩니다. 변경 사항의 전파는 Bi-directional, Sync to Hub, Sync from Hub 중에서 선택이 가능합니다.

위의 환경에서는 Hub 데이터베이스가 또한 Member 데이터베이스이므로 데이터를 Update 해보겠습니다. 스케뷸링 시간이 되면 아래와 같이 변경된 것을 확인 가능합니다.

n Local SQL Server

Hub 데이터베이스에서는 추적을 위해 아래와 같이 몇몇 테이블이 자동으로 생성되게 됩니다.

데이터베이스를 추가하거나 스케쥴링 시간을 변경할 수도 있으며 Sync Group을 삭제할 수도 있습니다.

이번 글에서 SQL Server to SQL Azure Synchronization 에 대한 Sync Group 생성과 데이터 동기화의 설정에 대한 내용을 정리했습니다. 괜찮은 기능으로 보입니다. 속도,비용 등등 고려사항은 별도로 보더라도

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

요즈음 클라우드 서비스들을 이용하다보면, Windows 서버 운영체제를 통해서 확장성있는 클라우드를 만들고자 하는 경우가 자주 있습니다. 일반적인 웹 사이트를 구축할 때에도 마찬가지이고, 당연히 KT UCLOUD나 Amazon과 같은 환경에서도 같은 노력이 뒷받침이 되어야 하지요. 그리고 제가 주 전공으로 하고 있는 Windows Azure 역시, 첫 배포 때에는 간과하기 쉬운 점이 바로 로드 밸런싱 환경이라는 점입니다.

이러한 로드밸런싱 환경을 만들때에는, 이전에 구축해본 경험이 없는 관리자가 개발자 입장에서는 상당히 어려운 문제에 봉착하게 될 가능성이 많습니다. 특히 요즈음 웹 환경에서는 당연하게 사용하는 세션이나 쿠키에 관련된 설정들이 로드밸런싱 환경에서 기대했던 것과 다르게 동작해서 좌절하는 경험을 많이들 하실텐데요, 제가 오늘 블로그에 올리는 것은 ASP.NET에 관한, 그리고 IIS 7에 관한 내용입니다. (PHP나 JSP 개발자분들께서도 공감하실 수 있는 부분이 있을 것입니다.)

로드밸런싱 환경을 잘 알고 구축할 수 있다면, 앞으로 나오게될 어떤 종류의 클라우드 서비스이든 관계없이 문제를 정확하게 해결할 수 있을 것입니다. 사실 클라우드 기반의 웹 서비스는 달리 표현하면, 기본 골자는 로드밸런싱에 기반을 두고 있는 것이고, 그 이후의 확장성 전략을 클라우드 솔루션으로 채우는 것과 같다고 말할 수 있습니다. (어떤 뼈대를 사용할 것인지는 전적으로 여러분들의 선택에 달린 것입니다.)

로드 밸런싱 환경이란?

로드 밸런싱 기술 자체는 상당히 오래된 것입니다. 이름에서 알 수 있듯이, 몰려오는 트래픽을 내부적으로 분산하여 특정 서버 컴퓨터로 연결이 몰려 서비스가 사용 불가 상태로 빠지는 것을 "지연"시키거나 "완화"시키는 것에 목적이 있습니다. 로드 밸런싱의 기술적 개념도는 다음과 같습니다. (이미지 출처: http://msdn.microsoft.com/en-us/library/ff650667.aspx)

다양한 상황에서 로드밸런싱이 쓰이겠지만 가장 일반적으로는 웹 환경에서 많이 쓰입니다. 연결을 오래 유지할 필요가 없으면서도, 짧은 시간 내에 빠른 연결 회전을 보이는 웹 프로토콜에서 가장 중요한 것은 바로 신속성인데, 분산 처리를 하지 않는 경우에는 필연적으로 서버 컴퓨터가 받아들일 수 있는 동시 연결 한계치에 금방 치닫게 됩니다. 그러나 로드 밸런싱을 정확히 사용하면 이러한 한계치에 치닫게 되는 속도가 로드 밸런싱에 참가하는 컴퓨터의 댓수만큼 반비례하게 됩니다. 그리고 이 때 하나의 웹 사이트를 위한 로드 밸런싱 서비스에 멤버로 참여하는 서버 컴퓨터들을 묶어서 "웹 팜"이라고 정의를 하는 것이지요. 더 일반적으로는 "서버 팜"이라고도 합니다.

잠시 다른 이야기로 넘어가자면, 요즈음 대두되는 클라우드 컴퓨팅은 관리 측면에서 봤을 때, 충분한 대역폭을 보장하는 연결과 매우 뛰어난 성능을 가진 로드 밸런서를 이용하여 연결을 분산하는 작업을 수행하는 것입니다. 그리고 웹 팜 안에 참여하는 컴퓨터의 유형에 있어서는 이전과 다른 점이 하나 있는데, 마치 구름과 같이 수축과 팽창을 자유자재로 한다는 것입니다. 물론 이런 수축과 팽창이 가능함은 내부적으로 가상화 솔루션을 이용했다거나 여기에 대응할 수 있는 알고리즘을 사용했다는 가정이 깔려있는 것입니다.

정말 완벽하고 정확하게 구축했다면, 적은 전원이나 자원 공급으로도 충분히 웹 팜이 유지가 될 수도 있고, 필요하다면 웹 팜의 크기가 엄청나게 커질 수도 있겠지요. 이걸 여러분이 관리하신다면 프라이빗 클라우드, 신뢰할 수 있는 IT 기업이 관리한다면 퍼블릭 클라우드가 된다고 보실 수 있겠습니다. 그러나, 클라우드 컴퓨팅이 만능약처럼 들릴 수 있는 부분이 있지만 정확히 알아야 할 것은 클라우드 컴퓨팅 역시 이 로드 밸런싱을 기초로 만들어지는 것이고, 여러분이 운영할 수 있는 한계에까지 트래픽이 몰리거나, 이런 일을 하는 IT 업체에게 지불할 수 있는 재정의 한계에까지 트래픽이 몰린다면 이것이 여러분이 생각할 수 있는 클라우드의 한계입니다. 무제한이라고 해서 값이 저렴하거나 무료에 수렴하는게 아님을 명확히 이해하고 있어야 합니다.

웹 로드 밸런싱을 위한 이야기

다시 본론으로 돌아와서, 웹을 로드 밸런싱할 수 있으려면 무엇을 검토해야 할까요? 가장 중요한 것은 웹 서버에 참여하는 각각의 컴퓨터 자체에는 "절대로" 컴퓨터의 고유한 정보를 가지고 있으면 안된다는 점입니다. 매우 단순한 이야기같지만 이러한 원칙을 지키지 않도록 설계되어있는 것이 지금 이 시점까지의 서버 컴퓨팅 기술들의 대다수의 원칙입니다. 간단한 예를 들어볼까요?

여러분이 일상적으로 사용하는, 웹을 통한 파일 업로드 기능을 담당하는 간단한 웹 앱이 있다고 가정해 보겠습니다. 이 웹 앱은 서버가 한 대 일때에는 참 쉽고 빠르게 설치해서 쓸 수 있었습니다. 당연히, 설치를 잘 했다면, 사용자가 웹 페이지를 방문해서 파일을 업로드하면 웹 서버가 그것을 알아보고 파일을 회수해서 하드 디스크 어딘가에 저장하겠지요. 그러나 시간이 지나서 이 웹 앱의 기능을 업그레이드하고 좀 더 많은 사용자들이 파일을 저장하고 다운로드할 수 있도록 만들어보고자 해서 로드 밸런싱 환경을 구축하여 베타 테스트를 시작했습니다. 그런데 어떤 문제들이 생겼을까요?

앞서 이야기한 기술적인 특성때문에, 사용자들은 분명히 조금전까지 파일을 업로드했었는데 페이지를 다시 와서보니 파일이 업로드되지 않은 상태로 페이지가 나와서 혼란스러워합니다. 혹은 파일을 어디로 빼돌린거냐며 분노하는 사람들도 있구요. 그래서 몇 번 F5키를 누르다보면 "어라?"하고 놀라게 됩니다. 조금 전에 업로드했던 파일이 다시 나타나니까요. 그러고나서 그 파일을 다운로드하려고 링크를 클릭하면 이번엔 또 다시 404 오류를 만납니다. 이제 사용자들은 이 서비스에 대해서 대단한 분노와 원성을 쏟아낼 것입니다. 서비스 상태에도 일관성이 없을 뿐 아니라 불안정한것 같다. 믿을 수 없다면서요.

이것이 일선 IT 현장에서 로드 밸런싱이나 클라우드를 처음 접목했을 때 겪는 "가장 흔하고 일반적인 장애"입니다. 더 안타까운 것은, 이것을 신 기술에 의한 책임으로 회피하고 문제시하는 것입니다. 문제의 본질을 정확히 알고 있다면 이렇게 말하는 것이 왜 잘못인지도 금방 알 수 있을 것입니다.

여기서 든 예제처럼, 이 웹 앱의 문제는 단순히 업로드한 파일을 자신의 컴퓨터에 저장하려고 했다는 데에 문제가 있습니다. 로드 밸런싱 멤버로 참여하는 컴퓨터가 자신의 상태를 중요하게 여기면, 다음번에 이어받는 다른 서버 컴퓨터의 입장에서는 이전에 그 컴퓨터가 무엇을 했는지 알 길이 없습니다. 그저, 찾고자 하는 내용이 없음을 이야기하는 수 밖에 없습니다. 이런 상황이 반복되면서 서비스 전체는 들어올때와 나갈때가 전혀 다른, 일관성이 없고 이상한 서비스가 되는 것입니다.

이 문제를 해결하기 위하여 어떻게 수정해야 할까요? 답은 간단합니다. 파일 저장소를 로드 밸런싱 멤버 컴퓨터 내부가 아닌, 여러 멤버 컴퓨터들이 같이 이용할 수 있는 공용 저장소로 바꾸는 것입니다. 가장 간단한 방법은 네트워크 UNC 경로로 이용할 수 있는 스토리지가 있을 수 있습니다.

여기서 궁금한 점이 하나 더 있는데, 그렇다면 로드 밸런싱에 의하여 애써 분산한 서비스가 다시 모이는 것이 아니냐고 반문할 수도 있습니다. 그런데 사실, 생각외로 사용자들이나 웹 크롤러와 같이 인터넷 상에서 발생하는 별 뜻없이 바쁘게 만드는 다양한 유형의 트래픽을 웹 팜 수준에서 한 번은 로드 밸런싱을 해주는 것 만으로도 실제 스토리지에 대한 요구 사항은 획기적으로 감소한다는 점입니다. 거기다, 역할 분담도 정확히 할 수 있으며 스토리지 자체에 대한 요구 사항이 폭증하는 것을 방지하기 위하여 기술적으로는 좀 더 복잡해질 수 있지만 캐싱 기능을 사용할 수도 있습니다. 이렇게 함으로서, 우리가 흔히 잘 아는 클라우드 서비스의 시작을 뗄 수 있게 됩니다.

기술적인 이야기 1 - 세션 처리 방법 바꾸기

그렇다면 IIS와 ASP.NET에서는 이런 이상한 상황을 예방하고 신뢰할 수 있는 서비스를 만들기 위해서 어떤 수정 사항을 반영해야 하는 것일까요? 제가 이제까지 인터넷 상으로 자료 조사를 해왔던 것은 모두 제각기 흩어져있는 정보들이었고 이것을 한 번에 취합할 수 있는 방법을 오늘 블로그 포스팅을 통하여 소개할까 합니다.

기본적으로 ASP.NET은 세션 처리를 IIS 프로세스 안에서 수행하도록 되어있습니다. 가장 동선도 짧고, 신속하게 반응하기 때문입니다. 그러나 로드 밸런싱 환경에서 이는 당연히 "채택하면 안되는" 기법입니다. 이 방법은 web.config 파일 안의 <sessionState> 요소에서 변경할 수 있는 부분으로, <configuration> 요소 아래의 <system.web> 요소 아래에서 없는 경우 새로 지정할 수 있습니다. <sessionState> 요소의 mode 속성의 값을 변경하면 됩니다. 지금 이야기한 부분은 mode 속성이 InProc으로 지정되어있거나, 아무것도 지정되어있지 않을 때 .NET Framework의 글로벌 web.config 설정을 바꾸지 않은 경우 기본으로 지정되는 설정입니다.

IIS 7에서 볼 수 있는 아래 그림과 같은 설정도 이 XML 파일의 수정을 텍스트 에디터 없이 수정하는 것입니다.

로드 밸런싱 환경에서 정상적으로 동작하는 웹 사이트를 만들기 위해서는 mode의 설정 값을 InProc 대신 StateServer나 SQLServer로 바꾸어야 하는데, 양쪽 값 모두 장단점이 있습니다. StateServer의 경우 기본적으로는 꺼져있는 ASP.NET State Service라는 NT 서비스가 제공하는 별도의 서버를 이용하는 방식이고, SQLServer는 이름에서 알 수 있듯이 실제 SQL Server를 사용하여 세션을 구현하는 방식입니다. 데이터베이스 서버의 성능이 세션을 모두 수용할 수 있을만큼 획기적으로 뛰어나거나, 세션 서버가 죽었다가 살아나도 로그아웃 처리가 안되게 한다던가, 혹은 여러 로드 밸런싱 사이트 사이에서 세션 공유를 안전하게 할 방법이 필요하다면 이 모드를 사용할 수 있습니다. 이에 비하여 StateServer는 별도의 SQL 서버 없이도 간편하게 구축할 수 있는 방법을 제공하긴 하지만, 세션 서버가 죽었다 살아날 경우 내용이 없어지는 휘발성 세션입니다.

양쪽 모드 모두 중요한 것은 멤버로 참여하는 웹 서버 컴퓨터 밖에 상태를 보관해야 한다는 것이 키 포인트로, 이것을 지키지 않고 멤버 컴퓨터 안에 이런 설정을 구축하면 전혀 나아지는 것이 없습니다. 그리고 당연한 이야기이지만 멤버 컴퓨터로 참여하는 모든 웹 서버가 같은 설정을 가지고 있어야 합니다.

StateServer와 SQLServer 모드를 구현하는 방법에 대한 자세한 내용은 아래 아티클을 참고하시면 되겠습니다.

http://msdn.microsoft.com/ko-kr/library/ms178586.aspx

기술적인 이야기 2 - ASP.NET 사이트 간에 립싱크 맞추기

세션을 공유하는 것 이외에, ASP.NET은 내부적으로 Machine Key라는 것을 사용합니다. Machine Key의 용도는 ASP.NET 안에서 참 다양한데, 가장 대표적으로는 클라이언트와 서버 사이에 쿠키 정보를 주고 받을 때 암호화하기 위한 수단으로 이용하는 것이 유명한 사례입니다. 쿠키를 이용한 취약점 공격은 웹 세계에서 너무나 당연한 공격 방식 중 하나이기 때문에 ASP.NET은 처음부터 이를 보완하기 위한 전략을 구현하고 있었습니다. 그러나 이것이 지금 와서 로드 밸런싱 환경이 되면서는 또 다른 어려운 문제로 바뀐 것입니다.

이 Machine Key라는 것 역시 서버 컴퓨터마다 고유하게 생성할 뿐 아니라, 매번 연결할 때 마다 다른 값을 생성하여 암호화에 사용합니다. 클라이언트 입장에서야, 서버가 "ABC"라는 쿠키를 주니까 "아 그렇구나. 나중에 돌려주면 서버가 날 알아보겠지?"하며 성실하게 반납합니다. 그런데 로드 밸런싱에 참여하는 A라는 서버 대신 C라는 서버가 이 쿠키를 받아들었을 때는 "이거 내것 아님" 하며 클라이언트에게 퇴짜를 놓습니다. 이것이 문제의 핵심인 것이죠.

이 문제를 해결하기 위해서는 아까전에 이야기한 주제보다 좀 더 많은 노력이 필요합니다. 생각보다, 보안을 완벽하게 유지하기 위하여 ASP.NET이 관리자들에게 요구하는 사항이 까다롭기 때문입니다. 이 Machine Key를 만들기 위해서는 별도의 생성 도구를 사용해야 합니다. 그러나 안타깝게도 이 도구를 구한다거나 만들 수 있으려면 개발자들의 조력이 좀 필요합니다. 그리고 개발자 본인들도 이런 방법을 찾아야 하기때문에 꽤나 귀찮습니다. Codeproject에 가면 이러한 방법을 자세히 설명한 아티클도 있습니다만 간단한 도구도 드리고, 코드 조각도 드리니 프로그램에 넣어 활용하시면 더 편리할 것입니다.

using System;
using System.Text;
using System.Security.Cryptography;

/* 중략 */

        public static string getRandomKey(int bytelength)
        {
            byte[] buff = new byte[bytelength];
            RNGCryptoServiceProvider rng = new RNGCryptoServiceProvider();
            rng.GetBytes(buff);
            StringBuilder sb = new StringBuilder(bytelength * 2);
            for (int i = 0; i < buff.Length; i++)
                sb.Append(string.Format("{0:X2}", buff[i]));
            return sb.ToString();
        }

        public static string getASPNET20machinekey()
        {
            StringBuilder aspnet20machinekey = new StringBuilder();
            string key64byte = getRandomKey(64);
            string key32byte = getRandomKey(32);
            aspnet20machinekey.Append("<machineKey\n");
            aspnet20machinekey.Append(" validationKey=\"" + key64byte + "\"\n");
            aspnet20machinekey.Append(" decryptionKey=\"" + key32byte + "\"\n");
            aspnet20machinekey.Append(" validation=\"SHA1\" decryption=\"AES\"\n");
            aspnet20machinekey.Append("/>\n");
            return aspnet20machinekey.ToString();
        }

        public static string getASPNET11machinekey()
        {
            StringBuilder aspnet11machinekey = new StringBuilder();
            string key64byte = getRandomKey(64);
            string key24byte = getRandomKey(24);

            aspnet11machinekey.Append("<machineKey");
            aspnet11machinekey.Append(" validationKey=\"" + key64byte + "\"\n");
            aspnet11machinekey.Append(" decryptionKey=\"" + key24byte + "\"\n");
            aspnet11machinekey.Append(" validation=\"SHA1\"\n");
            aspnet11machinekey.Append("/>\n");
            return aspnet11machinekey.ToString();
        }

위의 코드를 사용하여 프로그램을 만들거나 ZIP 파일 안의 프로그램을 이용하여 값을 만들도록 하면 아래와 같은 XML 코드 조각을 얻을 수 있을 것입니다. 이 코드 조각을 각각의 서버에 들어있는 web.config에 지정하거나, 특정한 값만 인용하여 아래의 IIS 7 설정 아이콘에서 볼 수 있는 설정 도구를 통해서 직접 설정할 수도 있습니다.

<machineKey
 validationKey="FACBB6C89C44CB8BB7165FC4639BAA7267B...EF297D815E1BDD40E883E3451628CB95D34309"
 decryptionKey="4E95057676CC8DBA9AB...AACC1121B6B962E5AFA7849B0C82"
 validation="SHA1" decryption="AES"
/>

기술적인 이야기 3 - IIS에서 놓치면 안되는 것

ASP.NET을 가장 먼저 사용할 수 있게 된 웹 서버가 IIS이다보니 발생한 일종의 특성입니다만 여러 포럼에 걸쳐서 잘 언급되지 않는 문제점이 하나 있습니다. 바로 IIS에서 사용하는 사이트 ID 값을 통해서 정해지는 Application Path를 Machine Key와 같이 활용된다는 사실입니다. 웹 사이트 관리를 하다보면 로드 밸런싱에 참여하는 컴퓨터들을 다음과 같이 관리하게 되는 경우가 있습니다.

• 서버 A에서는 기본 웹 사이트를 먼저 지우고 새 웹 사이트를 만들었다.
• 서버 B에서는 새 웹 사이트를 먼저 만들고 기본 웹 사이트를 지웠다.

혹은 아래와 같은 경우도 있을 수 있습니다.

• 서버 C에서는 사이트 A를 만들고 사이트 B를 만들었다.
• 서버 D에서는 사이트 B를 만들고 사이트 A를 만들었다.

별 차이 없이 생각할 수 있지만, IIS에서는 이 경우 각각의 사이트들에 다른 ID 값을 부과하게 됩니다. 이 경우, 분명히 Machine Key를 동일하게 지정했음에도 불구하고 로드 밸런싱 환경에서 세션 상태가 일관성없게 변하는 문제를 만나게 됩니다. 제가 이번에 고민하게 된 부분도 바로 이 부분이었는데요, 이 문제를 해결하기 위해서는 IIS 7에서 전체 웹 사이트 목록에 나타나는 내용 중 다음의 ID 값이 멤버로 참여하는 웹 서버마다 차이가 있지 않은지 우선 검토해야 합니다.

위에있는 그림에서 빨간색으로 그린 부분이 서버 컴퓨터마다 차이가 있다면 이 값을 수정해주어야 합니다. 이 값을 수정하기 위해서는 수정할 사이트를 클릭하고, 고급 설정 링크를 아래 그림과 같이 클릭합니다.

이제 아래와 같은 팝업 대화 상자가 나타나면 강조 표시한 속성인 ID 값이 멤버로 참여하는 웹 서버 모두 같은 값을 가질 수 있도록 통일시켜줍니다.

확인 버튼을 누른 다음, ID 값이 바뀐 서버 컴퓨터에 한해서 IIS 전체를 재시작해주시거나 사이트 재시작을 시켜주시면 정상적으로 작동하게 될 것입니다.

Windows Azure 환경에서의 고려 사항

오늘 살펴본 내용은 IIS 7과 ASP.NET에 관한 부분이었지만, Windows Azure Platform의 경우에도 비슷한 문제가 있습니다. Windows Azure Platform에 VM Role로 웹 사이트를 게시를 하든, Web Role로 웹 사이트를 게시하든 세션을 사용하게 될 경우 비슷한 문제가 있을 수 있습니다.

다행히, Web Role을 이용한다면 내부적으로 사용하는 IIS에서 여러분이 몇 개의 웹 사이트를 추가적으로 구성하든 관계없이 같은 순서로 같은 ID를 사용하는 웹 사이트를 만들 것이므로 세 번째로 이야기한 ID 값 수정과 같은 작업은 할 필요가 없을 것입니다. 그러나 Machine Key에 대한 설정이나 세션 공유를 위한 설정은 SQL Azure를 이용한다거나, Worker Role에서 ASP.NET State Service 혹은 써드파티의 Session State Server를 이용해야 할 수 있습니다.

물론, 최근에 Windows Azure Platform의 일부로 Windows Azure AppFabric Cache가 새로 출시되기는 하였습니다만 상당히 이용 가격이 비싼 편입니다. (비싼만큼 확실한 성능을 제공합니다.) 로드 밸런싱 환경에서 특별한 문제를 일으키지 않는 일반적인 세션 공유가 필요하시다면 오늘 이야기한 주제를 응용한 Azure Project를 구축해보는 것도 의미가 있을 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Data Sync (1) – 소개와 Agents 구성

이번 글은 SQL Azure Data Sync에 대한 내용을 한번 알아보도록 하겠습니다.
여기서의 버전은 SQL Azure Data Sync CTP 2 를 사용합니다.

SQL Azure Data Sync를 그림 하나로 정의하면 아래와 같습니다. 양 방향 화살표로 SQL Azure – SQL Azure, SQL Server – SQL Azure, SQL Azure – SQL Server로 데이터를 동기화해 주는 내용입니다.

[그림 1]

출처: http://social.technet.microsoft.com/wiki/contents/articles/1085.aspx

아래는 SQL Azure Data Sync CTP2에 등록된 화면입니다.

https://datasync.azure.com/

관련 참조 링크는 아래와 같습니다.

• Introduction to SQL Azure Data Sync (Video PDC 2010)
• SQL Azure Data Sync Cost Considerations (wiki article)
• SQL Azure Data Sync - Data Security (wiki article)
• SQL Azure Data Sync - Supported SQL Azure Data Types (wiki article)
• Troubleshooting Guide (wiki article)
• SQL Azure Data Sync - Collisions and Collision Resolution (wiki article)
• SQL Azure Data Sync Scenario: SQL Server-to-SQL Azure Synchronization

위의 [그림 1]처럼 SQL Azure Data Sync를 위해서는 몇 가지 준비가 필요합니다. 그럼 이제 준비사항에 대한 내용 중에서 첫 번째로 Agents 구성을 정리해보도록 하겠습니다.

1. SQL Azure Data Sync CTP2로 이동하여 Agent Name과 Key를 생성합니다. 아래 그림에서 Generate Key 버튼을 클릭합니다. Agent Name 은 “hongju” 로 입력합니다.

2. Agent Name에 대한 Key가 생성된 것을 확인할 수 있으며 현재 상태는 아직 연결되지 않아 노란색 느낌표가 나타납니다.

3. Agent Key를 생성하는 화면의 하단에 Agents 를 다운로드하는 링크가 보이므로 다운로드 해서 실행합니다.

4. 위의 그림에 나온 것처럼 시작, 프로그램에서 Agent Configuration Tool을 시작하여 위에서 생성한 Agent Key를 이용해서 구성해주어야 합니다. 시작, 프로그램에서 SQL Azure Data Sync Agent CTP2를 클릭하면 아래와 같은 화면을 볼 수 있습니다.

5. Encrypt Password 체크 박스를 체크하고 Edit Agent Key를 클릭하여 2 에서의 Key를 복사하여 붙여 넣기 합니다. Ping Sync Service 아이콘을 클릭하여 제대로 연결되는지 확인합니다.

6. 그리고 Add Member 아이콘을 클릭하여 SQL Server Database를 등록하게 됩니다.

7. 잘 등록되었다면 아래와 같은 화면을 볼 수 있습니다.

8. 관리도구의 서비스에서 SQL Azure Data Sync Agent CTP2 서비스를 시작해주고 SQL Azure Data Sync Portal로 이동합니다. 그러면 Agents와 Database 메뉴에서 연결된 것을 확인 가능합니다.

다음에서 Sync Group을 설정하는 내용에 대해서 알아보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Sharding 소개

SQL Azure의 경우 데이터베이스는 비즈니스 형태가 50GB 를 지원하고 있습니다. 이 용량을 넘어가는 경우 접근할 수 있는 방법에 대한 내용을 알아보도록 하겠습니다. SQL Azure Sharding 과 SQL Azure Federation 으로 대용량 데이터에 대한 부분을 접근할 수 있습니다. SQL Azure Federation은 차후 CTP 를 통해 다루어 보고 이번 글에서는 SQL Azure Sharding에 대한 내용을 알아봅니다.

Sharding은 여러 데이터 베이스를 통해 수평으로 파티션된 응용 프로그램 패턴이며 응용 프로그램을 위한 데이터의 수평적인 확장성을 제공해줍니다. Windows Azure Training Kit 의 데모에 SQL Azure Sharding에 대한 내용이 있어 적용해서 테스트해보겠습니다.

참조: http://social.technet.microsoft.com/wiki/contents/articles/how-to-shard-with-sql-azure.aspx

데이터에 대한 Partion을 생성 할 때 아래 관련 코드 중 PartionField 를 이용하여 여러 데이터베이스에 데이터를 파티션 시킵니다.

실제 응용 프로그램에서 파티션한 결과는 아래와 같습니다. 국가별로 SalesOrderHeader 테이블이 파티션되어 있습니다.

실제 데이터를 한번 살펴보도록 하겠습니다.
위 내용을 통해 응용 프로그램에서 ADO.NET을 이용하여 Sharding Library를 통해 처리된 것을 확인 가능합니다. SSMS를 이용하여 해당 데이터베이스에서 SalesOrderHeader를 SELECT 해보겠습니다. 데이터베이스 별로 Country별로 구분되어 있습니다.

파티션된 결과에 대해서 Select 하는 코드을 접근해보도록 하겠습니다. 아래 코드를 이용하여 Sharding 에 대한 데이터베이스를 병렬로 액세스해서 결과를 병합해주고 있습니다.

SELECT의 웹 페이지 결과는 다음과 같습니다.

Sharding에 대한 INSERT 에 대한 내용도 한번 알아보도록 하겠습니다. 아래 코드를 통해 해당 파티션에 INSERT를 수행하게 됩니다.

위에서 SQL Azure Sharding에 대해서 알아보았는데 SQL Server의 Partitioned 뷰와 유사하며 ADO.NET을 통해 Sharding 에 대한 생성, 조회, 추가를 처리할 수 있다는 것을 알 수 있습니다.

이를 통해 대용량 데이터에 대해 확장성 있게 SQL Azure를 구성할 수 있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Reporting (3)

앞에서 SQL Azure를 데이터 원본으로 하여 보고서를 생성하고 테스트하고 SQL Azure Reporting에 게시해서 결과를 살펴보았습니다.

이번 글에서는 SQL Azure Reporting을 Windows Azure 웹 역할에서 이용하는 내용을 다뤄보도록 하겠습니다. SQL Azure Reporting 을 이용하는데 Windows Azure에서 ReportViewer 컨트롤을 사용하는 내용입니다.

Visual Studio 2010을 통해 Windows Azure 프로젝트를 생성합니다. 웹 역할의 이름은 “AzureReportingWebRole” 으로 지정하겠습니다.

Default.aspx 의 디자인 화면에 일단 ScriptManager를 추가합니다. 그리고 도구상자의 보고에 있는 ReportViewer를 추가합니다. 적절히 넓이와 높이를 지정합니다.

솔루션 탐색기에서 참조 추가를 해서 Microsoft.ReportViewer.Common을 추가합니다. Microsoft.ReportViewer.WebForms 컨트롤은 자동으로 추가되었을 겁니다. 추가되지 않았다면 추가합니다. 그리고 어셈블리의 속성에서 로컬 복사를 true로 지정합니다. Windows Azure로 게시해서 구동하기 위함입니다.

이제 Default.aspx.cs 로 가서 코드를 작성해보도록 하겠습니다.

Page_Init 이벤트에서 작업을 진행하도록 하겠습니다. Page_Load에서 작업할 경우 보고서가 제대로 처리되지 않습니다. Page_Init 때문에 처음에 상당히 고생했었습니다.

ReportViewer 컨트롤의 ReportServerUrl, ReportPath, ReportServcerCredentials 을 처리하면 됩니다.

ReportServerUrl 의 경우는 아래와 같이 지정하면 됩니다. 별도로 Config 파일에서 불러와도 되겠죠.

https://서버이름.ctp.reporting.database.windows.net/ReportServer

ReportPath 의 경우는 위 주소로 로그인하면 경로와 보고서이름을 알 수 있습니다.

/subdir/reportname

ReportServcerCredentials 같은 경우는 IReportServcerCredentials 형식이라 별도의 클래스를 생성해야 합니다. 해당 클래스는 IReportServcerCredentials 인터페이스를 상속해야 합니다. 인터페이스를 구현하면 아래와 같이 구성되게 됩니다. Authority는 서버전체이름 또는 도메인을 나타냅니다.

로컬에서 실행하고 테스트를 진행해봅니다.

이제 Windows Azure로 게시해보도록 하겠습니다. 물론 결과는 잘 나옵니다.

ReportViewer 컨트롤 외에 ReportService2010.asmx 를 통해서도 보고서를 액세스할 수 있습니다.

이상으로 SQL Azure Reporting에 대한 부분을 간략히 살펴보았습니다.

SQL Azure Reporting 은 아직 SSMS를 통해서 액세스가 되지는 않습니다. 또한 관리자 사이트를 별도로 제공하고 있지 않습니다. 보고서 권한, 매개변수, 스냅숏/캐시 등의 내용에는 제약이 있습니다. 지금은 CTP 입니다. ㅋ

Windows Azure 에서 SQL Azure 데이터를 기반으로 리포팅에 대한 내용을 지원해주고 있는 기능입니다.

SQL Azure Reporting 관련 문서는 아래를 참고하시면 됩니다. 또한 Sample을 다운로드 받을 수 있습니다.

http://msdn.microsoft.com/en-us/library/gg552871.aspx#ReportsandReportViewer

http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-reporting-samples.aspx

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Reporting (2)

SQL Azure Reporting (2) 에서는 SQL Azure 를 데이터원본으로 하여 보고서를 생성하여 SQL Azure Reporting 으로 배포해서 보고서를 서비스하는 내용입니다.

먼저 Business Intelligence Development Studio를 통해서 보고서 서버 프로젝트를 생성합니다.

프로젝트 탐색기의 공유 데이터 원본을 오른쪽 클릭해서 새로운 데이터 원본을 생성하고 보고서에서 재 사용하도록 하겠습니다. 데이터 소스는 SQL Azure 를 선택해야 합니다. 그렇지 않으면 배포에서 오류가 발생하거나 보고서 실행시 오류가 발생하게 됩니다.

새 데이터 원본 창에서 편집을 클릭해서 SQL Azure에 대한 정보를 입력합니다.

데이터베이스 이름은 직접 입력하고 연결 테스트를 클릭합니다.

확인을 클릭하고 자격 증명 페이지에서 사용자와 암호를 선택하고 SQL Azure의 사용자 정보를 입력하고 데이터 원본을 생성합니다.

솔루션 탐색기에서 새로운 보고서를 추가하고 데이터 탐색기에서 데이터 원본을 추가하고 위에서 생성한 공유 데이터 원본을 선택합니다.

그리고 아래와 같은 쿼리를 이용하여 데이터 집합을 생성합니다.

SELECT oh.OrderDate, c.Name Category, p.Name Name, SUM(OrderQty) Qty, SUM(UnitPrice) Sales

FROM SalesLT.Product p INNER JOIN SalesLT.ProductCategory c

ON p.ProductCategoryID = c.ProductCategoryID

INNER JOIN SalesLT.SalesOrderDetail od

ON p.ProductID =od.ProductID

INNER JOIN SalesLT.SalesOrderHeader oh

ON oh.SalesOrderID = od.SalesOrderID

WHERE oh.OrderDate = '2008-06-01' AND ParentProductCategoryID=@ProductCategoryID

GROUP BY oh.OrderDate, c.Name, p.Name

HAVING SUM(OrderQty) >10

ORDER BY c.Name, p.Name

그리고 매개변수에 대한 데이터 집합을 생성하고 아래와 같은 보고서를 디자인합니다.

오른쪽 열 들은 계기와 표시기를 추가해서 속성을 설정하면 됩니다.

미리 보기를 한 결과는 아래와 같습니다.

이제 SQL Azure Reporting으로 배포를 하면 됩니다. 프로젝트를 오른쪽 클릭해서 속성을 선택합니다.

TargetServerURL 은 https://서버이름.ctp.reporting.database.windows.net/ReportServer 으로 지정하면 됩니다. Management Portal의 SQL Azure Reporting의 웹 서비스 URL에 대한 정보를 참조합니다.

프로젝트를 배포합니다. 배포할 경우 암호와 패스워드를 물어봅니다. Management Portal 의 SQL Azure Reporting의 User계정 정보에 암호를 입력합니다.

배포가 잘 되었으면 보고서 사이트를 방문해서 결과를 확인하면 됩니다.

https://서비이름.ctp.reporting.database.windows.net/ReportServer 사이트를 열어 SQL Azure Reporting 계정과 암호를 입력합니다. 그리고 나면 배포된 보고서를 확인 가능합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure Reporting (1)

SQL Azure Reporting 에 대한 CTP 신청 결과 메일을 7월 14날 받았습니다.

SQL Azure Reporting 은 로컬 네트워크에서 SQL Server Reporting Service가 돌아가는 보고서 서버를 별도로 운영하던 것을 Azure 환경으로 옮겼다고 보시면 됩니다. 물론 데이터 원본은 SQL Azure가 일반적이겠죠.

아래는 SQL Azure Reporting 을 활성화하고 Management Portal의 사이트입니다.

위 화면에서는 별다른 설정은 없고 암호를 다시 설정할 수 있습니다. 보고서 관리자 계정은 동적으로 생성됩니다. 웹 서비스 URL 을 얻을 수 있고요. 다른 추가 관리 사항은 없습니다.

아래는 샘플 보고서를 배포한 결과의 보고서 사이트입니다.

샘플을 클릭할 경우 아래와 같은 보고서를 볼 수 있습니다.

아래 사이트는 SQL Azure Reporting에 대한 참조 링크입니다.

http://social.technet.microsoft.com/wiki/contents/articles/sql-azure-reporting-samples.aspx

SQL Azure Reporting으로 서비스 하는 방법은 두 가지 있습니다.

l SQL Azure Reporting 서버에서 보고서를 실행

l Report Viewer 를 통해 Windows Azure 어플리케이션을 통해 실행

먼저 첫 번째 방법에 대한 보다 더 구체적인 내용을 다음 글에서 나열해보도록 하겠습니다.

이상으로 간단히 살펴보았는데 아직은 로컬의 SSRS 처럼 보안, 매개변수관리, 캐시/스냅샵 등은 지원하지 않고 있습니다. 보고서를 Azure 환경에서 서비스만 하고 있을 뿐입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure 데이터 이용(5)

앞에서 언급한대로 WCF REST 서비스를 JSON으로 Windows Phone에서 액세스 해보도록 하겠습니다.

WCF 서비스 웹 역할을 생성하고 서비스의 OperationContract을 아래와 같이 정의했습니다.

GetProductByCategoryID 메서드는 입력 매개변수에 따라 SQL Azure의 데이터를 액세스하고 JSON을 반환하는 내용입니다. 데이터 액세스는 SQL Azure의 아래 화면의 저장 프로시저를 호출하게 됩니다.

크로스 도메인 경계에 대한 내용으로 Clientaccesspolicy.xml 을 프로젝트에 추가했습니다.

로컬에서 테스트하고 아래와 같이 클라우드의 프로덕션 환경으로 게시했습니다.

Windows Phone 프로젝트를 생성하고 ListBox를 추가하고 ItemTemplate을 아래와 같이 지정합니다.

MainPage.xaml.cs 에서는 Load 이벤트에서 아래처럼 JSON 을 반환하기 위해 호출하게 됩니다.

OpenReadCompleted 이벤트에서는 DataContractJsonSerializer 를 이용해서 처리합니다.

자 최종결과는 아래와 같습니다. SQL Azure의 데이터를 WCF 서비스 웹 역할을 통해 Windows Phone에서도 손쉽게 이용할 수 있다는 것을 알 수 있습니다.

클라우드의 SQL Azure를 이용할 경우 IT 자산이 불필요하며 대역폭을 사용한 만큼 비용을 지불하는 장점이 있습니다. SQL Azure를 이용해서 다양한 클라우드 응용 프로그램에서 평상시 쓰던 ADO.NET을 이용해서 SQL Azure를 손쉽게 이용할 수 있다는 것을 알아보았습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Azure Platform을 활용해봤던 경험이 있는 많은 사용자들이 클라우드에 대한 이상을 포기하게 되는 가장 큰 부분이 바로 SQL Azure의 현실적인 문제들입니다. 클라우드에 대해서 장밋빛 미래를 이야기하면서도 막상 SQL Azure는 우리가 생각하는 무제한의 와이드 서비스와는 사실 매우 거리가 멀다고 해야 할 것입니다. 오늘은 SQL Azure의 한계와 그 대처 방안들에 대하여 짚어보는 시간을 가지려고 합니다.

SQL Azure 데이터베이스는 여러분의 로컬 데이터베이스가 아닙니다.

SQL Azure 데이터베이스는 여러분의 로컬 데이터베이스가 아닙니다. 여기에는 상당히 많은 의미가 포함되어있는데, 그 중에서도 가장 첫 번째의 의미는 모든 것이 Microsoft의 관리 체계 아래에 놓여있다는 것입니다.

전통적으로 우리가 업무 중에 사용하는 데이터베이스는 정말 미세한 요소 하나하나에 영향을 받습니다. 같이 실행 중인 프로세스들, 하드 디스크의 입/출력 상태, 네트워크 회선 상태 등 Care해야 할 요소가 굉장히 많습니다. Mission Critical Application을 지원하는 데이터베이스라면 이러한 요소들로 인하여 승패가 갈릴 수도 있다는 의미가 되겠습니다.

Microsoft가 제시하는 클라우드 데이터베이스의 모습은 물론 SLA (Service Level Agreement)를 완벽히 준수하여 중단이 없고 항상 일정한 성능을 보장하는 것을 목표로 합니다. 그러나 우리는 이미 클라우드 기반 서비스들이 의외로, 정말 의도하지 않게 중단될 수도 있다는 것을 자주 접해왔고 인정하고 있습니다. Microsoft를 비롯하여 모든 클라우드 서비스 업체는 SLA를 최고 수준까지 보장할 수 있도록 노력한다는 것은 틀림이 없지만 그렇다고 해서 여러분의 Mission Critical Application을 지원할 수 있다는 것이 아님을 분명히 이해하고 있어야 합니다. 여러분의 Mission Critical Application은 단순히 서비스 가동률에 대한 것만이 아니라 운영 비용, 속도와 같은 부분에도 영향을 받을 것입니다.

SQL Azure 데이터베이스가 항상 인터넷 위에서 실행 중이라는 사실을 잊으면 안됩니다.

우리 나라에서도 유명했던 인터넷 대란 중에 SQL Server의 취약점을 대상으로 대규모로 유행했던 Worm Virus가 있었다는 것을 기억하시는 분들이 계실 것입니다. 방화벽의 필요성에 대한 인지도가 낮았을 뿐만 아니라 지금보다는 꽤 취약했던 것이 사실입니다. 물론 지금은 이런 문제점이 기본적인 보안 수준의 향상으로 상당히 개선된 것은 사실이지만 언제 어떤 형식으로 문제가 다시 도래할지는 아무도 장담하지 못합니다.

SQL Azure 데이터베이스는 기본적으로 인터넷 위에서 실행되는 데이터베이스입니다. 물론 보통의 SQL Server 연결때와 마찬가지로 암호화되지 않은 연결을 허용하는 것은 아닙니다. 오로지 암호화된 연결만을 사용할 수 있게 되어있습니다. 그러나 이것이 모든 보안 문제로부터의 완벽한 격리를 뜻하는 것은 아닙니다. 왜냐면, "인터넷 위에서 실행 중"이기 때문입니다. SQL Azure 데이터베이스로 연결을 하기 위해서 필요한 연결 문자열 안에는 서버의 주소, 사용자 계정 정보 등이 포함되는데, 필연적으로 서버의 주소는 인터넷 상의 호스트를 가리켜야 하므로 FQDN (Fully Qualified DNS Name)일 수 밖에 없으며 ID와 비밀 번호도 데이터베이스에 설정된 그대로를 이용할 수 밖에 없습니다. 즉, 연결 문자열의 보안에 관한 부분도 응용프로그램에서 관리하지 않으면 안된다는 의미입니다.

연결 문자열의 보호 수준은 전적으로 여러분이 실행하는 응용프로그램의 종류나 환경, 사용 조건에 맞게 관리되어야 합니다. 서버 응용프로그램이라고 해서 방심할 수 없는 것은, 규모가 큰 기업이거나, 서버 응용프로그램이 재배포 가능한 형태의 패키지인 경우도 포함이 되기 때문입니다.

그리고 SQL Azure에서의 방화벽 정책은 기본적으로 "아무도 연결할 수 없도록 만드는 것"이 최적의 설정입니다. 절대 "모두에게 연결을 허용하는 설정"은 존재하지 않으며 이를 위하여 IP 대역을 넓은 범위로 추가하는 일도 하면 안됩니다. 꼭 필요한 IP 주소만을 정확히 지정하여 관리하는 것이 필요합니다. 만약 불특정 다수에게 데이터베이스의 데이터를 제공해야 한다면 SQL Azure Labs에 있는 SQL Azure OData Services (http://www.sqlazurelabs.com/ConfigOData.aspx)를 검토하거나, 여러분의 IT 인프라 환경 내에 WCF 데이터 서비스를 이용하여 데이터를 제공할 수 있도록 해야 합니다.

SQL Azure 데이터베이스를 백업할 수 있을 것이라는 생각은 하지 않는게 좋습니다.

제목 그대로입니다. SQL Azure 데이터베이스는 백업할 수 있는 것이 아닙니다. 정확히 말하면, 백업을 할 수 있을 만큼 여러분의 예산이 충분한지 검토해야 하고, 백업이 가능한 수준의 데이터를 보관하고 있는 것인지를 묻는 것입니다. 백업을 위하여 소모되는 네트워크 트래픽의 비용은 생각보다 클 수 있으며, 백업을 위하여 시도하는 모든 행위들은, 특히 데이터베이스가 온라인인 상태에서 성능 상의 손해를 크게 입힐 수 있습니다. 그럼에도 불구하고, 불가피한 경우 백업을 할 수 있는 다양한 방안은 Microsoft에 의하여 제공됩니다. 하지만 Full Scan Backup 등은 꼭 필요한 경우가 아니면 택했을 때 문제가 될 수도 있습니다.

그렇다면 여러분의 데이터를 보호하기 위한 관점에서 취할 수 있는 다른 방안은 없을까요? 이 부분에 대해서는 데이터베이스 복제라는 기능을 이용하는 것으로 해결될 수 있습니다. 물론 복제된 데이터베이스에 대한 사용 및 운영 비용은 당연히 발생하지만, Full Scan Backup보다는 저렴하고 성능 상의 손해를 끼치지 않는 것이 가능합니다.

데이터베이스 복제는 같은 서버 내에서 서로 다른 데이터베이스로 하는 것, 그리고 서로 다른 서버 간에 데이터베이스를 복제하는 것 모두 지원되고, 모든 과정은 비동기로 이루어지며 모니터링이 가능합니다. 성능에 영향을 끼치지 않도록 성능 상태를 고려하여 데이터베이스 복제를 천천히 수행하는 경향이 있으며, 복제된 데이터베이스는 트랜잭션 상태가 일관성이 있도록 복제됩니다. 데이터베이스 복제에 대한 자세한 내용은 추후 강좌에서 소개할 수 있도록 하겠습니다.

SQL Azure는 공유 환경에서 실행되고, 용량 제한이 있습니다.

SQL Azure에 대해서 기술적으로 가장 많이 좌절하는 부분이 두 가지가 있습니다. 바로 공유 환경에서 실행된다는 특성과, 용량 제한이 있다는 설정입니다.

우선 공유 환경에서 실행되기 때문에 문제가 되는 것은, 여러분이 로컬 데이터베이스를 다루듯이 해프게 열어서 쓰던 데이터베이스 연결 패턴을 SQL Azure에 그대로 적용하려고 하면, 꽤 높은 확률로 SQL Azure로부터 접속이 차단되거나 예고없이 만들어진 연결이 끊어지는 것을 경험할 수 있습니다. 이는 다른 SQL Azure 사용자에게 성능 상의 손해를 입힐만한 여지가 있다고 판단하는 경우 자동으로 연결을 끊거나 차단하도록 정책 설정이 되어있기 때문입니다. 그래서 SQL Azure를 기존 응용프로그램의 데이터베이스로서 사용하려면 이러한 문제가 일어나지 않도록 연결 풀링을 더 강화해야 하며, 연결 문자열을 SQL Azure에 대해 완전히 하나로 통일할 수 있도록 노력하는 것이 좋습니다.

그리고 용량 제한이 있다는 사실을 기억해야 합니다. 1GB, 5GB, 10 ~ 50GB 사이에서 선택이 가능하며 이 이상의 데이터베이스는 지원되지 않습니다. 따라서, 단일 데이터베이스에 의존하여 데이터를 구축하도록 만드는 설계는 바람직하지 않습니다. 보통은 이러한 한계의 극복을 위해서 Windows Azure Table Storage로 기술을 바꾸거나, 다른 데이터베이스 클라우드를 택하는 경우가 있지만, SQL Azure에 최근에 Database Federation이 추가되어 이러한 불편을 최소화할 수 있게 되었습니다. Database Federation 도입 이전에는 Database Sharding 패턴을 적용하는 방법이 인기있었지만 이는 데이터베이스 관리자의 재량이 아닌 응용프로그램 개발자의 재능에 연관된 기술이었고 관리가 까다로운 문제가 있었습니다.

그럼에도 불구하고 SQL Azure가 필요한 이유

이러한 엄청난(?) 문제점들을 달고 있음에도 SQL Azure는 여러분의 훌륭한 클라우드 기반 데이터베이스 시스템입니다. 여러분이 SQL Azure 데이터베이스에 대해 가지고 있었던 환상이나 오해를 정확히 없애고, 정확한 목적과 계획을 두어 사용한다면 매력적일 수 있습니다.

SQL Azure를 트위터나 페이스북과 같은 I/O가 빈번한 소셜 네트워크 서비스에 대한 데이터베이스로 보는 것은 피해야 합니다. 대신, 참조되는 빈도가 많은 통계형 자료를 보관하는 용도나, 로컬 서버에서 처리하기에 부담스러운 데이터베이스 수준에서의 JOIN 연산 작업들을 수행하기 위한 용도, 혹은 글로벌 데이터베이스로서 지리적으로 멀리 떨어져있는 클라이언트와 데이터를 원활하게 공유할 수 있도록 브랜치 데이터베이스를 만드는 등의 용도로 활용하는 것이 SQL Azure의 정확한 용도가 될 것입니다.

SQL Azure에 대한 더 나은 비전과 활용 방안은 앞으로 SQL Azure에 추가될 업데이트를 통하여 새롭게 발굴될 수 있습니다. 그리고 SQL Server의 차기 버전인 Codename: Denali를 통하여 하이브리드 데이터베이스 구축이 좀 더 완벽한 형태로 만들어질 수도 있을 것입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

SQL Azure 데이터 이용(4)

이번에는 WCF 역할을 통해서 SQL Azure 데이터를 액세스해보도록 하겠습니다.

Management Portal 의 몇몇 텍스트가 한글이 제공되어 왔었는데 지금 시점에서는 상당히 많은 부분이 한글로 변경되어 있습니다. 한글로 변경된 화면도 볼 겸 WCF REST 를 이용해서 SQL Azure 데이터를 호출해보도록 하겠습니다.

먼저 WCF 서비스 웹 역할을 만들도록 하겠습니다.

코드는 아래와 같은 내용으로 처리되어 있습니다. 물론 Web.Config의 Connection String은 SQL Azure를 바라 보고 있습니다.

ADO.NET 코딩을 하고 로컬에서 테스트해본 후 잘 나오는 것을 확인했으면 게시해서 Management Portal에 새 호스트를 생성합니다. 한글로 많이 바뀐 것을 알 수 있습니다.

스테이징 환경에서 테스트해보고 큰 문제가 없다면 프로덕션 환경으로 변환할 수 있습니다. 변환은 상단 메뉴의 VIP 교환 메뉴를 클릭하면 됩니다.

아래는 프로덕션 환경으로 변환된 결과입니다.

이제 WCF 서비스를 호출하여 최종 결과를 확인합니다. 브라우저에서만 결과를 확인하도록 하겠습니다. 클라이언트에서 테스트할 필요는 없을 것 같습니다.

다음 글에서는 위에서 만든 WCF REST를 조금 변경하여 Windows Phone 에서도 이용해보도록 하겠습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Azure Sample – All in One Code Framework

영문 MSDN을 보시면 아래와 같은 All in One Code Framework에 대한 내용을 보실 수 있습니다.

실제 Site는 Codeplex 이며 주소는 다음과 같습니다.

http://1code.codeplex.com/

Sample 찾아보기 하면 아래와 같이 여러 Sample 들이 보이고 Windows Azure Sample을 확인 가능합니다. SharePoint에 대한 내용은 안 보이는군요 ^^

Windows Azure Code Sample을 클릭해보시면 32개 정도의 Sample 을 보시고 다운로드 가능합니다. 약간 고쳐서 바로 써 먹거나 참조해도 도움이 될 듯 합니다.

다음 글에서는 Azure + Bing Map sample application 을 돌려볼까 합니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Windows Azure Platform에서 최근 들어 가장 좋아진 기능을 꼽으라 한다면 바로 원격 데스크톱의 지원일 것입니다. 검증된 형태의 템플릿을 사용하는 경우에는 문제가 될 일이 거의 없지만, 여러분이 직접 Web Role이나 Worker Role을 만들거나, 혹은 이러한 템플릿 위에서 무언가 여러분만의 고유한 기능을 추가하려고 하면 실제로 배포하고 난 이후 전혀 예상치 못한 문제에 봉착하는 경우가 상당히 많습니다. 여러 가지 이슈들이 있을 수 있고, 그 때 마다 적절한 해결법은 모두 다릅니다. 이 경우 원격 데스크톱은 여러분에게 큰 보탬이 되어줄 것입니다.

보편적인 원격 데스크톱과 다른 점

같은 기술을 사용하지만, 서버에서 지원하는 원격 데스크톱과는 사실 많이 다릅니다. 일상적으로 우리는 원격 데스크톱을 관리 목적으로 사용하거나, 개발 목적으로 구축한 서버의 경우 한 발 더 나아가서 원격 데스크톱 위에서 프로그램을 긴급히 디버깅하거나 작성하는 일도 많이 합니다. 하지만 Windows Azure가 제공하는 원격 데스크톱은 어디까지나 문제 해결의 용도로만 사용해야 합니다.

이렇게 해야만 하는 가장 큰 이유는, Windows Azure는 처음부터 탄력성을 중시하는 시스템 운영 정책을 사용하기 때문에 예고 없이 개별 Virtual Machine이 업그레이드되거나, 순환되거나, 교체될 수 있고 또한 같은 일을 하는 Virtual Machine이 늘거나 줄어들 수도 있습니다. 이러한 과정에서 원격 데스크톱으로 재정의하거나 변경한 환경은 임의로 초기화되므로 원격 데스크톱으로 해결한 문제가 다시 원래 상태로 돌아오는 문제가 발생할 수 있습니다. 원격 데스크톱으로 해결할 수 있는 문제의 성격을 정확히 파악하고, 수행했던 작업을 여러분의 프로젝트에 다시 반영하는 과정이 이 때문에 반드시 필요합니다.

Windows Azure에서는 각각의 Virtual Machine이 우리가 생각하는 하나의 완벽한 서버의 개념이 아닌, 마치 응용프로그램이 사용하는 임시 자원과 비슷한 Scope에 놓여있기 때문에 전통적으로 우리가 잘 따르던 제한된 수의 서버를 이용한 서비스 프로그래밍 개념과는 많이 다른 것입니다.  원격 데스크톱 말고도 프로그래밍 방법에 관해서도 이 때문에 많은 도전을 받게 되어있습니다.

원격 데스크톱 지원을 Windows Azure 프로젝트에 추가하는 법

원격 데스크톱을 기존 Web Role과 Worker Role에 추가하기 위해서는 Windows Azure Tools for Visual Studio 1.3 버전 이상의 도구가 설치되어있고 이 버전의 SDK를 기반으로 프로젝트가 새로 만들어지거나 업그레이드되어야 합니다. 준비가 끝나면 다음의 단계를 따릅니다.

참고로 Windows Azure 프로젝트에 원격 데스크톱 지원을 추가할 수 있는 것은 프로젝트 속성 단계에서가 아니라 배포 직전에서의 단계입니다. 이 부분에 대한 혼동이 없도록 합니다.

Step 1: Windows Azure 프로젝트를 솔루션 탐색기에서 찾아 오른쪽 버튼으로 클릭한 후 나타나는 팝업 메뉴에서 게시 메뉴를 클릭합니다.

Step 2: 패키지만 만들 것인지, 또는 Visual Studio 안에서 배포와 함께 서비스 시작까지 자동으로 진행시킬 것인지를 묻는 대화 상자가 나타나는데, 라디오 버튼들의 상태와 관계없이 아래쪽의 Configure Remote Desktop connections 링크를 클릭할 수 있으므로 이 링크를 클릭합니다.

Step 3: 도구를 이용하여 생성한 적이 있었던 인증서와 시스템에 미리 설치된 인증서들이 열거되는 드롭 다운 박스를 클릭하면 아래와 같이 새 인증서를 생성할 수 있는 항목이 나타나는데 이 항목을 클릭합니다.

Step 4: 인증서의 Friendly Name을 입력하고 OK 버튼을 클릭합니다. 앞으로 이런 식으로 인증서를 만들어 활용할 일이 많을 것이므로, 서비스를 실행하려는 Windows Azure 계정의 이름과 프로젝트의 이름을 지정하여 Friendly Name을 지정해두면 인증서를 알아보기 쉽습니다. 이에 관해서는 여러분 나름의 규칙을 정해두기를 권장합니다.

Step 5: 새로 만든 인증서를 선택하고 View 버튼을 클릭합니다.

Step 6: 임시로 만든 인증서이므로 인증서가 유효하지 않다는 경고가 보이지만 Windows Azure에서 관리자 인증을 목적으로 사용하기 위한 인증서의 조건에는 부족하지 않습니다. 자세히 탭을 클릭하고 하단의 파일에 복사 버튼을 클릭합니다.

Step 7: 인증서 내보내기 마법사가 나타납니다. 다음 버튼을 클릭합니다.

Step 8: Windows Azure에 제공해야 하는 인증서는 개인 키 값을 포함하는 PFX 형식의 인증서이므로 아래 대화 상자에서 개인 키를 내보내도록 선택하고 다음 버튼을 클릭합니다.

Step 9: 개인 정보 교환 (PKCS-12) 형식을 사용하도록 지정하고, 추가 옵션 없이 다음 버튼을 클릭합니다.

Step 10: 개인 키에 포함할 비밀 번호를 지정합니다. 보안을 위하여 가능한 고유하면서도 유추가 어려운 여러분 만의 강력한 암호를 지정할 것을 권장합니다. 확인 암호까지 한 번 더 입력하고 다음 버튼을 클릭합니다.

Step 11: 내보낼 파일 경로를 지정하고 다음 버튼을 클릭합니다.

Step 12: 모든 사항을 확인하고 완료 버튼을 클릭하면 인증서 내보내기가 마무리 됩니다.

Step 13: 모든 설정을 저장하고 Step 3의 대화 상자로 다시 되돌아 와서, 아래와 같이 필요한 정보들을 입력합니다. 사용자 이름, 비밀 번호, 계정 만료 기간을 지정합니다. 계정 만료 기간은 여러분의 편의에 맞추어 입력합니다. 보안을 위해서는 계정 만료 기간을 짧게 설정하고, 관리자 포털 사이트에서 직접 기간 연장을 하는 것이 좋습니다. 모든 설정이 끝나면 OK 버튼을 클릭합니다.

Step 14: 이제 이 설정을 사용하기 위해서는 http://windows.azure.com/ 에 접속해서 방금 우리가 내보낸 PFX 인증서 파일을 Windows Azure Portal에 직접 등록해야 합니다. 사이트에 로그인 한 다음 Hosted Services, Storage Accounts & CDN 메뉴를 클릭하고, Hosted Services 메뉴를 클릭합니다. 이렇게 하면 아래와 같은 화면이 나타날 것입니다.

Step 15: 여러분의 Cloud Service를 호스팅할 Hosted Service 항목을 찾아, 하단의 Certificates 폴더를 클릭하면 상단의 리본 메뉴가 Add Certificate / Delete Certificate 버튼만 나타나도록 변경됩니다. 여기서 Add Certificate 버튼을 클릭하면 아래와 같이 Modal 대화 상자가 나타납니다. PFX 파일을 지정하고, 내보내기 때 지정한 비밀 번호를 입력 후 Create 버튼을 클릭합니다.

Step 16: 이제 해당 Cloud Service를 Production이나 Staging에 배포하고 나면 원격 데스크톱 연결을 테스트해볼 수 있습니다. 정상적으로 적용되었다면 도구 모음의 배열이 여러분이 접속하려는 해당 인스턴스를 클릭했을 때 다음과 같이 바뀌어 나타납니다.

Step 17: 아래는 실제로 접속한 화면의 예시입니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

지난 시간에는 Windows Azure에 여러분이 게시하려고 했거나, 이미 게시한 Web Role, Worker Role 등을 원격으로 제어하기 위해서 인증서를 등록하는 방법을 알아보았습니다. 전통적인 IT 환경에서 널리 통용되는 Active Directory 기반의 인증이 Windows Azure에서는 극히 제한적으로만 활용할 수 있기 때문에 인증서, 정확히는 X.509 형식의 인증서를 관리하는 일은 Windows Azure 기반의 관리나 서비스 개발에 있어서 매우 중요합니다.

오늘은 Windows Azure 환경에서 사용되는 대표적인 인증서 활용 사례들을 살펴보고, 인증서를 체계적으로 관리할 수 있는 방안을 논의해보기로 하겠습니다.

Windows Azure Web Role의 HTTPS 지원

Windows Azure Web Role은 내부적으로 IIS 7.0 (Guest OS 버전을 Windows Server 2008 R2로 지정하였을 경우 IIS 7.5)를 기반으로 웹 사이트나 WCF, XML 웹 서비스 등을 호스팅하도록 되어있습니다. 이 때, 보안 향상을 위하여 HTTPS 프로토콜을 기반으로 호스팅할 필요가 있는데 이 때 Windows Azure에서는 HTTPS 프로토콜 형성에 필요한 인증서를 Windows Azure Portal에 별도로 등록하도록 요구합니다. 이렇게 하는 이유는, Windows Azure가 필요 시에 수행하는 동적 인스턴스 복제 때 마다 시스템에 필요한 인증서를 자동으로 설치할 수 있도록 하기 위함이고 또한 HTTPS 기반의 프록시 릴레이를 구현하기 위함입니다. 

이를 위해서 Windows Azure에 제출해야 하는 인증서는 개인 키 값을 포함하는 PFX 형식의 인증서 파일이며, 개별 Windows Azure 프로젝트에서는 인증서의 손도장 값 (Thumbnail)을 설정 파일 상에 지정해야 합니다. 이전에 언급한 대로, 손도장 값은 단순히 어떤 인증서를 사용할 것인가에 대한 설정일 뿐이며, 실제로 인증서를 관리하는 것은  Windows Azure에서 관리를 하는 것입니다. 개인 키를 포함한 인증서는 외부로 유출되지 않도록 따로 잘 보관하여야 하며, 보안 상 Windows Azure에 제출한 개인 키 포함 인증서는 외부 유출 방지를 전제로 다시 회수하기 어렵게 되어있습니다.

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.