제가 가장 좋아하는 인용구 중 하나는 다음과 같습니다.
“우리가 이분법적으로 보는 거의 모든 것이 사실은 스펙트럼이다.” -존 그린(John Green)
우리는 사물을 카테고리로 분류하는 데 많은 시간을 들이며, 이러한 카테고리는 훨씬 더 복잡한 개념에 대한 축약입니다. 언어는 본질적으로 현실만큼 풍부하지는 않지만, 간단함을 위해서, 즉 사실을 소통하고 묘사할 수 있도록 우리는 사물을 틀 속에 넣는 경향이 있습니다. 그래서 “핫도그는 샌드위치인가?” 같은 실없는 질문이 나오기도 합니다. 사실 샌드위치는 불완전한 개념입니다. 우리가 간단하게 카테고리로 생각하는 대부분의 것들이 사실은 스펙트럼상의 한 점에 불과합니다.
그렇기 때문에 스토리지, 데이터베이스 등의 데이터 시스템을 ‘비공유(shared nothing)’, ‘공유(shared everything)’ 같은 단순하고 기본적인 카테고리로 분류하는 것은 굉장히 쓸모 없는 일입니다. 이 두 용어는 모두 복잡한 아키텍처와 개념을 단순화하려는 시도로, 이러한 용어를 사용하는 것 자체가 무의미합니다.
예를 들어, 두 개의 SQL 데이터베이스 서버가 있습니다. 하나는 주 서버로 작동하고 다른 하나는 보조 서버로 작동하는데 각 서버가 자체 로컬 데이터 복사본을 사용하는 경우, ‘비공유’로 간주될 수 있습니다. Google의 Cloud Spanner(영문자료) 데이터베이스와 같은 정교한 클라우드 시스템도 마찬가지입니다. 그러나 이 두 시스템은 복잡성, 복원력, 기능의 스펙트럼에서 서로 멀리 떨어져 있으며, Cloud Spanner의 확장성에 의문을 제기하는 사람은 거의 없습니다.
이 글에서는 다양한 스토리지 아키텍처와 그 장단점을 자세히 살펴보고, 퓨어스토리지 제품에서 각 아키텍처를 사용하는 이유를 알아봅니다. 또한 왜 제품이나 플랫폼에서 중요한 것이 아키텍처만은 아닌지 살펴봅니다.
더 유용한 설명 방법
이러한 시스템을 분류하는 데 더 유용한 방법은 데이터베이스 아키텍처에 대한 토비아스 지글러 외(Tobias Ziegler et al)의 최근 논문(영문자료)에서 언급된 방법입니다. 이 논문의 분류법은 쓰기 작업을 처리하는 방식에 따라 시스템을 구분합니다. 합리적인 방법입니다. 읽기 전용 시스템에서 그렇듯, 스케일 아웃은 사소한 일이기 때문입니다. 스케일 아웃 시스템의 거의 모든 복잡성은 업데이트를 처리하는 방식에서 비롯됩니다. 퓨리티(Purity)가 업데이트를 처리하는 방법(영문자료)과 높은 업데이트 데이터 스트림을 위해 설계된 방법에 대해서는 이전에 자세히 살펴본 적이 있습니다.
이 논문에서 저자들은 시스템을 4가지 주요 유형, 즉 단일 작성자(single-writer) 시스템, 분할 작성자(partitioned-writer) 시스템, 그리고 두 가지 다른 유형의 공유 작성자(shared-writer) 시스템(일관된 캐시가 있는 경우와 없는 경우 모두 포함)으로 정의합니다. 앞서 설명한 간단한 2개 데이터베이스 서버는 한 번에 하나의 노드만 쓰기를 실행할 수 있으므로 단일 작성자 시스템이 됩니다. 반대로, 이 분류에 따르면 클라우드 스패너는 분할 작성자 시스템으로 구분됩니다.
이 예를 들은 이유는 두 서버에서 실행되는 간단한 액티브-패시브 데이터베이스와 확장 가능한 클라우드 네이티브 데이터베이스 간에는 단순히 ‘비공유’로 묘사할 수 없는 큰 차이가 있음을 설명하기 위해서입니다. 제 생각에, ‘비공유’는 (거의) 아무런 의미가 없습니다.
이 분류법에서 퓨리티는 어디에 속할까요?
이 시스템에서 퓨어스토리지가 스펙트럼의 어디에 위치하는가를 물어보실 수 있을 겁니다. 정답은 사실 퓨어스토리지는 제품별로 다른 아키텍처를 사용한다는 것입니다. 퓨어스토리지의 플래시어레이(FlashArray) 제품군은 단일 작성자 설계를 활용하는 버전의 퓨리티(퓨리티//FA라고 합니다)을 활용합니다. 모든 플래시어레이 시스템에는 두 개의 컨트롤러가 있으며, 각 컨트롤러는 다이렉트플래시(DirectFlash) 및 NVRAM(영문자료)에 대한 액세스 권한을 공유합니다. 또한 플래시어레이 시스템의 모든 프런트엔드 포트는 활성 상태이지만, 한 번에 하나의 컨트롤러만 입출력을 처리합니다. 이러한 접근 방식은 컨트롤러에 장애가 발생하는 상황에서도 일관된 100% 성능(영문자료)을 보장합니다. 또한 퓨어스토리지의 공유 NVRAM 접근 방식을 사용하면, 컨트롤러 페일오버 이벤트가 완전히 무중단으로 처리됩니다. 하드웨어와 소프트웨어의 이러한 긴밀한 결합 덕분에 플래시어레이는 동급 시스템 중 가장 간단하면서 복원력이 높은 시스템이 되었으며, 이는 에버그린(Evergreen) 아키텍처를 통해 구현되는 핵심적인 경험입니다.
스케일 아웃 플래시블레이드(FlashBlade) 시스템에서, 퓨리티//FB는 분할 작성자 시스템으로 볼 수 있습니다. 시스템의 각 블레이드는 컴퓨팅 성능과 스토리지 용량을 포함하는 노드이지만, 전체 시스템에는 여러 개의 논리적 분할(영문자료)이 포함되어 있으며, 각 분할은 모든 스토리지 장치에서 특정 플래시 및 NVRAM 분할에 액세스하고 소유권을 갖습니다. 이러한 논리적 분할을 가상화하면 과거 분할 작성자 시스템이 직면했던 많은 확장성 문제를 해결할 수 있습니다. 플래시블레이드 시스템은 분할이 특정 하드웨어에 얽매이는 것이 아니라, 성능과 용량을 선형적으로 (함께) 또는 독립적으로 확장할 수 있습니다. 또한 독립적인 논리적 분할이 여러 개 있다는 것은 시스템의 더 많은 부분을 최대한 빨리 실행하여 더 확장된 동시성을 제공할 수 있다는 것을 의미합니다.
스케일 아웃에 공유 작성자 접근 방식은 왜 안될까요?
논문의 저자들이 지적했듯이, 일관된 캐시가 없는 공유 작성자 접근 방식으로 이동하는 경우 분할 작성자 모델과 전반적인 확장성은 동일합니다. 분할 작성자 시스템의 유일한 단점은 새 노드를 추가할 때 클러스터를 확장하는 데 어려움이 있다는 것입니다. 그러나 플래시블레이드의 설계자들은 가상화된 분할 모델을 통해 플레시블레이드 클러스터에 새로운 노드와 스토리지를 추가하는 문제를 해결했습니다. 또한 이러한 분할을 유지하면 분할을 넘지 않는 트랜잭션에 잠금이 필요하지 않아 대부분의 업데이트 작업 속도가 크게 향상됩니다. 공유 작성자 모델에서는 모든 작성자가 모든 블록에 쓰기를 할 수 있기 때문에 모든 트랜잭션에 대해 일부 잠금 메커니즘이 구현되어야 하며, 이 잠금 프로토콜 자체가 확장 가능하고 사용 가능해야 합니다. 또한 일관된 캐시가 없으면 모든 읽기, 쓰기 및 중요한 메타데이터 작업에서 기본 공유 스토리지에 액세스하여 실측 자료(ground truth)를 파악해야 합니다. 퓨리티의 메타데이터 엔진은 높은 인제스트 업데이트에 최적화(영문자료) 되어 있기 때문에 아키텍처에 쓰기 성능을 더 잘 확장하는 접근 방식을 사용하는 것이 당연한 선택이었습니다.
퓨어스토리지 아키텍처의 확장성에 대한 증거가 필요하면 이 사실을 참고하시기 바랍니다. 10여년 전에 플래시어레이 시스템이 처음 출시되었을 때 최대 용량은 약 5TB였습니다. 현재 플래시어레이//E는 단일 어레이에서 4페타바이트의 플래시를 제공할 수 있습니다. 거의 1,000배가 증가한 수치입니다. 2017년에 출시된 첫 플래시블레이드 시스템은 최대 120TB의 플래시를 지원했습니다. 현재 퓨어스토리지는 30페타바이트를 지원합니다. 250배 증가한 것입니다. 퓨어스토리지 플랫폼의 확장성은 현장에서 입증되었습니다. 그리고 확장은 아직 끝나지 않았습니다. 퓨어스토리지는 앞으로 몇 년 안에 다이렉트플래시 모듈의 크기를 두 배로 늘리고 또 다시 두 배 더 늘릴 계획이기 때문입니다.
그림 1: 플래시블레이드 아키텍처의 확장성 발전 현황
이러한 카테고리가 중요하기는 할까요?
많은 부분이 학문적 관점에서 흥미롭긴 하지만, 모든 시스템의 실제 가치는 그 시스템이 제공하는 결과로 입증됩니다. 퓨어스토리지는 시스템의 아키텍처와 이를 통해 얻을 수 있는 확장성에 대해 큰 자부심을 갖고 있지만, 초점을 두는 부분은 고객 성과입니다. 모든 스토리지 시스템에는 메타데이터 아키텍처뿐만 아니라 다양한 요소들이 존재합니다. 시스템의 안정성, 고객 경험, 운영의 간단함은 시스템의 기저 아키텍처만큼이나 중요합니다.
스토리지 시스템의 가장 중요한 측면은 사용자에게 제공하는 전반적인 기능과 경험입니다. 조직의 스토리지 요구사항을 고려할 때 ‘마케팅’ 메시지가 아니라 비즈니스에 실제로 무엇이 필요한지에 집중하는 것이 중요한 이유입니다.
Written By:
Uncomplicate Data Storage, Forever
Find the right solution for your organization’s data storage needs.
