클라우드 네이티브 Qumulo가 AWS에서 1.6TB/s까지 확장되었는데, 이게 전부가 아닙니다. 이것이 여러분에게 어떤 의미인지 알아보겠습니다.
수년간 기업 고객들은 클라우드에 대해 동일한 우려를 표명해 왔습니다.
"속도가 충분히 빠르지 않아요."
"설령 그렇다 하더라도, 하나의 가용 영역에서 충분한 컴퓨팅 자원을 안정적으로 확보할 수는 없습니다."
한 고객은 당면 과제를 명확하게 제시했습니다.
"클라우드 환경에서 안정성이나 유연성을 희생하지 않고 1.5TB/s 이상의 지속적인 처리량을 달성해야 합니다."
TB에서 대문자 "B"가 중요합니다. 이것은 비트가 아니라 바이트입니다. 1바이트는 8비트이므로 1.5TB/s는 지속적인 데이터 전송량으로 환산하면 약 12테라비트/초에 해당합니다. 그리고 '지속적'이라는 표현이 매우 중요합니다. 이는 순간적인 버스트나 캐시 지원으로 인한 급증이 아니라, 시간이 지남에 따라 유지되는 연속적인 처리량을 의미합니다.
이 수치를 이해하기 쉽게 설명하자면, 4K 영화 한 편을 스트리밍하는 데 일반적으로 초당 약 25메가비트가 필요합니다. 12테라비트/초의 속도라면 동일한 시스템에서 이론적으로 거의 모든 영화를 스트리밍할 수 있습니다. 오십 만 동시 4K 스트리밍.
궁금해하시는 분들을 위해 말씀드리자면, Qumulo CNQ는 이 도전을 성공적으로 완수하여 1.6TB/s의 처리량과 20.7만 IOPS를 달성했습니다. 하지만 이에 대한 자세한 내용은 나중에 다루겠습니다.
사실 성능 수치 그 자체만으로는 진정한 문제가 될 수 없습니다. 오늘날 1.5TB/s의 속도가 필요한 기업은 거의 없지만, 경험상 현재 수요만을 고려한 계획은 좋은 결과를 가져오지 못하는 경우가 많습니다. 클라우드 리소스를 활용한 고성능 시스템 구축은 예산, 위험 감수 능력, 그리고 시스템 취약성과 밀접한 관련이 있습니다. 실제로 속도만을 중시하는 것은 많은 기업에서 최고재무책임자(CFO)의 눈 밖에 나는 지름길입니다. 취약한 인프라 아키텍처와 속도를 결합하면 일시적으로는 문제를 해결할 수 있을지 모르지만, 연쇄적인 기술적, 경제적 문제로 이어질 수 있습니다.
건축적 유연성의 근본적인 문제를 해결하려면 새로운 사고방식이 필요합니다.
대부분의 클라우드 스토리지 플랫폼은 고객에게 장기적인 인프라 관련 결정을 조기에 내리도록 요구합니다. 성능, 가용성 및 비용은 밀접하게 연관되어 있어 최대 수요에 대비한 과잉 프로비저닝, 복원력을 위한 데이터 복제 또는 특정 위치에 워크로드를 고정하는 등의 조치가 필요합니다. 이러한 선택이 일단 이루어지면 되돌리기가 어렵고 비용도 많이 듭니다.
결과적으로 스토리지는 변화하는 워크로드에 적응하는 유연한 기반이 되기보다는 컴퓨팅 팀이 계획을 세울 때 고려해야 할 제약 조건이 됩니다.
고객이 던져야 할 더 나은 질문은 "이 차는 얼마나 빨리 달릴 수 있나요?"가 아닙니다.
핵심은 이것입니다. 클라우드가 내가 필요할 때 극도로 뛰어난 성능을 제공하면서도, 취약한 아키텍처, 중복된 스토리지, 또는 영구적으로 과도하게 구축된 인프라에 얽매이지 않도록 해줄 수 있을까?
쿠물로는 그 도전을 진지하게 받아들였습니다. 단순히 눈길을 끄는 수치를 쫓는 것이 아니라, 차별화된 운영 모델을 입증함으로써 말이죠. 그래서 1.6TB/s라는 수치가 핵심이 아닌 것입니다. "쿠물로, 만약에..."라고 질문하실 수도 있겠죠. AWS에서 1.6TB/s까지 확장, 헤드라인이 그거 아니에요? 그럼 뭐가 헤드라인이죠?
만약 진짜 핵심 이슈가 속도에 관한 것이 아니라, 경제적 부담 없이 지역 제한을 없애는 것에 관한 것이라면 어떨까요?
해답은 기존 시스템을 개조하는 것이 아니라 클라우드 네이티브 아키텍처에서 시작됩니다.
처음부터 클라우드 환경에 맞춰 설계되었습니다.
쿠물로의 아키텍처는 클라우드 환경에 맞춰 설계된 것이지, 클라우드에 적응하도록 만들어진 것이 아닙니다. 이 차이점은 중요합니다.
대부분의 클라우드 파일 저장 시스템이 실패한 이유는 실행상의 문제 때문이 아닙니다. 하드웨어 중심 시대의 가정을 그대로 물려받아 클라우드 기반 운영에 맞게 완전히 재설계되지 않았기 때문입니다.
기존 파일 시스템은 단순한 물리적 진리에 기반을 두고 있었습니다. 즉, 스토리지 하드웨어가 용량과 성능을 모두 결정한다는 것이었습니다. 디스크 수가 많을수록 저장 공간이 늘어나고, 저장 공간이 많을수록 처리량이 증가했습니다. 용량과 성능은 물리적으로 밀접하게 연결되어 있었기 때문에, 어느 한쪽을 고려하지 않고는 의미 있는 확장이 불가능했습니다. 이러한 모델은 기업들이 회전식 디스크를 구입하고, 서버를 설치하고, 자체 네트워크를 구축하던 시절에는 완벽하게 타당했습니다.
클라우드 서비스 제공업체들이 관리형 파일 서비스를 도입했을 때, 그러한 가정들이 상당 부분 그대로 이어졌습니다.
일부 서비스는 용량을 자동으로 확장하지만, 성능은 저장된 데이터 양에 따라 달라집니다. 다른 서비스는 고객이 용량과 처리량을 고정 속성으로 함께 프로비저닝해야 합니다. 탄력성은 존재하지만, 온프레미스 환경에서와 마찬가지로 특정 조건에 종속됩니다.
성능과 용량이 서로 연관되어 있기 때문에 고객은 두 가지 달갑지 않은 선택지밖에 남지 않습니다.
- 성수기 대비책: 사용률이 낮을 때에도 항상 최대 성능과 용량을 유지하도록 비용을 지불하십시오.
- 평균에 대한 조항: 작업량이 한계에 도달하고 성능이 병목 현상이 될 때까지 비용을 절감하세요.
대부분의 팀은 첫 번째 옵션을 선택합니다. 작업 부하 제한이나 마감일 지연으로 인한 비용이 과잉 공급으로 인한 비용보다 훨씬 크기 때문입니다. 그러나 필요한 만큼만 비용을 지불하는 것은 위험할 수 있습니다. 수도 수요는 클라우드 경제성과 정반대입니다.
프로토콜의 다양성이 개입되면 문제는 더욱 복잡해집니다. 리눅스 환경은 NFS를 기대하고, 윈도우 환경은 SMB를 필요로 합니다. 최신 애플리케이션들은 점점 더 S3 호환 API를 통한 객체 접근에 의존하고 있습니다.
그 결과 파편화가 발생합니다. 서로 다른 서비스, 서로 다른 확장 모델, 서로 다른 운영 방식이 나타납니다. 혼합 워크로드를 실행하는 팀은 종종 여러 스토리지 시스템을 관리하게 되는데, 각 시스템은 특정 사용 사례에 최적화되어 있습니다.
시간이 지남에 따라 저장 공간은 컴퓨팅 팀이 계획을 세울 때 고려해야 할 제약 조건이 됩니다.
"저장 용량이 얼마나 되나요?" "어떤 프로그램을 실행할 수 있나요?"라고 그들은 묻습니다.
이건 완전히 잘못된 접근입니다. 인프라가 워크로드에 맞춰야지, 그 반대가 되어서는 안 됩니다.
클라우드 네이티브 Qumulo는 이러한 결합을 깨뜨립니다.
CNQ는 처음부터 성능과 용량을 분리하도록 설계되었습니다. 컴퓨팅은 영구 객체 스토리지와 독립적으로 확장되며, 성능은 용량을 미리 할당하는 대신 컴퓨팅 리소스를 조정하여 추가하거나 제거할 수 있습니다. 고객은 사용한 스토리지에 대해서만 비용을 지불하며, 성능은 고정된 약정이 아닌 탄력적인 속성이 됩니다.
이를 통해 CNQ는 일반적인 엔터프라이즈 파일 서비스를 경제적으로 지원하는 동시에 고객이 영구적인 과잉 프로비저닝이나 파편화된 스토리지 사일로에 빠지지 않고도 특수 고강도 워크로드로 확장할 수 있습니다.
그러면 헤드라인이 명확해집니다. CNQ는 클라우드 환경에 맞춰 설계된 것이 아니라, 클라우드에 최적화되어 있습니다. 하지만, 뭔가 부족한 느낌이 든다.
도전 과제: 안전망 없이 온프레미스보다 더 빠르게 진행하기
고객의 요구사항은 이론적인 것이 아니었습니다.
온프레미스 환경에서는 워크로드가 단일 데이터 센터에서 실행되었으며, 지연 시간을 최소화하기 위해 컴퓨팅 리소스가 스토리지와 가까운 곳에 배치되었습니다. 전력, 냉각 또는 네트워크 등 인프라에 장애가 발생하면 워크로드가 중단되었습니다. 재해 복구 시스템은 존재했지만, 대부분의 재해 복구 시스템과 마찬가지로 비동기식이었고, 테스트가 충분히 이루어지지 않았으며, 워크로드의 전체 성능을 유지할 수 없었습니다.
그 시스템은 작동했지만, 취약했다.
전통적으로 클라우드로의 이전은 속도에 관한 것이 아니었습니다. 새로운 제약을 도입하지 않고 단일 장애 지점을 제거하는 것이 목적이었습니다. 하지만 만약 속도가 빠르다면, 그것은 고객 비즈니스에 어떤 영향을 미칠까요?
클라우드 환경에서 기대치는 명확했습니다.
- 온프레미스 성능을 능가합니다.
- 단일 가용 영역에 대한 의존성을 피하십시오.
- 장애 발생 시에도 완벽한 성능을 유지합니다.
- 저장 비용을 두 배로 늘리지 않고 하세요
바로 이 마지막 요구 사항에서 많은 클라우드 파일 시스템이 부족한 모습을 보입니다.
대부분의 다중 가용 영역(Availability Zone, AZ) 솔루션은 복제 방식을 사용합니다. 각 영역에 데이터의 전체 복사본을 유지하여 가용성을 보장합니다. 내구성 측면에서는 효과적이지만, 이 방식에는 몇 가지 단점이 있습니다. 스토리지 비용은 영역 수에 비례하여 증가하고, 영역 간 조정으로 인해 쓰기 성능이 저하됩니다. 결과적으로 다중 AZ는 정상적인 운영 환경보다는 장애 발생 시에만 사용되는 경우가 많습니다.
동시에 클라우드 환경에서의 컴퓨팅 자원 가용성은 고르게 분포되어 있지 않습니다.
GPU 및 CPU 사용량이 많은 워크로드는 종종 영역별, 그리고 시간에 따라 달라지는 용량 제약에 직면합니다. 데이터를 단일 영역에 고정하는 설계는 해당 지역의 다른 곳에 용량이 있더라도 컴퓨팅 자원이 데이터를 따라가도록 강제합니다. 결과적으로 고객은 인스턴스를 찾아 헤매거나, 데이터 준비 전에 컴퓨팅 자원을 예약하거나(비용 발생), 아예 작업을 지연시키는(결과 도출 시간 연장) 상황에 놓이게 됩니다.
고객은 Qumulo에게 속도, 안정성 및 복원력 측면에서 까다로운 과제를 제시했습니다. 이 솔루션은 영역별 종속성을 제거하고 스토리지 중복을 없애며, 컴퓨팅 용량이 사용 가능한 모든 곳에서 워크로드를 실행할 수 있도록 하면서 더 높은 성능을 제공해야 합니다.
Qumulo는 기존의 가정 위에 가용성을 추가하는 방식이 아니라 아키텍처 수준에서 해당 문제를 해결합니다.
아키텍처: 중복이 아닌 설계에 의한 다중 가용성 영역
이번 배포의 핵심은 단일 AWS 리전 내 3개의 가용 영역에 고르게 분산된 멀티 AZ CNQ 클러스터였습니다.
가용 영역(AZ)은 AWS 리전 내에서 물리적으로 분리된 하나 이상의 데이터 센터 집합입니다. 각 AZ는 자체 전력, 냉각 및 네트워킹을 갖추고 독립적으로 운영되도록 설계되었으며, 동시에 고대역폭, 저지연 링크를 통해 리전 내 다른 AZ와 연결됩니다. 이러한 분리 덕분에 전체 데이터 센터 위치에 장애가 발생하더라도 애플리케이션은 계속해서 사용 가능합니다.
AWS는 지역별 데이터 보호 기능을 제공하며, 데이터는 여러 시설에 걸쳐 자동으로 보호됩니다. 이러한 이유로 AWS는 업계 표준 데이터 보호 지표로 널리 인정받는 99.999999999%의 데이터 내구성(11나인)을 제공합니다.
CNQ의 아키텍처는 설계상 각 영역에 고객 데이터의 전체 복제본을 저장할 필요 없이 여러 AWS 가용 영역에 걸쳐 운영됩니다. 결과적으로 다음과 같은 이점이 있습니다.
- CNQ가 하나의 가용 영역에서 실행되든 여러 가용 영역에서 실행되든 스토리지 비용은 동일합니다.
- 쓰기 성능은 영역 간 복제로 인해 저하되지 않습니다.
- 멀티 AZ 운영은 정상적인 상태이며, 장애 모드가 아닙니다.
참고: 일반적으로 멀티 AZ 서비스는 싱글 AZ 서비스보다 비용이 두 배 더 많이 듭니다. 비용을 동일하게 유지하는 것은 상당한 경제적 이점입니다.
하나의 가용 영역을 사용할 수 없게 되더라도 클러스터는 나머지 영역에서 데이터 손실 없이 계속 작동하며, 보조 복사본으로 장애 조치를 수행할 필요가 없습니다.
이 설계는 복제 기반 다중 AZ 접근 방식보다 더 간단하고 빠르며 비용도 상당히 저렴합니다.
이것을 헤드라인으로 삼는 것은 쉬울 것이다: CNQ 아키텍처는 데이터 중복 없이 다중 가용 영역(Multi-AZ) 복원력을 제공합니다. 틀린 말은 아니지만, 우리는 더 잘할 수 있습니다.
GPU 집약적 워크로드에 대한 CNQ 다중 가용 영역의 이점
멀티 AZ는 일반적으로 가용성 기능으로 논의되지만, 요즘에는 가용성이 기본 요소로 여겨집니다. 실제로 중요한 것은 CNQ가 컴퓨팅에 가져다주는 이점, 즉 GPU 및 CPU 확보 부담을 훨씬 줄여준다는 점입니다.
대부분의 클라우드 파일 시스템은 멀티 AZ(가상 영역)를 지원한다고 광고하는 시스템조차도 스토리지를 단일 기본 영역에 고정합니다. 컴퓨팅 리소스도 데이터를 따라가야 합니다. 해당 영역에서 GPU나 CPU를 사용할 수 없는 경우, 리전 내 다른 곳에 여유 용량이 있더라도 워크로드가 중단됩니다.
이로 인해 팀은 GPU와 CPU를 찾아 헤매야 합니다. 먼저 부족한 컴퓨팅 인스턴스를 검색하고, 예약 및 비용 지불을 완료해야만 사용할 수 있습니다. 그다음은 데이터 문제입니다. 대규모 데이터 세트는 컴퓨팅 자원이 확보된 위치로 복사하거나 재배치해야 합니다. 이 모든 단계를 완료한 후에야 작업을 재개할 수 있습니다. CNQ는 이러한 제약을 없애줍니다.
CNQ를 사용하면 여러 가용 영역의 컴퓨팅 리소스가 동일한 데이터 세트에 동시에 액세스할 수 있습니다. 고객은 데이터를 복사하거나 재스테이징하지 않고도 여러 영역의 용량을 단일 논리 풀로 통합할 수 있습니다.
월요일에 한 영역에서 GPU를 사용할 수 있고 화요일에 다른 영역에서 사용할 수 있는 경우, 고객은 데이터를 이동하거나 인프라를 재구축할 필요가 없습니다. 기존 CNQ 배포를 컴퓨팅 자원을 사용할 수 있는 위치로 지정하기만 하면 됩니다.
고객 관점에서 볼 때, 이는 다음과 같은 이점을 제공합니다.
- 희소한 GPU와 CPU에 대한 더 빠른 접근
- 데이터 재스테이징 또는 복사 단계 없음
- 복제 페널티 없음
- 보관 비용 인상 없음
데이터가 영구 저장소 계층 역할을 하는 S3의 모든 가용 영역에 이미 존재하므로 즉시 작업을 시작할 수 있습니다. Amazon Elastic Block Store(EBS) 또는 인스턴스 연결 스토리지와 달리 이 아키텍처는 컴퓨팅을 시작하기 전에 각 영역으로 데이터를 복사하거나 복원할 필요가 없습니다. 대신 파일 시스템은 NeuralCache를 통해 각 가용 영역의 데이터에 로컬로 액세스합니다. 이 접근 방식을 통해 몇 주씩 걸리는 데이터 스테이징 작업을 없애고 고가의 컴퓨팅 리소스를 처음부터 최대한 활용할 수 있습니다.
또다시 여러분은 이렇게 생각하실지도 모르겠습니다. "이게 당연히 헤드라인이어야 하지 않을까?" CNQ와 GPU 사냥을 좀 더 수월하게 만드는 기술. 우리는 올바른 방향으로 가고 있습니다. 이보다 더 나은 결과를 낼 수 있을지 지켜보죠.
원하는 만큼 성능을 높인 다음 다시 낮추세요.
고객은 안정성과 유연성을 희생하지 않고 클라우드에서 1.5TB/s 이상의 지속적인 처리량을 요구했습니다. Qumulo는 기대를 뛰어넘는 테스트 배포를 구축하여 1.6TB/s의 지속적인 총 처리량과 20.7만 IOPS를 달성했습니다. 이 수치는 매우 인상적입니다(향후 독자분들은 발행일을 참고하시기 바랍니다). 하지만 이는 최대 요구 사항일까요, 아니면 평균 요구 사항일까요? 만약 이 글을 읽고 계신 고객 중 1.6TB/s와 20.7만 IOPS에 관심이 있으시다면 걱정하지 마세요! 아래 내용을 확인해 보세요.
많은 고객은 유연성을 중시하며 수요 변화에 따라 리소스를 확장하거나 축소할 수 있는 기능을 필요로 합니다. 앞서 논의했듯이, 고객은 종종 높은 비용을 감수하고 최대 수요에 맞춰 리소스를 구축하거나, 평균 사용량에 맞춰 구축하고 성능 저하 위험을 감수하는 것 중에서 선택해야 합니다. 이러한 상충 관계는 클라우드의 핵심 가치인 가변성을 보여줍니다. 이러한 구성은 시간당 약 5,000달러의 비용이 발생할 수 있으므로 필요할 때는 유용하지만 지속적으로 운영하는 것은 경제적으로 비효율적입니다. 필요할 때만 이러한 수준의 성능을 활용할 수 있다는 점은 온프레미스 인프라에 비해 클라우드 기반 접근 방식을 경제적으로 타당하게 만드는 요소입니다.
CNQ를 사용하면 고객은 항상 최대 용량에 대한 비용을 지불하지 않고도 최고 성능을 발휘할 수 있습니다. 이것이 바로 차이점입니다.
많은 클라우드 파일 시스템의 성능은 영구적으로 프로비저닝된 용량에 따라 결정됩니다. 최대 부하를 기준으로 용량을 설정하면 작업량이 줄어들더라도 항상 최대 부하 요금을 지불해야 합니다.
CNQ는 그러한 결정들을 분리합니다.
고객은 마감일, 교육 기간 또는 생산량 급증에 맞춰 성능을 적극적으로 확장한 다음, 최고치가 지나면 다시 축소할 수 있습니다. 일시적인 수요 급증에 대응하기 위해 성능 한계치에 맞춘 구성에 얽매일 필요가 없습니다.
이러한 유연성은 확장성뿐만 아니라 인스턴스 선택에도 적용됩니다. 이번 구축 사례에서는 지역 용량 제약으로 인해 설계 도중 인스턴스 유형이 조정되었습니다. 그 결과, 클러스터는 재설계 없이도 노드당 대역폭을 낮추면서 약 333,000개의 연결을 지원하는 250개 노드로 확장되었습니다.
고객은 추후 다운타임이나 데이터 마이그레이션 없이 롤링 교체를 통해 더 낮은 비용으로 최신 인스턴스 제품군으로 전환할 수 있습니다.
우리는 마침내 헤드라인을 찾아냈습니다. CNQ는 다음과 같은 혜택을 제공합니다. 최고의 성과를 내되, 최고의 헌신은 필요하지 않습니다. 그렇죠? 하지만 누가 이 정도의 최고 성능을 필요로 하겠어요?
최고의 기량을 발휘해야 하는 순간들
모든 워크로드에 극단적인 처리량이 필요한 것은 아니며, 바로 그 점이 핵심입니다.
이 아키텍처는 항상 1.6TB/s의 속도로 작동하는 것을 목표로 하는 것이 아닙니다. 시간이 중요한 상황에서는 그 속도로 작동할 수 있는 옵션을 제공하고, 나머지 시간에는 재정적 또는 운영적 측면에서 불이익을 받지 않도록 하는 것이 목표입니다.
오늘날 과하다고 느껴지는 것이 내일은 기본이 되는 경우가 많습니다. 그렇다면 누가 이런 수준의 성능을 필요로 할까요?
에너지 회사가 10억 달러 규모의 유정을 임대할지 여부를 결정한다고 가정해 보겠습니다. 여기서 중요한 것은 분석에 드는 클라우드 비용이 몇 백만 달러 더 드는 것이 아닙니다. 누가 먼저 답을 얻으느냐가 핵심입니다. 선점권이 자산 확보의 승패를 좌우할 수 있습니다.
의료 분야에서 신속한 유전체 분석은 장기간의 불확실성을 해소하고 생명을 구할 수 있는 치료 결정을 내리는 데 중요한 역할을 할 수 있습니다.
미디어 및 엔터테인먼트 분야에서 속도는 프로젝트가 예정된 출시 시기를 맞출 수 있는지 여부를 결정짓는 중요한 요소입니다. 지연이 발생하면 예상치 못한 비용이 연쇄적으로 발생하여 수익 마진을 감소시킵니다. 더 빠른 렌더링, 더 빠른 분석, 더 빠른 반복 작업은 인프라를 기다리며 시간을 낭비하는 크리에이티브 팀의 활동을 줄여줍니다.
이 모든 사례에서 제약 조건은 저장할 수 있는 데이터의 양이 아닙니다. 바로 통찰력을 얻고 의사 결정을 내리는 데 걸리는 시간입니다. 인프라가 더 빠르게 해답을 제공하면 조직은 워크로드를 더 빠르게 실행할 뿐만 아니라 결과도 더 빠르게 도출할 수 있습니다. 전체 의사 결정 주기를 단축하고 가장 값비싸고 대체 불가능한 자원인 전문가의 시간을 최대한 활용하여 더 큰 가치를 창출할 수 있습니다.
성능을 필요에 따라 확장하고 축소할 수 있고, 불필요한 여유 자금에 대한 비용 지불을 멈추고 결과에 따라 비용을 지불하기 시작하면 비즈니스가 어떤 성과를 거둘 수 있을지 상상해 보세요.
제목은 분명 다음과 같아야 할 것입니다: 인프라 구축을 기다리지 마세요. CNQ는 더 빠른 결과를 제공합니다. 하지만 이것이 정말 모든 것을 담아낼 수 있을까요?
퀀텀 효과
Qumulo는 1.6TB/s의 지속적인 누적 순차 읽기 처리량을 제공하여 온프레미스 시스템 대비 고객의 원래 성능 목표를 50% 이상 초과 달성했습니다. 이러한 수준의 성능을 달성하기 위해서는 표준 AWS 인프라를 기반으로 구축되고 3개의 가용 영역에 걸쳐 있는 클라우드 네이티브 아키텍처가 필요했습니다.
더욱 중요한 것은, 이 연구는 극단적인 성능을 달성하는 데 있어 감당할 수 없는 절충안이 필요하지 않다는 것을 보여준다는 점이다.
이 시스템은 1.6TB/s의 처리량과 더불어 2070만 IOPS를 달성했으며, 지연 시간은 1밀리초 미만이었습니다.
하지만 진정한 가치는 수치 그 이상입니다. 이 아키텍처를 통해 고객은 단일 가용 영역에 국한되지 않고 모든 가용 영역에 걸쳐 컴퓨팅 리소스를 활용할 수 있으므로 대규모 GPU 및 CPU 확보가 훨씬 쉬워집니다. 또한 AWS에서 CNQ의 복원력을 입증하여 스토리지 중복으로 인한 비용 증가 없이 뛰어난 데이터 가용성과 99.9 ...
이러한 기능들을 종합하면 누적 효과가 발생하는데, 이를 우리는 다음과 같이 부릅니다. 정량적 효과.
어쩌면 당신의 관심을 사로잡아야 할 헤드라인은 하나뿐만이 아닐지도 모릅니다. 어쩌면 모든 헤드라인이 다 중요할지도 모릅니다.
- 클라우드 네이티브 Qumulo, AWS에서 1.6TB/s까지 확장
- CNQ는 클라우드 환경에 맞춰 설계된 것이 아니라, 클라우드에 최적화되어 있습니다.
- CNQ 아키텍처는 데이터 중복 없이 다중 가용 영역(Multi-AZ) 복원력을 제공합니다.
- CNQ와 GPU 사냥을 좀 더 수월하게 만드는 기술
- CNQ는 최고의 성능을 제공하면서도 최고의 투자 부담은 없습니다.
- 인프라 구축을 기다리지 마세요. CNQ는 더 빠른 결과를 제공합니다.
그 조합이 바로 이야기의 핵심입니다.
테이크 아웃
이번 구축 사례를 통해 클라우드 네이티브 파일 시스템이 성능 저하 없이 탁월한 성능을 제공할 수 있음이 입증되었습니다.
- 다중 AZ는 설계 의도에 따른 것이지, 중복에 의한 것이 아닙니다.
- 확장성과 축소성이 뛰어난 성능
- 데이터가 고정된 곳이 아닌, 컴퓨팅 자원을 사용할 수 있는 곳에서 실행할 수 있는 자유
- 결과적으로 결과를 더 빨리 얻을 수 있습니다.
클라우드는 단순히 속도가 빠르기만 하면 되는 것이 아닙니다. 올바른 아키텍처를 갖추면 온프레미스 시스템보다 훨씬 유연하고, 복원력이 뛰어나며, 경제적일 수 있습니다.
