마이크로소프트가 클라우드 서비스를 운영하면서 얻은 교훈들.. 그 결과로..
마이크로소프트가 가장 오랜 기간동안, 가장 많은 사용자 분들을 대상으로 제공했던 서비스의 이름은 무엇일까? 라는 생각을 해보신 적이 있나요?
바로 “Windows 업데이트 서비스”입니다. 잘 생각해보면, 지난 10여년 이상을 특정 시간대마다, 빠짐없이 마이크로소프트 기술에 대한 다양한 보안 및 기술 업데이트에 대해 릴리즈하고, 전세계에 분포된 사용자 분들의 운영 체제로 큰 문제없이 배포되고 있습니다. 이 서비스라는 컨셉이 지금 생각해보면 클라우드라는 컨셉이며, 어찌보면 매우 오래전부터 클라우드 형태의 서비스를 생각해오고, 이에 대해 현실화시키고 있었던 기술 벤더중 하나이지 않나라는 생각도 듭니다.
지난 클라우드 트렌드와 함께, 공용 클라우드(Public Cloud) 형태로 Windows Azure, SQL Azure, Office 365, Windows Intune 등과 같은 불특정 다수의 고객 분들을 위한 서비스를 만들고, 이에 대한 데이터센터(위의 그림)에서 수백만의 고객과 수십만대의 서버, 그리고 그 안에서 운영되는 엄청난 숫자의 가상 머신과 응용 프로그램들을 운영하면서, 이에 대한 마이크로소프트 기술을 활용 및 적용하고 있었다는 것도 자명한 사실입니다.
마이크로소프트엔 제품 출시 전, 내부 직원들이 이에 대한 기술을 먼저 사용해보고, 이에 대해 건의 사항 및 의견을 개진하는 프로그램이 꽤 오래전부터 있었습니다. 새로운 운영 체제의 출시나 기술 소프트웨어 출시전, 전세계에 있는 많은 숫자의 직원들이 고객이 사용하시기 전에 이를 사용해보고, 고객과 동일한 입장에서 생각을 해보는 것이죠.
동일하게 데이터센터에서 운영중인 공용 클라우드 서비스를 운영하면서, 여러가지 측면, 물론 이 측면이 긍정적인 면도 있고, 부정적인 면도 있겠지만, 근 3~5년내에 갑작스레 증가한 클라우드의 요구에 따라 Windows Server와 관리 기술인 System Center를 적용하면서 많은 점을 새롭게 배웠다고 전해집니다.
지난 3월 27일, 서울 잠실 롯데 호텔에서 개최된 마이크로소프트 사설 클라우드의 키노트 세션과 더불어 IT CAMP 등에서 마이크로소프트 사설 클라우드 소개 슬라이드에서 잘 등장한 페이지입니다. 마이크로소프트의 기술이 클라우드에 적용되기 위해서 필요했던 큰 4개의 축이 잘 정리되어져 있습니다.
표준화 지향
말 그대로 표준화를 향해야 한다는 의미입니다. 클라우드의 특징은 기민성(Agility)이 그중 하나입니다. 이 기민성을 기반으로 탄력성(Elastic)이 붙게 되고, 무언가를 비즈니스 요구에 맞춰 빠르게 만들기 위해서는 여러 고객 시나리오에 적절한 표준이 있어야 한다는 것입니다. 예로 하나를 살펴보면, 바로 운영 체제의 경우, 가상화 환경에 들어가게 되면, 특정 파일 포맷의 형태(Windows Server 2008 R2까진 VHD, Windows Server 2012에선 VHDX)가 되겠죠. 하나의 이미지가 다양한 측면의 요구 사항에 적절하다면, 이미지 관리 및 배포가 빨라지게 되고, 보다 기민성이 생기게 됩니다. 너무 많은 시나리오에 이미지가 필요하다면, 쉽게 모듈 단위 On/Off를 취하게 되면, 이야기가 더욱 적절해집니다. 운영 체제라는 큰 뼈대에 필요한 기능에 따른 Enable/Disable이 가능하다면, 역시나 설정에 대해서 빠른 적용이 가능해집니다.
지금까지의 표준화는 운영 체제(PaaS)까지, 그보다 작다면 하드웨어 레벨(IaaS)이 많았습니다만, 실제로 비즈니스에 이익을 남겨주는 것은 응용 프로그램(소프트웨어, SaaS) 레벨입니다. 결국 클라우드라는 틀을 고객이 사용하는 경우, 이에 대해 혜택을 누리고자 한다면, 응용 프로그램까지 포팅이 되어야 하며, 이를 위해서라면 응용 프로그램 레벨에 대해서도 표준화가 필요합니다.
컴퓨터 = 하드웨어 + 운영 체제 + 응용 프로그램 + 데이터
서비스 = 다수의 컴퓨터의 묶음 (N-티어)
클라우드 = 서비스
System Center 2012 Virtual Machine Manager에 보여진 서비스 템플릿입니다. 지금까지의 템플릿은 잘해야 VM 레벨이었지만, 이제 템플릿은 응용 프로그램 레벨까지 적용이 가능합니다. 2011년 6월 28일에 포스팅한 인프라를 넘어서, Web, DB, Middle-Tier까지 클라우드 기반의 유연성을… SAV(Server Application Virtualization) 패키지 생성!에서 살펴본 내용입니다. 결국 앞서 언급한 바와 같이 응용 프로그램을 올려야 비즈니스 서비스가 가능해지고, 응용 프로그램을 서버 응용 프로그램 가상화(SAV)를 이용해서 서버에도 가능하게 한 기술의 응용입니다. SAV v1의 경우엔 Web Deploy를 이용하는 웹 서버, 그리고 SQL DAC를 이용하는 데이터베이스가 가능합니다. 차후 SharePoint나 Exchange Server까지 확장될 예정입니다. 이런 형태라면 응용 프로그램, 운영 체제(설정 포함), 하드웨어에 대한 표준화 생성이 가능해지고 이를 다수 엮게 되면 서비스가 되겠죠?
SLA 기반 아키텍쳐
서비스 제공자에게 고객과의 약속은 장애없이 서비스를 운영해주겠다는 측면이 가장 큽니다. 문제가 발생하더라도, 빠르게 해결하겠다는 부분도 포함되게 됩니다. 뿐만 아니라, 고객의 응용 프로그램적인 측면의 아주 작은 문제라도 고객보다 먼저 파악하고, 이를 자동으로 수정하거나, 필요시 빠르게 고객에게 알려줘야 할 의무가 있습니다. 고객과 서비스 제공자와의 약속을 우리는 SLA(Service Level Agreement)라고 합니다. 명확한 가이드를 제시하고, 이 가이드에 맞게 운영되고 있다는 약속이죠.
이를 위해서는 몇가지 선행되어야 할 과제가 있습니다.
- 운영 중인 인프라 자체내의 로그 명확성 및 정확성
- 매우 세세한 측면까지의 모니터링과 이에 대한 해결 가이드
이번에 새롭게 출시된 System Center 2012에는 클라우드 관리 및 모니터링에 필요한 많은 기술이 개선, 혹은 추가되었습니다. 그 중 하나인 APM(Application Performance Monitoring)입니다. 자세한 내용은 여러 기술이 혼재된 환경(Heterogeneous)을 위한 응용 프로그램(Generic/.NET/Java) 성능 모니터링(APM), System Center Operation Manager(SCOM) 포스팅을 참고하시면 기술적인 사항을 참고하실 수 있습니다. 기존에는 동작하는 운영 체제까지에 대한 부분은 System Center의 Operation Manager가 담당할 수 있었습니다. 이번에 업그레이드된 2012의 경우에는 응용 프로그램 부분, 그리고 하위 하드웨어에 대한 부분을 강화하였습니다. 역시나 앞에서 이야기드린 공식인 컴퓨터 = 하드웨어 + 운영 체제 + 응용 프로그램 + 데이터라는 측면에서 어디서부터 어디까지의 관리가 필요할 지를 가늠할 수 있겠죠.
SLA를 위한 또 하나의 필요 요소중에 하나가 사용자(고객)가 필요시 원하는 것을 바로 신청 및 확인할 수 있는 셀프 서비스 포탈 및 이에 따른 프로세스 처리입니다. 이어서 언급할 프로세스 성숙도와 연계된 이야기입니다만, 우리의 사내 IT 인프라는 무언가를 IT에 요청할 경우, 전자 메일, 전화 혹은 무언가의 직접적인 방법으로 요청하게 됩니다. 오프라인 세미나에서도 종종 언급드리는 사항이지만, 이런 요청을 실제 환경, 예를 들어 포털 사이트등에 가입을 요청하거나, 카페 가입을 신청하는 경우에 직접 포털 업체에 전화를 걸어 신청하지 않고, 직접 웹 사이트에 접속하여 진행하는 것에 익숙해져 있음에도 불구하고, 이상하게 IT 환경으로 오게 되면 이를 비효율적인 방법으로 요청하고, 처리받게 되죠. System Center에서는 사용자의 요청,그리고 요청에 대한 진행 상태 및 결과(마치 택배 배송 상태 조회와 비슷한 형태)를 셀프 서비스 포탈에서 확인 가능케하고, 이에 대해서 IT가 체계적인 관리를 가능하게 합니다. 이런 작은 요소들이 모여, 상호간의 서비스에 대한 체계적 제공 및 정리, 나아가 IT 팀에 대한 평가가 가능해지겠죠.
프로세스 성숙도
무언가 IT에서 일을 진행할 때는, 정해진 규칙 및 방법론이 있습니다. 작게는 계정을 하나 만들때부터 시작해서, 크게는 인프라에 변경을 가할 때도, 더불어 문제 발생시 문제를 트러블슈팅할 때도, 어떤 순서에 따라 진행하게 되죠. 우리는 이를 프로세스라고 표현합니다.
예를 하나 들어보죠. 특정 웹 사이트에 접속 문제나 장애가 발생했다고 가정하겠습니다. 우리는 어떤 방식으로 진행을 할까요?
- 웹 사이트가 정말 접속이 안되는지 브라우저를 열고 접속한다.
- PING이나 네트워크 명령을 통해 서버가 응답하는지 확인한다.
- 웹 서버 재시작 도구들(IIS로 따짐 IISRESET 등)을 이용한다.
- 이래도 해결이 안되면, 직접 서버를 열고 문제 해결을 시작한다.
또 하나의 예를 들어볼까요? VDI 환경을 이용할 경우, 새 가상 데스크톱의 생성 및 배정이 필요합니다.
- 신규 계정을 만든다.
- 해당 계정이 사용할 가상 데스크톱을 배치할 여유있는 가상화 플랫폼을 확인한다.
- 해당 플랫폼에 가상 데스크톱 파일을 복사한다. 그리고 기본적인 운영 체제 설정을 진행한다.
- 필요한 응용 프로그램을 설치 혹은 응용 프로그램 가상화를 통해 스트리밍한다.
- 해당 데스크톱의 IP를 사용자에게 전자 메일 등의 방식으로 전달한다.
역시나 무언가의 정해진 순서가 있는 형태죠. 이를 우린 프로세스라고 합니다. 프로세스는 기술의 영역과 사람의 영역으로 나눠지게 됩니다. 기술의 경우엔 첫번째 예제가 해당되며, 이 경우 반복적인 작업등에 대해서는 위의 그림과 같은 형태의 워크플로우를 만들고, 특정 조건이 발생했을 경우에 자동화처리를 할 수 있습니다. 클라우드나 IT 인프라가 점점 프로세스에 대한 중요도를 강조하고, 반복적 업무에서 탈피하려는 움직임에 따라, System Center 2012 Orchestrator와 같은 형태의 기술 프로세스 자동화 모듈등이 관심을 받고 있습니다.
사람의 경우에는 특정 시점이나 조건에서 사람이 개입해야 하는 경우가 있습니다. 가상 머신을 새롭게 받았는데, 메모리를 100GB를 요청하거나, 네트워크 용량을 평균이상으로 요청하는 등.. 무언가 사람이 확인하고, 이에 대해 진행, 혹은 진행하지 않음에 대해 결정해야 하는 경우가 있을 수 있죠. 기존 우리나라에서는 전자 결제와 같은 형태가 여기에 해당됩니다. 상위의 그림은 System Center 2012 Service Manager입니다. 서비스 매니저의 경우엔 기술에 대한 자동화와 더불어, 사람이나 여러 환경적인 조건을 가미할 수 있습니다. 특정 작업에 대해 팀장급에서 전원 승인, 과반수 승인, 1인 승인등과 같은 우리의 결제 문화와 동일한 형태로 만들어낼 수도 있고, 이를 통과했을 경우, 실패했을 경우, 기술적인 방향성(앞서 언급드린 Orchestrator 등의)과 연계할 수 있습니다.
또한 서비스 매니저의 경우, 작업 및 여러 프로세스에 대한 처리 결과, 장애 발생 및 해결 등에 대해서 전체적인 상태, 방향성을 하나의 데이터베이스에 저장해놓습니다. 우리는 이를 CMDB(Configuration Management Database)라고 합니다.
지금까지 System Center 2012의 Orchestrator와 Service Manager의 차이를 조금은 이해하실 수 있으시겠죠?
이렇게 IT에 대한 여러 우리가 해왔던 일상적인, 혹은 어떤 순서에 따른 처리등을 잘 정리하여, 명확한 프로세스로 만들어놓았다면, IT에서 업무 요청, 할당, 처리, 결과 보고등의 처계적인 작업이 진행될 수 있으며, 이는 앞서 언급한 고객과의 SLA 약속에도 긍정적인 방향을 제시하게 됩니다.
위임 및 제어
클라우드 인프라가 되면서, 이제는 인프라의 크기나 구성은 사용자의 입장에서는 의미가 없습니다. 이 인프라가 Hyper-V인지, Citrix인지, VMWare인지는 사용자 입장에서는 필요하지 않다는 것입니다. 내가 원할 때, 원하는 양만큼을 잘 할당받아서, 남에게 영향을 받지 않고, 나만의 인프라 형태로 이용하고 싶어합니다. 결국 논리적으로 인프라를 분리할 경우, 보안 및 격리 수준이 높아야 한다는 것이죠. 하단의 인프라 레벨에서 상호간 영향을 주지 않고, 명확하게 분리되어져 있어야 하고, 이 분리된 영역내에서는 마음껏 이용할 수 있어야 합니다. 또한 그 영역은 사설 클라우드, 공용 클라우드별로 다르게 바라봐져서는 안된다는 것이죠.
마이크로소프트의 클라우드 기술은 현재 멀티 테넌트에 대한 이야기로 나아가고 있습니다. Windows Server 다음 버전에서 많이 언급되는 멀티 테넌트(Multi-Tenant)란? 포스팅에서 이에 대한 방향성을 간략히 정리해봤으며, 차후 포스팅을 통해 네트워크 가상화나 PVLAN(Private VLAN)을 살펴볼 예정입니다.
System Center의 경우, 클라우드 영역에 대한 논리적인 분리를 Fabric 관점에서부터 시작하여, 전체적인 클라우드 인프라까지로 나눠주게 됩니다. (Fabric에 대한 이야기는 제가 외부에 기고한 칼럼 : [칼럼]클라우드 떠받치는 패브릭, 도대체 무엇일까을 참고하시면 좋을 듯 합니다.) System Center 2012 Virtual Machine Manager에서 나눠진 클라우드 영역들은 그 영역별로 사용 가능한 리소스나 생성 가능 숫자등의 할당량까지 제어가 가능하죠. 이를 고객이 실제로 사용할 경우, System Center 2012 App Controller를 통해, 사용자는 상호간에 간섭(!)을 받지 않고, 본인에게 제공된 부분만을 제어할 수 있습니다.
모니터링적인 측면에서도 사설과 공용은 구분되어져 있지 않은 한 콘솔에서 동작 상태의 확인이 세부 레벨까지 가능합니다. IT가 사설이던 공용이던 어느쪽 클라우드를 사용할지는 비즈니스적인 판단에 의거하기 때문에, 결론적으로는 같은 인프라라는 것입니다. 크게 봤을 때, 두 클라우드, 즉 사설과 공용 클라우드는 하나처럼 동작하게 될 것이고, 이를 벌써 하이브리드 클라우드란 단어로 이야기하고 있습니다. Windows Server 2012에 향상된 측면이 Site-to-Site VPN 기술인데, 해당 기술을 통해 Windows Azure + Windows Server 환경, 혹은 Windows Server로 구성된 사설 클라우드 환경들을 하나의 통 인프라로 설정할 수 있습니다. 이를 통해 특정 클라우드내 웹 서버 서비스와 특정 클라우드내 데이터베이스 서비스를 하나의 IP 대역내에서 서비스할수 있다는 의미로 보시면 됩니다.
결론
내용이 참 길어졌습니다. 포스팅하나를 여기저기 세미나를 다니던 중에 작성해서 3일이란 시간이 걸렸네요.
결론은 이렇습니다. 
이런 여러가지의 교훈으로 만들어진 기술들을 마이크로소프트 클라우드 서비스에서는 사용하고 있습니다. 그렇지만 이러한 기술을 가지게 된 계기는 바로 시장 및 고객 분들의 피드백, 이용, 비즈니스 협력등으로 이뤄냈기에, 다시 시장에서 사용 가능한 표준화 제품 및 기술로 내놓는 것이 맞다고 생각한 것 같습니다.
현재 클라우드에 대한 공식은 클라우드 = 플랫폼 + 관리(구성, 배포, 모니터링, 프로세스, 셀프 서비스 등등) 을 가져가고 있습니다.
이러한 두가지 측면에서 플랫폼은 Windows Server 2012, 관리는 System Center 2012로 연결되며, 오늘(4월 18일) 새벽 미국에서 개최되고 있는 MMS 2012에서 System Center 2012의 공식 릴리즈를 발표하였습니다. 지금까지의 기술들과는 비교했을 때, 한차원 높은 수준의 기술 세트를 만들어놓았습니다. 이러한 기술이 그냥 생각만으로 나온 것이 아니라, 수백만의 고객과 수십만의 서버들을 운영하면서 마이크로소프트 기술에서 필요한 사항이 무엇인지를 정확하게 느끼고, 이를 단순히 해결만 하는 것이 아니라, 더욱 가치있게 기술로서 제공할 수 있도록 고민한 흔적들이 여기저기에서 보여집니다.