클라우드는 하드웨어, 소프트웨어, 서비스, 모바일 등 분야에 관계 없이 공통의 관심사가 된지 오래다. 실제로 하드웨어, 네트워크, 소프트웨어, 서비스 부문의 다국적 기업들은 이를 새로운 성장의 기회로 보고 자사의 기술 로드맵을 구체화하고 관련 제품 및 서비스 출시에 열을 올리고 있다. 엔터프라이즈 환경에서 클라우드를 고려할 때 어떤 기술적 요소들에 대한 이해가 필요한지, 도전 과제는 무엇이고 어떤 시나리오를 가지고 현실성 있게 접근할 수 있을 것인지에 대해 3회에 걸쳐 살펴본다. <편집자>
권희웅
펌킨네트웍스 개발이사
hukwon@pumpkinnet.com
실제로 클라우드는 어느 정도 현실성이 있는가? 흔히 이야기 하는 퍼블릭 클라우드(Public Cloud)에 대한 그림은 명확하지만 기업들이 가장 관심을 가질 분야인 프라이빗 클라우드(Private Cloud)에 대해서는 아직 명쾌한 답을 내리기 힘들다. 그 이유는 과연 어떤 워크로드를 어떤 이유로 클라우드화할 것인지? 그리고 이를 통해 어떤 효과를 얻을 수 있는지에 대한 총체적이고 구체적인 답을 내기 위해서는 풀어야 할 숙제가 너무 많기 때문이다.
클라우드를 논할 때 빼놓을 수 없는 기술이 하나 있다. 바로 ‘가상화(Virtualization)’다. 기업 IT 인프라를 구성하는 모든 요소들은 이 가상화라는 공통 분모 아래 기술적 진보를 거듭해 나가고 있다. 그리고 이들 기술들이 모이게 되면 클라우드라는 총체적인 결과나 모습으로 나타나게 된다. 여기서 말하는 가상화 관련 핵심 구성 요소는 크게 서버, 네트워크, 워크로드(Workload)라는 세 가지 관점에서 나눠 볼 수 있다.
이를 좀더 세분화해 보면 서버는 프로세서와 운영체제의 관점에서, 네트워크는 L2와 L4~7 레이어 차원에서, 워크로드는 피크 타임과 성능 병목 등에 관계 없이 최적의 리소스를 가지고 배포 및 운영할 수 있도록 하기 위기 위한 방법론적인 차원에서 클라우드를 바라보는 관점을 뽑아 볼 수 있다.
그리고 이들 요소들을 마치 큰 그림의 퍼즐을 맞추듯 하나씩 연계해 보면 엔터프라이즈 환경에서 클라우드를 고려할 때 기반 기술 차원에서 어떤 검토를 실무적으로 해야 하는지에 대한 지표를 마련할 수 있다.
서버 부문에서 일고 있는 가상화 현주소
기업들은 업무별로 서버를 구성해 운영하는 것에 익숙하다. 하지만 데이터센터 상면 부족 및 에너지 절감 그리고 운영 관리 효율화 등의 이유로 시스템 대수를 줄여가기 위한 방안으로 통합에 주목하고 있다. 이를 가능케 하는 인자는 바로 가상화 기술이다. 사실 가상화는 지금까지 주로 서버 및 워크로드 통합을 위한 기술로 주목 받았다. 물리적인 서버의 대수를 줄이는 것이 주요 이유이자 목표였던 것이다. 하지만 이를 클라우드 관점에서 보면 이야기가 달라진다. 가상화 환경은 어떤 워크로드가 주어지던지 최적화된 리소스를 제공할 수 있어야 하고, 해당 워크로드는 고정적이라기 보다 상황에 따라 가변적으로 이동 및 대체될 수 있어야 한다.
엔지니어 입장에서 보면 이러한 조건을 만족시키기 위해 가장 시급한 현안은 바로 성능에 대한 보장이다. 어떤 상황에서건 즉각적으로 최적화된 성능을 보장할 수 있어야 실무자 입장에서 클라우드 상에 워크로드를 올려도 되겠다는 확신을 가질 수 있다.
사실 가상화는 처음부터 지금까지 성능으로부터 자유롭지 못하다. 그렇다면 서버 관점에서 볼 때 어떤 혁신이 2010년 현재 실제로 이루어지고 있을까? 이를 살펴보게 되면 우리는 클라우드 인프라 상에서 서버를 어떻게 바라보고 활용할 것인지에 대한 기술적 힌트를 얻을 수 있다.
멀티코어 등장
먼저 멀티코어의 등장을 살펴보겠다. 사실 초기 멀티코어 프로세서는 사용자들에게 가져다 줄 수 있는 이익이 그렇게 많지 않았다. 멀티코어 프로세서를 장착한다고 해도 무조건 성능이 향상되지 않기 때문이다. 그 이유 중 하나로 초기에는 소프트웨어들이 멀티코어를 충분히 지원하지 못했던 것을 꼽는다.
최근에는 멀티코어에 맞춰 소프트웨어의 성능이 지속적으로 개선되고 있다. 멀티코어 시장에서 이를 가장 잘 활용할 수 있는 응용 분야 중 하나로 가상화를 꼽는다. 전통적으로 소프트웨어적으로 풀이되던 가상화는 멀티코어의 등장 그리고 프로세서 업체들이 인텔 VT나 AMD-V 등 칩 차원에서 기능을 지원하면서 전환점을 맞이하고 있다. 특히 프로세서 차원의 기능 지원은 가상화에 대한 새로운 가치를 전파하는 촉매 역할을 하고 있다.
그 이유를 운영체제 관점에서 풀어 보자. 커널은 프로세서의 권한 모델(Privileged Model) 중 최고 레벨인 링(RING) 0에서 운영된다. 이 영역은 다른 영역으로부터 철저하게 보호되어 운영체제의 신뢰성과 안정성 그리고 보안을 유지한다.
일반적인 상황에서 가상화를 통해 호스트와 게스트 운영체제를 동시에 운영하면, 호스트는 최고 레벨에서 작동하지만 게스트의 커널은 최고 레벨이 아닌 그 아래 레벨인 링 1에서 작동해야 하기 때문에 구현상의 복잡함과 더불어 오버헤드를 유발시킨다. 이러한 문제를 해결하기 위해 프로세서 레벨에서 가상의 권한 레벨인 링 -1을 둔다. 이렇게 해서 호스트는 링 -1에서 그리고 게스트는 링 0에서 작동하게 할 수 있다. 자연스럽게 게스트를 운영할 수 있도록 하는 것이다.
메모리 관리 측면에서도 오버헤드 이슈가 있다. 호스트의 커널이 실제로 메모리를 관리하며, 게스트는 호스트에게 서비스를 받는데, 이 과정에서 소프트웨어적으로 복잡한 페이징 변환 작업을 처리하다 보니 오버헤드가 상당하다. 최근 프로세서들은 이러한 변환 과정을 하드웨어적으로 처리해 최적의 성능을 이끌어 낼 수 있도록 진화하고 있다.
운영체제 관점에서 지원하는 가상화
운영체제 관점에서 지원하는 가상화 방식 역시 성능이라는 고지를 넘어서기 위한 시도들이 많았다. 이를 가장 최근의 추이에 맞춰 한 마디로 압축해 보면 ‘하이브리드’라고 말할 수 있다. 흔히 가상화 방식은 전가상화(Full Virtualiza tion)와 파라가상화(Para Virtualization)로 나뉜다. 이 두 방식은 프리빌리지드 오퍼레이션(Privileged operation)을 어떻게 수행하느냐에 따라 그 특징을 설명할 수 있다.
전가상화는 게스트가 프리빌리지드 오퍼레이션을 수행하면 이를 예외처리(Exception Handling)를 통해 호스트에게 위임한다. 이 방식은 성능은 좋지 않지만, 게스트 운영체제의 코드를 변경하지 않아도 되기 때문에 현존하는 대다수의 운영체제를 소화할 수 있다는 장점이 있다. 반면에 파라가상화는 운영체제를 수정하여 프리빌리지드 오퍼레이션들에 대한 서비스를 호스트에서 하이퍼콜(hyper call)이라는 API 형태로 제공하며, 게스트 커널의 프리빌리지드 오퍼레이션들은 하이퍼콜을 이용하도록 수정돼야 한다.
결국, 이를 통해 얻고자 하는 것은 성능이다. 하지만 게스트 운영체제의 커널을 수정해야 하는 문제점을 가져 리눅스와 같은 공개된 운영체제는 이 방식을 쉽게 채택할 수 있으나, 윈도우와 같이 코드가 공개되지 않은 운영체제는 제조사에서 이를 지원하지 않는 경우 사용할 수 없다는 단점을 가진다.
전가상화의 방식의 대표적 예는 VM웨어이고 파라가상화의 경우는 시트릭스 젠(Zen)을 생각하면 된다. 현시점에서는 이러한 두 가지 방식이 명확히 구분된다기 보다, 각 방식의 장점을 추하기 위해 하이브리드 형태를 취해 성능과 운영체제에 대한 호환성을 높여가는 추세라고 볼 수 있다.
이 같은 프로세서와 운영체제의 변화는 결국 가상 환경에서의 속도와 성능 이 두 가지 태생적 이슈를 극복하기 위한 노력이라 봐야 한다. 다만 서버 가상화를 넘어 클라우드까지 생각한다면 이 두 기술만으로는 인프라 구성에 제약과 한계가 있다. 서버 가상화와 달리 클라우드는 IT 인프라 전체가 유기적으로 가상 또는 실제의 환경 속에서 상호작용해야 한다. 따라서 서버뿐 아니라 네트워크 부문에서 어떻게 클라우드와 가상화를 바라보고 대응해야 할지를 꼼꼼히 따져 봐야 한다.
클라우드, 가상화, 그리고 네트워크 인프라
서버의 구성이 변하면 자연히 네트워크 인프라를 구성하는 것들 역시 이에 따라 움직여야 한다. 네트워크 장비 개발자의 눈으로 보면 최근 가상화 및 클라우드 관련 업체들이 제시하는 구성안이 현실적으로 받아들여지기 위해서는 서버와 마찬가지로 성능 이슈가 해결돼야 한다. 네트워크 부문의 성능은 서버 못지 않게 여러 요소들이 관여돼 있어 실제 가상 네트워크 인프라를 구성할 때 점검해야 할 부문이 꽤 된다. 크게 L2 레이어와 L4~L7 레이어로 나눠 설명할 수 있는데, 먼제 L2의 경우를 살펴보자.
L2 레이어와 관련해 가상 환경의 가장 큰 고민은 I/O이다. 이는 스토리지쪽도 마찬가지일 것이다. 이에 대한 해결책으로 업계가 머리를 맞대어 내놓은 방안은 멀티큐이다. 과거에는 NIC(Network Interface Card) 하나를 시스템에 꼽으면 핸들링 할 수 있는 인터럽트는 하나였다. 즉, 여러 개의 코어를 가진 프로세서가 꼽혀 있다 해도 요청되는 인터럽트는 자신이 바라보고 있는 프로세서 한 개에게만 전달되여 충분한 성능을 내지 못했다.
하지만 멀티큐가 지원되는 경우는 이야기가 다르다. NIC는 물리적으로 한 장이지만 독립적인 큐를 가지고 있으며, 각각의 큐는 서로 다른 프로세서들과 인터럽트를 연결해 분산 처리가 가능하며, 가상화 관점에서 이들은 각각의 프로세서에서 작동하는 게스트 운영체제에게 독립적인 네트워크 I/O 채널을 제공할 수 있어 가상 머신 운영시 높은 성능을 이끌어 낼 수 있다.
이러한 흐름은 운영체제 커널에도 이미 적용됐거나 새로이 반영되고 있다. 리눅스 커널을 예로 들면 기존에 네트워크 I/O에 대해 NAPI(New API)라는 기법을 채용했다. 이 기법은 네트워크 I/O에 대한 소프트웨어적인 오버헤드를 줄이는 방법으로 최근 멀티코어 프로세서와도 좋은 궁합을 보여주고 있으며, 가상화를 적용했을 때에도 성능상의 큰 이득을 가져다 준다.
최근 이와 같은 방식을 블럭계층(block layer)으로 확대해 리눅스 커널 2.6.32부터 적용했다. 이는 디스크 I/O와 같은 영역도 성능 확장을 기대할 수 있다는 것을 의미한다. 결과적으로 이러한 기술들을 통해 운영체제가 각각의 가상 머신에 전용의 네트워크 I/O나 디스크 I/O를 연계할 수 있는 기반을 마련해 주는 형태로 발전하고 있다고 볼 수 있다.
L2/3 가상 환경
L2/3 스위칭 시장에서 최근 10Gbps급 스위칭 장비들의 사용이 확산되고 있으며, 이 영역도 가상화와 관련한 이슈들이 결부돼 있다. 많은 사람들이 10Gbps급의 스위칭 장비들이 많이 보급될까라는 의문들을 제기하는 것 같다. 하지만 한대의 서버에 다수의 가상머신이 작동하는 환경을 상상해 보자.
앞서 설명했듯이 한대의 물리적인 서버에 수십 개의 가상머신이 올라가 있다면, 이들 트래픽을 효과적으로 처리하기 위해서는 과연 서버에 몇 개의 NIC를 설치해야 할까? 사실 이러한 이슈의 해답은 앞서 설명했던 멀티큐를 지원하는 10Gbps급 랜카드를 설치해 10Gbps급의 스위치와 연결하면 연결의 복잡성을 해결하고, 관리를 쉽게 할 수 있으며 성능도 보장할 수 있어 가장 좋은 해결책 중 하나지 않을까 하는 생각이 든다.
이상과 같은 환경에서 다수의 가상머신은 네트워크 I/O를 통해 물리적인 한대의 서버 내에서도 데이터를 주고 받기도 하며, 외부와도 통신을 한다. 사실 이러한 내 외부 통신은 호스트 커널을 통해 소프트웨어적으로 이뤄지기 때문에 스위칭, 라우팅, 보안 정책 적용 등에 있어 상당한 유연성을 가지지만 큰 오버헤드를 가진다는 단점이 있다.
이러한 단점을 극복하기 위해 시스코나 HP 등의 다국적 기업에서 VEPA(Virtual Ethernet Port Aggregation)와 OVF(Open Virtualization Format)와 같은 표준안을 만들어 가고 있는 것도 주목할 만한 사실이다. 이들의 목적은 물리적인 서버 내부의 가상머신들의 네트워크 I/O를 모두 VEPA가 지원되는 스위치를 통해 이뤄지도록 해, 라우팅이나 보안 정책 등은 기존과 같이 외부의 전용 장비를 통해서 이뤄지도록 한다는 취지다.
실제 구현은 VLAN(Virtual LAN)과 유사하며, 각 가상머신에 대해 태크(tag)를 부여해 사용하는 방식이다. 이는 가상머신의 성능상 문제를 해결할 뿐만 아니라 네트워크의 운영 관점에서 전체 인프라를 일관성 있게 관리할 수 있다는 장점도 가지고 있다.
L4의 화두, ‘로드랠런싱’
L4 레이어의 최대 화두는 로드밸런싱(Load Balancing)이다. 물리적으로 독립된 서버들 사이의 로드밸런싱이 전통적인 방식이었다면, 가상화 및 클라우드 구성 상에서는 물리적인 면뿐 아니라 논리적으로도 다이나믹하게 스위칭을 할 수 있는 구성이 뒷받침돼야 한다. 단, 이때 전제가 되어야 하는 것이 있다. 두 대의 실제 서버를 놓고 로드밸런싱을 할 경우 L4 스위치는 이 두 대만 바라보면 된다. 하지만 고성능, 고집적 단일 머신 상에 가상 머신들을 올려 놓을 경우 과거에는 신경쓰지 않았던 리소스 및 전력 사용 등까지도 염두에 둬야 한다.
이는 로드밸런싱의 목표를 부하 분산 그 자체로 한정 짖는 것이 아니라 워크로드에 최적화해 서버의 자원 활용도를 극대화 시켜주는 것까지 확대해야 한다는 말이다. 실제로 이와 같은 사상을 가지고 제품을 출시한 스위치 업체도 있다. 이 업체의 경우 전원 관련 프로토콜을 이용해 L4 스위치와 서버들을 연결하고, 현재 쓰이는 트래픽을 감안해 서버의 전원을 켜거나 끄는 기능을 제공한다. 로드밸런싱을 리소스 및 전력 사용 최적화의 관점에서 보고 이를 기술적으로 풀어낸 것이다.
인프라 전체 관점에서 살펴야
L7 성능은 클라우드와 가상화 환경에서 최대 관심사다. 다만 여기서 말하는 성능은 앞서 소개한 L2와 L4에서의 것과 다른 의미다. 기업의 IT 환경의 복잡도가 증가하면서 언제부터인가 성능에 대한 화두가 하드웨어, 소프트웨어 할 것 없이 대두되기 시작했다. 기업들은 최종 사용자가 느린 응답을 받았을 때 이에 대한 원인을 보고 싶어 한다. 흔히 이야기하는 비즈니스 트랜잭션이 일어났을 때 어느 지점에서 병목 현상이 발생하는 지를 알고 해결하고 싶어하는 것이다.
하지만 오늘날 기업 IT 환경에서 일어나는 각 워크로드 별 트랜잭션은 웹, 미들웨어, 데이터베이스, 서버, 네트워크 등 수 많은 계층을 거치기 때문에 응답 속도가 느려지거나, 먹통이 됐을 때 원인을 찾아내기가 어렵다. 이에 대한 답 역시 각 업계마다 각자의 입장에서 내놓고 있다.
가령 네트워크 업계에서는 ADC(Application Delivery Controller)를 밀어 붙여왔다. AFE(Application Front End), 웹 가속, 웹 압축, SSL 가속 등을 포괄해 L7 계층에서 애플리케이션 딜리버리를 최적화하기 위한 움직임을 보여온 것이다. 소프트웨어 업계의 경우 APM(Application Perfor mance Management)를 필두로 몇 년 전부터는 비즈니스 트랜잭션 모니터링 솔루션들이 기업들의 선택을 받아오고 있다.
향후 클라우드가 기업의 전통적인 IT 환경에 접목되게 되면 비즈니스 관점에서의 성능에 대한 통찰력을 얻고자 하는 요구들은 더욱 커질 것이다. 그리고 이런 시기가 되면 네트워크, 소프트웨어 등 분야를 가릴 것 없이 모든 관리 및 점검 대상 요소들이 유기적으로 잘 이어져, 돌아가고 있는 지를 볼 수 있어야 할 것이다. 즉, 현재 다양한 분야의 업체들이 한 발씩 담그고 있는 성능은 클라우드 환경에서는 단순히 네트워크, 서버, 소프트웨어, 서비스를 개별적으로 볼 것이 아니라 인프라 전체의 관점에서 어떻게 각 워크로드의 트랜잭션 흐름을 어떻게 최적화해 관리할 수 있을 것인지에 대한 궁극적 솔루션이 필요할 것이다.
워크로드와 트랜젝션에 더 큰 관심
최근 기업들은 시스템보다는 이 위에 올라가는 워크로드와 트랜잭션에 더 관심을 보이고 있다. 기업 입장에서는 어떤 솔루션이나 서버를 쓰냐보다 사실 어떤 업무를 어떻게 흐르도록 할 것인지 그리고 얼마나 안정적이고 신뢰성 높게 운영할 수 있는 지가 더 큰 관심사다. IT 업계가 기업에 클라우드를 제안하는 이유도 따지고 보면 같은 맥락이다.
구글처럼 스스로 다 만들고 알아서 운영할 것이 아니라면 IT 인프라와 시스템 자체에 대해 신경쓰지 말고 비즈니스에 더 집중하라는 메시지를 IT 업계는 기업들에게 던지고 있다. 즉, 기업의 눈길을 받는 클라우드의 핵심은 곧 워크로드에 최적화된 유연한 IT 환경을 뜻한다.
그렇다면 이를 어떻게 구현할 것인가? 2010년 현재 프라이빗 클라우드 구현에 대해서는 업계마다 서로 다른 각도에서 접근 방식을 제안하고 있다. 물론 기술적으로 보면 큰 차이가 없지만 용어나 사상 등의 잣대를 대보면 차이가 난다. 네트워크 인프라 기술을 연구하는 개발자 입장에서 기업에서의 클라우드 시나리오는 상상 이상으로 많을 수 있다고 본다. 쉽게 말해 정답이 있다기 보다 상황과 현황에 가장 이상적인 시나리오를 끌어 낼 수 있는 가능성이 많다는 이야기다.
현실성 검증 해봐야
한 가지 예를 하나 들어보자면 특정 워크로드를 운영하는 서버 이미지를 스냅샷으로 떠서 각 워크로드에 따른 피크타임 등에 대한 주요 지표를 패턴화해 가상화된 IT 인프라 상에 필요 리소스 요구 수준에 맞게 옮겨 가는 것도 생각해 볼 수 있다. 이 경우 워크로드는 특정 시스템에 정적으로 고정돼 있다기 보다 필요에 따라 여기저기 옮겨질 수 있는 동적인 상태라 보면 된다.
이 시나리오의 주인공은 트랜잭션을 모니터링하고, 통제하는 로드밸런싱이다. 성능과 용량 그리고 수가 정해진 서버들을 놓고 로드밸런싱 장치가 패턴에 기초해 피크 타임에는 특정 워크로드를 5대의 서버에서 돌리고 한가한 시간 대에는 2대로 줄이는 등의 조정을 할 수 있다. 서버나 운영체제 업체들이 말하는 시나리오와 비슷해 보이지만 접근 방식은 조금 다르다.
앞서 언급한 것처럼 클라우드와 가상화는 상상 이상으로 다양한 시나리오가 나올 수 있다. 다만 현실적으로 구현할 때 기술적인 이슈는 분명 존재한다. 이러한 사례를 실제 구현하려면 소프트웨어 라이선스, IP 자원 등에 대한 복합적인 문제가 일어날 수 있다. 또한 패턴 분석 등을 통해 대응하는 것이 실제 얼마나 현실성이 있는 지도 검증을 해봐야 한다. 즉 해봐야 안다는 말이다. 그렇다고 남들이 다 해볼 때까지 기다릴 수는 없는 일 아닌가.
다음에는 현재 필자가 몸담고 있는 펌킨네트웍스의 창업 아이디어이자 원천 기술이기도 한 콘체르토의 기본적인 사상과 기술을 가지고 오늘날 이야기하는 엔터프라이즈 클라우드 시나리오를 어떻게 구현해 볼 수 있는지에 대해 소개하겠다.
