F5와 IBM으로 엔터프라이즈 클라우드 구축

소개

일부 추산에 따르면 엔터프라이즈 클라우드(프라이빗 클라우드라고도 함)는 퍼블릭 클라우드보다 더 빠른 속도로 도입되고 있습니다. 기업 컨설팅 회사인 Accenture는 2011년 말까지 기업의 프라이빗 클라우드 도입률이 77%에 이를 것으로 전망했습니다.¹  이처럼 민첩한 온사이트 인프라 구축이 빠르게 진행되는 주된 이유는 대기업과 중소기업의 IT 부서 모두 인프라와 데이터를 사내에서 직접 통제하고 관리해야 하기 때문입니다.

클라우드 인프라를 도입하기로 결정한 후에는 비용, 위험 및 가치를 분석하여 내부/프라이빗 클라우드와 외부/퍼블릭 클라우드 중 하나를 선택하게 됩니다. 퍼블릭 클라우드는 일반적으로 유연한 접근 방식과 가장 큰 비용 절감 효과를 제공하지만, 보안, 서비스 수준 계약(SLA), 가용성 및 관리와 관련된 위험이 따릅니다. IT 부서는 적은 초기 비용으로 사실상 무제한에 가까운 확장성을 활용할 수 있지만, 그 대신 통제권을 포기해야 합니다. 기존의 온프레미스 또는 호스팅 데이터 센터에서 외부 퍼블릭 클라우드로 이전하는 것은 기본적으로 데이터 센터 전체를 다른 사람의 손에 맡기는 것과 같습니다.

엔터프라이즈 클라우드를 사용하면 IT 부서는 필요한 수준의 제어권을 확보하고 퍼블릭 클라우드와 관련된 위험을 피할 수 있습니다. 하지만 프라이빗 클라우드는 구축 비용이 더 많이 들고, 직원에게 더 높은 수준의 지식과 전문성을 요구하며, 온프레미스 데이터 센터의 복잡성을 가중시킵니다. 엔터프라이즈 클라우드 인프라는 필요에 따라 확장할 수 있고 동적 프로비저닝과 민첩성을 제공하지만, 이러한 확장성과 제어력을 확보하려면 초기 비용이 더 많이 드는 경우가 많습니다.

F5 Networks®와 IBM은 복잡성으로 인해 발생하는 여러 문제를 완화하는 엔터프라이즈 클라우드용 참조 아키텍처를 공동으로 설계했습니다. 이 아키텍처는 퍼블릭 클라우드의 다양한 아키텍처 및 확장성 구성 요소를 온프레미스 환경에 구현하여, 내부 시스템을 개별적으로 구축하는 데 드는 비용을 크게 절감합니다. F5와 IBM은 필수 구성 요소를 사전에 정의하고 이러한 구성 요소가 함께 작동하는 방식을 제시함으로써 완전하고 동적이며 민첩한 엔터프라이즈 클라우드 인프라를 구축했습니다.

워크플로

온디맨드 프로비저닝 시스템에서 가장 중요한 요소는 이벤트를 기반으로 의사 결정을 내리고 조치를 취하는 능력입니다. 시스템 내 어딘가에서 발생한 이벤트는 경고나 메시지를 생성하며, 이 메시지는 메시지 버스를 구독한 구성 요소 또는 API 호출을 통해 직접 요청받은 구성 요소에 의해 수신됩니다. 그러면 해당 구성 요소가 메시지에 따라 조치를 취합니다. 워크플로는 구성 요소가 시스템 메시지에 대응하는 절차와 순서를 의미합니다.

엔터프라이즈 클라우드에서 워크플로는 일반적으로 리소스를 요청하거나 반환하는 프로비저닝 구성 요소와 리소스 할당을 관리하는 데 필요한 단계로 구성됩니다. 가상 머신(VM)에 추가 CPU 리소스가 필요해지면 해당 CPU 리소스를 어디에서 확보할지 결정하고, 새 VM을 시작하고, IP 주소를 할당하는 등의 작업을 수행하는 워크플로가 시작됩니다.

워크플로 아키텍처

F5와 IBM의 엔터프라이즈 클라우드 아키텍처는 다음 두 가지 핵심 원칙을 기반으로 합니다:

1. 이벤트 알림 메시지를 전달하는 데 사용되는 중앙 집중식 메시지 버스가 있으며, 이벤트에 대응해야 하는 모든 구성 요소가 이 버스에 연결됩니다.
   

클라우드 참조 아키텍처.

이 두 가지 원칙 외에도 F5와 IBM의 참조 아키텍처는 유연성이 매우 뛰어나 기존의 어떤 데이터 센터 또는 클라우드 아키텍처에도 적용할 수 있습니다. 예를 들어 VM 배포를 관리하는 오케스트레이션 엔진이 이미 있다면, 기존 엔진을 사용할 수 있도록 이 참조 아키텍처를 조정할 수 있습니다. 엔터프라이즈 클라우드를 구축하려면 전체 인프라를 교체해야 한다는 오해가 있지만, F5와 IBM의 솔루션은 가능한 모든 단계에서 기존 구성 요소와 통합되도록 설계되었습니다.

워크플로 구성 요소

어떤 구성 요소가 기존 요소이고 어떤 구성 요소가 새로운 요소인지와 관계없이, 엔터프라이즈 클라우드 워크플로는 특정 작업을 수행하는 개별 구성 요소로 이루어집니다. 전체 클라우드 시스템은 이러한 개별 구성 요소로 구성되며, 이들은 서로 연동하여 완전한 클라우드 인프라를 제공합니다. 이 인프라는 클라우드 이벤트를 관리하는 일련의 조정된 작업인 구성 요소 워크플로를 통해 구동되고 제어됩니다.

메시지 버스

메시지 버스는 이벤트와 경고를 기반으로 영향을 받는 각 구성 요소에 메시지를 전달하는 시스템입니다. 이벤트로 인해 메시지가 생성되면 해당 메시지는 메시지 버스를 통해 특정 구성 요소로 전송되며, 각 구성 요소에는 그 메시지를 처리하는 방법에 대한 규칙이 있습니다. 또한 메시지 버스는 특정 구성 요소에 적용되는 규칙에 따라 메시지를 정규화하는 역할도 합니다.

F5 및 IBM 참조 클라우드 아키텍처에서는 IBM Tivoli Netcool OMNIbus 솔루션을 중앙 메시지 버스로 사용하지만, 어떤 엔터프라이즈 메시지 버스든 시스템 전체에 이벤트 알림을 전달하는 데 사용할 수 있습니다.

오케스트레이터

오케스트레이터는 엔터프라이즈 클라우드의 두뇌라고 할 수 있습니다. 즉, 버스를 통해 수신한 메시지를 기반으로 대부분의 거시적인 프로비저닝 결정을 내리는 구성 요소입니다. 오케스트레이터는 ‘새 가상 머신 프로비저닝’ 워크플로를 시작하는 등 클라우드 아키텍처의 주요 이벤트와 워크플로를 개시합니다. 또한 각 워크플로에 필요한 데이터를 가져와 해당 구성 요소에 제공하는 역할도 담당합니다. 예를 들어 새 VM을 프로비저닝하는 데 필요한 IP 주소 정보를 제공합니다.

참조 아키텍처에서 오케스트레이터는 버스에서 전달되는 메시지에 따라 동작하고 워크플로 이벤트를 시작하는 일련의 인터프리터 방식 스크립트를 사용하여 구성됩니다. IBM Tivoli Intelligent Orchestrator, HP Operations Orchestration 또는 VMware vCenter Orchestrator와 같은 모든 유형의 오케스트레이터를 사용할 수 있습니다.

클라우드 컨트롤러

클라우드 컨트롤러는 프로비저닝 프로세스를 시작하는 데 필요한 예비 데이터를 수집하고 취합하는 프런트엔드 시스템입니다. 처음에는 관리자가 생성 프로세스의 일부로 이 정보를 제공하며, 해당 정보는 프로비저닝에 사용되는 워크플로 유형별로 다릅니다. 예를 들어 클라우드 컨트롤러는 VM 위치, 애플리케이션 유형(웹 서버, 데이터베이스 서버, 메일 서버 등), 최소 리소스 요구 사항 등의 정보를 수집합니다.

자동 프로비저닝이 실행될 때 이 예비 데이터가 이미 시스템에 저장되어 있으면, 오케스트레이터는 기존 정보를 요청하고 추출하여 프로비저닝 워크플로를 시작하는 데 사용합니다. 클라우드 컨트롤러의 예로는 Eucalyptus Cloud Controller, VMware vCloud Director, Amazon EC2 등이 있습니다. 향후 다른 클라우드 플랫폼으로 확장할 가능성을 고려하면, 표준 클라우드 API 세트와 통합하거나 통신할 수 있는 클라우드 컨트롤러를 선택하는 것이 좋습니다. 그러면 엔터프라이즈 클라우드 플랫폼을 재설계하지 않고도 클라우드 컨트롤러를 퍼블릭 또는 하이브리드 클라우드 공급자로 확장할 수 있습니다.

클러스터 컨트롤러/하이퍼바이저

클러스터 컨트롤러는 엔터프라이즈 클라우드에서 프로비저닝 중인 가상 머신과 해당 VM을 실행하는 데 필요한 스토리지 및 메타데이터를 관리하는 구성 요소입니다. VM 실행 환경인 클러스터 컨트롤러에는 가상 플랫폼 하이퍼바이저가 포함되며, 더 광범위한 하이퍼바이저 관리 환경도 포함될 수 있습니다. 예를 들어 클러스터 컨트롤러는 VMware ESXi와 같은 기본적인 하이퍼바이저일 수도 있고, VMware vSphere 또는 VMware vCloud와 같은 대규모 분산 하이퍼바이저 시스템 모음일 수도 있습니다.

모니터링

상태 및 가용성 모니터링은 모든 엔터프라이즈 애플리케이션 배포에 필수적인 요소입니다. 또한 모니터링은 가상 머신이 가동되어 네트워크 연결에 응답하는 경우와 같이 프로비저닝 시스템에 상태 업데이트를 제공합니다. 시스템을 지속적으로 모니터링하면 실시간 경고를 제공할 수 있으며, 이러한 경고는 궁극적으로 새로운 워크플로에 반영되어 프로비저닝 결정에 영향을 미칩니다. 애플리케이션 및 네트워크 상태를 모니터링할 수 있는 모든 구성 요소를 엔터프라이즈 클라우드 배포에 사용할 수 있지만, F5 및 IBM 참조 아키텍처에서는 IBM Tivoli Monitoring 소프트웨어를 사용합니다.

DNS

도메인 이름 시스템(DNS)은 F5 및 IBM 엔터프라이즈 클라우드 참조 아키텍처에서 핵심적인 역할을 합니다. DNS는 IPv4 및 IPv6의 IP 주소와 도메인 이름 정보뿐만 아니라 클라우드 컨트롤러가 수집한 정보와 고유한 시스템 식별 정보 등의 시스템 메타데이터도 저장합니다. 이 참조 아키텍처에서는 DNS가 표준 기반 시스템으로서 이미 대부분의 네트워크에 존재하고, 모든 클라우드 구성 요소에서 사용할 수 있으며, 인프라에 별도의 데이터베이스형 스토리지를 추가할 필요를 줄여 주기 때문에 메타데이터 저장 위치로 선택되었습니다. IT 부서에서 관리하며 추가 영역과 영역 파일을 생성할 수 있는 DNS 솔루션이라면 무엇이든 사용할 수 있습니다.

스토리지

F5 및 IBM 참조 아키텍처에서 클러스터 컨트롤러는 로컬 스토리지의 가상 머신을 실행하지만, 가상 머신이 실행 중이 아닐 때는 VM 가상 디스크가 가상화된 스토리지에 저장됩니다. 워크플로 프로비저닝 이벤트가 발생하면 클러스터 컨트롤러는 NFS(Network File System)를 통해 가상 스토리지 장치에 가상 디스크를 요청합니다.

애플리케이션 전송 컨트롤러

엔터프라이즈 클라우드의 마지막 구성 요소는 애플리케이션 전송 컨트롤러(로드 밸런서라고도 함)이며, F5 및 IBM 참조 아키텍처에서는 F5® BIG-IP® Local Traffic Manager™(LTM)가 이에 해당합니다. BIG-IP LTM은 가상 머신에서 전송되는 애플리케이션 데이터의 연결, 서비스 및 전송을 관리합니다. 궁극적으로 BIG-IP LTM은 워크플로 프로비저닝 이벤트에 따라 동작하는 시스템의 최종 구성 요소입니다.

단계별 안내: 수동 및 자동 프로비저닝

F5 및 IBM 엔터프라이즈 클라우드 참조 아키텍처의 목표는 애플리케이션을 동적으로 배포할 수 있는 실제 환경의 리소스 기반 플랫폼을 제공하는 것입니다. 모든 구성 요소가 준비되면 다양한 워크플로를 통해 서로 연동하여 필요에 따라 새로운 애플리케이션 서비스를 프로비저닝합니다. 엔터프라이즈 클라우드에 구축된 시스템을 프로비저닝하는 방법에는 수동 프로비저닝과 자동 프로비저닝의 두 가지가 있습니다.

수동 프로비저닝

일반적으로 엔터프라이즈 클라우드의 첫 번째 워크플로는 시스템 관리자 또는 애플리케이션 요청자가 입력한 정보를 바탕으로 수동 프로세스를 통해 시작됩니다. 그렇다고 워크플로 자체가 수동이라는 의미는 아닙니다. 시스템에 처음으로 정보를 입력하는 작업만 수동으로 이루어집니다. 관리자로부터 데이터가 수집되면 시스템은 애플리케이션 프로비저닝을 위해 사전 정의된 자동화 워크플로 이벤트를 시작합니다.

1단계: 클라우드 컨트롤러 데이터 입력

클라우드 컨트롤러 GUI를 사용하여 관리자(또는 새 프로비저닝 이벤트를 시작할 책임이 있는 주체에 따라 애플리케이션 요청자)가 새 가상 머신을 구동하고 애플리케이션을 온라인 상태로 전환하는 데 필요한 정보를 입력합니다. 이 정보는 일반적으로 다음과 같은 상위 수준의 인프라 데이터입니다:

• 애플리케이션 유형: Microsoft SharePoint, 웹 서버, 메일 서버, Oracle 데이터베이스 등 사용 가능한 애플리케이션 유형이 미리 정의된 목록입니다.
• 네트워크 정보: 클러스터 IP 주소, 프런트 엔드 URL, 이 애플리케이션의 외부 공개 여부 또는 내부 전용 여부 등
• 프로비저닝 정보: 네트워크 위치(대개 물리적 데이터 센터와 연계된 지리적 위치를 의미하며, 예: “유럽–코펜하겐 데이터 센터”) 및 특정 애플리케이션 유형에 허용되는 최소 및 최대 인스턴스 수에 대한 제한 등 프로비저닝 시스템에 필요한 추가 정보입니다.

이 정보는 엔터프라이즈 클라우드 전반에서 자동 프로비저닝을 위한 메타데이터로 사용됩니다.

2단계: 프로비저닝 워크플로 시작 및 메타데이터 배포

관리자가 필수 데이터를 제출하면, 다음 단계로 클라우드 컨트롤러가 해당 정보와 함께 프로비저닝할 인스턴스를 시스템 전반에서 식별하는 데 사용되는 “vm12345”와 같은 동적으로 생성된 고유 인스턴스 ID를 패키징한 후 메시지 버스를 통해 오케스트레이터에 배포합니다.

첫 번째 단계에서 제공된 모든 정보는 오케스트레이터에 전달되기 전에 메시지 버스에 의해 정규화됩니다.

이와 동시에 클라우드 컨트롤러는 API를 통해 동일한 메타데이터와 고유 인스턴스 ID를 하이퍼바이저에 제공하고, 필요한 애플리케이션 이미지를 배포하도록 지시합니다. 그러면 하이퍼바이저는 클라우드 기반 스토리지에 해당 가상 머신 디스크 이미지를 요청합니다. 스토리지 장치는 NFS를 통해 적절한 디스크 이미지를 가져와 로컬 스토리지로 복사하기 시작합니다.

3단계: 오케스트레이터가 메타데이터 배포

오케스트레이터는 메시지 버스로부터 정규화된 이벤트 정보와 메타데이터를 수신한 후, 메타데이터를 모니터링 시스템과 DNS에 동시에 전달하는 두 가지 워크플로를 시작합니다. 모니터링 시스템은 이 정보를 사용하여 애플리케이션의 자동 모니터링 일정을 구성하고, 애플리케이션이 정상적으로 실행 중이라는 알림을 받은 후 모니터링을 시작합니다. 또한 이 단계에서 오케스트레이터는 모니터링 시스템 이벤트의 임계값을 정의합니다. 예를 들어 이 가상 인스턴스의 CPU 사용률이 75%를 초과하면 이벤트 알림을 보내도록 모니터에 지시합니다.

오케스트레이터는 가상 인스턴스 메타데이터를 DNS에도 전송하며, 이 데이터는 엔터프라이즈 클라우드 전반에서 사용할 수 있도록 저장됩니다. 오케스트레이터는 메타데이터를 적절한 DNS 영역 형식으로 제출해야 하므로 인스턴스 ID를 기반으로 도메인 이름을 구성하고, IPv4 및 IPv6 DNS 레코드를 생성하며, 클라우드 컨트롤러의 인스턴스 정보를 추가하고, 새 인스턴스 정보를 적절한 영역에 추가해야 합니다. 예를 들어 오케스트레이터는 고유한 인스턴스 ID를 사용하여 “vm12345.vm.cloud.example.com”에 대한 DNS 항목을 생성한 후 기존 example.com 영역에 추가합니다.

엔터프라이즈 클라우드 전체에 메타데이터를 배포하는 마지막 단계는 BIG-IP LTM 애플리케이션 딜리버리 컨트롤러에 호스트 이름, IP 주소, 애플리케이션 유형(또는 BIG-IP LTM의 풀), 모니터링 정보 등의 새 인스턴스 정보를 입력하는 것입니다.

4단계: 가상 머신 알림

2단계에서 클라우드 컨트롤러는 하이퍼바이저에 새로 프로비저닝된 인스턴스와 연결된 가상 머신을 시작하도록 지시했습니다. 해당 VM이 예상대로 가동되어 연결 가능한 상태가 되면 메시지 버스의 이벤트 알림을 통해 오케스트레이터에 이를 알립니다. 오케스트레이터는 이 이벤트 알림을 수신한 후, BIG-IP LTM에 새 VM을 풀에서 사용 가능한 상태로 표시하고 부하 분산 방식에 따라 새 연결을 가상 인스턴스로 전송하고 분산하도록 지시하는 워크플로를 시작합니다. 또한 BIG-IP LTM은 애플리케이션 풀에 할당된, 이전에 구성한 애플리케이션 모니터를 사용하여 새 인스턴스의 모니터링을 시작합니다.

새로 실행된 VM에서 발생한 이벤트 알림은 오케스트레이터가 엔터프라이즈 클라우드의 전체 모니터링 시스템에 가상 인스턴스 모니터링을 시작하도록 알리는 계기가 되기도 합니다. 이제 새로 프로비저닝된 가상 인스턴스가 엔터프라이즈 클라우드에서 정상적으로 실행되며 애플리케이션 서비스 요청을 처리합니다. 이는 엔터프라이즈 클라우드에 속한 모든 서비스의 정상 운영 모드입니다.

자동 프로비저닝

수동 프로비저닝은 엔터프라이즈 클라우드 내에서 서비스를 프로비저닝하는 워크플로의 첫 단계이지만, 가장 빈번하게 사용되는 프로비저닝 방식은 아닙니다. 원활하게 운영되는 시스템에서 엔터프라이즈 클라우드는 자체 모니터링이 가능한 더욱 역동적이고 유연한 시스템으로 전환되며, 필요와 수요에 따라 새로운 서비스를 자동으로 프로비저닝합니다. 이러한 민첩한 셀프 프로비저닝은 모든 클라우드 플랫폼의 핵심이며, 실시간 이벤트를 모니터링하고 이에 대응하기 위한 추가적인 자동 프로비저닝 이벤트와 워크플로가 필요합니다.

1단계: 모니터링 및 알림

모든 자동 프로비저닝 시스템의 첫 번째 단계는 모니터링, 즉 시스템 전반에서 이벤트를 수집하고 감지하는 것입니다. 첫 번째 수동 프로비저닝 과정에서 모니터링 시스템에는 이름, 위치, 모니터링 유형, 이벤트 임계값 등의 가상 인스턴스 정보가 입력되었습니다. 이 정보는 애플리케이션과 가상 인스턴스의 가용성 및 성능을 자동으로 모니터링하는 데 사용됩니다. 예를 들어 특정 가상 인스턴스가 사용 가능한 CPU 리소스의 75% 이상을 소비하는 이벤트가 모니터링 시스템에서 감지되면, 메시지 버스에 이벤트가 생성되어 리소스가 고갈되었음을 오케스트레이터에 알립니다.

2단계: 데이터 수집

일반적인 자동 프로비저닝 시나리오에서 오케스트레이터는 현재 인스턴스의 리소스 부하를 줄이는 데 도움이 되는 새 가상 인스턴스를 생성합니다. 두 개 이상의 가상 인스턴스를 사용하여 애플리케이션의 컴퓨팅 및 네트워크 부하를 분산합니다.

자동 프로비저닝 워크플로를 시작하려면 오케스트레이터가 구성 요소 이벤트를 수집하고 새 가상 인스턴스를 프로비저닝하는 데 필요한 메타데이터를 요청해야 합니다. F5 및 IBM 참조 아키텍처에서는 메타데이터가 DNS에 저장되며 최초 수동 프로비저닝 워크플로의 일부로 입력됩니다. DNS는 애플리케이션 유형, 지리적 위치, 프로비저닝 임계값 등의 정보를 오케스트레이터에 반환합니다.

3단계: 워크플로 시작

자동 프로비저닝 워크플로의 마지막 단계에서 오케스트레이터는 DNS에서 가져온 메타데이터를 메시지 버스를 통해 클라우드 컨트롤러로 전송합니다. 기본적으로 이 자동화 단계는 관리자가 머신 정보를 입력하고 프로비저닝 워크플로를 수동으로 시작하는 단계를 모사합니다. 클라우드 컨트롤러는 이 정보를 받아(수동 프로비저닝 시 관리자에게서 정보를 받는 것과 동일하게) 새로운 가상 인스턴스 프로비저닝 워크플로를 시작합니다. 이후에는 새 가상 인스턴스가 가동되어 실행되고 새로운 연결을 수락할 때까지 위에서 설명한 프로비저닝 단계와 워크플로가 반복됩니다.

일반적인 엔터프라이즈 클라우드 배포에는 수동 및 자동 프로비저닝 워크플로가 모두 포함됩니다. 새로운 서비스나 애플리케이션은 관리자가 서비스의 배포 방식과 위치를 제어할 수 있도록 처음에는 수동 워크플로를 사용하여 배포됩니다. 서비스가 가동되면 자동 프로비저닝 워크플로가 리소스 요구 사항과 가용성에 따라 프로비저닝을 관리합니다.

결론

프라이빗 엔터프라이즈 클라우드를 구축한다고 해서 복잡성이 증가하거나 상호 운용성이 저하되어서는 안 됩니다. 모든 클라우드 구축의 목적은 새로운 서비스 개발의 장벽을 낮추고 더욱 민첩한 컴퓨팅 인프라를 제공하는 것입니다. 엔터프라이즈 클라우드는 이러한 민첩성을 데이터 센터에 구현하여 관리 편의성과 제어 능력을 크게 향상합니다.

F5는 IBM과 함께 자동 프로비저닝되는 엔터프라이즈 클라우드를 위한 참조 아키텍처를 구축했습니다. 이 아키텍처는 모듈성과 유연성을 갖추도록 설계되어 필요에 따라 기존 구성 요소를 통합할 수 있으며, API와 공유 메시징 인프라를 통해 전체 엔터프라이즈 클라우드를 다른 모든 클라우드 플랫폼에 연결할 수 있습니다. 프라이빗 엔터프라이즈 클라우드는 저마다 다르지만, F5와 IBM의 아키텍처는 다양한 환경에 맞게 조정되며 모든 애플리케이션 배포 또는 데이터 센터에 민첩한 인프라의 이점을 제공합니다.

¹ Babcock, Charles(2011년 1월 18일). “프라이빗 클라우드의 도약.” Information Week. 웹.

2012년 1월 10일 게시