“컨테이너에 맞는 스토리지 필요하다”

코어OS가 컨테이너 기반 인프라에 최적화된 분산 스토리지 기술을 오픈소스로 풀었다. 현존하는 스토리지 기술은 컨테이너와 마이크로서비스 환경에 적합하지 않다는 주장과 함께 말이다.

지난 1일 코어OS는 분산 스토리지 시스템 ‘토러스(Torus)’의 프로토타입 버전을 오픈소스로 공개했다.[토러스 깃허브 바로가기]

토러스는 컨테이너 클러스터 인프라에 맞게 만들어진 스토리지다. 컨테이너 기반의 마이크로서비스 아키텍처 환경에서 확장성과 민첩성, 고가용성을 제공한다.

컨테이너관리툴인 쿠버네테스로 제어되는 클러스터에서 신뢰성과 확장성을 갖춘 스토리지로 설계됐다.

코어OS 토러스 개념도

코어OS는 분산 시스템이 인터넷을 더 안전하고 신뢰성있게 만드는 토대라고 강조했다. 모듈 방식이 증가하는 워크로드를 제어하고, 쉽게 다른 요소를 조합하게 해주며, 웹스케일 컴퓨팅의 도전과제를 해결하는 기초라고도 덧붙였다.

코어OS 측은 “다이나믹하고 빠르게 반복되는 컨테이너의 세계에서 데이터의 지속성과 내구성을 어떻게 보장할 것인가”란 질문을 던졌다.

코어OS는 현존하는 스토리지 시스템이 컨테이너 인프라에 적합하지 않다고 주장했다. 컨테이너 클러스터에 시중의 스토리지 솔루션을 적용하기 어렵고 비싸다는 것이다.

상용 분산 스토리지 시스템은 대형 머신으로 작은 클러스터를 만들도록 설계됐고, 구글의 웹스케일 방식은 저가 소형머신으로 대규모 클러스터를 만들도록 설계됐다. 때문에 웹스케일 방식의 클라우드 애플리케이션에 상용 스토리지를 쓰려면 비용증가에 직면하고, 특정 하드웨어와 소프트웨어에 종속된다고 주장했다.

코어OS는 자사에서 3년간 개발한 키벨류 스토리지 ‘etcd’ 개발 과정에서 분산 컨센서스(consensus, 합의도출) 문제를 해결한 경험을 들었다. 분산 컴퓨팅은 정보를 쪼개 각 조각을 동시에 연산한 뒤 종합된 결과물을 내놓게 되는데, 컨센서스는 항상 같은 결과물을 내도록 하는 것이다.

분산 컴퓨팅 환경에서 데이터 조각들은 여러 머신에 퍼져있으며, 비동기식으로 각각 업데이트된다.

이런 가운데 신뢰성있는 분산 스토리지의 문제는 매우 어려운 문제다. 분산 스토리지를 올바르게 실행하기 위해 컨센서스 알고리즘이 요구되며, 합의도출 오류는 심각한 결과를 초래할 수 있다.

분산 스토리지 시스템의 데이터세트는 종종 매우 크고, 스토리지 에러는 탐지하기 어려운 정도로 확산된다. 데이터 크기의 증가는 또한 백업, 아카이브, 장애대비수단 등 애플리케이션 에러를 방지하는 여러 방식을 바꾸고 있다.

코어OS는 “컨테이너 인프라에 레거시 스토리지를 연결할 수 있지만, 분산 애플리케이션을 구동하는 컨테이너 클러스터에 스토리지를 제공하는 문제는 쉽지 않은 일”이라고 강조했다.

토러스는 etcd를 이용해 수천건의 프로덕션 배포를 보증하고, 메타데이터를 관리하면서 컨센서스를 유지한다. 역동적인 컨테이너 환경에 최적화됐다는 주장은 여기에 기반한다.

통상 컨테이너 인프라는 매우 동적인 환경이다. 컨테이너로 만든 마이크로서비스는 자동으로 확장돼야 하고, 지속적으로 딜리버리돼야 한다. 한 마이크로서비스가 장애를 겪으면, 미리 만들어져있는 복제본이 원본의 역할을 대체한다.

컨테이너 기반 마이크로서비스에서 퍼시스턴트 스토리지는 마이크로서비스의 시작, 정지, 업데이트, 클러스터 내 다른 노드로 이전 등에서 불변성을 유지해야 한다.

모노리틱 애플리케이션에 스토리지를 제공하는 것처럼 단순하지 않다. 볼륨을 할당해서 컴퓨팅에 저장공간을 마운트하는 수준에 그치지 않고, 무수한 연산과 변경에 발빠르게 대응해줘야 시스템이 죽지 않는다.

마이크로서비스가 작동할 때 데이터와 컴퓨팅의 연결이 끊어지면 바로 오류다. 작은 데이터가 무수하게 저장소를 드나들기 때문에 전통적인 컨트롤러 기반의 외장형 스토리지일 경우 네트워크 부하도 문제다.

토러스는 분산된 블록 스토리지나 대형 오브젝트 스토리지 모두를 제공한다. 구글에서 만든 고(Go) 언어로 작성됐고, rRPC 프로토콜로 통신한다.

컨테이너와 쿠버네테스 같은 클러스터 오케스트레이션 플랫폼에 맞게 설계됐으며, 배포와 운영이 단순하다. etcd를 사용해 파일이나 오브젝트 메타데이터를 저장, 복구한다. 빠르게 신뢰성있게 스토리지를 운영할 수 있다고 회사측은 강조했다.

수백노드로 확장가능하며, 단일 스토리지 풀로서 디스크를 인식한다. 공개된 프로토타입 버전은 블록네트워크디바이스(NBD)를 지원한다. 향후 오브젝트 스토리지도 지원하게 된다. 내부 P2P API를 통해지속적 해싱, 복제, 가비지콜렉션, 풀 리밸런싱을 지원한다. 암호화와 리드솔로몬 오류정정코드(ECC)도 지원할 예정이다.

'리드-솔로몬(Reed-Solomon) 오류정정코드(ECC)’는 데이터 단위를 작은 조각으로 나눠서 오류 검출과 정정을 하기 쉽게 만드는 일반적인 방식이다. 예를 들면 1기가바이트(GB)짜리 파일을 100메가바이트(MB)짜리 조각 10개로 나눈 뒤, 오류에 대비해 100MB짜리 보정 데이터를 4개쯤 덧붙이는 식이다. 이는 결과적으로 백업에 1.4GB를 사용하는데, 파일 전체를 이중 백업하기 위해 2GB를 쓰는 것보다 효율적이다.

컨테이너에 맞는 스토리지가 필요하다는 코어OS 주장 자체는 수긍가는 부분이다. 그러나, 현존하는 기술 중 컨테이너와 마이크로서비스에 최적화된 스토리지가 없다는 주장엔 쉽게 동의하기 어렵다.

레드햇에서 제공하는 세프(Ceph), 글러스터FS는 오픈소스 분산 스토리지로 이미 엔터프라이즈 현업 시스템에서 다수 쓰이고 있다. 또 오픈스택의 신더 같은 클라우드용 오브젝트 스토리지 기술도 존재한다.

더레지스터의 크리스 에반스는 “솔리드파이어 같은 플랫폼이 완전한 API 중심 제품을 제공하고, 의심할 여지없이 컨테이너를 지원하게 될 것”이라며 “수많은 대안이 존재한다”고 주장했다.

그는 외부의 오픈소스 생태계와 별개로 움직이려는 코어OS의 행보에 우려를 표했다. 오픈스택 모델을 사용하지 않고 오로지 코어OS 산하 프로젝트로 인프라를 꾸리게 하고 있다는 것이다.

코어OS는 마이크로서비스를 위한 플랫폼 지배에 욕심을 내고 있는 것으로 보인다. 코어OS는 현재 분산 컴퓨팅을 위한 OS에서 시작했고, 분산 스케줄러(Fleet), 분산 키벨류 스토어(etcd), 새로운 컨테이너 엔진(Rocket), 네트워크 패브릭(Flannel), 분산 스토리지 시스템(Torus) 등을 개발하고 있다.

크리스 에반스는 “더 나은 방향은 오픈컨테이너이니셔티브의 일부로서 스토리지 표준을 개발하는 것”이라며 “이를 통해 현존하는 스토리지 사업자가 표준에 동의하면서 자신의 솔루션을 개발하게 해야 한다”고 강조했다.