3 つのストレージ・システムを管理している組織は、データの保存という 1 つのシンプルな決定のために何百万もの時間を無駄にしています。
オブジェクト・ストレージ、ブロック・ストレージ、ファイル・ストレージは、それぞれ異なる方法でデータを整理し、アクセスします。ブロック・ストレージは、データベースのデータを固定サイズのチャンクに分割します。ファイル・ストレージは、共有ドキュメントに階層フォルダを使用します。オブジェクト・ストレージは、クラウド・アプリケーションのフラットな構造で、リッチなメタデータを使用して非構造化データを管理します。
しかし、問題があります。モダンなワークロードは、このような境界を気にしません。AI トレーニングには 3 つの要件があります。コンテナは、境界線を曖昧にします。また、うまく連携することを拒否する個別のシステムを管理するのが難しくなっています。
このガイドでは、各ストレージ・タイプがどのように機能するか、各ストレージの性能とコスト、ストレージ・タイプの選択が時代遅れになっている理由について解説します。
3 種類のストレージを理解する
ブロック・ストレージ：コストを伴う高速性
ブロック・ストレージは、それぞれ独自のアドレスを持つ固定サイズのブロックにデータを分割します。番号付きのストレージ・ユニットのように考えてみてください。システムは、全てがどこにあるかを正確に把握し、即座にそれをつかみます。
この設計は、0.5～1.5 ミリ秒の応答時間を提供し、最新のオールフラッシュ・アレイは 150 マイクロ秒未満です。毎秒何千ものトランザクションを処理する際に、毎マイクロ秒が重要になるため、データベースに最適です。
ブロックストレージは、iSCSI、ファイバー・チャネル、NVMe over Fabrics などのプロトコルを介して接続し、ファイル・システムのオーバーヘッドなしで直接アクセスします。ただし、難点もあります。メタデータが限定的であるうえ、SAN インフラを考慮すると、GB あたりのコストが高額になることです。
ファイル・ストレージ：馴染みはあるが限定的
ファイル・ストレージは、データを階層フォルダとファイル構造に整理します。デジタル・ファイリング・キャビネットとして、ユーザーにとって直感的で、コラボレーションに最適です。
ネットワーク接続ストレージ（NAS）システムは、NFS（Linux/Unix）または SMB/CIFS（Windows）を介してファイルを共有し、複数のユーザーが同時に同じファイルにアクセスできるようにします。NAS ファイル・サービスは、多くの場合、直接接続のブロック・ストレージよりもレイテンシーが高くなります。プロトコル、ハードウェア、ワークロードによっては、通常はミリ秒から数十ミリ秒の範囲です。ブロック・ストレージ・オプションと比較して、大量のランダム I/O を持つデータベースに障害が生じることがあります。
しかし、その身近な階層がボトルネックになっています。ファイル数が多くなると、一部の NAS／ファイル・システムではメタデータ処理のパフォーマンスに負荷がかかる可能性があります。大規模環境でもパフォーマンスを維持するには、分散メタデータ・サーバーやキャッシュ・レイヤーなど、アーキテクチャを慎重に選択する必要があります。
オブジェクト・ストレージ：大規模環境向けに設計
オブジェクト・ストレージは、個々のオブジェクトのフラットな名前空間を使用して、従来のフォルダなしでデータを整理します。各データは、データ自体、一意の識別子、広範なメタデータの 3 つの部分を持つオブジェクトになります。階層ではなく、オブジェクトのフラット・プールです。
HTTP を使用して REST API を介してオブジェクトにアクセスすると、この設計がより容易に拡張できるようになるまでは制限されているように見えます。例えば、Amazon S3 は、分散インデックスとフラットな名前空間アーキテクチャによって可能となり、グローバル規模で毎秒 1 億件のリクエストに対応します。
パブリック・クラウドのオブジェクト・ストレージは、ネットワーク、ワークロード、キャッシングに応じて、標準セットアップで小さなオブジェクト・アクセスのためのミリ秒～数百ミリ秒のレイテンシーを示すことがよくあります。高度な設計（高速プロトコル、キャッシング・レイヤー、最適化されたオールフラッシュ・ソフトウェアなど）により、一部のオブジェクト・ストレージ・システムは、スケーリング中にミリ秒未満またはマイクロ秒単位のレイテンシーを達成できます。
ストレージ・タイプの比較
メカニズムを理解することで、従来のトレードオフが存在する理由と、もはや必要ない理由が明らかになります。
ブロック・ストレージは、ハードウェアに最も近い場所で動作します。データはブロックに分割され、アドレスが割り当てられ、メディア間で分散され、必要に応じて再組み立てされます。オーバーヘッドが最小限であるため、高速です。コントローラは、各ブロックの正確な位置を把握しています。最新の SAN は、スナップショットやレプリケーションなどの機能を追加しますが、これらはより多くのコントローラ・リソースを必要とし、コストを増大させます。
ファイル・ストレージは、抽象化レイヤーを積み重ねます。ファイル・システムは、ブロックをファイルに整理し、メタデータは権限を追跡し、プロトコルはネットワーク・アクセスを処理します。各レイヤーは、機能だけでなくレイテンシーも追加します。ファイルを開くということは、ディレクトリを横断し、権限をチェックし、ブロックを見つけて、読むことを意味します。共有に適していますが、レイテンシーが増大する可能性があります。
オブジェクト・ストレージは、あらゆるものを再考します。オブジェクトは、一貫したハッシュを使用してノード間で分散され、耐久性のために複製され、API を介してアクセスされます。分散アーキテクチャは水平に拡張できます。さらに、拡張可能なメタデータにより、GPS 座標、コンプライアンス・タグなど、アプリケーションのニーズに応じてあらゆるものを添付できます。
組織が選択に苦慮する理由
ストレージ・タイプごとに個別のシステムを維持することで、インフラ、ツール、専門知識の要件が増大します。複雑さが飛躍的に増大します。
ストレージ・サイロの隠れたコスト
3 つの異なるストレージ・システムを運用するということは、次のような状況を意味します。
- 3 倍のインフラ：個別のネットワーク、スイッチ、管理ツール
- 専門知識の分散：SAN 管理者、NAS スペシャリスト、オブジェクト・ストレージ開発者
- データ・モビリティの摩擦：移行には数か月かかる場合があり、破損のリスクが伴う
実際のコストはストレージではなく、複雑さの管理です。多くの組織にとって、より大きなコスト項目となるのはストレージの物理容量ではなく、複数のストレージ・システムを管理する運用上のオーバーヘッドです。
複数のストレージ層にまたがるモダン・ワークロード
AI ワークフローはさらに複雑になります。
- トレーニング・データは、オブジェクト・ストレージ（ペタバイト単位）に格納されます。
- データ準備には、データ・サイエンティストがアクセスするためのファイル・ストレージが必要です。
- トレーニングには、チェックポイント書き込みのためのブロック・ストレージが必要です。
- モデル・サービングには、3 つのモデルが同時に必要です。
GPU がその実態を物語っています。ほとんどの組織は、ストレージが追いついていないため、GPU 使用率が約 60%～70% にとどまっています。
コンテナは、それを悪化させます。単一の Kubernetes クラスタには、永続的なボリューム（ブロック）、共有ボリューム（ファイル）、オブジェクト・バケットが同時に必要です。DevOps チームは、さまざまなシステム間でストレージ・プロビジョニングを解決するために時間を無駄にしています。
従来のホット／ウォーム／コールド・データ階層が現実と一致しない理由
多くのストレージ・アプローチは、データをホット／ウォーム／コールド・データ階層に分類できるという考えに基づいています。しかし、大規模な本番環境からのテレメトリでは、より複雑で動的なアクセス・パターンが見られることがよくあります。
2025 年の Global Cloud Storage Index によると、クラウド・オブジェクト・データのわずか 19% が本当にコールド（アクセス頻度が年 1 回以下）であり、IT 意思決定者の 83% が少なくとも毎月アーカイブ層にアクセスすると回答しています。つまり、「コールド」と呼ばれているデータの多くは、実際にはかなり頻繁に利用されています。以下に例を示します。
- コンプライアンス監査には 7 年前のデータが必要
- AI トレーニングには、完全な履歴データセットが必要
- ランサムウェアからのリカバリには、迅速なバックアップへのアクセスが必要です。
- 分析クエリは、データレイク全体にまたがります。
多くのストレージ・プラットフォームは、アクセス・パターンに基づいて性能と容量の階層間でデータを移動する階層化アーキテクチャに依存し続けています。これらの設計は、多くの場合、低コストのメディアにあまりアクティブでないデータを配置することでコストを削減することを意図していますが、ソフトウェア、ポリシー管理、運用の複雑さの層も追加しています。
実際には、階層化された環境では、データが正しく配置されるように継続的な監視と調整が必要です。アクセス・パターンが変化したり、データが誤って分類されたりすると、ワークロードのパフォーマンスに予期しないばらつきが生じ、トラブルシューティング作業や運用オーバーヘッドが発生する可能性があります。
オールフラッシュ・ストレージ・システムが成熟するにつれ、メディア密度、データ削減技術、運用効率が向上し、階層型アーキテクチャと非階層型アーキテクチャのコスト・ギャップが縮小しました。これにより、多くのワークロードで単一のパフォーマンス階層でデータを実行することができ、一貫したレイテンシーとストレージ管理の簡素化を実現します。これらの環境では、パフォーマンスは、データがホットまたはコールドのどちらとみなされるかに依存しなくなり、ばらつきを減らし、アプリケーションの動作をより予測しやすくします。
統合ストレージがもたらす変革
選択する必要がないとしたら、どうでしょうか。モダン・アーキテクチャは、妥協することなく、単一のプラットフォームから 3 つのストレージ・タイプ全てを提供できます。
統合ストレージの実際の仕組み
データベースの書き込みを画像化し、150 マイクロ秒単位のレイテンシーでボリュームをブロックします。アナリストは、ファイル共有と同じデータにアクセスします。その後、オブジェクト・ストレージにアーカイブされます。1 つのプラットフォームでブロック、ファイル、オブジェクトのプロトコルを処理できるため、移行やデータ移動を最小限に抑え、それらの間のパフォーマンスのペナルティを低減できます。
組織が複数のストレージ・システムを 1 つに統合すると、次のようなメリットが得られます。
- コスト削減（システム削減、管理削減）
- 管理時間の短縮（1 つのインターフェース、複数ではない）
- 性能向上（最新のフラッシュは従来の専用システムを上回る）
基盤となるストレージがミリセカンド以下の安定した性能を提供するとき、プロトコルの選択は、パフォーマンスの制約ではなく、ソフトウェアの問題となっています。
ストレージに関する正しい判断
ストレージ戦略は、AI ファクトリーの構築において最も重要なアーキテクチャの選択肢の 1 つです。誤った判断は、GPU の活用不足、パイプラインの停滞、運用コストの暴落につながる可能性があります。性能、スケーラビリティ、セキュリティ、管理性のバランスが取れた適切な意思決定が可能です。
統合ストレージが意味を持つとき
統合ストレージは、ブロック、ファイル、オブジェクトのワークロードを単一のプラットフォームに統合し、サイロ化を排除し、運用を合理化します。柔軟性と拡張性が優先される環境では特に重要です。以下の場合は、統合ストレージを検討してください。
- 現在、複数のストレージ・システムが稼働しており、管理オーバーヘッドとデータ・サイロが発生している
- AI/ML ワークロードが計画されており、高スループット・アクセスと柔軟な容量スケーリングの両方が必要
- IT リソースは、個別のシステムを維持する複雑さに悩まされている
- 柔軟性は、各ワークロードを個別に細かく最適化することよりも重要
- ランサムウェア・レジリエンスと迅速なリカバリが最優先事項
モダンな統合プラットフォームは、あらゆるプロトコルにわたってオールフラッシュの性能、サイバー・レジリエンス、インライン・データ削減やアップタイム保証などの高度なデータ・サービスを提供します。単一の管理インターフェースにより、エンタープライズ・グレードの性能と保護要件を満たしつつ、インフラを簡素化できます。
専用ストレージが引き続き適用される場合
特化型ストレージがなくなるわけではありません。柔軟性よりも精密な最適化が重視される特定の用途では、引き続き合理的な選択肢です。特化型システムが必要な状況には、次のようなものがあります。
- ワークロードは変化せず、ストレージのニーズを十分に理解しており、予測可能
- 論理パーティショニングが提供できる範囲を超えて、データの厳密な物理的分離を必要とする規制要件
- 特定のプロトコルやストレージ構成にハードコードされた依存関係を持つ従来のアプリケーション
とはいえ、このような状況でも、業界トレンドは統合システム内の論理的な分離にシフトしています。多くの統合プラットフォームは、ワークロードの分離、暗号化ドメイン、規制基準を満たすのに十分な堅牢性を備えたコンプライアンス機能をサポートしており、サイロ化されたシステムの強力な代替手段となっています。
