1.aWS에서 6TB/s는 클라우드 네이티브 Qumulo의 헤드라인이 아닙니다

클라우드 네이티브 Qumulo는 AWS에서 1.6TB/s로 확장되었으며, 이는 가장 좋은 부분도 아닙니다. 이것이 여러분에게 주는 의미는 다음과 같습니다.

수년 동안 기업 고객들은 클라우드에 대해 동일한 우려를 표명해 왔습니다:

"충분히 빠르지 않습니다."
"설령 빠르다고 해도 하나의 가용 영역에서 충분한 컴퓨팅을 안정적으로 확보할 수 없습니다."

한 고객이 문제를 명확하게 제기했습니다:

"안정성이나 유연성을 저하시키지 않으면서 클라우드에서 1.5TB/s의 지속적인 처리량을 초과해야 합니다."

TB의 대문자 "B"가 중요합니다. 이것은 비트가 아닌 바이트 단위입니다. 1바이트는 8비트에 해당하므로 1.5TB/s는 초당 약 12테라비트의 지속적인 데이터 이동을 의미합니다. 그리고 지속성도 마찬가지로 중요합니다. 이는 단기간의 버스트나 캐시 지원 스파이크가 아니라 시간이 지남에 따라 유지되는 지속적인 처리량을 의미합니다. 

4K 영화 한 편을 스트리밍하려면 일반적으로 초당 25메가비트가 필요합니다. 12Tb/s의 경우, 동일한 시스템에서 이론적으로는 거의 50만 4K 동시 스트리밍을 지원합니다.

궁금해하는 분들을 위해 Qumulo CNQ는 1.6TB/s와 2,070만 IOPS를 달성하며 도전에 성공했지만 이에 대해서는 나중에 자세히 설명하겠습니다. 

사실 성능 수치만이 중요한 것은 아닙니다. 오늘날 1.5TB/s를 필요로 하는 기업은 거의 없지만, 경험에 따르면 현재 수요에 대한 계획만으로는 제대로 된 결과를 얻는 경우가 드뭅니다. 클라우드 리소스로 고성능 시스템을 구축하는 것은 예산, 위험 허용 범위, 시스템 취약성의 문제인 경우가 많습니다. 실제로 속도만을 목표로 구축하는 것은 많은 조직에서 CFO와 좋은 관계를 맺는 좋은 방법이지만 좋은 방법은 아닙니다. 속도와 취약한 인프라 아키텍처를 결합하면 일시적으로 한 가지 문제를 해결할 수 있지만, 그 결과로 많은 추가적인 기술 및 경제적 문제가 발생합니다.

아키텍처 유연성이라는 근본적인 문제를 해결하려면 새로운 사고가 필요합니다. 

대부분의 클라우드 스토리지 플랫폼은 고객이 장기적인 인프라 결정을 조기에 내리도록 강요합니다. 성능, 가용성, 비용이 긴밀하게 결합되어 있어 최대 수요에 대비한 오버프로비저닝, 복원력을 위한 데이터 중복, 특정 위치에 워크로드를 고정해야 합니다. 이러한 선택은 한 번 내리면 되돌리기 어렵고 비용도 많이 듭니다.

결과적으로 스토리지는 변화하는 워크로드에 적응하는 유연한 기반이 아니라 컴퓨팅 팀이 계획하는 제약 조건이 됩니다.

고객이 해야 할 더 좋은 질문은 "얼마나 빨리 갈 수 있나요?"가 아니라 "얼마나 빨리 갈 수 있나요?"입니다

바로 이것입니다: 클라우드가 취약한 아키텍처, 중복된 스토리지 또는 영구적으로 오버프로비저닝된 인프라에 나를 가두지 않고 필요할 때 엄청난 극한의 성능을 제공할 수 있는가?

쿠물로는 이 도전을 진지하게 받아들였습니다. 헤드 라인 숫자를 쫓는 것이 아니라 다른 운영 모델을 증명하는 것이었습니다. 그렇기 때문에 1.6TB/s는 헤드라인이 아닙니다. "Qumulo, AWS에서 1.6TB/s로 확장하면, 헤드라인이 아니라면 뭐가 헤드라인이죠?"

진짜 헤드라인이 속도가 아니라 경제적 세금을 내지 않고도 지역적 제약을 제거하는 것이라면 어떨까요?

답은 개조된 아키텍처가 아닌 클라우드 네이티브 아키텍처에서 시작됩니다.

1import os
2import sys
3from datetime import datetime
4import libnfs
5
6os.environ['LD_LIBRARY_PATH'] = "/var/task/lib:/var/task/libnfs:" + os.environ.get('LD_LIBRARY_PATH', '')
7sys.path.append('/var/task')
8
9def handler(event, context):
10    try:
11        nfs = libnfs.NFS("nfs://YOUR_CNQ_ADDRESS/YOUR_NFS_EXPORT")
12    except Exception as e:
13        return {"statusCode": 500, "body": "Error connecting to NFS export: " + str(e)}
14    
15    try:
16        timestamp = datetime.now().isoformat()
17        message = f"Hello from AWS Lambda via CNQ! - {timestamp}\n"
18        
19        f = nfs.open("/testing-from-lambda.txt", "w+")
20        f.write(message)
21        f.close()
22    except Exception as e:
23        return {"statusCode": 500, "body": "Error writing to file: " + str(e)}
24    
25    try:
26        f = nfs.open("/testing-from-lambda.txt", "r")
27        content = f.read()
28        return {"statusCode": 200, "body": content}
29    except Exception as e:
30        return {"statusCode": 500, "body": "Error reading file: " + str(e)}
31
32Built for the Cloud from the Beginning

Qumulo의 아키텍처는 클라우드를 위해 설계된 것이지 클라우드에 맞게 조정된 것이 아닙니다. 그 차이가 중요합니다.

대부분의 클라우드 파일 스토리지 시스템은 실행이 제대로 되지 않아서 실패한 것이 아닙니다. 하드웨어 정의 시대의 가정을 계승하고 클라우드 기반 운영을 위해 완전히 재설계하지 않았기 때문에 실패한 것입니다.

기존의 파일 시스템은 스토리지 하드웨어가 용량과 성능을 모두 정의한다는 단순한 물리적 진리를 기반으로 구축되었습니다. 디스크가 많다는 것은 곧 더 많은 공간을 의미했고, 공간이 많다는 것은 곧 더 많은 처리량을 의미했습니다. 용량과 성능은 물리적으로 결합되어 있었습니다. 어느 한쪽이 없으면 다른 한쪽을 의미 있게 확장할 수 없었습니다. 이 모델은 조직이 스피닝 디스크를 구입하고, 서버를 랙에 설치하고, 자체 네트워크를 배선할 때 완벽하게 이해되었습니다.

클라우드 제공업체가 관리형 파일 서비스를 도입했을 때, 이러한 가정은 대부분 그대로 이어졌습니다.

일부 서비스는 용량을 자동으로 확장하지만 성능은 저장된 데이터의 양에 따라 달라집니다. 또 다른 서비스는 고객이 용량과 처리량을 고정 속성으로 함께 프로비저닝해야 합니다. 탄력성은 존재하지만 온프레미스에 존재했던 것과 동일한 커플링으로 인해 제약을 받습니다.

성능과 용량이 계속 연결되어 있기 때문에 고객에게는 매력적이지 않은 두 가지 옵션이 남게 됩니다:

• 피크에 대비한 프로비저닝: 사용률이 낮을 때에도 항상 최대 성능과 용량에 대한 비용을 지불합니다

• 평균을 위한 조항입니다: 워크로드가 벽에 부딪혀 성능이 병목 현상을 일으킬 때까지 비용 절감

대부분의 팀이 첫 번째 옵션을 선택하는 이유는 스로틀링된 워크로드 또는 마감 기한을 놓치는 비용이 오버프로비저닝 비용을 훨씬 초과하기 때문입니다 might 필요성은 클라우드 경제성과는 정반대입니다.

프로토콜 다양성을 고려하면 문제는 더욱 복잡해집니다. Linux 환경에서는 NFS를 기대합니다. Windows 환경에는 SMB가 필요합니다. 최신 애플리케이션은 점점 더 S3 호환 API를 통한 개체 액세스에 의존하고 있습니다.

그 결과 파편화가 발생합니다. 서로 다른 서비스, 서로 다른 확장 모델, 서로 다른 운영 방식. 혼합 워크로드를 실행하는 팀은 좁은 사용 사례에 최적화된 여러 스토리지 시스템을 각각 관리하는 경우가 많습니다.

시간이 지남에 따라 스토리지가 컴퓨팅 팀의 계획에 제약이 됩니다.

"저장 용량이 얼마나 되나요?" "무엇을 실행할 수 있나요?"라고 묻습니다

이것은 거꾸로입니다. 인프라는 워크로드에 맞춰 조정되어야지 그 반대가 되어서는 안 됩니다.

클라우드 네이티브 큐뮬로는 이러한 연결 고리를 끊습니다.

CNQ는 처음부터 성능과 용량을 분리하여 설계했습니다. 컴퓨팅은 내구성이 뛰어난 오브젝트 스토리지와 독립적으로 확장되며, 용량을 미리 할당하는 대신 컴퓨팅 리소스를 조정하여 성능을 추가하거나 제거할 수 있습니다. 고객은 사용한 스토리지에 대해서만 비용을 지불하고, 성능은 고정된 약정이 아닌 탄력적인 속성이 됩니다.

이를 통해 CNQ는 범용 엔터프라이즈 파일 서비스를 경제적으로 지원하는 동시에 고객이 영구적인 오버프로비저닝이나 파편화된 스토리지 사일로를 사용하지 않고도 특수한 고강도 워크로드로 확장할 수 있습니다.

이것이 바로 헤드라인입니다: CNQ는 클라우드에 맞게 설계된 것이 아니라 클라우드를 위해 설계되었습니다. 그래도 뭔가 부족한 느낌이 듭니다.

도전 과제: 안전망 없이 온프레미스보다 빠르게 이동하기

고객의 요구 사항은 이론적인 것이 아니었습니다.

온프레미스에서는 지연 시간을 최소화하기 위해 스토리지에 가까운 곳에 컴퓨팅을 배치하여 단일 데이터 센터에서 워크로드를 실행했습니다. 전력, 냉각, 네트워킹 등 인프라에 장애가 발생하면 워크로드가 중단되었습니다. 재해 복구가 존재했지만, 대부분의 DR 시스템과 마찬가지로 비동기식이고 테스트가 거의 이루어지지 않았으며 전체 워크로드 성능을 유지할 수 없었습니다.

시스템은 작동했지만 취약했습니다.

전통적으로 클라우드로의 이전은 속도에 관한 것이 아니었습니다. 새로운 제약을 도입하지 않고 단일 장애 지점을 제거하는 것이었습니다. 하지만 속도가 빨라진다면 고객의 비즈니스에 어떤 영향을 미칠까요?

클라우드에서는 기대치가 명확했습니다:

• 온프레미스 성능을 뛰어넘는 성능

• 단일 가용 영역에 대한 의존성 방지

• 장애 발생 시 전체 성능 유지

• 스토리지 비용을 두 배로 늘리지 않고

이 마지막 요구 사항은 많은 클라우드 파일 시스템이 부족한 부분입니다.

대부분의 다중 가용성 영역 제품은 복제를 활용합니다. 가용성을 제공하기 위해 각 영역에 데이터의 전체 복사본이 유지됩니다. 이 접근 방식은 내구성에는 효과적이지만 실제적인 결과를 초래합니다. 스토리지 비용은 영역의 수에 따라 선형적으로 증가합니다. 영역 간 조정으로 인해 쓰기 성능이 저하됩니다. 멀티 AZ는 고객이 정상 운영이 아닌 장애 시나리오를 위해 예약하는 것이 됩니다.

동시에 클라우드의 컴퓨팅 가용성은 균등하게 분산되어 있지 않습니다.

GPU와 CPU를 많이 사용하는 워크로드는 종종 영역에 따라 그리고 시간에 따라 달라지는 용량 제약에 직면합니다. 데이터를 단일 영역에 고정하는 설계는 해당 지역의 다른 곳에 용량이 있는 경우에도 컴퓨팅을 따라가도록 합니다. 결국 고객은 인스턴스를 찾아 헤매거나, 데이터가 준비되기 전에 컴퓨팅을 예약하거나(비용이 많이 들고), 작업을 아예 지연시키거나(결과까지 걸리는 시간이 길어집니다).

고객은 속도, 안정성, 복원력을 갖춘 Qumulo에 도전했습니다. 이 솔루션은 영역 수준의 종속성을 제거하고 스토리지 중복을 제거하며 언제든 컴퓨팅 용량을 사용할 수 있는 곳에서 워크로드를 실행할 수 있는 동시에 더 높은 성능을 제공해야 했습니다.

Qumulo는 레거시 가정 위에 가용성을 계층화하는 대신 아키텍처 수준에서 이 문제를 해결합니다.

아키텍처: 중복이 아닌 설계에 따른 다중 가용성 영역

이 배포의 핵심은 단일 AWS 리전 내 3개의 가용 영역에 고르게 분산된 다중 AZ CNQ 클러스터였습니다.

가용 영역(AZ)은 AWS 리전 내에 물리적으로 분리된 하나 이상의 데이터 센터 집합입니다. 각 AZ는 자체 전력, 냉각 및 네트워킹을 통해 독립적으로 작동하도록 설계되었으며, 고대역폭, 저지연 링크를 통해 리전 내 다른 AZ와 연결됩니다. 이러한 분리를 통해 전체 데이터 센터 위치가 중단되더라도 애플리케이션을 계속 사용할 수 있습니다.

Amazon S3는 여러 시설에 걸쳐 데이터가 자동으로 보호되는 리전 수준에서 내구성을 제공합니다. 이것이 바로 AWS가 데이터 보호의 업계 벤치마크로 널리 알려진 11.9(99.999999999% 내구성)를 제공하는 이유입니다.

CNQ의 아키텍처는 설계상 각 영역에서 고객 데이터의 전체 복제본이 필요하지 않고 여러 AWS 가용 영역에 걸쳐 있습니다. 결과적으로

• 스토리지 비용은 하나의 AZ에서 실행하든 여러 AZ에서 실행하든 동일합니다

• 영역 간 복제로 인해 쓰기 성능이 저하되지 않습니다

• 다중 AZ 작동은 장애 모드가 아닌 정상 상태입니다

참고: 일반적으로 멀티 AZ 서비스는 단일 AZ 구현보다 비용이 두 배 더 많이 듭니다. 비용을 동일하게 유지하는 것은 상당한 경제적 이점이 있습니다. 

가용 영역 하나를 사용할 수 없게 되더라도 클러스터는 데이터 손실 없이 나머지 영역에서 계속 작동하며 보조 복사본으로 페일오버할 필요가 없습니다.

이 설계는 복제본 기반의 다중 AZ 접근 방식보다 더 간단하고 빠르며 실질적으로 저렴합니다.

이것을 헤드라인으로 삼는 것은 쉽습니다: 데이터 중복 없이 멀티 AZ 복원력을 제공하는 CNQ 아키텍처. 틀린 말은 아닙니다. 하지만 우리는 더 잘할 수 있습니다. 

GPU 집약적 워크로드를 위한 CNQ 다중 가용성 영역의 이점

멀티 AZ는 일반적으로 가용성 기능으로 논의되지만, 요즘에는 가용성이 테이블 스테이크처럼 여겨지고 있습니다. 실제로 중요한 것은 CNQ가 컴퓨팅을 위해 제공하는 기능, 즉 GPU와 CPU 획득을 훨씬 덜 고통스럽게 만드는 것입니다. 

대부분의 클라우드 파일 시스템, 심지어 멀티 AZ로 판매되는 시스템도 스토리지를 단일 기본 영역에 고정합니다. 컴퓨팅은 데이터를 따라가야 합니다. 해당 영역에서 GPU 또는 CPU를 사용할 수 없는 경우, 해당 지역의 다른 곳에 사용되지 않는 용량이 있더라도 워크로드가 멈춥니다.

이로 인해 팀은 GPU와 CPU를 찾아야 합니다. 먼저 희소성 있는 컴퓨팅 인스턴스를 검색합니다. 그런 다음 컴퓨팅을 사용하기 전에 해당 컴퓨팅을 예약하고 비용을 지불합니다. 다음은 데이터 문제입니다. 대규모 데이터 세트는 컴퓨팅을 찾은 곳에서 복사하거나 다시 스테이징해야 합니다. 이 모든 단계가 완료된 후에야 작업을 재개할 수 있습니다. CNQ는 이러한 제약을 제거합니다.

CNQ를 사용하면 여러 가용성 영역의 컴퓨팅이 동일한 데이터 세트에 동시에 액세스할 수 있습니다. 고객은 데이터를 복사하거나 다시 스테이징하지 않고도 여러 영역의 용량을 단일 논리적 풀로 통합할 수 있습니다.

월요일에는 한 구역에서 GPU를 사용할 수 있고 화요일에는 다른 구역에서 사용할 수 있는 경우, 고객은 데이터를 이동하거나 인프라를 다시 구축하지 않습니다. 기존 CNQ 배포를 컴퓨팅을 사용할 수 있는 곳으로 지정하기만 하면 됩니다.

고객 입장에서는 이를 통해 다음과 같은 이점이 있습니다:

• 부족한 GPU 및 CPU에 더 빠르게 액세스하기

• 데이터 리스테이징 또는 복사 단계 없음

• 복제 불이익 없음

• 스토리지 비용 증가 없음

영구 스토리지 계층 역할을 하는 S3 내의 모든 가용성 영역에 데이터가 이미 존재하기 때문에 작업을 즉시 시작할 수 있습니다. 이 아키텍처는 Amazon Elastic Block Store(EBS) 또는 인스턴스 연결 스토리지와 달리 컴퓨팅을 시작하기 전에 각 영역에 데이터를 복사하거나 다시 수화할 필요가 없습니다. 대신, 파일 시스템은 NeuralCache를 통해 각 AZ에서 로컬로 데이터에 액세스합니다. 이 접근 방식은 몇 주에 걸친 데이터 스테이징 작업을 없애고 고가의 컴퓨팅 리소스를 처음부터 완전히 활용할 수 있게 해줍니다.

다시 한 번 말씀드리지만, 당연히 이것이 헤드라인이 되어야 한다고 생각할 수 있습니다: CNQ와 GPU 헌팅을 견딜 수 있게 만드는 기술. 우리는 올바른 방향으로 가고 있습니다. 더 잘할 수 있을지 지켜봅시다.

원하는 만큼 성능을 확장한 후 다시 축소하기

고객은 안정성이나 유연성을 희생하지 않으면서 클라우드에서 1.5TB/s의 지속적인 처리량을 초과할 것을 요청했습니다. Qumulo는 궁극적으로 기대치를 뛰어넘는 테스트 배포를 생성하여 1.6TB/s의 지속적인 총 처리량과 2,070만 IOPS를 달성했습니다. 실제로 이러한 수치는 인상적이지만(향후 독자들은 발행일을 참조해 맥락을 파악하시기 바랍니다), 이 수치가 최대 요구 사항일까요 아니면 평균 요구 사항일까요? 이 글을 읽고 있는 고객 중 1.6TB/s와 2,070만 IOPS에 관심이 있으시다면 걱정하지 마세요! 아래를 참조하세요.

많은 고객은 유연성을 우선시하며 수요 변화에 따라 리소스를 확장 및 축소할 수 있는 기능을 필요로 합니다. 앞서 설명한 대로 고객은 종종 높은 비용을 들여 최대 수요에 대비한 프로비저닝과 평균 사용량에 맞춰 규모를 조정하고 성능 부족의 위험을 감수하는 것 중에서 선택합니다. 이러한 상충 관계는 클라우드의 핵심 가치인 가변성을 강조합니다. 이 구성은 시간당 약 5,000달러의 비용이 들 수 있으므로 필요할 때는 유용하지만 지속적으로 실행하기에는 경제적으로 비현실적입니다. 필요할 때만 이 수준의 성능을 사용할 수 있기 때문에 클라우드 기반 접근 방식은 온프레미스 인프라에 비해 경제적으로 실행 가능합니다.

CNQ를 사용하면 고객은 항상 최대 용량에 대한 비용을 지불하지 않고도 최고 성능에 도달할 수 있습니다. 이것이 바로 차이점입니다.

많은 클라우드 파일 시스템에서 성능은 영구적으로 프로비저닝된 용량에 연동되어 있습니다. 피크에 맞게 크기를 조정하면 워크로드가 줄어들더라도 항상 피크 요금제를 지불해야 합니다.

CNQ는 이러한 결정을 분리합니다.

고객은 마감일, 교육 기간 또는 생산량 급증에 맞춰 성능을 공격적으로 확장한 다음 피크가 지나면 다시 축소할 수 있습니다. 가끔씩 급증하는 트래픽을 감당하기 위해 레드라인 구성에 얽매이지 않아도 됩니다.

이러한 탄력성은 확장뿐만 아니라 인스턴스 선택에도 적용됩니다. 이 배포에서는 지역적 용량 제약으로 인해 설계 도중에 인스턴스 유형을 조정했습니다. 클러스터는 재설계 없이 노드당 대역폭을 낮게 사용하여 약 333,000개의 연결을 유지하면서 250개 노드로 간단히 확장되었습니다.

나중에 고객은 다운타임이나 데이터 마이그레이션 없이 롤링 교체를 통해 더 저렴한 비용으로 최신 인스턴스 제품군으로 전환할 수 있습니다.

마침내 우리는 함께 헤드라인을 발견했습니다: CNQ 제공 사항 최대 약정 없이 최고의 성능. 그렇죠? 하지만 이 정도의 최고 성능이 필요한 이유는 무엇일까요? 

최고의 성능이 요구되는 순간

모든 워크로드에 극한의 처리량이 필요한 것은 아니며, 바로 그 점이 핵심입니다.

이 아키텍처는 항상 1.6TB/s로 실행하는 것이 아닙니다. 시간이 중요할 때만 그 정도로 빠르게 실행하고 나머지 시간에는 재정적 또는 운영상의 불이익을 받지 않도록 하는 옵션이 필요합니다.

오늘 과도하게 느껴지는 것이 내일의 기준선이 되는 습성이 있습니다. 그렇다면 이 성능이 필요한 이유는 무엇일까요? 

10억 달러 규모의 유정을 임대할지 여부를 결정해야 하는 에너지 회사를 생각해 보세요. 문제는 분석에 클라우드 비용이 몇 백만 달러 더 들지 여부가 아닙니다. 문제는 누가 먼저 답을 얻느냐입니다. 누가 먼저 답을 얻느냐에 따라 자산을 확보하는 사람과 빈손으로 돌아가는 사람이 결정될 수 있습니다.

의료 분야에서 더 빠른 게놈 분석은 불확실성의 장기화와 생명을 구할 수 있는 치료 결정의 차이를 의미할 수 있습니다.

미디어 및 엔터테인먼트 분야에서는 속도가 프로젝트의 출시 기간을 맞출지, 아니면 지연이 예상치 못한 비용으로 이어져 수익 마진이 사라질지를 결정할 수 있습니다. 더 빠른 렌더링, 더 빠른 분석, 더 빠른 반복은 인프라에서 대기하는 크리에이티브 팀의 유휴 시간이 줄어든다는 것을 의미합니다.

이 모든 사례에서 제약 조건은 저장할 수 있는 데이터의 양이 아닙니다. 인사이트를 얻는 시간과 의사 결정에 걸리는 시간입니다. 인프라가 더 빠르게 답을 제공하면 조직은 워크로드를 더 빠르게 실행할 뿐만 아니라 결과도 더 빨리 얻을 수 있습니다. 전체 의사 결정 주기를 단축하고 가장 비싸고 대체할 수 없는 자원인 전문가의 시간에서 더 많은 가치를 창출할 수 있습니다. 

성능이 확장 및 축소되고, 유휴 헤드 룸에 대한 비용을 지불하지 않고 성과에 대한 비용을 지불하기 시작하면 비즈니스가 달성할 수 있는 것을 상상해 보세요. 

헤드라인은 반드시 그래야 합니다: 인프라를 기다리지 마세요. CNQ는 더 빠르게 결과를 제공합니다. 하지만 이것이 정말 모든 것을 담아낼 수 있을까요? 

누적 효과

1.6TB/s의 지속적인 총 순차 읽기 처리량을 제공함으로써 Qumulo는 온프레미스 시스템과 비교하여 원래의 고객 성능 목표를 50% 이상 초과 달성했습니다. 이 수준의 성능을 달성하려면 표준 AWS 인프라를 기반으로 3개의 가용 영역에 걸쳐 구축된 클라우드 네이티브 아키텍처가 필요했습니다.

더 중요한 것은 이 작업이 극한의 성능을 구현하기 위해 무리한 희생이 필요하지 않다는 것을 보여준다는 점입니다.

이 시스템은 1.6TB/s의 처리량과 함께 밀리초 미만의 지연 시간으로 2,070만 IOPS를 달성했습니다. 

하지만 진정한 가치는 숫자를 넘어서는 것입니다. 이 아키텍처를 통해 고객은 단일 영역에 국한되지 않고 모든 가용 영역에 걸쳐 컴퓨팅을 적용할 수 있으므로 대규모 GPU 및 CPU를 훨씬 쉽게 확보할 수 있습니다. 또한 중복으로 인한 스토리지 비용 증가 없이 뛰어난 데이터 가용성과 11.9의 내구성을 제공하는 CNQ on AWS의 복원력을 검증했습니다. 고객은 자신의 성능 요구 사항과 예산에 맞는 인스턴스 제품군을 유연하게 선택할 수 있으며, 실제로 사용한 만큼만 비용을 지불하면 됩니다.

이러한 기능을 종합하면 누적 효과, 즉 누적 효과.

어쩌면 관심을 끌어야 하는 것은 하나의 헤드라인이 아닐 수도 있습니다. 어쩌면 모든 헤드라인일 수도 있습니다.

• AWS에서 1.6TB/s로 확장된 클라우드 네이티브 Qumulo 

• 클라우드를 위해 설계된 CNQ, 클라우드에 맞게 조정되지 않음

• 데이터 중복 없이 멀티 AZ 복원력을 제공하는 CNQ 아키텍처

• CNQ와 GPU 헌팅을 견딜 수 있게 만드는 기술

• 최대 약정 없이 최고의 성능을 제공하는 CNQ

• 인프라를 기다리지 마세요. 더 빠르게 결과를 제공하는 CNQ

그 조합이 바로 스토리입니다.

테이크아웃

이 배포를 통해 클라우드 네이티브 파일 시스템이 성능 저하 없이 최고의 성능을 제공할 수 있음을 입증했습니다:

• 복제가 아닌 설계에 의한 멀티 AZ

• 확장 및 축소 가능한 성능

• 데이터가 고정된 곳이 아닌 컴퓨팅이 가능한 곳에서 자유롭게 실행 가능

• 결과 도출 시간 단축 

클라우드는 단순히 속도가 빠르기만 하면 되는 것이 아닙니다. 올바른 아키텍처를 사용하면 온프레미스 시스템보다 더 유연하고 탄력적이며 경제적인 클라우드가 될 수 있습니다.