클라우드 스토리지 기술동향—페타스케일을 넘어서

국내에서는 인터넷 포털, 클라우드, 통신 사업자 등에서 페타스케일 스토리지 구축 사례가 증가하고 있다.

대표적인 인터넷 포털 업체인 NHN, 다음커뮤니케이션즈는 자체적으로 페타바이트 규모를 지원하는 분산 파일 시스템을 개발하여 자사 서비스에 활용하고 있으며, 한국전자통신연구원은 자체 개발한 기술의 보급 및 발전에 힘쓰고 있다. 현재까지 개발된 분산 파일 시스템의 기술적 특징을 비교하면 <표 1>과 같다[6]-[8].

현재까지 국내 분산 파일 시스템은 누적 데이터 규모가 100페타급, 100억개 파일 이상으로 증가함에 따라 독립적인 수십 페타스케일 스토리지를 다수 구축함으로 인한 관리 복잡도 증가, 내결함성 지원을 위한 데이터 3중화에 따른 비용 증가 등의 문제에 직면하고 있다.

<표 1>

국내 페타스케일 스토리지 SW 기술

국외에서는 클라우드 컴퓨팅 사업자, 빅데이터 분석, 슈퍼컴퓨팅 등에서 페타스케일 스토리지 구축이 증가하고 있으며, Intel, Apache, Redhat 등이 공개 SW 기반의 페타스케일 분산 파일 시스템을 개발하여 배포하고 있다[9]-[13]. 이러한 분산 파일 시스템도 국내의 경우들과 마찬가지로 누적 데이터 증가에 따른 관리 복잡도 증가, 비용 증가 등 동일한 한계에 직면하고 있는 것으로 알려져 있다[<표 2> 참고].

<표 2>

국외 페타스케일 스토리지 SW 기술

데이터 확장성의 지원은 성능 저하를 최소화하면서 얼마나 많은 서버들을 연결하여 저장 공간을 확보할 수 있을 것인가와 관련이 있다.

이에 대한 분석을 하기에 앞서, 시스템 규모 확장을 위해서 필요한 구성 요소들이 어느 정도 증가되어야 하는지 이해하기 위해 엑사스케일 스토리지를 지원하는 경우를 고려하여 예측해 보았다[<표 3> 참고].

<표 3>

엑사스케일 스토리지 구성 요소의 기술 혁신도 예측

그 결과, 디스크 고용량화를 감안하더라도 10 페타바이트 스토리지 구축에 필요한 서버, 디스크, 연결망의 부품 수와 전력, 공간 등 거의 모든 구성 요소들이 엑사스케일 스토리지를 위해서는 약 10배 이상 증가할 것으로 예상된다.

<표 3>에서 볼 수 있듯이, 수백 노드 정도로 구성되는 페타스케일 연결망의 규모를 대용량화하기 위해서는 노드 수가 천 노드 이상 확장될 것으로 예측되므로 데이터 확장성 지원을 위해서는 그 규모에 적합한 확장성을 갖는 스토리지 연결망 구조가 필수적으로 고려되어야 한다. 또한, 운영비용도 데이터 확장성에 직접적인 영향을 미친다.

그러므로 데이터 확장성에 관한 이슈들은 스토리지 연결망 확장성과 운영비용 부분으로 나누어 분석한다.

가. 스토리지 연결망 확장성

지금까지 페타스케일 스토리지에서는 스위치를 사용한 트리(fat-tree) 토폴로지를 주로 이용해 왔다[14]. 이 토폴로지는 아직까지 스토리지 연결망으로 가장 일반적으로 사용되지만, 사전 규모 예측에 따른 설계가 필수적으로 선행되어야 하며, 페타스케일에서 보다 큰 규모로의 점진적인 확장 등 최초 설계 규모를 벗어난 확장 시 전면적인 트리 재구성에 대한 부담이 발생할 수 있다.

(그림 2)에서는 트리 토폴로지 기반으로 엑사스케일 스토리지를 구성할 경우의 연결망 구성을 예로 도출해 보았다. 그 결과, 36포트 스위치를 가정하더라도 규모 증가에 따른 연결망이 매우 복잡해짐을 알 수 있다.

(그림 2)

트리 토폴로지 기반의 엑사스케일 스토리지 연결망 구성(36포트 스위치 가정)

엑사스케일 컴퓨팅 시스템들을 참고하면[3][4], 수천~수만 노드 규모의 연결망 구축 시 트리 토폴로지의 확장성 한계를 극복하기 위한 대안으로 메쉬, 2D/3D 토러스 구조나 하이퍼큐브 토폴로지를 고려해 볼 수 있다 [(그림 3) 참고][15][16].

(그림 3)

확장성 제공 가능한 네트워크 토폴로지 대안들

* <출처>: RIKEN, Fujitsu, Limited, ”Japan's Next-Generation Supercomputer Configuration is Decided: Architecture Based on Scalar System,” July 2009, http://www. fujitsu.com/global/about/resources/news/press-releases/2009/0717-01.html

이 토폴로지들의 기술적인 특징들을 분석하고 한계점을 정리하면 <표 4>와 같다[14]-[16].

<표 4>

스토리지 연결망 대안 비교

나. 시스템 운영비용

운영비용도 데이터 확장성을 위해서 고려해야 할 중요한 요소이다. 스토리지 시스템의 운영비용은 서버와 스위치를 포함한 구성 요소들의 개수, 차지하는 공간, 사용 전력의 양과 직접적인 관련이 있다.

<표 5>는 엑사스케일 스토리지 구축을 예로 들어서 트리와 토러스 토폴로지 기반의 스토리지 서버 구축 비용과 네트워크 구축 비용을 계산해 본 것이다. 스토리지 서버의 수는 <표 3>을 참고하여 4U 크기의 서버 1,000대를 기준으로 하였다.

<표 5>

트리와 토러스 구조 상의 서버 및 네트워크 구축 비용 예측(엑사스케일 클라우드 스토리지 규모 가정)

<표 5>를 통해서 알 수 있듯이, 운영비용은 스토리지 연결망에 의해서 큰 차이가 난다. 스토리지 연결망은 스토리지 서버 운영비용의 약 10% 정도로 상당히 큰 비중을 차지하고 클라우드 스토리지의 규모 확장 시에 비용 부담이 발생하기 때문에 더 경제적인 스토리지 연결망 기술을 도입할 필요가 있다. 트리 구조의 대안으로 고려할 수 있는 메쉬, 토러스, 하이퍼큐브 등을 이용하면 연결망 구축 비용을 절반 정도 절감할 수 있을 것으로 기대된다. 단, 이 경우는 인접한 노드만이 직접 통신할 수 있는 토폴로지 한계를 해결하는 기술에 대한 도전이 필요하다.

(그림 4)는 Cluster design에서 제공하는 툴을 이용해 트리와 토러스 토폴로지 상의 노드 수 증가에 따른 비용 증가 정도를 살펴보았는데[17], 토러스 구조에서의 비용이 가장 낮음을 알 수 있다.

(그림 4)

트리와 토러스 토폴로지 기반 망 구축 비용 예측(Cluster Design 툴 사용)

메타데이터 확장성은 시스템에서 지원 가능한 파일 수와 메타데이터 연산 성능에 의해 표현될 수 있다.

<표 6>은 엑사스케일 스토리지를 구축한다고 가정할 때 현재 기술에 비해 지원해야 하는 파일 수와 메타데이터 연산 성능을 예측해 보았는데, 거의 100배 정도 증가할 것으로 예상된다.

<표 6>

엑사스케일 스토리지 구성 요소의 기술 혁신도 예측

이와 같이, 클라우드 스토리지의 용량이 확장됨에 따라 파일 메타데이터의 개수 및 처리 성능도 비례하여 개선되어야 하는 것은 메타데이터 확장성을 위해서는 기본적으로 해결되어야 하는 이슈이다.

하지만, (그림 5)에서 보는 바와 같이 수십억 개 파일들을 처리할 수 있는 현재의 메타데이터 처리 기술로는 용량의 증가에 따른 메타데이터 처리 성능이 따라가지 못하고, 엑사스케일까지 확장되면 메타데이터 처리가 불가능한 수준이다. 따라서 메타데이터 확장성 지원을 위해서는 기본적으로 이 이슈가 해결될 수 있어야 한다.

(그림 5)

클라우드 스토리지에서 메타데이터 확장성 한계

이와 관련된 현재의 메타데이터 확장성 지원 기술들을 살펴보면, 메타데이터 처리 방식은 크게 중앙집중 방식, 분산 인덱스 방식, 분산 해싱 방식으로 나눌 수 있다. 현재의 메타데이터 확장성과 관련한 기술들의 특징 및 한계는 <표 7>과 같다[9]-[13].

<표 7>

메타데이터 확장성 기술 비교

실제로 중앙 집중형 메타데이터 관리 기술과 분산형 메타데이터 관리 기술에 대해 메타데이터 성능 측정을 수행해 보았다. Lustre, Google File System, Hadoop File System 등을 포함한 중앙 집중형 메타데이터 관리 방식에서 단일 메타데이터 서버 구조의 처리 성능은 1,000~10,000ops, 저장 가능한 파일 개수는 수 백만~수 천만 개가 한계인 것으로 나타났다.

그리고 Ceph, Gluster 등과 같은 분산형 메타데이터 관리 방식은 메타데이터 처리 성능과 파일 수를 선형 확장시키는 메타데이터 분산 기술이 시도되었으나 성능 확장성 한계, 파일 누적에 따른 성능 저하, 낮은 완성도 등 기술적인 한계가 존재한다[(그림 6) 참조].

(그림 6)

노드 수 증가에 따른 Gluster의 분산 메타데이터 성능

<출처>: Gluster, “Gluster Scale-Out Tests: An 84 Node Volume,“ May 9th, 2014, http://blog.gluster.org/2014/05/ gluster-scale-out-tests-an-84-node-volume/

클라우드 스토리지의 규모가 커질수록 디스크 등의 부품 수 증가로 인해 장애 발생 주기(MTTF)가 장애 복구 시간(MTTR)보다 짧아지므로 데이터 내결함성 확보를 위해 비용 대비 효율적인 복구 기술이 요구된다.

이와 관련하여 연간 디스크 고장율 평균 3%를 적용할 경우 디스크 장애 발생률을 예측해 보면, (그림 7)과 같이 페타스케일 수준은 약 6일에 1회 주기로 발생하지만, 그 주기가 짧아져 엑사스케일 규모까지 확장되면 수 시간 정도의 짧은 주기로 장애가 발생할 것으로 예상된다.

(그림 7)

클라우드 스토리지에서 디스크 장애 발생률 (페타스케일 vs. 엑사스케일)

현재의 데이터 내결함성을 지원하기 위한 기술 수준을 조사한 결과는 <표 8>과 같다[10][13][18]-[20].

<표 8>

데이터 내결함성 기술 비교

<표 8>을 참고하면, 기존 RAID 기술은 서버 장애에 대비할 수 없고 디스크 고용량화에 따라 평균 디스크 장애 복구 시간이 24시간 이상 걸려 클라우드 스토리지의 규모가 현재보다 커지면 적용이 힘들 것으로 판단된다.

두 번째 방법인 분산 파일 시스템에서 일반적으로 사용하는 복제(replication)는 데이터 3중화에 따른 낮은 스토리지 효율(33%)로 스토리지 구축 비용을 증가시킬 수 있다.

또한, 스토리지 효율을 70% 이상으로 개선할 수 있는 장점 때문에 최근 확산되고 있는 이레이저 코딩(Erasure Coding: EC) 기술은 실제로는 읽기 전용, 낮은 4K 랜덤 I/O 성능, 24시간 이상 평균 장애 복구 시간 등 기술적인 한계를 노출하고 있는 상태이다.

(그림 8)은 EC의 기록 성능을 측정한 결과이다. 복제 방법을 이용하는 GLORY-FS와 비교할 때, Ceph과 Gluster의 EC 기반 성능은 128K 순차, 4K 랜덤, 4K 순차 성능 모두 낮음을 알 수 있다. 특히 4K 랜덤 I/O의 경우에는 EC 기반 성능이 매우 저조하여 EC 기술을 고용량 클라우드 스토리지에 적용하기 위해서는 이 점도 극복되어야 할 대상으로 고려되어야 한다.

(그림 8)

복제 방식과 EC의 성능 한계 비교(GLORY-FS vs. Ceph vs. Gluster)

현재 메타데이터 내결함성 지원을 위해서는 공유 디스크 및 복제 기술에 기반하고 있으나, 공유 디스크 도입 비용 절감, 단일 볼륨당 매우 큰 파일 개수(예, 엑사스케일에서는 1조 개 파일) 지원, 성능 저하 최소화 등 기술적인 이슈 극복이 필요하다.

현재의 메타데이터 내결함성 지원과 관련한 기술 수준은 <표 9>와 같다[9]-[13].

<표 9>

메타데이터 내결함성 기술 비교

<표 8>을 참고하면, active/standby 서버 기반으로 메타데이터가 저장된 외장 스토리지를 공유하는 구조는 메타데이터 서버와 외장 스토리지가 필요하며, 서버 처리의 성능 한계로 최대 수천만 개 파일 이상을 처리하기에는 어려움이 있을 것으로 예상된다. 외장 스토리지 없이 메타데이터를 active/standby 서버 간에 네트워크를 통해 복제하는 여러 방식들이 있으나, 지원 파일 수 제한(최대 수천만 건), 완성도, 성능 저하 등의 한계가 존재한다.

현재의 연결망 내결함성 지원과 관련하여 기술들의 기술적 특징 및 한계는 <표 1>과 같다[14]-[16].

<표 10>

연결망 내결함성 기술 비교

현재 망 연결에 많이 사용되고 있는 트리 토폴로지를 보다 큰 규모의 클라우드 스토리지로 확장할 경우 내결함성을 위해 스위치 다중화 구성이 복잡하며 스위치 장애로 인한 성능 저하 및 접속 단절 범위가 광범위해지는 부담이 있다.

계층 스위치 다중화 구성(fat-tree)을 통해 스위치/링크 장애에 대한 내결함성 확보가 가능하나 다중화로 인한 스위치 개수 증가 및 스위치 장애 시 하위 계층의 성능 저하 혹은 연결 단절 현상 파급 문제가 존재할 수 있다[(그림 9) 참고].

(그림 9)

트리 구조에서의 연결망 내결함성 지원 구조

<출처>: M. Al-Fares and et al., “A Scalable, Commodity Data Center Network Architecture,” SIGCOMM, Aug. 2008, http://ccr.sigcomm.org/online/files/p63-alfares.pdf

반면, 메쉬, 토러스, 하이퍼큐브 토폴로지에서는 모든 노드가 별도의 네트워크 스위치 없이 인접한 노드와 다차원 방향으로 직결되는 방식으로서, 노드 및 링크 장애 시 추가 비용 없이 인접한 우회 경로를 통한 내결함성 확보가 가능할 것으로 예상된다. (그림 10)의 토러스 토폴로지 구조를 참고하면, 특정 서버나 네트워크 링크에 장애가 발생할 경우 우회 경로 생성으로 내결함성 지원이 가능함을 알 수 있다.

(그림 10)

토러스 구조에서 연결망 내결함성 지원 구조