AIワークロード向けオブジェクトストレージ
AIワークロード向けオブジェクトストレージ
オブジェクトストレージは、データをディスク上のフォルダ内のファイルやブロックとしてではなく、自己完結したオブジェクトとして保存します。写真、動画、音声、メール、Webページ、センサーの読み取り値、そしてAIアプリケーションが生成するベクトル埋め込みなど、非構造化データのために作られています。
クラウドオブジェクトストアは、このデータを多数のマシンに分散しますが、HTTP APIを通じて単一のプールとしてすべてにアクセスできるようにします。各オブジェクトは3つのものを保持します。データそのもの、追加した任意のメタデータ、そして一意のIDです。ファイルの種類に関係なく、そのIDで任意のオブジェクトを取得または分析できます。
最初のクラウドオブジェクトストアであるAmazon S3は、現在500兆を超えるオブジェクトを保持しています。クラウドのデフォルトのストレージレイヤーとなっています。
オブジェクトストレージの仕組み
3つのストレージモデルは、データをそれぞれ異なる方法で扱います。ファイルシステムはデータを入れ子のフォルダに置きます。ブロックストレージはデータをディスク上の固定サイズのブロックに分割します。オブジェクトストレージは、各項目をフォルダなしのバケットと呼ばれるフラットなコンテナ内に丸ごと保持します。
ファイルを保存するには、システムがデータを受け取り、指定した任意のメタデータを追加し、IDを付与します。その後、アプリはHTTP API経由でそのIDを使ってオブジェクトを読み取り、書き込み、削除します。ファイルパスもマウントポイントもありません。
PUT /my-bucket/embedding-batch-042.parquet # store an object
GET /my-bucket/embedding-batch-042.parquet # retrieve it by ID
DELETE /my-bucket/embedding-batch-042.parquet # remove it
フラットな構造こそが、オブジェクトストレージをスケールさせる要因です。フォルダツリーを作り直すのではなく、プールにマシンを追加することで容量を増やすため、単一のバケットはほぼ無制限に拡張できます。2006年に登場したAmazon S3は、業界の他社が模倣するAPIを確立し、Ceph、MinIO、OpenStack SwiftはいずれもS3互換であり、他の主要クラウドも同様です。
| サービス | プロバイダー | API標準 |
|---|---|---|
| Amazon S3 | AWS | S3（事実上の標準） |
| Cloud Storage | Google Cloud | S3相互運用 + ネイティブ |
| Blob Storage | Microsoft Azure | ネイティブ + S3互換ゲートウェイ |
| MinIO / Ceph | セルフホスト（オープンソース） | S3互換 |
主な特徴と制限
オブジェクトストレージの設計は、明確な強みと明確な限界をもたらします。
主な特徴
- ほぼ無制限にスケールします。 単一のバケットに必要な数だけオブジェクトを保持できます。より多くのデータを書き込むことで容量を追加し、事前にクラスタのサイズを決める必要はなく、保存した分だけ支払います。
- 耐久性とレジリエンスがあります。 オブジェクトストアは、各オブジェクトのコピーを複数のマシンに保持し、多くの場合データセンターやリージョンをまたいで保存します。Amazon S3はイレブンナイン（99.999999999%）の耐久性を目標に設計されており、すべてのオブジェクトが少なくとも3つのAvailability Zoneにまたがって保存されます。
- 安価で、階層があります。 ギガバイトあたりの価格はブロックストレージやファイルストレージを大きく下回り、コールドデータは自動的により安価な階層へ移動します。
- 豊富なメタデータとともに、あらゆるデータを保持します。 1つのバケットであらゆる種類の非構造化データを保持でき、各オブジェクトには定義したメタデータが付与されます。ファイルタイプに関係なく、そのメタデータでオブジェクトを見つけてフィルタリングできます。
- オープンでアクセスしやすいです。 オブジェクトはシンプルなHTTP API経由で読み取られます。S3 APIは事実上の標準であるため、多くのツールが特別なコネクタなしで同じバケットを読み取れます。
制限
- ブロックストレージより遅いです。 すべてのリクエストがHTTP経由で行われるため、オブジェクトストレージは低レイテンシのランダムアクセス作業やトランザクションデータベースには適していません。
- インプレース編集はできません。 オブジェクトの一部を変更するのではなく、オブジェクト全体を置き換えるため、頻繁に変更されるデータにはオブジェクトストレージは適していません。
- 小さな読み取りは高くつきます。 多数の小さな読み取りを行うワークロードでは、データ自体が小さくてもAPI料金が大きく膨らむ可能性があります。
- 検索やコンピュートは組み込まれていません。 オブジェクトストレージはバイトを保存して提供します。インデックスも検索も分析もありません。「このオブジェクトをIDで取得する」を超える処理には、その上にクエリエンジンが必要です。この最後のギャップこそが、オブジェクトストレージがAIデータの基盤でありながら、それ単体ではAI検索を提供できない理由です。
ユースケース、そしてAIへの橋渡し
オブジェクトストレージは、そのスケール、耐久性、低コストにより、多くのワークロードのデフォルトの保管先になっています。
- データレイク（標準的なストレージ基盤）
- バックアップと災害復旧
- 長期アーカイブ
- メディアの保存と配信
- ログと分析データ
- ML トレーニングセット（モデルが学習する大規模データセット）
AI 検索は今、オブジェクトストレージに対して、データを保持する以上のことを求めています。埋め込みは、セマンティック検索と検索拡張生成（RAG）の背後にある数値ベクトルです。埋め込みの数は膨大で、一つひとつが大きく、それらを専用データベースに保存すると高コストになります。
そのため、チームは埋め込みをオブジェクトストレージに直接保持し始めています。2025 年 12 月から一般提供されている Amazon S3 Vectors は、S3 にネイティブなベクトルストレージと検索を追加します。AWS によると、専用ベクトルデータベースと比べてベクトルの保存とクエリのコストを最大 90% 削減し、インデックスあたり最大 20 億ベクトルを保持し、頻繁なクエリには約 100 ミリ秒、まれなクエリには 1 秒未満で応答します。
問題は速度です。オブジェクトストレージは今やベクトルを低コストで保持し検索できますが、データをオブジェクトストレージに置いたまま、別の高速ストアへコピーすることなく検索に高速に応答することが難しい点です。
AI インフラストラクチャにおけるオブジェクトストレージ
オブジェクトストレージには、AI にとって一つ大きな欠点があります。それ自体を検索する方法がないことです。埋め込みは安価に格納できますが、類似性検索を行う場合、悪い選択肢が 2 つあります。データを専用のベクトルデータベースにコピーすれば、2 つのコピーを保持し、2 つの料金を払い、それらの同期を保つ必要があります。インデックスなしで生ファイルを検索すれば、本番環境には遅すぎます。
解決策は、オブジェクトストレージに欠けている唯一のもの、つまりデータが置かれている場所で検索する方法を与えることです。そのためには 3 つの要素が必要で、いずれも標準では組み込まれていません。
- データの隣にあるインデックス。 ベクトルインデックスは、別システムではなく、データの隣のオブジェクトストレージ上に置かれます。
- 必要なものだけを取得する読み取り。 クエリエンジンは、ファイル全体ではなく、クエリが触れるインデックスページとデータ断片だけを取得します。
- 前段のキャッシュ。 メモリまたはローカル SSD がオブジェクトストレージの前に置かれ、ホットデータは往復なしで提供されます。
これらを組み合わせることで、オブジェクトストレージを受動的なストアとして扱うのではなく、直接検索できるようになります。
Zilliz Vector Lakebase は、このように構築されたシステムの一つです。データとインデックスをオブジェクトストレージ上に保持し、それらをクエリするコンピュートとは分離します。複数のコンピュートクラスターが、提供、探索、分析のために、データを複製せずに同じデータコピーを同時に読み取ることができます。External Collections 機能は、Lance、Iceberg、Parquet、または独自の Vortex 形式のいずれであっても、すでに持っているレイクテーブルを指し示し、その場でベクトル検索を実行します。
10 億ベクトルの Iceberg テーブルに対する Zilliz のベンチマークでは、速度はデータのキャッシュ方法によって異なります。
- インデックスなし（総当たりの Spark スキャン）：数時間
- コールド（インデックス作成直後、約 20 分）：約 30 秒
- ウォーム（ローカル SSD キャッシュから）：数十ミリ秒
- ホット（メモリから）：1 桁ミリ秒
各クエリは必要なページだけを読み込むため、Zilliz は読み取り増幅（無駄なデータ転送）を 90% 以上削減し、同社の Vortex 形式は Parquet よりも S3 からの 1 回の読み取りあたりのデータ転送量を 135 分の 1 に抑えると報告しています。
このパターンは、特定の製品にとどまるものではありません。オブジェクトストレージは、AI データが保存される場所であることに加え、その上で直接検索される場所へと変わりつつあります。
よくある質問
オブジェクトストレージは AI ワークロードに適していますか？
はい。耐久性、ほぼ無制限の容量、低コストが活きる、トレーニングデータ、埋め込み、モデル成果物の大規模な保存に適しています。制約は速度です。そのデータを高速に検索するには、生のストアの上にインデックスとコンピュートが必要です。
オブジェクトストレージとベクトルデータベースの違いは何ですか？
オブジェクトストレージは、ID でアクセスされる、あらゆる非構造化データのための汎用ストアです。ベクトルデータベースは、埋め込みに対する類似検索のために構築されており、高速な最近傍クエリ向けに調整されたインデックスを備えています。この 2 つは収束しつつあります。チームはますます、ベクトルをオブジェクトストレージに保持し、その上に検索レイヤーを追加するようになっています。
オブジェクトストレージ上でベクトル検索を直接実行できますか？
ますます可能になっています。AWS S3 Vectors はネイティブなベクトル検索を追加しており、レイクテーブルをその場で参照するプラットフォームでは、オブジェクトストレージのデータを外部にコピーすることなく検索できます。クエリはインメモリインデックスよりも遅く実行されますが、コストははるかに低くなります。
なぜデータレイクはオブジェクトストレージを使用するのですか？
データレイクは、構造化データと非構造化データの膨大な量を、安価かつ耐久性高く、オープン形式で保持し、同時に多くのエンジンからアクセス可能にする必要があります。オブジェクトストレージのフラットで ID アドレス指定されたプールは、ファイルストレージやブロックストレージよりもその用途に適しています。
オブジェクトストレージはブロックストレージより遅いですか？
単一の操作については、通常はそうです。ブロックストレージは、トランザクション処理やランダムアクセスの作業に対して非常に低いレイテンシを提供します。オブジェクトストレージは、大規模で主に静的なオブジェクトを HTTP 経由で読み取る際のスループット、耐久性、コストと引き換えに、その低レイテンシを犠牲にしています。大きなシーケンシャル読み取りでは差は縮まりますが、小さくレイテンシに敏感な読み取りでは依然として大きな差があります。
AI のためのオブジェクトストレージ：次のステップ
オブジェクトストレージは、AI データスタックの残りの部分が構築される基盤です。ベクトルネイティブなプラットフォームが、オブジェクトストレージのデータに対して直接、検索、発見、分析をどのように実行するかを確認するには、From Vector Database to Vector Lakebase を読むか、Zilliz Cloud platform をご覧ください。