프라이빗 클라우드 구축 따라잡기

프라이빗 클라우드는 데이터센터 전반에 걸쳐 널려 있는 다양한 부류의 하드웨어 및 소프트웨어의 민첩성(agility)과 효율성을 높이기 위한 최근의 여러 시도 중 하나다. 즉 컴퓨트, 스토리지, 그리고 네트워크 리소스를 한 곳에 몰아 넣고 중앙 소프트웨어 컨트롤 포인트에서 이들을 한꺼번에 관리하려는 것이다.

아마도 공유 인프라스트럭처를 설계 및 운영해 본 경험이 가장 많은 것은 퍼블릭 클라우드 서비스 공급자 자신들일 것이다. 아마존, 구글, 마이크로소프트, 그리고 세일즈포스 등은 옛날 방식으로 데이터센터를 관리하지 못한다. 각 애플리케이션을 담당하는 정적이고 고정된 인프라스트럭처로는 감당할 수가 없다.

이들 몇몇 선구자들이 퍼블릭 클라우드 운영 경험을 통해 지금의 프라이빗 클라우드 모델이 탄생할 수 있었다.

클라우드의 소형화
어떤 이들은 퍼블릭 클라우드 제공업체들이 다양한 서비스를 소규모로 제공하기보다 대부분 제한적인 숫자의 서비스를 대규모로 제공하고 있다고 지적한다. 그렇다면 과연 퍼블릭 클라우드에서 차용한 모형이 모든 기업에 적합할까?

상황에 따라 다르다. 일정 규모 이상의 서버 가상화가 발생할 경우 퍼블릭 클라우드 모형은 유효하다. 이제 가상화는 너무나 만연해져 있어서 우리는 VM과 같은 리소스들이 확산되는 것을 너무나 자연스럽게 받아들이고 있다. 그러나 사실 이는 우리가 컴퓨팅 인프라스트럭처를 관리하는 방식에 있어서의 근원적인 변화를 시사한다.

이 차이는 가상화가 일정 정도 이상이 되면 나타난다. 예를 들어 수백 개의 피지컬 호스트(physical host)와 수천 개의 VM에 도달했을 때, 혹은 즉각적 만족을 원하는 여러 명의 각기 다른 테넌트(tenants)들의 요구를 들어줄 때 가상화 관리는 질적인 측면에서 달라지게 된다.

이 때부터는 무엇보다도 자원을 할당하고 영업 부문에 다시 비용을 할당하기 위해 프라이빗 클라우드 소프트웨어가 꼭 필요하다. 가능하다면 이해 관계자들이 자신의 자원을 공급하도록 하는 식으로 가상화 된 인프라스트럭처의 민첩성를 잘 이용해도 된다. 덧붙여 서버와 함께 스토리지 및 네트워크 리소스도 가상화 해야 할 것이다.

이 모든 것을 다 해낼 수 있는 소프트웨어를 이미 유칼립투스(Eucalyptus), VM웨어, 오픈스택, 마이크로소프트, 시트릭스 등등의 기업에서 내 놓은 바 있다. 이 다양한 프라이빗 클라우드 소프트웨어들은 그러나 데이터센터의 인프라스트럭처 소프트웨어를 전적으로 대체하기 위해 만들어진 것들은 아니다.

프라이빗 클라우드의 구성 요소
이제 여러 프라이빗 클라우드 요소들이 새로운 매니지먼트 레이어(management layer)를 형성하고 있다. 어려운 주문일지도 모르겠지만, 프라이빗 클라우드로 이전한다는 것이 반드시 모 아니면 도인 것은 아님을 기억해야 한다.

상당수의 하드웨어 및 소프트웨어 벤더들은 진짜 프라이빗 클라우드를 만들기 위해서는 새로운 하드웨어와 소프트웨어가 필요하다고 말하지만 사실 기존의 가상화 인프라스트럭처에 개별 클라우드 기능들을 하나하나 접목시킬 수도 있다.

컴퓨트. 가장 기본적으로 프라이빗 클라우드에서 컴퓨트 요소는 가상 매니지먼트 소프트웨어와 비슷한 일을 한다. 프로비전(provision), 디프로비전(deprovision), 시작, 정지, 중지, 클론(clone), 그리고 VM의 중앙 컨트롤 포인트로부터의 이동 등이 그것이다.

가장 큰 차이점이라면 프라이빗 클라우드의 목적은 가능한 한 넓은 서버 인프라스트럭처에서 관리가 가능하도록 하는 것이라는 점이다. 이는 대부분의 경우 다수의 하이퍼바이저 지원을 의미한다.

스토리지. 플랫폼 전반의 스토리지 관리는 10년 넘게 꿈으로 남아 있었다. 대부분 프라이빗 클라우드 플랫폼들은 다양한 데이터센터 스토리지 시스템 상에서 오브젝트 스토리지와 리플리케이션과 함께 블록 스토리지 및 스냅샷 매니지먼트 지원을 위해 힘써왔다. 물론 아직도 진행형이다. 프라이빗 클라우드 스토리지의 또 다른 핵심은 가상 서버와 가상 디스크 이미지의 효율적 운용이다.

네트워킹. 프라이빗 클라우드 소프트웨어가 최첨단 SDN(Software-Defined Networking) 세계로 확장되는 지점이다. 가상 포트(virtual ports) 제작, VMs 첨부, 가상 스위치 설정 등이 모두 가능하다.

더 큰 네트워크 인프라스트럭처 내부에서 프라이빗 네트워크를 만드는 것도 가능한데, 이는 특히 여러 명의 유저가 접근할 수 있는 큰 규모의 프라이빗 클라우드를 만들 때 꼭 필요하다. 통합 데이터 및 스토리지 네트워크로 가득한 현대의 데이터센터에서는 대역폭을 역동적으로 모으고 나눌 수 있는 능력이 매우 중요하다.

리소스 측정 및 비용 청구. 인프라스트럭처를 공유하고 나면 한 데 모인 컴퓨트, 스토리지 및 네트워킹 리소스들을 나누고 측정할 방법이 필요하다. 또 이들을 현업 부문에, 혹은 관련 이해 관계자들에게 청구할 방법도 있어야 한다. 그렇지 못할 경우 IT에서 청구 비용을 알아내기 위해 스프레드시트를 놓고 씨름을 하던가 부정확, 불공평 한 비용 분담을 감수하게 될 것이다.

셀프 서비스. 프라이빗 클라우드가 제공하는 가장 큰 효율성 중 하나는 아마도 이해 관계자들에게 ‘당신이 하시오’ 라고 말할 수 있게 되는 것일 것이다. 예를 들어 개발자들의 경우 셀프-서비스 포털을 사용해 자신들의 개발 및 테스트 환경을 설정, 재설정 할 수 있다.

현업 부문들에서도 애플리케이션을 ‘주문’ 및 설치 할 수 있는데 이 애플리케이션들은 IT가 개입하지 않고도 자동으로 제공된다. 물론 포털, 정책, 그리고 자동화라는 마법에는 시간과 노력이 들어간다. 또한 이해 관계자들의 선택의 폭도 좁아질 수 밖에 없을 것이다. 그렇지만 프로비저닝, 설정, 요구 사항 등에 시간을 덜 쏟아도 된다는 점에서 분명 매력적이다.

자동화와 통합(orchestration). 마법의 셀프-서비스 포털이 제대로 효과를 발휘하려면 자동화가 필요하다. 다시 말해 간단한 작업들을 하는 스크립트가 필요하다. 서버 프로비저닝, 공유 스토리지 설정, VLAN 네트워크 설정 등과 같은 작업 말이다.

통합 과정은 이 자동화 된 작업들을 선정된 특정 애플리케이션이나 서비스의 워크플로우에 통합시키는 것이다. 여기에는 게이트키퍼(gatekeeper)의 사인오프(signoffs)가 필요할 수도 있다. 예를 들어 개발자가 상당량의 리소스와 라이브 데이터베이스의 카피를 필요로 하는 애플리케이션을 테스트하려고 할 경우 워크플로우 소프트웨어가 자동으로 승인 요청을 보낸다.

애플리케이션 매니지먼트 및 모니터링. 프라이빗 클라우드는 애플리케이션 레이어 관리에까지 확장될 수 있다. 여기에는 애플리케이션 배치 및 설정 템플릿도 포함 되지만, 또한 내부 SLA 요건을 맞추기 위한 애플리케이션 퍼포먼스 관찰 및 보고도 포함된다. 경영진에게 꼭 필요한 안목을 제공해주는 계기판과 함께 말이다. 이러한 모니터링은 오토스케일링(autoscaling)을 촉진해 인력 개입 없이도 퍼포먼스 레벨이 일정 수준 유지되도록 돕는다.

보안. 공유 인프라스트럭처에서 다수의 테넌트를 분리해야 하기 때문에 보안은 매우 중요하며 또한 복잡한 과제다. 유저 그룹에 따라 다양한 레벨의 권한을 부여하는 아이덴티티 매니지먼트 시스템(identity management system)이 핵심 요소다. 이 시스템은 낱개의 액세스 컨트롤을 내부그룹 뿐 아니라 외부 유저들에게까지 확장시킬 수 있어야 한다(고객이나 파트너 등).

프라이빗 클라우드의 어떤 요소를 먼저 시행할지는 작업량에 따라 다르다. 만일 프라이빗 클라우드에 파트너들을 호스팅 하고 싶다면 가상 프라이빗 클라우드를 지원하기 위한 보안 및 네트워크 요소들이 가장 중요한 요소가 될 것이다. 리소스 분배 관리와 테스트가 우선순위라면 개발자들의 셀프-프로비전(그리고 자동화 및 통합)을 위한 포털이 1순위가 될 것이고 말이다.

반면, 비즈니스 부문들이 셀프-서비스 역량을 이용할 능력이나 생각이 없는 환경에서 풀-피처드(full-featured) 프라이빗 클라우드를 배치한다는 것은 엄청난 시간과 돈의 낭비가 될 것임에 분명하다.

많은 중견기업 또는 대기업들이 프라이빗 클라우드에서 이득을 얻을 수 있다. 어려운 부분은 모두를 프라이빗 클라우드의 규칙, 자동화 시스템의 정책에 적응시키는 일이다. 그 문제만 해결할 수 있다면 모든 것을 가상화 하고, 작업량의 우선 순위를 정하며 점진적으로 프라이빗 클라우드 기능을 늘려갈 수 있을 것이다. dl-ciokorea@foundryco.com