ブログ

1.クラウドネイティブのQumuloにとって、AWSの6TB/sは見出しではない

2026年1月30日

Bill Crew

クラウドネイティブのQumuloがAWS上で1.6 TB/sまでスケールした。これが何を意味するのか。

何年もの間、企業の顧客はクラウドについて同じ懸念を表明してきた：

「十分な速度が出ない。
「仮にそうだとしても、1つのアベイラビリティ・ゾーンに十分なコンピュート数を確実に確保することはできない。

ある顧客はその課題を端的に表現した：

「信頼性や柔軟性を犠牲にすることなく、クラウドで1.5TB/秒を超えるスループットを維持する必要がある。

TBの大文字の "B "は重要だ。これはビットではなくバイトである。1バイトは8ビットに相当するため、1.5TB/秒は1秒間におよそ12テラビットのデータ移動が持続することになる。そして、持続性も同様に重要だ。これは、短時間のバーストやキャッシュによるスパイクではなく、時間と共に維持される継続的なスループットである。

この数字を文脈に当てはめると、4K映画1本をストリーミングするには、通常、毎秒25メガビットが必要だ。12Tb/秒の場合、同じシステムで理論的にはほぼ以下のものをサポートできる。 50万ドル 同時4Kストリーム。

そして、Qumulo CNQは、1.6TB/秒と2070万IOPSを達成し、この挑戦に立ち向かった。

実際、性能の数字だけが真の関心事では決してなかった。現在、1.5TB/秒を必要とする企業はほとんどないが、経験上、現在の需要に合わせた計画だけでは、うまくいくことはほとんどない。クラウドのリソースから高性能のシステムを構築することは、予算、リスク許容度、システムの脆弱性の問題であることが多い。実際、スピードだけを求めて構築することは、多くの組織でCFOとファーストネームで呼ばれるようになる素晴らしい方法だが、良い意味ではない。スピードと脆弱なインフラ・アーキテクチャの組み合わせは、一時的には1つの課題を解決するかもしれないが、ノックオン効果としてさらに多くの技術的・経済的課題を生み出す。

建築の柔軟性という根本的な問題を解決するには、新しい考え方が必要だ。

ほとんどのクラウド・ストレージ・プラットフォームは、顧客に長期的なインフラストラクチャの決定を早い段階で迫る。パフォーマンス、可用性、コストは緊密に結びついており、ピーク時の需要に対して過剰なプロビジョニングを行ったり、耐障害性のためにデータを二重化したり、ワークロードを特定の場所に固定したりする必要がある。一度こうした選択をすると、元に戻すのは難しく、コストもかかる。

その結果、ストレージは、変化するワークロードに適応する柔軟な基盤ではなく、コンピュートチームが計画を立てる際の制約となってしまう。

顧客が問うべきは、"どれくらいのスピードが出るのか？"ではない。

それはこうだ：クラウドは、脆弱なアーキテクチャ、二重化されたストレージ、恒久的に過剰にプロビジョニングされたインフラに閉じ込めることなく、必要なときに、クレイジーで極端なパフォーマンスを提供できるのか？

Qumuloはその挑戦に真剣に取り組んだ。見出しの数字を追うのではなく、異なる運用モデルを証明することで。だからこそ、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のアーキテクチャはクラウド用に設計されたものであり、クラウドに適応したものではない。この違いは重要だ。

ほとんどのクラウド・ファイルストレージ・システムは、実行が不十分だったために失敗したのではない。ハードウェアで定義されていた時代の前提を引き継ぎ、クラウドベースの運用のために完全に再設計されなかったからだ。

従来のファイルシステムは、ストレージ・ハードウェアが容量と性能の両方を定義するという、単純な物理的真実の上に構築されていた。ストレージ・ハードウェアは容量と性能の両方を規定していたのだ。容量と性能は物理的に結合していた。一方がなければ、もう一方を有意義に拡張することはできなかった。このモデルは、組織が回転ディスクを購入し、サーバーをラッキングし、独自のネットワークを配線していたときには、完全に理にかなっていた。

クラウド・プロバイダーがマネージド・ファイル・サービスを導入した際も、同じような想定が多く用いられた。

一部のサービスは容量を自動的に拡張するが、パフォーマンスは保存データ量に連動したままである。また、容量とスループットを固定属性としてプロビジョニングする必要があるサービスもある。弾力性は存在するが、オンプレミスに存在したのと同じカップリングによって制約される。

性能と容量が連動したままであるため、顧客には2つの魅力的でない選択肢が残されている：

ピークへの備え： 利用率が低い場合でも、常に最大限のパフォーマンスと容量を提供する。
平均的な引当金： ワークロードが壁にぶつかり、パフォーマンスがボトルネックになるまでコストを節約する。

ほとんどのチームが最初の選択肢を選ぶのは、ワークロードのスロットルや納期遅れのコストが、オーバープロビジョニングのコストをはるかに上回るからである。 かもしれない クラウド・エコノミクスの対極にあるものだ。

プロトコルの多様性が入ってくると、問題はさらに大きくなる。Linux環境はNFSを期待する。Windows環境はSMBを必要とする。最近のアプリケーションは、S3互換APIを介したオブジェクト・アクセスに依存するようになっている。

その結果が断片化だ。異なるサービス、異なるスケーリングモデル、異なる運用行動。混合ワークロードを実行するチームは、狭いユースケース向けにそれぞれ最適化された複数のストレージシステムを管理することが多い。

時間の経過とともに、ストレージはコンピュートチームが計画を立てる際の制約条件となる。

"どれだけのストレージがあるのか？"彼らは、"何を走らせることができるのか？"と尋ねる。

これは逆だ。インフラはワークロードに適応すべきであり、その逆ではない。

クラウドネイティブのQumuloは、そのカップリングを解消する。

設立当初から、CNQは設計上、パフォーマンスとキャパシティを分離していた。コンピューティングは、耐久性のあるオブジェクト・ストレージとは独立してスケールし、キャパシティを事前に割り当てるのではなく、コンピューティング・リソースを調整することでパフォーマンスを追加または削除する。顧客は消費したストレージの料金のみを支払い、パフォーマンスは固定的なコミットメントではなく、弾力的な属性となる。

これにより、CNQは汎用的なエンタープライズ・ファイル・サービスを経済的にサポートすると同時に、顧客に恒久的なオーバープロビジョニングや断片化されたストレージ・サイロを強いることなく、特殊で高負荷のワークロードに対応するスケーリングを実現します。

この見出しは明快だ： CNQはクラウドに適応するのではなく、クラウドのために設計された。 それでも何か物足りなさを感じる。

課題セーフティネットなしで、オンプレミスより速いスピードへ

顧客の要求は机上の空論ではなかった。

オンプレミスでは、ワークロードは単一のデータセンターで実行され、レイテンシを最小化するためにストレージの近くにコンピートを配置した。電力、冷却、ネットワークなど、インフラに障害が発生すると、ワークロードは停止してしまう。ディザスタリカバリは存在したが、ほとんどのDRシステムと同様、非同期で、テストも不十分で、ワークロードのパフォーマンスをフルに維持することはできなかった。

システムは機能していたが、脆弱だった。

従来、クラウドへの移行は決してスピードの問題ではなかった。新たな制約を導入することなく、単一障害点を取り除くことだった。しかし、もしそれが高速化できたとしたら、顧客のビジネスにどのような影響を与えるだろうか？

クラウドでは、期待は明確だった：

オンプレミスのパフォーマンスを上回る
単一の可用性ゾーンへの依存を避ける
故障時にもフルパフォーマンスを維持
ストレージコストを倍増させることなく

この最後の要件が、多くのクラウド・ファイルシステムが不足している点だ。

ほとんどのマルチ・アベイラビリティ・ゾーン・オファリングは、レプリケーションを利用している。可用性を提供するために、データのフルコピーが各ゾーンに保持される。耐久性には効果的だが、このアプローチには現実的な問題がある。ストレージコストはゾーン数に応じて直線的に増加する。ゾーン間の調整により、書き込みパフォーマンスが低下する。マルチAZは、顧客が通常運用のためではなく、障害シナリオのために確保するものになる。

同時に、クラウドのコンピュート可用性は均等ではない。

GPUやCPUを多用するワークロードは、しばしばゾーンや時間によって異なるキャパシティ制約に直面する。データを単一のゾーンに固定する設計では、たとえリージョンの他の場所にキャパシティがあったとしても、コンピュートもそれに従わざるを得ません。顧客は結局、インスタンスを探したり、データの準備ができる前にコンピュートを予約したり（コストがかかる）、作業を完全に遅らせたり（結果までの時間が延びる）することになる。

顧客はQumuloにスピード、信頼性、回復力を求めました。このソリューションは、ゾーンレベルの依存性を排除し、ストレージの重複を排除し、ワークロードがいつでも利用可能なコンピュートキャパシティで実行できるようにしながら、より高いパフォーマンスを提供しなければなりません。

Qumuloは、レガシーな前提の上に可用性を重ねるのではなく、アーキテクチャレベルでこの問題を解決する。

アーキテクチャ重複ではなく、設計によるマルチ可用性ゾーン

このデプロイの中核は、単一のAWSリージョン内の3つのアベイラビリティゾーンに均等に分散されたマルチAZ CNQクラスタであった。

アベイラビリティゾーン（AZ）は、AWSリージョン内の1つまたは複数のデータセンターから構成される物理的に独立したセットです。各AZは、独自の電源、冷却、ネットワークで独立して動作するように設計されていますが、高帯域幅、低レイテンシのリンクでリージョン内の他のAZと接続されています。このように分離されているため、データセンター全体で障害が発生しても、アプリケーションは利用可能な状態を維持できる。

耐久性はAmazon S3によって地域レベルで提供され、データは複数の施設にわたって自動的に保護されます。これが、AWSがデータ保護の業界ベンチマークとして広く認められている11ナイン（99.999999999％の耐久性）を提供する理由です。

設計上、CNQのアーキテクチャは複数のAWSアベイラビリティゾーンにまたがっており、各ゾーンに顧客データの完全なレプリカを必要としません。その結果

ストレージコストは、CNQが1つのAZで実行されても、複数のAZで実行されても同じである。
クロスゾーン・レプリケーションによる書き込み性能の低下はない
マルチAZ動作は通常状態であり、故障モードではない

注：通常、マルチAZサービスのコストは、シングルAZ実装の2倍かかる。コストを同じにすることは、経済的に大きなメリットがある。

1つのアベイラビリティ・ゾーンが使用不能になっても、クラスタは残りのゾーンで運用を継続し、データの損失はなく、セカンダリ・コピーにフェイルオーバーする必要もありません。

この設計は、レプリカベースのマルチAZアプローチよりもシンプルで高速であり、コストも安い。

これを見出しにするのは簡単だ： CNQアーキテクチャは、データを重複させることなく、マルチAZレジリエンスを実現する。 間違ってはいない。でも、私たちはもっといいことができる。

GPU集約型ワークロードにおけるCNQマルチ可用性ゾーンの優位性

マルチAZは通常、アベイラビリティ機能として議論される。実際に重要なのは、CNQがコンピュートに対して何をアンロックするかである。

ほとんどのクラウド・ファイルシステムは、マルチAZとして販売されているものであっても、ストレージを単一のプライマリゾーンに固定している。コンピューティングはデータに従わなければならない。そのゾーンでGPUやCPUが利用できない場合、たとえリージョンの他の場所に未使用のキャパシティがあったとしても、ワークロードは停滞する。

そのため、チームはGPUとCPUを探し回ることになる。まず、少ないコンピュートインスタンスを探す。そして、そのコンピュート・インスタンスを使用する前に予約し、料金を支払う。次にデータの問題がやってくる。大規模なデータセットは、コンピュートが見つかった場所にコピーするか、再ステージ化しなければならない。これらの手順がすべて終わって初めて、作業を再開することができる。CNQはこの制約を取り払う。

CNQを使用すると、複数のアベイラビリティゾーンのコンピュートで同じデータセットに同時にアクセスできます。お客様は、データのコピーや再ステージングを行うことなく、ゾーン間のキャパシティを単一の論理プールに集約することができます。

月曜日にあるゾーンでGPUが利用可能になり、火曜日に別のゾーンで利用可能になったとしても、顧客はデータを移動したり、インフラを再構築したりする必要はない。既存のCNQデプロイメントを、コンピュートが利用可能な場所に向けるだけだ。

顧客の視点に立てば、これが可能になる：

不足するGPUやCPUへのアクセスを高速化
データのリステージやコピーフェーズがない
レプリケーション・ペナルティなし
保管コストの増加なし

永続ストレージ層として機能するS3内の各可用性ゾーンにデータが既に存在するため、すぐに作業を開始することができる。Amazon Elastic Block Store (EBS)やインスタンス・アタッチド・ストレージとは異なり、このアーキテクチャでは、計算を開始する前にデータを各ゾーンにコピーしたり、再保存したりする必要はない。その代わり、ファイルシステムはNeuralCacheを通じて各AZのローカルデータにアクセスする。このアプローチにより、何週間もかけてデータをステージングする必要がなくなり、高価なコンピュートリソースを最初からフルに活用することができます。

もう一度言うが、これは見出しに違いない： CNQとGPUハンティングを耐えうるものにする技術 我々は正しい道を歩んでいる。それを上回れるかどうか見てみよう。

望むだけパフォーマンスを拡大し、その後縮小する

お客様は、信頼性や柔軟性を犠牲にすることなく、クラウドで1.5TB/秒を超える持続スループットを求めていました。Qumuloは、最終的に期待を上回る1.6TB/秒の持続的な集約スループットと2070万IOPSを達成するテスト導入を行った。確かに、これらの数字は印象的だが（今後の読者は、文脈のために出版日をご覧ください）、これはピーク要件なのか平均要件なのか？もしあなたがこれを読んでいて、1.6TB/sと2070万IOPSに興味を持っている顧客なら、心配する必要はない！以下をご覧ください。

多くの顧客は柔軟性を優先し、需要の変化に応じてリソースを増減する能力を必要としている。前述したように、顧客はしばしば、高いコストをかけてピーク需要に対応するプロビジョニングを行うか、平均的な使用量に合わせてサイジングし、パフォーマンス不足のリスクを負うかのどちらかを選択する。このトレードオフは、クラウドの中核的価値である「可変性」を浮き彫りにする。この構成では、1時間あたりおよそ5,000ドルのコストがかかるため、必要なときに利用価値はあるが、継続的に稼働させるのは経済的に現実的ではない。必要なときだけこのレベルのパフォーマンスを消費できるクラウドベースのアプローチは、オンプレミスのインフラと比較して経済的に実行可能です。

CNQは、ピーク時の容量に常にお金を払うことなく、ピーク時のパフォーマンスを実現します。これが大きな違いです。

多くのクラウド・ファイルシステムでは、パフォーマンスは恒久的にプロビジョニングされた容量に縛られる。ピークに合わせたサイズを設定すれば、ワークロードが落ち着いても、常にピーク価格を支払うことになる。

CNQはこれらの決定を切り離す。

お客様は、締め切り、トレーニング期間、または本番の急増に合わせてパフォーマンスを積極的にスケールアップし、ピークが過ぎたらスケールダウンすることができます。時折発生するスパイクをカバーするためだけにレッドライン構成に固定することはありません。

この弾力性は規模だけでなく、インスタンスの選択にも適用される。このデプロイでは、地域のキャパシティ制約のため、設計の途中でインスタンスタイプを調整した。クラスターは単純に250ノードまで成長し、設計を変更することなく、ノードあたりの低い帯域幅を使用して、およそ333,000の接続を維持した。

その後、ダウンタイムやデータ移行を行うことなく、ローリングリプレースメントを使用して、より低コストで新しいインスタンスファミリーに移行することができます。

私たちはついに見出しを発見した： CNQが提供するもの ピーク・コミットメントなくしてピーク・パフォーマンスなし。 そうだろう？しかし、なぜこれほどのピークパフォーマンスが必要なのだろうか？

Qumuloのおかげで、他のストレージソリューションで経験したよりもはるかに低い運用コストを実現できました。さらに、クラスタの規模を2倍に拡大し、近いうちにさらに2倍に拡大する予定です。
ブライアン・バルダーストン
インフラストラクチャー部長

最高のパフォーマンスが求められる瞬間

すべてのワークロードが極端なスループットを必要とするわけではない。

このアーキテクチャーは、常に1.6TB/sで動作させるというものではない。重要な時にその速度で動作し、それ以外の時間は経済的にも運用的にも不利にならないようにするためのオプションなのだ。

今日過剰だと感じることは、明日のベースラインになる癖がある。では、なぜこのパフォーマンスが必要なのだろうか？

エネルギー会社が10億ドル規模の油井をリースするかどうかを決めることを考えてみよう。問題は、分析に数百万ドルのクラウド費用がかかるかどうかではない。問題は、誰が最初に答えを導き出すかである。早ければ早いほど、誰が資産を確保し、誰が手ぶらで立ち去るかを決めることができる。

ヘルスケアの分野では、ゲノム解析の迅速化が、不確実性の長期化と救命治療の決断の分かれ目になる。

メディアやエンターテインメント業界では、スピードが、プロジェクトがリリース期限に間に合うか、あるいは遅延が予定外のコストに連鎖して利益率を削るかを左右する。より速いレンダリング、より速い分析、より速いイテレーションは、インフラを待つアイドル状態のクリエイティブチームを減らすことを意味する。

これらすべての例において、制約は保存できるデータ量ではない。洞察に要する時間と意思決定に要する時間である。インフラストラクチャーがより速く答えを提供するとき、組織はワークロードをより速く実行するだけでなく、より速く結果を出すことができる。意思決定サイクル全体を圧縮し、最も高価でかけがえのないリソースである専門家の人間の時間から、より多くの価値を引き出しているのだ。

パフォーマンスがスケールアップしたり、スケールダウンしたりすることで、ビジネスがどのような成果を達成できるか想像してみてください。

きっと見出しはこうなるに違いない： インフラを待つのはもうやめよう。CNQはより早く結果を出す。 しかし、これで本当にすべてを把握できているのだろうか？

累積効果

Qumuloは、1.6TB/秒の持続的なシーケンシャル・リード・スループットを提供することで、オンプレミスのシステムと比較して、顧客の当初のパフォーマンス目標を50%以上上回りました。このレベルのパフォーマンスを達成するには、標準的なAWSインフラ上に構築され、3つのアベイラビリティゾーンにまたがるクラウドネイティブなアーキテクチャが必要でした。

さらに重要なことに、この研究は、極限のパフォーマンスが、手の届かないトレードオフを必要としないことを示している。

1.6TB/秒のスループットとともに、システムはミリ秒以下のレイテンシーで2070万IOPSを達成した。

しかし、本当の価値は数字だけではありません。このアーキテクチャにより、顧客は単一のゾーンに限定されることなく、すべてのアベイラビリティゾーンにコンピートを適用することができ、大規模なGPUやCPUの獲得が大幅に容易になります。また、AWS上のCNQの弾力性も検証され、重複によってストレージコストを膨張させることなく、卓越したデータ可用性とイレブンナインの耐久性を実現している。顧客は、パフォーマンスのニーズと予算に合ったインスタンスファミリーを柔軟に選択でき、実際に使用する分だけの料金を支払うことができます。

これらの能力を総合すると、累積効果が生まれる。 累積効果.

もしかしたら、あなたの注意を引くべき見出しはひとつだけではないかもしれない。もしかしたら、それらすべてかもしれない。