[CIO BIZ+]Analysis-기업 프라이빗 클라우드 컴퓨팅 구축 어떻게

관련 통계자료 다운로드 가트너의 프라이빗 클라우드 서비스 계층 분류

　클라우드 컴퓨팅이 대세다. 하지만 통신 서비스 업체와 대형 IT서비스 업체 등 일부 서비스 제공업체들이 사업 포트폴리오 일환으로 준비하는 것이라고 생각하면 두 가지 측면에서 오해다.

　우선 전 세계적으로 클라우드 컴퓨팅 주도 기업은 서비스 제공업체가 아니라 개별 기업이다. 자사 데이터센터를 클라우드 컴퓨팅 인프라스트럭처로 바꾸려는 기업들 때문에 퍼블릭 클라우드보다 프라이빗 클라우드가 더 빨리 확산되며 시장 규모도 더 클 것으로 점쳐지고 있다.

　두 번째 오해는 클라우드 컴퓨팅 시기에 대한 것이다. 국내에서는 대외 서비스를 위해 통신 및 IT 서비스 업체들이 기반 조성을 하는 단계이지만 밀린드 고베카 가트너 부사장에 따르면 미국, 영국 그리고 유럽 일부 지역에서는 2008년 말~2009년 초부터 클라우드 인프라를 조성하기 시작했다.

　전 세계적으로 경기 침체기에 클라우드 인프라를 조성한 이들 선진 기업은 내년 초부터 기업 정보 서비스가 클라우드 환경에서 본격 운영할 것으로 보인다. 얼마 전 클라우드 기술 벤치마크차 미국 실리콘밸리를 방문한 LG그룹 계열사들 최고정보책임자(CIO)들 역시 현지의 클라우드 서비스 활용 및 상용화 수준을 보고 국내와의 현격한 간극에 대해 놀라워했다는 후문이다.

　하지만 가트너는 기업들이 프라이빗 클라우드를 구현하려고 할 때 놓쳐서는 안 되는 것이 있다고 지적한다. 프라이빗 클라우드의 계층별 구성요소에 대한 이해와 통합 전략, 서비스 관리다. 데이터센터 아키텍처와 운영관리의 단순성과 확장성, 유연성이 클라우드 아키텍처의 가장 큰 특징이자 구현 목표인데, 섣부른 접근 전략으로 단순성은커녕 혼란과 관리 복잡성을 가중시킬 수 있다.

　◇프라이빗 클라우드는 통합 전략 아래 단계별 접근=이를 해결하기 위해선 프라이빗 클라우드의 구성 요소에 대한 이해와 단계별 접근 전략이 필요하다. 특히 단순하지만 중요한 원칙은 새로운 클라우드 서비스를 개발해 기존 시스템에 추가하는 것이 아니라, 기존 시스템을 하나씩 클라우드로 바꿔 나가는 것이다.

　기업이 프라이빗 클라우드 환경을 구축할 때 고려해야 할 것은 크게 세 가지다. △기존 애플리케이션과의 연동 등 기구축 시스템과 새 클라우드 서비스와의 조화 및 통합 전략 △핵심 업무와 지원 업무 두 가지 관점에서 클라우드 서비스 구축 △프라이빗 클라우드의 네 가지 계층 간의 독립성 확보가 그것이다. 따라서 프라이빗 클라우드의 4계층을 이해하는 것이 기업이 기존 정보 시스템을 포함하는 통합 전략을 수립하는 데 기본이 된다.

　가트너에 따르면 프라이빗 클라우드의 기능별 아키텍처는 4가지 계층으로 구성된다. 접근 관리, 서비스 관리, 자원 관리, 그리고 기반 자원(인프라)이다. 이론적으로 이 각각의 계층은 상호 독립적으로 운영되어야 한다. 각 계층에서 기술이나 솔루션을 바꿔도 전체 클라우드 서비스에는 영향을 주지 않아야 하기 때문이다. 클라우드 환경에서 공급업체를 자유롭게 바꿀 수 있고 유연한 구현을 위해 독립성은 반드시 보장되어야 한다.

　◇셀프서비스 포털의 접근 관리 계층=프라이빗 클라우드 서비스는 사용자에게 서비스에 기반한 인터페이스를 제공한다. 세부적으로 어떻게 구현돼 있는지는 인터페이스 아래 숨겨져 있다. 클라우드 관리자나 IT 엔지니어 등 역할에 따라 인터페이스 아래 기술 정보가 노출된다. 사용자들은 가상머신(VM) 등이 어떤 설정으로 어떻게 구성돼 있는지 신경 쓸 필요 없이 필요한 서비스를 이용하면 된다.

　잘 설계된 클라우드 아키텍처라면 기반 기술이 달라져도 사용자 인터페이스에 영향을 주어서는 안된다. 또 인터페이스 그 자체에 대해서도 새로운 기술이나 솔루션을 쉽게 구현할 수 있어야 한다.

　이 인터페이스들은 사용자가 직접 접속하는 셀프서비스 포털이거나 API 형태를 띈다. 서비스 수준을 유지하기 위한 정보를 제공하면서 동시에 새로 추가되는 서비스 수준 요구를 수용할 수 있는 양방향성을 전제로 한다. 서비스 수준은 성능뿐만 아니라 계측(미터링), 비용 정보 등을 포함한다.

　비용이나 사용량 정보 등이 제공되지 않는 셀프서비스 인터페이스라면 엄밀한 의미에서 클라우드 서비스라고 하기 어렵다. 이는 단지 유틸리티 공유 서비스를 조합해놓은 것에 불과하다. 그렇지만 여전히 많은 기업의 IT조직은 사용량 기반 과금(차지백)이나 서비스 가격 제시를 하지 않고 있다. 이는 퍼블릭 클라우드 서비스가 아니더라도 필요하며 프라이빗 클라우드에서는 최소한 사용량 계측, 비용 추산 또는 외부 서비스를 이용할 경우의 비용을 보여줄 수 있어야 한다. 물론 이 서비스 비용은 책정된 서비스 수준에 기반한다.

　접근 관리 계층에서는 당연히 계정 및 접근관리 기술이 필요하다. 사전 정의된 사용자 역할에 따라 서비스에 차등적으로 접근할 수 있어야 한다.

　◇가장 많은 일이 이뤄지는 서비스 관리 계층=서비스 관리 계층은 클라우드 서비스에서 가장 다양한 기술과 솔루션이 등장할 것으로 전망된다. SLA는 이 계층에서 사전 예측된 관리 프로세스, 즉 가용성 관리, 성능 관리 등 관리 수준을 결정할 뿐 아니라 제공되는 서비스 아키텍처를 설계하는 데에도 중요한 역할을 한다. 서비스 수준을 사전에 정립하지 않고 클라우드 서비스 아키텍처를 구성하는 것은 있을 수 없는 일이기 때문이다.

　실제로 SLA는 기업이 퍼블릭 클라우드 서비스 이용을 꺼리는 이유이기도 하다. 가트너는 지난해 12월 데이터센터 콘퍼런스에서 참석자를 대상으로 클라우드 컴퓨팅 설문조사를 실시했는데, 응답자 23%가 클라우드 서비스의 가시성을 보여주고 모니터링할 수 있는 툴이 없거나 기능이 부족하다고 답했다.

　기존 전통적인 서비스 관리에서는 IT 서비스가 어디서 운영되는지, 얼마나 많은 자원이 이용됐고 이 자원이 언제 확장 혹은 감축되어야 할지 결정하지 않는다. 이는 서비스 관리의 역할이 아니다. 하지만 프라이빗 클라우드 아키텍처에서 IT 자원은 SLA에 의한 서비스 수준을 충복시킬 수 있도록 자동 재배치, 할당되어야 하며 이는 서비스 관리의 자동화를 요구한다. 서비스 수준 평가와 지속적인 자원 공급 프로세스는 내부 및 외부 클라우드 서비스가 혼합된 하이브리드 환경에서 계속 수행되어야 한다.

　향후 클라우드 서비스가 확산되면 서비스 관리 계층에서 퍼블릭 클라우드와 프라이빗 클라우드의 경계를 넘나들며 자원 공급과 서비스 조합을 하게 된다. 클라우드 아키텍트와 관리자들이 가상 인프라스트럭처 위에서 드래그&드롭으로 서비스들을 설계하고 연결하며 구현할 수 있도록 해주는 서비스 설계 툴이 나올 것으로 보인다.

　서비스 관리 계층은 서비스 카탈로그, 서비스 모델, 서비스수준관리(SLM) 등으로 구성된다. 서비스 카탈로그는 사용자들에게 가격 정보를 포함해 사용 가능한 서비스들을 보여주며, 서비스 모델은 정책에 따른 서비스 분류를, SLM은 사용자가 카탈로그에서 선택할 수 있는 서비스 수준 옵션을 규정한다.

　이외에 △서비스 모니터링과 상호 관계를 제공하는 서비스 가용성과 성능 관리 △수요 이력 패턴을 분석하고 수요 변경 계획 등을 서비스 거버너에게 제안하는 서비스 수요 관리 △서비스의 실시간 최적화를 유지하기 위해 역동적인 구성관리 변경을 수행하는 서비스 구성관리 △계측, 사용량 기준 과금, 보고서를 포함하는 서비스회계관리 등이 서비스 관리 계층에서 수행된다.

　그리고 이러한 툴들은 서비스 거버너와 연결되어야 한다. 서비스 거버너는 서비스 관리 계층의 하위 계층인 자원 관리 계층과 인터페이스 하는 부분으로 사전 정의된 서비스 수준에 따라 서비스가 유연하게 제공될 수 있도록 자원을 자동으로 매핑, 공급하는 역할을 한다. 서비스 거버너가 없으면 자원 재할당 최적화 등은 수작업에 의해 이뤄질 수밖에 없다.

　◇인프라 세부 구성을 이해해야 하는 자원 계층=서비스 거버너 아래 계층은 자원 관리와 자원(기반인프라) 계층으로 구성된다.

　자원 관리 계층에서는 인프라스트럭처가 논리적 혹은 물리적인 실제 자원에 인터페이스하고 자원을 조합하는 데 필수인 리소스 에이전트와 컨트롤러로 구성된다. 자원 관리 계층의 윗 단계인 서비스 거버너에서 설정한 서비스 수준과 정책에 따라 자원 할당을 수행하는데, 서비스 거버너가 없을 경우 서비스 관리 계층 내 위치한 구성관리 기능을 통해 수작업으로 하게 된다.

　자원 관리 계층이 서비스 관리 계층과 다른 점은 사용자, 이 경우 관리자가 되는데 실제 인프라스트럭처에 대한 지식을 갖고 있어야 한다는 점이다. 다시 말해 아래에서 설명할 네 번째 자원 계층에서 자원 관리가 세부적으로 이뤄지지 않고 있을 경우 이 자원 관리 계층에서 물리적 자원과 가상 자원을 매핑해야 한다.

　서비스 카탈로그에서 요청되는 표준화된 서비스들을 위해 운용체계(OS)와 애플리케이션 이미지들은 이미지 저장소(리포지터리)로부터 추출되고, 사전 설정된 정책에 의거한 스토리지나 네트워크 자원들과 함께 구현된다. 자원 재할당은 VM웨어의 V센터, 아마존 EC2 API 등과 같은 제품에 인터페이스함으로써 수행된다.

　어떤 경우 기업 프라이빗 클라우드에서 리소스 거버너의 수준이 퍼블릭 클라우드보다 낮을 수 있다. 하지만 이럴 경우 실제 사용할 때 인프라 컴포넌트들의 기능이 부족해진다. 궁극적으로 성능과 사용량 데이터는 서비스 관리 계층이 설정한 정책대로 수집된다.

　가장 하부 구조가 되는 자원 계층은 자원의 공유 풀을 뜻한다. 하이퍼바이저나 파티션, 스토리지전용네트워크(SAN) 등 자원을 가상화하는 기능 혹은 기술들과, 서버나 디스크, 네트워크 장비 등 인프라 패브릭으로 구성된다. 순수 물리적 장비 및 기술 계층이라고 할 수 있다.

　가상화 기술 업체들이 곧 클라우드 업체는 아니며 클라우드 업체가 또한 가상화 업체는 아니다. 그러나 가상화에 의한 자원 공유 기술은 클라우드 아키텍처의 구성 요소로서 인정받을 것으로 보이며 가상화 기술에 의해 자원 공유 수준과 비용 혜택을 극대화할 수 있다.

　현재 발표된 가상화 기술은 상대적으로 성숙돼 있으며 프라이빗 클라우드 서비스를 구현하는 데 좋은 기반이 된다. 가상화 기술만으로 프라이빗 클라우드 서비스가 구현되지는 않지만 가상화는 자원을 전유 아닌 공유의 대상으로 문화를 바꾸고 있으며 기존 운영 프로세스를 바꿀 수 있는 촉진제가 되고 있다.

　◇핵심업무와 지원업무에 따라 관리 수준 달라=기업 프라이빗 클라우드는 다시 핵심 업무(production) 클라우드와 지원 업무(non-production) 클라우드로 구분해서 생각할 수 있다. 지원 업무 클라우드는 개발 테스트나 교육 및 훈련에 사용되는 컴퓨팅 환경을 예로 들 수 있다.

　핵심 업무 클라우드에서는 접근 관리·서비스 관리, 자원 관리와 기반 계층까지 모두 고도의 서비스 수준을 요구하고 서비스수준계약(SLA)을 지켜야 하지만 지원 업무 클라우드에서는 서비스 관리 레이어에서 다소 여유롭다. 핵심 업무 클라우드와 동일한 수준의 IT관리 프로세스나 서비스 수준이 필요한 것은 아니다.

　현재 다양한 솔루션 업체들이 프라이빗 클라우드 시장을 겨냥해 제품을 내놓고 있다. 프라이빗 클라우드를 구현하기 위해서 먼저 클라우드 서비스가 제공될 업무 대상사업자의 제안을 네 가지 계층 각각에 대입해 평가하는 것이 필요하다. “모든 클라우드 구현 시나리오가 완벽한 기술 스택을 마련할 필요는 없지만 기업의 핵심 업무 클라우드에서는 다르다”고 고베카 부사장은 지적했다.

　박현선기자 hspark@etnews.co.kr

　

가트너의 프라이빗 클라우드 서비스 계층 분류

　

　접근 관리 계층

　· 셀프서비스 포털

　· API

　· 서비스 사용자 관리

　· 계정 및 접근 관리

　

　서비스 관리 계층

　· 서비스 카탈로그

　· 서비스 모델

　· 서비스 구성관리

　· 서비스 수준 관리

　· 서비스 가용성과 성능 관리

　· 서비스 요구 관리

　· 서비스 회계 관리

　

　서비스 거버너

　

　자원 관리 계층

　· 리소스 거버너/구성관리

　 - 자원 할당

　 - 자원 풀링

　· 자원 현황 관리

　· 자원 성능 모니터링/사용량 측정

　· 자원 보안

　

　자원 계층(인프라스트럭처, 플랫폼 혹은 소프트웨어)

　· 구성요소 관리

　· 자원 풀

　· 가상 자원

　· 물리적 자원

　

　외부 관리 API

　· 즉각적인 배포 및 변경 등 관리 프로세스

　· 분석 및 용량 플래닝 툴 등