CNQが保険のマルチAZをコスト中立の競争優位性に変える方法
クラウドは、場所や地域を問わず実行できる弾力的なコンピューティングを約束します。GPU ワークロードは、その約束をひっそりと破りました。
クラウドにはGPUが存在しますが、データが存在するのと同じリージョンまたはゾーンで利用できますか？必要なときにGPUを利用できますか？
高速コンピューティングの需要は、現在、地域的な供給を上回っています。多くの組織では、GPUの需要が単一のアベイラビリティゾーン、あるいは単一のリージョンにおけるGPUのキャパシティを上回り、重大な業務遅延を引き起こしています。キャパシティは一時的に出現し、予測不能な変化を見せ、そしてあっという間に消失します。
GPUの可用性の不均衡は、新たな運用上の現実を生み出します。チームはもはやGPUの作業をスケジュールする必要はなく、いつでもどこでもGPUが利用可能になる場所を探し求めるようになります。コンピューティングの可用性が動的になるにつれて、データの局所性が制約となります。ようやくGPUが利用可能になっても、データはそこにあるはずの場所には存在しないのです。
ほとんどの組織は、この問題に対して、コストのかかる 2 つの方法のいずれかで対応します。
オプション1：予約して待つ
数百万ドル相当の予約済みGPUがアイドル状態のまま放置されています。これは作業が準備できていないからではなく、データがコンピューティング能力を利用できる場所に存在しないからです。チームは莫大な費用をかけて希少なGPUキャパシティを確保した後、「適切な」アベイラビリティゾーンにデータがコピーされるまで、何時間も、あるいは何日も待ちます。コンピューティング能力が最初に予約され、作業は後から開始されます。何も実行されていない間も、メーターは秒単位で動き続けます。
オプション2: 事前コピーと希望
チームは、複数のアベイラビリティゾーン、リージョン、さらにはクラウドにデータを事前に複製します。データはあらゆる場所で転送、保存、維持する必要があり、ネットワーク料金、ストレージコスト、運用オーバーヘッドが増大します。これらのデータの多くはアイドル状態のまま放置され、GPUが実際に動作するずっと前から予算を消費してしまいます。
その結果、クラウドにおける大規模なGPU導入には、目に見えない損失が潜んでいます。組織がデータの処理を待つか、コンピューティングの処理を行うかに関わらず、結果は同じです。企業は作業開始前に費用を負担することになります。
経営幹部はダッシュボードでこの損失を目にすることはほとんどなく、むしろクラウド料金、プロジェクトの遅延、期限の遅れ、そして競合他社よりも遅いチームの動きといった形で現れます。
これは容量の問題ではありません。Cloud Native Qumulo は、この問題を解決するために構築されたアーキテクチャ上の問題です。
GPUハンティングの隠れたコスト
理論上、クラウドコンピューティングは弾力性を備えています。しかし実際には、GPUの容量は複数のアベイラビリティゾーンに分散され、常に変化しています。今日あるゾーンに容量があっても、明日は別のゾーンに容量が足りなくなる、といった状況です。
ほとんどのストレージ システム アーキテクチャは、これらの条件に適応できません。
従来のクラウドファイルシステムは、依然としてアクティブデータを単一のゾーンに固定しています。「マルチAZ」と謳っていても、コンピューティングを実行するプライマリロケーションに依存しています。レプリカは別の場所に存在しますが、パフォーマンス、ひいては実行は固定されたままです。
結果は予想通りです:
- GPUの可用性がデータのゾーンの居住地と一致しない
- ゾーンGPUの可用性に合わせてデータをコピーする必要がある
- 数百テラバイトのデータが移動している間、GPUはアイドル状態のまま
この「GPU ハンティング税」は、現在、クラウドで AI、ML、シミュレーションを実行するための構造的なコストとなっています。
そして規模が大きくなると状況はさらに悪化します。
コンピューティングリソースが高価で不足するほど、アイドル時間による損害は大きくなります。ストレージが作業場所を決定する場合、リージョン全体の可用性は無意味になります。
マルチAZが修正するはずだったアーキテクチャ上の欠陥
マルチアベイラビリティゾーンは、耐障害性要件を満たすように設計されており、実際にその要件を満たしています。しかし、GPUワークロードの場合、耐障害性は問題ではありません。
アクセスは。
キャパシティが存在する場所であればどこでもコンピューティングリソースをデータに接続できるアーキテクチャではない場合は、マルチAZシステムではありません。バックアップを備えたシングルAZシステムです。
これが、Cloud Native Qumulo が排除するように設計された欠陥です。
CNQはアイドル状態のGPUコストを削減します
Cloud Native Qumulo (CNQ) は、複製ではなく設計によりマルチアベイラビリティーゾーンになっています。
プライマリゾーンがありません。
データ重力なし: コンピューティングは、どこからでも瞬時にデータに接続します。
ステージングフェーズはありません。
CNQを使用すると、複数のアベイラビリティゾーンにあるコンピューティングリソースから同じライブデータセットに同時にアクセスできます。他のプラットフォームでは、アクセスはプライマリアベイラビリティゾーンに制限されています。
CNQ を使用すると、データは一度存在し、地域レベルで永続的に保護され、GPU が利用可能な場所であればどこでもパフォーマンスが提供されます。
容量がシフトする場合:
- 何も動かない
- 何も再建されない
- 何も待たない
チームはGPUが既に存在する場所で作業を開始するだけで済みます。作業はすぐに開始され、アイドル状態は発生しません。
CNQは、万が一に備えてペタバイト単位のデータを事前にコピーするのではなく、オンデマンドでデータをストリーミングします。実際にアクセスされたデータのみがネットワークを通過し、残りのデータはそのまま残ります。GPUはゾーンに関係なく、データに瞬時に接続します。
GPU 探しはロジスティクスの演習ではなくなり、スケジュールの決定になります。
コスト中立のマルチAZがブレークスルー
ほとんどのマルチAZストレージシステムは、耐障害性と引き換えに実質的なコストを課します。別のアベイラビリティゾーンを有効にすると、データが完全に複製され、その新しいゾーンに保存されるため、ストレージコストが増加します。このプロセスは、新しいアベイラビリティゾーンごとに繰り返されます。そのため、組織はマルチAZを渋々有効化し、日常的な運用ではなく障害シナリオ用に確保しておくことになります。
CNQの仕組みは異なります。CNQは可用性と耐久性をAmazon S3にオフロードし、Amazon S3は設計上、リージョンレベルでの保護を提供します。そのため、データセットはアベイラビリティゾーンごとに1つではなく、リージョンレベルで1つだけ存在します。ゾーン間でアクセスできるようにするためだけに、同じデータの完全なコピーを複数作成して料金を支払う必要はありません。1つのアベイラビリティゾーンを使用するか、複数のアベイラビリティゾーンを使用するかに関わらず、ストレージコストは実質的に一定です。
これはチューニングのトリックではありません。根本的なアーキテクチャ上の決定です。
CNQ には次の利点があります。
- 複数のアベイラビリティゾーンに保管されたデータの複数のコピーに対してコスト増加はありません
- マルチAZアクセスによるパフォーマンスの低下なし
- 回復力のための無駄なコストなし
透明性を確保するため、CNQでは、データがアクティブに書き込まれている際に、アベイラビリティゾーン間のネットワーク料金が若干発生する場合があります。ただし、AI、ML、分析ワークロードの大部分では、アクセスパターンは圧倒的に読み取り中心です。実際には、このオーバーヘッドは最小限に抑えられ、データがアイドル状態にある間ではなく、作業の実行中にのみ発生します。常にそうであるように、具体的なワークロードについては、ソリューションエンジニアに確認することをお勧めします。
注: Qumulo では、無料のアーキテクチャレビューおよびソリューション構想セッションを提供しています。
チームがCNQを導入し、アベイラビリティゾーン間のGPU可用性を追跡することで、ストレージシステムのマルチAZ可用性と耐久性が自動的に実現されます。通常は保険機能として扱われるものが、組み込みのメリットになります。マルチAZはもはや、予防措置としてのみ正当化される追加コストではありません。ストレージコストを増やすことなく、GPUが利用可能な場所であればどこでも作業を実行できるようにする、コア機能です。
これがGPUの経済性を変える理由
GPUをプロビジョニングするとすぐに、動作時間1秒ごとにコストが発生します。アイドル時間は無駄なコストとなり、遅延はチームやプロジェクト全体に影響を及ぼします。
GPUが不足すると、チームは常にジレンマに陥ります。データの待機中にコンピューティングコストが発生するか、コンピューティングを待機している間にストレージとネットワーク容量の費用を支払うかです。多くの場合、最終的には両方を支払うことになり、いずれの場合も「GPUハンティング税」を支払うことになります。
ゾーンアンカーを完全に廃止することで、CNQは両方のトレードオフを解消します。リージョンのGPU容量が使用可能な容量になります。お客様は、データの待機時間やアイドル状態のデータコピーの維持に料金を支払う必要がなくなります。GPUが処理を実行した場合にのみ料金が発生します。
より深い利点は選択性です。
CNQの場合:
- チームは数週間前にGPUがどこで利用可能になるかを予測する必要がない
- ストレージはもはや早期インスタンス決定を制限しない
- 新しいインスタンス ファミリーは移行やダウンタイムなしで導入できます
容量、価格、パフォーマンスが変化すると、インフラストラクチャは適切に適応します。
クラウド規模のリソースの約束が今、実現しました。弾力性があり、場所に依存しないコンピューティングはリアルタイムに適応し、インフラストラクチャの配置決定から切り離され、キャパシティが利用可能な場所であればどこでも自由に実行できます。
防御アーキテクチャから競争優位性へ
CNQ により GPU の取得が楽になると言っても過言ではないでしょう。
しかし、その影響は過小評価されています。
CNQが真に排除するのは、アーキテクチャの重力です。ストレージが作業場所を左右することはなくなり、コンピューティングは過去の配置決定に縛られることもなくなります。チームはインフラストラクチャの都合ではなく、機会が訪れた時に動きます。
この時点で、マルチアベイラビリティゾーンはもはや障害への対応ではなく、競合他社よりも迅速に行動し、キャパシティが利用可能になった時点で即座に作業を開始し、アイドル状態だったGPU時間を実際の成果に変えることが重要になります。
それは保険ではありません。
それは利点です。
