[ClouDeveloper News – Azure Edition] 2016년 12월 15일

클라우드 컴퓨팅을 중심으로 관련된 여러 기술과 업계 소식을 매주 전하는 ClouDeveloper News를 시작합니다. 파일럿 프로그램으로 구상하여 운영 중에 있으며 추후 여러 피드백과 의견 수렴을 통하여 프로그램의 틀을 갖추어 나갈 예정이오니 많은 관심과 구독을 부탁드립니다.

이번주 커뮤니티 소식

Azure 서비스 공지 사항

  • General availability: Package Management extension for Visual Studio Team Services
    • Visual Studio Team Service에서 NuGet Package와 NPM Package를 관리할 수 있는 익스텐션 서비스가 새로 출시되었습니다. Visual Studio Marketplace에서 청약할 수 있는 상품입니다.
  • General availability: Azure IoT Gateway SDK
    • 기존 하드웨어나 인프라를 교체하지 않고, 게이트웨이 장치를 개발하여 Azure IoT와 자연스럽게 연동될 수 있도록 만들 수 있습니다. 오픈 소스로 공개된 Azure IoT Gateway SDK를 사용하여 기존 장치가 Azure IoT Hub와 직접 통신할 수 있는 여건이 되지 않더라도 원격에서 장치를 제어하거나 상태를 보고하는 대행 게이트웨이 하드웨어를 더 쉽게 개발할 수 있습니다.
  • With general availability, enhancements abound in Azure IoT Hub Device Management
    • Azure IoT Hub에서 그동안 강조되지 않았거나 샘플 코드 수준으로만 제공되어오던 “장치 관리”에 관련된 기능과 API가 GA로 전환되었습니다. 예약 작업, 다이렉트 메서드, 쿼리, 디바이스 트윈 API를 사용하여 좀 더 많은 장치 제어 시나리오를 커버할 수 있게 되었습니다.
  • Latest update of Azure Analysis Services preview brings scale up and down
    • Azure Analysis Service의 인스턴스 크기를 조정할 수 있는 기능이 포털에서 새롭게 제공됩니다. 상황에 따라 강력한 성능 발휘를 위하여 인스턴스 등급이나 규모를 늘리고, 사용하지 않는 때에는 최소한으로 낮추어 경제적으로 Azure Analysis Service를 활용할 수 있게 됩니다.

교육 자료

새로운 제품 및 서비스

  • Introducing Windows Server & SQL Server Premium Assurance
    • 지원이 중단될 예정인 Windows Server와 SQL Server에 대한 보안 업데이트 제공 서비스가 유상으로 제공됨에 따라 기존 라이프사이클에서 최대 6년까지 지원이 연장됩니다. 신규 플랫폼과 서비스로 이행을 하기에 시간적 여유가 없는 경우 선택할 수 있는 옵션입니다. Windows Server 2008, Windows Server 2008 R2, SQL Server 2008, SQL Server 2008 R2가 첫 지원 대상입니다.
  • Announcing SQL Server Management Studio – 16.5.1 Release
    • SQL Server Management Studio의 최신 버전인 16.5.1이 릴리스되었습니다. 제품 출시 후 발견된 문제점들을 수정한 패치 성격의 업데이트 버전입니다.

활용 및 노하우

웹 캐스트

  • SQL Server + Java: What’s new
    • 새 Microsoft JDBC 드라이버를 통해 Java 기반 애플리케이션에서 SQL Server에 접속하여 쓸 수 있는 새로운 기능들을 소개하는 웹 캐스트입니다. 최근 JDBC 드라이버의 소스 코드를 GitHub 리포지터리에 게시하여 오픈소스화 하였으며, Maven 리포지터리를 통하여 JDBC 드라이버에 대한 종속성을 간편하게 추가할 수 있게 되었습니다.
  • Azure Media Indexer 2: Japanese support, punctuation improvements, no more time limit
    • 동영상에서 화자가 말하는 언어를 음성 인식하여 자막을 만들고 동영상 검색의 기본 데이터를 형성하는데 도움을 주는 Azure Media Indexer의 새 버전에서는 Microsoft Research의 연구 성과를 바탕으로 지속적으로 품질과 성능을 개선하고 있으며, 이번 릴리스에서는 일본어 음성 인식 지원, 10분 길이 제한 해제, 발음과 문법 품질 향상을 주안점으로 두고 있습니다.
  • Get Started with Azure Functions
    • Azure Function에 대한 튜토리얼 웹 캐스트입니다.
  • Digital marketing solutions on Azure
    • Orchard, Umbraco와 같은 유명 CMS 솔루션을 Azure 위에서 기술적인 지식 없이 손쉽게 구축하여 디지털 마케팅 전략에 활용할 수 있는 방안을 소개하는 웨비나 세션을 소개합니다.
  • Dev and test better in the cloud
    • Azure 및 클라우드 환경에서 개발과 테스트 전략을 더 효율적으로 수행할 수 있는 방법을 소개하는 무료 웹 캐스트입니다.

서드파티 소식

  • Kafka Connect for Azure IoT Hub
    • Azure IoT Hub에 연결하여 데이터를 Kafka로 보낼 수 있는 Connector의 오픈 소스 버전이 새롭게 공개되었습니다.

ClouDeveloper 페이스북 페이지에 댓글로 의견을 남겨주시면 뉴스 발행 및 각종 정보 전달에 반영하도록 하겠습니다. 고맙습니다.

의견 남기기: https://fb.com/cloudeveloper

[ClouDeveloper News – Azure Edition] 2016년 12월 1일

클라우드 컴퓨팅을 중심으로 관련된 여러 기술과 업계 소식을 매주 전하는 ClouDeveloper News를 시작합니다. 파일럿 프로그램으로 구상하여 운영 중에 있으며 추후 여러 피드백과 의견 수렴을 통하여 프로그램의 틀을 갖추어 나갈 예정이오니 많은 관심과 구독을 부탁드립니다.

Azure 서비스 공지 사항

새로운 제품 및 서비스

활용 및 노하우

웹 캐스트

  • Leverage the cloud for modern business: 무료 온디맨트 웹 캐스트로 기존 비즈니스에서 클라우드를 어떻게 접목할 수 있는지에 대한 일반론을 설명합니다.
  • Get started with Xamarin and Azure Webinar: 한국 시간으로 12월 3일 토요일 새벽 2시부터 진행되는 웹 캐스트로 Xamarin 개발 플랫폼과 Azure를 연동하는 자세한 방법을 설명합니다.
  • SQL Server on Linux: High availability and security: SQL Server on Linux가 Windows 버전과 같이 고가용성과 안정성, 그리고 보안을 준수할 수 있는지 궁금하기도하고 불확실하다는 생각을 가지고 계시다면 이 웹 캐스트를 확인해보실 것을 추천합니다.
  • Microsoft Ignite On-Demand: 지난 가을에 열린 Microsoft Ignite 2016의 모든 세션을 VOD로 시청할 수 있는 카탈로그 페이지가 열렸습니다.
  • Connect(); 2016 On-Demand: 지난 11월에 열린 Connect(); 2016의 모든 세션을 VOD로 시청할 수 있는 카탈로그 페이지가 열렸습니다.

서드파티 소식

  • Protect all of your public and hybrid cloud workloads on with Security: 엔드포인트 보안 및 침입 차단, VPN 등 다양한 보안 솔루션 포트폴리오를 제공하는 Fortinet이 Azure Platform의 각 영역에 대한 보안 솔루션을 제공합니다. https://www.fortinet.com/azure 에서 확인해보실 수 있습니다.

ClouDeveloper 페이스북 페이지에 댓글로 의견을 남겨주시면 뉴스 발행 및 각종 정보 전달에 반영하도록 하겠습니다. 고맙습니다.

의견 남기기: https://fb.com/cloudeveloper

IronPython으로 Windows NT 서비스 만들어서 띄우기

안녕하세요. Windows Azure MVP 남정현입니다.

IronPython은 이제 다른 Python Implementation과 어깨를 나란히 할 수 있는 수준까지 완성도가 개선되었습니다. Python을 이용해서 흔히 기대하는 NumPy, SciPy 같은 수학 및 공학용 라이브러리는 당연히 쉽게 처리할 수 있고, 이를 기반으로 하는 NLTK (Natual Language Tool Kit) 라이브러리도 약간의 불편함이 따르기는 하나 종속성을 충족하면 자연어 처리도 원활하게 수행합니다.

그리고 당연하다면 당연한 이야기이지만 Windows NT 서비스를 IronPython으로 구현하는 것도 생각해볼 수 있습니다. Windows NT 서비스를 관리 언어를 이용하여 개발하는 것 자체는 그렇게 새로울 것이 없습니다만, 한 가지 많이 오해를 하는 부분이 있는데 Visual Studio가 제공하는 템플릿이 아니면 만들 방법이 없는 것 처럼 여겨지는 것 같습니다. 그러나 실제로는 전혀 그렇지 않으며, .NET Framework의 실행 모델을 처리할 수 있는 프로그래밍 언어는 모두 간편하게 System.ServiceProcess.dll 어셈블리가 제공하는 SCM 상호 작용 컴포넌트를 쉽게 이용할 수 있습니다.

그렇다면 IronPython을 이용해서 Windows NT 서비스를 개발하려면 어떻게 해야 할까요? 생각보다 단순합니다. 준비물은 이 글을 쓰는 현 시점에서 최신 버전인 IronPython 2.7 패키지와 관리자 권한만 있으면 됩니다. 만약 sc.exe 유틸리티가 없다면 이 유틸리티가 이번 강좌에서는 꼭 필요하므로 Windows SDK를 찾아보시기 바랍니다.

초간단 IronPython 기반 Windows NT 서비스 코드 살펴보기

글을 쓰는 것이 무안할 정도로 정말 초간단합니다.

import clr
clr.AddReference(‘System.ServiceProcess’)
from System.ServiceProcess import ServiceBase

class MySvc(ServiceBase):
  def OnStart(self, args):
    ServiceBase.OnStart(self, args)
    print args
  def OnStop(self):
    ServiceBase.OnStop(self)

svc1 = MySvc()
ServiceBase.Run(svc1)

코드의 각각의 줄을 하나씩 살펴보도록 하겠습니다.

우선 처음의 세 줄은 CLR 모듈을 로드해서 System.ServiceProcess 어셈블리를 현재 IronPython의 스코프에서 사용할 수 있도록 준비하는 과정입니다. 관리되는 언어로 Windows NT 서비스를 등록하고 SCM과 상호 작용하기 위해서 필요한 모든 코드가 이 어셈블리에 들어있다고 보시면 되겠습니다.

그리고 Windows NT 서비스의 API를 객체 지향 방식으로 모델링한 ServiceBase 클래스를 상속받는 새로운 클래스를 하나 만들어야 합니다.

Python 문법에 익숙하지 않은 분들을 위하여 부연 설명을 더하면, 현재 스코프에 ServiceBase라는 클래스가 있고, 이 클래스를 상속받는 MySvc 클래스를 정의하고 있습니다. 그리고 따로 지시자는 없지만 이름이 같게 설정된 메서드는 Python 세계에서는 자동으로 메서드를 재정의한 것이 됩니다. 이에 따라, OnStart과 OnStop 메서드가 SCM에 의해서 자동으로 호출되는 메서드가 되는데, 서비스 시작 시 서비스가 잘 작동하고 있음을 알리기 위해 부모 클래스인 ServiceBase 클래스의 OnStart 메서드를, 그리고 프로세스 종료를 해도 괜찮음을 알리기 위해 OnStop 메서드를 호출합니다. 그리고 self라는 인자는 인스턴스 메서드임을 설명하는 것이며 동시에 여기에 인스턴스 참조가 전달됩니다.

그리고 따로 시작점이 있는 것이 아니라 Python 코드는 그 자체가 즉시 실행 가능한 Main 메서드 역할을 합니다. 그래서 곧바로 MySvc 클래스를 인스턴스로 만들어 ServiceBase.Run 메서드를 호출합니다.

SCM을 이용하지 않고 실행할 경우

ServiceBase.Run 메서드는 기본적으로 SCM과 상호 작용을 시작하기 위해서 필요한 기능들을 미리 제공합니다. 그런데 위의 코드를 일상적으로 사용하는 IronPython 콘솔에서 실행하면 어떻게 결과가 나타날까요? 아래와 같은 메시지가 나타납니다.

“명령줄 또는 디버거에서 서비스를 시작할 수 없습니다. 먼저 installutil.exe를 사용하여 Windows 서비스를 설치한 다음 서버 탐색기, Windows 서비스 관리 도구 또는 NET START 명령을 사용하여 시작해야 합니다.”

이런 오류 메시지가 나타납니다. 그런데 제가 하고 싶은 이야기는 정말 installutil.exe를 사용해야만 관리 언어로 만든 NT 서비스를 등록할 수 있는가에 대한 부분입니다. 결론부터 말하면 “아니오”입니다. installutil.exe를 사용하여 NT 서비스를 설치하기 위해서는 위의 코드 말고도 사실 설치 관리자 컴포넌트를 따로 구현해야 하는데, 이것을 Visual Studio Professional 이상의 버전에서는 템플릿으로 제공하고 있고 설치 프로젝트와 연계해서 만들 수 있도록 해주는 것입니다. 그러나 개인적으로는 이러한 설정을 마음에 들지 않습니다. 좀 더 간단하게 갈 수 있는 방법도 많으니까요.

그러면 installutil.exe를 대신할 도구가 있을까요? 바로 sc.exe입니다. sc.exe 자체는 개발된지 오래된 유틸리티이지만, 관리 언어로 만든 Windows NT 서비스까지도 매우 유연하게 지원합니다. 바로 EXE 파일로 만들어지는 NT 서비스에 한해서 그 진가가 십분 발휘됩니다.

SC.EXE 유틸리티를 사용하여 NT 서비스 등록하기

이제 SC.EXE 유틸리티를 사용하여 NT 서비스를 등록해보겠습니다. 그러나 SC.EXE 유틸리티로 서비스를 등록하려면 시스템 관리자 권한이 필요하므로 명령 프롬프트를 관리자 권한 또는 권한 상승 모드에서 시작해주셔야 합니다. 만약 설치 프로그램에서 구동한다면 설치 프로그램 초입에 권한 상승이 동반되므로 따로 신경쓸 것은 없습니다.

SC.EXE 유틸리티의 문법은 사소한 부분에서 실수하기 쉬우므로 문자그대로 아래와 같이 정확하게 입력해야 함을 유의하기 바랍니다.

sc create <서비스 이름> binPath= “<ipyw64.exe의 절대 경로> <IronPython 스크립트 파일의 절대 경로>”

sc create mysvc binPath= “C:Program FilesIronPython 2.7ipyw64.exe c:usersrkttu_000desktopservice.py”

다른 것보다도 binPath= 부분에 유의합니다. binPath = “~” 도 아니고 binPath =”~”도 아니며 오로지 binPath= “~” 로 해야만 올바른 문법으로 인지됩니다. binPath 옵션에 IronPython Non-Console 인터프리터의 경로와 함께 실제 구현 코드를 포함하는 IronPython 스크립트 파일을 지정했습니다.

주의할 것은 여기에 서술하는 모든 경로는 절대 경로로 서술해야 합니다.

서비스 테스트하기

정상적으로 서비스가 설치되었다면 “[SC] CreateService 성공” 이라는 메시지를 볼 수 있습니다. 그리고 서비스의 시작을 위해서 아래와 같이 명령어를 실행하거나 서비스 관리자에서 여러분이 등록한 서비스를 찾아 시작시킵니다.

C:Windowssystem32>net start mysvc
mysvc 서비스를 시작합니다..
mysvc 서비스가 잘 시작되었습니다.

그리고 서비스 중지도 잘 되는지 확인합니다.

C:Windowssystem32>net stop mysvc
mysvc 서비스를 멈춥니다..
mysvc 서비스를 잘 멈추었습니다.

팁 한가지

IronPython을 이용하여 Windows NT 서비스를 만들 수 있으므로, 복잡한 템플릿에 의존하거나 유틸리티를 사용하는 일 없이 기존 서버 로직을 얼마든지 NT 서비스로 옮길 수 있는 것은 참 바람직합니다. 하지만 NT 서비스는 디버깅하기 매우 불리한 구조를 가지고 있는데, 이를 극복할 방법이 없을지 고민을 해보게 됩니다.

Microsoft의 기술 자료 (http://msdn.microsoft.com/ko-kr/library/7a50syb3(v=vs.90).aspx) 의 내용을 참고하여 직접 서비스를 디버깅하는 것이 널리 알려진 방법입니다. 이 방법은 정말 살아있는 실제 서비스를 대상으로 디버깅을 하는 것이므로 보안 권한을 포함한 모든 사항이 가장 실제 운영 환경에 근접한 것입니다.

그러나 좀 더 단순하게 서비스 로직 자체에 대한 디버깅이나 검증이 필요하다면 다른 접근 방법이 더 좋을 수 있습니다. NT 서비스로 만들기에 앞서 보통의 콘솔 응용프로그램으로 띄울 수 있도록 핵심 로직만 발췌해서 가지고 오도록 하면, NT 서비스로 배포하기에 앞서서 핵심 로직 자체만 따로 평가할 수 있으므로 더 유용할 것입니다.

그리고 프로그램에 전달된 인자를 활용하여 -service 같은 문자열이 전달된 것을 확인할 때에만 ServiceBase.Run 메서드를 호출한다면 NT 서비스가 아닌 상태와 NT 서비스인 상태를 동시에 지원할 수 있어 더욱 유용할 것입니다.

Windows Azure를 통한 클라우드 서비스 확장성 포스터

안녕하세요. Windows Azure MVP 남정현입니다.


Windows Azure를 사용하면서 여러가지 서비스들을 많이 활용할 수 있지만, 역시 Windows Azure Platform을 제일 잘 설명할 수 있는 것은 확장성에 충분히 대응할 수 있는 유연한 아키텍처가 아닐까 싶습니다. 하지만 이러한 아키텍처를 어떻게 디자인하고 설계하고 수정해야 할지 개념을 잡기가 쉽지 않을 수 있는데요, 이러한 개념을 알기 쉽게 설명해주는 유용한 포스터를 하나 공유합니다.



아래 링크를 클릭하시면 포스터 PDF 파일을 내려받으실 수 있습니다. 포스터를 내려받아서 필요한 부분만을 읽어보시거나, 포스터 인쇄를 주문하셔서 잘 보이는 곳에 붙여놓고 활용하시면 좋을 것 같습니다. 🙂


cfile26.uf.1822613F5157B41E045499.pdf


감사합니다.

Windows Azure 웹 캐스트

안녕하세요. Windows Azure MVP 남정현입니다.


웹 캐스트 이벤트 홈페이지: http://msdn.microsoft.com/ko-kr/jj720372



2012년 후반에 접어들어서 새롭게 업데이트되는 Windows Azure의 다양한 내용을 미리 살펴보실 수 있도록 웹 캐스트를 촬영하였고 약 20여편의 내용을 포함하는 컬렉션이 Microsoft Showcase에 업로드되었습니다. 2012년 8월 여름까지 발표된 Windows Azure의 각종 서비스들에 대한 내용을 포함하고 있으며, Windows Azure Mobile Service에 대한 부분은 이후 블로그 아티클 등을 통하여 별도로 내용을 전개해볼까 합니다.



  1. [Windows Azure Platform/Microsoft 웹 캐스트] – #1. Windows Azure 개요

  2. [Windows Azure Platform/Microsoft 웹 캐스트] – #2. Windows Azure 웹 사이트 소개

  3. [Windows Azure Platform/Microsoft 웹 캐스트] – #3. Azure에서 실행되는 ASP.NET 웹 사이트 만들기

  4. [Windows Azure Platform/Microsoft 웹 캐스트] – #4. WPNS와 Windows Azure로 알림 서비스 구현하기

  5. [Windows Azure Platform/Microsoft 웹 캐스트] – #5. Windows Azure 미디어 서비스 API 활용하기

  6. [Windows Azure Platform/Microsoft 웹 캐스트] – #6. Windows Azure 클라우드 서비스

  7. [Windows Azure Platform/Microsoft 웹 캐스트] – #7. Cloud Service 프로젝트 처음 만들어보기

  8. [Windows Azure Platform/Microsoft 웹 캐스트] – #8. 기존 ASP.NET 웹 사이트를 Azure로 옮기기

  9. [Windows Azure Platform/Microsoft 웹 캐스트] – #9. Windows Azure 가상 컴퓨터

  10. [Windows Azure Platform/Microsoft 웹 캐스트] – #10. Windows 가상 컴퓨터 소개

  11. [Windows Azure Platform/Microsoft 웹 캐스트] – #11. SQL 데이터베이스 소개

  12. [Windows Azure Platform/Microsoft 웹 캐스트] – #12. SQL 데이터베이스 실습하기

  13. [Windows Azure Platform/Microsoft 웹 캐스트] – #13. Windows Azure 저장소

  14. [Windows Azure Platform/Microsoft 웹 캐스트] – #14. Windows Azure 저장소 실전 예제 살펴보기

  15. [Windows Azure Platform/Microsoft 웹 캐스트] – #15. Windows Azure 서비스 버스

  16. [Windows Azure Platform/Microsoft 웹 캐스트] – #16. 서비스 버스 Queue와 Topic

  17. [Windows Azure Platform/Microsoft 웹 캐스트] – #17. 클레임 기반 인증 구현하기

  18. [Windows Azure Platform/Microsoft 웹 캐스트] – #18. 확장성, 전역성, 높은 가용성을 지닌 앱 만들기

  19. [Windows Azure Platform/Microsoft 웹 캐스트] – #19. 캐시 클러스터를 이용하여 신축성있는 클라우드 서비스 만들기

  20. [Windows Azure Platform/Microsoft 웹 캐스트] – #20. 트래픽 관리자를 이용한 24×365 글로벌 서비스 구축하기

감사합니다.



[#M_만약 위의 블로그 페이지들이 잘 보이지 않으면 여기를 눌러주세요.|접기|

Windows Azure 웹 캐스트 목록



  1. Windows Azure 개요: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=9de78a72-c744-49ca-925c-5b45336b0a5c

  2. Windows Azure 웹 사이트 소개; http://www.microsoft.com/en-us/showcase/details.aspx?uuid=a804e50e-98e3-427c-bd9f-842a97a7e31f

  3. Azure에서 실행되는 ASP.NET 웹 사이트 만들기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=8a7d7867-677a-42d3-ad60-002e5fdfaebf

  4. WPNS와 Windows Azure로 알림 서비스 구현하기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=c596ada7-7a12-4277-a25e-f97b4e097175

  5. Windows Azure 미디어 서비스 API 활용하기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=24c658f5-6c27-4790-9c48-81b84dcc4a3b

  6. Windows Azure 클라우드 서비스: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=15ab73ba-93df-4808-b7ea-f6423dfa3844

  7. Cloud Service 프로젝트 처음 만들어보기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=5caa2a2e-1fd5-4711-9089-442b6966426c

  8. 기존 ASP.NET 웹 사이트를 Windows Azure로 옮기기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=a6eeffc3-6c1e-4740-b17d-25710bd3f979

  9. Windows Azure 가상 컴퓨터: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=a5bc31f9-cd26-477d-9c4d-cd80633d89fd

  10. Windows 가상 컴퓨터 소개: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=6d7a370b-2567-49f5-9896-1ee272aabbc4

  11. SQL 데이터베이스 소개: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=d8c131d2-9563-499c-8de2-8937778b153e

  12. SQL 데이터베이스 실습하기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=07910327-f9c7-451c-8f20-4096537866c3

  13. Windows Azure 저장소: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=3e893926-188f-4331-890d-13a10a0f9fd7

  14. Windows Azure 저장소 실전 예제 살펴보기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=54b98714-8d26-4e08-8ec0-3588561f5d47

  15. Windows Azure 서비스 버스: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=e8ddec3e-ad3b-4f3c-b62e-4ca6d8aca8bd

  16. 서비스 버스 Queue와 Topic: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=2e5a4ad7-de01-4488-a9e2-bec763fd0d58

  17. 클레임 기반 인증 구현하기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=ae7943ef-45f3-488c-9449-6a7803781a62

  18. 확장성, 전역성, 높은 가용성을 지닌 앱 만들기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=a1e07ae7-566e-4c41-824d-ce8238120be3

  19. 캐시 클러스터를 이용하여 신축성있는 클라우드 서비스 만들기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=36e2ddbf-35eb-4c80-8538-cac63908bd0e

  20. 트래픽 관리자를 이용한 24×365 글로벌 서비스 구축하기: http://www.microsoft.com/en-us/showcase/details.aspx?uuid=226fc0eb-5f9e-43c8-8a17-4af8e74fc42d
_M#]

 

클라우드 시대의 피아식별: Access Control #2

지난번 글에 이어서 Access Control을 실제로 ASP.NET 웹 사이트에 사용하기 위한 방법을 살펴보도록 하겠습니다. Access Control은 이제 독립적인 Building Block 중 하나로 언급되고, AppFabric이라는 브랜드 네임은 더 이상 붙지 않습니다.


주: 글 작성의 편의상 ACS 혹은 액세스 제어 서비스라는 말을 혼용해서 사용하려고 합니다.


Access Control 서비스 신청하기


Access Control 서비스는 2012년 여름 현재 아직 새 포털 사이트 (manage.windowsazure.com)에서 프로비져닝하거나 관리할 수 있는 UI가 없습니다. 그러나 빠른 시일 내에 추가가 될 것으로 예상되며, 현재는 실버라이트 기반의 포털 사이트 (windows.azure.com)에서 프로비져닝하고 관리할 수 있습니다.


로그인하고 난 다음에 화면 좌측 하단의 “서비스 버스, 액세스 제어 및 캐시” 탭을 클릭합니다. 사용중인 서비스가 있다면 아래와 같이 나타날 수 있으며, 다른 서비스가 없다면 상단 리본 메뉴에서 “새로 만들기” 버튼을 클릭합니다.



이름에서 알 수 있듯이 네임스페이스 아래에 다수의 서비스가 연결되어있습니다. 관련성이 떨어져보이긴 하지만 캐시도 네임스페이스 아래에 배치하여 프로비져닝할 수 있도록 하고 있습니다. 여기서 한 가지 유의하실 것이 하나 있는데, 실제로 사용하려는 서비스에만 체크해야 불필요한 지출이 발생하지 않습니다. 그리고 이곳의 캐시는 최근 소개된 Dedicated Cache와는 다른 것으로 고성능을 전제로 하지만 상대적으로 작은 용량, 높은 비용이 특징입니다.



서비스 버스 신청 후에는 내부 활성화 및 프로비져닝 절차가 복잡한 것으로 추정되고, 이 때문인지 다른 클라우드 서비스보다 다소 시간이 많이 걸립니다. 완전히 사용할 수 있는 상태가 되면 아래 그림과 같이 항목이 나타나며, 특별히 액세스 제어를 신청했다면 상단 리본 메뉴의 액세스 제어 서비스 버튼이 활성화됩니다.


NOTE: 아마 더 이상 그런 일은 없겠지만 ACSV1으로 신청해서 사용 중인 계정을 아직도 가지고 계시다면, ACSV2로 업그레이드를 따로 요청하셔야 합니다. (아마 지금즈음이면 어떤 형태로든 ACSV2 기반으로 마이그레이션되었을 것으로 봅니다.)



ACS 관리하기


ACS 포털은 각 서비스 노드마다 따로 제공되는 것으로 위의 그림에서 액세스 제어 서비스 버튼을 클릭하면 아래 그림과 같이 새 웹 페이지가 나타날 것입니다. 접속 주소의 패턴은 https://[네임스페이스 이름].accesscontrol.windows.net/v2/mgmt/web 과 같습니다. 



그런데 실버라이트 포털에서 그냥 나와버려서 당황하셨을 수도 있는데, 걱정하지 않으셔도 됩니다. 로그인 상태는 지금 보시는 포털과 실버라이트 포털 사이에 모두 세션이 일치된 상태로 계속 유지가 되기 때문에 (즉 SSO를 구현하고 있기 때문에) 사용에 전혀 지장이 없습니다.


ACS는 여러분이 어떻게 설정하는가에 따라 전적으로 동작이 달라지게 되겠지만 보통은 (1) ID 공급자를 지정하여 ACS 서비스가 여러분의 응용프로그램을 위하여 어떤 ID 공급자와 계약을 맺을 것인지 정의하고, (2) ACS에 여러분의 응용프로그램의 속성을 등록하여 상호 작용에 필요한 정보를 사전에 관리하고, (3) ID 공급자와 응용프로그램 사이에 주고 받을 데이터의 내용을 관리하는 것으로 설정을 다룹니다. 그리고 지금 이야기한 단계 모두 ACS 사이트의 자동 생성 기능을 사용하면 어렵지 않게 초기화할 수 있습니다. 이번 블로그 글에서는 ACS 첫 설정에 대한 내용을 살펴보려고 합니다.


ID 공급자 추가하기


당연한 이야기이지만 Windows Azure는 Windows Live ID (혹은 앞으로는 Microsoft ID라고 불리겠군요)를 기반으로 모든 서비스 프로비저닝이 이루어지므로 기본적, 종속적, 필수적으로 ACS의 기본 ID 공급자로 자동 구성되어있으며 동시에 뺄 수 없도록 보호되어있습니다.


Windows Live ID 공급자를 제외하면 웹 관리 UI 상으로는 아래 그림과 같은 종류의 ID 공급자들을 지원합니다.



별 다른 노력 없이 쉽게 추가할 수 있는 공급자 종류로 Google과 Yahoo!가 있고, 기존의 인프라가 선행되어야 하는 공급자 종류로 Facebook와 WS-Federation ID 체계를 지원하는 공급자를 택할 수 있게 되어있습니다. 만약 여러분이 작성하려는 웹 서비스가 소셜 네트워크와 친화적일 필요가 있다면 ACS를 사용해서 한 번에 Facebook과 Google, Yahoo!를 인증 공급자로 택하여 SSO를 자동으로 구현할 수 있는 것입니다.


저는 여기서 간단하게 Google을 ID 공급자로 등록해보도록 하겠습니다. 기회가 되면 Facebook을 활용하는 것도 글로 다루어보도록 하겠습니다.



로그인 페이지 상에 표시할 상세 정보를 지정할 수 있는 페이지가 보입니다. 특별한 설정 없이 저장 버튼을 눌러도 무방하므로 계속 진행합니다.



새 ID 공급자와 ACS 간의 연동이 완료되었습니다. 계속해서 신뢰 당사자 응용프로그램 등록 절차를 진행합니다.


응용프로그램 정보 등록하기


ACS를 실제로 사용하려는 웹 사이트의 정보를 등록해야 합니다. 위의 화면 상 왼쪽 메뉴에서 “신뢰 당사자 응용프로그램” 메뉴를 클릭하고 추가 링크를 클릭하면 아래 그림과 같이 등록 절차가 시작됩니다.


요구하는 항목의 수가 많아 부담스러운 페이지이긴 하나 모두 의미가 있는 항목들이므로 하나씩 찬찬히 살펴보면서 진행해야 합니다.




  • 이름: 관리 도구나 기타 메타데이터 상에서 표시할 알아보기 쉬운 이름을 입력하며, 보통은 도메인 이름 약칭을 적어주면 유용합니다.

  • 모드: 수동으로 설정 입력에 체크합니다.

  • 영역: ACS로 인증을 거친 이후에 실제로 전달받은 토큰이 쓰일 수 있는 URL 경로를 지정합니다. 사이트 전체를 ACS 인증 체제로 확정하려면 그냥 도메인을 포함하여 루트 URL을 지정하고, 그렇지 않은 경우에는 웹 서버 설정과 맞추어 지정해야 합니다. 동일 도메인이라 할지라도 이 영역을 벗어나면 먼저 인증하여 받은 토큰은 자동으로 무력화됩니다.

  • 반환 URL: XML 형태로 넘어오는 보안 토큰값을 실제로 받아서 처리할 URL을 지정합니다. 이 URL을 정확히 지정하여 로그인해서 넘어오는 어떤 임의의 사용자가 실제 여러분이 가지고 있는 사용자 DB와 일치하는 동일 사용자인지 피아식별하고 판정할 수 있습니다.

  • 오류 URL: 옵션 항목이며, 오류가 발생했을 때 사용자가 당황하지 않도록 안내문구를 표시해줄 URL을 지정하여 서비스에 대한 클레임을 최소화하는데 활용할 수 있습니다.

  • (계속)



  • 토큰 형식: 토큰 데이터를 ACS에서 응용프로그램으로 넘길 때 어떤 형태로 패키징해서 보낼 것인지를 결정하는 부분으로, 이번 강좌에서 사용하려는 프레임워크인 Windows Identity Foundation을 고려하여 SAML 2.0으로 지정합니다. 만약 다른 프레임워크를 사용하려는 경우 적절한 포맷을 선택합니다.

  • 토큰 암호화 정책: ACS에서 토큰을 넘겨받을 때 인증서와 키 값을 이용하여 토큰을 암호화해서 넘겨받아야 하는 경우가 있을 때 암호화 사용을 선택합니다. 여기서는 암호화를 필수적으로 사용해야 하는 경우가 아니므로 암호화 정책을 기본값으로 설정하겠습니다.

  • 토큰 수명: 토큰이 발행되고 난 뒤에 만료되기까지의 기간을 설정합니다. 초 단위의 값이며 기본값은 10분입니다.

  • ID 공급자: 앞 단계에서 등록한 공급자들 중에서 지금 등록하려는 응용프로그램과 연결하려는 ID 공급자를 따로 지정할 수 있습니다. 보통은 네임스페이스와 연결된 모든 ID 공급자를 선택할 수 있지만 편의에 따라 설정을 바꿀 수 있습니다.

  • 규칙 그룹: ID 공급자와 이 응용프로그램 사이에 어떤 정보를 주고 받을 것인지에 대한 구체적인 설정을 보관하는 규칙 그룹을 선택할 수 있습니다. 이미 만들어진 규칙 그룹을 고르거나 새로운 규칙 그룹을 만들어 독립적인 설정을 구성할 수 있습니다.

  • 토큰 서명: 토큰 서명 시 사용하려는 인증서를 고를 수 있는데, 자체 제공되는 ACS용 인증서를 이용하거나 여러분이 기존에 소유하고 있는 인증서를 대신 지정할 수 있습니다. 선택 옵션에 따라 하단에 새 옵션 필드가 하나 더 늘어날 수 있습니다.

  • 인증서: 토큰 서명에 사용할 인증서를 직접 지정하도록 옵션을 변경하면 나타나는 옵션 필드로 X.509 인증서와 연결되어있는, 비밀 키를 포함하는 PFX 파일과 비밀 키 값을 지정해야 합니다.

ACS의 인증은 사이트 도메인 경계를 넘나드는 형태로 진행되기 때문에, 위의 옵션에서 잠시 나왔던 것 처럼 localhost 주소가 등록하려는 Application의 실제 주소가 될 수 있습니다. 달리 표현하면, VPN 환경과 같이 외부와 격리되어있으면서 실제 VPN 네트워크 안에 참가해야만 유효한 특별한 형태의 네트워크일지라도 ACS나 실제 ID 공급자와 통신하는데 문제가 없다면 좀 더 견고한 인트라넷-인터넷 간 상호 인증을 구현하는 것도 얼마든지 가능합니다. 그리고 localhost 주소를 지원하므로 당연히 Visual Studio나 Eclipse 등의 개발 도구 등으로 만든 Ad-hoc 서버의 주소를 넣어서 ACS 기능을 테스트하는 것도 당연히 가능합니다.


저의 경우에는 테스트를 위하여 Visual Web Developer 2010 Express Edition을 이용하여 ASP.NET MVC 프로젝트를 만들고 이 주소를 Application으로 등록하기로 하였습니다. Visual Studio 개발 서버나 IIS Express 모두 Ad-hoc 서버이므로 정확한 포트 번호의 확인을 위해서 만든 웹 프로젝트의 속성에서 포트 번호를 확인해야 합니다.



제가 테스트를 위해서 확정해야 하는 주소는 http://localhost:50086 이군요. 이 주소를 바탕으로 신뢰 응용프로그램 정보에 다음과 같이 정보를 등록하려고 합니다.



  • 이름: MyApp

  • 수동으로 설정 입력

  • 영역, 반환 URL, 오류 페이지 주소: http://localhost:50086/

  • ID 공급자: Google 및 Windows Live ID

  • 기타 항목은 모두 기본값으로 설정합니다.

저장 버튼을 누른 다음에는 아래와 같이 응용프로그램 정보가 새로 등록된 것을 볼 수 있습니다.



이제 규칙 그룹의 세부 설정을 완성해야 합니다.


규칙 그룹 구성하기


규칙 그룹 링크를 화면 왼쪽에서 클릭하면 아래 그림과 같이 응용프로그램 등록 과정에서 자동으로 추가된 항목이 나타날 것입니다. 규칙 그룹 이름을 클릭하여 상세 정보를 확인합니다.



규칙 그룹의 상세 내역을 확인해보면 처음 만들어진 그룹이기 때문에 아무것도 등록되어있지 않은 것을 볼 수 있습니다. 규칙 그룹의 이름 같은 부분들은 역시 이곳에서 편집이 가능하고, 어떤 규칙 그룹과 앱이 연결되어있는지도 한 번에 파악할 수 있습니다.



하단의 생성 링크를 클릭하여 자동으로 ID 공급자와 응용프로그램들 사이에 필요한 모든 규칙을 한 번에 만들도록 구성할 수 있습니다. ID 공급자들이 ACS에 제안하는 기본적인 옵션들을 한번에 만들어주므로 일반적인 연동을 위해서는 보통 이 작업 한 번으로 필요한 모든 기능을 자동으로 구성할 수 있게 되어있습니다.



규칙들이 아래 그림과 같이 등록된 것을 볼 수 있습니다. ID 공급자별로 제공할 수 있는 클레임과 클레임의 출처, 그리고 간단한 설명이 열거되어있습니다.



Google의 경우 사용자의 Google 계정과 연결된 메일 주소, 사용자 이름, 그리고 고유 식별자를 제공하며, Windows Live ID의 경우에는 다른 정보 없이 최소한의 식별자만을 제공하고 있습니다. 이후에 다시 살펴보겠지만 사실 모든 ID 공급자들이 친절하게 e-mail 주소를 공개한다는 보장은 할 수 없습니다. 그렇기 때문에 파악이 쉬운 e-mail 주소와 같은 클레임을 직접 사용하려고 하기 보다는 고유 ID 값을 근거로 새로운 프로필을 만들도록 권하는 방식이 ACS 사용 시에는 더 좋은 방법이라고 할 수 있습니다.


마무리


이제 기본적인 구성이 모두 완료되었습니다. 실제 응용프로그램에서 ACS와 연동하여 SSO를 어떻게 구현할 수 있는지 그 내용을 다음번 강좌때 올리도록 하겠습니다.

Windows Azure 관리자 포탈 사이트에 대하여

안녕하세요. Windows Azure MVP 남정현입니다. 오늘은 Windows Azure 관리자 포탈에 대해서 한 가지 이야기를 드릴까 합니다. 현재 Windows Azure는 Preview 버전의 포탈과 Retail 버전의 포탈로 나누어서 서비스가 제공되는 상황인데, 그렇다보니 어디를 어떻게 들어가서 이용해야 하는지 햇갈릴만큼 다소 복잡한 상태입니다.


일단 두 포탈 사이에 가장 큰 기술적 차이는, Retail 버전의 경우 Silverlight로 서비스를 제공하는 것이고 접속 주소는 windows.azure.com 입니다. 그리고 Preview 버전은 HTML5로 서비스를 제공하는 것이며 manage.windowsazure.com이 접속 주소입니다. 양쪽 사이트의 모습은 아래 그림과 같이 차이가 납니다.


Retail 버전의 관리자 포탈 (windows.azure.com으로 접속)



Preview 버전의 관리자 포탈 (manage.windowsazure.com으로 접속) 



Preview Portal의 경우 계속해서 기능을 개발 중에 있으며, Azure Web Site, Azure Virtual Machine, Azure Media Service에 대한 관리 및 프로비져닝 기능을 제공합니다. 반면 Service Bus나 Access Control과 같은 Cloud Service와 연계되는 고급 Building Block 서비스들은 Preview Portal 아닌 Retail Portal로 가서 프로비져닝하거나 관리해야 합니다. 이후에는 모든 서비스들이 새 포탈쪽으로 제공이 될 예정에 있습니다.


만약 실무에서 SLA 계약을 지켜줄 수 있는 서비스들로만 안전하게 Windows Azure를 사용하기 원하신다면, Preview Portal을 통해서 상품을 프로비져닝하지는 마시고, 새 업데이트 소식이 나오기 전까지는 windows.azure.com에서만 서비스를 사용하시는 것이 정확합니다. 포탈을 포함하여 Azure Web Site, Azure Virtual Machine, Azure Media Service, Azure Virtual Network는 모두 Preview 상품이기 때문에 아직 완전한 상태는 아닙니다.


이 외에도 SQL Database (구 SQL Azure), Access Control 또한 자체 포탈을 현재는 별도로 운영을 하고 있으므로 세부적인 설정은 메인 관리 포탈을 통해서 접근하고 관리할 수 있으므로 참고하시면 도움이 될 것입니다.

최신 웹 사이트 & 웹 앱 개발을 위한 웹 매트릭스 도서를 출간하였습니다.

 

 

안녕하세요. 남정현입니다. 이번에 출간한 책은 웹 매트릭스에 대한 실전 사용 가이드 및 예제 중심의 도서인 “최신 웹 사이트 & 웹 앱 개발을 위한 웹 매트릭스” 도서입니다. 웹 매트릭스, ASP.NET, Razor View Engine을 사용하여 웹 프로그래밍을 하는 방법을 상세히 설명하고, HTML5에 대한 다양한 내용을 예제와 함께 살펴볼 수 있는 책입니다.

이번 책은 한국기술교육대학교에 재학 중이신 허찬 (http://hahaheo.com/, Twitter: @hahaheo)님과 함께 저술한 책으로, 허찬님께서는 Imagine Cup 2011 USA Windows Phone 7 Challange 부문에서도 전세계 2위를 수상한 뛰어난 IT 기술 전문가입니다. 책을 쓰는 과정에서 여러모로 우여곡절도 많았고 스케줄 맞추기도 쉽지 않았지만 끝까지 같이 책을 저술하여 펴낼 수 있도록 도와주신 것에 큰 감사의 인사를 드리며, 더불어서 두 사람의 여러가지 난해한 스케줄과 작업 상의 문제를 해결해주시고 끝까지 지원해주신 홍성근 팀장님께도 감사의 인사를 드립니다.

책에 대한 추천사

기업에게는 변화의 순간이란 것이 있습니다. 제가 마이크로소프트에 있던 시절도 PC에서 웹으로
제품의 체질이 넘어 가려 하던 변화의 순간이었습니다. 그러한 변화가 성공적이었는지 평가하는 것은 후일의 몫이지만, 모든 변화의 과정은 현장에서
리얼타임으로 목격할 수도 또 공동체와 공유도 가능한 일이기에 늘 중요합니다. 웹매트릭스라는 웹 개발 툴은 마이크로소프트가 근래에 겪은 변화
과정의 일환이자, 일종의 상징이기도 했습니다. 저자 허찬씨는 당시부터 여러 커뮤니티 활동에서 리더십을 발휘하며, 그 변화의 긍정적 확산에 늘
주역으로 활동해 왔습니다. 웹매트릭스 서적의 한글판이 허찬씨의 노력에 의해 나오는 일은 그런 면에서 의미가 크다 할 수 있습니다. Razor가
가져 온 경쾌한 문법에 기존의 ASP.NET의 상식이 깨진 순간을 아직도 기억합니다. 그 기분 좋은 각성을 여러분도 본서와 함께 느낄 수 있기
바랍니다.
– 김국현 / editoy.com 설립자 및 개발자

단순히 정보 공유와 하이퍼링크로 대변되던 웹은 N-screen
시대를 맞아 바야흐로 중심 플랫폼이 되고 있습니다. 이런 대세에 맞춰 Microsoft에서는 누구나 웹 사이트를 제작할 수 있도록 서버와
데이터베이스, 심지어 오픈 소스 CMS까지 포함되어 있는 WebMatrix를 선보였습니다. 차세대 웹 표준 기술인 HTML5까지 끌어안고 있는
WebMatrix. 웹 개발에 첫 발을 내딛는 사람들이라면 이 책을 통해 가장 빨리 “웹”이라는 신세계와 만날 수 있으리라 믿습니다.

고경희 / IE MVP

책에 대한 정보

책을 구입할 수 있는 곳

감사합니다.

ASP.NET과 IIS 7을 위한 로드 밸런싱 전략과 기초적인 이야기, 그리고 Azure Platform

요즈음 클라우드 서비스들을 이용하다보면, 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에 가면 이러한 방법을 자세히 설명한 아티클도 있습니다만 간단한 도구도 드리고, 코드 조각도 드리니 프로그램에 넣어 활용하시면 더 편리할 것입니다.


cfile23.uf.127986354E6E12A427F866.zip


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(“<machineKeyn”);
            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를 구축해보는 것도 의미가 있을 것입니다.

사내 인프라와 인트라넷 개발은 이제 Office 365가 좋은 선택입니다.

요즈음은 회사의 분야나 크기, 규모를 막론하고 누구나 자체적인 전산망을 구축하기 원하고, 자체적인 협업 사이트를 구축하기 원하며, 자체적인 통합 커뮤니케이션 시스템을 구현하기를 원합니다. 제대로만 구축된다면 참 편리하게 쓸 수 있고 회사가 빠르게 성장하는데 많은 도움을 줄 것이라는 것을 익히 보고 들어왔기 때문이죠. 하지만 생각만큼 쉬운 일이 결코 아닙니다. 경우에 따라서는, 회사가 원래 목표로 세웠던 대외적인 활동보다도 더 큰 역량이 들어가서 배보다 배꼽이 더 큰 일로 빠지는 경우도 많으니까요.

이번에 제가 다녀온 Office 365 MVP Day에서는 많은 이야기들이 있었지만 개인적으로는 Windows Azure Platform이나 기타 클라우드 컴퓨팅 플랫폼과 연결될 수 있는 Office 365만의 고유한 기능들에 대해서 가능성을 조사해보고 타진하는 것을 저만의 즐거움으로 삼을 수 있었습니다.

Exchange Web Service Managed API

다른 Microsoft 서비스들과 마찬가지로 Office 365 역시 독창적인 API를 제공합니다. EWS Managed API를 사용하여 조직 내 E-MAIL 계정 사용자의 작업을 대행하거나, 개인의 일정 정보를 검색하거나, 메일 내용을 검색하는 등의 서비스를 기존의 Windows Application에서는 물론, 여러분이 만들 고유한 웹 서비스 및 모바일 애플리케이션에서도 구현할 수 있습니다. 아래는 Epience에서 근무하시는 최정우 차장님께서 Demo로 보여주신 EWS를 이용하여 만든 Web Mail 시스템의 실행 예시입니다.

EWS Managed API 자체는 Exchange Server에서 제공하는 API를 기반으로 만들어진 것이기 때문에, 정확한 서비스 위치만 알고 있다면 XML Web Service를 처리할 수 있는 프로그래밍 언어에서는 EWS를 이용하여 필요한 작업을 수행할 수도 있습니다. http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=17947 에 게시된 문서를 통하여 다양한 프로그래밍 언어와 환경에서 EWS Online API를 사용하는 예시를 살펴보실 수 있습니다. 🙂

SharePoint Portal Development with Office 365

SharePoint는 기본적으로 협업을 위한 위키 페이지 작성, 문서 공유 등의 작업을 수행할 수 있도록 디자인된 기업용 맞춤형 포털 서비스를 제공합니다. 그렇지만 클라우드 버전의 SharePoint Online에서는 이 외에도 클라우드 기반 시스템으로 갖추어야 할 기본적인 소양으로 많이 꼽히는 Claim-based Authentication이나 Data Conversion/Migration 등의 기능도 제공하고 있습니다.

그리고 종전의 Standalone 버전의 SharePoint와는 달리, 클라우드 환경에서는 타 고객들에게 금전적, 시간적 손해를 끼칠 가능성을 사전에 차단하기 위하여 클라우드 서비스에 대해서 영향을 주지 않을것이라고 확신할 수 있는 컨텐츠만을 제작할 수 있는 SharePoint Designer 이외의 모든 코드들이 샌드박스 환경 안에서 수행됩니다.

전적으로 개발자의 재량에 따른 것이지만 간단한 전자결재 시스템 역시 SharePoint를 통하여 구축하는 것이 가능합니다. 좀 더 자세한 내용은 http://msdn.microsoft.com/en-us/sharepoint/gg153540.aspx 에서 확인해보실 것을 권합니다.

Microsoft표 온라인 서비스의 이점

클라우드 서비스를 제공하겠다고 나서는 업체들은 매우 많습니다. 그렇지만 이러한 클라우드 서비스를 단순히 제공한다는 사실만을 너무 강조한 나머지 기본에 충실하지 못한 경우를 자주 보게 되는데, 이는 달리 표현하면, “바퀴를 붙여 잘 굴러가게 만들었으니 자동차로서의 기능을 지원한다”고 설명하는 것과 같은 오류가 될 수 있습니다. Microsoft가 제공하는 온라인 서비스들은 이러한 오류에 빠지지 않도록 지속적으로 기능을 개선하고, 기본에 충실하면서도, 신뢰성이 높은 서비스들로 구성되어있다는 점에서 이번 Office 365의 런칭은 개인적으로 Windows Azure Platform이 런칭될 때 못지 않은 기대감을 가지게 합니다.

조만간 국내에서도 KT를 통하여 Office 365 서비스를 신청할 수 있게 될 것으로 보입니다. Office 365의 기본 기능들만 사용해도 훌륭하지만 이제 클라우드 시대에 맞추어 여러분도 다른 업체에 여러분의 시스템을 맡기는 일 없이 여러분의 입맛에 맞게 회사 내 인트라넷 시스템과 인프라를 DIY할 수 있습니다. 🙂