오늘날과 같이 데이터 볼륨이 빠르게 증가하는 상황에서, 클라우드 스토리지의 인기도 높아지고 있다는 건 놀랄 일이 아니다. 그 중에서도 가장 빠른 증가세를 보이는 데이터는 아카이브 데이터인데, 비용, 액세스 빈도, 보호 및 가용성을 포함한 다양한 요인을 고려할 때 클라우드 스토리지를 도입하기에 이상적인 영역이라 할 수 있다. 그러나 모든 클라우드 스토리지가 똑같지는 않다. 어떤 제공자는 주로 비용에 초점을 맞추는 반면, 또 어떤 제공자는 가용성이나 성능에 초점을 맞춘다. 단 한 가지 영역에만 집중하여 아키텍처를 설계하지는 않지만, 어떤 아키텍처가 일정한 특성을 구현하는 정도에 따라 대상 시장과 알맞은 사용 모델이 정해진다.

효용성의 관점을 고려하지 않고 아키텍처에 대해 논하기는 어렵다. 즉, 비용, 성능, 원격 액세스 등을 포함한 다양한 특성을 고려하여 아키텍처를 평가해야 한다는 뜻이다. 따라서 필자는 우선 클라우드 스토리지 모델을 평가하는 일련의 기준을 정의한 다음, 클라우드 스토리지 아키텍처 내의 몇 가지 흥미로운 구현을 탐색하는 방향으로 논의를 진행하겠다.

우선, 나중에 고유한 아키텍처의 특성을 탐색하기 위한 컨텍스트를 설정하기 위해 일반적인 클라우드 스토리지 아키텍처에 대해 논의해보자.

일반적인 아키텍처

클라우드 스토리지 아키텍처는 주로 매우 확장성이 뛰어난 멀티테넌트 방식으로 요청 시 스토리지를 제공한다는 개념으로 설계된다. 일반적으로(그림 1을 참조할 것), 클라우드 스토리지 아키텍처는 스토리지에 액세스하기 위해 API를 내보내는 프론트엔드로 구성된다. 기존의 스토리지 시스템에서는 이 API가 SCSI 프로토콜이지만, 클라우드에서는 이런 프로토콜이 계속 발전하고 있다. 클라우드에서는 웹 서비스 프론트엔드, 파일 기반 프론트엔드, 심지어 더 전통적인 프론트엔드(예: 인터넷 SCSI 또는 iSCSI)를 찾을 수 있다. 프론트엔드 이면에는 필자가 스토리지 논리라고 부르는 미들웨어 계층이 있다. 이 계층은 (지리적 배치를 고려하는) 전통적인 데이터 배치 알고리즘 위에 복제 및 데이터 감소와 같은 다양한 기능을 구현한다. 마지막으로, 백엔드는 데이터를 위한 실제 스토리지를 구현한다. 이는 특정 기능이나 전통적인 백엔드를 실제 디스크에 구현하는 내부 프로토콜일 수 있다.

그림 1에서 현재 클라우드 스토리지 아키텍처에 대한 몇 가지 특성을 볼 수 있다. 특정 계층에서는 어떤 특성도 제외되지 않지만 이 기사에서 다루는 특정 주제에 대한 가이드 역할을 한다. Table 1에 이런 특성의 정의가 정리되어 있다.

관리 효율성

클라우드 스토리지의 한 가지 주요 관심사는 비용이다. 클라우드에서 스토리지를 임대하여 사용할 때와 비교하여, 고객이 스토리지를 직접 구입하여 로컬에서 관리할 수 있다면 클라우드 스토리지 시장이 사라질 것이다. 그러나 비용은 실제 스토리지 에코시스템 자체의 비용과 이를 관리하는 비용이라는 두 가지 상위 레벨 카테고리로 구분할 수 있다. 관리 비용은 숨겨져 있어 바로 파악하기 어렵지만, 전체 비용에 장기적으로 계속 영향을 주는 요소이다. 이런 이유로, 클라우드 스토리지의 자동 관리 범위를 크게 넓혀야 한다. 시스템이 새 스토리지를 수용하기 위해 자동으로 자동 구성하는 스토리지를 새로 도입하는 능력과 오류가 있을 때 이를 찾아서 자동 복구하는 능력이 핵심이다. 미래에는 자율 컴퓨팅과 같은 개념이 클라우드 스토리지 아키텍처에서 핵심적인 역할을 할 것이다.

액세스 방법

클라우드 스토리지와 기존 스토리지의 가장 두드러진 차이점 중 하나는 스토리지에 액세스하는 수단이다(그림 2 참조). 대부분의 제공자는 여러 가지 액세스 방법을 구현하지만, 웹 서비스 API는 공통적이다. 많은 API가 REST 원리를 바탕으로 구현되는데, 이는 곧 HTTP을 바탕으로 개발된(HTTP를 전송 수단으로 사용) 오브젝트 기반 스킴을 의미한다. REST API는 Stateless이므로 간단하고 효율적으로 제공할 수 있다. 많은 클라우드 스토리지 제공자가 Amazon Simple Storage Service(Amazon S3), Windows Azure™ 및 Mezeo Cloud Storage Platform을 포함한 REST API를 구현한다.

웹 서비스 API의 한 가지 문제점은 클라우드 스토리지를 이용하기 위해 애플리케이션과의 통합이 필요하다는 점이다. 따라서 즉각적인 통합을 위해 클라우드 스토리지와 함께 공통적인 액세스 방법도 사용된다. 예를 들어, iSCSI와 같은 블록 기반 프로토콜과 마찬가지로 NFS/CIFS(Common Internet File System) 또는 FTP와 같은 파일 기반 프로토콜이 사용된다. Nirvanix, Zetta 및 Cleversafe와 같은 클라우드 스토리지 제공자가 이런 액세스 방법을 제공한다.

위에서 언급한 프로토콜이 가장 일반적이지만, 클라우드 스토리지에는 다른 프로토콜이 적합하다. 가장 흥미로운 것 중 하나가 WebDAV(Web-based Distributed Authoring and Versioning)이다. WebDAV 역시 HTTP를 기반으로 하며 웹을 읽고 쓸 수 있는 자원으로 사용한다. WebDAV의 제공자로는 다른 제공자 외에도 Zetta와 Cleversafe가 포함된다.

멀티프로토콜 액세스를 지원하는 솔루션도 찾을 수 있다. 예를 들어, ® Smart Business Storage Cloud는 같은 스토리지 가상화 인프라에서 파일 기반(NFS 및 CIFS) 및 SAN 기반 프로토콜을 모두 사용한다.

성능

성능에는 많은 측면이 있겠지만, 사용자와 원격 클라우드 스토리지 제공자 간에 데이터를 이동하는 능력이 클라우드 스토리지의 최대 해결 과제이다. 인터넷의 원동력이기도 한 TCP가 문제점이다. TCP는 피어 엔드포인트에서의 패킷 승인을 바탕으로 데이터 플로우를 제어한다. 패킷 손실 또는 늦은 패킷 도착에 대비하여 정체 제어 기능을 사용하며, 더 많은 글로벌 네트워킹 문제를 피하기 위해 성능이 더욱 제한된다. TCP는 글로벌 인터넷을 통해 소량의 데이터를 이동하는 데 이상적이지만, 라운드트립 시간(RTT)이 증가하는 대량의 데이터 이동에는 별로 적합하지 않다.

Amazon에서는 Aspera Software를 통해 문제 해결의 방정식에서 TCP를 제거함으로써 이 문제점을 해결한다. RTT 증가와 심각한 패킷 손실이라는 문제에 직면하여 대량의 데이터 이동 속도를 높이기 위해 FASP™(Fast and Secure Protocol)라는 프로토콜이 새로 개발되었다. TCP에 상대되는 전송 프로토콜인 UDP를 사용하는 것이 핵심이다. UDP를 통해 호스트는 FASP의 애플리케이션 계층 프로토콜로 정체 문제를 넘겨 정체를 관리할 수 있다(그림 3 참조).

FASP는 표준 (비가속) NIC를 사용하여 애플리케이션에 지원되는 대역폭을 효율적으로 사용하고 기존의 대량 데이터 전송 스킴에 따른 기본적인 병목 현상을 제거한다. 참고자료 섹션에서는 기존의 WAN, 대륙간 전송 및 손실이 많은 위성 링크를 능가하는 FASP 성능에 관한 몇 가지 흥미로운 통계 자료를 제공한다.

멀티테넌시

클라우드 스토리지 아키텍처의 한 가지 주요 특성으로 멀티테넌시라는 것이 있다. 이는 단순히 다수의 사용자(또는 다수의 "테넌트")가 스토리지를 사용한다는 뜻이다. 멀티테넌시는 사용자 간에 스토리지 네임스페이스가 분리되는 애플리케이션 계층에서 특정 사용자 또는 사용자 클래스를 위해 실제 스토리지가 분리될 수 있는 스토리지 계층까지, 클라우드 스토리지 스택의 많은 계층에 적용된다. 멀티테넌시는 특정 사용자에게 일정한 서비스 품질과 대역폭 분할을 허용하기 위해 스토리지에 사용자를 연결하는 네트워킹 인프라에도 적용된다.

확장성

다양한 방식으로 확장성을 평가할 수 있겠지만, 요청 시 클라우드 스토리지의 상태를 볼 수 있다는 점이 확장성이 지닌 가장 설득력 있는 요소이다. 스토리지 니즈를 확장할 수 있는 능력(사실은 필요에 따라 늘리거나 줄이는 것을 모두 포함하는 개념)은 곧 사용자가 부담할 비용 구조는 개선되고 클라우드 스토리지 제공자의 몫인 복잡도는 증가한다는 의미로 통한다.

스토리지 자체(기능 확장)는 물론이고, 스토리지에 할당된 대역폭(로드 확장)에 대해서도 확장성이 제공되어야 한다. 클라우드 스토리지의 또 다른 핵심 특성은 (마이그레이션을 통해) 일단의 클라우드 스토리지 데이터 센터보다 사용자에게 더 가깝게 데이터를 제공할 수 있는 데이터의 지리적 분배(지리적 확장성)이다. 읽기 전용 데이터의 경우, 복제와 배포도 가능하다(컨텐츠 제공 네트워크를 사용함). 이 점은 그림 4에 잘 나타나 있다.

내부적으로는 클라우드 스토리지 인프라를 확장할 수 있어야 한다. 서버와 스토리지는 사용자에게 아무런 영향도 주지 않고 크기를 조정할 수 있어야 한다. 관리 효율성 섹션에서 설명한 바와 같이, 자율 컴퓨팅이 클라우드 스토리지 아키텍처의 요구사항이다.

가용성

클라우드 스토리지 제공자가 사용자의 데이터를 보유한 경우 제공자는 사용자의 요청이 있을 때 그 데이터를 사용자에게 다시 제공할 수 있어야 한다. 그러나 네트워크 가동 중단, 사용자 오류 및 기타 불가피한 상황에서는 안정적이고 확정적인 방식으로 데이터를 제공하기 어려울 수 있다.

정보 분산과 같이, 가용성 문제를 해결하기 위한 몇 가지 흥미롭고 새로운 스킴이 있다. 사설 클라우드 스토리지(이후에 논의함)를 제공하는 회사인 Cleversafe에서는 물리적 장애와 네트워크 가동 중단이 발생할 경우의 데이터 가용성을 높이기 위해 IDA(Information Dispersal Algorithm)를 사용한다. 원래는 Michael Rabin이 통신 시스템용으로 작성한 IDA는 데이터가 없어지는 경우 데이터 재생성 목적으로 Reed-Solomon 코드를 사용하여 데이터를 여러 조각으로 분리할 수 있게 해주는 알고리즘이다. 더욱이 IDA를 사용하면 주어진 데이터 오브젝트를 4개의 조각으로 분리하고 1회의 실패를 허용하거나 20개의 조각으로 분리하고 8회의 실패를 허용하는 방식으로 데이터 조각 수를 구성할 수 있다. RAID와 유사하게, IDA에서는 원본 데이터의 서브세트에서 데이터의 재생성을 허용하되 (허용되는 실패 횟수에 따라) 오류 코드를 위한 일정한 양의 오버헤드가 포함된다. 이 점은 그림 5에 잘 나타나 있다.

Cauchy Reed-Solomon 정정 코드와 함께 데이터를 여러 조각으로 분리할 수 있는 기능을 사용하여 지리적으로 떨어진 복수의 사이트에 이들 조각을 분배하여 저장할 수 있다. 여러 개의 조각(p)과 여러 차례 허용되는 실패(m)를 감안할 때, 결과적 오버헤드는 p/(p-m)이다. 따라서 그림 5의 경우 p = 4이고 m = 1이므로 스토리지 시스템에 대한 오버헤드는 33%이다.

IDA의 부정적인 면은 IDA가 하드웨어 가속 없이 처리 작업이 많다는 점이다. 복제는 또 다른 유용한 기술로서 다양한 클라우드 스토리지 제공자가 복제를 구현한다. 복제를 위해서는 대량의 오버헤드(100%)가 불가피하지만, 간단하고 효율적으로 제공할 수 있는 기술이기도 하다.

제어

고객이 자신의 데이터를 저장하는 방법과 그와 관련된 비용을 통제하고 관리하는 능력이 중요하다. 수많은 클라우드 스토리지 제공자가 사용자에게 더욱 강력한 비용 통제 능력을 제공하는 제어 수단을 구현한다.

Amazon에서는 RRS(Reduced Redundancy Storage)를 구현하여 사용자에게 전체 스토리지 비용을 최소화할 수 있는 수단을 제공한다. Amazon S3 인프라 내에서 데이터가 복제되지만, RRS를 사용함으로써 데이터 손실 가능성을 안은 채 데이터 복제 횟수가 줄어든다. 이는 다시 작성할 수 있거나 다른 곳에 사본을 저장해두는 데이터에 이상적이다. 또한, Nirvanix는 정책 기반 복제 기능을 제공하여 데이터 저장 방법 및 위치를 더욱 세부적으로 제어한다.

효율성

스토리지 효율성은 클라우드 스토리지 인프라의 중요한 특성으로서, 특히 전체 비용에 초점을 맞춘다. 다음 섹션에서 비용 문제를 구체적으로 거론하겠지만, 이 특성은 비용보다는 사용 가능한 자원의 효율적인 사용에 더 중점을 둔다.

스토리지 시스템의 효율성을 더욱 높이려면 더 많은 데이터를 저장해야 한다. 데이터 감소가 일반적인 해결책이며, 원본 데이터를 줄여 필요한 실제 공간을 줄이겠다는 것이다. 이런 목표를 달성하기 위한 두 가지 수단이 다른 표시 방법을 사용하여 데이터를 인코딩함으로써 데이터를 줄이는 압축과 동일한 데이터 사본이 존재하지 않도록 중복 데이터를 제거하는 중복 제거이다. 두 방법 모두 유용하지만, 압축에는 인프라 안팎으로 데이터를 다시 인코딩하는 처리 작업이 필요한 데 반해, 중복 제거에는 중복 데이터를 검색하기 위해 데이터의 시그니처를 계산하는 작업이 필요하다.

비용

클라우드 스토리지의 가장 두드러진 특성 중 하나가 클라우드 스토리지를 사용하여 비용을 줄일 수 있다는 점이다. 여기에는 스토리지 구입 비용, 가동 비용, (드라이브 오류 시) 복구 비용과 아울러 관리 비용까지 포함된다. 이런 관점에서 클라우드 스토리지를 볼 때(SLA 및 스토리지 효율성 증가 포함), 클라우드 스토리지가 어떤 사용 모델에서는 이익이 될 수 있다.

Backblaze라는 회사에서 제공하는 클라우드 스토리지 솔루션을 살펴보면 흥미로운 점을 발견할 수 있다(세부사항은 참고자료 참조). Backblaze는 클라우드 스토리지 오퍼링을 위한 저가의 스토리지 빌드에 착수했다. Backblaze POD(스토리지 쉘프)를 사용하면 US$8,000 미만의 가격으로 4U 격납장치에 67TB의 데이터를 저장할 수 있다. 이 패키지는 4U 격납장치, 마더보드, 4GB DRAM, SATA 제어기 4개, 1.5TB SATA 하드 디스크 45개, 전원 공급 장치 2개로 구성된다. Backblaze는 마더보드에서 HTTPS 및 Apache Tomcat을 사용하여 Linux®(JFS를 파일 시스템으로 사용)와 GbE NIC를 프론트엔드로 가동한다. Backblaze의 소프트웨어에는 데이터 보호를 위해 중복 제거, 암호화 및 RAID6이 포함된다. (사용자가 스스로 만드는 방법을 자세히 설명한) Backblaze의 POD에 대한 설명을 보면 클라우드 스토리지가 실용적이고 비용 효율적인 옵션이 될 만큼 기업이 스토리지 비용을 얼마나 절감할 수 있을지 알 수 있다.

위로

클라우드 스토리지 모델

지금까지 주로 클라우드 스토리지 제공자에 대해 설명했지만, 사용자가 데이터에 대한 제어 능력을 유지할 수 있게 해주는 클라우드 스토리지 모델이 있다. 클라우드 스토리지는 세 가지 카테고리로 발전했는데, 그 중 하나는 비용 효율적이고 안전한 옵션을 위한 두 카테고리의 병합을 허용한다.

이 기사에서는 (장기 또는 단기 저장과 인프라 내에서 사용되는 네트워킹 대역폭의 측면을 모두 포함하여) 스토리지 인프라를 임대 가능한 상품으로 제공하는 공용 클라우드 스토리지 제공자에 대해 설명하는 데 많은 부분을 할애했다. 사설 클라우드는 공용 클라우드 스토리지의 개념을 사용하지만, 사용자의 방화벽 내부에 안전하게 임베드 가능한 양식으로 되어 있다. 마지막으로, 하이브리드 클라우드 스토리지에서는 어떤 데이터를 개인용으로 유지해야 하고 어떤 데이터를 사설 클라우드 내에서 안전하게 보호할 수 있을지 정의하는 정책을 설정하여 두 모델을 병합할 수 있다(그림 6 참조).

그림 6에 클라우드 모델이 도식적으로 표시되어 있다. 공용 클라우드 스토리지 제공자로는 (SaaS를 제공하는) Amazon 및 Nirvanix와 같은 회사가 있다. 사설 클라우드 스토리지 제공자로는 (내부 클라우드용 소프트웨어 및/또는 하드웨어를 빌드하는) IBM, Parascale 및 Cleversafe와 같은 회사가 있다. 마지막으로, 대표적인 하이브리드 클라우드 제공자로는 Nirvanix 및 Egnyte가 있다.

위로

추가 정보

클라우드 스토리지는 기업 내부에서 스토리지를 생성, 액세스 및 관리하는 방식을 새롭게 정의하는 스토리지 모델의 발전된 형태이다. 클라우드 스토리지는 오늘날 유력한 소비자 기술이기도 하지만, 엔터프라이즈급의 품질을 향해 빠르게 발전을 거듭하고 있다. 하이브리드 클라우드 모델을 사용하는 기업에서는 로컬 데이터 센터에서 기밀 데이터를 유지 및 관리하는 한편, 비용 절감과 지리적 분산을 통한 보호를 위해 기밀 수준이 낮은 데이터는 클라우드 환경에서 관리할 수 있다. 클라우드 스토리지 제공자와 그들의 고유 기술에 관한 정보는 참고자료에 제시된 링크를 통해 확인할 수 있다.

참고자료

교육

• 관리 효율성은 클라우드 스토리지 인프라의 가장 중요한 요소 중 하나다. 비용 효율성을 위해, 클라우드 스토리지 인프라는 자동 관리되어야 하고 자율 컴퓨팅 원리를 구현해야 한다. IBM Research에서 자율 컴퓨팅에 대한 자세한 내용을 읽어보자.
  
  
• REST API는 클라우드 스토리지 인프라에 액세스하기 위해 널리 사용되는 방법이다.
  
  
• REST만큼 대중적이지는 않지만, WebDAV 스펙도 효율적인 클라우드 스토리지 인터페이스로 사용된다. Egnyte Cloud File Server는 WebDAV를 클라우드 스토리지 인프라에 대한 인터페이스로 구현한다.
  
  
• IBM Smart Business Storage Cloud는 기업용 클라우드 스토리지에 대한 흥미로운 전망을 보여주는 솔루션이다. IBM의 스토리지 클라우드는 엔터프라이즈 설정을 위해 고성능 온 디맨드 스토리지를 제공한다.
  
  
• 액세스 방법은 사용자가 클라우드 스토리지 인프라에 클라이언트 측 시스템을 통합할 방법을 결정하므로 클라우드 스토리지의 중요한 요소 중 하나다. 파일 기반 API를 구현하는 제공자로는 Nirvanix와 Zetta가 있다. iSCSI 기반 인터페이스를 구현하는 제공자로는 Cleversafe와 Cloud Drive가 있다.
  
  
• Aspera Software는 이 애플리케이션에서 TCP의 단점이 있어 인터넷을 통한 대량 전송에 도움을 주기 위한 프로토콜을 새로 작성했다. A Faster Way to the Cloud에서 Fast and Secure Protocol에 대해 자세히 파악할 수 있다.
  
  
• Backblaze는 저가의 클라우드 스토리지를 자체적으로 빌드하기로 하고 디자인 작업을 수행하여 소프트웨어를 공개했다. Petabytes on a budget: How to build cheap cloud storage에서 Backblaze와 Backblaze의 혁신적인 스토리지 솔루션에 대해 자세히 알아보자.
  
  

제품 및 기술

• IBM 제품 평가판을 다운로드하고 Information Management 및 DB2®, Lotus®, Rational®, Tivoli® 및 WebSphere®의 애플리케이션 개발 도구 및 미들웨어 제품을 사용해 볼 수 있다.
  
  

토론

• developerWorks 포럼 & 블로그를 통해 developerWorks 커뮤니티에 참여하자.
  
  

필자소개

M. Tim Jones는 임베디드 펌웨어 아키텍트이자 Artificial Intelligence: A Systems Approach, GNU/Linux Application Programming(2판이 나왔다), AI Application Programming(2판이 나왔다), BSD Sockets Programming from a Multilanguage Perspective의 저자이기도 하다. Jones의 공학 배경은 정지 위성을 위한 커널 개발에서 시작해 임베디드 시스템 아키텍처와 네트워크 프로토콜 개발에 이르기까지 다양한 분야를 아우른다. Jones는 콜로라도 주, 롱몬트 소재 Emulex 사에서 컨설턴트 엔지니어로 활약한다.

아티클 순위

의견

위로

목차

• 일반적인 아키텍처
• 클라우드 스토리지 모델
• 추가 정보
• 참고자료
• 필자소개
• 의견