바로 여기를 찾아주세요. Technet에서 최신 기술을 스크린과 설명을 동시에 하는 형태, Product를 직접 개발하는 매니저가 설명하는 웹 캐스트 형태로 제공되며 데모가 곁들어져 이해가 상당히 쉽습니다.
IE8, Hyper-V 가상화 기술, System Center, MOF(Microsoft Operation Framework), SQL Server 2008, 그린 데이터센터 등 최신 기술 동향에 대해 데모와 함께 다양한 정보를 얻으실 수 있습니다.
저도 자주 찾아가는데, 정말 강추합니다.
Virtualization for MAP(Microsoft Assessment & Planning) Tool에 대해 들어보신 적 있으신가요? 보유하고 있는 윈도우 장비들의 성능, 사양 등을 파악하여 어떤 서버가 가상화에 적합한지 여부와 호환성 부분까지 점검해주는 Tool 입니다. 또한, 다양한 가상화 중 어떤 가상화를 사용할 것인지에 대해 잘 알지 못할 때 IPD(Infrastructure Planning & Design) 가이드를 참고하면 베스트 프랙티스를 통해 현명한 의사결정을 내릴 수 있게 됩니다. IPD에 대해서는 시리즈로 연재해볼 까 합니다.
제 이메일 주소는 hsshin@microsoft.com 입니다.
또한, 윈도우, IIS, MSSQL 서버를 사용 중 발생하는 오류에 대해서는 윈도우 호스팅 포럼에 문의하시면 전세계의 호스팅 전문가로부터 답변을 받으실 수 있습니다. (무상 제공)
http://forums.asp.net/default.aspx?ForumGroupID=29
1. 본사 사이트 (www.microsoft.com)
2. 본사 MSDN (www.microsoft.com/msdn)
3. 본사 TechNet (www.microsoft.com/korea/technet)
4. 한국 사이트 (www.microsoft.com/korea)
5. 한국 MSDN (www.microsoft.com/korea/msdn)
6. 한국 MyMSDN (www.microsoft.com/korea/msdn/mymsdn/public/)
7. 한국 TechNet (www.microsoft.com/korea/technet)
8. ASP.NET (www.asp.net)
9. IIS7.0 (www.iis.net)
10.오픈소스PJT (www.codeplex.com)
11.SQL팀 블로그 (blogs.msdn.com/sqlserver/)
12.IIS팀 블로그 (blogs.iis.net/bills/archive/2006/11/14/powershell-rocks.aspx)
13.쉐어포인트 (blogs.msdn.com/sharepoint/)
14.윈도우 서버 (blogs.technet.com/windowsserver/default.aspx)
2007년 3월 시행함.
지난 2개월 동안 준비해오던 Asia Pacific과 Greater China Region(중국,홍콩,대만) 지역의 IT 전문가분들을 약 30여분 모시고 태국 방콕에서 제 1회 Training을 진행하고 있습니다.
(호스팅 비즈니스 및 아키텍쳐를 이해하는 강사 위주의 교육)
제목에서 이야기하는 바와 같이 Microsoft의 Windows Based Hosting v4.0에 대한 Training인데 개념설명과 더불어 실제 환경을 구성하며 진행하는 Hands-on Lab이라 준비에 더 많은 시간이 소요되었지만, 교육효과는 아주 좋은 것으로 평가되고 있습니다.
한국, 싱가폴, 태국, 말레이지아, 인도네시아, 베트남, 중국, 대만, 홍콩 등 대부분의 국가에서 참여해주셨습니다. Windows Based Hosting 솔루션의 핵심은 Centralized Management(중앙관리: Active Directory기반), Server Purposing (Automated Deployment Service), Update Management (WSUS), Monotoring & Reporting이 핵심 기반 Infra가 되고 Web Hosting(IIS), Data Hosting(MSSQL), Sharepoint Service를 부가적인 서비스로 보고 여기에 새로운 서비스가 생기면 Automate하게 서비스를 추가할 수 있는 마이크로소프트의 호스팅 플랫폼을 의미합니다. 또한, 호스팅 서비스의 베스트 Practice를 제공하고 있기에 많은 호스팅 업체에서 바로 활용 가능한 솔루션입니다.
이번 교육이 끝나면 각 국가별로 Windows Based Hosting v4.0 Training을 진행하려고 합니다. 한국의 호스팅 업체 엔지니어분들도 한국에서 진행되는 교육에 많이 참여해주시길 부탁드립니다.
SaaS에 대한 관심은 나날이 증대되고 있는 것 같습니다.SaaS를 설명하면서 언급하고 싶은 내용이 있습니다. 바로 장애입니다. 인프라 운영 시 장애는 일어납니다. 스위치 장비, 웹서버, 어플리케이션 서버, DB서버, 스토리지를 모두 이중화 하여 장애에 대비한다고 해도, Zero Down 타임을 보장 받을 수 없습니다. 최소화 할 수는 있겠지만, 어떠한 이중화도 100% 운영 시간을 보장할 수는 없습니다. 그렇다면, 발생 가능한 분쟁을 시스템을 운영하는 회사와 고객은 어떻게 해결할 수 있을까요? SLA(Service Level Agreement)가 바로 그것입니다.
모든 IDC에서는 SLA를 통해 고객과 벌어질 수 있는 불편한 상황을 피할 수 있습니다. 대표적인 지표는 서비스 가동율이 있지만, 상세한 항목으로 정의할 수 있습니다. 고객이 지불하는 금액에 따라 인프라 이중화 구성 및 데이터 복구 수준이 정해질 것이므로 정확한 값을 언급하는 것은 의미가 없을 것입니다.
제가 SaaS를 이야기하면서 SLA를 이야기하는 것도 바로 이런 이유 입니다. SaaS를 통해 서비스를 제공받는 고객 역시 SaaS 서비스를 제공하는 업체와 SLA에 대한 부분을 반드시 협의하여 지속적으로 관리 해야 합니다. 예를들어, CRM 서비스의 경우라면 5분, 10분, 30분, 60분 등 고객에 따라 참을 수 있는 다운타임이 있을 것이고, 이 부분에 대한 협의를 진행하며 서비스 비용을 결정해야 한다는 것입니다. (SLA는 업체마다 다르므로, 제가 제시한 값은 샘플값임을 고려하십시요)
블로그를 읽다 보면 Salesforce.com에 대한 이야기가 많이 스크랩되고, 쓰여지는 것을 볼 수 있습니다. Salesforce.com은 SaaS CRM으로 인기를 끌고 있고, 많은 관심을 받고 있는 업체입니다.
지난 주(2007년 3월 둘째 주)에 Salesforce.com 인프라에 장애가 발생하여 5-6시간 동안 서비스가 중단 되었습니다. 2005년 12월 큰 장애 이후, 대규모 장애는 이번이 2번 째 입니다. Salesforce.com의 CRM 서비스를 사용하던 고객들도 영향을 받았지만, 그 보다 더 심각한 영향은 AppExchange Platform을 통해 고객을 획득하던 ISV(Independent Service Vendor)들이 받았습니다. 장애에 대해 ISV 업체들이 할 수 있는 것이 아무것도 없었고 Salesforce.com이 장애를 처리하길 기다리는 수밖에 없었죠. 업체의 말을 빌리면, "우리는 바보처럼 기다릴 수박에 없었어요." 였습니다. 장애는 5-6시간 이었으나 실제로 ISV는 이틀 동안 이나 상품을 팔지 못했다고 합니다. ISV 들은 Salesforce.com이 이런 일이 벌어지는 동안 제대로 설명해 주지 않았다고 불평했습니다.
서비스 운영 관점에서 장애는 발생할 수 있지만, 어떻게 처리하느냐가 중요한 능력 중의 하나입니다. 이런 관점에서 이번 Salesforce.com의 대응 자세는 문제가 있었고, SLA에 대한 중요성이 부각되는 측면이라고 하겠습니다. SLA에 언급되어 있지 않다면 어떤 불평도, 보상도 받기 어려울것이기 때문입니다.
Service Level Agreement (SLA)
A formal written agreement made between two parties: the service provider and the service recipient. The SLA itself defines the basis of understanding between the two parties for delivery of the service itself. The document can be quite complex, and sometimes underpins a formal contract. Generally, an SLA should contain clauses that define a specified level of service, support options, incentive awards for service levels exceeded and/or penalty provisions for services not provided.
일반적인 웹 사이트를 개발할 때의 라이프사이클을 생각해보겠습니다. 개발자가 웹사이트를 만들고 나면, 이 웹사이트를 운영해줄 누군가와 서버(H/W, 웹서버, DBMS)가 필요하게 됩니다. 대부분의 경우는 호스팅 업체를 통해 웹사이트를 운영하도록 합니다.
그럼 SaaS 어플리케이션의 경우는 어떨까요? 서비스 어플리케이션을 만들었다고 가정하겠습니다. 기존 같이 호스팅 업체에 맡기면 될까요? 위의 웹사이트의 경우는 나의 사이트를 맡긴 것이기 때문에 장애가 나면 내가 감당하면 됩니다. 그렇지만, 내가 서비스를 만들었고 고객의 데이타를 다루는 서비스를 운영하고자 하는데 장애가 나면 어떻게 해야할까요? 고객의 중요한 업무가 장애로 인해 중단된 상태인데, 서비스 제공자인 내가 할 수 있는 일은 아무것도 없습니다. 호스팅 업체가 장애를 해결해주기를 기다리는 것 이외에는. 하드웨어 장애의 경우는 호스팅 업체가 해결해줄 수 있지만 어플리케이션 장애의 경우는 내가 해결해야 합니다. 원격으로 접속해서 문제를 해결하기가 대단히 어려울 것입니다.
그렇다면, 호스팅 업체 대신에 내가 직접 어플리케이션 및 H/W를 운영하는 경우를 생각해보겠습니다. 아시다시피 서비스는 365일, 24시간, 7일 동안 즉 중단없이 운영이 되기 때문에 운영자를 최소한 4명은 두고 4조 3교대 형태를 유지해야 합니다. 1명씩이 근무를 하고 있는데 네트웍, H/W, S/W, 어플리케이션에 대한 모든 장애를 다 감지하고 해결할 수 있을까요? 2명씩 근무를 하는 체제로 바꾸어 8명을 두어야 한다고 가정해보겠습니다. 그래도 다양한 오류를 해결할 수는 없고 무엇보다 비용이 가장 큰 문제입니다. 8명을 유지하기 위해 1개월에 소요되는 기본 비용이 엄청나죠? 이 비용 이상을 서비스로 매출을 올린다는 것은 쉽지 않은 이야기입니다.
그래서 등장한 해법이 SaaS 호스팅 업체 입니다. 해외에서는 SaaS Hoster라는 용어를 사용합니다. SLA(Service Level Agreement)를 어플리케이션 서비스 업체와 체결하여 그 수준을 맞추며 호스팅 서비스를 제공하는 업체를 말하는 것이죠. 하지만, 국내의 경우는 SLA에 대한 개념이 아직 정착되어 있지 않아 SaaS Hoster는 없다고 보는 것이 맞을 것 같습니다. SaaS를 확산시키기 위해서는 SaaS Hoster를 양성하는 것도 꼭 필요하다는 것을 강조하고 싶습니다.
기억하세요. 어플리케이션 운영을 어떻게 진행하고, 비용 부담을 줄일 것인지가 꼭 고려되어야 합니다.
SaaS 서비스를 도입하기를 꺼리는 사용자 입장에서 제일 걱정되는 부분이 바로 데이터를 서비스 제공자에게 맡겨야 한다는 것입니다. 예를들면, 아래와 같은 경우가 있을 수 있습니다.
1. 서비스 제공자가 파산하여, 서버 및 스토리지를 채권자에게 압류당한 경우
2. 서비스 제공자와의 분쟁으로 인해 데이터에 대한 접근을 차단 당하는 경우
3. Consumer가 다른 서비스 제공자로 데이터를 이관을 하기를 원할 경우
4. 서비스 제공자의 장애가 장기간 길어지는 경우
5. 해커가 침입하여 데이터를 악용하여 Consumer에게 책임이 전가되는 경우
이런 경우에 대한 두려움이 해결되지 않으면 믿고 맡기기 정말 어려울 것입니다.
이를 해결하기위해 에스크로 제도가 필요할 것입니다.
SaaS 에스크로 서비스는 아래와 같은 서비스를 제공하면 됩니다.
1. SaaS 데이터의 핫백업을 제공
2. 소스코드를 포함하여 SaaS 어플리케이션의 복사본 제공
3. 유사시 에스크로 제공자에게 서비스가 이관시 정상적으로 작동하는 것을 보장하는 검증 테스트
이런 서비스를 제공할 수 있다면 믿고 맡길 수 있을 것입니다.
현재 미국의 www.ironmountain.com 라는 회사가 SaaS 에스크로 서비스를 제공하고 있습니다.
싱가폴을 포함한 동남아시아 호스팅 업체들이 주요 청중이 될 텐데요, 현재 IDC 및 호스팅 업체들이 겪고 있는 문제점 및 이슈를 해결할 수 있는 다양한 해법을 세미나를 통해 전달하게 됩니다.
호스팅 업체 IT 관리자가 시간을 사용하는 내역을 살펴보면, 서버 빌드 시간, 서비스팩, 소프트웨어 업데이트, 보안패치, 장애 발견 시 사후 트러블슈팅 등에 많은 시간이 소요되는 것을 알 수 있습니다.
보통 1대의 서버에 OS를 설치하는데 1시간 - 1시간 30분 정도 소요된다고 가정하면 10대에 OS를 설치하면 10시간에서 15시간 정도가 소요된는 겁니다. 1대로 치면 적지만, 모이면 꽤 큰 시간을 서버 빌드에 사용하는 겁니다. 이를 WBH 솔루션의 Server Purposing (실제로 Automated Deployment Service)을 이용하면 10대를 15-20분에 설치하게 되므로 실로 어마어마한 시간을 절감할 수 있게 되는 거지요.
이렇게 절감된 시간을 향후 IT 인프라 최적화 및 최신 기술에 대한 Study에 사용하면 관리자 개인 및 회사 입장에서 큰 효과를 보게 될 것임은 자명한 일입니다.
ADS에 대해서 조금 자세하게 설명을 해볼까 합니다. 사용법이 상당히 쉽습니다. Windows Server 2003 Enterprise Edition을 가지고 있다면, 무료로 add-on 할 수 있는 솔루션 입니다. 이 ADS를 한대의 서버에 설치하면, 이 서버를 컨트롤러 서버라고 한다면, 이게 준비의 끝 입니다. 서버에 OS를 설치하려는 HW가 PXE(Pre-boot Execution Environment)를 가지고 있다면 동일 네트웍에 연결 시키는 즉시 컨트롤러가 인식을 합니다.
컨트롤러의 콘솔에서 인식을 하고, 어떤 방식으로, 그리고 어떤 이미지를 빌드할 것인지를 선택할 수 있게 되는 거지요. IIS가 설치되어 있는 이미지, SQL 서버가 설치되어 있는 이미지, 아니면 다른 특정 어플리케이션이 설치되어 있는 이미지 등을 미리 만들어 놓고, 향후에 똑같은 유형의 서버 설치를 원하면 바로 선택하면 됩니다. 가장 대표적이며 쉽게 적용할 수 있는 기능은 바로 이 ADS라고 생각합니다.
가장 많이 받는 질문이 바로 "SaaS와 ASP의 차이점이 뭐죠"라는 것입니다. 이와 비슷하게 가장 많이 받았던 질문이 "혁신(Innovation)이 뭐죠" 였던 것 같습니다.
"왜 이런 질문이 나오는 것일까?" 곰곰히 생각을 해봤는데요 정의에 대해, 즉 개념을 명확히 하고 넘어가지 않았기 때문인 것 같습니다.
SaaS의 정의는 "소프트웨어가 호스팅 환경으로 배포되어, 인터넷을 통해 서비스 되는 것" 입니다.
IDC가 이렇게 정의하고 있고, 마이크로소프트도 역시 동일한 정의를 사용하고 있습니다.
이 정의를 기준으로 하면 "ASP도 SaaS가 맞군" 이라고 말하실 것입니다. 맞습니다. ASP도 SaaS가 맞습니다. 다만, 성숙도(Maturity)가 다르다고 표현하는게 맞을 것 같습니다.
지난 2007년 7월 4일, IT렌털산업협회가 주관한 조찬 세미나에서 "2008년 SaaS 산업 전망과 이슈"라는 내용으로 주제발표를 했습니다.
1단계, Application Hosting, 즉 ASP 모델입니다. 하나의 고객을 위해 1개의 Instance를 띄우게 되고, 고객에게 맞춰서 커스토마이징을 하게 됩니다. 커스토마이징에 많은 비용이 소요되기고, Instance를 개별로 띄우기에 규모의 경제를 실현할 수 없게 되는 단점이 있습니다.
2단계, 본격적인 SaaS Architecture입니다.고객 당 Instance를 하나씩 띄우기는 하지만, 커스토마이징이 아닌 메타데이터를 활용한 Configuration을 통해 고객 설정을 하기 시작합니다. 초기 셋업을 서비스제공자가 아닌 고객이 직접하고, 커스토마이징이 없기에 비용을 절감할 수 있지만 아직 규모의 경제는 실현하지 못합니다.
3단계, Multi Tenant를 실현하고, Congiguration까지 가능한 진화 모델입니다. 하나의 Instance로 다수의 고객을 서비스하기에 규모의 경제가 실현되며 Configuration으로 고객 설정을 하기에 비용절감, 규모의 경제가 실현됩니다.
4단계, Multi Tenant, Configuration, Scalability가 구현된 것입니다. 즉, 성숙된 SaaS 어플리케이션은 이 3가지의 특성을 보여주게 되는 것입니다.
ASP와 SaaS를 구분짓는 것은 어떤 개념상의 차이가 아니고, 비즈니스 상에 어떤 효과를 주는지로 구분하는 것이 맞다는 것입니다.
자동차를 예를들어 설명하겠습니다. 현재 자동차는 휘발유 또는 디젤을 연료로 사용합니다.
여기에 연비가 뛰어나고, 화석 연료의 사용을 줄일 수 있는 전기와 휘발유, 디젤을 병행 사용하는 하이브리드카를 만들었다고 가정해보죠.
하이브리드카는 광의의 개념으로 보면 똑같이 자동차이고, 협의의 개념으로 보면 연료 비용을 절감하고, 화석 연료가 고갈되는 시기를 연장시켜주는 새로운 개념의 차라고 이야기할 수 있을 것입니다.
ASP와 SaaS의 차이도 이와 비슷합니다. 광의의 개념으로 보면 ASP와 SaaS는 조직 내부에서 직접 설치하여 운영하는 방식(on-premise)와 달리 서비스제공자에 의해 설치되고 서비스로 제공되는방식(hosted)임에는 차이가 없지만, 협의의 개념으로 보면 서비스를 이루는 어플리케이션의 아키텍쳐가 개선되어, 규모의 경제 및 ROI를 향상시켜주는 진화된 모델이라고 볼 수 있는 것입니다.
즉 ASP는 어플리케이션의 구조가 고객마다 커스토마이징을 해야하는 구조였기 때문에 1 to many를 구현하지 못하고, 1 to few 구조였기 때문에 규모의 경제를 실현하지 못하는 단점을 가지고 있었다는 것이죠. 어플리케이션의 아키텍쳐가 Configuration, Multi-tenant, Scalability 요소를 갖는다면 진정한 의미의 SaaS라고 부를 수 있이고, 단계적인 개선이 이루어질 때마다 1단계, 2단계, 3단계 SaaS 아키텍쳐라고 부를 수 있을 것입니다.
21세가 통일 한국을 이끌어 갈 주역으로 성장하기 위한 노력에, 학생들도 함께 동참하기를 바라는 마음에 정말 열심히 준비했고, 열정적으로 전달했다고 생각합니다. 많은 학생들이 강연이 끝난 후에도 연락을 해주고 있어서, 너무 기쁘고 뿌듯합니다. 이 블로그를 통해서 각자의 비전을 공유해보는 건 어떨까요? 100가지 소원 중 이루어진 것도 함께 나누어 보기로 해요.
강연모습
뒷풀이 사진
이번 주일에는 비전 여행 세번째 시간을 보냈습니다.
가장 중요한 내용은 앞으로의 일생에서 꼭 이루고자 하는 일 100가지를 작성하는 일이었습니다. 평상시에 바라던, 기도가 꼭 이루어졌으면 하는 일 100가지를 적는 시간이 있었는데요, 정말 어렵더군요.
내가 바라는 게 정말 이렇게 적었나 하는 나의 소박함에 놀랐고, 그동안 많은 성취감을 느끼지 못했던 것도 바로 정확한 목표가 없었기 때문이구나 하는 생각을 하게 되었습니다.
1. 현재 수영을 배우기 시작한 지 5주 정도 지났는데, 마스터하여 한강횡단수영대회에 참가하기
2. 평생의 소원 악기 연주하는 법 배우기 - 피아노로 내가 좋아하는 노래 멋지게 연주
3. 한달에 한 번 그림을 그리는 여행을 꼭 떠나기
4. 정원이 있는 집을 갖기
...
아직 37번까지 밖에 작성하지 못했습니다. 이번 주일까지 숙제가 100가지 작성하기인데, 좀 더 생각해봐야겠네요.
추가로 적어보면, 드디어 100개의 소원을 다 적었습니다. 생각보다 내가 원하는게 많지 않다는 사실에 놀랐어요. 굉장히 하고 싶은게 많을 거라고 생각했었는데.
이제 달성된 소원들을 하나씩 지우는 재미로 한 번 살아볼까 합니다.