디지털 Transformation, 데이터센터 & Cloud, 베트남

오늘 중요 고객을 모시고 마이크로소프트의 가상화 전략에 대한 세미나를 진행했습니다.
그 내용을 공유합니다.

하드웨어, 운영체제, 어플리케이션, 프리젠테이션의 Tight한 연결을 끊어주는 기술

. 종이를 붙일 때 강력접착제, 풀을 사용하면 떼면 찢어지고 원형을 알아볼 수 없게되죠

. 하지만, 3M의 포스트잇의 경우는 뗐다 붙였다가 자유롭지요

데스크탑, 노트북 컴퓨터의 예를 들어보죠.

운영체제, 어플리케이션, 사용자 데이터 및 셋팅 값이 한대의 하드웨어에 강하게 밀착되어 있었기에 업그레이드가 필요할 때 새로운 PC로 이전하거나

분실했을 때 데이터를 복구하는 것이 굉장히 어려웠죠. 전통적인 OS/어플리케이션의 인스톨 방식과 데이터 저장장치 기술의 한계 때문입니다.

데스크탑 배포 관점에서 운영체제, 어플리케이션의 실행/ 프리젠테이션, 사용자 데이터 등이 모두 한 대의 장치 안에 담겨져 있는 것이죠. 이 모델은 단순함과 오프라인으로 이동중 에도 쓸 수 있다는 것이 큰 장점 입니다. 하지만, 타이트한 바인딩으로 인해 모든 시나리오에 적합할 수는 없겠죠. 이런 이유 때문에 마이크로소프트는 새로운 윈도우 배포 옵션을 제공하여 이동중에도 사용가능하고, 유연성을 확대할 수 있는 방식의 제공이 필요하게 된거죠.

컴퓨팅 계층간의 종속성을 줄임으로 써 각 시스템은 실시간으로 필요할 때 요청하면서 사용하는 방식을 제공할수 있게 된거죠. IT 부서는 각 계층을 별도로 관리할 수 있습니다.

윈도우 비스타 출시와 함께 Virtual PC, 윈도우 이미지 포맷 (하드웨어, 운영체제 분리)을 출시하였고 터미널서비스와 SoftGrid, 이제 마이크로소프트 어플리케이션 가상화로 이름이 변경됐죠. (운영체제와 어플리케이션 분리), 데이터와 폴더 리다이렉션 (운영체제, 어플리케이션으로 부터 데이터 분리)이 발표됐죠.

이런 다양한 기술들은 여러 시나리오에 유용하게 사용될 수 있습니다.

앞에 설명 드렸던 각 계층간의 분리를 통해 다양한 시나리오가 나올 수 있습니다. 프리젠테이션 가상화(SBC), 어플리케이션 가상화, 서버가상화 이 3가지를 오늘 다루어 보도록 하겠습니다. 딱 듣기에도 이렇게 쓸 수 있으면 좋을 것 같네? 라는 생각이 들지 않습니까? 네. 그렇죠.

그런데 몇 가지 이슈가 있습니다. 기존 전통적 방식와 인프라스트럭처가 어떻게 바뀔지에 대한 이해가 필요하고, 관리가 아주 중요한 이슈로 떠오릅니다. 가상화에서는 각 가상머신 각각을 하나의 데이터 파일로 보기 때문에 제대로 관리하지 못하면 아주 관리의 Hell이 될 수도 있을 겁니다. 또한, 물리적인 머신과 가상 머신, 즉 가상화된 장비와 그렇지 않은 장비가 공존하게 되고, 가상화된 장비의 경우 물리적인 머신 1대 위에 수개의 가상머신이 공존하는 상황이 오기 때문에 1개의 관리도구가 가상머신과 물리적 머신을 함께 관리해주어야 합니다. 라이선싱 측면에서도 기존 방식에 비해 TCO 측면에서 도움이 되어야 하는 것은 당연하겠죠. 또한, 다양한 운영체제가 함께 가상머신으로 구동될 수 있어야 현실적인 안으로 검토 가능하다고 할 수 있겠습니다. 하나의 플랫폼으로만 이루어진 회사는 없을테니까요. 이런 관점으로 보면 Windows 운영체제 위의 리눅스, 솔라리스를 보는 것도 놀랄 일이 아니겠죠. 리눅스 위에 윈도우, 솔루리스도 역시 가능하겠죠. 이런 식스로 메타 플랫폼 개념으로 진화하고 있다는 겁니다. 여기서는 더 깊이 들어가지는 않겠습니다.

마이크로소프트의 가상화 전략, 오늘의 핵심이죠. 비즈니스 환경에서 크게 2가지 운영체제를 접하실 겁니다. 개인의 업무 생산성을 위한 환경은 데스크탑, 회사의 업무용 시스템, ERP 및 메일시스템 등은 서버에서 구동을 하게 되죠. 그중 서버를 살펴보면 서버의 평균 가동율이 몇 % 될거라고 보십니까? 15%, 최고 20% 정도를 사용하면 정말 많이 사용하는 거죠. 삼성전자 사이버사업장의 경우 많이 사용하는 시스템들이 그 정도 사용했으니까, 사실 하드웨어 입장에서는 놀고 있는 거죠. 이 물리적인 서버에 가상화를 적용하면 20% 정도의 사용율을 보이는 논리적인 서버로 만들면 4대 정도를 구동할 수 있다, 즉 서버 통합을 할 수 있는 기술이 서버 가상화 입니다. 지금까지의 가상화는 바로 이 서버 통합이 가능한 서버 가상화를 통칭하는 개념 정도로 이해를 하고 계실겁니다. 이 서버 가상화도 두 가지로 나뉘는데 머신 가상화와 서버 가상화로 나뉩니다. 머신가상화는 HP 같은 수퍼돔 서버에 물리적으로 파티션이 나뉘어져 있고, 각 파티션에 개별 운영체제를 설치할 수 있는 개념입니다. 개별장비를 도입하는 것에 비해 효율적인 것은 사실이지만 각 파티션간의 이동에 제약이 많았습니다. 반쪽짜리 가상화 정도로 이해를 하면 좋을 것 같습니다. 그런데 서버가상화에서 사용하는 가상화는 하이퍼바이저라고 하는 하드웨어와 운영체제 사이의 아주 가벼운 가상화 소프트웨어가 그 역할을 감당하는 것으로 보면 됩니다.

데스크탑 가상화는 Virtual PC로 서버 가상화와 유사한 방식입니다. 이런거죠. 제가 윈도우 비스타를 사용하고 있는데 윈도우 XP에서만 구동되는 어플리케이션이 있다고 가정해보죠. 한대의 PC를 더 사야 할까요? Virtual PC 소프트웨어를 설치한 후 Windows XP를 제 비스타 위에 구동할 수 있게 해주는 거죠. (Demo: Virtual PC) 개발자의 경우에 다양한 버전의 운영체제를 한대의 PC에 설치해 놓고 환경에 맞게 테스트할 수 있기에 개발 및 테스트 목적으로 많이 사용합니다.

이와 유사하게 Windows Vista Enterprise Centralized Desktop(VECD)가 있는데, 이런거죠. 제 비스타의 이미지가 로컬에 설치되지 않고, 중앙의 관리서버에 설치되는 겁니다. 모든 설정 및 어플리케이션이 중앙의 서버에 설치되므로 향후에 분실했을 경우에 중요한 데이터의 망실 등의 위험을 방지할 수 있는 거죠.

어플리케이션 가상화는 재미있는 개념입니다. 프리젠테이션 가상화, 일명 SBC의 경우는 모든 어플리케이션이 모두 서버에 설치되고 구동되며 클라이언트, 즉 PC는 키보드입력, 마우스 포인트 등에 대한 화면 정보만 사용하는, 즉 아주 사양이 낮은 PC에서도 사용이 가능하고 분실했을 때나 정보 유출에 대한 우려를 없애는 목적으로 사용되죠. 그런데 단점은 사용자는 자기가 장비를 소유하고 있고, 각자의 커스토마이징을 소유하기를 원하는데 프리젠테이션 가상화는 이런 부분이 불가능하고 데이터나 화면이 복잡한 경우 속도가 느린 불편함이 있었습니다. 어플리케이션 가상화는 이런 단점을 보완하여 사용자가 어플리케이션을 요청 시 처음 스트리밍 방식으로 어플리케이션을 서버에서 클라이언트로 가져옵니다. 그리고, 로컬 CPU 및 메모리의 파워를 이용하여 어플리케이션을 구동하는 거죠. 사용이 종료되면 기본적인 내용만 캐시에 남기고 모든 데이터를 삭제하여 데이터의 보안성을 보장합니다. 또한, 로컬에 레지스트리나 DLL을 설치하지 않기 때문에 버전간의 호환성 충돌 등의 위험이 전혀 없습니다. 오피스 2003을 사용중인 회사가 오피스 2007을 함께 사용해야 할 필요가 있을 때 지금은 DLL등의 충돌로 인해 함께 사용할 수 없지만, 어플리케이션 가상화를 이용하면 2003은 인스톨 방식으로 사용하고 2007은 어플리케이션 가상화를 이용하여 함께 사용할 수 있게 됩니다. 또한, 오피스의 배포 방식을 지금과 같은 설치 방식 외에도 프리젠테이션 가상화를 통한 사용자 방식, 어플리케이션 가상화를 이용한 방식 등 다양하게 제공하여 새로운 비즈니스 모델을 만들어 낼 수도 있는거죠.

자, 그럼 서버 가상화에 대해 조금 더 자세히 살펴보도록 하겠습니다. 데이터센터의 관심사항이 뭘까요?

서버가 폭주하고 있습니다. 시스템이 점점 복잡해지면서 복잡한 어플리케이션이나 솔루션은 별도의 장비에서 구동하게 되었습니다. 결국 서버의 수가 엄청나게 증가하게 되는 거고

쿨링, 전원, 상면, 관리가 큰 이슈로 등장하게 되는 겁니다. 제가 KIDC, 하나로IDC, KT-IDC 등과 일을 많이 하는데 데이터센터에 상면, 공간이 없습니다. 주차장도 다 없애고 확장하고 있지요. 마찬가지로 적절한 서버 업타임과 시스템 가용성을 보장하는 것은 사용자의 생산성을 높여주지만, 결국 복잡도, 비용, 관리의 오버헤드가 높아지게됩니다. 서버와 최종 사용자의 데스크탑에 운영체제 및 어플리케이션을 설치하고, 이미지 및 패치를 처리하고 사용자 설정을 하는 것은 아주 큰 챌린지 입니다.

오류의 발생이 훨씬 더 크리티컬 하기 때문에 포괄적인 개발 및 테스트 환경이 점점 더 중요해지고, 보안 패치 및 품질관리, 새로운 운영체제 위에서 다양한 어플리케이션 및 솔루션의 호환성 및 버전 체크가 중요한 이슈로 등장하게 되었습니다.

이런 모든 Concerns 들은 IT뿐 아니라 IT 매니저, 비즈니스 Decision Maker에게도 큰 골치거리가 아닐 수 없죠. 결과적으로 IT 부서는 전략적인 이점을 제공하는 부서로 거듭나기를 원하는데 이러한 이슈들을 처리하는데도 엄청난 리소스를 쏟고 있기에 전략적인 도움, 비즈니스가 Agile하게 움직이는데 도움을 주기 어려운 것입니다. 결국 IT 부서가 비용을 절감하고, Agility를 향상 시키지 못하는 한 모든 문제는 IT 부서에게 큰 Concern으로 남아있을 것이 분명하죠.

예를들면 이런 겁니다. 제가 호스팅 비즈니스 할 때 삼성전자가 품의하고 결재 받는데 3개월이 걸립니다. 근데, 서버는 1주일 안에 가져와서 서비스하게 해달라는 거죠. 돕니다. 서버 발주하고 입고에 최대 4주 정도 소요되는데, 1주 안에 어떻게 다 설치하고 서비스를 하도록 합니까? 근데 못한다고 할 수 있나요? 여러 가지 변칙을 쓰게 되는 거죠. 만약 요구를 못들어 주면 너가 하는게 뭐냐? 뭐 이런 이야기를 듣게 되죠. Agility가 생명 이니까요. 근데 1주일이 아니라 10분 안에 서비스 하도록 해드릴게요? 한다면 엄청 Dynamic 해지는 거죠.

가상화는 이런 일을 가능하게 해줍니다.

마이크로소프트의 ITSM(IT Service Management)는 인프라스트럭처 최적화 모델로 설명할 수 있습니다. Dynamic IT 모델을 최종 지향점으로 보고 있는데요.

목적은 비용절감, 서비스레벨 향상, Agility 최적화 입니다.

Basic 단계에서는 IT 부서가 Cost Center로서의 역할을 수행합니다. 모든 서버 운영체제 설치, 계정 설정, 디스크할당 등의 작업이 매뉴얼로 이루어지고, 요청이 이루어질때마다 서버가 1대씩 늘어나죠. 서버에 대한 표준 같은 것도 정해지지 않은 상태입니다.

여기에 개발 및 테스트 환경이 구축되고, 서버 통합이 이루어지고, 어플리케이션에 대한 호환성 등이 보장되는 단계가 Standardized 단계 입니다. 엔터프라이즈에서의 가상화는 자연스럽게 성숙도 커브를 따라야 합니다. 각 회사마다 차이가 있기에 조금씩 적용되는 범위는 다르지만 기본적인 가이드라인을 제공할 수 있죠. 백업 및 복구, 통합 관리가 제공되면 Rationalized 단계이고, 마지막은 Dynamic 단계로 아주 Flexible하게 프로비저닝이 가능한 단계를 의미합니다. 가상화가 Dynamic IT에는 필수라고 할 수 있죠. 데모를 통해 보여드리도록 하겠습니다.

서버 가상화의 아키텍처, 간단히 보고 넘어가겠습니다. 아까 말씀드린 Virtual PC, 마이크로소프트의 Windows Server 2008 출시 이전까지 서버 가상화에 사용되던 Virtual Server는 Type-2 가상화 구조를 가지고 있습니다. 하드웨어 위에 운영체제가 깔리고, 그 운영체제 위에 Virtual PC 같은 가상화 소프트웨어를 통해 운영체제를 또 설치하는 방식 이었습니다.

그런데 Windows Server 2008의 가상화, Hyper-V에서는 하드웨어 위에 Hyper-V라는 가상화 소프트웨어가 올라가고 그 위에 가상머신(VM)이 바로 올라가는 구조를 취하고 있습니다. 즉 Type2에 비해 절차가 단순해졌죠. 조금 더 구체적으로 살펴보면 하드웨어 위에 커널모드와 사용자 모드로 나뉘어지는데 커널모드에 호스트 운영체제가 설치되고 , 게스트 가상머신들은 사용자모드로 설치가 되는 겁니다. 이 가상머신이 하드웨어, 즉 CPU, 메모리를 사용하려면 호스트 OS를 거쳐서 사용하여야 하므로 성능이 저하되는 단점이 있었습니다. 일반적인 물리적인 서버에 비해, 가상머신의 성능이 70% 정도 나오는 것으로 알려져 있습니다.

가상화를 사용하면서 원래 물리적인 서버보다 더 좋은 성능을 내게 해달라? 가능할까요? 불가능하죠… 말이 안되죠.

하지만 최대한의 성능을 내야 채택할 수 있는 건 당연하겠죠. 그런데, Windows Server 2008의 Hyper-V의 경우는 가상머신이 하드웨어, 즉 CPU나 메모리를 사용할 때 커널모드를 통해 바로 접근하도록 설계가 되어 있습니다. 훨씬 효율적으로 사용하게 된거죠. 일반적으로 가상머신의 성능이 이론적으로 97% 정도 나오는 것으로 되어 있는데, 실제로는 90% 정도의 성능을 보이는 것으로 측정되었습니다. 현재 CPU의 경우 인텔 VT, AMD-V라는 특정 칩셋에 Hypervisor를 지원하도록 만들어져 있고, 이 칩셋의 경우 가상화 지원이 최적화 되어 있지만 메모리, 디스크의 경우는 아직 최적화 되어 있지 않았기 때문에 90% 정도가 나오는 것이고, 향후에는 97% 정도의 성능을 보일 것으로 보여집니다.

Hyper-V의 핵심 기능, 특히 호스트OS는 64비트 (x64) 하드웨어만 가능하고, AMD-V, Intel VT CPU를 사용해야 합니다.

가상머신 운영체제로는 x32비트, x64비트 모두 사용 가능합니다. 또한 가상머신의 메모리는 32기가 까지 지원 가능하며, CPU도 4개까지 사용 가능합니다.

서버 가상화의 시나리오는 크게 4가지 정도로 나누어 볼 수 있습니다.

서버통합: 100대의 서버를 10대 또는 20대로 줄일 수 있고, 결과적으로 전원 및 상면 비용을 따지면 엄청난 절감 효과가 있는 것이죠. 서버 1대당 전원을 1년에 15만원 정도 사용한다고 보면 1,500만원의 전기세가 150만원 또는 300만원으로 절감 되는 겁니다. 상면까지 치면 엄청 절약되겠죠?

DR: 재해 및 복구 시나리오 입니다. 스냅샷 기능을 통해 장애가 일어나기 전 상태로 바로 돌릴 수 있는 기능이 포함되어 있습니다.

고객들이 자주 하는 요청 중의 하나가 개발서버를 구해달라는 것입니다. 처음에는 2주만 쓰겠다고 하지만 한 번 빌려주면 1년 이상 그냥 쓰죠. 뺏을 수도 없고 말이죠. 또한 확보하는데 걸리는 시간이 몇 개월이 걸리기도 하죠. 이럴 때 가상 머신을 할당해주는 개념을 제안하는 거죠. 개발 및 테스트 환경 구축 프로젝트를 통해 고객이 원할 때 할당해주고, 필요 없어지면 바로 회수하는 형태가 가능해집니다.

Dynamic Data Center는 고객이 원할 때 바로 사용하고, 문제가 발생하면 바로 신속히 원래의 상태로 복구하고, 이런 Agile과 비즈니스 연속성을 보장하는 환경이 가능해진다는 것입니다. 괜찮지 않습니까?

서버 통합에 대해 조금 더 자세히 살펴보면 다음과 같습니다.물리적인 인프라, 즉 WS2003, 2008 서버가 8대 있습니다. 가상머신 호스트로 3대가 준비되었습니다. 관리를 위해서는 관리도구가 필요하다고 말씀 드렸죠. 가상머신 매니저라는 솔루션이 존재합니다. 가상머신 매니저의 에이전트가 가상머신 호스트에 배포됩니다. 성능 데이터가 통합할 후보를 결정하기 위해 취합됩니다. 가상머신 매니저가 그 정보를 가지고 있죠. CPU 사용율 정보가 보이는 것을 확인하실 수 있습니다. 어떤 서버를 통합할 것인지에 대한 우선순위 리포트가 나옵니다. 호스트의 성능 정보 역시 가상머신 매니저에게 보내집니다. 물리적인 서버가 가상 머신으로 전환됩니다. Intelligent 배치가 이루어집니다. 물리적 머신은 용도 폐기 되거나 다시 재활용 합니다. 91%의 사용율을 나타내는 서버는 그대로 유지합니다.

시나리오2는 관리자 프로비저닝 입니다. 앞에서 언급한 시나리오, 고객이 서비스 환경을 위해 서버 1대 셋업을 내일까지 해달라고 합니다.가상머신 템플릿에 라이브러리가 존재하고 있죠. 새로운 가상 머신을 위한 템플릿이 미리 설정되어 있습니다. 템플릿에서 설정이 조정됩니다. 이미 설정된 템플릿으로 부터 VM이 만들어집니다. 성능 데이터가 수집 됩니다 .새로 설정될 가상머신이 가장 적당한 호스트에 배치됩니다.

시나리오3은 프로비저닝 위임 입니다. 가상머신 매니저는 웹으로도 접근 가능합니다. 위임 받은 사용자가 새로운 가상 머신을 생성합니다. 즉, 고객이 직접 서버 셋업을 할 수 있다는 의미 입니다. 이미 설정된 템플릿으로 부터 가상 머신이 만들어집니다. 가상 머신이 최적의 호스트에 배치됩니다.

시나리오4는 엔터프라이즈 토폴로지 입니다. 가상머신 매니저가 중심에 서게 되죠. 다양한 관리 도구가 존재합니다. 쉘 방식에 익숙한 사용자는 파워쉘을 사용하실 수 있고, 콘솔을 원하는시는 분은 콘솔, 웹 기반으로 작업해야 하는 상황에서는 웹을 통하여 고객에게 다양한 시나리오를 제공하는 것이죠. 다양한 지역, 런던, 싱가폴 등의 지역에 위치한 서버들도 가상머신 매니저를 통해 관리가 가능한, 즉 엔터프라이즈에서 사용 가능한 환경을 제공 가능합니다. Microsoft is ready !!!

가상화를 위해 고려해야 할 몇 가지 주요한 관심사항에 대해 짚고 넘어가겠습니다. 라이선싱은 유연한 정책을 제공합니다. WS2008 Standard Edition의 경우는 1개의 가상머신까지는 추가비용 없이 설치할 수 있습니다. Enterprise Edition의 경우 4개의 가상머신까지 추가비용 없이 설치 가능합니다. Data Center Edition의 경우 가상머신의 개수와 상관없이 설치 가능한 정책을 제공하고 있습니다. 인프라 측면으로는 Hyper-V, Virtual Server 2005 R2를 제공하는데, Agility를 보장하고, 서버 자원의 효율적인 활용, 또한 인텔 & AMD와의 파트너십을 통해 Value를 제공하고 있지요. 가상화에서 가장 중요한 내용이 바로 관리입니다. 마이크로소프트 가상 머신 매니저는 가상 인프라와 물리적인 인프라의 통합 관리가 가능하고, 자원의 관리를 효율적으로 하도록 도와주고 IT 비용 절감에 도움이 되는 도구 입니다. 또한, 상호운영성 측면에서는 이기종 운영체제를 지원하고, 가상머신의 디스크포맷 VHD는 표준이며, 또한 Third Party 어플리케이션의 호환성 보장을 위해 Validation Program을 진행하고 있습니다. 또한, VMWare Hyper-visor 및 Xen Hyper-Visor와 모두 호환 가능하며, 심지어 VMWare 상의 가상머신을 바로 그대로 가져와서 구동할 수 있습니다. 또한 System Center Operation Manager는 오라클, MySQL, 리눅스 등에 대해서도 모니터링이 가능합니다. 어플리케이션에서는 배포를 빠르게 확산할 수 있고, 어플리케이션 지원 비용을 절감할 수 있으며 어플리케이션을 다이내믹하고 실시간으로 서비스할 수 있는 개념을 가지고 있습니다.

Dynamic IT에 대한 몇가지 데모를 살펴보도록 하겠습니다.

Demo 1: New Virtual Machine, WS2008 서버 신규 생성

Demo 2: Snapshot (Checkpoint)

Demo 3: Quick Migration

다음으로 프리젠테이션 가상화에 대해 알아보도록 하겠습니다. 마이크로소프트 고객분들이 가장 많이 사용하는 기술인데, Remote Desktop, 터미널서비스가 바로 프리젠테이션 가상화의 예제 입니다. 그런데 고객분들은 가상화가 화두가 되고, 이야기는 많이 하시지만 이건 가상화라고 잘 생각하지 못하시죠. 하지만, 프리젠테이션 가상화는 최종 사용자 및 IT 관리자가 현재 존재하는 시스템과 사용하는 방식을 어떻게 재 정의할 것인지 고려할 때 아주 좋은 예가 됩니다. 가상화가 없다면 사용자는 로그인하기 위해 물리적으로 그 장비 앞에 가야 하죠. 하지만 프리젠테이션 가상화 덕분에 제가 지금 데모를 보여드리고 있는 거죠. 서버를 제가 들고 다닐 수는 없지 않겠습니까?

프리젠테이션 가상화, 모든 작업이 서버에서 이루어 지는 거죠. Sjb-hyperv-01 서버에 접속합니다. WS2008 CLI2에서 https://koalra-dc/ts 를 입력합니다.

워드 인증에 ID: kyongrs, P@ssw0rd 입력

WS2008-DC 장비에 가서 서비스를 살펴보면 워드 프로세스가 구동중임을 확인시켜 줄 것 !!! 모든 저장도 서버에 이루어짐

마지막으로 어플리케이션 가상화 입니다.

비행기를 타려는데 보안을 이유로 랩탑을 가지고 갈 수가 없습니다. 이런 일은 이미 여러 나라에서 일어나고 있죠. 영국에서 2주 동안 테러 위협을 이유로 랩탑을 가지고 항공기를 타는 것이 금지되었죠. 이럴때 비즈니스 출장을 가야한다면 어떻게 하시겠습니까? 아침에 자고 일어났더니 사무실이 물에 잠겨서 노트북, 데스크탑을 모두 못쓰게 됐습니다. 이럴때 그 안에 담겨진 소중한 정보는 어떻게 하실거죠? 회사 전체 또는 부서가 다른 지역으로 이전을 하게 됐습니다. 고객 대응에 영향을 미치지 않으면서 부드럽게 이전하실 수 있나요? 스탭, 계약직원을 고용하거나 아르바이트를 쓸 경우에 네트웍 상의 관리되지 않는 PC를 어떻게 처리할 건가요? 이런 경우 원래보다 훨씬 더 많은 주의를 기울여야 하므로 관리 측면에서 큰 부담으로 작용하게 되죠. 이럴때 어떤 방법으로 위험을 최소화 할까요? 아주 극단적인 몇 가지 예제 이지만 충분히 닥칠 수 있다고 생각합니다. 삼성에서야 PC Man같은 관리용 프로그램을 모두 설치하고 모니터링을 하기에 어느 정도 관리는 되긴 하지만, 해당 어플리케이션이 문제를 일으키면 IT 데스크에서는 엄청난 작업을 해야하죠.

다양한 업무 환경을 살펴볼까요?

모바일 근로자: 출장과 외근이 잦은 경우 네트웍과 연결되지 않은 상태에서 업무를 수행할 일이 많죠. 오피스(메일), CRM 등을 많이 사용할거고 상대적으로 PC의 성능이 좋아야 합니다. 영업사원의 경우가 대표적이죠.

오피스 근로자: 대부분의 시간을 회사 네트웍과 연결된 상태에서 일을 하게 되고, 높은 사양의 PC가 필요 합니다. 주로 오피스, CRM, ERP 등의 LOB(Line Of Business) 어플리케이션과 웹, 프로젝트 관리 툴 등을 주로 사용하게 되죠. 안정적인 네트웍에서 대용량의 LOB 작업을 수행하기도 하기에 컴퓨팅 파워도 많이 사용하는 경우가 많습니다.

태스크 근로자: 데이터 입력 등의 일을 주로 수행하는 근로자를 의미하는데, 주로 1~2개의 LOB 어플리케이션을 사용하고 회사 네트웍에 항상 연결되어 사용하게 됩니다. 자리가 고정되지 않고 이동하면서 일할 수 있는 환경인 경우가 많죠. 콜센터, 뱅크텔러, 공장 근로자 및 소매점의 POS 캐시어의 경우가 해당됩니다.

계약 및 해외 근로자: 계약직 근로자 및 파트타이머를 고용할 때 PC를 지급하고, 회사의 어플리케이션과 데이터에 접속 권한을 주는 경우가 많죠. 즉, 관리되지 않는 이 PC를 어떻게 관리할 것인지에 대한 부분이 관심사항이 됩니다.

어디서나 Access: 때때로 회사의 네트웍에 긴급할 때 집에서, 또는 PC 방에서 접속해야 할 필요가 있습니다.

전통적으로 고객들이 이러한 시나리오에 대해 보안을 유지하고 비용은 많이 들지 않도록 적합한 어플리케이션과 데이터에 접근하도록 하는 것은 쉽지 않았죠. 그렇지 않나요?

Mobility는 대부분의 조직에서는 필수로 요구되는 항목입니다. 지식근로자는 어디서나, 언제나 데이터 및 어플리케이션에 접근할 필요가 있죠. 이런 이유 때문에 전세계적으로 Laptop을 사용하는 비율이 훨씬 많아지고 있는거죠. 사용자는 기본적으로 데이터를 가지고 다니기를 원하고, IT 부서는 해당 데이터가 잘 보호되기를 원하며 Laptop을 분실, 도난당했을 때 사용자의 업무 생산성에 영향이 최소화 되기를 원합니다. 사용자와 IT는 사용자가 사용하고 있는 어플리케이션, 훨씬 더 중요한 데이터를 다운타임을 최소화하면서 백업이 유지되고 '바로 교체 가능한 PC' 환경을 원하고 있는 거죠. 마이크로소프트는 모바일 사용자를 위해 'Replaceable PC' 솔루션을 제안합니다. Windows Vista Enterprise Edition의 Bitlocker Drive encryption이 바로 데이터를 보호하는 기능을 하지고 있고, 마이크로소프트의 어플리케이션 가상화 (SoftGrid)가 어플리케이션을 설치하지 않고 네트웍에 연결되어 있든, 되어 있지 않든 관계없이 어플리케이션을 사용자에게 전송해주는 역할을 하게 되며, 오프라인 폴더에 Folder Redirection 기능을 통해 중앙에서 관리되는 데이터 저장소의 데이터를 역시 네트웍에 연결되어 있든, 있지 않든 관계없이 사용할 수 있게 해줍니다. 만약 사용자 랩탑에 Bitlocker Drive Encryption이 설치되어 있는 상태에서 분실, 또는 도난 당하면 해당 데이터는 인증되지 않은 사용자의 접근을 제한합니다. Folder Redirection 기능을 통해 중앙 저장소에 저장된 데이터를 사용자는 접근하여 사용할 수 있게 되는 거죠. 사용자가 새로운 PC를 받게 되면 네트웍 상의 데이터가 자동으로 하드디스크에 싱크되면서 억세스 가능하게 되는 겁니다. 마이크로소프트의 어플리케이션 가상화는 자동으로 사용자에게 할당된 어플리케이션 셋팅을 로컬 PC에 어떤 셋팅 작업 없이 그대로 사용 가능하게 됩니다. 이 시나리오의 확장으로 IT 부서는 모바일 사용자에게 아주 중요한 어플리케이션의 경우는 터미널 서비스를 통해 중앙에서 구동하게 하고, 사용자는 화면을 통해서 조작을 하고, 모든 작업 및 데이터는 서버에서 이루어지도록 할 수도 있는 거죠. Windows Vista, MDOP,

Windows Server 2008이 함께 사용되면 Replaceable PC를 적용할 수 있습니다.

어플리케이션 가상화에 대해 조금 더 자세히 알아보겠습니다. 어플리케이션 가상화는 어플리케이션의 라이프사이클에 변화를 일으킵니다. 기존 방식으로는 오피스를 사용하려면 반드시 로컬에 설치를 해야만 했죠. 하지만, 어플리케이션 가상화를 이용하면 라이선스가 있는 어느 장비에서든 로컬 장비에 설치하지 않고 사용할 수 있게 되는 거죠. 새로운 패치나 새로운 버전은 사용자가 데스크탑 아이콘을 클릭하는 순간 제공되고, 사용자가 세션을 종료하면 코드, 셋팅, 프로파일 값은 PC의 가상화된 SandBox에 저장됩니다. 따라서, 사용자가 오프라인 상태일지라도 해당 어플리케이션을 사용할 수 있게 되는 거죠.

장점은 여러가지가 있지만,

사용자에게 신규 노트북을 지급할 때 준비 시간을 단축시켜주고, IT부서가 해당 장비에 대한 컨트롤을 할 수 있도록 해주죠

어플리케이션을 스트리밍 서버를 통해 독립시켜주기 때문에 어플리케이션 충돌을 최소화 하고

어플리케이션 호환성 테스트를 획기적으로 줄여주고, 운영체제의 종류에 상관없이 사용 가능하도록 해주고

스트리밍되는 어플리케이션의 사용 리포트를 실시간으로 볼 수 있도록 해주며

노트북에 문제가 있을 때 다른 장비로 대체하는 것을 쉽게 해주죠

어플리케이션 가상화는 2가지 형태로 사용될 수 있습니다. 첫째, 해당 어플리케이션을 서버에서 스트리밍 받아서 로컬에서 구동하는 방식과 둘째, 해당 어플리케이션을 터미널서버에서 구동하면서, 그 화면을 프리젠테이션 가상화로 받아서 처리하는 방식이죠.

정리해보면 다음과 같은 기능을 제공하는 거죠.

어플리케이션 가상화: PC나 터미널서버의 자원을 이용하여 어플리케이션을 구동하고 어플리케이션을 운영체제에 설치하지 않음

멀티플 배포 옵션: 다이나믹 스트리밍을 포함하여 여러 가지 방식 중 선택이 가능함 (로컬에서 구동, 터미널서버에서 구동 등)

Standalong Mode: 네트웍에 주로 연결되지 않는 고객은 별도의 스탠드어론 방식으로 사용하도록 지원함

Demo: 어플리케이션 가상화

비즈니스 모델로는 Dynamic IT라는 Theme으로 내부 인프라 개선, 고객 인프라 개선, 개발 및 테스트 환경 구축 제안이 가능하고 어플리케이션 서비스 제공자로서의 역할이 가능할 것 같습니다. 소프트웨어와 서비스가 공존하는 소프트웨어 플러스 서비스 세상에서 서비스의 중요성은 점점 증대되고 있습니다. 오피스를 현재와 같은 방식으로 라이선스를 판매하지만, 프리젠테이션 가상화를 이용한 오피스 Delivery, 어플리케이션 가상화를 이용한 Delivery가 가능할 것이고 고객의 니즈에 맞는 형태로 제안이 가능하다는 거죠.

가상화에 대해 장점만 설명드렸는데 몇가지 고려해야할 사항을 말씀드리겠습니다.

첫째, 가상화는 혁명입니다. 인식의 전환이 수반되어야 한다는 거죠. 충분한 이해를 통한 적용이 필요합니다.

둘째, 만병통치약은 아니라는 겁니다. 마술이 아니고, 복잡한 문제를 풀 수 있는 도구로 이해해야 합니다. 철저한 계획과 관리에 대한 이해가 선행되어야 합니다.

셋째, 가상화는 관리가 가장 중요한 항목 입니다. 또한 모든 물리적인 서버가 가상화 될 수 있는 건 아닙니다. 물리적인 서버와 가상화가 함께 공존하므로 물리적인 서버와 함께

관리가 가능해야 합니다.

가상화는 메타 플랫폼의 등장을 가능하게 합니다. 윈도우 위에 리눅스, 솔라리스가 구동될 수 있게 되는 거죠. 이를 위해 XenSource, Novell등과의 협약으로 다양한 기술 공유가 이루어졌고, 현재도 진행중입니다. 여러 파트너와 생태계를 이루어가고 있습니다.

마지막으로 마이크로소프는 데이터센터부터 데스크탑에 이르기까지 포괄적인 가상화를 제공하고 있습니다.

하나의 관리 플랫폼으로 물리적인 서버, 가상 머신을 함께 관리할 수 있습니다.

비용 절감, 가용성 향상 및 신속성을 제공 받으면서 여러 가지 직면하고 있는 어려움을 해결 가능 합니다.

감사합니다.

서비스 배포(Service Delivery)는 네트워킹, 보안, 모니터링, 운영체제, 비즈니스 프로세스 및 시스템 자동화 등의 기술적인 영역을 지식 및 베스트 프랙티스와 결합하는 광범위한 작업 입니다. 딱 보기에도 만만치 않은 작업 같이 보이시죠? 통신 업체는 이미 서비스 배포에 대한 다양햔 경험을 가지고 있고, 이 산업의 특징은 다음의 약어로 설명 될 것 같습니다. FCAPS(Fault, Configuration, Accounting, Performance, Security Management)

소프트웨어, 솔루션을 개발하는 ISV가 호스팅 운영 환경에 대한 경험이 없고, 관심이 없는 것은 당연한 일이지요. 이런 업체가 SaaS 시장으로 진입하는데 있어 가장 큰 장애요인이 바로 이 운영 입니다.
그런데 재밌는 사실은 시장 상황이 서비스 친화적으로 변하면서 이런 업체들이 자체적으로 호스팅 솔루션을 개발하곤 한다는 것이지요. 그런데 과연 이것이 그들의 서비스를 얼마나 차별화해줄까요? 개발 비용 및 시간이 상당히 많이 들 것임이 분명하지요. 이런 업체들을 위해 SaaS 호스팅, 즉 운영을 대행해줄 업체가 있다면 아주 환상적인 찰떡 궁합이 될 거라고 생각합니다.
그림1. 간단한 호스팅 플랫폼

위의 그림에서 보면 ISV가 빌링, 미터링, 로깅 등을 모두 직접 처리하고 있습니다. 그렇지만, 이런 모듈은 호스팅 업체가 전문성이 있죠. 그림2를 한 번 살펴보도록 하겠습니다. SaaS 배포 플랫폼 (SDP, SaaS Delivery Platform)을 통해 서비스 컴포넌트들이 일반화되면 가능하다는 것이죠. SDP에서 제공되는 인터페이스를 통해 어플리케이션이 인프라 서비스와 서로 의사소통을 할 수 있게 되는 것입니다. SDP가 운영체제가 제공하는 역할과 같이 일반화 되면 소프트웨어 업체들은 핵심 어플리케이션 개발에 전념할 수 있게 되고 결국 시장 진입이 한결 쉬워지는 겁니다.


그림2. SDP가 구현된 후의 아키텍처

SDP는 인프라 서비스 이외에도 소프트웨어 업체가 사용할 수 있는 관리, 모니터링, 어플리케이션 설정등의 다양한 기능이 포함될 수 있습니다. 게다가 서비스 사용 패턴, 빌링 트랜잭션 및 결제 관련된 다양한 상황등의 고차원 비즈니스 정보를 대쉬보드, 컨트롤 패널 형태로 제공할 수 도 있습니다. 소프트웨어 벤더가 마켓 전략을 수립하는데 필요한 BI(Business Intelligence)로 활용이 가능한 것이죠.

SDP는 SaaS 형태로 사업을 하려는 고객을 모두 모아서 매출 규모를 극대화 할 수 있는 새로운 모델 입니다. 왜냐면 현재 호스팅 업체의 경우 상면(공간), 전원부족 등의 제약으로 인해 무작정 서버수를 늘리는 것은 한계가 있기 때문입니다. 현재의 자원을 어떻게 최대로 활용할 필요가 있고, SDP가 바로 그 대안이 될 수 있다는 거죠. 이를 위해서는 자동화 및 SDP를 어떻게 공유할 것인지에 대해 고민할 필요가 있습니다. SDP는 여러 고객이 함께 사용해야 하기 때문에 한 번 개발해 놓으면 지속적인 매출이 여러 고객으로부터 확보되는 장점을 가지고 있습니다.

그렇다면
SaaS 호스팅 업체가 ISV 업체를 끌어들일 수 있는 서비스가 무엇일까요?
SaaS 호스팅 업체가 개발 및 제공해야 하는 기술적인 차별성은 무엇일까요?
SaaS 호스팅을 통해 소프트웨어 서비스의 디자인과 구현 방법은 어떻게 달라질까요?
소프트웨어 개발과 배포 사이의 갭을 어떻게 SaaS 호스팅 업체가 메꿔줄 수 있을까요?

ISV가 원하는 것을 최적화

시장의 어플리케이션 개발 플랫폼에 주목하여 인기 있는 운영체제 플랫폼, 어플리케이션 플랫폼, 데이터 베이스를 선택할 수 있도록 제공한다면 소프트웨어 사업자가 어플리케이션을 서비스 배포 인프라에 통합하는데 소요되는 시간을 단축시킬 수 있을 겁니다.


그림3. WCF 기반의 소프트웨어 서비스를 위해 빌링 모듈을 제공

빌링 모듈을 WCF 기반으로 제공하면 소프트웨어 개발 업체는 서비스 형태로 이용이 가능하게 된다는 거죠. 웹서비스 요청을 받아서, 빌링 인터셉터가 빌링 이벤트를 발생시키면 빌링 시스템이 요청을 받아서 미터링 데이터베이스에 값을 저장하는 형태로 이루어집니다.
또한, 소프트업체가 일반적으로 필요로 하는 솔루션을 조사한 후 호스팅 환경의 어플리케이션이 필요로 하는 모델을 설정해 놓을 수 있습니다. 이러한 모듈 (즉, WCF 빌링 인터셉터), 템플릿, 가이드 제공을 통해 어플리케이션이 호스팅 환경에서 효과적으로 동작하고, 통합될 수 있도록 아키텍처를 사전에 검토하여 만들 수 있게 되는 거지요.  그림4 참조.

그림4. 호스팅 업체가 최적화 할 수 있는 일반적인 어플리케이션 모델

예를들면 아래와 같은 구현 가이드라인이 있을 수 있겠죠
1. 웹사이트, 웹서비스, 데이터베이스 등의 조합으로 만들어진 어플리케이션
2. SQL DB와 통신하는 WCF 서비스
3. 디렉토리 서비스를 사용하는 사용자 레포지터리와 통신하는 WCF
4. 모든 .NET 프레임웍의 어셈블리들은 어플리케이션이 모두 Private으로 설정 (Global Assembly Cache에 컴포넌트를 설치하지 않아야 함)
5. 모든 설정 정보는 .NET 프레임웍의 표준 파일 (web.config)에 저장되어야 함
6. 익셉션에 대한 로깅과 처리는 마이크로소프트 엔터프라이즈 라이브러리로 실행되어야 함
7. 데이터 억세스는 엔터프라이즈 라이브러리 데이터 억세스 어플리케이션 블록으로 실행되어야 함
8. 엔터프라이즈 라이브러리에는 표준 확장자만 허용됨
9. 엔터프라이즈 라이브러리의 바이너리가 SaaS 호스팅 업체에 의해 제공됨

이런 가이드를 적용함으로 소프트웨어 업체는 커스톰 관리 모듈을 직접 개발할 가능성을 줄이게 됩니다.
반면에 호스팅 환경에 통합하는데 필요한 플랫폼 툴을 호스팅 업체가 제공하고, 높은 운영 서비스 수준을 보장 받으면서 어플리케이션을 더 싸고, 빠르게 개발할 수 있게 되는 겁니다. 물론 이러한 것이 어플리케이션의 개발이 전체적인 운영 라이프사이클을 고려하지 않고 디자인 및 개발 되어야 한다는 것은 아닙니다. 반드시 "호스팅을 염두에 두고 개발되어야 합니다". (Design for Hosting) 이후에 Design for Hosting에 대해서는 더 자세히 다루겠습니다.

비용과 운영상의 컴플라이언스
SaaS 호스팅 업체를 사용하는 것이 많은 이점이 있지만 소프트웨어 업체들이 항상 제공되는 가이드를 따라서 개발해야만 하는 것은 아니고, 때로는 호스팅 환경이 특정 어플리케이션을 위해서만 구성되어야 할 때가 있습니다. 음악 이커머스 어플리케이션이 음악 트랙의 처음 20초 정도를 먼저 들려주어야 하고, 각 트랙이 아주 빠르게 로딩 되어야 할 필요가 있다고 해보죠. 이 어플리케이션은 대단히 빠른 디스크 및 네트웍 I/O가 제공되어야 한다고 할 때 SaaS 호스팅 업체의 일반적인 환경에서 제공되기 어렵겠죠. 또한, 내부에서 개발된 메인프레임과의 통합을 위해 MQ 시리즈 네트워킹 인프라가 필요할 수도 있겠죠. 어떤 경우든 소프트웨어 업체는 특화된 장치가 설치되기를 원하면 추가 비용을 부담해야 합니다.

원하는 내용이 크면 클수록 비용이 더 비싸지겠죠. 표준 환경에 대한 비용은 호스팅 업체가 이미 알고 있죠. 따라서 표준 환경을 원하면 비용이 제일 저렴할 겁니다. 어플리케이션이 표준 이외의 환경이 필요하다면 호스팅 업체가 더 많은 비용을 쓰게되겠죠. 아래 그림의 컴플라이언스 레벨 3은 특정한 요구가 없는 경우이며 추가적인 요구가 있을 때 비용이 더 비싸지는 것을 보실 수 있습니다.

호스팅 업체의 빌링 사이클에 맞추어 빌링을 진행할 경우는 비용을 적게 내면 되겠지만, 만약 별도의 주기를 가지고 빌링을 진행해야 한다면 더 많은 비용을 지불해야 할 것입니다.

SaaS 호스팅 연속성
어플리케이션 업체가 SaaS 호스팅을 사용하는 것은 좋은 일임에 틀림없지만, 서비스를 다른 회사가 운영할 때 완전히 분명한 역할을 나누는 것은 정말 어려운 일입니다. ISV가 호스팅을 직접 할 것인지, 일부는 직접하고 SaaS 호스팅 업체를 일부 활용하는 하이브리드 형태로 할 것인지, 아니면 완전히 일임할 것인지는 다양한 요소에 의해 결정될 수 있을 겁니다. 왜냐면 추가적인 비용을 내겠다고 하더라도 SaaS 호스팅 업체가 표준 호스팅 환경 이외에는 제공하지 않겠다고 할 수 있기 때문이죠. 이런 경우는 직접 해야 하는 것이죠.

어플리케이션 플랫폼의 요구사항 이외에도 법적인 규제 및 비즈니스 컴플라이언스 요인 때문에라도 직접 호스팅 해야할 때가 있을 수 있을 겁니다. 예를들면 데이터센터의 기계간의 통신에 IPSec을 반드시 사용해야 한다거나 데이터베이스의 암호화를 위해 4096-비트 암호화 키를 사용해야 한다는 등의 규제가 있고 이런 스펙을 제공하는 호스팅 업체가 없다면 직접 할 수 밖에 없겠죠.

하지만 일반적인 경우에는 표준 방식을 사용할 수 있을 것이고, 빌링시스템, 모니터링, 프로비저닝 등의 시스템을 그대로 활용할 수 있다면 대단히 큰 연구 개발 비용을 절감할 수 있게 될 것입니다.

그림6. SaaS 호스팅 연속성

주문과 빌링의 예를 들어볼까요. ISV가 자기 채널을 통해 취득된 고객의 주문을 관리하기로 결정했지만, 결국 처리는 SaaS 호스팅 업체의 채널을 통해 주문을 처리했다고 생각해보죠. 왜 이렇게 할까요? SaaS 호스팅 업체의 비즈니스 정책은 누구를 통해 취득되었든 간에 주문처리 서비스에 의해 처리되어야 하고 매출도 공유해야 하는 것이었기 때문이죠. 대신 SaaS 호스팅 업체가 빌링시스템 사용료를 벌크 형태로 통합 처리하는 경우 비용을 절감할 수 있는 이점이 있습니다. 대부분의 호스팅 업체는 이미 정부 정책에 맞는 빌링 솔루션을 보유하고 있기 때문에 별도로 고민할 필요가 없는 겁니다.

SaaS 호스팅 알아보기
저의 전문 분야 SaaS 호스팅 입니다. ^^
SDP의 아키텍처를 조금 더 자세히 살펴보겠습니다.

그림7. SDK를 통해 SDP 호스팅 환경에서 구동될 수 있도록 설계된 어플리케이션의 아키텍처

1) SDP를 통해 SaaS 어플리케이션의 라이프사이클 기간 동안 인프라, 운영 및 비즈니스 등을 지원함
2) SDP SDK의 추상화 계층을 통해 SaaS 어플리케이션과 SDP 런타임 사이에 이미 구축된 인터페이스를 통해
    커뮤니케이션이 이루어짐
3) SDP에 어플리케이션의 운영과 비즈니스 정책 적용을 위한 상태 및 이벤트 정보를 제공하는 SaaS 어플리
    케이션을 "Design for Hosting"으로 부르고, 바로 운영이 가능한 상태를 의미함

SaaS Delivery Platform (SDP)
. SDP가 할 수 있는 일들
. 아이덴티티와 접근 관리
. 주문 및 프로비저닝
. 미터링과 빌링
. 모니터링
. 기타 SDP 서비스들

자, 그럼 첫번째로 SDP가 할 수 있는 일을 살펴보겠습니다.
SDP의 제일 큰 목적은 소프트웨어 벤더가 어플리케이션 서비스를 운영하고 관리하는데 필요한 사용자 아이덴티티, 소프트웨어 서비스의 사용과 관계된 다양한 비즈니스 활동을 지원하는 것이죠. 크게 나누어 보면 위에 언급한 아이덴티이와 접근관리  등으로 나누어 볼 수 있습니다. 아래 그림 참조


그림8. SDP가 할 수 있는 일들에 대한 High Level 아키텍처

SDP가 할 수 있는 일은 인프라에 관계된 컴포넌트 외에도 산업계 및 운영 프로세스와 연계된 아주 정제되고 특화된 플랫폼 서비스 모듈이 포함되어야 합니다. 그림에서 보듯 모든 액티비티와 프로세스는 다 연계되어 있습니다. 프로비저닝 모듈의 경우 주문 관리 모듈에 의해 시작되는 것을 보실 수 있고 겨룩에는 아이덴티티 관리, CRM, SLA 모니터링 모듈과 연계되어 다양한 셋업 및 설정 단계를 거치게 됩니다. SDP의 설계는 위와 같이 연계된 모든 작업을 고려하여 실시되어야 합니다.

또한 중요하게 고려해야 하는 아키텍처 고려 요소가 바로 멀티태넌시 입니다. 1차로, SDP의 아이덴티티 관리 모듈에서 SaaS 호스팅 업체는 SDP에 입주한 소프트웨어 업체의 아이덴티티를 관리할 수 있어야 합니다. 왜냐면, SaaS 호스팅 업체는 여러 소프트웨어 업체의 고객들을 호스팅하기 때문에 멀티태넌시의 여부에 따라 각 소프트웨어 업체들의 입주 고객들에 차별화된 아이덴티티 및 억세스 정책을 적용할 수 있기 때문입니다. 2차로, 각 소프트웨어 입주 고객들은 소프트웨어 서비스를 사용하는 고객에게 별도의 아이덴티티 및 억세스 정책을 적용할 수 있어야 합니다. 즉 멀티레벨 멀티 태넌시 컨셉을 가지고 있어야 한다는 말이지요. 그림 참조
 
그림9. 멀티레벨 멀티태넌스 데이터 모델

조금 부연설명하면 Northwind는 SaaS 호스팅 업체이고 ISV A, ISV B는 소프트웨어 서비스 제공자로 가입을 했습니다. ISV A에 2개의 고객이 서비스 신청을 했는데 Application A, Application B를 각각 신청했다고 가정해보죠. 이 경우 관리 위임이 두 단계로 가능합니다. 소프트웨어 서비스 제공자와 어플리케이션 사용고객이 비로 Northwind에 의해 호스팅되고 있지만, SaaS 소프트웨어 서비스 제공자의 어드민, 또는 사용고객의 어드민에 의해 사용자 및 어플리케이션 Function 레벨에서 관리가 가능하다는 것이죠.

아이덴티티 및 억세스 관리
멀티레벨 멀티태넌트 아이덴티티 데이터 모델을 통해 각 하위 단계의 어드민에게 아이덴티티 및 억세스 정책에 대한 설정을 위임할 수 있게 됩니다. 각 고객들은 빌링 리포트를 생성하거나 데이터베이스 백업을 시작하는 등의 작업을 특정 몇 명에게만 권한을 부여할 수 있고, 각 사용자에게 알맞은 설정 및 기능을 선택하는 등의 작업을 가능하게 해야 합니다.

아이덴티티에 있어서 꼭 가능해야 하는 기능이 싱글 사인 온 (SSO) 입니다. 몇 가지 시나리오를 생각해보죠. 첫째, SDP에 호스팅된 어플리케이션 간에 SSO이 가능하도록 하는 것입니다. SaaS 호스팅 업체가 여러 소프트웨어 업체의 서비스를 번들링 하거나 리셀링 하는 일이 빈번할텐데 이런 번들링된 어플리케이션간에 SSO을 제공하는 것이 불필요한 로그인 작업을 없애고, 사용자의 편의성을 높일 것 입니다. 모든 어플리케이션 서비스를 사용하기 위해 사용자가 매번 로그인해야 한다고 생각해보면, 그런 서비스 이용 안하겠죠.

여러개의 호스팅 환경의 어플리케이션 간에 SSO이 가능하도록 하기 위해서 SaaS 호스팅 업체는 아이덴티티 제공자 역할도 해야 할 필요가 있습니다. 아이덴티티 제공자 역할을 위해 등록하고, 관리하고, 인증을 수행하기 위한 인프라가 필요하게 되죠. 아래 부분에서는 SSO을 어떻게 구현할 것인지에 대해 조금 더 자세히 적어 보겠습니다. 호스팅 환경의 어플리케이션을 억세스 하는데 사용자 아이덴티리를 인증하고 검증하는 것은 보안 측면에서는 당연히 그렇게 해야 하는 것이죠. 우선 아이덴티티 제공자로부터 아이덴티티에 대한 확인을 거쳐야 합니다. 계정이 유효하면, 아이덴티티 제공자는 보안 토큰을 발행하여 해당 사용자가 유효하다는 것을 확인시켜 줍니다. 어플리케이션이 체크하여 가입된 사람임을 확인한 후 보안 토큰의 유효성을 체크한 다음 사용자에게 권한을 부여합니다. 이후에 다른 어플리케이션을 사용하려고 한다면 사용자를 인증하기 위해 다시 입력 받을 필요가 없죠. 아이덴티티 제공자에 의해 동일한 보안 토큰이 발행되기 때문에 다른 어플리케이션 사용에 대한 권한을 그대로 유지하고 있고 결국 SSO이 이루어지는 것이죠. 시장에서 통용되는 SSO 패턴과 동일한 방식을 사용하는 겁니다.

위에서 설명한 SSO 방식은 호스팅 서비스 제공자가 발행한 보안 토큰을 사용하는 방식을 이야기 했지만 현실적으로 어플리케이션들이 서로 다른 유형의 보안 토큰을 사용할 수 있을 겁니다. 예를들면, 어떤 어플리케이션은 사용자 아이디와 비밀번호를 사용하고, 또 다른 어플리케이션은 HTTP 쿠키를 보안 토큰으로 쓸 수도 있겠죠.

시큐리티 토큰 교환 패턴은 만약 특정 어플리케이션이 서비스 제공자의 보안 토큰을 사용하도록 수정이 불가능할 때 사용을 고려할 수 있는 아키텍처 접근 방식 입니다. 패턴의 구현은 보안 토큰 교환 프록시 컴포넌트를 필요로 하고 서비스 제공자에 의해 발행된 표준 토큰을 미리 처리하도록 설치하는 방식을 취할 수 있습니다. 토큰 인증이 이루어진 후 프록시 컴포넌트가 어플리케이션이 요구하는 방식으로 또 다른 사용자의 계정값을 매핑하여 처리할 수 있습니다. 그림 10은 ISV A와 ISV B의 어플리케이션이 보안 프록시 컴포넌트를 구현하는 예를 설명하고 있습니다.

그림10. 싱글 사인 온 (SSO) 시나리오

세번째, SSO 시나리오는 엔터프라이즈의 사용자가 지금 사용하는 계정 정보를 가지고 호스팅 어플리케이션에 로그인 하도록 하는 방식입니다. 다양한 방식으로 구현할 수 있지만, 어떤 것은 너무 확장성이 떨어지고 오류 가능성이 많기도 합니다. 디렉토리 동기화 등의 방식이 고려될 수 있긴 하지만 확장성이 떨어지고 비효율 적이라고 생각됩니다. 새로운 방식은 표준 기반의 아이덴티티 (즉, Active Directory Federation Service) 등을 통해 아이덴티티 시스템 간의 정책에 트러스트를 형성하고, 서로 느슨하게 연결되도록 하여 확장성을 보장하는 방식을 사용할 수 있습니다. 즉, SaaS 호스팅 업체와 엔터프라이즈 간에 엔터프라이즈 SSO를 위한 트러스트 관계를 맺는 것이죠. 하지만, 엔터프라이즈 고객은 이 방식을 크게 선호할 거라고 보여지지는 않습니다.

주문 및 프로비저닝 (Ordering & Provisioning)
주문과 프로비저닝은 밀접하게 연계되어 있습니다.

소프트웨어 벤더 On-board
소프트웨어 벤더와 호스팅 업체 간에는 Qualification 프로세스를 거치게 되는데 기술, 비즈니스와 연계된 꼭 알아야 하는 정보 및 추정하는 내용을 서로 공유하여 프로비저닝을 진행하는 것이 발생할 수 있는 위험요소를 사전에 최소화 할 수 있습니다.
 . 어플리케이션의 속성 및 기능
 . 어플리케이션이 구동 가능한 운영 체제와 어플리케이션 플랫폼
 . 어플리케이션 아키텍처에 대한 이해 및 보유 여부
 . 어플리케이션에서 사용하는 엔티티와 데이터 모델, 데이터베이스의 필요 사항
 . 네트워킹 관련 필요 사항
 . 방화벽 이슈를 일으킬 우려가 있는 현재 사용중인 프로토콜
 . 어플리케이션 프로토타입이 배포 되었는지? 배포 문서가 만들어 졌는지? 배포에 도움이 될 만한 문서 여부?
 . 관리와 트러블슈팅에 있어 어플리케이션의 관리 포인트
 . 고려가 필요한 법적인, 규제와 연계된 컴플라이언스 이슈가 있는지?
 . 원하는 성능 메트릭 및 어느 정도의 사용자가 사용할 것으로 추정되는지?


그림11. 소프트웨어 벤더의 On Boarding 프로세스

하나의 워크플로우 안에 어플리케이션과 플랫폼 컴포넌트를 인프라 플랫폼 프로비저닝 컴포넌트가 설치 및 설정 할 수 있도록 소프트웨어 이미지, 호스팅 인프라의 설명 및 설정 정보와 SDP의 기능 등이 모두 포함되어 있습니다. SDP의 기능 중에서 어플리케이션 및 운영 지원 (아이덴티티 관리, 모니터링) 등도 필요에 따라 포함됩니다.
바로 위의 워크플로우는 어플리케이션 배포를 위한 것이고, 또 다른 워크플로우는 소프트웨어 서비스를 실제 사용하는 사용자가 리뷰, 구독 및 접근 하는데 있어 필요한 프로덕트 카탈로그 및 주문 관리 서비스에 대해 설명합니다.

On-boarding 어플리케이션 사용자
사용자가 어플리케이션을 사용하도록 준비하는 단계는 사용자가 프로덕트 카탈로그에서 서비스를 선택하여 주문을 시작하는 순간 시작됩니다. 어플리케이션에 따라 다르긴 하지만, 구매 신청, 고객의 조직, 주소, 연락처 및 빌링 정보가 필요하게 되죠. 보다 더 복잡한 어플리케이션의 경우 주문 프로세스가 고객 혼자 힘으로 끝나지 않을 수 있습니다. 고객 영업 대표가 인계 받아서 사용자 대신 정보가 등록되는 경우도 있을 수 있겠죠.

새로운 주문이 주문 관리 어플리케이션을 통해 들어오면 새로운 주문 관리 워크플로우 인스턴스가 SDP안의 프로비저닝 액티비티를 일으키게 됩니다. 대부분의 작업들이 바로 준비되지 않는 경우가 많기 때문에 주문 관리 워크플로우는 대기 상태에 있게 되고 해당 주문에 대한 주문 추적 번호가 발급됩니다.

그림12는 주문 관리와 어플리케이션 사용자의 주문 완료 프로세스에 대해 설명합니다.

그림12. 주문관리 및 주문 완료 프로세스

주문에 대한 상세 정보가 프로비저닝 파이프라인에 보내집니다. 비즈니스 연관된 정보, 즉 고객의 조직, 빌링 정보, 서비스 개시 등에 대한 정보가 고객 및 빌링 시스템에 입력 됩니다. 또 다른 파이프라인에서는 어플리케이션 프로비저닝 요청이 큐에 입력이 됩니다. 어플리케이션 프로비저닝 시스템이 해당 요청을 받게 되면 설정하고 업데이트해야 할 어플리케이션 컴포넌트를 알아낸 다음 프로비저닝 로직에 따라 실행을 하게 됩니다. 어플리케이션 프로비저닝 로직이 복잡할 때 소프트웨어 업체는 SDP 프로비저닝 시스템이 호출하여 작업할 수 있는 자동 스크립트 또는 코드를 구현하는 것이 좋습니다. 하이브리드 시나리오 역시 가능한데, SaaS 호스팅 업체가 웹서버에 가상 디렉토리를 생성하거나 LDAP 디렉토리를 새로 만들고 사용자 계정을 아이덴티티 시스템에 등록하는 스크립트를 만들 수도 있겠죠. 동시에 소프트웨어 업체는 새로운 고객의 엔트리와 사용자가 설정 가능한 인터페이스, 브랜드, 칼라 스킴, 워크플로우, 비즈니스 룰, 엔티티데이터 모델 등 어플리케이션 메타데이터 정보를 업데이트 할 수 있는 프로비저닝 인터페이스를 제공할 수도 있을 겁니다.

가입자의 프로비저닝 작업은 SDP에서 핵심적인 요소이기도 하고, 완전히 자동화가 이루어지기 정말 어려운 분야이기도 한데, 프로비저닝 워크플로우가 성공적으로 진행되기 어려운 경우에 대한 예외 프로세스를 고려해야 합니다. 중복된 이름이 LDAP 디렉토리에 존재하여 해당 OU(Organization Unit)을 만들지 못하는 경우 등이 생긴다는 것이고, 이럴때는 지금까지 해왔던 모든 작업에 대한 undo 및 롤백 등으로 이전 상태로 되돌려야 하고, 지원인력이 트러블슈팅하거나 향후에 수정할 수 있도록 로깅이 반드시 남아야 합니다 . 프로비저닝 시스템은 해당 단위 작업에 대해 이해하고 있어야 하고, 이전 상태로 되돌릴 수 있는 Undo 기능을 가지고 있어야 함을 의미합니다.
모든 작업이 성공적으로 완료된 후에도 해당 작업에 대해 로그가 남아 있어야 합니다.

미터링과 빌링

클라우드 컴퓨팅에 대한 글, 기사는 계속 쏟아져 나오고 있습니다. 사용하는 용어도 참 다양하지요. 클라우드컴퓨팅, 유틸리티컴퓨팅, PaaS(Platform as a Service) 등의 용어가 주로 나오지요.
"마이크로소프트의 Gianpaolo의 블로그에서 가져왔습니다."

그런데 "클라우드 컴퓨팅"이 사용될 때 아키텍처 측면에서는 어떤 변화가 있을까요?

1. "직접 해라" vs "서비스로 쓰자"
 - "직접 해라"의 경우는 컨트롤을 할 수 있지만, 반면에 규모의 경제 효과는 볼 수 없겠지요. 모든 비용을 혼자 지 불해야 합니다.
 - "서비스로 쓰자"의 경우는 규모의 경제는 확실히 얻을 수 있지만, 직접 제어할 수는 없는 거죠

즉, "제어"와 "규모의 경제" 사이의 Trade Off이 있다는 거죠



2. "누가 구축할거냐"와 "누구의 장비에서 운영할 거냐"
 - "누가 구축할거냐" (직접 개발하는 방식 vs 구입); 기능의 컨트롤에 영향을 미치는 거죠. 직접 구축한다면
    기능을 넣고 빼는 것을 맘대로 할 수 있지만, 서비스 제공자로 부터 소프트웨어를 획득하는 거라면 제공자가
    부여하는 것밖에 사용 못하겠지요.
 - "누구의 장비에서 운영할 거냐"; SLA의 컨트롤에 영향을 미칩니다. "On Premise" 방식으로 직접 설치하고
    운영한다면 SLA에 대한 모든 제어가 가능하겠지요. 물론 SLA에 대한 제어가 가능하다고해서 높은 SLA를
    제공한다거나, 클라우드 방식보다 더 잘한다는 보장은 없지만요. ^^ 결국 SLA에 대한 조절은 가능하다는
    것이고, 클라우드 방식을 사용한다면 SLA를 서비스 제공자가 주는대로 사용해야 겠지요.



3. 가능성 맵 (map of possibilities)
위의 2가지 요소가 왜 중요할까요? 이 두가지의 요소를 통해 엔터프라이즈가 IT 자산을 사용할 수 있는 가능성 맵을 만들어볼 수 있기 때문이지요.
엔터프라이즈는 위의 2가지 요소에 비추어 "기능의 컨트롤", "SLA 컨트롤"을 규모의 경제를 활용하면서 얻기를 원하고 있다는 거죠. 맵 상의 하나의 선택이 다른 것보다 더 좋다는 것을 의미하는 것은 아니고 비즈니스 상황 및 규제 등에 따라 다르게 선택될 수 있는 것입니다.

아래의 그림을 통해 IT 자산의 몇 가지 유형을 볼 수 있습니다. 맨 왼쪽 위에 보면 '직접 설치된 패키지 소프트웨어'를 볼 수 있는데 직접 설치하고, SLA에 대한 모든 제어가 가능하지만 기능에 대해서는 제한적으로 선택이 가능하고, 규모의 경제를 통해 아쉬움을 달래는 것이죠. 소프트웨어 벤더의 경우 수백, 수천의 고객에게 패키지를 판매함을 통해 직접 고객이 개발하는 것보다 더 저렴한 금액으로 소프트웨어를 공급하게 됩니다. 맨 아래의 왼쪽 영역이 "직접 개발하고 직접 운영하는 소프트웨어" 영역 인데, 뱅킹 시스템을 예로 들어보지요. 제어권 및 기능을 모두 가지고 있지만 규모의 경제는 실현 못하죠. 개발 및 운영에 대한 모든 비용을 혼자 감당합니다 오른쪽 맨 위 영역이 바로 'SaaS' 입니다. 규모의 경제 효과가 높지만 기능 및 SLA에 대해서는 한계가 존재하는 거죠. 중간의 칼럼 (호스팅과 클라우드 컴퓨팅)은 직접 구축 및 운영에 비해 SLA 제어에 대해서는 제어권이 약화되지만 규모의 경제 효과는 증가되는 것을 볼 수 있죠.


4. 가상의 시나리오
이 시나리오 에서는 몇 개의 IT 자산은 원하는 독자적인 시스템을 직접 구축 하고 몇 개는 시장에서 통용되는 되는 방식을 그대로 사용하는 것입니다. 다시 말하면, 차별화가 필요한 자산은 집중적인 투자를 하고 (의료 진단 소프트웨어 등), 아주 일반적인, 즉 차별화 되지 않는 자산 (CRM, 이메일 등)은 시장에서 구입하여 사용하는 것이죠. 게다가 IT 자산은 직접 운영하고 보유하여, IT 환경에 대한 SLA를 직접 통제하는 방식을 의미합니다.



이런 형태의 그림이 아주 일반적이지요. 하지만 대부분의 CIO 분들은 이런 형태가 이상적이지만, 너무 많은 예산이 차별화 되지 않는 솔루션에 사용된다고 이야기 합니다.
결국 바라는 모습은 이런 겁니다.


이메일과 CRM은 차별화 되기 쉽지 않고, 규모의 경제를 보장 받으면서 SLA와 기능에 대해 Trade Off하는 거죠. 직접 개발된 리거시 HR 시스템의 경우 기능면에서 규모의 경제를 보장 받는 형태로 전환되면서 SLA에 대한 보장 및 데이터 보안이 필요하다면 내부에서 운영되도록 할 수 있습니다. 의료 진단 소프트웨어의 경우는 차별화되어 경쟁력을 보유할 필요가 있으므로 기존 보다 2배 정도의 예산을 투자하여 뛰어나게 개발하는 겁니다. (다른 쪽에서 비용을 절감했기에 여기에 더 많은 예산을 쓸 수 있다는 거죠)

목적은 분명합니다. 컨트롤을 유지하면서 규모의 경제를 보장 받는 형태로 자산을 배치시키는 방향을 취하면 됩니다.

케즘을 넘어서 ...


말이 쉽지 사실 직접 행동하는 건 쉽지 않죠.
Geoffrey A. Moore의 책에서 나온 말을 인용해보죠. 소프트웨어를 넘어서 클라우드로는 "케즘을 넘어서..."와 비슷합니다. 이 케즘은 아키텍트가 마스터해서 넘겨야 하는 거죠. 아키텍처가 당면한 도전과제는 다양합니다.

첫째, 아이덴티티
둘째, 관리
셋째, 데이터 입니다.

아이덴티티의 경우 크로스 바운더리상의 인증과 권한, 싱글 사인 온, 아이덴티티 라이프 사이클 등이며 관리는 방화벽을 넘어서 SLA 모니터링과 소프트웨어 액션 트리거링 (Halting, Pausing, Throttling) 할 것인지에 대한 것과 데이터의 소유권, 데이터의 이전 및 리포팅과 프라이버시 등입니다.

클라우드 컴퓨팅에 대해서 모든 답을 다 가지고 있는 사람은 없을 것입니다. 여러가지 방향으로 좋은 아키텍트 및 해결책을 찾으려고 노력하고 있다는 것이 적절한 표현일 것입니다. 앞으로는 위에 언급한 3가지 도전과제에 대해 좀 더 상세히 다루어 보려고 합니다. 그리고, 마이크로소프트가 공개한 S+S 어플리케이션 LitwareHR2에 대한 아키텍처 및 코드에 대한 부분을 다음 글에 다루어 보도록 하겠습니다.

"마이크로소프트 Gianpaolo의 블로그에서 가져왔습니다."

마이크로소프트의 월드와이드 파트너 컨퍼런스에서 마이크로소프트 서버 & 툴 비즈니스를 총괄하는 Bob Kelly는 다음달에 MSSQL 2008 정식 버전이 출시될 것이라고 밝혔습니다. 아주 기쁘게도 가격은 기존 2005와 동일하다고 합니다. 좋은 소식이죠?

또한, 마이크로소프트의 End-to-End 가상화에 대한 Launch가 9월에 예정되어 있다고 밝혔습니다. 한국에서는 9월 중순 이후로 잡혀 있는 것으로 확인되고 있는데요,정확한 날짜와 장소가 확정되면 제가 다시 글을 올리도록 하겠습니다. 전 세계에 있는 서버 중의 10% 정도가 현재 가상화 되어 있다고 합니다. 국내의 경우는 그 비율이 더 적어져서 3% 정도가 가상화 되어 있다고 하네요. (정확한 수치는 아닙니다. ^^)

앞으로 가상화로 구성된 서버의 수가 늘어날 것이고, 그 서버들은 마이크로소프트 가상화를 이용한 서버일 것으로 예상됩니다. 경쟁사의 서버 가상화에 비해 1/3 가격으로 구성이 가능하기 때문이죠. 또한, 관리툴인 System Center 제품군은 물리적인 서버 뿐 아니라 가상 머신들까지 하나의 도구로 관리가 가능하고, System Center Operation Manager와 연계되면 Linux, 오라클, 아파치, MySQL 등의 이 기종 서버 및 DBMS 까지 관리가 가능하기 때문에, 가상화에서 가장 중요시되는 관리 측면에서 마이크로소프트가 가지는 이점이 많은 것이 분명하기 때문이죠

가상화에 대해 설명해 보시겠습니까? 가상화에는 서버 가상화만 있을까요?
아니 가상화가 왜 등장하게 되었을까요?