オブジェクト・ストレージよりも22%低いコスト、標準的なファイルシステム機能/アクセス、そして最高のパフォーマンスを備えたS3ベースのストレージ
課題ファイルベースのワークロードのクラウドへの移行
あなたはクラウドへの移行を進めている。何千ものアプリケーションのうちの1つかもしれませんが、従来のファイルベースのストレージで稼働しています。パフォーマンス、コラボレーション、予算目標を損なうことなく、アプリケーションをクラウドに移行するにはどうすればよいでしょうか。
歴史的には3つの選択肢があった：
オプション1：オブジェクト・ストレージへのリファクタリング
一見すると、これは「クラウドネイティブ」路線のように思える。S3互換のオブジェクトストレージは安価で、プロビジョニングが簡単で、インフラもほとんど必要ない。
しかし、現実はもっと複雑だ。
キャッチ複雑さ、コスト、ロックイン
レガシー・アプリケーションをオブジェクト・ストレージ用にリファクタリングすること：
時間がかかる： おそらく何万ものアプリでオブジェクト・セマンティクスをサポートするためにコードを書き直すのは、週末の仕事ではない。
高い： インフラは節約できても、ソフトウェアの開発、テスト、長期的なメンテナンスに多額の費用がかかる。
高レイテンシー、低IOPS： オブジェクトストレージは、数十万から数百万の小さな読み書きを必要とする低レイテンシの「おしゃべりな」ワークロード用に設計されているわけではない。ハイパフォーマンスなファイルシステム上で実行されることを期待するワークロードでは苦労するだろう。
オペレーションが複雑： あなたが管理していないアプリ（サードパーティや非推奨のベンダーソフトウェアなど）では、リファクタリングが不可能な場合があります。そのため、ファイル・ゲートウェイを使用するか（次のトピック）、カスタム・ワークフローを作成してオブジェクト・ストレージからローカル・ファイル・システムにデータをハイドレートし、再度書き戻す必要があります。
クラウドベンダーのロックイン： 特定のオブジェクト・ストレージAPI用にリファクタリングすると、特定のクラウド・ベンダーと緊密に結合することになる。
そう、ポジティブなこともある......。
低いインフラコスト
丈夫で弾力性のある収納
配備が簡単
......しかし、ほとんどのファイルベースのワークロードにとって、これらの課題が上回ることはない。
オプション2：ファイル・ゲートウェイ経由のリフト・アンド・シフト
もう1つの一般的なアプローチは、ファイル・ゲートウェイを使って、コードを変更することなくファイルベースのアプリをオブジェクト・ストレージに接続することだ。
キャッチパフォーマンスの低さとAPIコストの高さ
規模が大きい： ゲートウェイは多くの場合、プロトコルの抽象化レイヤーを実行する単一のVMまたはホストとして実装され、オブジェクトストレージAPIの前に位置するNFSまたはSMBサービスを実行する。ローカルキャッシュを使用しても、単一のホストが提供できる最大帯域幅と最大計算量に制限されます。このため、HPC、AIトレーニング、3Dレンダリングのような大規模なワークロードには実用的ではありません。
シングルライターの制限： スケーリングの制限を克服するために複数のゲートウェイを運用するとしても、ほとんどのファイルゲートウェイは様々な場所で安全にアクセスを共有することができません。これはリアルタイムのコラボレーションを排除し、さらに悪いことに、複数のゲートウェイがそれぞれのキャッシュされたデータビューから読み書きを行うため、オブジェクトバケットにデータ破損のリスクをもたらします。
APIコールのオーバーヘッド： ゲートウェイはファイル操作をS3のAPI呼び出しに変換するため、特にメタデータが多いアプリやファイルのアクティビティが小さいアプリでは、コストが爆発的に増加する。
アプリケーションの互換性： 多くのアプリケーションは、ローカルファイルシステム上で動作するように構築・設計されており、エンタープライズグレードのNAS上で動作させることで組織向けに拡張されています。オープンソースのプロトコルスタックを活用したり、FUSEドライバを使用したりするゲートウェイではよくあることだが、公式のLinux NFSサーバやWindowsファイルサーバによって提供される契約に準拠していない、不完全で一貫性のないSMBやNFSの実装は、しばしば許容されない。
ポジティブな点は？
迅速な配備
アプリの変更を必要としない
それでも、このアプローチでは、特に規模が大きくなったり、グローバルなチームにまたがる場合には、多くのことが望まれている。
オプション3：クラウドファイルシステムを使用する
Amazon FSx、EFS、Azure Files、Azure NetApp Filesのようなクラウドホスト型ファイルシステムは、ファイルセマンティクスをクラウドにもたらすことを約束している。
問題点高いコスト、限られた規模、サイロ化された展開
高い： オンプレミスのストレージ・サーバーをクラウドに移植するため、24時間365日プロビジョニング可能なブロック・ストレージ（EBSなど）が必要になり、特に規模が大きくなると、オブジェクト・ストレージに比べてコストが非常に高くなる。
限られた規模： クラウドファイルストレージ」の中には、実際にはクラウドデータセンターで稼働しているサードパーティベンダーのハードウェアに過ぎないものもあり、サプライチェーン、デプロイメントセマンティクス、プロビジョニングのすべてが、オブジェクトストレージやその他のネイティブサービスで使用される標準化されたハードウェアやラック構成とは別物であるため、容量の問題が生じる。他のサービスは、単一のVM上のストレージの限界を超えて成長することができず、最大でも数百TBにとどまるか、ソフトウェアスタックが単にそれ以上のストレージをサポートできないために苦しんでいる。その結果、複数のインスタンスでデータをシャードしなければならず、管理がより複雑になる。
限られた機能： ファーストパーティーのクラウド・ネイティブ・ファイル・サービスの多くは国産の実装であるため、シングル・プロトコルであり、オンプレミスのシステムで慣れ親しんだエンタープライズ・グレードの機能（スナップショット、クォータ、監査ログ、レプリケーション、アクセス制御など）を備えていない。
非弾力的： 一方、既存のオンプレミスソフトウェアスタックのクラウドホスト版については、その多くが、ほぼ静的なデータセンターで、ほぼ静的なサーバーハードウェア上で動作するように設計されたソフトウェアの移植版であることに苦しんでいる。このソフトウェアは、オンデマンドでノードを追加したり削除したりできるようには設計されていない。また、まばらに割り当てられるオブジェクト・ストレージ容量の実質的に無限のプールに対応できるようには設計されていない。そのため、これらの製品の多くは、プロビジョニング時に前もって一方通行のドアを決定する必要があり、必要なときにパフォーマンスをスケールアップしたり、必要でないときにスケールダウンしたり、要件が変わったときにストレージのプロビジョニングを解除したり（そうすれば、ストレージへの支払いを止めることができる）する機能は提供されていない。
ポジティブな点は？
迅速な配備
リファクタリングの必要なし
管理インフラ
しかし、ハイパフォーマンス・コンピューティング、グローバル・コラボレーション、マルチペタバイト・データセットなどのユースケースを含む場合、これらのソリューションでは不十分なことが多い。
より良いクラウド・ファイル・ソリューション
パフォーマンス、コスト、シンプルさの間で選択する必要がないとしたらどうでしょう？
クラウドネイティブのQumuloは、クラウド用にネイティブに構築された、真にモダンなファイルストレージプラットフォームを提供します。
なぜクラウドネイティブのQumuloなのか？
リファクタリング不要
既存のファイルベースのワークロードをそのままクラウドへ。エンドユーザーエクスペリエンスも変わりません。
✅ ネイティブS3統合
アプリケーションをリファクタリングすることなく、S3の耐久性と冗長性を利用できます。
✅ 真のマルチプロトコル
サイロ化することなく、NFS、SMB、S3を使用して同じデータにアクセスできます。
✅ CDF（クラウド・データ・ファブリック）によるグローバル・コラボレーション
地域やクラウドを超えたコラボレーションを即座に実現。レプリケーションは不要です．ただ動くだけです．
✅ 弾力的なスケール
スモールスタートから10EB+まで拡張可能。性能は容量とともに向上し、最大1.6TB/sのスループットと20M IOPSを実現します。
✅ TCOを80%削減
従来のクラウドファイルシステムと比較して、Qumuloは以下の方法で総コストを削減します：
インテリジェントなキャッシュ（S3 APIコストの削減）
圧縮（S3に保存されたデータを減らす）
保管効率の向上
✅ S3 API単独よりも高いパフォーマンス
S3 APIを使用した場合でも、Qumuloは標準的なオブジェクトストレージを凌駕します。
実世界での成功ペタバイト規模の航空宇宙
このような理由から、あるグローバルな航空宇宙企業は、数ペタバイトのワークロードをQumuloに移行することを選択し、大きなメリットを得ました：
スタンダードS3を使用して完全にリファクタリングされたアプリと比較して、 ✅ ストレージコストを22%削減
✅ インテリジェントなキャッシングとクラウド・データ・ファブリック（CDF）により，API呼び出しが減少
内蔵の圧縮機能により、データフットプリントが小さくなります。
✅ レガシー・アプリの再アーキテクチャ／リファクタリングは不要
次のステップへ：今すぐQumuloを試す
単一のアプリケーションを移行する場合でも、数千ものアプリケーションを移行する場合でも、Qumuloは、ファイルベースのワークロードをクラウドで実行するための将来性のある基盤を提供します。
📩 始める準備はできていますか？
Eメール aws@qumulo.com または AWSマーケットプレイス 今すぐ配備を開始する。