|
클라우드는 하드웨어, 소프트웨어, 서비스, 모바일 등 분야에 관계 없이 공통의 관심사가 된지 오래다. 실제로 하드웨어, 네트워크, 소프트웨어, 서비스 부문의 다국적 기업들은 이를 새로운 성장의 기회로 보고 자사의 기술 로드맵을 구체화하고 관련 제품 및 서비스 출시에 열을 올리고 있다. 엔터프라이즈 환경에서 클라우드를 고려할 때 어떤 기술적 요소들에 대한 이해가 필요한지, 도전 과제는 무엇이고 어떤 시나리오를 가지고 현실성 있게 접근할 수 있을 것인지에 대해 3회에 걸쳐 살펴본다. <편집자>
권희웅
펌킨네트웍스 개발이사
hukwon@pumpkinnet.com
두 번째 주제인 ‘클라우드 컴퓨팅 서버 및 네트워크 인프라 시나리오’에 대해 알아보겠다. 클라우드 컴퓨팅에 어떻게 접근할 것인가에 대해서는 사실 어느 관점에서 보는가에 따라 그 구성이 달라진다. 하드웨어 업체는 데이터센터 관점에서 이야기를 풀어갈 것이고, 소프트웨어 업계라면 개발과 운영 등의 관점에서 방향을 제시하고자 할 것이다.
그렇다면 무엇이 맞는 것일까. 사실 정답은 없다. 보는 관점이 틀리다고 지향점이 다른 것은 아니기 때문이다. 기업 입장에서는 현재 환경과 IT에 대한 투자 전략 등을 총체적으로 고려해 어디서부터 출발할 것인지를 정할 수 있는 혜안이 필요하다. 이번 연재에서는 과연 클라우드란 개념을 어떻게 현재의 인프라 상에 투영시켜 볼 수 있는지를 살펴볼 수 있는 시나리오를 소개한다.
경계의 벽을 넘어서는 아이디어
지난 호에 설명한 바와 같이 클라우드는 새로운 개념이라기 보다 각 영역 별로 꾸준히 발전한 기술들이 각각의 경계를 넘어 새로운 가능성을 만들어 내고 있는 것이라 보는 편이 맞다. 실제로 필자가 몸 담고 있는 펌킨네트웍스의 창업 아이템이 지금 말하는 클라우드와 상당히 밀접한 관계가 있을 정도로 클라우드는 새로운 기술이 아니다. 2000년대 초반 우리 회사는 콘체르토(Concerto)라는 솔루션을 개발했는데, 이 솔루션이 하는 일은 주어진 수 많은 서버들을 서비스 별로 클러스터화해 관리하는 것이다.
좀더 구체적으로 설명하자면 클러스터에 과부하가 발생하거나 효율성이 떨어진 클러스터가 발견될 경우 이들 클러스터의 서버들을 재조정해 최적의 효율을 낼 수 있도록 하며, 장애가 발생한 서버들을 다른 대체 서버로 역할을 이관시켜 주는 등의 기능을 가지고 있었다. 오늘 날 클라우드가 추구하는 바와 크게 다르지 않다.
당시 이 아이디어가 나오게 된 배경은 서로 다른 분야의 전문가들 간의 아이디어 융합에서 찾아볼 수 있다. 이에 대해 간단히 설명하겠다. 2000년대 초반 병렬 컴퓨팅(parallel computing) 분야의 전문가와 인공지능(Artificial intelligence) 분야의 전문가가 대용량 웹 서버를 만들어보자는 목표 아래 의기투합했다.
인터넷 혁명기를 맞아 기업들, 특히 인터넷 서비스 기업들은 그 어느 때보다 빠른 서버 인프라의 확장을 경험했다. 이런 기업들의 고민을 풀어 보고자 새로운 아이디어를 내게 된 것이다. 물론 초기에는 시행착오도 있었다. 슈퍼 컴퓨팅에서 사용하는 연산 방식을 적용하려다 보니 웹 서버 환경에는 잘 맞지 않았던 것이다. 아파치 웹 서버를 슈퍼컴퓨팅용 라이브러리인 MPI(Message Passing Interface)를 사용하도록 수정해 데모를 돌려본 결과 당초 목표로 했던 결과가 나오지 않자, 새로운 대안을 찾게 되었다. 오랜 고심 끝에 찾은 답은 바로 L4/7 스위칭 기술을 활용하는 것이었다.
L4~7 스위칭 기술 활용
L4/7 스위칭을 활용하는 방식은 딱 들어 맞았고, 콘체르토는 보다 높은 목표를 추구할 수 있게 됐다. 콘체르토가 지향하는 최종 목표는 모든 서버를 일종의 공기계(Machine)로 보고 인공지능 기술을 활용해 관리자의 개입 없이 워크로드를 최적의 상태로 운영할 수 있도록 배포하는 것이다. 다시 말해 운영체제만 설치된 머신으로 클러스터를 구성하고, 각 머신에 콘체르토를 배포하면 이들 머신은 중앙집중적인 관리·통제를 받게 된다. 여기서 말하는 관리 통제는 각 머신에 특정 역할(role)을 부여하는 것이다. 요즘 말로 하자면 워크로드를 중앙에서 각각의 머신에 나누어주는 것이라 말할 수 있다. 이를 아키텍처 차원에서 풀어보겠다.
| |
 |
|
|
<그림 1> 콘체르코 아키텍처
|
<그림 1>의 콘체르토 아키텍처는 크게 3가지의 요소로 구성돼 있다. 서버(Server), 컨트롤호스트(Control Host), 그리고 컨덕터(Conductor)가 그것이다. 서버는 콘체르토가 인스톨 되어, 원래 서버 본연의 목적인 웹, 메일 등과 같은 애플리케이션을 운용할 수 있는 환경과 상황에 따라 L4/L7스위칭 기능과 보안 기능 등을 로컬 매니저(Local Manager)를 통해 수행한다.
또한 시스템의 트래픽이나 부하 정보 등을 모니터링 하여 컨트롤 호스트로 전달하는 역할을 수행한다. 컨트롤 호스트는 클러스터 모니터링(Cluster Monitoring)과 클러스터 매니저(Cluster Manager)를 통해 각 서버의 상태를 모니터링하며, 전문가 시스템(Expert System)의 도움을 받아 다수의 클러스터들을 대상으로 상황에 적절하게 클러스터의 워크로드를 배분할 수 있도록, 각 서버의 로컬 매니저를 통해 서버의 역할을 재조정한다. 그리고 컨덕터는 UI 환경을 통해 클러스터 운영 상황에 대한 모니터링과 클러스터의 구성을 제어할 수 있는 방법을 사용자에게 제시한다.
웹 서버 대상으로 한 클라우드 컴퓨팅 시나리오
콘체르토의 기술 기반과 사상을 오늘 날 기업의 IT 인프라에 적용해 보면 일종의 클라우드 환경이 꾸려진다. 참고로 본 연재에서 소개하는 시나리오는 사내에 직접 구축하는(On-premise) 형태의 클라우드 구성에 대한 것으로 한정 짓도록 하겠다. 그리고 클러스터내의 머신의 운영체제는 리눅스, 윈도우, 솔라리스 세 종류로 하고 서버들에 할당되는 역할은 웹 서버, L4/L7 스위칭, 보안으로 하겠다.
콘체르토를 통한 클러스터 구성은 각 서버 마다 고유의 애플리케이션이 고정적으로 설치되어 있는 전통적인 스택 구성이 아니라 서버 인프라의 구성 자체를 동적으로 할 수 있다는 점에서 오늘날의 클라우드와 일맥상통하는 부문이 많다. 다만 당시에는 이 개념에 시대적 한계가 존재했다. 예를 들면, 머신에 역할을 나누어줄 때 이 역할의 범위가 제한적이었다. 다양한 업무용 애플리케이션까지 역할별로 머신에 배포할 수 있으려면 기업에서 쓰는 모든 애플리케이션을 머신에 미리 설치해야 하는 것이 당시 상황이다. 이는 클러스터를 공기계로 구성해 하나의 거대한 인프라로 사용하자는 본래의 취지를 벗어나는 것이다.
당시 콘체르토는 웹 서버라는 특정 역할에 초점을 맞춘 솔루션으로 시장 내에서 포지셔닝을 했다. 당시 콘체르토라는 기술적 토대를 가지고 시장에 제시한 것이 바로 그림 2와 같은 어댑티브 클러스터링(Adaptive Clustering)이다. 공기계로 구성된 클러스터를 인프라 삼아 웹 서버라는 단일 역할을 장애 여부나 과부하 정도에 따라 서비스를 이리 저리 옮겨 주는 것이다.
어댑티브 클러스터링 구성의 가장 큰 장점은 부하가 적절히 분산되는 가운데 서버 팜 전반의 자원 활용도(Utilization)를 극대화할 수 있다는 점이다. 최후의 유휴 서버 한 대가 남을 때까지 웹 서버의 운영에 필요한 자원이 쓰일 수 있다는 것이다. 그리고 이러한 특징은 관리자의 개입 없이 전문가 시스템(Expert System)을 통해 최적화된다. 예를 통해 실제 어떻게 기능하지를 살펴보자.
| |
 |
|
|
<그림 2> 어댑티브 클러스터링
|
<그림 2>에서 Cluster-A는 사용자 커뮤니티를 포함하고 있는 blog.portal.com을 운영하고 있으며, Cluster-B는 동영상 강의를 위주로 하는 stream.portal.com은 주로 퇴근 시간 이후의 저녁 시간대라고 가정해보자. 두 클러스터는 트래픽 사용 특성과 서버의 워크로드가 시간대에 따라 크게 차이가 난다고 가정을 해보자.
Blog.portal.com은 사용이 급증하는 피크 시간대가 낮에 있으며 이를 소화해내기 위해서는 최대 7대의 서버가 필요하며 반대로 저녁 시간대에는 사용이 감소하여 2대면 충분하다. 반대로 stream.portal.com은 낮 시간대에는 강의를 듣는 사용자들이 적어 3대가 필요하지만 퇴근시간 이후 집에서 동영상 강의를 시청하는 사용자들의 접속이 집중돼 이를 수용하기 위해서는 최대 8대의 서버가 필요하다.
기술적 제약 가상화로 해결
클러스터를 구축하기 위해서는 최대 피크를 기준으로 15대의 서버를 운영하여야 원활한 서비스를 할 수 있다. 하지만 서비스의 종류에 따라 서버의 사용률이 다르다는 점을 착안하면 이들 대수를 줄이더라도 동일한 서비스 품질을 만들어 낼 수 있다는 결론이 나온다. 전문가 시스템에 앞서 설명한 시나리오와 같은 지식을 입력해 어댑티브 클러스터링을 적용할 경우 10대의 서버들을 시스템의 로드나 상황에 맞추어 재배치를 함으로써 15대를 사용하는 것과 같은 효과를 얻을 수 있어 서버 운영측면에서 그 효용성을 최대화 할 수 있다.
하지만 앞서 예처럼 서버의 역할을 블로그 서버에서 스트리밍 서버를 전환하는 경우에는 몇 가지 문제가 발생할 수 있다. 콘체르토가 처음 등장했을 때만 해도 웹 서버 이외의 역할에 대한 배포는 기술적으로 불가능했다. 동일하거나 유사한 작업을 처리하는 애플리케이션 서버라면 상관 없겠지만 서비스 자체가 서로 판이하게 다를 경우, 한대의 서버에 모든 애플리케이션을 설치해야 하는 문제점을 안고 있었다. 또한 온디맨드(On-Demand)로 다른 서버 애플리케이션의 구성을 머신에 배포하는 것은 당시로써는 어려웠다. 그러던 것이 2010년 현재 당시의 기술적 제약은 가상화를 통해 풀어 낼 수 있는 상황으로 발전했다.
콘체르토의 사상을 뒷받침하는 기술적 진보가 이루어진 것이다. 가상화 기술을 사용하게 되면 기간계를 제외한 업무의 경우 애플리케이션 구성을 이미지화하여 공기계에 뿌려주는 것에 아무런 제약이 없다. 이는 소프트웨어 업계에서 이야기 하는 가상화를 통한 클라우드 접근과 크게 다르지 않다고 볼 수 있다.
2티어 아키텍처 기반 네트워크 클라우드 시나리오
앞서 설명은 어댑티브 클러스터링을 통한 전체적인 클러스터 운영관점에서 살펴봤다. 지금부터는 서버를 중심으로 어떻게 클러스터가 구성되는지 살펴본다. 콘체르토의 기본 설계철학은 L4/L7 스위치를 중심에 둔 구성이라기 보다는 서버를 중심에 두고, 이들을 어떻게 활용하는 것인가가 핵심 사항이었다. 따라서외부의 하드웨어 장비를 이용하는 것이 아닌, 필요에 따라 서버가 L4나 L7 스위치로서 작동을 하거나 보안 장비로 변신을 할 수도 있는 구조이다.
기업 네트워크 환경에서는 보통 보안, L4/7 스위칭과 서버 애플리케이션을 독립적인 장비와 독립적인 서버를 통해서 구성한다. 본 연재에서 소개하는 시나리오는 장비가 아닌 순수한 소프트웨어로 2티어 구성을 통해 네트워크 인프라를 구성한 것이다. 사실 이러한 접근은 과거 한 때 여러 기업들에 의해 주목 받기도 했다. 그러던 것이 요즘 가상화와 클라우드가 부각되면서 네트워크 및 보안을 단일 장비가 아니라 순수 소프트웨어 차원에서 구성하는 것에 관심이 많아지고 있다. 본 연재에서 소개하는 예제 구성 역시 소프트웨어 관점에서의 보안, 네트워크 기능에 대한 구성이라 보면 된다.
클러스터의 구성요소인 서버는 앞서 설명한 것처럼 리눅스, 윈도우, 솔라리스 등의 운영체제상에 서버 애플리케이션과 더불어 서버용 콘체르토가 탑재된다. 서버용 콘체르토의 기능으로는 L4 스위칭, L7 스위칭, 보안이 주된 기능이다. 그리고 이러한 기능들은 설정에 의해서 또는 상황에 따라 자동으로 그 역할이 변경될 수 있다.
2티어의 의미는 클러스터 내의 다수의 서버를 통해 유사한 기능이라도 나눠 처리할 수 있다는 의미다. 유입되는 트래픽을 한대의 서버에서 1차적으로 L4 스위칭을 통해 부하를 분산하며, 분산된 트래픽을 수신한 서버는 2차로 L7 스위칭을 적용해 프로세싱 워크로드에 대한 분산하는 구성이 가능하다. 또한 1차적으로 L4 스위칭을 수행해 분산된 트래픽을 수신한 서버에서 보안 기능을 분산 처리하면서 서버 애플리케이션을 운용할 수도 있다. 이러한 역할에 대한 작동은 앞서 설명했듯이 컨트롤 호스트에서 로컬 매니저를 통해 명령이 전달돼 이뤄진다. <그림 3>은 이러한 예를 보여주고 있다.
| |
 |
|
|
<그림 3> 2티어 기반 아키텍처
|
이러한 운영환경에서 <그림 4>와 같이 로드밸런서로 지정한 서버의 하드웨어 장애가 발생한 경우, 클러스터 내의 다른 서버로 그 역할을 이전시켜 서비스를 지속시킬 수 있다. 이차적인 장애가 발생한 경우, 또 다른 서버로 그 역할을 이전시켜 마지막 한대의 서버가 남아 있을 때까지 서비스를 지속할 수도 있다. 처리 경계를 제거해 네트워크와 관련한 처리와 서버 애플리케이션의 워크로드를 분산 처리할 수 있는 구조로서 서버를 좀더 유연하게 활용할 수 있도록 다중화된 안정장치를 제공할 수 있다. 최근 대형 서버를 도입해 가상화 환경에 다양한 업무를 통합하는 시도들이 많아지고 있는데, 이런 환경에서는 소프트웨어로 네트워크 인프라 구조를 짜는 것이 나름 합리적일 수 도 있다.
| |
 |
|
|
<그림 4> 캐스케이드 페일오버
|
보안 기능 역시 2티어로 구조화할 경우 얻을 수 있는 이익이 크다. 보안 기능을 2티어 구성할 경우 보안 체제를 논리적으로 다 계층화하고, 악의적인 침입으로 야기되는 문제의 확산을 최소화하는 데 효과적일 수 있기 때문이다.
클라우드 인프라의 핵심은 소프트웨어
일반적인 서버 인프라는 물리적으로 여러 대의 서버를 사용하지만, 클러스터를 운영하는 기업이나 이들을 통해 서비스를 받는 기업들의 입장에서는 고성능의 한대의 서버라고 바라본다는 관점을 가질 수 있다. L4/L7스위치는 가상 IP 주소를 통해 부하부산을 함으로써 네트워크 상의 다수의 서버를 한대처럼 보이게 한다.
현재까지는 이러한 관점에서 L4/L7 스위치가 이용돼, 현재는 AFE(Application Front-End)를 통해 서버의 워크로드를 감소시키는 추세에 이르고 있다. 좀더 나아가 생각해보면 앞서 설명한 기술들을 통해 서버들을 클러스터에 동적으로 배치하고, 네트워크와 서버의 워크로드를 다양한 형태로 분산시킨다면 최소의 비용으로 최적의 서버 및 네트워크 인프라를 구축할 수 있지 않을까?
최근 네트워크 업계에서는 L4/7 스위칭 장비에서 계층간 분리 작업에 한창이다. 장비는 고전적인 쓰임 그대로 제안하고, 소프트웨어는 가상화나 클라우드 구성을 고려 중인 기업에게 제안하기 위해서이다. 그리고 소프트웨어 기반 라우터나 네트워크 인터페이스 카드 등을 만들어 내는 업체들도 하나 둘 늘고 있다. 이런 상황들을 종합해 볼 때 클라우드를 현재 기업의 네트워크 인프라에 대입하기 위해 소프트웨어적인 유연성이 그 무엇보다 중요하다.
소프트웨어적인 관점에서 접근할 때 주의할 점이 있다. 바로 물리적 구성의 직관성 보장이 쉽지 않다는 것이다. 그래서 소프트웨어적으로 구성을 하려면 유연성과 함께 논리적 구성 전반에 대한 통찰력을 얻을 수 있는 관리에 대한 실질적 방안이 되어야 할 것이다. 다음 호에서는 유연성과 관리성이라는 두 가지 화두를 가지고 ‘어댑티브 엔터프라이즈 네트워크(Adaptive Enterprise Network)’라는 새로운 개념에 대해 설명한다. |
webmaster@datanet.co.kr
KT, ‘28GHz 기업전용 5G 네트워크’ 개발 성공
