System Compleat.

'스토리지'에 해당되는 글 1건

  1. Things that you have to concern when you build CLOUD.

Things that you have to concern when you build CLOUD.

Techs
( younjin.jeong@gmail.com , 정윤진 ) 



클라우드는 이제 관심을 넘어, 이 업계의 사람들에게 실제 비용을 주고 어떻게라도 접근 해야 뒤쳐지지 않는, 마치 패션과 같은 무엇이 되어 버렸다. 이는 어떠한 일반적인 사용자에게는 애플의 "포토스트림" 과 같은 서비스를 해 주는 무언가로 인식 되기도 하고, 개발자들에게는 "저렴한 개발 플랫폼" 으로 인식되기도 하며, 누군가에게는 "어디서나 접근 가능한 저장소" 의 개념이 되기도 한다. 

바야흐로 Everything as a Service 의 시대를 맞이함에 있어, 위에 소개한 개념들을 내포한 대부분의 서비스들이 우후죽순 처럼 생겨나는 시대가 되었다. 누구나 Post Facebook 에 대해 생각해 보고, 좋은 사업 아이디어를 가지고 저렴한 비용으로 서비스를 시작해 볼 수 있는 시대이기도 하다. 아이디어만 있다면, 사업을 시작함에 있어 적어도 인프라에 있어서는 기존의 1/10 도 안되는 비용으로 가능하다.

하지만 언젠가는, 사업이 일정 규모 이상으로 커지고, 데이터 보안에 대한 압박이 커져 갈 수록 기존의 Public Cloud 서비스는 비용과 보안에서 커다란 문제를 가진다. 또한 서비스를 구성하는 각 모듈화된 컴포넌트를 구현함에 있어 제약 사항이 발생하게 되고, 이러한 제약 사항을 해결하기엔 너무 획일적인 구조를 가진 기존의 서비스로 인해 한계에 봉착하기도 한다. 이러한 한계로는 주로 네트워크의 대역폭, 사용 가능한 IP 의 제한, 심각할 정도로 낮은 I/O 성능, 서비스 공급자의 장애 발생에 의한 서비스 중단 및 Flat Network 구성으로 인해 인스턴스에서 1개의 네트워크로 외부 연결 및 내부 연결을 처리해야 하는 구조적인 제약을 가지곤 한다.

Image from: http://softwarestrategiesblog.com/2011/07/27/gartner-releases-their-hype-cycle-for-cloud-computing-2011/

이러한 제약으로 인해 빠르던 느리던 각 기업은 기존과 같이, 직접 운용해야 하는 클라우드 인프라를 소유하고자 하는 경우가 발생하게 된다.  하지만 이러한 클라우드 시스템은 오픈 소스로 구현 하였을 경우, 또 적절한 운용 인력이 있는 경우에 최대한의 성능을 발휘하지만 국내에서는 이 두가지 모두 쉬운일이 아니다. 따라서 많은 기업은 "이미 구현되어 사용법만 알면 되는 클라우드 플랫폼" 에 관심을 가지게 된다. 하지만 이건 구현에 있어 "엄청난 비용" 이 필요하므로, 처음부터 가격 경쟁력을 무시하겠다 라고 정의하고 시작하지 않는다면 향후 큰 난관을 맞이하게 된다. 

금일 포스팅은 이러한 "클라우드 플랫폼" 구성에 있어 반드시 고려해야 하는 요소들을 몇가지 적어보려 한다. 이는 물론 이 포스팅을 읽는 어느분께는 유용할 수도, 유용하지 않을 수도 있지만, 가장 궁극적인 목적은 나 스스로 이러한 것들이 중요하다고 정의/정리 하는 것이 필요함을 느껴서 이다. 따라서 관심이 없는 분들은 언제든 닫아 주셔도 좋다. 또한, 이제부터 정리하는 내용들은 모두 오픈소스 또는 가장 저렴한 방법을 통해 클라우드를 구성한다고 의사 결정이 완료 되었음을 가정하고 설명한다. 


0. 개념 

개인적으로 클라우드의 정의는 클라우드란 사실, 클러스터의 특화된 개념으로 볼 수 있다. 특정 서비스의 구현을 목적으로 동일한 형상의 시스템 다수를 네트워크를 통해 묶는 것을 말한다. 최근에 많이 사용되는 서비스를 기준으로 가상화된 인스턴스를 제공하는 클라우드는 하이퍼바이저 클러스터로 볼 수 있으며,  무한대의 확장을 제공하는 스토리지 클라우드를 디스크 클러스터로 볼 수 있다. 다시 이 위에 서비스를 구현 한 것들은 DB 클러스터, Queue 서비스 클러스터로 볼 수 있다. 

결국 엔드유저 또는 기업이 원하는 것은 하이퍼바이저 클러스터인 컴퓨트 클라우드와, 디스크 서버 클러스터인 스토리지 클라우드로 이루어진 IaaS 클라우드가 되며, 이 위에 DB, Queue, Load Balancer, CMS, CDN 등의 서비스를 덧입힌 것을 REST API 를 통해 컨트롤 하게 만들면 바로 클라우드가 된다.  

클러스터라고 부르면 보통 컴퓨팅에서는 수퍼컴퓨팅 또는 자연과학, 물리학 등에서 계산을 목적으로 사용하는 컴퓨터의 묶음 또는 거대한 Cray 컴퓨터로 할 수 있는 무엇을 상상하곤 한다. 클라우드라 불리는 이 특수목적용 클러스터는 결국, 세분화 한다면 가상화 인스턴스 클러스터, 파일 및 오브젝트 저장 클러스터의 확장에 다름 아니다. 

IBM이 문서 정리는 참 잘하는데, 다음의 링크를 한번 읽어보는 것도 좋다. 
http://www.ibm.com/developerworks/kr/library/os-cloud-anatomy/



1. 네트워킹 

클라우드가 곧 일종의 클러스터이므로, 용도와 목적에 맞는 네트워킹의 구조 설계가 하나의 중요한 포인트이다. 하지만 이 네트워크 구성에 다소 어려움을 겪는 것이 일반적인데, 이는 기존에 사용하던 단일 서비스 네트워크 구조와는 그 모양새가 다르기 때문이다. 왜 다르냐고 묻는다면, 바로 듣기에도 생소한 하이퍼바이저의 클러스터링을 해야 한다 라는 요구조건 때문인데, 이 클러스터링이 요구하는 형태가 그 클러스터 소프트웨어에 따라 조금씩 상이하기 때문에며, 또한 하이퍼바이저 역시 조금씩 다른 성향을 가지고 있기 때문이다. 

물론 그렇다 하더라도, 모든 클라우드 클러스터는 다음의 내용을 충족해야 한다는 조건을 가진다. 

- Scale-out 의 형태로 거의 무한대에 수렴하게 증설이 가능한 구조여야 한다. 
- 필요에 따라 FCoE 즉 iSCSI 트래픽의 처리에 중점을 두어야 할 필요가 있다. 
- 하이퍼바이저 또는 스토리지 클러스터가 원하는 요구조건을 충족해야 한다. 
- 보통 서비스/관리/스토리지/가상 네트워크의 종류를 가진다. 
 
예를 들어, 랙 하나를 가지고 컴퓨트 클라우드를 구현하고자 하는 경우, 다음의 옵션을 사용 할 수 있다.
- Option A :  Cloudstack  +  # of Xen server +  iSCSI Storage + Logging/etc.
- Option B :  Open Stack Nova + # of KVM server + iSCSI Storage + etc.

Option A 를 선택한다고 가정 할 때, 랙이 단 1개만 구성되는 경우라면 별 고민없이 대부분의 컴포넌트에 기본 옵션을 사용 할 수 있다. 예를 들어 Xen server 의 최대 클러스터 수량인 16대를 Compute Node 로 묶어 하나의 공유 스토리지를 가지는 형태로 구성이 가능하다. 이러한 시스템의 준비 및 설치는 장비만 있다면 필자의 경우 수십분 내로 구성이 가능하다. 이러한 단순한 구성에도 네트워킹을 위해서는 사설 관리 네트워크 / 공인 네트워크 / 사설 스토리지 네트워크의 적어도 3가지가 필요하게 되며, 이 랙을 Public 클라우드 처럼 사용하고자 한다면 Router VM 에서 각 고립된 계정에 할당되어 사용할 별도의 사설 IP 대역 및 스위치 레벨에서의 tagged VLAN 구성이 필요하게 된다.

랙 1개에 구성하고자 하는 경우에는 이처럼 큰 구조만 짜 맞추어 주면 별 문제가 안된다. 대부분을 기본값을 사용해도 무방하다. 만약 기업에 필요한 인스턴스의 숫자가 200개 미만이고, 높은 가용성을 요구하지 않는다면 손쉽게 만들어 사용 할 수 있다.

하지만, 만약 사설 클라우드를 ( 이 글의 기본 요구조건인 기업 고객이 그들의 서비스를 위해 사용하고자 하는 경우이므로 ) 엔터프라이즈 레벨, 즉 적어도 랙 500개 이상을 구현하고자 할 때는 간단한 네트워킹으로 해결 할 수 없다. 이는,  다음과 같은 요구조건을 가지게 된다.

- 모든 랙은 서로 통신이 가능해야 한다.
- 서브네팅을 하지 않는다면, 하나의 하이퍼바이저 또는 스토리지가 전체 클라우드를 말아먹을 수 있다.
- 손쉬운 설치를 위해, 모든 랙의 관리 네트워크는 DHCP 가 가능해야 한다. 
- EBS와 같은 기능을 구현하고자 하는 경우, 모든 랙에서 접근 가능한 스토리지 네트워크의 구현이 가능해야 한다.  
- 이 모든 네트워크는 확장 또는 추가에 일정한 "법칙" 또는 "체계" 를 가지도록 해야 하는 것이 좋다. 그렇지 않은경우, 디스크/서버 장애가 발생한 경우 교체를 위해 OP는 책 한권 분량의 매핑 자료를 들고 다녀야 할 것이다. 

언뜻 보기에는 쉬운 요구조건 같지만,  무엇이 베스트 모델인지 추려내는 것은 경험 없이는 쉬운일이 아닐 것이다. MLAG 기반의 L2 형 확장이 답인지, 아니면 각 랙을 L3 기반으로 만들어 백본에 추가하는 것이 나은지는 오직 서비스 요구 조건과 규모, 그리고 비용에 따라 다를 수 있다. 다음을 보자. 

MLAG 을 사용하기로 결정 한 경우
- Enterprise 보다는 Midsize 에 권한다. 
- 백본의 성능이 중요한 이슈가 된다. 
- 벤더마다 다르지만, MALG 구성시 양쪽의 회선을 동일하게 Active - Active 형태로 제공하는 제품을 사용하는지 확인 할 필요가 있다. 
- Backbone 의 포트 수량에 따라 클러스터의 크기가 결정되는 경우가 많다. 

L3 기반의 네트워킹을 사용하기로 결정 한 경우 
- OSPF/BGP 등의 프로토콜이 전사적으로 지원 되어야 한다. 
- ToR 의 물리적 Uplink 수량에 따른 ECMP 지원 여부를 확인/테스트 해야 한다. 
- 실제 장애를 발생시키는 테스트에서 Route Path 의 업데이트를 명확하게 체크하도록 한다. 


공통 
- Flat Network 를 구성하는 경우, QoS 사용 여부를 적극 검토하도록 한다. 
- 서비스에 따라 MTU 구성에 대한 최적의 값을 찾아보도록 한다. 물론, 하이퍼바이저에 따른 MTU 의 지원여부는 확인해 보아야 한다. 
- Provisioning 을 위한 DHCP Relay 의 동작을 구성하도록 한다. 

본 네트워킹에 대한 부분에서는, 이전에 포스팅한 iBGP 관련 내용을 확인 해 보도록 한다. 
네트워킹은 클러스터의 젖줄이기 때문에, 그 설계에 있어 클러스터에 필요한 모든 요구사항을 반영할 수 있어야 한다. 이 말은 바꾸면 클러스터에 대한 요구 조건을 파악하는 것이 클라우드 네트워크 설계의 핵심이며, 따라서 다음의 내용은 클러스터에 대해 알아 보도록 한다. 

아시다시피, 각 클러스터의 리소스에 연결되는 대역폭 또는 Latency 와 같은 이슈도 중요함은 굳이 추가로 설명하지 않는다. 



2. 하이퍼바이저. 

어떠한 하이퍼바이저를 사용 할 것인가 결정하는 문제는 그렇게 쉬운 것이 아니다. 그 이유는 첫째, 직접 원하는 환경에서 구동해 보지 않으면 알아낼 수 있는 사실이 거의 없고, 문제가 한번 발생하면 상용이던 오픈소스던 해결이 쉽지 않으며, 가상화를 이해하는데 필요한 기본 개념이 제법 많기 때문이다. 

한가지 더 중요하게 고려해야 할 사항은, 과연 하이퍼바이저가 필요한가의 여부이다. 물론 대부분의 가상화된 인스턴스를 제공하고자 하는 클러스터는 당연히 하이퍼바이저를 사용해야 하지만, 경우에 따라 하이퍼바이저가 없는, 즉 기존의 일반적인 물리 서버를 그대로 사용하고자 하는 경우도 있을 수 있다. 가상화를 사용하기 시작한 이유는 대부분의 서버가 서비스 하는 시간동안 peak 상태를 유지 하는 것 보다, idle 상태가 더욱 많기 때문에 물리적 자원을 극대화 하여 사용하기 위해 이를 독립적으로 쪼개어 사용하고자 하는 이유에서 비롯된 것이다. 하지만 서비스가 대부분의 시간동안 Peak 를 치는 경우, 이는 하이퍼 바이저를 사용하지 않거나, 또는 인스턴스 생성의 기본이 되는 서비스 오퍼링을 극대화, 즉 DomU 의 수량을 줄이는 형태의 구성도 때로는 필요하게 된다. 아마도 HPC 분야에 사용하려는 클라우드의 경우 이러한 구성을 생각해 볼 수 있겠다. 

상용으로 많이 사용하는 것은, VMWare 와 Xen 이며, Xen 의 경우에는 오픈소스로도 가져다가 사용이 가능하다. 통상 KVM, VMware, Citrix Xen, OSS Xen 중 하나를 선택하여 클러스터를 구성하게 되는데, 각 클러스터 별로 인스턴스의 통제를 지원하는 범위 및 API 의 사용성등이 상이하므로 충분한 테스트를 통해 기업의 서비스에 맞는 하이퍼바이저를 선택하는 것이 중요하다. 

예를 들자면, 
- VM에 대한 BIOS 제어 범위 
- Redundancy 구성의 가용 범위 ( 예를 들면 802.3ad 구성시 MTU 변경 적용 가능 여부 등 ) 
- vCPU, 메모리 할당의 한계와 VM 수량에 대한 적정 비율. 
- API 
- VM 의 백업 지원 방법 
- 공유 스토리지 필요여부 
- 이미지 / 템플릿을 통한 Deploy 
- Thin Provisioning 
- 필요한 경우 GPGPU 와 같은 기능을 위한 PCI Pass-through 
- 필요한 경우 Software 기반 스위치 ( ex. Open vSwitch ) 와의 연동 여부 
- Dom0 로 통칭되는 가상화 OS 의 변경 적용 범위 
- 사용하고자 하는 클라우드 통제 시스템 ( 통칭 클라우드 스택 ) 과의 부드러운 연계 

등등의 내용이 있을 수 있다. 이러한 하이퍼바이저의 선택과 사용은, 벤더의 제품인 경우에도 벤더에 의지하기 보다는 내부의 경험있는 기술자에 의해 검증되는것이 필요하다. 일반적으로 논의되는 Vendor Lock-in 의 문제를 피하기 위해 다양한 하이퍼바이저가 검토되어야 할 필요가 있지만, 이 하이퍼바이저는 하드웨어와도 직접적으로 연계되는 부분이 제법 있으므로 보통 한번 선택하면 변경될 가능성이 거의 없다. 

하이퍼바이저라는건 기본적으로 VM 또는 인스턴스가 돌아가는 기본 장소이며, 이에 필요한 기능만을 선택하여 사용하는 것이 중요하다. 예를 들면, Citrix Xen server 는 공유 스토리지를 기반으로 클러스터링 하여 사용하는 것이 가능하지만, 별도의 클라우드 관리 스택을 사용하는 경우 공유 스토리지 없이 사용 하는 것도 가능할 수 있다. 이렇게 되면 XAPI 를 사용한 클러스터간 통신이 없어지게 되며, 별도의 라이브마이그레이션 등의 기능을 사용하지 않게 되므로 VM을 "만들고", "켜고", "끄고", "지우는" 기본 동작이 엔터프라이즈의 규모에서 보다 빠르고 안정적이게 동작 하는 것이 가능하다. 물론, 이는 여러가지 상황을 함께 고려해야 하므로, 단순히 본인의 의견을 수용하는 것 보다는 사용하고자 하는 오케스트레이션 도구, 즉 클라우드 스택과의 연동을 함께 살펴보는 것이 중요하겠다. 


3. 클라우드 관리 도구 

사실 각 클라우드의 특성은, 이 관리도구를 어떻게 구성하는가와 밀접한 관련이 있다. 이 관리 도구의 특성과 각 구성에 있어 지원하는 범위에 따라 컴퓨트 클라우드는 그 기능이 정해진다고 해도 무리가 없다. 이를 테면 다음의 핵심 기능들이 꼭 구비 되어야 컴퓨트 클라우드가 원하는 기능을 수행하는 클라우드 스택이라고 말할 수 있다. 

- 사용자 관리 도구. 
- 사용자가 가진 인스턴스에 대한 메타데이터 생성/보존/변경 
- 하이퍼바이저 클러스터의 전체 리소스 균등 분배 
- 골드 이미지/템플릿 등을 통한 리눅스/윈도우 등의 인스턴스 생성/삭제/종료/시작 
- 사용자 키 기반의 인스턴스 보안 설정 지원 ( 패스워드 및 admin 계정 등 ) 
- 필요한 경우 사용자 단위의 추가 Volume 생성/삭제/인스턴스 연결/해제 지원 
- 사용자 이미지 생성/백업을 위한 다양한 스토리지 연결 지원 
- 각 인스턴스 또는 리소스에 대한 헬스체크를 사용, 문제 발생시 메타데이터를 통한 VM 이동, IP/Volume 등 기존 자원의 자연스러운 매핑 
- VM 콘솔 
- 빌링이 필요한 경우 각 리소스 사용량에 대한 측정 지원 
- 위의 모든 기능을 사용 할 수 있는 API ( REST API ) 지원 

클라우드 스택이란건 ( cloud.com 의 제품만을 말하는 것이 아님 ) 결국 컴퓨트 클라우드에서 가상화 자원에 대한 "이동", "생성", "삭제", "연결", "중지", "시작", "접근", "백업", "복구" 등의 핵심적인 기능을 지원하는 도구를 말한다. 이러한 모든 동작은 하이퍼바이저를 제어하는 기능과, 현재 가지고 있는 자원에 대한 적절한 계산을 통한 분배 등을 지원하는 기능을 포함해야 한다. 

예를 들어, 처음 인프라를 구성하게 되는 경우 5개의 랙으로 시스템을 구비하였다가, 향후 20개의 랙으로 확장 했을때 기존 5개의 랙에서 동작하던 VM이 자연스럽게 나머지 20개의 랙으로 골고루 퍼질 수 있어야 한다. 현재 상용및 오픈 소스로 구성이 가능한 클러스터 모두 이러한 부분에 있어 제한 사항을 가지고 있는데, 어떠한 제약이 있는지는 직접 테스트 해 보는 것이 좋을 듯 하다. 

내 생각에 가장 좋은 구현의 방법은, 메타데이터를 통한 API 명령을 조합하여 위의 기능들을 구현한 관리 스택을 기업의 개발팀이 직접 만들어 내는 것이다. 물론 개발 그룹이 없는 기업의 경우에는 힘들겠지만, 국내 대부분의 클라우드를 위한 대규모의 자금을 사용할 수 있는 기업의 경우 자력으로 구현이 가능한 자회사를 가지고 있다고 생각한다. 물론, 여러가지 이슈로 쉬운 일이 아니긴 하지만, 그런 부분을 제외하고 개인적인 견해를 피력해 보자면, 다음과 같은 컨셉을 반영한 도구면 된다. 

- 기본적으로 하이퍼바이저 레벨에서 지원하는 클러스터링은 하지 않는다. 이는 클러스터 규모를 제한함으로서 확장 단위 구성에 난점이 있다. 
- 기존의 대규모 계산용 클러스터와 같은 구성을 취하도록 한다. 각 하이퍼바이저는 랙 내에서 독립적으로 동작하며, 이들 리소스에 대한 관리는 클라우드 스택에서 한다. 
- 클라우드 스택은 서비스를 위한 데이터베이스를 가지고, 이 데이터베이스에는 사용자 VM이 동작하는 위치, VM 생성에 사용된 서비스 오퍼링, iSCSI 또는 SAN 에서 해당 VM에 연결된 가상 Volume 의 위치, 네트워크 정보 및 인증 정보 등을 가진다. 또한 별도의 헬스체크 모듈을 통해 일정 시간 단위로 VM의 상태에 대해 파악한다. 
- VM에 문제가 발생한거나 사용자가 원하는 경우, 미리 계산된 리소스 ( 하이퍼바이저의 vCPU, RAM ) 등의 가용성에 따라 적절한 호스트에 VM을 신규로 생성하고, 기존의 VM은 삭제 처리 한다. 물론, 데이터베이서의 정보를 바탕으로 기존의 Volume 연결을 지원해 준다. 
- 백업이 필요한 경우 별도의 스토리지 또는 오브젝트 스토리지등의 클라우드로의 백업 경로를 지원한다. 보통 동일한 이미지를 사용하도록 강제하는 정책을 사용함으로서, 스냅샷 기반의 백업/복구를 보다 쉽게 처리하도록 한다. 


위와 같은 구조를 채택한다면, 아마존의 EBS와 같은 사용성을 제공함과 동시에 클라우드 스택이 지원하는 모든 하이퍼바이저를 어떠한 구조적 제약 없이 사용하는 것이 가능 할 것이다. 기본적으로 우리는 항상 VM에 하이퍼바이저를 통한 Volume 연결을 생각하지만, VM에 직접 iSCSI 또는 FCoE 와 같은 기술을 통해 직접 연결을 구성한다면 필요한 Volume 의 확보 및 인스턴스(VM) 의 장애에 대한 데이터 복구가 훨씬 자유로울 수 있을 것이다. 

이러한 클라우드 스택의 동작은 하이퍼바이저를 통제하는, 즉 가상화 시스템 상위에 위치하지만, 기업이 직접 구현해야 할 사용자 포털 및 관리 포털 보다는 하위에 위치한다. 따라서 클라우드 스택은 이러한 연계를 위해 API 및 포털로 부터 할당받은 커맨드 실행을 위한 Queue 등을 구현해 줄 필요가 있게 된다. 이 말이 의미하는 바는, 즉 클라우드 스택의 기능 범위를 제한 할 필요가 있다는 것이다. 아마존을 빗대어 이야기 해 보자면, SQS, EMR, RDS, ELB 와 같은 서비스를 모두 클라우드 스택 내에 녹여낼 필요는 없다. 물론 함께 동작 할 수 있다면 좋겠지만, 각 서비스별로 구분된 클러스터를 독자적으로 만들고, 이를 포털에서 API 로 통제하는 것이 더 좋다는 말이다. 이해를 돕기위해 추가적으로 설명 해 보자면, 

- 클라우드 스택은 VM 및 Volume 의 관리 및 (사설 또는 공인) IP 의 할당 까지만 관여한다. 
- ELB 와 같은 기능은 별도의 밸런서 팜을 구성하고, 여기에 포털에서 스택과의 연계를 통해 밸런서에 인스턴스를 등록 할수 있도록 한다. 
- SDB와 같은 서비스는 고객의 인스턴스가 위치하는 컴퓨트 클라우드 외에, 별도의 독립된 컴퓨트 클라우드 팜을 구성하고, 여기에 CouchDB / MongoDB 와 같은 서비스 클러스터와 API 를 구현, 역시 포털에서 사용자 별로 독립적으로 할당하도록 한다. 

뭐 당연한 이야기 같지만, ELB 와 같은 서비스의 경우 클라우드 스택 내에서 해결하려는 경우가 많다. 극단적인 예로 단일 기업이라면, 컴퓨트 클라우드를 구성하고 각 인스턴스에 공인 ( 또는 공인 처럼 취급되는 사설) IP 를 직접 연결, 상위 별도의 망에서 밸런싱 처리를 하는 구조를 취하는 것이 가능 할 수 있다. 


이처럼, 컴퓨트 클라우드를 위한 관리 스택은 바로 EC2 의 관리를 위한 모듈처럼 취급 되어야 하며, 그 자체로 적절한 기능의 제한이 있어야 한다. 한가지의 보다 더 극단적인 예는, Cloud.com ( 이제는 Citrix ) 의 구조를 사용한 작은 클러스터를 랙 별로 할당하고, 이를 상위 포털에서 Cloudstack 의 API 를 통제하는 형태로 구현하는 것도 가능할 것이다. 물론, 여기에서 발생하는 네트워크 문제는 여러분이 직접 해결 해야 할 것이다. 기회가 되면 소개하겠지만, 이미 이 주제에 대해 너무 많이 쓴 것 같다. 



4. 스토리지 

대부분의 현재 동작중인 퍼블릭 클라우드가 I/O 성능을 병목 구간으로 가지고 있다. 사실 컴퓨트 클라우드를 더 잘 사용하려면 가급적이면 I/O 접근을 사용하는 부분을 줄이는 것이 좋은데, 아무리 이 부분을 강조 하더라도 기존의 단일 서버처럼 사용하도록 개발을 하는 패턴을 전체 개발자에게 금지 시킬 수는 없다. 하여, 기본적으로 어느 정도까지는 그 I/O 성능을 보장해 줄 필요가 있는데, 이에 대한 요구 조건을 충족 하려면 다음과 같은 내용을 고려 해야 한다. 

- 클라우드에서 사용되는 스토리지는 대부분 네트워크를 통한 원격 스토리지이다. 
- 하이퍼바이저 내에서 동작하는 VM의 수량과 관계가 있다. 이는 또 물리적으로 다른 랙에 타겟 스토리지를 구성한 경우 랙간 레이스 컨디션이 발생 할 수 있다. 
- 클라우드 클러스터에서는 대부분의 I/O 가 랜덤하게 발생한다. 따라서, 스토리지의 성능이 매우 중요한데, 요청이 과다하게 몰리는 경우에도 timed out 이 발생하여 스토리지 세션이 끊어지지 않도록 관리하는 것이 매우 중요하다. 
- 따라서 분산이 매우 중요하다. Commodity H/W 의 개념에서, 한대의 스토리지가 분산을 지원하는 것 보다는 수많은 스토리지를 별도의 네트워크에 분산하고, 이를 클라우드 스택에서 관리하도록 하는 것이 현명 한 방법이 될 수 있다. 
- 성능 이슈로 분산했다면, 장애 극복을 위한 복구 및 복제 방침이 마련 되어야 한다. DRBD 와 같은 구성이 요구 될 수 있다. 
- 하나의 랙 또는 한대의 스토리지에 너무 많은 디스크 자원을 분배하지 않아야 한다. CPU 당 디스크, I/O 성능을 기반으로 한 네트워크 한계점 설정이 중요하다. 
- 이러한 형태의 클라우드 스토리지에서는 캐쉬빨이 별로 받지 않는다. 
- 비용이 허락한다면 Write Back 을 지원하는 HBA 를 사용하도록 한다. 


스토리지는 참으로 귀중한 자원이다. 특히 오브젝트 스토리지와는 다르게 일반 Volume 의 사용성을 가지며 인스턴스에 직접 연결되는 이러한 스토리지는, 반드시 사용자의 필요에 의해 요청된 경우에만 인스턴스에 연결해야 한다. 이 말은 기본 스토리지는 휘발성을 가지도록 구성해야 하며, 꼭 필요한 경우에만 이러한 원격 스토리지를 할당해야 부하를 줄일 수 있다는 말이 된다. 

만약 인스턴스의 로컬에 격렬한 계산을 통해 스크래치 파일 ( 일반적으로 삭제되도 되는 파일 ) 을 만들어 내는 경우, 이는 하이퍼바이저 로컬에 thin provisioning 된, VM이 살아 있는 동안에만 유지되는 가상 파일시스템을 사용하는 것이 맞다. 만약 이렇게 격한 I/O 를 원격 스토리지를 사용하도록 한다면, 아마존에서 발생했던 것과 유사한 장애를 경험하게 될 확률이 높다. 

이 부분의 설계시 중요하게 고려되어야 할 부분은, 원격 스토리지 볼륨의 사용은 Persistency 를 가지는 데이터에 한하며, 각 가상 인스턴스는 꼭 필요한 경우가 아니면 이러한 원격 스토리지를 할당하지 않도록 서비스를 설계 해야 한다. 이를테면, 인스턴스가 처음 생성되거나 재부팅 시에 항상 업데이트된 코드를 저장소로 부터 다운로드 받도록 구성하는 것과 같은 기법 말이다. 

아마존 서비스의 많은 부분이 미스테리이긴 하지만, 중요한건 기업용 사설 클라우드가 반드시 아마존과 동일한 형태로 모든 서비스를 구축 할 필요는 없다는 것이다. 그들의 주 목적은 모든 사용자를 위한 "Public" 클라우드 이며, 기업용은 거의 대부분의 경우 "Private" 클라우드 이기 때문이다. 

EBS 시스템에 관해 재미있는 번역 포스팅이 있는데, 한글도 있으므로 관심이 있다면 읽어보는 것도 좋을 듯 하다. 
http://jmlab.tistory.com/19

결국은, 클러스터 된 네트워크 스토리지이며 확장을 위해 L3 레벨로 구성되었음을 알 수 있다. 



5. 자동화 

이 부분을 의외로 쉽게 보는 분들이 많은데, 위의 0,1,2,3,4 가 모두 아키텍처로 녹아 있는 것이 바로 이 자동화가 되겠다. 하지만 시작부터 겁낼 필요는 절대 없다. 이는 하나의 거대한 어플리케이션을 만드는 것이 아닌, 요소별 필요한 파트를 지속적인 코드 테스트를 통해 구현해야 하는 것이다. 하드웨어 별로 다른 코드가 필요할 수 도 있으며, 향후 인프라 아키텍처의 변경으로 인해 수정되어야 할 필요가 있을 수 있다. 처음부터 완벽한 클라우드 또는 클러스터를 만드는 것은 현재로서는 거의 불가능하며, 반복된 자동화 코드의 수정을 통해 보다 안정된 서비스를 만들어 낼 수 있게 될 것이다. 

클라우드용 클러스터 구현을 위한 자동화는, 보통 다음과 같은 내용을 구현 해야 할 필요가 있다. 

- Internal Resources ( NTP, TFTP, DHCP, DNS, Package Mirror-site, Code repository, etc ) 
- PXE Boot  Support 
- OS Install 
- First-boot scripts
- Interface setup
- File system
- SSH keys
- Cluster setup
- Storage server 
- Log / Meetering / Monitoring , etc 

서비스에 따라 더 구성해야 할 것들이 있을 수 있지만, 기본적으로는 위와 같은 구성요소를 자동화 해야 할 필요가 있다. 클라우드의 용도에 따라, 그리고 하드웨어의 변경에 따라 코드의 변화가 필요할 것 같은 부분들은 변수처리를 통해 구현하는 것이 유리하다. 

자동화에 대해서는 별도의 책을 출간 준비중이므로, 조만간 좋은 내용을 소개 할 수 있지 않을까 한다. 




6. 클라우드 개발에 대한 인식 

사실 앞의 내용들 보다 이 부분이 가장 중요 할 수 있다. 기본적으로 상용 클라우드를 직접 덩어리째 사서 들고올 생각이 아니라면, 일정 부분 이상은 오픈소스를 사용해야 할 수 있다. 심지어 오픈소스가 아닌 상용을 구매하여 사용하는 경우라도 각 컴포넌트를 충분히 경험한 엔지니어가 많지 않다. 이 말은, 어떠한 경우에라도 문제가 발생했을때 올바른 지원을 받을 가능성이 낮아진다는 말이 된다. 게다가 이 클러스터는 수많은 요소가 서로 결합된 것이기 때문에, 스토리지와 하이퍼바이저의 벤더가 다른 경우 문제가 발생 했을때 서로 손가락질 할 가능성이 있다. 이는 네트워크도 마찬가지이며, 국내 벤더사들의 특성상 벤더 엔지니어는 벤더 제품에 종속적인 경우가 많고, 만약 다른 부분에 장애가 발생한 것을 명확히 파악 하더라도 입밖으로 내기 쉬운 환경이 아니다. 

이러한 환경적 제약은, 바꾸어 말하면 클라우드를 구현하려는 기업이 스스로 능력을 축적해야 한다는 말이 된다. 컨셉을 확인 할 수 있는 최소한의 규모의 랙을 가지고, 수많은 테스트를 통해 무엇이 최선인지, 그리고 어떻게 사용해야 하는지에 대해 내부 인력이 학습해야 한다. 그것을 바탕으로 자동화코드를 만들고, 만들고 부수는 작업을 반복했을때 비로소 동작하는 클라우드를 만드는 것이 가능해 진다. 

바로,  

아키텍처 디자인 --> 개발 환경 구성 --> 자동화 코드 개발 --> 설치 및 배포 --> 테스트 --> 재 디자인 --> 코드 개발 --> 배포 --> 테스트 

의 순환을 가급적 빠른 속도로 잘 짜여진 스케줄 안에서 진행해야  개발, 운영에 대한 노하우의 내재화가 가능 할 것이다. 
물론 이러한 구성에 있어 경험자의 리딩이 매우 중요하며, 전체 과정이 일반적인 기업 연구소에서 진행 되는 것 처럼 루즈하게 늘어져서는 안된다. 그러기 위해서는 현재 실무를 담당하고 있는 인프라와 개발진이 적절한 리더에 의해 협업해야 하며, 인프라가 개발을 무시하거나 개발이 인프라를 무시하는 일 없이 서로가 서로의 일이 어떻게 시스템에 반영되는지 긍정적인 자세에서 이해하는 것이 필요하겠다. 


사실, 국내의 모든 클라우드는 바로 이 부분이 쉽지 않기 때문에 문제가 발생하지 않나 싶다. 개발과 운영이 협력하면 참 좋을텐데, 이게 쉽지 않더라는...  아무튼. 


엄청나게 긴 포스팅이 되었는데, 실질적으로 코드는 하나도 없어서 좀 그런 것 같다. 또한 너무 컴퓨트 클라우드에 종속적인 이야기가 많은 듯 하지만, 결국 기업이 원하는 사설 클라우드에 필요한 구성은 컴퓨트와 스토리지 클라우드가 거의 대부분이다. 이 두개 클러스터의 아키텍처가 올바르다면, 나머지 아마존like 한 서비스를 올리는 것은 시간의 문제일 뿐이다. 다만, 굳이 아마존과 비슷한 서비스를 만들어야 할 필요가 있는지는 자문해 보아야 한다. 

각 개인에게 클라우드 서비스를 판매 할 것이 아니라 서비스를 클라우드 위에서 구현하는 것이 목적이라면, 해당 서비스에 맞는 "적절한 클러스터의 구현" 이 오히려 올바른 개발 방향이 될 것이다. 굳이 아마존 따라서 개발 하느라 가랭이 찢어지지 말고, 먼저 구현해야 할 올바른 클러스터를 준비하는 것이 맞지 않을까 생각해 본다.


( younjin.jeong@gmail.com , 정윤진 )