SQL Azure Reporting(2)

Cloud 2011. 8. 18. 08:30 Posted by 알 수 없는 사용자

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 계정과 암호를 입력합니다. 그리고 나면 배포된 보고서를 확인 가능합니다.


C++0x가 드디어 C++11이 되었습니다.

C++0x 2011. 8. 15. 16:02 Posted by 알 수 없는 사용자

새로운 C++ 표준 작업이 언제쯤에나 끝날지 고대하고 있는 분들에게 반가운 소식이 있습니다.

드디어 C++0x 작업이 거의 마무리 되었습니다.

 

저번 주 수요일에 최종 국제 투표가 끝난 후 드디어 결과가 나왔는데 만장 일치로 승인이 되었습니다. 이제는 앞으로 몇 달 후에 ISO로부터 최종 발행만 기다리면 됩니다(즉 서류적인 절차만 남았습니다).

 

이로써 길게 길게 진행된 C++의 새로운 표준 작업은 끝나게 되어서 이제 C++11로 불리게 되었습니다( 이전에는 C++98, C++03이 있었습니다 ).

 

C++은 특정 회사가 주도하지 않고, 기존에 C++로 만들었던 코드가 문제 없이 동작해야 하고(표준 사양만 지켰다면), 성능과 편리성을 모두 가지려고 하니 많은 시간이 걸렸습니다.

 

아직 ISO에서 최종 문서가 나오지 않았고 무료로 최종 사양이 어떻게 되었는지 궁금한 분들은 http://t.co/5mjCzyJ 를 통해서 문서를 받아보기 바랍니다. 이 문서는 워킹 드래프트 3242 ISO에서 나올 사양 문서와 거의 같을 것입니다(참고로 ISO에서 나온 문서는 유료입니다).

 

이제 우리는 앞으로 나올 Visual C++이 과연 얼만큼 새로운 표준 기능을 구현해 줄지가 기대됩니다. 개인적으로 꽤 많은 부분이 구현되리라 생각하고 혹 빠진 부분은 예전의 tr1처럼 서비스 팩에서 구현되지 않을까 생각합니다.

 

C++ 새로운 표준이 정해졌으니 남보다 앞서기를 바라는 C++ 프로그래머들은 새로운 C++ 표준을 공부해 봅시다. ^^

 

근래에 바빠서 글을 거의 올리지 못했는데 다음 글은 새로운 C++ 표준의 바뀐 부분을 간단하게 설명하는 글을 올릴 예정입니다.

그리고 새로 추가되는 표준 라이브러리는 boost 라이브러리에서 많이 들어왔습니다. 그래서 지금이라도 boost 라이브러리를 다운로드 받으면 새로운 표준에 들어갈 라이브러리를 미리 사용할 수 있습니다.

 

 


참고

C++0x 사양

위키피디아

http://en.wikipedia.org/wiki/C%2B%2B0x

GCC feature 테이블

http://gcc.gnu.org/projects/cxx0x.html

 

boost 라이브러리

설치 버전 다운로드

http://www.boostpro.com/download/

공식 홈페이지

http://www.boost.org

 

 

 

SQL Azure Reporting (1)

Cloud 2011. 8. 11. 08:30 Posted by 알 수 없는 사용자

SQL Azure Reporting (1)

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

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 환경에서 서비스만 하고 있을 뿐입니다.


SharePoint 2010 샌드박스 솔루션(2)

SharePoint 2010 2011. 8. 9. 08:30 Posted by 알 수 없는 사용자

샌드박스 솔루션(2)

샌드박스 솔루션에 대한 코드 내용을 한번 살펴보도록 하겠습니다.

Visual 웹 파트 프로젝트는 샌드박스 솔루션을 기본적으로 지원하지 않아 일반 웹 파트로 구성을 해보도록 하겠습니다.

빈 프로젝트를 생성하고(샌드박스 솔루션으로 선택하고) 새 항목을 웹 파트로 추가해서 아래와 같은 코드를 작성해봅니다.

샌드박스 솔루션이지만 코드를 작성하고 빌드, 패키지를 해보면 별 문제 없다는 것을 확인 가능합니다. 해당 사이트 모음의 솔루션 갤러리에 wsp패키지 파일을 업로드하고 활성화합니다.

먼저 결과값을 출력할 Label을 아래와 같이 추가합니다.


l Hello World를 출력한 Button 클래스를 추가하고 이벤트에서 Label에 결과 값을 출력합니다.


물론 잘 됩니다. 일반적인 코딩에서는 별 문제 없습니다.


l SPContext 클래스를 테스트하기 위해 아래와 같이 Button 클래스를 추가하고 이벤트에 코드를 작성합니다.


현재 Context 에 대한 정보이므로 별 문제 없이 잘 됩니다.


l RunWithElevatedPrivileges 를 테스트하기 위해 아래와 같은 코드를 작성하고 이벤트에서 RunWithElevatedPrivileges를 사용해봅니다.


빌드하고 패키지 할 때 까지는 문제 없다가 런타임에서 문제가 발생합니다. 제대로 실행되었다면 결과값이 출력되어야 합니다.


l 위의 코드와 비슷하게 다른 사이트 모음을 방문해보도록 하겠습니다. 물론 권한은 있습니다.


마찬가지로 별 문제 없다가 실행할 경우 문제가 발생합니다.


l 이제 네트워킹을 한번 해보도록 하겠습니다. Google Request를 해보려고 합니다.


오류정보 표시를 클릭해서 좀 더 내려가 보면 System.Net.WebPermission 에 대한 사용 권한을 요청하지 못했다고 문제가 발생합니다. CAS를 적용해주어야 합니다.


l 데이터베이스 Connection Open 해보도록 하겠습니다. 문제없다면 Label Open~ 이라는 글자가 출력되어야 합니다.


TypeInitializationException: 'System.Data.SqlClient.SqlConnection'의 형식 이니셜라이저에서 예외를 Throw했습니다 라는 오류가 발생합니다.

l 마지막으로 SPFarm에 대한 내용을 액세스해보겠습니다.

'Microsoft.SharePoint.Administration.SPFarm' 형식을 로드할 수 없습니다. 라는 오류가 발생합니다.

팜 솔루션으로 배포했을 때는 아무런 문제 없이 진행되는 코드입니다.


샌드박스 솔루션은 코딩과 빌드, 패키지에서는 차이가 없으며 실행시 리소스에 제한적이며 안전하게 동작된다는 것을 아실 수 있습니다.



SQL Azure 데이터 이용(5)

Cloud 2011. 8. 4. 08:30 Posted by 알 수 없는 사용자

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를 손쉽게 이용할 수 있다는 것을 알아보았습니다.



SharePoint 2010 Sandbox 솔루션(1)

SharePoint 2010 2011. 8. 2. 08:30 Posted by 알 수 없는 사용자


SharePoint 2010 Sandbox 솔루션(1)

SharePoint 2010 프로젝트를 만들려고 하면 팜 솔루션이나 샌드박스 솔루션을 선택하는 창을 보게 됩니다.

Office 365 SharePoint Online 사이트에서는 팜 솔루션으로는 제한되고 Client OM, Silverlight, 샌드박스 솔루션을 위주로 진행하게 됩니다.

샌드박스 루션이 어떤 것인지 좀 더 구체적으로 알아보도록 하겠습니다.


위 화면의 옵션은 프로젝트를 생성할 때 선택이 가능하며 배포하기 전에도 속성을 변경이 가능합니다.

샌드박스 솔루션의 특징은 다음과 같습니다.

l 해당 사이트 컬렉션의 기능에서만 보입니다. 다른 사이트 컬렉션에서는 보이지 않습니다.

l 사이트 컬렉션 소유자가 wsp파일을 솔루션 갤러리에 업로드 할 수 있습니다. 그리고 활성화합니다.

l 보안에 대해 안전하게 사용할 수 있다. 보안에 제한적이라는 의미입니다.

l 리소스가 제한적으로 기본적으로 300 포인트에서만 동작되게 됩니다. 초과하게 되면 임시적으로 중지됩니다. CPU, 데이터베이스 쿼리 등이 리소스에 해당되며 내부적으로 포인트를 계산합니다. 물론 중앙관리에서 포인트를 수정 가능합니다.

l 개발자가 코딩하는 것은 큰 차이 없습니다. 빌드, 디버그, 배포에도 큰 차이 없습니다. 해당 코딩에 대해서는 문제가 있을 경우 런타임에서 에러가 나타나게 됩니다. 전체 개체 모델의 SubSet으로 보면 됩니다.

l SPFarm, SPService, System.Net.HttpWebRequest.Create, SPSite 에서 다른 사이트를 액세스하려고 할 경우, SPSecurity.RunWithElevatedPrivileges, SQL Connection 등은 문제가 발생하게 됩니다. 해당 사이트 컬렉션에서만 놀아야 한다고 보시면 됩니다.

l 모든 프로젝트 템플릿과 프로젝트 항목이 샌드박스 솔루션을 지원하는 것은 아닙니다. (비쥬얼 웹 파트, 사이트 정의, 비즈니스 데이터 연결 모델, 응용 프로그램 페이지 등)

l 페이지 편집에서 웹파트 추가 등 사용하는 것에는 별 차이 없습니다.

l 샌드박스 솔루션을 이용하기 위해서는 중앙관리에서 “Microsoft SharePoint Foundation 샌드박스를 작동하는 코드 서비스서비스를 시작해주어야 합니다.


l w3wp.exe 프로세스에서 운영되는 것이 아니라 SPUCWorkerProcess.exe에서 운영됩니다.


다음 내용에서 샌드박스 솔루션에서 직접 런타임에서 오류가 발생하는 내용을 알아보도록 하겠습니다.

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를 통하여 하이브리드 데이터베이스 구축이 좀 더 완벽한 형태로 만들어질 수도 있을 것입니다.

SQL Azure 데이터 이용(4)

Cloud 2011. 7. 28. 08:30 Posted by 알 수 없는 사용자

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 에서도 이용해보도록 하겠습니다.



Windows Azure Sample – All in One Code Framework

Cloud 2011. 7. 27. 08:30 Posted by 알 수 없는 사용자

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 을 돌려볼까 합니다.


Windows Azure의 관리 포털 웹 사이트 (http://windows.azure.com)이 이번달 후반부에 한국어로 번역되어 서비스가 이루어지고 있습니다. 그동안 Windows Azure를 간접적으로 사용하셨던 개발자분들께서는 영어로 되어있는 포털 서비스에 대해서 불편함이 있었을 것이고 또 실버라이트 기반 App이기 때문에 느꼈던 어색함이 있었을 것인데, 이러한 부분들이 한국어로 번역된 서비스가 런칭됨과 동시에 많이 개선되었습니다. 오늘 살펴볼 내용은 한글화된 Windows Azure Platform 관리 포털에 대한 내용이며 동시에 실제 Windows Azure Platform을 사용하게 된다면 어떻게 활용할 수 있는지를 간단히 설명하는 내용을 알려드리려고 합니다.



당연한 이야기이지만 Windows Azure 역시 Microsoft의 인터넷 서비스이고 당연히 사용자 인증을 Windows Live ID로 하게 되어있습니다. Windows Azure 서비스를 신청하지 않았다면 서비스 신청 안내 페이지로 이동할 수 있는 안내 페이지가 나타나게 될 것입니다. 서비스를 신청하였고 하나 이상의 계정을 가지고 있다면 아래 그림과 같은 대시보드 화면이 나타날 것입니다.


사실 Windows Azure 관리 포털은 2008년 첫 발표 후 지금까지 약 세 차례에 걸쳐서 대대적인 업그레이드가 진행되었습니다. 그리고 지금 살펴보시는 화면은 세 번째 업그레이드된 버전으로 기본적인 모든 기능들이 실버라이트 App을 통하여 제공됩니다. 즉, Windows와 Mac OS X로 접속하면 Windows Azure 관리 포털에 접근하여 필요한 관리 기능을 즉시 사용하실 수 있습니다. 이번에 업그레이드된 새 포털로 접속하게 되면 이 App을 위하여 저장소 공간을 할당해야함을 안내하는 메시지도 보실 수 있는데, 포털 사이트의 각 관리 기능들에 대한 Add-In 패키지들을 로컬 저장소에 보관하기 위한 목적으로 사용되는 공간입니다.


Outlook 스타일의 메뉴 바 하단의 항목들 중 두 번째 항목인 "호스팅된 서비스, 저장소 계정 및 CDN" 항목을 클릭합니다. 이름이 상당히 길지만 보통 Windows Azure 기반 응용프로그램 개발자들이 자주 사용할 만한 기능들인 Compute, Storage, CDN, Virtual Machine 등에 대한 설정과 관리를 이곳에서 한번에 수행할 수 있습니다. 그리고 이 관리 애플릿을 이용할 때 부터 30초당 한번 씩 서비스 상태를 새로 가져오도록 타이머가 작동합니다. 이제 배포 상태 다음의 선호도 그룹 폴더를 열어보겠습니다.

선호도 그룹이란, Windows Azure 환경에서 여러분이 운영하게 될 하나 이상의 서로 다른 종류의 서비스들이 상호간에 긴밀한 연관성이 있음을 정의하는 서비스 정책 단위로, 표면적으로는 서비스를 논리적으로 하나의 그룹으로 묶을 수 있도록 해주는 역할을 수행합니다.

SPQuery 를 통한 페이징

SharePoint 2010 2011. 7. 26. 08:30 Posted by 알 수 없는 사용자

SPQuery 를 통한 페이징

요번 글에서는 페이징에 대한 내용을 다루어 보도록 하겠습니다. 커스터마이징을 통해 List의 데이터를 요구사항에 맞게 보여주게 됩니다. 그럴 경우 Server 개체 모델을 통해서는 SharePoint List의 데이터를 SPQuery 클래스를 이용해 CAML를 통해 쿼리, 정렬, 필터를 처리할수 있습니다.

그런데 트러블슈팅하러 업체에 가서 코드를 보니 전체를 들고 와서 처리하고 있어 간단히 정리해봅니다.

SPListItemCollectionPosition 클래스를 통해 페이징 처리하는 코드의 예를 한번 살펴보도록 하겠습니다. 먼저 아래와 같은 간단한 사용자 지정 목록에 데이터를 50건 입력했습니다. Ref 는 정렬을 하기 위한 내용으로 0~49까지의 값을 가지고 있습니다.

SharePoint OM에서 SPQuery를 통해 RowLimit, Query(Where, OrderBy)를 처리해서 1페이지에 대한 내용을 출력해줄 수 있습니다.

아래 코드의 내용을 보면 10건으로 제한하고 Ref Descending으로 정렬해서 화면에 출력해줍니다. 1 페이지의 경우 아래와 같이 처리하고 2 페이지부터는 페이징이 되도록 처리합니다.


1 페이지에 대한 결과는 아래와 같습니다.

2페이지에 대한 내용은 아래와 같이 처리할 수 있습니다. Lastitem은 직접 입력해서 처리했습니다.


SPListItemCollectionPosition 의 생성자의 매개변수(PageInfo)는 다양한 옵션들(Paged, p_정렬키, Next, Prev) 이 있으며 위의 코드에서는 아래와 같은 내용이 처리됩니다.

Paged=TRUE&p_Ref=40&p_ID=41

결과는 아래와 같습니다.


3페이지의 경우는 lastitem 30으로 해서 실행해보면 됩니다.

물론 페이지 사이즈를 5로 지정해서 테스트할 수도 있습니다.

위의 코드를 기반으로 SPQuery에서 모두 들고 와서 해당 페이지에 대한 내용을 표시해주는 경우 SPListItemCollectionPosition 을 통해 해당 페이지에 대한 내용만 가져와서 표시해 줄 수 있습니다. 실제 SQL 쿼리에서도 SELECT TOP(@NUMROWS)가 처리됩니다.

Client OM에서도 동일한 클래스(SPListItemCollectionPosition) 를 볼 수 있으며 REST 에서도 페이징에 대한 내용을 지원해주고 있습니다.


Real-World Windows Azure Development Guide – 원격 데스크톱

Cloud 2011. 7. 25. 13:00 Posted by 알 수 없는 사용자

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: 아래는 실제로 접속한 화면의 예시입니다.

인증서에 대하여

원격 데스크톱을 적용해보고 잘 동작한다면 이제 좀 더 자신감을 가지고 디버깅을 시작할 수 있을 것입니다. 그러나 몇 가지 막연한 것도 있을 것인데, 특히 인증서에 관해서는 더더욱 그럴 것입니다. 만약 실수로 여러분이 내보낸 인증서가 사라지게 된다면 패키지를 만들어서 Azure에 게시할 수 있을까요? 일단은 가능합니다. 하지만 여러분의 마음이 놓일 수 있는 상황을 만들기 위해서는 이전에 언급했던 절차를 다시 진행해야 하는 번거로움이 따르므로 인증서 관리는 항상 신중히 해야 합니다.

그리고 관리자 권한으로 로그인할 수 있도록 지정한 계정의 만료일이 넘었을 때, 서비스를 다시 업그레이드하지 않고도 만료일이나 비밀 번호를 바꿀 수도 있으므로 이 부분에 대해서도 안심해도 되겠습니다.

Azure RDP 파일이 보통의 RDP 파일과 다른 점

Windows Azure의 경우 Load Balancer가 있기 때문에 각각의 개별 Virtual Machine이 직접 IP 주소를 노출하는 일이 없습니다. 그런데 어떻게 Windows Azure Management Portal에서 제공하는 RDP 파일을 통해서 정확히 해당 Instance에 접속할 수 있는 것일까요? 의문을 풀기 위해, Azure에서 사용하는 RDP 파일 형식에 대해서 잠시 살펴보기로 하겠습니다. 이 파일 형식을 정확히 이해하고 활용하실 수 있다면 관리 포털 사이트까지 들어가는 수고 없이 곧바로 여러분이 원하는 원격 데스크톱 세션을 만들 수도 있습니다.

full address:s:qrcode.cloudapp.net
username:s:********
LoadBalanceInfo:s:Cookie: mstshash=<Role Name>#<Instance Name>#Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp

RDP 파일 자체의 내용은 매우 단순합니다. Full address username은 여러분이 알고 있는 것과 같습니다. 하지만 LoadBalanceInfo 부분이 실제로 연결을 성립하는데 꼭 필요한 정보들이 담겨있는 부분입니다. <Role Name> Windows Azure Portal에서 접속하려는 Role의 이름으로, Windows Azure 프로젝트 내 Role 프로젝트의 이름과 일치하는 부분입니다. 그리고 Instance 이름은 현재 실행 중인 인스턴스의 이름을 의미하며, 보통 Role Name 뒤에 _IN_[n] 형태의 접미사가 붙고, n 값은 0부터 시작합니다. 그리고 #Microsoft.WindowsAzure.Plugins.RemoteAccess.Rdp 문자열을 지정하여 Windows Azure Load Balancer와 상호작용해야 함을 명시하고 있습니다.

지난 시간에는 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에 제출한 개인 키 포함 인증서는 외부 유출 방지를 전제로 다시 회수하기 어렵게 되어있습니다.

참고로, Windows Azure에 제출하지 않은 인증서에 대한 Thumbnail 값을 사용하려고 하면 Windows Azure Portal 사이트에서 패키지를 게시하기 전에 이를 검사하여 배포할 수 없음을 안내하는 메시지가 나타납니다. 인증서에 대한 정보는 메타 데이터 형태로 기술된 XML 파일을 이용하여 확인할 수 있는 것이므로 이를 검사하는 것이므로 이 과정 자체는 오래 걸리지 않습니다.

Hosted Service용 인증서

Hosted Service용 인증서는 각 VM에 직접 설치하는 인증서로, VM 내에서 사용하기 위한 목적으로 제공되며, 나중에 설명할 기회가 있을 것입니다만 Windows Azure AppFabric Access Control을 Windows Azure 환경에서 정상적으로 사용하기 위해서는 꼭 필요하고, 또한 Remote Desktop 서비스를 개통하기 위해서도 필요합니다.

Windows Azure 환경에서의 Remote Desktop은 네트워크 수준 인증을 사용할 수 없기 때문에 모든 암호화 과정을 미리 등록한 인증서를 기반으로 할 수 있도록 되어있습니다. 이는 지난 시간에 살펴본 것과 같은 것으로, Visual Studio를 이용하여 클라우드에 게시할 수 있는 패키지 파일을 작성하기 직전에 지정할 수 있도록 되어있으며 현재는 개별 Role 단위가 아니라 Azure Project 전체에 걸쳐 공유하는 방식으로 인증서 지정이 가능합니다.

Remote Desktop용 인증서 역시 프로젝트 상에서는 Thumbnail 값만이 필요하지만 실제로 작동할 수 있으려면 Windows Azure의 프로젝트용 인증서 목록 안에 들어있어야 합니다. Windows Azure Portal 사이트에서 역시 이 설정을 검사하므로 등록되지 않은 인증서를 사용하려고 하면 업로드 후 배포가 취소됩니다.

Windows Azure Management API용 인증서

Windows Azure에서 사용하는 인증서의 또다른 유형으로는 Management API에서 사용하는 인증서가 있습니다. 이 인증서는 Management API를 사용하려 하는 Consumer와 Management API Provider 사이의 암호화 통신을 성립하기 위한 목적으로 사용되는 인증서입니다.

Management API용 인증서를 포털 사이트에 제출하는 방법은 앞서 살펴본 두 가지 형태의 인증서를 제출하는 방법과 차이가 있습니다. 포털 사이트 내에서 Management API용 인증서는 제출 후 각 VM에 설치되지는 않으므로 양쪽의 용도를 정확히 구분할 필요가 있습니다.

테스트용 인증서를 간단히 만드는 방법

이와 같이 인증서를 활용하는 폭이 많지만 한 가지 궁금한 것은, 때 마다, 그리고 갱신 철마다 매번 VeriSign이나 Thawte와 같은 인증 기관을 통해서 적지 않은 금액을 지불하고 인증서를 갱신해야 하는 것인가에 대한 부분입니다. 결론부터 말하면, 권장 사항으로 말할 것 같으면 모든 인증서를 그렇게 하는 것이 가장 최적이지만, 현실적으로는 그렇게 할 필요가 없습니다. 프로젝트에 관계되어있는 내부 관계자들 사이에서 이용하기 위한 서비스에서 필요한 인증서라면 (원격 데스크톱 제어 시 필요한 인증서와 같이) 임시 인증서를 생성하고 사용하면 됩니다. 하지만 HTTPS 웹 사이트를 실행하려는 경우라면 이는 내부 이해 관계자들 사이가 아닌 대외적인 웹 사이트가 될 가능성이 크기 때문에 정상적인 인증서를 발급받아 서버 인증서로 설치할 수 있도록 해주는 것이 꼭 필요할 것입니다.

정식 인증서를 사용하기 전에는 자체 서명 인증서를 통하여 이런 기능을 미리 시험해볼 수 있으며, 자체 서명 인증서를 만드는 방법은 Windows SDK에 포함되어있는 MAKECERT를 이용하거나 IIS 7 관리자 콘솔의 인증서 생성 마법사를 이용하는 방법이 있습니다. 이 중 명령줄 도구를 사용하는 방법은 http://blogs.microsoft.co.il/blogs/applisec/archive/2008/04/08/creating-x-509-certificates-using-makecert-exe.aspx 의 내용을 활용하시면 도움이 될 것입니다.

SQL Server CodeName “Denail” CTP 3에서의 SQL Azure 액세스

Cloud 2011. 7. 22. 08:30 Posted by 알 수 없는 사용자


SQL Server CodeName “Denail” CTP 3에서의 SQL Azure 액세스

SQL Server CodeName “Denail” CTP 3 가 발표되었습니다. 한국어 버전에 대한 내용도 제공되고 있습니다.

CTP 3 다운로드에 대한 내용은 아래 링크를 참고하시기 바랍니다.
https://www.microsoft.com/betaexperience/pd/SQLDCTP3CTA/enus/


설치하고 SQL Server CodeName “Denail” CTP 3를 통해 아래와 같이 SQL Azure 를 액세스 해보았습니다.

물론 잘 액세스되며 CTP 3 한글 버전에서 SQL Azure 를 테스트해볼 수 있습니다.

SharePoint 2010 Service Pack 1 설치

SharePoint 2010 2011. 7. 18. 08:30 Posted by 알 수 없는 사용자

SharePoint 2010 Service Pack 1 설치

서비스 팩을 설치하기 전에 테스트를 해서 이상이 없는지 확인 후 실제 서버에 적용해야 합니다. 또한 14폴더 백업과 팜 백업을 미리 해두어야 합니다. 적용 후 결과를 확인 해보셔야 하며 잘못 되었을 경우 준비를 해두고 진행해야 합니다. 만약 잘못된다면 다 본인 책임입니다.

커스터마이징하거나 개발 사항의 경우 14 폴더의 기본적으로 제공되는 콘텐트(마스터페이지, CSS) 등을 바로 편집했을 경우 서비스 팩이 설치되면 다 덮어써 버릴 수 있습니다. 이번 기회에 제대로 했는지 확인 가능할 것 같군요.

6월 말에 서비스 팩이 출시 되었습니다.
아래 사이트를 방문해서 언어에 맞게 서비스 팩을 다운로드 합니다.

http://www.microsoft.com/downloads/ko-kr/details.aspx?familyid=b9fcdc42-eea4-4c08-9169-a9a73e55b8d4&displaylang=ko

실행 파일을 실행하고 동의하면 업데이트가 아래와 같이 진행됩니다. 다 완료되고 나면 재 부팅하시면 됩니다.

서버 재 시작 후 다음 내용을 보시면 설치 여부를 확인 가능합니다.

14.0.6029.1000 이라는 것을 볼 수 있습니다.

테스트 후 이상 없다면 운영 팜에 각각 반영하실 수 있습니다.

서비스 팩을 설치해서 크게 변경된 것은 없지만 기존 화면과 비교해보면 기타 옵션에서 도서관이 없어지고 라이브러리로 변경되어 있는 것을 확인 가능합니다. Connect 사이트에 피드백을 올리긴 했지만 서비스 팩을 설치하면 변경되네요 ^ ^

아래는 기존 사이트의 모습이며 Office 365 사이트도 아래처럼 나옵니다.

오류나 잘못된 사항에 대해서는 맘에만 담아두지 마시고 한국 마이크로소프트나 MVP 에게 얘기해서 반영을 하실 수 있습니다~


 

[StartD2D-5] Direct2D의 리소스 기본 개념.

DirectX 11 2011. 7. 11. 08:30 Posted by 알 수 없는 사용자

 

 

Direct2D 리소스( Resource ) 기본 개념

 

Direct2D 에서 리소스라는 것은 단지 메모리를 의미합니다.

그 메모리는 지오메트리(Geometry)나 비트맵 이미지가 될 수도 있습니다.

즉, 이들 리소스는 메모리들이 추상화 된 일종의 개념적인 분류들입니다.

 

이들 리소스를 처리해서 모니터에 최종적으로 보여주는 것이 Direct2D의 역할입니다.

이전 까지 사용되던 GDI 도 바로 이런 역할을 하는 것입니다.

 

하지만, GDI와 Direct2D 는 리소스 처리 방식이 완전히 다릅니다.

앞선 시간을 통해서, GDI는 CPU만을 활용한다고 꾸준히 언급했습니다.

 

반면에, Direct2D는 CPU와 GPU를 동시에 활용합니다.

CPU와 GPU를 동시에 활용하기 때문에,

리소스들도 이들에 맞게 추상적으로 재분류 되어야 합니다.

 

Direct2D는 이 리소스들을 크게 두 가지 형태로 분류합니다.

바로 디바이스 독립적인 리소스( device-independent resource )와

디바이스 의존적인 리소스( device-dependent resource )로 분류하고 있습니다.

이들 두 리소스들은 모두 ID2D1Resource 인터페이스를 상속받습니다.

 

 

디바이스 독립적인 리소스

 

디바이스 독립적인 리소스라고 하는 것은 CPU에 의해서 처리되는 리소스를 의미합니다.

단어 자체에서 볼 수 있듯이,

이들 리소스는 사용자의 그래픽 하드웨어와 상관없는 처리 결과를 보장합니다.

 

뒤에서 살펴보겠지만, 지오메트리를 표현하는 인터페이스들이 여기에 속합니다.

( 조금 더 정확히 나열하면, ID2D1DrawingStateBlock, ID2D1Factory, ID2D1Geometry,

ID2D1GeometrySink, ID2D1SimplifiedGeometrySink, ID2D1StrokeStyle 등이 여기에 속합니다. )

아래는 이런 디바이스 독립적인 리소스들의 계층구조를 보여주는 그림입니다.

 

 

 

 

 

디바이스 의존적인 리소스

 

반면에 디바이스 의존적인 리소스는 GPU에 의해서 처리되는 리소스를 의미합니다.

사용자들이 가지고 있는 그래픽 하드웨어들은 매우 다양하기 때문에, 그 기능들을 모두 동일한 방식으로 처리하는 것이 쉽지 않습니다.

( 각각의 하드웨어마다 성능이나 명령어들이 모두 차이가 나기 때문이겠죠..^^ )

즉, 이들은 사용자의 하드웨어들에 따라서 결과가 차이가 날 수 있습니다.

이 차이라는 것은 눈으로 확인 가능한 차이를 얘기하는 것이 아니라,

그래픽 하드웨어들이 생성하는 명령어들과 성능 등과 같은 차이를 얘기하는 것입니다.

 

우리가 보는 모니터는 그래픽 하드웨어들이 생성한 명령어들의 최종적인 결과입니다.

리소스들도 바로 이 그래픽 하드웨어의 영향을 받아서 결과가 생성되는 것입니다.

 

앞서 우리가 화면에 렌더링 하기 위해서 만들었던 렌더타겟이나 브러시, 이미지 같은 리소스들은 모두 여기에 속합니다.

아래의 그림은 디바이스에 의존적인 리소스들의 계층구조를 표현하는 그림입니다.

 

 

 

 

Direct2D는 리소스 처리 방식은 되도록이면 GPU를 활용합니다.

GPU 처리가 불가능하다면, 자동적으로 CPU로 처리하게 됩니다.

GPU를 활용하는 리소스라면, 더욱 높은 품질로 빠르게 처리할 수 있습니다.

 

이들 리소스에 대한 설명은 다음 시간부터 차근히 살펴보겠습니다.^^

 


2010 겨울 마이크로소프트는 XBOX 360 새로운 사용자 인터페이스로 프로젝트 명 나탈을 키넥트라는 이름으로 출시했습니다(Kinect for Xbox 360). 이후 키넥트는 기록상 가장 빨리 판매된 가전기기로 선정되었고, 최근에 나온 마이크로소프트의 제품 사용자에게 가장 빠른 시간에 인정받는 제품으로 인정 받은 것 같습니다.

키넥트는 상황인지 컴퓨팅 중 NUI의 일반 사용자 버전으로 개발자, 과학자, 그리고 해커들에게도 상당히 매력적으로 보인 같습니다. 여기에 의료와 전시 다양한 분야에서 키넥트를 활용한 시나리오가 거론되면서, Xbox360 아닌 PC에서의 적용에 대한 다양한 시도가 일어나게 됩니다.

 마이크로소프트는 이러한 시도에 대해 과거와는 다른 접근 방법을 보이게 되고, 개발자와 과학자들을 위한 SDK 출시를 선언하게 됩니다.

MIX 발표와는 달리 오래 기다리기는 했지만, 마이크로소프트는 Windows 7에서 구동할 있는 키넥트용 개발 키트를 출시하게 되었습니다.(Kinect for Windows SDK)

공식 사이트(http://research.microsoft.com/kinectsdk)

키넥트를 활용할 있는 방법을 사용자와 장치 가지 기준으로 보면, 사용자는 일반 소비자와 기업 소비자, 장치는 PC Xbox 구분 있습니다.

현재 우리가 키넥트라고 부르는 것은 정확히 kinect for xbox 360으로 xbox 이용한 일반 소비자를 대상으로 게임 인터페이스로 있습니다.


<
그림1> 키넥트용 Xbox 360 게임과 키넥트를 통한 동작 인식

그림1에서 보이는 처럼, 스포츠와 모험, 그리고 댄스를 중심으로 게임들이 인기를 끌게 되고,

디바이스를 PC 바뀌게 되면, 장르가 단순히 게임을 떠나 의료와 교육 부분이 눈에 뛰게 됩니다.

가장 대표적인 것이 지난 Mix2011에서 보여준 데모들이 같습니다.

#Kinect for Windows SDK Preview(http://www.youtube.com/watch?v=co8jEyVjlPo)

내용 이외에도 유튜브를 보면 다양한 재미있는 동영상을 보실 있으실 입니다.

기업 부분에서는 홍보와 전시, 그리고 PC 제어가 쉽지 않은 공간 등에서 활용도가 많아지게 같습니다.

 

그럼, 이제 키넥트의 실체를 살펴 보도록 하겠습니다.

키넥트는 그림1 2 같이 개의 3D 센서와 하나의 RGB 카메라, 그리고 개의 마이크로 구성되어 있습니다.


<그림2> 키넥트 구조1

<그림3> 키넥트 구조2

<그림4> 키넥트 구조 3

키넥트의 동작 방식은 다음과 같습니다. 먼저 적외선 조명기에서 적외선을 방출합니다. 물체에 반사되는 적외선을 CMOS 카메라가 인식하고, 심도(Depth) 인식해서 처리 합니다. 컬러 이미지 CMOS 카메라에서 인식된 색과 위의 정보를 모두 모아서 스켈레톤 형태로 동작을 처리하는 방식으로 사용됩니다.

 

그럼, Xbox PC에서 키넥트는 어떤 차이점이 있을까?

정밀도(해상도) 부분은 TV 기반으로 XBox 모니터를 기반으로 PC 보다 떨어지게 됩니다. 아무래도 다양한 TV 만족시키기 위해서는 높은 해상도를 사용하기 쉽지 않을 같습니다. 여기에 비해 PC 그것도 Windows 7 이라는 OS 기본으로 하게 되면, 넷북을 최저 사양으로 있을 입니다.

결국 이러한 차이가 xbox 기반 키넥트의 해상도인 320x240 30 프레임 이라는 한계를 지니게 되었고, 여기에 비해서 PC 보다 다양한 해상도를 지원하게 같습니다.

PC SDK 320x24 30, 640x480 30, 1280x960 10 프레임을 지원할 있습니다.

아무래도 하드웨어 전문가가 아닌 필자가 내용을 모두 설명하기에는 부족한 감이 많을 같습니다. 이런 부분은 전기, 전자를 전공하신 유능하신 분들의 포스팅을 기다려봐야 같습니다.

 

현재까지 나온 데모 소스만으로 키넥트 SDK 평가 하기에는 이른 느낌이 듭니다. 다른 공개 라이브러리와 비교해서, 부족하다는 의견 또한 없지 않지만, 아직 베타 버전이고, 근거리 인식에 있어서는 장점을 보이고 있습니다.

 

이제 베타 버전을 통해 키넥트가 PC에서 어떻게 활용될 것인지 가능성을 점쳐보고, 향후에 어떻게 있을 것인지, 지적 호기심을 가지고 기다리고 준비하는 것도 재미있을 같습니다.

[StartD2D-4] WIC 를 이용한 이미지 작업하기

DirectX 11 2011. 7. 4. 08:30 Posted by 알 수 없는 사용자

 

  

이번 시간에는 직접 이미지를 화면에 표현하는 방법에 대해서 언급합니다.

Win32 API를 이용할 때, 우리는 '비트맵(Bitmap)' 이라는

그래픽 데이터 포맷을 읽어서 화면에 그려주었습니다.

사람마다 차이는 있겠지만, 일반적으로 다음과 같은 순서를 따라서 구성했을 것입니다.

 

  1. 비트맵을 읽기 위해서 파일을 오픈한다.

  2. 파일에서 헤더를 읽어 들인다.


  3. 비트맵 헤더의 정보를 통해서 관련 메모리를 생성하고,

    파일에서 색상 데이터에 대한 정보를 읽는다.


  4. DIBSection 을 생성하고, 실제 데이터를 읽는다.
  5. 그리고 마무리 한다.

 

이 순서는 수 많은 방법 중에 하나일 뿐이지만,

기본적으로 파일을 열어서 헤더를 먼저 읽고, 관련 메모리를 생성하고,

이후에 실제 데이터를 채우게 되는 순서는 공통된 작업입니다.

Direct2D 에서도 이와 같이 작업을 해도 되지만,

이미 편의를 위해 만들어진 라이브러리를 사용해서 조금 더 확장성 있는 작업을 할 필요가 있습니다.

지금부터는 WIC를 이용한 간단한 이미지 뷰어 작업을 해보겠습니다.

  

WIC( Windows Imaging Component )

 

DirectX 가 윈도우 운영체제 전반으로 광범위하게 활용되면서,

이들과 관련한 내용들을 분리할 필요가 있었습니다.

과거까지는 DirectX 는 게임 개발자들의 전유물에 가까웠기 때문에,

다른 개발자들도 손쉬운 개념으로 접근할 수 있는 그런 분류가 필요했습니다.


결과적으로 아래와 같이 분류가 되었습니다.  

 

WIC는 모든 이미지를 쉽게 처리할 수 있도록 만들어낸 COM 기반의 프레임워크입니다.

그림에서 보듯이 WIC도 하나의 큰 영역으로서 자리 잡고 있습니다.

( 참고로 DXVA는 영상 처리를 위한 프레임워크입니다. )

 

WIC를 이용한 이미지 처리는 앞서 GDI 기반에서 작성했던 것과는 완전히 다릅니다.

WIC는 PNG, JPG, GIF 등과 같은 거의 모든 주요한 이미지 형식을 포함하고,

기본 코덱들을 지원하고 있습니다.

 

말이 참 어렵죠?

쉽게 말해서, Direct2D 기반에서 이미지 처리를 하려면 WIC를 사용하면 쉽게 할 수 있다는 것입니다.

우리는 이것을 사용하는 순서와 방법에 대해서 배우기 위해서,

윈도우 화면에 이미지를 그려주는 간단한 애플리케이션을 만들어 볼 것입니다.

 

 

기본 WIC 프로그래밍

 

애플리케이션 마법사로 새로운 프로젝트를 만들고, stdax.h 에 다음을 추가를 합니다.

 

'WindowsCodecs.lib'와 'wincodec.h' 가 바로 WIC를 사용하기 위해 추가시킨 것입니다.

눈치 빠른 분들이라면, 이름에서 약간 앞으로의 작업 방향을 예측할 수 있을 것입니다.

 

이번 프로젝트에서 사용할 전역 변수들은 아래와 같습니다.

 

 

익숙한 개념이 눈에 보이지 않으십니까?

바로 IWICImagingFactory 입니다. 네 그렇습니다~

WIC 도 바로 팩토리 형태로 생성이 됩니다.

 

추가된 변수들은 아래와 같은 절차에 의해 값이 채워집니다.

즉, 아래는 WIC의 처리 과정입니다.

 

  1. WIC 팩토리를 만든다.

  2. 파일 경로를 기반으로 해서 디코더를 만든다.

  3. 디코딩된 프레임을 가져온다.

  4. 변환기에 넣어서 Direct2D 형식으로 변환한다.

  5. Direct2D 비트맵을 생성하고, 이를 렌더링한다.

 

이제 위의 절차를 실제로 어떻게 처리하는지를 차근차근 살펴보겠습니다.

 

가장 먼저하는 초기화 작업입니다.

앞서 언급했듯이, WIC 도 팩토리 개념으로 생성됩니다.

COM 기반이기 때문에 API 인자들이 굉장히 어려워 보일 수도 있지만, 관심을 둘 부분은 아닙니다.

위와 같은 방법으로만 하면, WIC가 생성 되어진다는 개념으로만 인식하고 다음 단계로 넘어갑니다.

 

 

 

다음 단계는 디코더를 만들고, 이를 기반으로 해서 Direct2D 형식으로 데이터를 변환하는 것입니다.

이를 위해서 가장 먼저 해야 하는 일은

이미지를 읽어들이기 위한 디코더( Decoder )를 만드는 일입니다.


갑자기 등장한 생소한 용어에 조금 혼란스러울 것 같습니다.

우리가 사용하는 모든 멀티미디어 파일( 이미지, 영상, 사운드 등 )들은

굉장히 어려운 방법으로 압축이 되어있습니다.


이들에 대한 원리나 형식을 이해하는 것도 중요한 일일 수도 있지만,

이는 간단하게 본 페이지에서 설명할 수 있는 내용이 아닙니다.

물론 저도 이와 관련한 전문가는 더더욱 아닙니다.

우리는 단지 API만으로 이들에 대한 고민을 해결할 수 있습니다.

바로 그것이 WIC의 존재 이유 중 하나 일 것입니다.^^

 

즉, 우리는 이미 만들어진 API를 이용해서 손쉽게 이미지 파일을 읽어올 수 있습니다.

그런 역할을 하는 것이 바로 디코더입니다.

아래는 디코더를 가지고 실제 작업을 하는 부분입니다.

 

 

디코더는 WIC 팩토리 멤버함수로써 생성이 되어집니다.

우리가 사용했던 이 API의 원형은 다음과 같습니다.

<코드>

HRESULT CreateDecoderFromFilename(

[in] LPCWSTR wzFilename,

[in] const GUID *pguidVendor,

[in] DWORD dwDesiredAccess,

[in] WICDecodeOptions metadataOptions,

[out, retval] IWICBitmapDecoder **ppIDecoder

);

</코드>

 

이 API는 주어진 이미지 파일을 기반으로 해서 디코더를 생성해 줍니다.

첫 번째 인자로 파일명이 들어갑니다.

이 파일을 기반으로 해서 적합한 디코더를 생성해 주게 되는 것입니다.

예를 들어, PNG 파일이면 PNG에 대한 디코더가 필요하다고 인식하고,

그에 맞는 디코더를 자동적으로 생성해 주는 것입니다.

 

두 번째 인자는 선호하는 디코더 벤더(vendor)의 GUID를 입력해야 하는데, 지금은 NULL을 사용합니다.

 

세 번째 인자로는 디코더에 대한 접근 방법을 명시합니다.

읽기(read), 쓰기(write), 혹은 둘 다 가능한지를 넣어주면,

가장 최적화된 방법과 메모리 위치를 가지는 디코드를 생성해 줍니다.

위의 예제에서는 읽기용으로만 디코더를 만들었습니다.

 

네 번째 인자는 디코더의 캐시 관련 옵션입니다.

우리가 인자로 넘긴 WICDecodeMetadataCacheOnDemand는

필요한 이미지 정보만 캐시 하도록 옵션을 준 것입니다.

다음 번에 언급할 지도 모르지만, 하나의 이미지 파일에는 여러 이미지들을 포함하고 있을 수 있습니다.

예를 들면 GIF 애니메이션 이미지 같은 것들이다.

이런 경우에 유용하게 캐시하려면, 다른 옵션을 주어야 할 것입니다.

 

마지막 인자는 생성된 디코더를 저장할 디코더의 포인터입니다.

여기까지 작업하면, 우린 이제 파일을 읽은 디코더를 소유하게 되는 것입니다.

뭔가 절차 상으로 굉장히 복잡한 것처럼 느껴지죠?

 

 

다음으로 할 작업은 프레임(frame) 작업입니다.

프레임이라는 것은 실제 픽셀 데이터를 가지고 있는 비트맵입니다.

앞서 잠깐 언급했듯이, 하나의 이미지 파일은 여러 장의 이미지가 존재할 수 있습니다.

그런 경우를 대비해서 체크를 해야겠지만,

우린 여기서 단 하나의 프레임만이 존재한다고 가정할 것입니다.

디코더의 멤버 함수인 GetFrame()를 통해서 우린 가장 첫 번째 프레임을 얻을 수 있습니다.

이 프레임을 얻는다는 것은 우리가 화면에 표현할 수 있는 이미지를 얻었다는 것입니다.

 

이제 우리는 디코더를 통해서 이미지를 Direct2D에서 표현할 수 있도록

적절하게 변환을 해주어야
합니다.

CreateFormatConverter() API는 이를 위해서 컨버터를 만들어줍니다.

그리고 이 컨버터를 우리가 원하는 형태로 초기화를 시켜 줍니다.

컨버터의 멤버함수 Initialize() 는 이미지를 컨버팅 하면서

픽셀 정보를 보정해 줄 수 있는 많은 옵션을 가지고 있습니다.

이들 옵션에 대한 세부 설정을 하지 않았습니다.

그래서 위에 인자들 형태로 주면, 별다른 이미지의 수정 없이 32비트 포맷으로 남게 됩니다.

 

이제 마지막으로 실제 렌더링 가능한 형태의 메모리를 생성해야 합니다.

렌더타겟의 멤버함수인 CreateBitmapFromWicBitmap() API를 통해서 이 작업을 하게 됩니다.

여기까지 하면, 이미지를 렌더링 하기 위한 준비작업이 모두 끝난 것입니다.

 

저는 여기에 모든 옵션들을 나열하지 않습니다.

( 기본 목적인 이미지를 띄우는데 충실하고자 합니다.^^ )

 

 

생소한 API들이 눈에 많이 띄지만, 이들은 일련의 절차에 지나지 않습니다.

중요한 개념은 이미지를 읽어 들일 디코더를 만들고,

이 이미지 데이터를 Direct2D가 표현할 수 있는 픽셀 데이터로 변환하는 것입니다.

그리고 이 데이터를 렌더타겟에서 표현할 수 있는 비트맵으로 만들어서

렌더링 가능한 상태로 만듭니다.

위의 코드는 바로 이 개념들을 표현하고 있는 것입니다.

 

그러면 실제 WM_PAINT 메시지를 통해서 이들이 어떻게 화면에 그려야 하는지 살펴보겠습니다.

 

WM_PAINT 메시지에서는 렌더타겟이 존재하지 않는 경우, 렌더타겟을 생성합니다.

렌더 타겟이 존재한다면, 비트맵을 그리고 있습니다.

렌더타겟의 렌더링 작업도 BeginDraw() / EndDraw() 의 매커니즘 내부에서

특정 상태를 기반으로 작업을 수행하게 됩니다.

우리는 Clear() 라는 API를 통해서 렌더타겟의 메모리를 흰색으로 채우고 있습니다.

그리고 현재 우리가 이미지를 (0,0) 위치에 (300,300) 크기로 렌더링 합니다.

 

마법의 함수 DrawBitmap()

 

앞선 작업을 통해서 우린 Direct2D를 이용해서 이미지를 화면에 그릴 수 있었습니다.

만약 우리가 읽어 들인 이미지의 일부분만을 화면에 그리고 싶다면 어떻게 해야 할까요?

혹은 흐릿한 효과를 주고 싶다면 어떻게 해야 할까요?

굉장히 어려운 일들 같지만, 이들 기능은 DrawBitmap() 에 모두 옵션 인자로서 존재하고 있습니다.

( 무척 고마운 일이지요..^^ )

그렇기 때문에, 우리는 이 함수를 잘 사용할 수 있어야 합니다.

API의 원형은 다음과 같습니다.

 

<코드>

virtual void DrawBitmap(

[in] ID2D1Bitmap *bitmap,

[in, optional] const D2D1_RECT_F *destinationRectangle = NULL,

         FLOAT opacity = 1.0f,

D2D1_BITMAP_INTERPOLATION_MODE interpolationMode =

D2D1_BITMAP_INTERPOLATION_MODE_LINEAR

,

[in, optional] const D2D1_RECT_F *sourceRectangle = NULL

) = 0;

</코드>

 

첫 번째 인자는 우리가 렌더링 작업을 수행할 이미지입니다.

 

두 번째 인자부터는 옵션적으로 설정할 수 있다.

두 번째 인자는 렌더링 작업을 수행할 화면의 영역을 설정합니다.

NULL 로 설정한다면, 렌더타겟의 원점에 그리게 됩니다.

만약 이미지 크기보다 크게 설정된다면, 자동적으로 이미지를 확대해서 보여주게 됩니다.

 

세 번째 인자는 투명도를 설정합니다.

범위는 0.0~1.0 사이의 값으로 0.0은 투명한 상태를 나타내고 1.0은 불투명한 상태를 나타냅니다.

 

네 번째 인자는 우리가 렌더링하는 이미지가 회전을 하거나 크기가 조정되었을 때,

어떻게 부드럽게 보일 것인가에 대한 옵션을 설정하는 부분입니다.

즉, 보간( interpolation ) 옵션입니다.

 

마지막 인자는 원본 이미지에서 일정 영역을 보여주고 싶을 때 영역을 입력하는 옵션입니다.

이 때 단위는 해당 이미지 파일의 사이즈를 기준으로 영역을 설정해 주면 됩니다.

 

그러면, 간단하게 실제로 이미지의 일부 영역을 약간 투명하게 보여지는 것을 프로그램으로 구현해자면,

앞서 작성했던, 이미지 뷰어의 기능에서 DrawBitmap()만 변경해주면 됩니다.

 

<코드>

HRESULT hr = E_FAIL;

::g_ipRT->BeginDraw();

::g_ipRT->SetTransform( ::D2D1::Matrix3x2F::Identity() );

::g_ipRT->Clear( ::D2D1::ColorF( ::D2D1::ColorF::White ) );

                            

if( ::g_ipD2DBitmap != nullptr )

{

    ::D2D1_RECT_F dxArea = ::D2D1::RectF( 0.0f, 0.0f, 500.0f, 500.0f );

    ::D2D1_RECT_F dxSrc = D2D1::RectF( 0.0f, 0.0f, 250.0f, 250.0f );

    ::g_ipRT->DrawBitmap( ::g_ipD2DBitmap, dxArea, 0.3f,

D2D1_BITMAP_INTERPOLATION_MODE_LINEAR, &dxSrc );

                

}

hr = ::g_ipRT->EndDraw();                

</코드>

 

우리는 간단하게 DrawBitmap() 의 인자들만 변경해주는 것만으로 이미지의 일부 영역만을 보여주고,

투명도를 조절할 수 있음을 확인해 보았습니다.

각각의 값을 변경시키면서, 여러가지 아이디어를 구상해 보기 바랍니다. ^^


아래 소스코드를 첨부합니다..


C++ AMP

Visual C++ 10 2011. 6. 28. 09:00 Posted by 알 수 없는 사용자

C++ AMP라는 것을 들어보셨나요?근래에 나온 단어입니다.

AMP AcceleratedMassive Parallelism의 약자로 병렬 프로그래밍과 관련된 것입니다.

 

C++ AMP 2주 전의 AMD Fusion 컨퍼런스에서MicrosoftHerb Sutter씨가(MS의프로그램 언어 아키텍터 이자 C++ 표준 위원 멤버) 처음으로공개한 것으로 다음 버전의 Visual Studio(현재는Visual C++)에서 GPGPU 프로그래밍환경을 제공하는 것을 뜻합니다.

 

병렬 프로그래밍에서 대해서 조금 깊게 공부하신 분들은 아마 GPGPU라는것을 들어본 적이 있으리라 생각합니다. GPGPU는 간단하게 말하자면 GPU CPU 처럼 사용하자라는 것으로 GPU의 높은 성능을 사용하여 CPU와 똑 같게는 사용할 수는 없지만연산 처리에서 높은 병렬 기능을 사용하여 CPU보다 훨씬 뛰어난 결과를 얻을 수 있습니다.

 

현재까지 GPGPU 개발환경은NVIDIA Cuda와 오픈 아키텍처인 OpenCL,DirectX 베이스의 DirectCompute가 있습니다.

 

GPGPU 프로그래밍의 단점은 프로그래밍이 복잡하고 아직 레퍼런스가적다는 단점이 있어서 아직은 일반적인 프로그래밍 영역에 들어오지 못하고 있습니다(사실 아직 일반 병렬프로그래밍도 쉽게 사용하지 못하고 있으니..). 그래서 GPGPU가나온 것은 몇 년이 지났지만 아직 일부 전문 영역에서만 사용되고 있었습니다.

 

그러나 CPU 아키텍처가 멀티코어에서 헤테로지니어스 아키텍처(이기종의 CPU가 결합.CPU+GPU)로 서서히 넘어가고 있어서 자연스럽게GPGPU 프로그래밍이 부각되고 있었습니다. 하지만 아직도 개발환경의 뒷받침이 부족한 상태였는데드디어 우리 개발자에게 친숙한 Visual C++에서 이런 문제를 해결하려고 합니다.

 

C++ AMP는 쉽게 말하면Visual C++에서 GPGPU 프로그래밍을 지원하는 것을 말합니다. Visual C++의 뛰어난 개발환경을 토대로 하여 이때까지 복잡했던GPGPU 프로그래밍을 일반 프로그래밍 하듯이 사용할 수 있게 해줍니다. 이로써 GPGPU가 일반 프로그래밍 영역으로 들어 올 수 있는 큰 계기가 되었다고 생각합니다.

 

 

C++ AMP에 대해서 AMD Fusion 컨퍼런스에서 데모를 시연한 Daniel Moth의 블로그에올라온 글을 정리하면

개발자의 생산성과 이식성을 저해하지 않고 헤테로지니어스 하드웨어 프로그래밍의 허들을 낮게 하여 프로그래밍 일반영역에서 사용할 수 있도록 한다.

 

현재의 대 규모 병렬 하드웨어(CPU GPU)의 사용을 돕기 위한 것만이 아닌 코드의 투자를 미래에 대비한 디자인으로 하여 견고하도록 한다.

 

Visual Studio의 일부분으로 또 다른 컴파일러나 다른 구문을배울 필요가 없다.

 

현재의 C++ 언어를 사용하며 C나다른 파생 언어가 아니다.

 

Visual Studio vNext와 완벽하게 통합하여 지원한다. 편집, 빌드, 디버그, 프로파일러 등 Visual Studio의 다른 모든 기능이 C++ AMP와 같이 동작한다.

 

기존의 Concurrency Runtime의 일부로 STL와 비슷한 형태의 라이브러리를 제공하여 amp.h 헤더 파일을제공한다.

 

병렬화를 주 특징으로 하여 헤테로지니어스 하드웨어 위에서 거대한 다 차원 데이터를 아주 쉽게 동작한다.

 

유일의 코어 C++ 언어 확장을 도입한다.

 

DirectX(DirectCompute) 위에 구축하지만 C++ AMP에서는 DirectX의 모습은 나타나지 않는다( DirectX를 몰라도 상관 없다).

 

 

 

또 동 세미나에서 기조 연설을 한 Herb Sutter씨의 강연 중 C++ AMP에 관한 내용으로는

C++ AMP에 의해서 기존의C++에서 큰 변경을 가하지 않으면서 언어를 확장하는 점을 강조하여 새로운 언어가 만들어서 개발자에게 혼란을 주는 것을 피했다라는것을 알림.

 

언어 확장으로 restrict() 함수와 array_view라는 2개의 type Key로 잡음. restrict()는 프로세서 아키텍처에 따라서 실행가능한 기능에 제한을 거는 것이고 array_view는 불 균인한 메모리 공간으로의 접근으로 생기는문제를 회피하기 위한 것으로 메모리 공간을 N 차원의 배열로서 작업하는 것을 뜻한다. 메모리 공간의 추상화라고 할 수도 있다. restrict()array_view는 프로세서 아키텍쳐와 메모리 공간의 차이를 흡수할 수 있는 것으로 C++ AMP의 중요한 Key이다.

 

C++ AMP의 컴파일러는Visual Studio의 차기 버전에서 들어갈 예정으로 릴리스는 이번 연말로 예상하고 있다. 또이 컴파일러는 오픈 사양일 예정으로 Windows 상의 VisualStudio 뿐만이 아닌 그 이외의 개발 환경(C++ Builder이나 이클립스 등)에서도 이용할 수 있도록 AMD와 협력 하여 개발 중이라고 한다.

 

 

 

 

 

DirectXDirectCompute를 사용한다고 하니 C++ AMP를 사용한 프로그램은 Windows Vista 이상에서만 사용할 수 있을 것 같습니다(이유는 DirectCompute DirectX 10에서 지원하기 때문).

 

GPGPU에 관심은 있었지만 아직 시기상조라고 생각하는 분들은 C++ AMP가 나오면 개발 허들이 크게 내려가므로 본격적으로 준비를 해도 좋을 것 같습니다. AMD에서는 헤테로지니어스 컴퓨팅 프로그래밍의 전망을 CUDA 등의독자 사양에서 OpenCL이나 DirectCompute 등의오픈 사양으로 이동하고, 전문 프로그래머만 프로그래밍 하는 시대를2011년까지로 보고 그 이후로는 일반 프로그래머가 완전하게 C++로 프로그래밍하는 헤테로지니어스컴퓨팅 프로그램이 올 것으로 보고 있다고 합니다.

 

저도 이제 슬슬 GPGPU 프로그래밍 쪽으로 들어가볼 예정인데 일단조만간 OpenCL부터 시작해 볼까 합니다. 연말에 VS vNext가 나올 수도 있다고 하니 그때 꼭 C++ AMP를 공부해서 그 내용을 공유하도록 하겠습니다^^

 

 

 

참고

헤테로지니어스 멀티 코어 http://jacking.tistory.com/513

 

Daniel Moth씨의 블로그 http://www.danielmoth.com/Blog/

  위 글을 정리한 한블로그(일본어)
 http://blogs.msdn.com/b/hiroyuk/archive/2011/06/20/10176783.aspx

 

AMD Fusion 컨퍼런스에서의 데모

비디오 http://channel9.msdn.com/posts/Daniel-Moth-Blazing-fast-code-using-GPUs-and-more-with-C-AMP

슬라이드 http://ecn.channel9.msdn.com/content/DanielMoth_CppAMP_Intro.pdf

 

일본의 임프레스 사이트에 올라온 Herb Sutter씨의 기존 강연정리 글

http://pc.watch.impress.co.jp/docs/news/event/20110617_453939.html

 

[STL] 15. VC++ 10에 추가된 새로운 컨테이너 forward_list – 사용편

C++0x 2011. 6. 21. 09:30 Posted by 알 수 없는 사용자

STL의 컨테이너를 사용해보았다면 forward_list라고 해서 딱히 어려운 부분은 없습니다. 다만 forward_list이 단 방향 리스트라는 것과 다른 컨테이너에서는 지원하는 기능이 일부 없다는 것을 잘 숙지해야 합니다.

 

필요한 헤더 파일

forward_list는 이름과 같은 ‘forward_list’라는 헤더 파일을 포함해야 합니다.

#include <forward_list>

 

 

[예제] forward_list를 사용하여 요소 추가, 순회, 삭제하기

#include "stdafx.h"

#include <iostream>

#include <forward_list>

 

using namespace std;

 

 

int main()

{

           forward_list< int > flist;

 

 

           cout << "flist에 추가한 요소들 출력" << endl;

           // 추가하기

           auto iter = flist.before_begin();

           for( int i = 0; i < 5; ++i )

           {

                     iter = flist.insert_after( iter, i );

           }

                    

           // 순회

           for( iter = flist.begin(); iter != flist.end(); ++iter )

           {

                     cout << *iter << endl;

           }

 

           cout << endl;

           cout << "flist의 요소들 중 일부를 삭제한 후 남은 요소들 출력" << endl;

           // 순회 하면서 일부 요소 삭제

           auto prev_iter = flist.before_begin();

           iter = flist.begin();

           while( iter != flist.end() )

           {

                     if( 3 == *iter )

                     {

                                iter = flist.erase_after( prev_iter );

                                continue;

                     }

                     ++prev_iter;

                     ++iter;

           }

 

           // 순회

           for( iter = flist.begin(); iter != flist.end(); ++iter )

           {

                     cout << *iter << endl;

           }

 

           return 0;

}

 

< 결과 >


 

위 예제를 보면 아시겠지만 forward_list std::list에 비해 성능 면의 이점을 가지고 있지만 사용 측면에서는 조금 불편한 점이 좀 있습니다. 그러나 C와 비슷한 성능을 내고 싶은 경우에는 좋은 선택 기가 될 수도 있습니다.

 


참고

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