우리나라에는 프라이빗(Private Cloud)에 대한 2가지 큰 오해가 있다.

첫 번째는 VDI 또는 단순 서버가상화를 클라우드로 인식하는 것이고, 두 번째는 퍼블릭 클라우드(Public Cloud)와 프라이빗 클라우드의 운영방식이 똑같다고 생각하는 것이다.

이로 인해 한 쪽에서는 클라우드를 도입해 봐야 별거 없다는 인식이 쌓이고 다른 쪽에서는 비싼 돈을 지불해 클라우드를 도입했지만, 기존 레거시처럼 운영하게 돼 업무의 차별성을 가져가지 못한다.

국내에서 프라이빗 클라우드를 구축한다고 하면, 제일 먼저 오픈스택(OpenStack) 또는 VM웨어를 떠올린다.

이유는 클라우드를 통합 인프라로 인식하지 않고 가상화로 인식하기 때문이다.

클라우드 컨설팅 자료를 보면 거의 대부분 ‘유닉스 투 리눅스(Unix to Linux)’를 하라고 돼 있다.

그런데, 대다수의 컨설팅 자료는 다양한 환경의 클라우드를 구축해 보았거나 운영해 본 고수의 냄새가 전혀 나지 않는다.

심지어는 동작할 수 없는 아키텍처들도 종종 본다. 클라우드 전문가 자체가 매우 부족하기에 고객사 이름만 다르고 결론은 같은 결과 보고서가 넘쳐나는 것은 어쩌면 당연하다.

문제는 말만 잘하는 일부 벤더의 조언과 컨설팅 결과물에 의지해 클라우드 항해를 떠났다가 제대로 풍랑을 만나 좌초된 클라우드 사업들이 많다는 것이다.

그렇다면 어떤 방식으로 접근해야 프라이빗 클라우드를 구성할 수 있을까?

만병통치약과 같은 획일화된 디자인은 존재할 수 없다. 하지만 근간이 되는 표준 아키텍처와 설계 원칙은 잡을 수 있다.

이를 위한 첫 단계는 클라우드를 개별 솔루션이 아닌 통합인프라스트럭처, 즉 SDDC(Software Defined Data Center) 기반으로 상호 연동되게 종합 설계해야 한다.

모두가 알만한 실례를 들면, 시장에 높은 인지도가 있는 SDC와 SDN 벤더 간 경쟁으로 인해 솔루션 간 호환성을 정책적으로 보장하지 않는다.

각 벤더들의 장점을 비교 검토해 경쟁을 통해 최적의 솔루션들이라 믿고 도입했지만 장애가 생기면 어떻게 될까?

서로 간 호환성을 이유로 ‘TAC 서비스’를 받을 수 없다.

이같은 일들은 두 벤더만 해당되는 것이 아니라 종종 발생한다.

이러한 이유로 사업을 낼 때 벤더 간 호환성을 받아오라고 하면 기술적 검증없이 사업 기간에 서둘러서 호환성 검증 문서를 제출하는 곳도 자주 목격된다.

그렇게 되면, 피해보는 곳은 고객사일 수밖에 없다.

클라우드 프로젝트를 진행하다가 중간에 업체가 바뀐다거나 의도한 대로 사용 못하고 울며 겨자먹기로 아주 기본 기능만 어쩔 수 없이 사용하는 고객사도 많다.

최근 한풀 꺾이고는 있지만 한때 ‘오픈스택’이 마치 클라우드의 완성판인 듯한 메시지가 시장에 많이 흘러나왔다.

그런데 기술적으로 살펴보면 ‘오픈스택’은 그냥 ‘오픈스택’이다. 서버가상화의 일부 기능 확장판이다.

‘오픈스택’을 스토리지와 붙이려면 ‘씬더(Cinder)’라는 모듈을 활용한다. 그러면 스토리지의 모든 정보를 볼 수 있을까?

절대 아니다.

스토리지에서 ‘오픈스택’용으로 할당한 공간만큼만 사용할 수 있는 것이지, 스토리지 상태 정보나 디스크 정보 등 스토리지 운영에 필수적인 정보는 개별 스토리지에 들어가서 확인해야 한다.

네트워크도 마찬가지다.

‘오픈스택’은 오픈스택대로 운영하고, 네트워크와 스토리지는 따로 운영을 해야 한다.

SDDC 기반으로 구성해 서버, 스토리지, 네트워크 정보를 복합적으로 분석하고 확인할 수 있는 별도의 운영관리 툴이 필요하다.

퍼블릭 클라우드에서는 CSP에서 제공하는 API에 맞춰 사용자 포털과 관리자 포털을 만든다.

인프라스트럭처와 안정성은 CSP에서 제공하는 것으로 이용자 입장에서는 전혀 고려대상이 아니다.

그런데, 문제는 프라이빗 클라우드도 퍼블릭 클라우드와 같은 방식으로 접근하는 것이다.

퍼블릭 클라우드에서는 사용자 포털을 통해 원하는 만큼 서버, 스토리지, 네트워크 자원을 요청하면 즉시적으로 CSP 내부에 있는 운영관리플랫폼을 통해 가용성 확보 및 정합성을 체크해 인프라스트럭처를 제공하지만 프라이빗 클라우드에서는 이 모든 것을 고객사에서 구현해야 한다.

현재 대부분 프라이빗 클라우드는 SDC, SDN, SDS를 구성하고 사용자 포털과 운영자 포털로 구성돼 있다.

프라이빗 클라우드는 고객사가 보유한 서버, 스토리지, 네트워크를 유기적으로 연동해 안정적이면서도 즉시적인 서비스를 제공해야 하는 것인데, 현재 대부분의 클라우드 포털은 서버, 스토리지, 네트워크가 어떤 구조로 연동돼 있는지 구성도조차 제공하지 못한다.

퍼블릭 클라우드에서는 해당 정보가 중요하지 않겠지만, 프라이빗 클라우드에서는 매우 중요하다. 

VM이 어느 물리서버에 존재하고 해당 물리서버는 어느 ‘리프 스위치(Leaf Switch)’의 몇 번 포트에 연결돼 있으며, 스토리지는 얼마나 할당돼 있고, ‘VM to VM’ 경로는 어떻게 되는지 정보를 직관적으로 파악할 수 있어야 즉시적이면서도 안정적인 서비스 더 나아가 손쉬운 장애 진단과 트러블슈팅을 할 수 있다.

즉, 겉모습만 퍼블릭 클라우드와 같이 해야 하는 것이 아니라 ‘인프라스트럭처(Infrastructure) 아키텍처’도 퍼블릭 클라우드와 같은 형태여야 한다.

사용자 중심 포털과 인프라스트럭처(SDC, SDN, SDS) 사이에 운영관리플랫폼이 존재해 퍼블릭 클라우드와 같이 API로 자원을 요청하면, 운영 관리 플랫폼에서 정합성 체크 후 각 서버, 스토리지, 네트워크를 안정적으로 제공할 수 있어야 한다.

서버, 스토리지, 네트워크 자원의 상호 연결 구조도 제대로 파악 못하고, 어떤 자원이 어디에서 동작하고 이동하는지 전혀 파악 안되는 프라이빗 클라우드 환경에서는 퍼블릭 클라우드와 같은 프라이빗 클라우드는 사실상 불가능하다.

과거 서버가상화와 VDI를 클라우드라 칭했던 시절 클라우드를 도입해봐야 별 쓸모없다고 회자되던 것과 같이, SDDC 기반 클라우드를 도입해 봐야 더 복잡하고 힘들어진다는 인식이 확산될까 매우 우려스럽다.

최근 ‘하이브리드 클라우드(Hybrid Cloud)’가 수면 위로 빠르게 올라오면서 외산 클라우드 운영 플랫폼들이 하나 둘씩 베일을 벗으며 시장에 진출하고 있다.

하이브리드 클라우드가 궁극적으로는 나의 서비스가 퍼블릭 클라우드에 존재하든 프라이빗 클라우드에 존재하든 상관없이 하나의 관리 툴로 서비스의 연속성과 안정성 그리고 비용 효율성을 제공하는 아키텍처로 발전할 것이라는 것엔 모두가 동의한다.

외산 솔루션은 사용자 포털, 관리자 포털에 집중하기 보다는 이런 하이브리드 클라우드 환경에서 단순 서버 가상화가 아닌 서버, 스토리지, 네트워크를 얼마나 유기적으로 연동해 정보를 동기화하고 안정적으로 운영할 수 있는지에 집중하고 있다.

이는 인프라스트럭처 영역 중 핵심분야이기 때문에 인프라 전문가들에 의해 고민되고 완성돼야 한다.

그런데 우리나라 대부분 프라이빗 클라우드 사업은 운영관리 플랫폼없이 포털에서 직접 장비로 API 호출하도록 구성한다.

필수적으로 인프라 전문 영역인 곳을 인프라 전문가가 없는 개발사에게 저가로 단기간에 개발시킨다.

그래서 어려움을 겪고 있는 프라이빗 클라우드 구축 사례는 우리 주변에서 쉽게 접할 수 있다. 

이제는 프라이빗 클라우드와 하이브리드 클라우드가 본격화되는 시기다.

기존에 범하던 우를 동일하게 겪지 않고 시대의 준비를 철저하게 할 수 있었으면 하는 바램을 가져본다.

블루오션을 마치 레드오션처럼 만들고 있는 현재의 시장 분위기 속에서 벗어나 클라우드 기술 강국이 되길 소망한다.

다음 시간에는 유즈 케이스(Use Case)를 기반으로 ‘멀티 벤더, 멀티-DC, 하이브리드 클라우드(Multi-Vendor, Multi-DC, Hybrid Cloud) 운영 필수 요소와 구현’에 대해 알아보고자 한다.

<서영석 나임네트웍스 대표>david@naimnetworks.com