블로그 이미지
평범하게 살고 싶은 월급쟁이 기술적인 토론 환영합니다.같이 이야기 하고 싶으시면 부담 말고 연락주세요:이메일-bwcho75골뱅이지메일 닷컴. 조대협


Archive»


 
 

요즘 마이크로소프트의 행보를 보면서


조대협 (http://bcho.tistory.com)


근 1~2년간, IT 솔루션에 대한 비지니스가 많은 변화를 겪고 있습니다. 전통적인 라이센스 기반의 영업을 통한 엔터프라이즈 시장은 점점 매출이 떨어져가고 있고, 클라우드와 오픈소스 서브스크립션 모델 기반의 비지니스가 활성화 되어가는 상황에서, 공룡 IT 기업들이 변화를 시도하고 있습니다.


거대 공룡인 IBM의 경우 클라우드 컴퓨팅에 집중하기 이해서 소프트레이어 클라우드 (http://www.bloomberg.com/news/articles/2013-06-04/ibm-to-acquire-cloud-computing-provider-softlayer-technologies) 를 인수하였고, PaaS 서비스인 블루믹스를 개발하여 서비스 하고 있습니다. 얼마전에는 Node.js로 프레임워크로 유명한 StrongLoop 를 인수하였습니다. https://developer.ibm.com/bluemix/2015/09/10/ibm-acquires-strongloop/

그렇지만 아직까지 큰 존재감은 주고 있지 않는것 같습니다.


세일즈 포스의 경우 PaaS 클라우드로 유명한 Heroku를 인수했지요. http://www.salesforce.com/company/news-press/press-releases/2010/12/101208.jsp PaaS 플랫폼중에 접근성이 좋고, 많은 플랫폼 포트폴리오를 가지고 있어서, 나중에 강한 클라우드 벤더가 되지 않을까 합니다.


이러한 공룡 IT 기업들의 변화속에서 요즘 계속해서 눈에 띄는게 마이크로 소프트입니다. 윈도우즈와 .NET 기반의 폐쇄적인 플랫폼 생태계를 가지고 있어서 한계로 인식이 되었는데, 요즘 무섭게 기업 인수와 오픈 생태계로 나오면서 변화를 시도하고 있습니다.


얼마전에는 모바일 앱 크로스 플랫폼인 Xamarine을 인수하였고 https://xamarin.com/pr/xamarin-microsoft-partner

MS SQL의 Linux 지원을 공표하였습니다. https://www.microsoft.com/en-us/server-cloud/sql-server-on-linux.aspx

그러더니 오늘은 소프트웨어 스위치를 Debian Linux 기반으로 개발하여 발표 하였고 http://www.theregister.co.uk/2016/03/09/microsoft_sonic_debian/

몇일 전에는 이클립스 IDE 플랫폼에 합류 하였습니다. https://blogs.msdn.microsoft.com/visualstudio/2016/03/08/microsoft-joins-the-eclipse-foundation/

이뿐 아니라 R 언어를 지원하기 위해서 Visual Studio에 R 지원 기능을 탑재하였고 

http://blog.revolutionanalytics.com/2016/01/r-coming-to-visual-studio.html

비주얼 스튜디오 코드를 오픈소스로 전환해 버렸습니다. http://www.bloter.net/archives/244097

node.js도, 기존 구글의 V8엔진에서, 새롭게 포크하여 자사의 차크라 자바스크립트 엔진을 기반으로 한 node.js를 제공하겠다고 발표하였습니다. http://www.infoworld.com/article/3024271/javascript/nodejs-welcomes-microsoft-chakra-javascript-engine.html

얼마전에는 구글이 영상 인식이 가능한 Vision API의 클라우드 버전을 발표하더니만, 마이크로 소프트도 https://www.projectoxford.ai/vision 프로젝트를 통해서 Vision API 를 발표하였습니다.


아침에 일어나면 하나씩 빵빵 터지는지라, 다 적기도 어렵습니다. 

거대 공룡 기업이 이렇게 빠르게 변화에 대응하면서 변화를 따라잡는거 보면 놀랍기도 하고, 다음 기술을 이끌어갈 주자로써 마이크로 소프트를 무시할 수 없겠구나 하는 생각이 듭니다.



이러한 많은 변화는 나델라 CEO가 취임하고서 벌어진 변화인데, 국내 대기업들도 변화에 적응하기 위해서 많은 시도를 하고 있지만, 시장에 큰 임팩트를 주거나 대단한 변화라는 가시성을 보여주지는 못하는 것 같습니다. 

아마 나델라 같은 혁신적인 리더 부재가 아닐까 조심스럽게 추측해보는데...


어쨌거나, 공룡 IT 기업들도 빠른 변화를 진행하고 있는 중간에... 나는 어떻게 변화해야 할까를 고민해봅니다.





한마디로 이야기 하자면

- "대단한 서비스이다."

- "멀티미디어 컨텐츠에 대해서 End2End 시나리오를 지원한다."

- "독보적인 서비스이다"

 

주관적인 생각이지만 그만큼 가치가 있는 서비스라고 생각한다.

2012년 6월8일 한국 시간 오전 5시에 Windows Azure의 새 버전이 발표되었다. 여기에 클라우드 서비스로 추가된 것이 'Windows Azure Media Services"이다.

 

이 서비스의 시나리오를 요약하자면

1) [업로드] 컨텐츠 사업자가 Azure에 멀티미디어 컨텐츠를 업로드 하면,

2) [워크플로우] 사용자가 정한 컨텐츠 처리 로직을 수행하게 되는데

3) [인코딩] 컨텐츠를 필요한 포맷으로 인코딩 하고

4) [Ingestion] 각종 후처리 (광고 삽입,메타데이타 추출등)를 거치고

5) [DRM] 필요에 따라 컨텐츠에 DRM을 삽입해준다.

6) [저장] 이렇게 후처리가 끝난 컨텐츠들은 Azure에 저장이 되고

7) [배포] 사용자가 원하는 시스템으로 컨텐츠를 전송하거나 또는 CDN으로 배포가 된다.

8) [서비스] 이렇게 배포된 서비스는 Azure에서 제공하는 CDN을 통해서 Streaming 서비스가 가능하게 된다.

9) [Adaptive Streaming] Streaming시에 단말 사용자가 접속한 인터넷 회선 사항에 따라서 컨텐츠의 인코딩 품질을 조정하면서 끊김없는 동영상 서비스를 가능하게 한다.

10) [클라이언트 지원] Streaming등의 컨텐츠 서비스를 위해서 윈도우즈 플랫폼 뿐만 아니라 애플 iOS 플랫폼용 SDK까지 제공하여, 단말 개발까지 지원한다.

 

위에서 시나리오를 설명하였지만, 한마디로 멀티미디어 컨텐츠 생성을 제외한 저장,후처리,스트리밍 서비스 및 개발 지원까지의 Full 시나리오를 지원하며, 워크 플로우를 통해서 컨텐츠 후처리 로직을 다양하게 설정할 수 있다.

 

이번 Azure 업그레이드에서 주목할만한점중 하나는 "개방성"인데, Media Services에도 이 개방성의 사상이 반영 되었다. 즉, DRM, CDN등에 대해서 Third Party Solution과 Integration이 가능하다. CDN은 Akamai를 Streaming 서비스는 Wowza를 DRM에는 BuyDRM,EZDRM들을 이미 지원하고 있다.

 

아직 정식 서비스가 아닌 시범 서비스 단계이기는 하지만 멀티미디어 컨텐츠 서비스를 위한 강력한 클라우드 서비스 플랫폼임에는 틀림이 없고, 비용이 많이 들고 복잡도가 높은 멀티미디어 서비스를 클라우드 환경에서 플랫폼 형태로 제공함으로써 많은 사용자 서비스를 만들어내는데 기여할것으로 기대된다.

 

다시 돌아보는 MS

사는 이야기 | 2011.04.14 22:53 | Posted by 조대협
94년도에 MS-DOS로 프로그래밍을 본격적으로 입문했습니다.
TurboC,Borland C,Watcom C등을 거쳐서 Visual Studio를 다루게 되고
ASP를 통해서 웹프로그래밍을 처음 시작했습니다.
그리고, MFC,Win32SDK,Petzold (아시는 분은 다 아시져?)를 이용한 CS 프로그래밍
그리고 Direct X 게임
그러다가.. 이러다가는 밥굶겠다 해서 Unix/C 하다가 어찌어찌.. Java로 한 10년 먹고 살다가 지금은 MS에 와 있습니다.
사실 Java 진영의 커뮤니티 리더로써 .NET 죽이기를 하다가 지금은 .NET 진영에 와 있으니 참 모순이지요..
그런데 MS에 온지 1년이 지난 후에 정말 느끼는 건데.. 아직 안죽었더군요.
그리고.. 한국은 MS 솔루션에 너무 인색하더군요.
컨퍼런스나 회의 때문에 본사에 가면, 유럽,남아공,미국 등 여러 나라 친구들을 만나는데, 놀랍게도 Enterprise System (은행 계정계 포함) 40%가 .NET으로 개발된답니다.

오늘도 MIX11 행사를 보면서 문뜩 생각이 들어서 포스팅을 합니다.
금년에도 IE 9를 내었지만 FF5에 못 미친다는 생각이 들기도 전에 IE 10 Preview가 나왔습니다.
키넥트는 MS의 혁신적인 제품중의 하나이고, WIN7역시 제가 참으로 좋아하는 OS입니다.
클라우드 컴퓨팅의 제품 구조와 Azure 역시 놀랍습니다.
WinPhone7 역시 막판 보스의 포스를 풍기면서 오늘 1500개의 API를 Release했습니다.
얼마전 WCF로 REST를 구현해봤는데..
역시 놀랍습니다. 잘 정리된 API와 문서..JAVA에서는 이클립스 깔고, LIB깔고, WAS설치하고 복잡한데.
.NET은 걍 한방입니다.

저도 MS에 대한 기술적 편향은 많이 가지고 있었지만.
기술이 좋고 나쁨은 벤더를 보는게 아니라 기술 자체를 보는것은 어떨까 싶습니다.
MS에서 지난 1년간 많은 것을 얻었습니다.
아직 죽지 않은 공룡중에 하나져.. 그리고 이 회사에서 일할 수 있는 것을 영광으로 생각합니다.

앞으로는 왼손에 Unix/Java/Opensource 그리고 오른손에는 .NET을 쥐고 이야기 할 수 있을 것 같네요.
국순당 한잔에.. 주저리주저리 써봤습니다.


'사는 이야기' 카테고리의 다른 글

또 회사를 옮깁니다.  (10) 2011.07.03
메니져의 역할과 필요성  (1) 2011.05.30
다시 돌아보는 MS  (2) 2011.04.14
요즘 제 블로그 들어오시는분들..  (1) 2011.03.15
포스팅해야 하는 자료들  (0) 2011.03.10
컨설팅 하나 또 끝마치고..  (1) 2010.12.03

장애 대응 단계별 하드웨어 설계 방안

클라우드를 구축하는데 비용상의 문제점은 SAN을 구축하는데 소요되는 비용이다. SAN Controller Switch에 많은 비용이 소요되는데, 서버별 사용 시나리오별로 SAN 사용 여부를 판단함으로써 전체 하드웨어 구축 비용을 절약할 수 있다.


소프트웨어를 이용한 장애 대응

Tuxedo와 같은 TP Monitor Tomcat과 같은 Web Application Server 등은 소프트웨어 자체적으로 Cluster 구축을 통해서 Fail Over를 지원하거나 장애가 났을 때 일시적으로 Transaction이 중단되는 것을 허용하는 경우가 많다. 이런 경우에는 SAN을 구성하지 않고 Server에 직접 연결된 DAS를 이용해서 서비스를 제공한다.

권장 시나리오 : Application Server VM, Oracle RAC를 지원하는 DB 시나리오

Live Migration을 이용한 서버 장애 대응


하드웨어 장애가 났을 때에도 무 정지 상태로 Migration이 가능하다. VM 이미지를 저장하기 위해서 SAN이 필요하다. 이 경우에는 소프트웨어가 제공하는 Fail Over Mechanism을 사용하지 않는다. DISK에 대한 FailOver RAID 구성을 통해서 지원을 하지만, SAN Controller 장애시에는 전사 장애로 발전한다.

참고 : Linux VM의 경우 Hyper-V에서 Live Migration 지원이 불가능하다.

권장 시나리오 : MS SQL

SAN Cluster 구축을 통한 장애 대응


바로 위의 시나리오의 SAN Controller 장애에 대응하기 위한 아키텍쳐로 SAN Controller를 이중화 하고, 앞단에 SAN Switch를 넣어서 SAN Controller에 대해서 장애 대응을 한다. 모든 서버 하드웨어 장애 시나리오에 대해서 대응이 가능하다.

권장 시나리오 : 무정지 시스템, 무정지 MS SQL


For hosting and telecom providers, Microsoft offers a set of WCF-based services that provide automation capabilities to provision, manage, or query multiple products and server technologies that are used in the operational data centers.

Managed hosting services are sets of services that leverage Microsoft® System Center Server Management Suite Enterprise products, including System Center Configuration Manager, System Center Operations Manager, System Center Data Protection Manager, and System Center Virtual Machine Manager. These services enable hosting providers to construct a managed hosting solution that offers various managed services, such as the following:

·         Windows Server® 2008

o   Physical machine provisioning and management

o   Hyper-V™–based virtual machine provisioning and management

o   Templates and image management

o   Internet Information Services 7.0 Web server and FTP7 provisioning and management

·         Microsoft SQL Server® 2005 and SQL Server 2008

o   Database server provisioning and management

o   Database content management

·         System Center Configuration Manager

o   Software updates

o   Software distribution

o   Asset tracking and reporting

o   Software metering

·         System Center Operations Manager

o   Server monitoring

o   Application monitoring

o   Network monitoring

o   Security auditing

·         System Center Data Protection Manager

o   File/folder-level backups and restores

o   Virtual server (.vhd)–level backups and restores

o   Physical server–level backups and restores

·         System Center Virtual Machine Manager

o   Virtualization environment management

o   Virtual machine placement

o   Snapshot management

o   Failovers (quick migrations)


Microsoft Cloud Platform은 전통적인 Iaas,Paas 뿐만 아니라 그위에 CRM ,Exchange ,Office ,SharePoint 등 다양한 형태의 소프트웨어를 서비스 형태로 제공하고, Xbox Live Windows Live와 같은 애플리케이션 서비스도 제공한다. 그러나 본 문서에서는 전체 Microsoft Cloud에 대한 설명을 하는 것이 아니라 엔터프라이즈 애플리케이션 개발과 배포를 위한 클라우드에 대한 부분에 초점을 맞추기 때문에, Paas Microsoft Windows Azure에 대해서 설명하도록 한다.


Azure Compute

Azure는 기본적으로 Paas 형의 클라우드다. Iaas 형태의 클라우드가 OS까지만 제공한다면, Paas형태의 클라우드는 아래 그림과 같이 애플리케이션을 수행 할 수 있는 Runtime과 각종 Middleware (Web Application Server, DBMS, Service Bus etc)등을 포함해서 서비스로 제공한다.

Iaas의 경우에는 이렇게 사전 제공되는 형태의 플랫폼이 없기 때문에 고객 마음대로 플랫폼을 설치 구성할 수 있기 때문에 요구사항에 대한 유연성이 매우 높지만, 반대로 플랫폼에 대한 구입,설치 및 설정과 유지보수에 대해서는 모두 고객이 책임져야 하기 때문에 그만큼 비용과 관리 인력,시간이 소요된다.

 Azure Paas형태의 클라우드 서비스로 .NET 기반의 플랫폼과 Microsoft 기반의 미들웨어는 물론이고, PHP,JAVA와 같은 다른 기술을 지원할 수 있는 플랫폼 서비스를 제공한다.


<그림. Iaas Paas의 차이 >

 

Web Role & Worker Role

이러한 애플리케이션 서비스 모델을 Azure Compute라고 하고, 각 구체적은 서비스 모델에 따라서 ‘Role’이라는 개념으로 정의되는데, 크게 “Web Role”“Worker Role” 로 분리된다.

Web Role ASP.NET 기반의 웹 애플리케이션 서비스를 하기 위한 프로세스 모델로 생각하면 된다. IIS(Internet Information Server)내에서 기동이 된다.
 Worker Role
은 백 그라운드 작업을 하기 위한 Role로 생각하면 된다. HTTP 인터페이스를 가지지 않고 TCP Q등을 통해서 Invoke가 되고, Windows Server의 서비스 프로세스로 기동된다
.
Web Role
자체는 추가적인 설명이 필요 없을 듯 하고, Worker Role은 일종의 Unix Process(?)와 유사한 개념으로 생각하면 되는데, 자바 진영의 MDB (Message Driven Bean)과 같은 개념으로도 사용될 수 있고, TP Monitor들의 서비스 프로세스와 같은 개념으로도 사용될 수 있다.

흥미로운 것 중의 하나는 Worker Role을 이용하여 요즘 유행하는 Map & Reduce (하나의 거대 작업을 작은 단위로 나눠서 패레럴 하게 처리한 후 합쳐서, 전체 성능을 끌어올리는 알고리즘) 을 구현할 수 있다. Map & Reduce를 수행하기 위해서는 앞단에서 작업을 분배해주는 작업 큐와, 작업 내용을 저장할 저장소가 필요한데, 이는 Windows Azure Storage Service Queue Service를 이용해서, Worker Role에 작업을 분산 지정할 수 있고, Storage Service Blob이나 Table Storage를 이용하여 작업 내용을 저장할 수 있다.

VM Role

이번에 PDC 2010에서 새로 발표된 Role로써는 VM Role이 있다. Amazon EC2 AMI와 같은 형태의 Iaas 서비스라고 생각하면 된다. VM Role 이전에 Windows Azure Paas 성격이 강했으나, 이번 VM Role의 추가로, Windows 기반의 Iaas 서비스가 가능하게 되었다. OS Virtual Machine Image를 통째로 VM Role에 올려서 독립적인 OS를 사용할 수 있다.

장점중의 하나는 Windows Server 2008로 운영하고 있는 on premise 시스템을 통째로 이미지로 떠서 그대로 Azure Compute VM Role에 옮겨서 운영할 수 있다는 것이다. Windows Server Base 라면 한번에 클라우드로 전환이 가능하게 된다.

Blob Storage Service

다음은 Blob Storage이다. 이미지,동영상 또는 큰 사이즈의 Binary 데이터등을 저장하는데 사용되는 서비스이다.


특징은 대용량의 저장성을 보장하고, 특히 CDN (Contents Distribution Network – 일종의 웹캐슁 서비스와 비슷하게 생각하면 된다. 각 지역 마다 캐쉬 서버를 두고 컨텐츠를 그 캐쉬 서버에 복제해서 지역적인 차이로 인한 다운로드 속도를 절감해준다.)과의 연동을 통해서 Blob Data를 원거리에서 접근하는데 성능을 보장한다.

SNS 서비스에서 이미지,동영상 저장 서비스나, 일반 기업에서 Archiving 서비스 (경비 지출서에 영수증등을 스캔해서 몇 년동안 저장해야 하는 기업 내부 규정)등에 유용하게 사용될 수 있다.

Table Storage Service

말 그대로 테이블 형태로 데이터를 저장한다. 사용자당 여러 개의 테이블을 소유할 수 있으며, 각 테이블은 다수의 컬럼으로 정의된 행을 포함한다. 그냥 편하게 RDBMS의 하나의 테이블이나, 엑셀 테이블 하나 생각하면 된다.

(데이터 구조에 대한 설명은 Apache Cassandra와 유사하기 때문에 http://bcho.tistory.com/440 문서를 참고하기 바란다.)

그런데 이미 RDBMS나 다른 곳에서도 제공하는 테이블 데이터 구조를 왜 따로 정의했을까? 쉽게 생각하면 요즘 유행하는 NoSQL과 비슷한 사상으로 생각하면 된다. 복잡한 관계형 구조나 Query가 필요 없지만 데이터의 양이 상당히 크고 고성능의 접근성이 요구될 때 사용된다. 트위터가 데이타를 Cassandra와 같은 NoSQL DB에 저장하고 사용하는 것과 같이 이유이다. Amazon SimpleDB와 유사한 서비스로 생각하면 된다.

Queue Storage Service

Queue Storage는 우리가 일반적으로 프로그래밍에서 사용하는 Queue를 생각하면 된다. IBM MQ Java JMS와 같은 개념이다.


이러한 Queuing 서비스는 비동기식 처리 방식의 아키텍쳐를 구현할 때 매우 편리한데, 예를 들어 월말 정산을 한다던지, 리포트 생성과 같은 배치 처리를 하고자 할 때, 화면에서 Request를 받고 백그라운드에서 처리를 할 때 유용하게 사용된다. 자바에서 JMS – Message Driven Bean(EJB)와 같은 아키텍쳐를 구축할 수 있다.

Azure Drive

Disk Storage 서비스는 Blob Storage 서비스를 Disk Mount 해놓은 서비스이다. Blob Storage API를 통해서 접근한다면, Disk Storage Application 입장에서는 하나의 물리적인 디스크로 인식하고 접근할 수 있다. 접근 성능을 높이기 위해서 Local VM (Windows Virtual Machine) Local Cache를 둬서 성능을 보장한다.

SQL Azure

MS SQL Azure는 쉽게 이해하면 MS SQL RDBMS를 통째로 클라우드에 올려놨다고 생각하면 된다. RDBMS를 클라우드에서 사용할 수 있는 것이다. Amazon의 경우 EC2 Oracle 이미지를 올려놓고 사용할 수 있지만 클라우드 플랫폼 자체에 녹여놨다고 보기는 약간 어렵지 않을까?

SQL Azure 서비스 중에 하나 중 재미있는 것은 MS SQL Azure 노드간의 데이터 동기화나 MS SQL Azure 노드와 기업내의 SQL 서버간의 데이터 동기화가 가능하다. MS SQL 제품 내부에는 CDC (Change Data Capture) 기능을 가지고 있는데, 아마 이 모듈을 사용해서 구축된 듯하다. 이서비스의 이름은 SQL Azure Data Sync Service, CDC 기능을 쉽게 Wrapping해놔서, Web UI상에서 복제할 MS SQL Instance를 선택하고, 테이블을 선택하면 자동으로 복제가 진행된다. 아무래도 센터간 복제이기 때문에 실시간 복제는 불가능하리라 생각하고, 아래 동영상을 보니 스케쥴 기반으로 복제를 진행한다.

아래 동영상의 시연을 보면 약 1132건의 트렌젝션 (테이블 생성에서부터, 복제등을 포함해서) 미국에서 유럽 센터간 동기화를 수행하는데 11.4초 정도가 소요된다.

기업 내부에서 CDC를 통해서 데이터 베이스를 동기화 하는 경우는 근 실시간으로 이루어 지는데, Azure Data Sync Service를 통한 지역간 복제는 아무래도 복제 아키텍쳐를 스케쥴 기반으로 설계해야 한다.

AppFabric Service Bus

AppFabric Service Bus는 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합이다.

SOA에서 사용되는 Enterprise Service Bus Legacy 시스템 통합을 위한 아답터 지원, Message Exchange Pattern의 변화,Cross Cutting Concern (보안 및 로깅 처리),SLA, Message Routing Transformation에 집중을 한다면, Internet Service Bus Network간의 메시지 릴레이와 Message Exchange Pattern에 집중 되어 있다. 보안과 Message Routing,Transformation AppFabric내의 다른 서비스 (ACS WF)에 의해서 제공되니 나중에 다시 살펴보기로 하고, Azure Service Bus의 주요 목적은 서로 다른 시스템에 배포되어 있는 서비스를 서로 연결해주는 역할을 한다. 같은 Azure 클라우드 내에 있건 아니면 다른 센터간이건, 아니면 기업과 클라우드간의 연결이건, 이를 위해서 릴레이라는 개념을 사용하는데 살펴보도록 한다.

Message Relay

앞에서도 설명했듯이 Azure Service Bus의 주요 기능은 메시지에 대한 릴레이다.엔터프라이즈 시스템과 다르게 클라우드와 특히 기업내 시스템과의 통합은 거리 문제와 NAT(네트워크 주소 변환),방화벽등의 네트워크단의 이슈를 가지고 있다. 외부 시스템과 연동을 하려면 방화벽 포트도 열어줘야 하고, 네트워크 주소도 고정을 시켜야 한다. 또는 개인이 직접 외부에서 기업 내부의 서비스를 사용하려면 일일이 방화벽 포트를 열어줄 수 없으니 이런 경우에는 VPN등을 써야 하지요. 한마디로 번거롭다 이겁니다. 그래서 클라우드에 Service Bus를 놓고 Service Bus를 통해서 접근하겠다는 사상이다.

여기에 더해서 방화벽이나 NAT와 같이 서버의 주소가 변할 때 도 대응하게 하려면 어떤 방식이 필요한가? 보통 J2EE WebLogic같은 Web Application Server (WAS)도 비슷한 문제를 가지고 있다. WAS 앞단에 로드밸런서를 두고 WAS 인스턴스에 로드를 밸런싱 해주는데, 로드밸런서가 밖에 있으면 마찬가지로 방화벽 포트를 열어줘야 하는 문제가 생깁니다. 그래서 이런 문제를 막기 위해서 사용하는 기법을 역방향 프록시라는 (Reverse Proxy)라는 기법을 사용한다.

아키텍쳐는 방화벽은 특성상 밖에서는 못 들어오지만, 나가는 것은 자유롭다. 그래서 서비스를 제공하는 서버가 Service Bus로 먼저 Connection을 맺어서 Session을 열어놓고 이를 통해서 메시지를 주고 받는 방식입이다. 방화벽을 열 필요도 없고, 서비스를 제공하는 서버의 IP가 바뀐다고 해도 상관 없다.

 

Direct Connection

다음으로는 Direct Connection이라는 기능을 제공하는데, 클라우드 밖에 있는 두 애플리케이션이 Azure Service Bus를 통해서 통신을 할 때, 당연히 Cloud를 거치면 성능이 저하된다. (Azure Data Center 옆에 두 회사가 있지 않는 이상) 서로 직접 통신을 하는 게 성능상으로 가장 좋다. 그런데 앞에서도 언급했듯이, 만약에 서비스 제공 서버의 IP가 동적으로 바뀐다면 클라이언트는 서버 IP와 포트를 알 수 가 없다. (NAT에 의해서 변경이 되기 때문에)

이를 해결하기 위해서 NAT에 의해서 어떤 포트가 다음 번에 열릴지를 예측을 해서 (mutual port prediction algorithm) Service Bus가 클라이언트와 서버에 서로 상대방 애플리케이션에 주소와 포트를 알려준다. 이 기법은 주로 인터넷 메신져에서 많이 사용되는 아키텍쳐로, 일반적인 텍스트 메시지를 서버를 경유해서 릴레이하고, 파일 전송을 할 때 이런 방법으로 서로 포트를 알려줘서 전송을 하도록 한다.

Message Buffer

위에서 설명한 것 처럼 AppFabric Service Bus는 상당히 다양한 네트워킹 Feature를 가지고 있는데, 이건 .NET 기술을 기반으로 합니다. WebService REST와 같은 플랫폼 독립적인 기술에서는 위에서 설명한 것과 같은 역방향 프록시(릴레이),Direct Connection이 불가능하다. 그래서 구현할때도 .NET에서도 코딩이 기존의 WCF를 사용하는 것이 아니라 *RelayBinding이라는 것을 사용한다.

이러한 언어에 대한 종속성을 없애기 위해서 자바나 Ruby,PHP에서도 서비스 연동을 할 수 있도록 중간에 일종의 Proxy 같은 개념을 넣었는데, 그것이 Message Buffer 이다. 서비스 앞에 Message Buffer라는 서비스를 넣고, 메시지를 이 Buffer를 통해서 다른 플랫폼과 주고 받는다. 다른 플랫폼들은 Message Buffer REST (XML/HTTP)를 이용해서 접근한다.

 

Message Exchange Pattern 변환

먼저 Message Exchange Pattern이란 (이하 MEP), API 또는 Procedure의 호출 형태를 이야기 한다. 우리가 흔히 이야기 하는 SYNC,ASYNC,PUB/SUB,1:1,1:N,MultiCast 등등이 MEP에 해당하고 Service Bus API에 대한 MEP를 변환할 수 있도록 한다. MEP에 대한 Full 변환 지원은 지원하지 않는 것 같고. (필요하다면 Workflow Foundation을 이용해서 구현할 수 있으나..) SYNC 방식의 서비스를 ASYNC방식의 Fire&Forget과 같은 패턴으로 구현하는 OneWay Relay 서비스 등이 있다.

조금 더 자세한 Relay 서비스 방식에 대해서는 아래 문서를 참고하기 바란다.

http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Security 지원

처음에 설명했듯이, Service Bus의 기본 목적은 클라우드 내의 시스템과 외부의 시스템간의 통합입니다. 그래서 보안 특히 인증,인가(Authentication & Authorization 이하 A&A)는 매우 중요한 일입니다. 실제 기업 프로젝트 할 때 도 이 계정 체계 통합이 정말 골치 아픈일입니다.

Azure에서는 ACS(Access Control Service)라는 권한 컨트롤 체계를 가지고 있고, 그 중에서 클라우드 내외부의 계정을 통합할 수 있는 메커니즘을 가지고 있다.

쉽게 정리해서 보자면 클라이언트가 서비스를 요청하면, 클라우드는 기업 내부에 있는 계정 시스템에 해당 사용자가 서비스를 사용 가능한지 물어보고 가능하면 서비스를 허가 한다”. 이런 시나리오 이다.
만약 웹 기반 서비스이면 클라우드 시스템이 기업내부의 계정 시스템의 인증/인가 페이지로 Redirect한다음에 로그인 되면 원래 서비스 페이지로 다시 Redirect하는 메커니즘이다.

AppFabric Cache

AppFabric Cache는 전통적인 애플리케이션의 Cache 기능과 함께, 데이터 교환을 위한 데이터 버스 사용 시나리오 두 가지를 지원한다.

전통적인 Cache 시나리오는 DB Query 결과에 대한 Cache나 웹페이지에 대한 Cache 등을 지원할 수 있는데, 특히 웹페이지에 대한 Caching의 경우 기존 페이지를 변경하지 않고 코드 변경 없이 손쉽게 적용할 수 있기 때문에 짧은 노력으로 성능 향상과 함께, Transaction 을 절약함으로써, 하드웨어 자원을 절약할 수 있다

또한 AppFabric Cache는 클러스터 구조를 통해서 수평적으로 무제한 확장이 가능하며, Cache의 크기도 운영중에 Dynamic하게 늘이거나 줄이는 것이 가능하다.

데이터 버스로는 Cache가 여러 Instance간에 접근이 가능하고, 그 접근 속도가 매우 빠르기 때문에, Web Session공유나 Instance간의 데이터 공유의 용도로 사용될 수 가 있다. 기존의 On-premise 시스템에서는 오픈소스인 memcached, Oracle Coherence, MS Windows Server AppFabric Cache등을 사용하여 이러한 아키텍쳐를 구현하였는데,클라우드에 이 개념을 도입함으로써 특히나 어려운 클라우드 상의 Instance간의 데이터 교환을 지원할 수 있게 되었다.

AppFabric Integration

On-premise 시스템과의 통합에 있어서 네트워크 회선상의 문제뿐만 아니라, ERP,CRM등과 같은 패키지 소프트웨어에 대한 통합이 또 다른 문제로 작용한다. 이러한 패키지 소프트웨어등은 고유의 기술 (SAP ABAP , Tuxedo ATMI etc)을 사용하기 때문에 이러한 시스템과 연동을 위해서는 별도의 테크놀로지 아답터가 필요하다. 또한 통합을 지원하기 위해서는 복잡한 Process,메시지에 대한 변환, 로깅 및 추적등의 기능이 필요한데, 이러한 영역은 전통적으로 On premise 시스템에서는 EAI(Enterprise Application Integration)을 통해서 해결되어 왔다.

 Windows Azure에서는 이러한 EAI의 요건을 충족하는 Microsoft BizTalk을 클라우드에 서비스화함으로써, Cloud 시스템과 On-premise의 패키지 소프트웨어에 대한 통합을 지원하게 되었고, BAM (Business Activity Monitoring) 기능을 지원함으로써, 통합 과정에서 수행되는 프로세스 각 단계에 대한 모니터링을 가능하게 해준다.

 또한 기업간 연동을 위한 B2B Connector를 제공하며, B2B 연동에 필요한 Trading Partner 관리등의 기능을 제공한다.

AppFabric ACS (Access Control Service)

ACS 서비스는 클라우드 내에서 사용되는 계정 체계와 권한 체계에 대한 관리를 담당하고, 타 시스템 (FaceBook과 같은 온라인 서비스나, on-premise 서비스내의 계정권한 시스템)과의 통합을 지원한다.

ACS Active Directory를 근간으로 되어 있으며, 사용자 또는 그룹에 따라서 시스템에 대한 접근 권한을 설정할 수 있다. On premise 시스템에 배포된 Active Directory나 또는 다른 계정 관리 시스템과 통합할 수 있는 인터페이스를 지원하며, X.509등의 여러 credential을 지원한다.

Composite Applications

이번 PDC 2010에 발표된 새로운 서비스로, Azure내의 각종 서비스들을 Composite하여 새로운 서비스를 제공할 수 있는 기능이다. 흔히 WEB 2.0에서 말하는 Mash up과 같은 개념의 서비스로 (Yahoo Pipe와 같은 개념). Azure Integration Service가 복잡하고 Stateful Orchestration Package Software에 대한 Native 프로토콜을 이용한 Integration  담당한다면, Composite 서비스는 표준 서비스 인터페이스 (REST,SOAP etc)를 기반으로 한 Mediation 기반의 Composition을 지원한다.

 또한 Azure Composite 서비스는 단순히 Composition만을 지원하는 것이 아니라 Composite 되는 Workflow구간에 대한 모니터링과 디버깅을 지원하며 Metering 지원을 통해서 사용량 측정(과금이 필요한 경우 과금 기반 자료로 사용 가능)등의 서비스를 제공한다.


Map & Reduce on Azure

다음으로 근래에 구글등의 업체가 검색 기술 향상을 위해서 분산 파일을 기본으로 한 분산 처리 기술인 Map & Reduce를 많이 언급하고 있는데, 이는 하나의 큰 작업을 여러 개의 작업으로 나눠서 작은 컴퓨터에서 처리한 후에 하나로 합해서 PC급의 컴퓨터 여러대를 이용해서 한대의 수퍼컴퓨터와 같은 성능을 내는 아키텍쳐이다.

이미 Amazon은 오픈 소스인 Hadoop을 기반으로 해서 이 Map & Reduce 를 서비스하고 있는데, Map & Reduce는 정확하게는 Hadoop이라는 솔루션이 아니라 아키텍쳐이자 알고리즘이다. 그래서 Azure에서도 Map & Reduce가 구현이 가능하고, 사례가 있는데, Map & Reduce를 구현하는 Reference Architecture를 설명하면 다음과 같다.


o    Map 단계

먼저 처리하고자 하는 데이터를 Blob Storage에 업로드한후 Worker Role을 통해서 작업을 지시한다.

Worker Role은 작업을 작은 조각으로 나누고, 작업 명령을 Queue에 저장한다. (Queue Storage Service 이용)

o    Compute 단계

작업을 수행하는 각각의 Worker Role들은 Queue에서 작업을 하나씩 꺼내고, 처리할 데이타를 Input Data가 저장된 Storage에서 꺼내서 작업 및 계산을 수행한다.

o    Reduce 단계

작업이 끝나면 작업이 끝났다는 내용을 Output Queue에 저장하고 OutPut을 담당하는 Worker Role Queue에서 작업이 끝났다는 내용을 하나씩 받아서, 위에서 계산이 저장된 각각의 Blob Storage로부터 작업 결과를 읽어서 합치는 계산을 수행한다.

이 구조에서 Compute (계산)을 담당하는 Worker Role의 수를 탄력적으로 조정하여 Computing Power를 조절할 수 있다.

 이러한 기법은 검색 결과에 대한 계산 (Indexing), 3D 그래픽 렌더링, 대규모 수학계산, 분석에 응용이 가능하다.

Azure CDN

Azure역시 CDN 서비스를 제공하는데, 전세계 22개의 CDN 센터를 두고 Blob Storage와 연계하여 대용량 데이터에 대한 지역 차이로 오는 Latency를 극복할 수 있도록 해준다.


Azure Connect (cf. Amazon VPC)

Amazon VPC와 유사한 개념의 서비스로, On premise 시스템과 Cloud 서비스간의 연동을 위해서 Secure VPN 네트워크를 제공하여 고객에게 Private Cloud 서비스를 제공한다.

VPN망은 Private Cloud 서비스를 사용하기 위해서도 사용될 수 있지만, 개발자나 관리자를 위한 관리 인터페이스 접근을 위한 VPN으로, 또는 SQL Azure와 같은 데이터 접근시 보안을 필요로하는 경우 등에 응용되어 사용될 수 있다.

Platform Compatibility

Azure Paas인 만큼 어떤 플랫폼을 지원하는지를 확인할 필요가 있는데, Microsoft의 클라우드 플랫폼임에도 불구하고 MS기술만 지원하지는 않는다.

기본적으로 Azure 클라우드에 배포된 각종 기능 (Storage,SQL,AppFabric)등은 Microsoft .NET, Java, PHP,그리고 Ruby Client SDK를 지원하고 있고, 서버쪽에서도 애플리케이션 플랫폼으로는 .NET 뿐만 아니라, PHP Apache Tomcat기반의 Java 개발환경을 지원한다. 데이터베이스 관점에서는 MS SQL이외에 MSQL을 함께 지원한다.

PDC 2010에서는 Microsoft에서 향후 Azure에 대해서 개방형 플랫폼 지원을 확장할것이며 특히 Tomcat 기반의 지원을 통해서 Java Azure First Citizen으로 만들겠다는 Vision을 발표하였다.


Azure Appliance

Microsoft Azure가 흥미로운 점 중의 하나는 Azure Platform 자체를 하드웨어를 포함하여 컨테이너 방식으로 직접 고객에게 판매한다는 것이다. Azure Appliance 라는 상품명인데, 아직 현재 테스트중이고 구체적인 판매 가격 등은 미정인 상태지만, eBay를 비롯하여 DELL,HP,Fujitsh 등을 대상으로 고객 테스트를 진행중이다.


Azure Appliance Azure를 운영하기 위한 서버,네트워크 장비,공조시설,전원등이 일체형으로 설계되어 있고, Azure Paas까지 모두 인스톨되어 있는 모델로, 컨테이너를 설치와 즉시 전원 공급만으로 운영이 가능하다.

Azure Appliance를 고객사에서 사용할 경우 Azure Platform Private Cloud형태로 사용하거나 Public Cloud 형태로 다른 고객에게 서비스할 수 있다. 또한 Azure Appliance에 배포된 Application Microsoft Azure와 동일 아키텍쳐를 가지고 있기 때문에 필요에 따라서 Microsoft Azure Platform으로 손쉽게 Migration이 될 수 있다. Azure Appliance에 대한 플랫폼 유지보수와 업그레이드 역시 Microsoft 본사를 통해서 직접 이루어지기 때문에 플랫폼 운영에 대한 비용과 시간 역시 절약할 수 있다는 장점을 가질 수 있다.

 

Azure Appliance는 위의 그림에서 보는 바와 같이 Public Azure가 가진 특징 이외에 기업 특성에 맞춰진 형태의 아키텍쳐 구성이 가능하다.

아무래도 전직이 자바 개발자인지라, Azure를 봐도 자바 지원 여부를 보게 되는데, 재미있는 자료를 몇가지 찾아서 첨부한다.


위의 동영상은 Windows Azure Platform 위에서 Tomcat을 구동 시킬 수 있는 방법에 대한 글이다. 이클립스 연동도 되고 대충 쓸만해 보인다. 일반적인 웹 애플리케이션은 그럭저럭 기동 시킬 수 있을 텐데.. 앞뒤에 붙는 Apache Http 서버라던가, Jennifer와 같은 APM은 아마 적용하기 힘들것 같고, Thread Dump를 이용한 Trace라던가 JVM 튜닝 같은 내용의 적용이 쉽지 않아 보인다. 그냥 일반 서비스성 웹애플리케이션이나 이벤트성 서비스에는 그럭저럭 쓸 수 있을 듯 한데, 상용 서비스에서는 글쎄....??

이건 Azure Storage Service들을 Java에서 사용할 수 있는 API SET
http://www.interoperabilitybridges.com/projects/windows-azure-sdk-for-java.aspx
어짜피 Azure는 REST를 지원하니 Java나 PHP,Ruby등에서 당연 사용할 수 있는 것이지만, Library Set을 지원하니 훨씬 개발하기 편한듯 하다. 샘플 코드를 보니 정말 편한데..
아무래도 대용량 데이타를 유지 관리해야 하는 서비스나, BLOB과 같은 데이타를 유지해야 하는 서비스들에 대해서는 충분히 승산이 있을듯.

Amazon EC2에는 AMI로 해서 WebLogic까지 싸악 올릴 수 있군요.
http://www.theserverlabs.com/blog/2009/05/29/setting-up-a-load-balanced-oracle-weblogic-cluster-in-amazon-ec2/
멋집니다. 라이센스를 얼마나 받을 련지 몰겠습니다마나.


Windows Azure AppFabric Service Bus

Azure 클라우드에는 AppFabric이라는 또 하나의 서비스가 있습니다. 간략하게 설명하자면 다른 서비스나 on-premise (기업내에 배포된 시스템)과의 통합을 위해서 필요한 서비스들의 집합입니다. 그 중에서 이번에는 Service Bus에 대해서 설명해보겠습니다.
사실 이 Service Bus를 이해하는데 다소 시간이 걸렸습니다. 왜냐하면 제 기술적인 백그라운드가 SOA이고, 그 중 가장 중요한 컴포넌트 중 하나가 Enterprise Service Bus (ESB)니까요. 그런데 Azure의 Service Bus 개념은 약간 다릅니다. Internet Service Bus (ISB)라는 개념으로 설명을 하더군요.
Enterprise Service Bus가 Legacy 시스템 통합을 위한 아답터 지원, Message Exchange Pattern의 변화,Cross Cutting Concern (보안 및 로깅 처리),SLA, Message Routing 및 Transformation에 집중을 한다면,
Internet Service Bus는 Network간의 메시지 릴레이와 Message Exchange Pattern에 집중 되어 있습니다. 보안과 Message Routing,Transformation은 AppFabric내의 다른 서비스 (ACS와 WF)에 의해서 제공되니 나중에 다시 살펴보기로 하고, Azure Service Bus의 주요 목적은 서로 다른 시스템에 배포되어 있는 서비스를 서로 연결해주는 역할을 합니다. 같은 Azure 클라우드 내에 있건 아니면 다른 센터간이건, 아니면 기업과 클라우드간의 연결이건, 이를 위해서 릴레이라는 개념을 사용하는데 살펴보도록 하지요.

Message Relay
앞에서도 설명했듯이 Azure Service Bus의 주요 기능은 메시지에 대한 릴레이 입니다.엔터프라이즈 시스템과 다르게 클라우드와 특히 기업내 시스템과의 통합은 거리 문제와 NAT(네트워크 주소 변환),방화벽등의 네트워크단의 이슈를 가지고 있습니다. 외부 시스템과 연동을 하려면 방화벽 포트도 열어줘야 하고, 네트워크 주소도 고정을 시켜야 합니다. 또는 개인이 직접 외부에서 기업 내부의 서비스를 사용하려면 일일이 방화벽 포트를 열어줄 수 없으니 이런 경우에는 VPN등을 써야 하지요. 한마디로 번거롭다 이겁니다. 그래서 클라우드에 Service Bus를 놓고 Service Bus를 통해서 접근하겠다는 거지요.
여기에 더해서 방화벽이나 NAT와 같이 서버의 주소가 변할 때 도 대응하게 하려면 어떤 방식이 있을까요? 보통 J2EE의 WebLogic같은 Web Application Server (WAS)도 비슷한 문제를 가지고 있는데요. WAS 앞단에 로드밸런서를 두고 WAS 인스턴스에 로드를 밸런싱 해주는데, 로드밸런서가 밖에 있으면 마찬가지로 방화벽 포트를 열어줘야 하는 문제가 생깁니다. 그래서 이런 문제를 막기 위해서 사용하는 기법을 역방향 프록시라는 (Reverse Proxy)라는 기법을 사용합니다.
원리인 즉, 방화벽은 특성상 밖에서는 못 들어오지만, 나가는 것은 자유롭습니다. 그래서 서비스를 제공하는 서버가 Service Bus로 먼저 Connection을 맺어서 Session을 열어놓고 이를 통해서 메시지를 주고 받는 방식입니다. 방화벽을 열 필요도 없고, 서비스를 제공하는 서버의 IP가 바뀐다고 해도 상관 없습니다. 예전 웹로직 할 때 봤던 아키텍쳐인데 여기서 보니 또 새롭네요..
 

Direct Connection
다음으로는 Direct Connection이라는 기능을 제공하는데, 클라우드 밖에 있는 두 애플리케이션이 Azure Service Bus를 통해서 통신을 할 때, 당연히 Cloud를 거치면 느립니다. (Azure Data Center 옆에 두 회사가 있지 않는 이상) 서로 직접 통신을 하는 게 성능상으로 가장 좋습니다. 그런데 앞에서도 언급했듯이, 만약에 서비스 제공 서버의 IP가 동적으로 바뀐다면 클라이언트는 서버 IP와 포트를 알 수 가 없습니다. (NAT에 의해서 변경이 되기 때문에)
이를 해결하기 위해서 NAT에 의해서 어떤 포트가 다음번에 열릴지를 예측을 해서 (mutual port prediction algorithm) Service Bus가 클라이언트와 서버에 서로 상대방 애플리케이션에 주소와 포트를 알려줍니다. 이 기법은 주로 인터넷 메신져에서 많이 사용하는데요. 일반적인 텍스트 메시지를 서버를 경유해서 릴레이하고, 파일 전송을 할 때 이런 방법으로 서로 포트를 알려줘서 전송을 합니다.

Message Buffer
위에서 설명한 것 처럼 AppFabric Service Bus는 상당히 다양한 네트워킹 Feature를 가지고 있는데, 이건 .NET 기술을 기반으로 합니다. WebService나 REST와 같은 플랫폼 독립적인 기술에서는 위에서 설명한 것과 같은 역방향 프록시(릴레이),Direct Connection이 불가능하지요. 그래서 구현할때도 .NET에서도 코딩이 기존의 WCF를 사용하는 것이 아니라 *RelayBinding이라는 것을 사용하네요. 
 


어쨌든 간에, 언어에 대한 종속성을 없애기 위해서 자바나 Ruby,PHP에서도 서비스 연동을 할 수 있도록 중간에 일종의 Proxy 같은 개념을 넣었습니다. 그게 Message Buffer라는 것인데, 서비스 앞에 Message Buffer라는 서비스를 넣고, 메시지를 이 Buffer를 통해서 다른 플랫폼과 주고 받습니다. 다른 플랫폼들은 Message Buffer에 REST (XML/HTTP)를 이용해서 접근합니다.
 
일단 이렇게 해서 타 플랫폼과의 상호 운용성을 확보해주는 방법인데, Native WCF를 써서 SOAP이나 REST를 쓰는 것에 비해서 어떤 장점이 있는지는 좀 봐야 알 수 있을 것 같습니다.

Message Exchange Pattern 변환
먼저 Message Exchange Pattern이란 (이하 MEP), API 또는 Procedure의 호출 형태를 이야기 한다. 우리가 흔히 이야기 하는 SYNC,ASYNC,PUB/SUB,1:1,1:N,MultiCast 등등이 MEP에 해당하고 Service Bus는 API에 대한 MEP를 변환할 수 있도록 한다. MEP에 대한 Full 변환 지원은 지원하지 않는 것 같고. (필요하다면 Workflow Foundation을 이용해서 구현할 수 있으나..) SYNC 방식의 서비스를 ASYNC방식의 Fire&Forget과 같은 패턴으로 구현하는 OneWay Relay 서비스 등이 있다.
조금 더 자세한 Relay 서비스 방식에 대해서는 아래 문서를 참고하기 바란다.
http://msdn.microsoft.com/en-us/magazine/dd569756.aspx

Security 지원
처음에 설명했듯이, Service Bus의 기본 목적은 클라우드 내의 시스템과 외부의 시스템간의 통합입니다. 그래서 보안 특히 인증,인가(Authentication & Authorization 이하 A&A)는 매우 중요한 일입니다. 실제 기업 프로젝트 할 때 도 이 계정 체계 통합이 정말 골치 아픈일입니다.
Azure에서는 ACS(Access Control Service)라는 권한 컨트롤 체계를 가지고 있고, 그 중에서 클라우드 내외부의 계정을 통합할 수 있는 메커니즘을 가지고 있습니다.
쉽게 정리해서 보자면 “클라이언트가 서비스를 요청하면, 클라우드는 기업 내부에 있는 계정 시스템에 해당 사용자가 서비스를 사용 가능한지 물어보고 가능하면 서비스를 허가 한다”. 이런 시나리오 입니다.
만약 웹 기반 서비스이면 클라우드 시스템이 기업내부의 계정 시스템의 인증/인가 페이지로 Redirect한다음에 로그인 되면 원래 서비스 페이지로 다시 Redirect하는 메커니즘입니다.
대략 AppFabric의 모듈 중 하나인 Azure Service Bus에 대해서 살펴봤고, 다음 글에서는 AppFabric의 Work Flow 모듈과 보안 모듈(ACS)에 대해서 살펴보겠다.
 


대충 위와 같은 개념인데, ACS가 계정에 대한 통합 역할을 하는 셈입니다.
ACS는 SAML등과 같은 표준을 지원하기는 하지만 Active Directory를 잘 지원합니다. 기업의 계정 시스템이 Active Directory 기반이라면 아주 쉽게 통합이 된다는 겁니다.
그 외에도 Facebook, Open ID와 같은 SNS 기반의 ID 체계와도 통합 로그인을 할 수 있는 Feature를 제공하고 있습니다.
ACS에 대한 내용은 나중에 좀 더 알아보도록 하겠습니다.

 

지난주에 시애틀 마이크로소프트 본사로 교육을 다녀왔습니다.
MSSU (Microsoft Service University)라는 프로그램입니다. 세일즈,컨설팅등 제 아키텍트롤에 맞는 교육을 받았씁니다.
벤더 생활이 근 10년이 되어가는데, 이렇게 체계적인 롤 교육을 받아본것은 이번이 처음인것 같습니다. 역시 1등 회사는 모가 달라도 다르구나 하고 좀 느꼈습니다.

교육은 상당히 액티브하게 이루어집니다. 반 이상이 발표,토론,롤플레이등으로 이루어집니다. 교육 환경도 자유로운 편이라서.. 졸리면 뒤에가서 커피들고 서서 이야기 하고, 강사 앞에서 다리도 꼬고 앉습니다.
사용자 삽입 이미지

특히나 이번에는 전세계에서 온 컨설턴트들과 함께해서 이런 저런 이야기를 들을 수 있는 기회가 많았습니다. (프랑스,두바이,미국,남아공까지... 등등)
재미있었던 것중의 하나는 진짜 참여하는 것이 많았기 때문에, 그냥 듣고만 가는 한국 교육하고는 습득 정도가 차이가 많이 났습니다. 고객과 영업 또는 고객과 아키텍트 입장으로 나눠서 실제 롤 플레이도 하고, (다들 잔뼈가 굵은 사람들이라서.. 실제 상황이랑 거의 비슷하더군요.). 질문도 편하게 할 수 있고 토론도 정말 많이 한듯 싶습니다.
안되는 영어라서 진짜 고전했는데, 그래도 나름대로 잘 버텼던것 같네요.
사용자 삽입 이미지
위에는 수업 전경입니다. 뒤에 빼곡하니 붙은 종이들은 수업중에 실제 쓴 내용들입니다. 강사가 꼭지 잡아주고 설명해주면, 각자 나가서 경험을 쓰거나, 그룹을 나눠서 PT를 한다거나 그런 식으로 진행합니다.

일주일 동안, 하루는 몸살도 나서 고생도 하고, 일정이 아주 터프해서 몸이 거의 파김치가 됬지만, 이정도 교육이라면 시간 투자해서 받아볼 가치가 있다고 봅니다.

교육 과정중 사진 몇몇 올려봅니다. (MS 캠퍼스의 모습)

사용자 삽입 이미지
MS 본사 전경중 일부입니다. MS 본사는 캠퍼스라고 부릅니다. 진짜 대학같은 분위기인데, 서울대 몇배 크기라고 대충 생각하시면 됩니다. 너무 넓어서 걸어서는 도저히 돌아다닐 수 없어서, 아래 사진과 같이 셔틀과 택시가 다닙니다. (물론 공짜구요..)
사용자 삽입 이미지
 (MS 내부 돌아다니는 셔틀 택시. 대부분 운전사분들은 나이 많이 먹은 노인들입니다.)
사용자 삽입 이미지

벽에 빼곡하게 붙여놓은 교육과 토론 내용들...

마지막으로 컨설팅 교육 과정에서 같은 조였던 뉴질랜드 아키텍트 Terry와, 미국 프로젝트 메니져 Dann. 우리조가 클래스에서 1등했습니다.


조만간에 또 미국이나 싱가폴로 기술 교육이 예정될것 같습니다. 이번 회사에 있는 동안 한층 업그레이드될 수 있는 기회가 많기를 기대해봅니다.

시나리오를 설명 드리는게 제일 빠르겠네요
회사 PC의 C:\Mesh라는 폴더를 Live Mesh에 공유합니다. 집의 PC도 C:\HomeMesh라는 폴더를 Live Mesh에 공유합니다.
집에서 문서 작업을 해서 C:\HomeMesh라는 폴더에 저장하면 자동으로 회사 PC의 C:\Mesh라는 폴더에도 저장이 됩니다.
물론 저 폴더는 http://www.mesh.com 웹에서도 접근이 가능하고 여러개의 PC를 동기화 시킬 수 도 있습니다. 다른 사람의 PC까지도요. (팀 협업 작업에 진짜 편하겠져..)
MAC도 지원하고 WIN Mobile 계열 모바일 디바이스도 지원합니다. (예정.. Internal Beta가능)

어제 부터 사용하고 있는데, 집과 회사에서 문서 작성한후 메일이나 USB에 복사하지 않고 바로 작업할 수 있어서 편하네요.
http://www.mesh.com 입니다. 한번들 사용해 보세요.
요즘 Microsoft MediaRoom이라는 IPTV 솔루션을 보고 있는데...
데모나 스펙으로 봤을때도 집에서 지금 쓰고 있는 국산 IPTV솔루션에 비해서 월등하다..
국산 셋톱박스나 인터페이스 기능들에서 불편하다고 생각했던것들.. 있었으면 하는 것들이 이미 들어가 있다.
구글이나 애플이 TV 시장에 진출한다던데..
삼성과 LG돠 IPTV를 생산하기는 하지만 통신사에서 주문받은 플랫폼을 올리는것일뿐 아직까지 가시적인 독자적인 플랫폼은 보이지 않는다. 물론 국내 TV제조사에서 하고있는 일은 알지만...
이러다가는 모바일 전쟁에서 소프트웨어 및 플랫폼을 빼았기도 기계 제조사로 전락한것처럼.. TV세계에서도 같은 일이 반복될거 같다.
조만간 MediaRoom 스터디 해서 올릴께요. :)
오늘 MS 개발자 행사인 RemixK에 다녀왔습니다.
10년 이상 자바개발자 행사만 다닌 저한테는 다소 낮선 자리였습니다.

오늘 컨퍼런스 내용중에 흥미로웠던것중에 하나가 WinMobile7이었습니다.
년말에나 나올 '내일폰'이긴 합니다만.
Feature들이 흥미로워서 이야기 해봅니다.

크게 개발환경이 SilverLight와 XNA로 나뉘어 지는데, 일반적인 애플리케이션 개발은 SilverLight기반으로 하게 되어 있습니다. 그런데 개발툴이 일반 개발자 개발툴이라기 보다는 동영상 저작도구 같은 느낌이더군요. 아이폰의 Object C 개발환경, 이클립스 기반의 안드로이드 개발환경을 맛본 저로써는 다소 신선했습니다. 저작도구 답게 UI프로그래밍이나 이펙트가 매우매우 쉽습니다.
아마 아이디어만 있다면 웹디자이너라도 쉽게 기본적인 어플은 만들 수 있겠더군요.

그리고 다음이 XNA인데, 게임 개발 플랫폼입니다. 상당히 흥미로운 점은 XNA로 개발된 윈모7게임은 XBOX와, WIN7에서도 똑같이 동작합니다. 물론 화면 사이즈에 맞춰서 다시 렌더링 되서 말이지요. 이게 소위 MS에서 이야기하는 3Screen입니다. 한번 개발해서 모바일,데스크탑,TV에서까지 모두 사용할 수 있다는 겁니다.
게임 개발 프레임웍도 상당히 쉽습니다. 10년전(?)에 Direct X로 게임 개발을 하고 OPEN GL로 3D 프로그래밍 경험을 했을때 이것저것 만드느냐고 상당히 시간이 오래걸렸는데, 허허~~ 오늘 보니 이건 거의 거져 만들더군요. 충돌 로직이나 조이스틱,화면 IO,애니메이션 처리.. 한마디로 거져라고 말할 수 밖에 없을만큼 쉬워졌습니다.

그럼 이런것들이 무엇을 뜻 하느냐?

1. 개발자들의 진입이 쉬워집니다.
누구나 아이디어만 있다면 기술의 장벽을 넘어서 컨텐츠를 제공할 수 있다는 겁니다.
2. 시장이 넓다.
XNA기반의 게임 컨텐츠는 한번 개발하면 PC,X-BOX,모바일 환경에 모두 판매가 가능합니다. 한마디로 개발자의 투자 대비 수익이 늘어나는 거지요..

이 두가지 특징만 해도 모바일 플랫폼으로 무시 못할듯 싶습니다.
여기에 더불어서, 윈모7 탑재 디바이스들은 철저하게 스펙 규약이 있기 때문에 (화면 사이즈, CPU 제약,메모리 제약). 안드로이드가 겪고 있는 여러 스펙의 디바이스로 부터 오는 문제를 피해갈 수 있습니다.

또한 MS의 Azure 클라우드는 모바일 서비스에 새로운 가능을 제시해줍니다. 3G망 기반의 모바일 애플리케이션들은 인터넷을 통해서 통신을 하거나 OPEN API들을 호출합니다. 애플이나 안드로이드에서 작동하는 앱들은 대부분 공개된 오픈 API를 사용합니다.
그렇다면 특화된 서비스를 개발하고 싶다면? 서버 사이드를 구축해야할 필요가 있다면?
사야져... 서버도 사고.. 세팅과 운영도 하고... 개인이 하기는 비용이 만만하지 않습니다. 그래서 일부 전문 업체만 서버를 두고 OPEN API를 통해서 자사의 앱과 통합하는 형태를 가집니다.
그런데....
MS는 Azure를 들고 나왔습니다. 클라우드 플랫폼이져.. 개발이 다른 클라우드 플랫폼에 비해서 매우 쉬운 (비주얼 스튜디오에 개발환경이 통합되어 있어서, 기존 웹 개발 환경만 이해한다면 별도의 Learning Curve가 필요없습니다. ) 장점을 가지고 있고, 사용량에 대해서 과금을 하기 때문에, 손쉽게 서버를 갖출 수 있습니ㅏㄷ.

XNA지원,3Screen,모바일용 클라우드 보유

이 3가지 장점만 해도 모바일 2라운드를 한번 해볼만 하지 않을까 싶네요.
애플이 4세대 아이폰을 내고, 안드로이드 2.2가 경이로운 성능을 보여주기는 하지만 근본적으로 접근 방법이 틀리다는데에서 기대를 걸어봅니다.

새직장 출근2일째...

사는 이야기 | 2010.04.27 10:09 | Posted by 조대협
오늘이 새직장 출근 2일째입니다.
새로 옮긴 직장은 다름이 아니라 Microsoft Korea입니다. 컨설팅에서 엔터프라이즈 고객을 대상으로하는 아키텍트롤을 맏고 있습니다.
자바만 하던놈이 왠 MS냐? 하실 수 있으실텐데... 여러 이유가 있겠지만 일단 블로그상을 통해서 밝힐 수 있는 이유는
  • 다들 아시겠지만, 현재 기술의 선도는 더이상 IBM,SUN,Oracle과 같은 벤더 보다는 Twitter,FaceBook,Google,Apple등 서비스 영역에서 이루어지고 있습니다. 엔터프라이즈 기술에 기반을 둔 저로써는 엔터프라이즈+서비스를 모두하고 있는 Microsoft가 하나의 선택이 됩니다.
  • 자바는 할만큼 했다? 10년 했으니 오래한것 같기는 합니다. :) 물론 새로운 기술이 계속 나오고 있으니, 할만큼 했다고 할 정도의 수준은 아니겠지요.. 그래도 이 시점에서 기술 영역을 확장해볼 필요가 있지 않을까 합니다. (앞으로 20년은 더 먹고 살아야할텐데요.. )

어제 부터 출근해서 교육도 받고 아직 임시노트북으로 이런 저런 자료 살펴보고 있습니다.
새 직장에서도 어느정도 적응기가 필요하겠지만 또 예전에 BEA에 처음 입사했을때 기분으로 1년은 열심히 파봐야 겠습니다.

==

잠깐 직장 이야기를 해볼까 합니다. Microsoft는 BEA,Oracle에 이어 3번째 외국계 직장입니다. 중간에 NHN으로 외도도 잠깐했습니다.
 Microsoft는 이 3개를 합해놓은 느낌입니다. 가볍게 적어보자면  

  • 큰 조직인 만큼 시스템이  많고, Policy 등이 복잡하다.프로세스가 느리다 : O사 처럼
  • 주방에 자판기에 음료수가 무료다 (예전 N사 보다 좋음), 단 아침은 식빵 토스트 셀프로 해먹는다. (이건 N사가 좋음. 매일 아침 줬는데...)
  • 매출과 타겟에 민감한건 외국회사는 다 매한가지다. :B,O사 공통

앞으로 몇년을 MS에서 먹고 살아야 합니다. 그 후에는 왼손에는 자바 오른손에는 .NET을 들고 나타날지도 모르겠습니다.

직장 옮기는 기간, 그리고 적응기간이라서 블로그 업뎃이 뜸했습니다.
새로운 제품과 방법론들 공부좀 하고 또 블로그 업데이트 하겠습니다.

아!! 기존 저랑 프로젝트 하셨던 또는 하고자 하셨던 고객분들.. 이제 MS 제품 필요하면 연락주세요.. :) 같이 고민해보시죠...