Cloud2017. 6. 16. 16:49

Cloud Friendly, Cloud Native 등 친숙하지 않은 개념들을 많이 듣게 됩니다.


Cloud Native Application은 Cloud 환경에 최적화된 애플리케이션이라고 할 수 있는데 이것만 가지고는 어떤 의미인지 이해하기가 어렵습니다.

기업들이 Cloud를 도입하는 이유가 뭘까요? 새로운 기술, 즉 트렌드라서? 분명한 이점이 있기 때문일텐데요, 

가장 대표적으로 IT자원에 대한 자산투자를 하지 않고, 데이터센터 및 서버/운영체제/스토리지/네트웍 등의 자원에 대한 운영인력을 줄이고 컴퓨팅 자원은 필요할 때 즉각적으로 사용하고, 사용량만큼 비용을 지불할 수 있기 때문일 겁니다. Cloud도입 초기에는 인프라(데이터센터, 서버/스토리지/네트웍 등)를 빌려쓰는 IaaS로도 효과를 충분히 볼 수 있었지만, IaaS를 사용해보면 알겠지만 운영체제의 운영, 데이터베이스 운영, 네트웍 및 미들웨어 (Tomcat, Jeus 등) 운영 등 실제 애플리케이션 개발을 위한 플랫폼 운영 관련한 인력이 유지되어야 하고, 플랫폼 소프트웨어 설치/운영/모니터링 등의 업무도 그대로 남게 됨을 알 수 있습니다. 소프트웨어 개발자와 시스템 운영자는 여전히 넘을 수 없는 벽을 사이에 두고 일하게 되고, 개발자가 짠 애플리케이션은 하나의 거대한 단일 애플리케이션 (Monolithic)으로 구성되어 있어, 그중의 일부를 바꾸기 위해서는 전체 애플리케이션을 빌드하고 배포해야 하므로 배포는 자주해서는 안되는 금기시되는, 고객에게 필요한 기능도 쉽게 적용할 수 없는 상황에 처하게 됩니다. 


Cloud에 최적화된 애플리케이션은 바로 위에서 벌어지는 다양한 불합리함을 극복할 수 있게 해주는데, 가장 중요한 factor는 자동화라고 볼 수 있을 것 같습니다. 여기서, DevOps, Continuous Delivery, Micro-service, 그리고 Container 개념이 등장하게 됩니다. 


DevOps는 소프트웨어 개발자와 IT운영자간의 협업을 의미하는데, 소프트웨어 배포(Delivery)나 인프라의 변경 프로세스를 자동화하는 목적으로 합니다. 소프트웨어의 개발, 테스트와 배포를 보다 더 빠르고, 자주, 안정적으로 할 수 있는 하나의 문화라고 볼 수 있을 것 같습니다. 


Continuous Delivery는 단위 애플리케이션이 변경되어 배포되어야 할 때 시스템 정비시간을 기다릴 필요없이 배포할 수 있는 특징을 의미합니다. 배포작업은 모든 개발자 및 시스템 운영자가 부담스러워 하는 작업인데, 위험부담을 줄이고 고객의 피드백을 빠르게 적용하여 경쟁자를 압도할 수 있게 됩니다. 넷플릭스나 Amazon.com이 하루에도 수십/수백번의 배포를 할 수 있는 것도 바로 Continuous Delivery 정책을 사용하기 때문입니다. 


Microservice는 작은 서비스의 결합으로 하나의 애플리케이션을 구성하는 아키텍처 디자인 접근방식입니다. 각 서비스는 HTTP API를 통해 통신하고, 서비스별로 배포, 업그레이드, 스케일 out 및 구동될 수 있고 타 서비스와의 연결고리가 약하게 되어 있기 때문에 사용자에게 영향을 최소화 또는 없게 업데이트할 수 있습니다. 


Container는 하나의 운영체제 (물리적서버 or VM에 무관)에 서로 독립적인 파일시스템과 리소스를 갖고 있는 container로 나뉘어 동작합니다. Container의 생성 및 폐기가 가상머신에 비해 엄청 빠르게 이루어지고, 자원도 거의 사용하지 않아 고집적으로 사용할 수 있습니다. 


바로 이러한 DevOps, CD, MSA, Container 방식으로 개발된 Cloud Native Application의 구동을 가능하게 하려면 PaaS (Platform as a Service)가 필요하게 되는데, 가장 많이 사용하는 플랫폼이 바로 Cloud Foundry 입니다. 

Posted by 조이트리
마이크로소프트2010. 6. 11. 10:06

글로벌 시장의 클라우드 진영을 살펴보면 이후에 어떤 모습으로 시장이 전개될지 예측해볼 수 있습니다.

그렇다면 왜 이렇게 진영을 나눠서 클라우드 비즈니스를 전개하고자 할까요? 물론 Market Share를 높여서 매출
볼륨을 높이고자 하는 것이 가장 큰 이유겠지만 클라우드의 기반이 가상화로 이루어져 있기 때문이기도 합니다.
예를 들면, EMC/NetApp 스토리지 기반으로 IBM 하드웨어에 VMWare를 이용해서 가상화를 적용해서 CRM 애플리케이션이 구동되고 있다고 가정을 해보겠습니다. CRM 애플리케이션의 동작에 문제가 생겼습니다. 이때 네트웍, 서버, 운영체제, 가상화, 스토리지 중에서 어디에서 문제가 생겼는지 알 수 있을까요? EMC는 IBM 하드웨어, IBM은 VMWare, 운영체제도 문제일 수 있고 애플리케이션 자체의 문제일수도 있겠네요. 소위 핑퐁 이슈가 발생할 수 있습니다. 가상화를 적용할 때 발생할 수 있는 큰 이슈라고 할 수 있겠죠.

이런 문제를 사전에 없애기 위한 방법이 모든 것을 내부의 리소스로 해결하거나 아니면 alliance로 풀 수 있습니다.
제가 초점을 맞춰서 설명하는 영역은 엔터프라이즈 고객이 Private Cloud를 구축하고자 할 때 어떤 선택을 할 수 있냐에 대한 것입니다. 구글, 아마존은 스스로 Public Cloud를 제공하는 옵션만 제공합니다. 고객의 내부 Private에 절대로 기술을 이전하고자 하지 않겠죠. 그들의 비즈니스 모델이니까요.

IBM은 모든 것을 다 스스로 하고자 합니다. 오라클도 Sun 인수를 통해 스스로 하려고 하고 있죠. VCE 연합도 Cisco가 서버를 만들면서 다 해결하고자 하고 있죠.

이제 마이크로소프트 연합이 남았네요. 마이크로소프트는 Windows Azure Platform이라는 훌륭한 Public Cloud를 가지고 있고 직접 클라우드 서비스를 하지만, 플랫폼 사업자이기 때문에 고객의 내부에 Private Cloud를 구축하는 것을 지원하고 이를 위해 다양한 Alliance를 맺고 있습니다. HP – Microsoft 연합, NetApp 스토리지 연합을 통해 마이크로소프트가 가지고 있지 않은 영역에 대한 부분을 훌륭하게 보완했습니다. 물론 다른 하드웨어 업체와도 당연히 조합이 가능하지만 글로벌 동맹을 맺고 있기에 마이크로소프트의 Private Cloud 솔루션인 Dynamic Data Center Toolkit과 Tight하게 연계되어 클라우드 솔루션이 진화하고 있습니다.

오늘은 NetApp의 스토리지와 어떻게 연동되었는지를 설명해보려고 합니다. 6개월 전에 Microsoft - NetApp이 동맹을 맺으면서 NetApp의 스토리지를 마이크로소프트의 표준 관리도구, 즉 System Center 제품군으로 제어할 수 있도록 하겠다고 했는데 드디어 기술 연동이 완료되었습니다. Microsoft의 Dynamic Data Center Toolkit과 밀접하게 연동되어서 toolkit을 통해서 Windows Powershell 커맨드렛을 호출하면 자동 프로비저닝, 복제, Fail-Over등을 자동화할 수 있게 되었습니다. Dynamic Data Center Toolkit을 통해 서버, 스토리지까지 클라우드 환경으로 적용할 수 있게 되었네요. 이 부분에 대해서는 파트너가 구현하면 다시 소식을 올려보도록 하겠습니다.

Posted by 조이트리
아키텍트2010. 2. 22. 08:56

지난 주 목요일에 블로터닷넷 포럼에 참여했습니다.

한국마이크로소프트가 선정한 2010년 10대 IT 트렌드, 클라우드 컴퓨팅, 그린 IT, 마켓플레이스, 모바일, 3스크린 전략과 새로운 사용자경험(UX) 기술, 가상화, 소셜리틱 애플리케이션, 통합보안환경, IT거버넌스, 소프트웨어 품질에 대한 의견과 그 중에서도 클라우드 컴퓨팅에 중점을 두어 진행했습니다.
자세한 내용은 http://www.bloter.net/archives/26093 (블로터닷넷)을 참고하시면 됩니다.

  • 일시 : 2010년 2월 17일(목) 오후 5시~7시
  • 장소 : 블로터닷넷 대회의실
  • 참석자 : 장현춘 부장(개발자 및 플랫폼 사업 총괄, 아키텍트 에반젤리스트), 신현석 부장(개발자 및 플랫폼 사업 총괄, 아키텍트 에반젤리스트), 도안구·이희욱·주민영 블로터닷넷 기자
mscloud100222shinbloterforum1020msittrend
Posted by 조이트리
마케팅2009. 12. 30. 15:44

Value라는 말을 참 많이 듣게 됩니다. 너의 Value, 너네 Product의 Value가 뭐야?

그렇다면 Value의 정의가 무엇일까요?
Give (주는 것) 보다 Take (받는 것)이 더 크면 Value가 있는 것이죠. 너무 추상적인가요?
다시 표현하면 Cost (비용) 보다 Profit (수익)이 많으면 Value가 있는 것이죠.
또 다른 표현으로 Price (가격) 보다 Quality (품질) or Product (제품)이 만족스럽다면 Value가 있는 것이라고 생각합니다.

그렇다면 만족이란 무엇일까요?
Satisfaction (만족) = f( Perceived Performance: 인지하는 성능 – Buyer’s Expectation: 구매자의 기대치), 즉 성능이 기대치를 넘어서면 만족을 하게 된다는 것이죠. 너무 당연한 말이라고요? 그렇다면 어떤 제안을 할 때 실제로 내가 이야기 하는 것이 고객이 지불하는 돈보다 더 많은 것을 주고 있다고 자신하시나요?

대부분의 영업사원은 내가 팔고자 하는 것에 관심을 둡니다. 구매자는 물건 자체를 구매 당하는 것을 좋아하지 않고 구매하는 것을 좋아하죠. 여러분은 어떠세요? 누가 뭐 사라고 하면 일단 관심 끄지 않나요? 하지만, 내가 가치가 있다고 느끼면 좀 비싸더라도 지름신이 강림하는 경우를 종종 경험하셨을 것 같습니다.

중요한 차이가 있습니다. 구매 당하는 느낌, 강매 당하는 듯한 느낌이 들지 않도록 하는 것. 영업이 하는 일은 고객이 물건을 구매하는 것을 돕는 것이죠, 즉 사도록 하는 느낌이 들도록, 잘 선택하도록 하는 것이죠. 바로 가치 제안이 필요한 이유 입니다. 자, 그럼 가치 제안에 포함될 내용이 어떤 것들이 있을까요? 가치제안은 Target Audience (타겟 고객)이 반드시 정해져야 합니다.

그림1. 가치 제안 (시소)

여기서 고객이 받는 것 (Take)와 주는 것 (Give)가 어디가 더 크냐에 따라서 Value를 느낄 수도 느끼지 못할 수도 있는 것이죠.

또 이렇게 생각해 볼 수도 있을 것 같아요. Value를 category별로 나누어서 분석해 보는 거죠.
클라우드 컴퓨팅에 대해 제가 한 번 적어볼까요?
1. Market : Disruptive technology (파괴적인 기술, 기존 시스템 구매, 운영의 패러다임이 바뀜)
                 - Simplicity & ease of use (간단함과 사용이 쉬움)
                Improve PR, awareness & image (홍보에 큰 도움, 회사 인지도 및 이미지 상승)
2. Income : Increase/sustain/protect revenue (매출의 향상, 지속적인 유지, 손실 가능성에 대한 보호)
3. Time : Reduce time to market (비즈니스 기회에 빠르게 대응)
              - Increase capacity, add capability (성능 향상 및 요구에 빠르게 대응)
              - Scalability & Elasticity (on-demand) (확장 및 수요의 감소에 신속히 대응, 온디맨드)
4. Institutional: Green IT, low carbon & electricity (그린 IT, 저탄소 및 저전력)
5. Cost : Reduce / manage / defer cost (비용의 절감, 관리)
             Change cost type: Capex → Opex (투자에서 비용으로)
             Buy instead of building, subscription instead of license (구축 대신 서비스로,라이선스가 월단위 비용으로)
6. Operational Efficiency : Operational efficiency ↑ (운영 효율성의 증대, 신규 IT 인력 교육 수요 감소)
             Reduce training for new IT personnel
7. Risk : In case of losing right timing, lose competitiveness (시기를 놓치면 경쟁력 약화)

MITICOR 라고 약자로 이해하면 쉽습니다. (이 category는 lustratus 사의 웹사이트에서 참고했고, Value proposition 내용은 직접 작성했습니다)

이 7가지 항목을 위의 시소에 적용해보면 어떻게 될까요? Market은 공통 요소, 받는 것은 (Income, Time, Operational Efficiency), 주는 것은 (Cost, Risk, Institutiinal)로 분류해볼 수 있겠죠.

이렇게 정리해보면 내가 전달하고자 하는 Value Proposition이 어떤 것인지 좀 더 구체적으로 알 수 있지 않을까요?

Posted by 조이트리
아키텍트2009. 2. 25. 17:42

앞에 썼던 글을 조금 더 깊이 있게 살펴 보는 글입니다.

Windows Azure

Windows Azure는 두 가지 중요한 일을 합니다. 애플리케이션을 구동하고, 데이터를 저장하는 거죠. 


그림 1: 최초 CTP 버전에서 Windows Azure 애플리케이션은 Web role, Worker role 인스턴스로 이루어지고, 각 인스턴스는 자신의 VM (가상머신) 위에서 구동됨

애플리케이션 구동

애플리케이션은 여러 개의 인스턴스를 가지고 있는데, 인스턴스는 전체 복사본 또는 애플리케이션의 일부를 포함하고 있습니다. 각 인스턴스는 자신만의 가상머신(VM) 위에서 구동되는데, 이 가상머신들은 64비트 Windows Server 2008 환경이고, 클라우드에서 사용되도록 디자인된 Hypervisor에 의해 제공됩니다. 그렇지만, Windows Azure 애플리케이션은 실제로 그 가상머신을 볼 수 없게 설계되어 있습니다. 개발자가 가진 VM 이미지를 Windows Azure에서 구동하는 것은 지원되지 않습니다. 그대신 , CTP 버전은 개발자가 Web Role 인스턴스, Worker Role 인스턴스를 통해 .NET 3.5 기반의 애플리케이션을 만들 수 있도록 되어 있습니다. 이름에서 알 수 있듯이, Web Role 인스턴스는 IIS7을 경유하여 HTTP (HTTPs) 요청을 받아 들이는데, Web Role은 IIS와 함께 동작하는 ASP.NET, WCF, .NET Framwork 기술을 통해 구현할 수 있습니다. Windows Azure는 동일한 애플리케이션의 일부분인 전체 Web Role 인스턴스 간에 요청을 분산할 수 있도록 빌트인 로드밸런싱을 제공합니다.

반면에, Worker Role 인스턴스는 외부로부터 요청을 직접 받아들 일 수 없게 되어 있습니다. 어떤 유형의 네트웍 커넥션도 허용되지 않고, IIS가 VM 안에서 구동되지도 않습니다. 그대신, Web Role 인스턴스에서 입력이 들어와서, Windows Azure Storage에 Queue 형태로 저장됩니다. 작업의 결과 값이 Windows Azure Storage에 저장되거나 외부로 보내지고, 외부로 나가는 연결을 허용하는 거죠. Incoming HTTP 요청을 처리하고, 요청이 처리된 후 shutdown 하는 Web Role과 다르게 Worker Role 인스턴스는 배치 작업처럼 무한정 길게 구동될 수 있습니다. 이런 특징에 맞게 Worker Role은 main() method를 가진 어떤 .NET Technoloy로도 구현될 수 있습니다. (Windows Azure Trust가 보장된다는 조건하에)

Web Role 인스턴스, Worker Role 인스턴스에 관계 없이 각 VM은 Windows Azure Fabric과 상호 교류할 수 있도록 해주는 Windows Azure Agent를 포함하고 있습니다. 이 Agent는 인스턴스가 Windows Azure 관리 로그를 쓸 수 있는 Windows Azure에서 정의된 API를 제공하며, 소유자에게 Windows Azure fabric을 경유하여 경고를 보내주기도 합니다. 시간이 지나면 바뀔 수도 있겠지만, Windows Azure의 초기 릴리즈 버전은 VM과 물리적 프로세서 코어 간 1:1 관계를 유지하게 되어 있고 이 원칙 때문에 각 애플리케이션의 성능이 보장됩니다. 각 Web Role, Worker Role 인스턴스는 자신에게 할당된 프로세서 코어가 있는 것입니다. 애플리케이션의 성능을 증가하기 위해, 소유자는 애플리케이션 설정 파일 안에 운영되는 인스턴스의 수를 증가시킬 수 있습니다.

그런 후에 Windows Azure Fabric이 새로운 VM을 생성한 후, 코어에 할당하고 이 애플리케이션에 더 많은 인스턴스를 구동하도록 합니다. Fabric은 또한 Web Role, Worker Role 인스턴스에 오류가 발생했을 때 새로운 인스턴스를 구동해주는 역할을 합니다.

이것이 의미하는 바는 확장성을 보장하기 위해, Windows Azure의 Web Role 인스턴스는 stateless 여야만 한다는 것이죠. 상태 정보는 Windows Azure Storage에 쓰여지거나, 쿠키를 이용하여 클라이언트로 보내져야만 합니다. Web Role의 statelessness는 또한 Windows Azure의 빌트인 로드 밸런서에 의해 강제화 되어집니다. 왜냐하면, 요청이 특정 웹 Role 인스턴스 에게만 보내지는 것을 허용하지 않기 때문이고, 한 사용자가 사용하는 여러 요청들이 동일 인스턴스로 보내진다는 보장이 없기 때문이죠. Web Role과 Worker Role은 모두 표준 .NET 기술을 사용하여 구현되었지만 현재 있는 .NET Framework 애플리케이션을 Windows Azure로 변경 없이 사용하도록 하는 것은 불가능합니다. 애플리케이션이 스토리지를 접근하는 방식이 다르기 때문이죠. Windows Azure Storage에 대한 접근은 ADO.NET 웹 서비스를 사용하는데, 상대적으로 새로운 기술이고 아직 On-Premise 애플리케이션 사이에서는 사용되고 있지 않습니다. 유사하게, Worker role 인스턴스는 입력을 위해서는 Windows Azure 스토리지의 Queue를 이용합니다. 또 다른 제약사항은 Windows Azure 애플리케이션은 Full Trust 환경에서는 구동되지 않고,  마이크로소프트가 Windows Azure trust라고 부르는 것에 제한되는데, 여러 ASP.NET 호스팅 업체에 의해 허용되는 Medium Trust와 유사하다고 보면 됩니다.

개발자 입장에서, CTP 버전의 Windows Azure 애플리케이션을 개발하는 것은 전통적인 .NET 애플리케이션을 만드는 것과 거의 같습니다. 마이크로소프트는 Windows Azure Web Role, Worker Role, 두 가지를 함께 쓸 수 있는 Visual Studio 2008 프로젝트 템플릿을 제공한다. 개발자는 어떤 .NET 언어든 사용할 수 있습니다 (최초 버전에서는 C# 지원). 또한, Windows Azure 소프트웨어 개발 Kit은 개발자의 데스크탑에서 운영할 수 있는 Windows Azure 환경을 포함하고 있다. (에뮬레이션) 이 Windows Azure-in-a-box는 Windows Azure Storage, Windows Azure agent, 그리고 클라우드 상에서 애플리케이션이 구동하면서 필요한 것은 다 포함되어 있습니다. 개발자는 이 환경에서 애플리케이션 디버깅을 할 수 있고, 테스트가 완료됐을 때 실제 Windows Azure Cloud로 배포할 수 있습니다. 아직도, 몇 가지는 실제 클라우드와 완전히 똑 같지는 않습니다. 참고로 클라우드 기반 애플리케이션에 디버거를 연결하는 것은 불가능하다. 로컬에서 테스트 한 후에 올려야 한다는 거죠. Windows Azure는 개발자를 위한 다른 서비스를 제공하는데, 예를들면 Windows Azure agent를 통해 경고 문자열을 보내고, Windows Azure는 이메일, 인스턴트 메시지 등을 통해 포워드하는 등이 그 예입니다. Windows Azure fabric은 애플리케이션 실패를 감지하고, 결고를 보낼 수 있고 또한, 애플리케이션의 자원 소비량, 프로세서 시간, incoming & outcome 대역폭, 스토리지 등에 대한 상세한 정보를 제공합니다.

Accessing Data

애플리케이션은 데이터와 다양한 방식으로 동작합니다. 어떤 때는 Blob, 또 다른 때는 훨씬 더 구조화된 방식이 필요하기도 하죠. 어떤 애플리케이션이든 데이터를 교환하는 방식이 필요한 것입니다. Windows Azure는 3가지 형태를 지원합니다. Blobs, Tables, Queues

 

그림2. Windows Azure는 HTTP를 통해 RESTful 스타일로 Blobs, Tables, Queues를 지원한다.

가장 간단한 건, blobs을 사용하는 방식 입니다. 스토리지 계정은 하나 또는 더 많은 개수의 컨테이너를 갖고 있고, 이 컨테이너는 하나 또는 더 많은 개수의 blob을 갖고 있습니다. Blob은 1개당 50기가 바이트 크기까지 가능하고, 각 blob은 블록으로 나뉘어 질 수 있습니다. 만약 오류가 발생하면, 전체 blob을 다시 보내는 것이 아니고 가장 최근의 block을 다시 보내주는 방식입니다. Blobs은 연관된 메타데이터 정보, JPEG 사진을 어디서 찍었고, MP3파일의 작곡가가 누구인지 등에 대한 정보를 가질 수 있다. Blob은 특정한 데이터, 사진, MP3, WMV 파일 등을 위해서는 좋지만, 많은 경우에는 적합하지 않죠. 따라서, Windows Azure는 Tables 을 지원합니다. 엔티티의 계층구조를 저장할 수 있는데, 테이블은 정해진 스키마를 가지고 있지 않고, 프로퍼티를 통해 다양한 유형의 데이터 타입, 문자열, Int, Bool, DateTime 등을 가질 수 있습니다. Windows Azure의 Storage는 SQL을 사용하는 것이 아니고, LINQ Syntax 등의 쿼리 언어를 사용하여 테이블의 데이터를 CRUD 할 수 있습니다. 테이블 한 개는 엄청 커질 수 있고, 수십억개의 엔티티를 저장할 수도 있는데, 이 것은 Windows Azure Storage가 성능을 향상할 수 있도록 여러 서버에 파티션으로 저장하기 때문입니다. Blobs과 Table은 데이터를 저장하는 목적이 있지만, 세 번째 방법은 Queue이고 다른 용도를 가지고 있습니다. 바로 그것은 Web Role 인스턴스가 Worker Role 인스턴스와 통신할 수 있는 방법을 제공합니다.

예를들면, 사용자가 Windows Azure Web Role을 통해 구현된 웹 페이지에서 컴퓨팅을 많이 필요로 하는 작업을 요청할 때 Web Role 인스턴스가 이 요청을 받아서 어떤 작업이 이루어져야 하는지에 대한 메시지를 큐에 넣고 Worker Role 인스턴스가 이 큐에 있는 값을 읽어서 정해진 작업을 수행하고, 다른 큐를 통해 해당 결과 값을 돌려줄 수 있게 됩니다. Blob, table, queue에 관계 없이 Windows Azure storage에 저장된 데이터는 3번 복제 된다. Falut tolerance를 구현하기 위한 것이고, 1곳, 또는 2곳의 오류는 심각한 이슈를 발생하지 않겠죠.

Windows Azure storage는 Windows Azure 애플리케이션, 또는 다른 곳에서 구동되는 애플리케이션을 통해서도 접근 가능합니다. 모든 경우에 Windows Azure 스토리지 유형은 데이터를 노출시키는데 REST 방식을 사용합니다. 모든 것은 URI로 이름이 부여되어 있고, 표준 HTTP 방식으로 처리됩니다. .NET 클라이언트는 ADO.NET 서비스나 LINQ를 사용할 수 있지만, Java 애플리케이션으로 Windows Azure Storage를 접근하려면 표준 REST 방식을 사용할 수 있습니다. 예를들면, blob은 HTTP GET을 이용해, URI를 아래와 같이 부를 수 있습니다.

.blob.core.windows.net//">http://<StorageAccount>.blob.core.windows.net/<Container>/<Blobname>
<Storage Account>는 새로운 Storage Account가 생성될 때 지정되는 식별자이고, 유일하게 이 계정에서 생성된 blob, table, queue를 찾아낼 수 있게 해줍니다. <Container>, <Blobname>은 컨테이너의 이름이고, 이 요청이 접근할 blob의 이름을 의미하죠.

유사하게 특정 table을 부를 때 사용되는 것은 아래와 같습니다.
.table.core.windows.net/?filter=">http://<StorageAccount>.table.core.windows.net/<TableName>?filter=<Query>
<TableName>은 조회될 테이블을 지정하고, <Query>는이 테이블에 실행될 쿼리문을 포함합니다.

Queue 역시 위와 같은 방식으로 사용된다
Http://<StorageAccount>.queue.core.windows.net/<QueueName>

Windows Azure 플랫폼은 Compute와 Storage 자원을 독립적으로 비용을 책정합니다. 이건 어떤 의미냐 하면 On-Premise 애플리케이션은 앞에 언급됐던 RESTful 방식으로 Windows Azure Storage만 사용할 수 있다는 것이죠. 물론 주요 목적은 Azure 애플리케이션의 데이터를 저장하는 것이지만, 다양한 형태로 사용될 수 있다는 것은 분명합니다. 애플리케이션을 사용하는 목적은 On-Premise든, Cloud든 애플리케이션 자체와 데이터를 지원하는 것입니다. Windows Azure 는 이러한 것들에 대한 기본적인 부분을 충실히 지원합니다.

.NET Services

클라우드 기반의 인프라스트럭처, 이 서비스는 On-Premise 또는 클라우드 기반 애플리케이션에 의해 모두 사용될 수 있습니다.

Access Control

Identity는 모든 분산 애플리케이션의 근원적인 부분입니다. 사용자의 Identity 정보를 기반으로 사용자가 어떤 일을 하도록 할 것인지 결정하게 되는데 이 정보를 전송하기 위해 애플리케이션은 SAML(Security Assertion Markup Lanaguage)를 사용하는 토큰을 사용합니다. SAML 토큰은 클레임, 각 사용자에 대한 정보 들을 나눠서 저장하고 전달하는, 값을 갖고 있는데, 하나의 클레임은 이름을 갖고 있고, 또 다른 클레임은 관리자와 같은 Role에 대한 정보를 갖고 있고, 다른 클레임은 이메일 값을 가지고 있을 수 있습니다. 토큰들은 STS(Security Token Service)라고 하는 소프트웨어에 의해 생성되는데, 각각 디지털적으로 그 Source값을 검증하도록 되어 있는 방식이죠.

클라이언트 (브라우저)가 사용자의 토큰을 가지고 있고, 그 토큰 값을 애플리케이션에게 제시할 수 있습니다. 애플리케이션은 이 사용자가 어떤 일을 할 수 있는지 결정하는데 그 토큰의 클레임을 사용하는 방식입니다. 여기에는 몇 가지 문제점을 내포하고 있는데 다음과 같습니다.

  1. 토큰이 애플리케이션이 필요로 하는 클레임을 갖고 있지 않다면? 클레임 기반 아이덴티티를 가지고, 모든 애플리케이션은 클레임의 집합을 자유롭게 정의할 수 있지만, 이 토큰을 만들었던 STS가 이 애플리케이션이 요구하는 클레임을 정확히 입력하지 못했을 수 있습니다.
  2. 애플리케이션이 STS가 생성한 토큰을 신뢰하지 못한다면? 아무 STS로나 생성된 토큰을 애플리케이션이 신뢰할 수는 없겠죠. 대신 애플리케이션은 신뢰된 STS의 인증서 리스트를 선택하여 접근할 수 있고, 서명이나 토큰을 검증할 수 있을 것입니다. 신뢰된 STS를 통해 발급된 토큰만 받아들이는 형태를 취할 수 있습니다.

프로세스안에 또 다른 STS를 집어 넣음으로써 두 가지 문제를 모두 해결할 수 있다. 토큰이 올바른 클레임을 담고 있는지 확인하기 위해 이 추가적인 STS가 클레임 변환을 시도하는 것입니다. STS는 클레임의 입력 및 출력이 어떻게 연관되어야 하는지에 대한 Rule을 정의할 수 있고, 애플리케이션이 요구하는 정확한 클레임을 포함하고 있는 새로운 토큰을 생성할 수 있는 룰을 사용할 수 있습니다.

두 번째 문제를 해결하기 위해, 일반적으로 애플리케이션이 새로운 STS를 신뢰할 수 있도록 하는 Identity Federation이라는 하는 방식을 사용합니다. 새로운 STS와 STS의 토큰을 요청 받은 측과 신뢰 관계를 형성하는 것입니다. 또 다른 STS를 집어 넣는 데는 클레임 변환과 Identity Federation을 사용할 수 있습니다.

이 STS를 어디에서 구동해야 하나? 조직 내부에서 구동할 수도 있고, 다른 벤더에서 제공하는 서비스를 사용할 수도 있습니다. 이런 경우에는 조직 내부에 있든 외부에 있든 누구나 접근 가능하고, STS를 운영하는 짐을 서비스 제공자가 담당하도록 하는 것입니다.

바로 이 기능이 Access Control의 역할 입니다. 클라우드 상의 STS인 것이죠. 이 STS가 사용되는 방식을 살펴보겠습니다. ISV가 인터넷 접근 가능한 애플리케이션을 개발했는데 이 애플리케이션은 여러 다른 조직의 사용자가 사용하고 있습니다. 각 조직에서는 그 조직의 직원을 위해 SAML 토큰을 제공하지만, 이 토큰들은 해당 애플리케이션이 필요로 하는 정확한 클레임을 포함하고 있지 않은 경우가 많습니다.

 

 

그림3: Access Control 서비스는 Rule 기반의 클레임 변환과 Identity Federation을 제공한다

우선, 사용자 애플리케이션 (브라우저, WCF 클라이언트 등)이 사용자의 SAML 토큰을 Access Contril 서비스에 보냅니다 (1), 이 서비스가 해당 토큰의 서명을 검증한 후, STS서비스가 신뢰하는 STS에 의해 생성된 것인지 확인합니다. 해당 서비스가 애플리케이션이 요구하는 클레임을 포함한 새로운 SAML 토큰을 서명한 후 만듭니다 (2). 이러한 작업을 하기 위해 Access Control 서비스의 STS는 사용자가 사용하려는 애플리케이션 소유주가 정의한 룰에 따라 토큰을 만듭니다. 예를 들어, 애플리케이션이 해당 회사의 관리자에게만 접근 권한을 부여한다고 가정해보죠. 각 회사는 사용자가 관리자라고 하는 것을 나타내는 토큰을 클레임에 포함하고 있을 수 있지만, 실제로 표현 방식이 전부 다릅니다. 한 회사는 "Manager", 또는 다른 회사는 "Supervisor"라고 사용하고, 또 다른 회사는 코드를 쓸 수도 있겠죠. 이런 다양한 표현을 처리하기 위해 소유자가 이 세가지 클레임을 공통된 문자열 "Decision Maker"라고 변환하는 Rule을 Access Control에 넣을 수 있을 겁니다. 이 애플리케이션 입장에서는 처리하는 방식이 정말 간단해졌죠. 그렇지 않은가요? ^^

생성된 후에 Access Control 안의 STS가 이 새로운 토큰을 클라이언트에 보냅니다 (3). 그리고 그것을 애플리케이션으로 전송합니다. (4) 애플리케이션이 토큰의 서명을 검증한 후, 그 토큰이 정말로 Access Control Service의 STS에서 만들어졌는지 확인합니다. 서비스의 STS는 각 고객 조직의 STS와 신뢰 관계를 갖고 있어야 하고, 그 애플리케이션은 Access Control Service STS와만 신뢰관계를 가지고 있으면 됩니다. 토큰의 출처만 확인되면, 애플리케이션은 클레임을 통해 이 사용자가 무슨 일을 하게 할지, 말지에 대해 결정할 수 있게 됩니다.

애플리케이션의 특정 Function에 대한 접근을 허용하기 위해, 사용자가 특정 클레임을 제시해야 한다고 생각해보죠. 애플리케이션이 사용자의 토큰을 받았을 때, 이 클레임의 존재 유무에 따라 접근을 허용/거부할 수 있습니다.

Access Control은 모든 통신에 WS-Trust, WS-Federation 같은 표준 프로토콜을 사용합니다. 바로 이것 때문에 어떤 플랫폼을 사용하든, 어떤 애플리케이션이든 관계없이 쓸 수 있게 된 것이죠. Rule을 정의하기 위해 브라우저 기반의 GUI, 프로그래밍을 위한 클라이언트 API를 모두 제공합니다.

클레임 기반의 Identity는 분산 환경을 위한 표준적인 접근 방식입니다. 클라우드에서 STS를 제공함으로 Rule 기반의 클레임 변화을 제공하기 때문에 Access Control은 매력적인 방식 중의 하나라고 생각합니다.

Service Bus

우리 회사 내부에서 구동되는 애플리케이션이 있는데, 인터넷을 통해 다른 회사에서 접근 가능하도록 하고 싶다고 가정해보죠. 당신의 애플리케이션이 웹 서비스로서 구현되었다 (RESTful, SOAP 기반), 이런 경우 이 웹서비스는 외부 세계에서 볼 수 있습니다. 그런데, 실제로 외부세계와 함께 사용하려고 할 때 몇 가지 문제점이 있습니다.

첫째, 다른 조직의 애플리케이션이 당신 서비스에 연결할 Endpoint를 어떻게 찾을 수 있나요? 물론 다른 조직에서 여러분 애플리케이션의 위치를 찾을 수 있는 어떤 레지스트리가 있다면 좋겠지만 말이죠. 일단 찾았다고 하면, 다른 조직의 소프트웨어가 여러분의 애플리케이션에 어떻게 요청을 할 수 있죠? Network Address Translation(NAT)를 사용하고 있고, 애플리케이션이 외부에 노출되기 위한 고정 IP 주소를 가지지 않은 경우에는 어떻게 할까요? 비록 NAT가 사용되지 않더라도, 어떻게 그 요청이 방화벽을 통과하고 들어올 수 있죠? 물론 방화벽에 해당 포트를 개발하면 가능하겠지만, 대부분의 네트웍 관리자는 이런 포트 개방에 대해 부정적입니다. 그렇지 않나요?

 

그림4: Service Bus는 애플리케이션의 endpoint를 등록하고, 다른 애플리케이션이 찾고 접근할 수 있도록 함

당신의 애플리케이션을 Service Bus를 통해 하나, 또는 여러 개의 end point를 등록합니다(1) Service Bus가 당신 조직에 URI Root를 지정하고, 거기서부터 당신은 어떤 이름을 사용하든 관계없이 좋아하는 계층 구조 형태로 만들 수 있습니다. 이렇게 되면 당신의 endpoint가 특정, 검색 가능한 URI에 지정됩니다. 이때 애플리케이션은 노출시킬 endpoint를 위해 Service Bus와 연결을 개방해야 한다. Service Bus가 이 연결의 열려진 상태로 유지하므로 위에 발생했던 문제가 해결되는 것입니다.

첬째, NAT는 더 이상 이슈가 아닌데, 그 이유는 Service Bus에 개방 된 연결을 통해 트래픽이 항상 당신의 애플리케이션으로 라우팅 됩니다.

둘째, 연결이 방화벽 내부에서 이루어졌기 때문에 애플리케이션 사이에 정보를 보내는 것이 더 이상 문제가 아닙니다. 방화벽이 이 트래픽을 차단하지 않기 때문입니다.

다른 조직에서 당신의 애플리케이션에 대한 접근을 원할 때, 서비스버스 Registry를 찾습니다(2) 이 요청은 Atom Publishing 프로토콜을 사용하는데, 당신 애플리케이션의 endpoint에 대한 참조값을 보내는데 AtomPub 서비스 도큐먼트 값을 되돌려줍니다. 일단, 이 값이 있으면, 이 endpoint를 통해 서비스를 가져올 수 있습니다. (3)

각 요청이 Service Bus를 통해 받아들여지고, 당신의 애플리케이션으로 보내 집니다.
커뮤니케이션을 쉽게 하는 장점 이외에도, Service Bus는 보안을 강화시킬 수 있습니다. 클라이언트가 Service Bus에 의해 제공되는 IP주소밖에 볼 수 없기 때문에, 여러분 조직의 IP 주소를 외부로 노출시킬 필요가 없게 되는 거죠. 여러분의 애플리케이션은 anoynymous로 보여져, 외부 세계는 IP 주소를 볼 수 없게 됩니다. Service Bus가 외부 DMZ의 역할을 하고, 공격자를 혼란스럽게 하는 역할을 하게 됩니다. 마지막으로, Service Bus는 Access Control 서비스와 함께 사용되도록 만들어졌는데, 룰 기반의 클레임 변환을 허용합니다. 사실, Service Bus는 Access Control의 STS 서비스에 의해 발행된 토큰만 받아들이죠.

Service Bus를 통해 서비스를 노출시키려는 애플리케이션은 주로 WCF를 통해 구현되는데, Java 같은 기술로 구현된 클라이언트들은 SOAP, HTTP 등을 통해 요청할 수 있습니다. 애플리케이션과 클라이언트들은 공격자와 Service Bus 자체의 통신을 보호하기 위해 자체 보안 메커니즘, 암호화 등을 이용할 수 있습니다.

애플리케이션을 외부에 노출시키는 것은 생각만큼 간단하지 않은데, Service Bus는 이것을 아주 간단하게 쓸 수 있도록 해주는 역할을 합니다.

Workflow

Windows Workflow Foundation은 워크플로우 기반의 애플리케이션을 만드는 일반적인 기술입니다. 워크플로의 전형적인 시나리오는 길게 수행되는 프로세스를 제어하는 것이고, 종종 엔터프라이즈 애플리케이션 통합에서 이루어지는 일입이다. WF 기반의 애플리케이션은 많은 종류의 업무를 조율하는데 좋은 방법인데 특히, 그 업무가 다른 조직에 위치한 경우 클라우드 상에서 로직을 제어할 수 있도록 하는 것은 좋은 대안이 된다고 생각합니다.

워크플로우 서비스는 이렇게 진행됩니다. WF3.5 기반의 애플리케이션을 호스트하기 위해, 개발자가 클라우드에서 구동되는 워크플로우를 만들 수 있습니다.

그림 5: Workflow Service는 HTTP나 Service Bus를 통해 통신하는 WF 기반의 애플리케이션을 만들 수 있도록 함

모든 WF 워크플로우는 몇 가지 activitity를 사용하여 구현되는데 각 activity는 메시지를 보내거나 받는 등의 일부터, If 조건문을 구현하거나, While Loop 등의 만드는 등의 작업을 수행합니다. WF는 Base Activity Library(BAL)이라고 불리는 activity의 표준 집합을 제공하는데, Workflow 서비스는 애플리케이션이 BAL의 부분집합을 사용하도록 할 수 있고 자체적인 activity도 제공할 수 있는데, 예를 들면, HTTP를 사용하는 다른 소프트웨어와 통신하거나, 서비스 버스를 사용하는 서비스와 통신할 수 있습니다. 애플리케이션 통합에서 요구되는 XML 메시지와의 연동 등도 가능합니다. 클라우드 상에서 운영됨으로 WF 순차적인 워크플로우 모델만 사용 가능하다는 한계가 있고 임의적으로 작성한 코드는 쓸 수 없습니다.

워크플로우 서비스를 위한 애플리케이션을 만들기 위해서는 개발자가 Visual Studio의 표준 Workflow 디자이너를 사용할 수 있습니다. 일단 쓰여지면, WF 기반의 애플리케이션은 브라우저 기반의 포탈을 사용하거나 Workflow API를 통해 배포될 수 있죠. 서비스 버스와 마찬가지로 Workflow 서비스와 연동되는 애플리케이션은 Access Control Service로부터 토큰을 받아야만 한다. (Trusted STS) WF 기반의 애플리케이션이 모든 경우에 적합한 대안은 아니지만 적절한 시나리오에 활용하는 것을 고려하는 것은 가능할 것 같습니다.

SQL Services

데이터를 저장하고, 분석하고, 리포트를 만드는 등의 모든 작업을 포괄하는 서비스입니다. 데이터베이스가 제공하는 핵심적인 기능들을 제공하기 위한, 그 첫 번째 시도가 SQL Data Services 입니다.

클라우드 상의 데이터베이스는 많은 경우에 매력적입니다. 많은 기업이 전문적인 서비스 제공자가 안정성, 백업 대행, 기타 관리적인 부분을 대신하는 것에 관심이 있습니다. 클라우드 상의 데이터는 애플리케이션이 모바일 장치를 포함하여 어디서든 다 접근이 가능하다는 것이 매력입니다. 서비스 제공자는 규모의 경제를 통해서 좋고, 비용이 직접 구축하는 것에 비해 훨씬 저렴합니다. 


그림 6: SQL Data Services는 데이터센터에 authorities로 나뉘어 저장되고, authority는 container를 갖고 있으며, container는 Entity를 실제적인 값은 Property에 저장됨

 하지만, 인터넷 같이 불특정 상황의 확장성이 요구되는 공간에 안정적이고, 고성능 데이터베이스를 제공하는 것은 쉬운 일이 아닙니다. Tradeoff이 요구되는 것이죠. SQL Database는 표준 관계형 데이터베이스를 제공하는 것이 아니고, SQL 쿼리를 지원하지도 않습니다. 데이터가 구조적인 형태로 조직화 되어 있습니다.
SQL Data Services는 여러 데이터센터에 나뉘어서 정보를 저장합니다. 각 데이터 센터는 일정양의 Authorities를 갖고 있는데, Authority는 geo-location의 Unit이고, 유일한 DNS 이름을 갖습니다. Authority는 Containers를 보유하고, 그 각각을 여러 데이터센터에 복제해 놓습니다. Containers는 로드 밸런싱과 가용성을 목적으로 사용됩니다. 만약, 오류가 생기면 SQL Data Services는 자동으로 Container의 복제본을 사용하도록 변경 됩니다. 모든 쿼리는 특정 container를 대상으로 이루어지고, authority를 넘어서는 쿼리는 허용되지 않습니다. 각 container는 몇 개의 entity를 갖고 있고, 이 entity는 property 정보를 갖습니다. 이 property가 name, 데이터타입, 그리고 그 데이터타입의 값을 갖게 됩니다. SQL Data Services는 String, DataTime, Base64Binary, Boolean, Decimal 등의 데이터 타입을 지원하고,애플리케이션은 MIME Type을 가지고 Blobs을 저장할 수 있습니다.

이 데이터를 조회하기 위해 애플리케이션은 몇 개의 옵션을 갖고 있습니다. 하나는 LINQ C# Syntax와 유사한 언어를 사용하여, SOAP,RESTful 응 통해 쿼리를 보내는 방법입니다. 다른 하나는 ADO.NET Data Services를 사용하는 것입니다 (RESTful 방식의 대안). 또 다른 경우에는 애플리케이션이 ==, !=, <,>, AND, OR, NOT 등의 연산자를 container를 대상으로 보내는 것입니다. 쿼리는 ORDER By, Join같은 SQL과 유사한 연산을 포함할 수 있습니다.

쿼리는 프로퍼티가 아닌 entity를 대상으로 조회, 수정 등의 연산을 할 수 있습니다. 쿼리는 엔티티들에 대한 값을 리턴하는데, 포함한 모든 프로퍼티를 포함하여 조회할 수도 있습니다. 엔티티는 미리 지정된 스키마를 갖고 있지 않기 때문에, 프로퍼티는 다양한 데이터 유형을 가질 수 있습니다.SQL Data Services 내부의 데이터는 URI를 가지고 불리워지는데 일반적인 형태는 아래와 같습니다.

http://<Authority>.data.database.windows.net/v1/<Container>/<Entity>

데이터는 REST를 통해 접근될 수 있고 (HTTP), 어떤 플랫폼상의 애플리케이션도 SOAP을 통해 사용 가능합니다. 플랫폼의 종류와 관계없이 애플리케이션은 SQL Data Services에 미리 정의된 사용자이름/패스워드, 또는 Access Control 서비스 STS에 의해 만들어진 Token에 의해 사용자를 인증할 수 있습다.

마이크로소프트는 SQL Data Services를 지금 보다 더 관계형에 가까운 기술로 진화시키고 있다.

David Chappell의 글을 기준으로 작성하였습니다.

Posted by 조이트리
아키텍트2009. 2. 25. 16:41

제가 마이크로소프트의 클라우드 컴퓨팅, Windows Azure, Azure Services Platform에 대해 공부하다가 작성하였습니다. 참고하시고 이해에 도움이 되시면 좋겠습니다. 이 글은 기본적인 개념을 잡는데 도움이 됩니다. 조금 더 구체적인 내용은 다음 글에 적도록 하겠습니다.

마이크로소프트의 클라우드 컴퓨팅은 크게 2개 영역으로 나뉘어져 있습니다. Windows Azure, 그리고 Azure Services Platform이 바로 그것이지요.

The Cloud Computing and Services Platform Diagram

Windows Azure는 클라우드 상에 데이터를 저장하고, 윈도우 애플리케이션이 구동될 수 있는 환경을 제공하는 플랫폼입니다. Windows Azure 는 클라우드 애플리케이션에게 윈도우 기반의 컴퓨팅, 스토리지 서비스를 제공합니다.

Windows Azure
Windows Azure는 마이크로소프트 데이터센터에 위치한 수많은 서버 위에서 운영되는데, 인터넷을 통해 접근 가능합니다. Windows Azure Fabric Knit (잘 짜여진 Fabric)은 강력한 프로세싱 파워를 통합된 하나로 묶어 주는데, Windows Azure의 Compute & Storage서비스는 이 Fabric 위에 구축되었습니다.
Windows Azure Compute Service는 기본적으로 Windows 기반으로 이루어져 있고, 초기 버전 CTP(Community Technology Preview)는 .NET Framework 기반으로 구축된 애플리케이션만 구동되지만, Unmanaged 코드 역시 지원할 계획을 가지고 있습니다. (2009년 중에 발표 예정)

CTP 버전에서는 ASP.NET 애플리케이션과 Windows Communication Foundation (WCF) 서비스 같은 .NET 기반의 소프트웨어를 만들 수 있는데 C#, 기타 다른 .NET 언어를 Visual Studio 2008 같은 개발 도구를 이용할 수 있습니다. 웹 애플리케이션과 별도로 동작하는 백그라운드 프로세스를 지원합니다.

Windows Azure 애플리케이션, On-Premise 애플리케이션 모두 RESTful 접근을 통해 Windows Azure Storage 서비스를 이용할 수 있습니다. Windows Azure의 스토리지는 Microsoft SQL Server 기반이 아닙니다. Windows Azure Storage는 관계형 시스템이 아니고, 쿼리 언어도 SQL이 아닙니다. Storage 서비스는 Windows Azure 위에 구축된 애플리케이션을 위해 디자인됐고, 간단하고 확장 가능한 스토리지를 제공합니다. Blob(Binary Large Object), Windows Azure 애플리케이션 간의 커뮤니케이션을 위한 Queue를 지원하고, 직관적인 쿼리 언어를 사용하는 테이블을 지원합니다.

클라우드 서비스를 위해서는 효과적인 관리가 가능해야 하는데, Windows Azure의 각 애플리케이션은 설정 파일을 가지고 있고 이 파일을 수작업, 또는 프로그램을 통해 수정하면, 애플리케이션 개발자는 사용할 Windows Azure 인스턴스의 개수 변경 등의 정책을 통제할 수 있습니다. 또한, Windows Azure Fabric이 원하는 상태를 유지할 수 있도록 애플리케이션을 모니터링 합니다.

개발자가 개발, 설정, 모니터링 하는 등이 가능하도록 브라우저 기반의 포탈을 제공합니다. 애플리케이션을 구동하기 위한 호스팅 계정을 만들거나, 데이터를 저장하기 위한 스토리지 계정을 만드는 등의 작업이 가능합니다.

1. Start up, 즉 사업을 시작하는 회사가 웹사이트 구축(Facebook), 웹 서비스와 백그라운드 프로세스를 모두 구현 가능하므로 , 애플리케이션은 인터랙티브한 사용자 인터페이스를 제공합니다. (비동기 작업 가능) 인프라에 대한 걱정 없이, 사용자와 투자자에게 가치를 제공할 수 있는 코드 개발에 집중할 수 있습니다.
사용자가 적다면, 비용도 엄청 저렴할 것이고, 사용량이 늘어나면 Windows Azure가 자동 확장해주는데 이때는 매출이 발생할 것이기 때문에 비용을 지불하고도 수익을 낼 수 있는 구조 입니다.

2. 현재 On-premise 방식의 솔루션을 SaaS 버전으로 변경
Windows Azure가 표준 .NET 기반 환경이기 때문에 애플리케이션의 .NET 비즈니스 로직을 클라우드 플랫폼으로 변경하는 것이 그리 어렵지 않습니다. ISV가 비즈니스 로직에만 집중할 수 있습니다. (인프라에 대한 고민 No)

3. Enterprise
Windows Azure가 .NET 기반이기 때문에 기존의 기술이 있다면 개발이 어렵지 않습니다. 기존의 자산투자비용 -> 운영비용으로 개념이 바뀝니다. 크리스마스, 졸업 입학 선물 시즌 등의 사용량 증가를 고민할 필요가 없이, 클라우드 서비스 제공자에게 맡기면 됩니다.

Azure Services Platform

.NET Services

클라우드 상에 애플리케이션을 구동하는 것은 클라우드 컴퓨팅의 중요한 부분이긴 하지만, 그것보다 더 큰 영역이 있습니다. 클라우드 기반의 서비스를  On-Premise 애플리케이션과 Cloud 애플리케이션이 모두 이용할 수 있기 때문입니다. 이 두 영역간의 간격을 좁혀주는 역할을 .NET Services가 제공합니다.

분산 애플리케이션을 개발할 때 공통적으로 발생하는 어려움을 극복하기 위한 것이 .NET Services의 목적입니다.

Access Control: 애플리케이션에게 각 사용자의 정보를 담고 있는 클레임을 토큰 형태로 제공하는 것

즉, 애플리케이션이 이 클레임을 기준으로 어떤 일을 할 수 있는지 결정하도록 하는 것을 의미합니다.
여러 회사간에 이런 일이 가능 하려면 Identity Federation, 즉 한 Identity 영역에서 생성된 클레임이 다른 조직에서 받아들여질 수 있도록 하는 작업이 필요한데 이러한 역할을 Access Control이 담당합니다.

Service Bus: 인터넷 상에 애플리케이션 서비스를 노출시키는 것은 생각보다 쉽지 않습니다. Service Bus의 목표는 웹 서비스의 Endpoint를 노출시켜서 On-Premise, 클라우드 상의 다른 애플리케이션이 쉽게 접근할 수 있도록 하는 것입니다. 각 Endpoint에 대한  위치를 찾고 접근할 수 있도록 하는 것이지요. URI로 지정되어 있습니다. Service Bus는 또한 NAT(Network Address Translation), 노출된 애플리케이션이 새로운 포트를 열지 않고 방화벽을 통과하도록 하는 등의 역할을 제공합니다.

Workflow: 복잡한 애플리케이션을 개발하는 것, 즉 엔터프라이즈 애플리케이션 통합 등은 여러 부분의 상호작용을 조절하는 로직이 필요합니다. 이 로직은 오래 수행되는 프로세스들이 처리될 수 있도록 워크플로우를 사용하여 구현되는데,Windows Workflow Foundation(WF) 기반으로 구축되어 있습니다

몇 가지 예제

- 여러 다른 회사의 고객들이 사용하는 애플리케이션을 제공하는 ISV, Access Control 을 사용하여 애플리케이션
  개발 및 운영 단순화

여러 회사에서 요구하는 다양한 클레임을 해석하는 컴포넌트를 제공함으로, 각 회사들은 독자적인 아이덴티티 기술을 그대로 사용하면서, ISV 애플리케이션은 일관된 형태로 대응하여 개발 가능합니다. 또한, Identity Federation을 사용하지 않고 클라우드 기반의 Access Control 서비스를 사용하여 ISV가 On-premise Federation S/W를 운영할 필요가 없어집니다.

 

  1. 엔터프라이즈가 거래처를 대상으로 애플리케이션 하나에 대한 접근을 허용하고자 할 때 이 애플리케이션의 기능을 SOAP, RESTful 웹서비스를 통해 노출시키고, Endpoint를 Service Bus로 등록합니다. 해당 거래처가 서비스 버스를 통해 Endpoint를 찾을 수 있고, 서비스에 접근하게 되는데, 이런 과정 중에 방화벽상에 포트를 개방 할 필요가 없기 때문에 애플리케이션을 노출시키는 위험성을 줄여줍니다. 해당 조직은 또한 Access Control 서비스를 사용할 수 있을 것이고, 이 Access Control은 Service Bus와 함께 사용할 수 있도록 디자인되었기 때문에 거래처에게 해당 Identity 정보를 보내는 것이 아주 용이해집니다.
  2. 위의 예제에서 거래처와의 비즈니스 프로세스가 일관되게 이루어져야 하는데, 이럴 때 WF 기반의 애플리케이션인 Workflow 서비스가 이용될 수 있습니다. 서비스 버스를 통해 통신하고, Access Control을 통해 Identity 정보를 교환하고, Workflow로 비즈니스 프로세스를 처리할 수 있게 되는 것이죠.

Windows Azure의 브라우저로 접근 가능한 포탈을 통해 Windows Live ID를 통해 .NET Services를 신청할 수 있습니다. .NET 서비스의 목표는 분명한데, 분산 애플리케이션을 위해 유용한 클라우드 기반의 인프라를 제공하는 것입니다

SQL Services

이 기술을 통해 On-premise, 클라우드 기반 애플리케이션이 마이크로소프트 데이터 센터내의 서버에 데이터를 저장하고, 접근할 수 있습니다. 사용한 만큼만 지불하고, 조직의 필요성의 증감에 따라 증가, 감소할 수 있다는 것을 의미하고, 디스크, DBMS, 운영 등의 자산 투자를 운영비용으로  바꿀 수 있게 되는 거죠. 가장 큰 용도는 여러 장치, 위치에 관계 없이 접근 가능하다는 것이고, 이를 위해 SOAP, RESTful 인터페이스를 통해 노출시켜 다양한 방법으로 접근할 수 있게 됩니다. 데이터가 표준 프로토콜을 통해 노출됨으로 SQL Data Services는 어떤 유형의 시스템으로부터도 사용될 수 있다. (Windows만의 기술이 아님)

Windows Azure Storage 서비스와 달리, SQL Data Services는 Microsoft SQL 서버 기반으로 구축됩니다. 하지만, 전통적인 관계형 인터페이스를 제공하지 않고, 계층적 데이터 모델을 제공합니다. 이 서비스에 저장된 각 아이템은 Name, Type, Value의 프로퍼티로 저장되고, 이 데이터를 쿼리하기 위해 Microsoft Language Integrated Query (LINQ)에 의해 C# Syntax로 정의된 언어이거나, RESTful 접근을 통해 사용할 수 있습니다.

왜 이전의 SQL Server를 다루던 방식을 사용하는 대신, 다른 형태의 SQL Services를 제공할까요? 새로운 방식이 데이터를 조직화하고, 검색하여 replication, 로드밸런싱을 제공하는 것을 더 쉽고 빠르게 하기 때문입니다.

예제

  1. 애플리케이션이 오래된 데이터를 SQL Data Services로 아카이브 할 수 있습니다. 빈번히 업데이트되는 RSS 피드를 생각해보면, 30일 이상 된 자료의 경우 거의 사용되지 않지만, 여전히 사용 가능해야 하는데 이러한 데이터를 SQL Data Services에 저장하면 저렴한 가격으로, 안정적인 서비스가 가능합니다.
  2. 딜러와 소비자에게 프로덕트 정보를 제공하려고 하는 제조업자가 있다고 가정하면, 이 데이터를 SQL Data Services에 넣는다면 딜러와 고객 웹사이트에서 모두 접근 가능하도록 할 수 있을 겁니다. 데이터가 RESTFul , SOAP 인터페이스로 접근 가능하므로, 어떤 플랫폼에서 구동되든, 어떤 기술을 사용하는 애플리케이션이든 관계없이 해당 서비스를 쓸 수 있게 되는거죠. SQL Data Services는 쓰기가 정말 쉽습니다. 웹 포탈에 가서, 필요한 정보를 입력하면 되는데, 데이터를 아카이빙 하는 것이든, 여러 위치에서 접근 가능한 애플리케이션을 만드는 것이든, 클라우드 데이터베이스는 매력적임에 분명합니다.

David Chappell이 쓴 백서를 기준으로 작성했습니다.

Posted by 조이트리
아키텍트2008. 12. 3. 13:03
해당 행사에는 제가 준비 위원으로 참여 중 입니다.

오전에 기자간담회가 있는데, 기자 간담회 Q&A 세션에 저도 참가합니다. 후기는 공지하도록 하겠습니다.

이날 2건의 행사가 있습니다.
첫째, The Clouds 2008 행사 때 한국마이크로소프트에서는 NTO(National Technology Officer) 김명호 상무님이 "마이크로소프트와 클라우드컴퓨팅" 이라는 주제로 발표를 하십니다.

둘째, 마이크로소프트의 마케팅 매니저가 주관하는 Technet Secret Series가 또 있습니다.
일시: 2008년 12월 10일 1:30분 ~ 5:30분, 장소: 한국마이크로소프트 5층 세미나실
1:30분 부터 제가 "IT 트렌드 특강, 클라우드 컴퓨팅"으로 강의를 1시간 동안 진행합니다.

두 곳 중 한군데 와주세요. 감사합니다.
Posted by 조이트리
아키텍트2008. 8. 22. 14:05

현재의 IT 주요 트렌드가 무엇일까요? SOA(Service Oriented Architecture), Web2.0, SaaS(Software as a Service), RIA(Rich Internet Application), 그리고 클라우드 컴퓨팅 (Cloud Computing) 이라고 생각합니다.

한마디로 간단히 정의하면
SOA는 "Reuse & Agility, 재사용과 민첩합"을 목적으로 나온 개념입니다.
Web2.0은 "Network Effect, 네트웍 효과, 소셜 네트웍" 으로 설명할 수 있을 것 같구요,
SaaS는 "Flexbile Pricing & Delivery, 유연한 가격 정책과 서비스의 새로운 Delivery 방식" 이구요,
RIA는 "Experience, 사용자 경험"이 주요 개념입니다.
그렇다면, Cloud Computing은 "Service Utility, 즉 유틸리티, 수도 및 전기와 같은 컴퓨팅"이라고 설명할 수 있을 것입니다.

위와 같은 다른 용어로 시장에서는 설명을 하고 나름대로의 정의를 내리기는 하지만, 사실 SOA, SaaS, Web2.0, RIA, Cloud Computing은 어떻게 보면 다르지 않습니다. 모두 현재까지 나와있는 표준들, 다양한 기술들을 이용하여 조금씩 다른 방식으로 사용하고 있다라고 이야기할 수 있습니다.

마이크로소프트는 이러한 5가지 개념을 소프트웨어 플러스 서비스 라고 하는 Umbrella로 설명하고 있습니다. 어떤 개념을 사용하더라도 결국에는 소프트웨어, 서비스가 공존하는 환경이 펼쳐진다는 것이죠.


사용자 삽입 이미지


모든 기업은 두가지를 고려하게 됩니다. 데이터 및 어플리케이션을 통제하는데 우선순위를 둘 것인지, 아니면 규모의 경제에 우선순위를 둘 것인지를 결정해야 하는 거죠. 이러한 기준에 맞추어 시장에는 현재 4가지의 IT 모델이 존재합니다.
첫째, On-Premise. 하드웨어, 소프트웨어를 모두 관리 및 소유 하는 개념

둘째, Hosting. 호스팅 업체 및 IDC를 통해 내가 개발한 어플리케이션 및 패키지를 내가 지정한 하드웨어에서 구동하고 비용을 지불하는 방식

셋째, SaaS. 다른 누군가가 개발해 놓은 어플리케이션을 사용하고, 나는 하드웨어, 소프트웨어 등의 운영등은 전혀 고민하지 않는 방식. CRM 등의 솔루션이 요즘 많이 이용되고 있죠

넷째, 클라우드컴퓨팅. 어플리케이션이 클라우드 플랫폼에서 구동되는 것, 즉 내가 어플리케이션을 개발할 때 필요한 스토리지, 컴퓨팅 자원을 클라우드 플랫폼 제공자의 것을 사용하는 데, 접속량이 아무리 많아져도 문제없이 서비스 가용성을 보장하는 서비스 방식. (즉, Scalability, 확장성이 보장되는 것이죠) 1,2주 정도 올림픽 프로모션 사이트를 구축하려고 할 때, 대박이 나면 몇 명 정도가 접속할 지 알기 어렵죠. 1만명, 10만명, 100만명에 맞추어 서버 인프라를 구축해야 할지, 아니면 1,000명 수준으로 구축할 지 정말 판단하기 어렵고, 또 2주만 사용하는 사이트 인프라에 많은 비용을 쓰기 어렵겠죠. 한 번 쓰고 나중에 6개월 후에나 다시 쓸지 모르는데 큰 투자가 가능하겠어요? 이럴때 클라우드 컴퓨팅이 아주 적절한 개념이 되겠죠.

즉, On-Premise, Hosting, SaaS, 클라우드 컴퓨팅은 다른 것을 대체하는 개념이 아닌 서로 보완하는 개념으로 IT의 진보와 발맞추어 함께 갈 것이 분명합니다.
그렇다면, 내가 지금은 클라우드컴퓨팅 방식으로 개발해서 비용을 지불했는데, 정책이나 상황이 변해서 On-Premise 방식 또는 Hosting 방식, SaaS 방식으로 바꾸려고 할 때 어느정도 유연하게 바꿀 수 있느냐가 중요한 의사결정 포인트가 될 것인데요, 이와 같은 유연함을 제공할 수 있는 플랫폼을 고민하는 것이 필요한 시점입니다.
Posted by 조이트리