[칼럼] 왜 클리커일까요?

데이터센터를 이야기할 때 클라우드를 언급하지 않을 수 없는 시대가 되었습니다.

다만, 이야기의 중심이 이제는 인프라가 아니라 플랫폼 혹은 애플리케이션으로 많이 이동한 것 같은데요. 다들 어떻게 생각하시나요?

이러한 흐름은 최근에 많이 언급되고 있는 바이모달 IT(Bi-Modal IT)라는 단어에서도 쉽게 업계의 흐름을 읽을 수 있는데요, 효율성을 중시하는 전통적인 IT 운영 방식과, 속도를 중요시하는 Agile IT 혹은 클라우드 네이티브 IT가 어우러진 것이 바로 현재의 IT 운영 모델이라는 것입니다. 특히, 기업마다 서로 다른 IT환경에서 애플리케이션이 어떻게 개발/운영되는지 Bi-Modal IT 모델을 통해 언급하고 있습니다.

클리커(CliQr)는 이러한 요구 사항을 깔끔하게 해결할 수 있는 솔루션으로 지난 4월 시스코의 새로운 가족이 되어 뜨거운 관심을 한 몸에 받고 있습니다. 특히 시스코 ACI의 에코 파트너로 ACI 매력의 중심에 있는 애플리케이션 기반 네트워크 서비스 개념을 완벽하게 연동시킨 툴입니다.

클리커와 ACI는 공통적으로 애플리케이션 프로파일이라는 용어를 사용하고 있으며, 이 애플리케이션 프로파일이 다양한 클라우드 인프라를 지원하는 핵심이 됩니다.

Why CliQr?

왜 클리커에 관심이 모아지는지, 클리커의 뛰어난 장점들을 함께 살펴보도록 하겠습니다.

첫째, 클라우드 환경을 가리지 않습니다.

아마존 AWS 및 마이크로소프트 Azure, VMWare vCloudAir를 포함한 대부분의 퍼블릭 클라우드를 지원하며, 오픈스택 및 VMWare기반 프라이빗 클라우드도 지원합니다. 추가로 UCS Director와 ACI로 구성된 기존 데이터센터 인프라 역시 지원하고 있습니다.

이정도면 거의 모든 인프라에서 클리커를 사용할 수 있다는 의미겠죠?

둘째, 애플리케이션 생명주기 관리를 지원합니다.

하나의 애플리케이션을 설계하고, 개발하고 배포하고, 업그레이드하고, 회수하는 모든 과정을 지원하는 것입니다. 이러한 생명주기관리 기능이 어떤 경우에 도움이 될 수 있을까요?

예를 하나 살펴보겠습니다.

내부 데이터센터 환경에 맞게 개발된 애플리케이션을 아마존AWS 혹은 MS의 Azure 환경으로 마이그레이션을 고려할 때, 애플리케이션 코드의 비즈니스 로직은 크게 변경되지 않지만, 배포 및 운영 관련된 부분은 변경되기 마련입니다. 즉, 고정된 물리/가상 서버 및 이중화를 기본으로 구성된 데이터센터 환경에서 동적인 가상서버 및 확장성이 뛰어난 분산환경으로 전환 시 동일한 아키텍처를 유지할 수 없는 경우가 대부분입니다. 클리커는 이러한 애플리케이션을 해당 클라우드 인프라에 적합하게 재구성해서 배포할 수 있도록 지원하며 트래픽 규모에 맞게 동적으로 어플리케이션 노드를 확장하는 기능도 제공하고 있습니다.

셋째, 기업이 필요한 하이브리드 클라우드 전략을 강력하게 지원합니다.

기업들의 하이브리드 클라우드 전략은 데이터의 보안 및 거버넌스 측면에서 기업 내 데이터센터를 활용하고 단기간의 용량 증설 및 글로벌 커버리지를 위해서 퍼블릭 클라우드를 이용하는 것입니다. 이 경우 특정 클라우드 환경에 종속되지 않기 위해서는 여러개의 퍼블릭 클라우드 환경에 애플리케이션 배포 및 운영이 필수 고려사항입니다. 그러나 이 고려 사항을 만족시키는 위해서는 단일 환경에서 어플리케이션을 개발 운영하는 업무 보다 많은 시간과 비용이 소요되지요.

CliQr는 애플리케이션 배포시 클라우드 별 예상 비용을 파악할 수 있으며, 클라우드별 장점을 비교해서 최적의 클라우드를 선택할 수 있도록 도와 줍니다.

CliQr덕분에 운영자는 가장 효과적인 방식으로 어플리케이션을 안전하게 배포할 수 있게 되는 것이죠. 정말 멋지지 않습니까?

클리커의 아키텍처 소개

이번에는 놀라운 기능을 보유하고 있는 클리커의 아키텍처를 살펴보도록 하겠습니다.

CliQr 아키텍처는 아래와 같습니다.

클리커 클라우드 센터 아키텍처

사용자가 직접 사용하는 클라우드 센터 매니저, 각 클라우드에 설치되는 클라우드 센터 오케스트레이터, 그리고 핵심개념인 애플리케이션 프로파일이 있습니다.

오케스트레이터는 클라우드 환경에 가상머신으로 설치되며, 애플리케이션 프로파일을 해석하게 됩니다. 이를 통해 해당 클라우드 API로 필요한 인프라를 생성하며, 생성된 자원의 성능을 모니터링 하면서 필요 시 사전에 정의된 자동 확장 기능을 수행하게 됩니다.

애플리케이션 프로파일은 어떻게 만들어지나요?

다음은 클리커 기술의 핵심, 애플리케이션 프로파일은 어떻게 만들어지는 살펴보도록 하겠습니다.

위와 같이 CliQr 자체적으로 미리 생성해 놓은 다양한 서비스 항목들을 바탕으로 토폴로지 빌더를 통해 애플리케이션 프로파일을 생성하게 됩니다.

3 Tier 웹 애플리케이션의 경우 Apache 웹 서버, Tomcat 애플리케이션 서버, 그리고 MySQL 데이터베이스 서버를 구성하고 서로 어떻게 연결되는지를 토폴로지 빌더로 연결시킬 수 있으며, 연결 시 어떤 TCP 포트로 서비스되는지 명시할 수 있습니다.

그리고 웹 서버 앞에 로드 밸런서를 둘 수 있으며 각 논리적인 서버들의 기본적인 사양 (CPU, 메모리, 디스크 등)을 지정할 수 있습니다. 실제 자원이 할당되고 생성되는 클라우드 환경에서 이 프로파일의 요건을 만족시키는 가장 저렴한 VM을 생성하게 될 것입니다.

ECS에서 이런 유사한 기능이 스택 디자이너란 이름으로 제공되었는데요, 클리커가 이 자리를 대신하기로 했다고 하네요.

이젠 인프라만으로는 클라우드 서비스를 이야기할 수 없는 시대가 되었습니다.

어떤 서비스를 클라우드에 올릴 것이고, 그 서비스를 위한 애플리케이션은 어떻게 구성되는지, 그 구성이 다양한 클라우드 플랫폼에서 어떻게 자동화될 수 있는지를 이야기하는 시대가 된 것이지요. 클리커는 이러한 고민을 해결할 수 있는 좋은 툴이 되어줄 것이라 기대가 아주 크답니다.

혹시, 여러 서비스를 다양한 클라우드에 배포 해야 하는 고민이 있으신가요?

그렇다면 클리커로 고민의 실마리를 풀어보시면 어떨까요. 분명 빠르고, 효과적인 IT 서비스를 위한 해답을 찾게 되실 것입니다.

이 칼럼을 SlideShare에서 다운받으실 수 있습니다!

<<클릭>> 왜 클리커일까요?