2026年のセルフホスティング型S3代替ソリューション（RustFS、Garage、SeaweedFS、Ceph）
MinIOに次いでセルフホスト型S3を選んだ理由
Amazon S3はオブジェクトストレージの事実上のAPIとして定着しています。オープンソースのMinIOリポジトリが2026年4月にアーカイブ化された後、信頼性の高いセルフホスト型代替手段が7つ残っています。
これらの選択肢は互換性があるわけではありません。一部は独自のデータレイアウトを持つフル機能なオブジェクトストレージエンジンであり、他は既存のファイルに薄いゲートウェイとしてアクセスを提供するものです。ネイティブストレージとファイルシステムベースのゲートウェイというこの分岐は、機能リストよりも、バックアップ、復旧、マイグレーションにおいてより大きな決定要因となります。
この記事では、RustFS、Garage、SeaweedFS、Ceph RGW、VersityGW、S3Proxy、rcloneを比較します。各セクションでは、ストレージモデル、S3機能のカバレッジ、プロジェクトの適応範囲、そして選択を決める主な制限事項を扱います。記事の最後には、シングルサーバーおよびマルチサーバーデプロイメント向けの判断ガイドを示します。
より広い視点、つまりオブジェクトストレージ、データベース、検索、AIネイティブなデータレイヤーについては、AIシステムのためのデータインフラをご覧ください。
セルフホストS3ストレージの比較
最も重要な質問は、分散型オブジェクトストレージが必要なのか、それとも既存のストレージの前にS3インターフェースを置くだけで十分なのかということです。
| ソフトウェア | ストレージモデル | 分散型 | S3互換性 | ディスク上のプレーンファイル | 複雑さ | 最適な用途 |
|---|---|---|---|---|---|---|
| RustFS | ネイティブオブジェクトストレージ | はい | 高い（テスト済みサブセット） | いいえ | 低〜中 | 一般的なMinIOの代替 |
| Garage | ネイティブオブジェクトストレージ | はい | 良い（より狭いAPI） | いいえ | 低〜中 | 小型の分散クラスタ |
| SeaweedFS | 分散型Blobおよびファイルストレージ | はい | 高い | いいえ | 中 | 大量のファイル数および混合ストレージ |
| Ceph RGW | Cephオブジェクトゲートウェイ | はい | 高い | いいえ | 高 | 大規模ストレージインフラ |
| VersityGW | POSIXベースのS3ゲートウェイ | バックエンド依存 | 良い | はい | 低 | 通常のファイル上のS3 |
| S3Proxy | S3変換レイヤー | バックエンド依存 | 中程度 | はい（filesystem-nio2の場合） | 中 | ゲートウェイおよびプロトコル変換 |
| rclone serve s3 | S3ゲートウェイ | バックエンド依存 | 基本的（実験的） | はい（ローカルバックエンドの場合） | 非常に低 | シンプルで軽量なデプロイメント |
RustFSは、従来のMinIOデプロイメントへの最も近い直接的な代替手段です。Garageは小型の分散クラスタに適しています。SeaweedFSとCephはより広いストレージ問題を解決します。VersityGWは、オブジェクトペイロードを通常のファイルのままにしておくことで、既存のPOSIXファイルシステムをS3経由で公開できます。Garage、MinIO、AWS S3の機能マトリックスについては、Garage vs MinIO vs AWS S3をご覧ください。
S3ストレージの2つの異なるタイプ
ネイティブオブジェクトストレージは、そのストレージレイアウトを所有します：
RustFS、Garage、Ceph RGW、SeaweedFSは、このファミリに属します。基盤となるディスクに見えるファイルは実装詳細であり、アプリケーションが直接操作すべきではありません。
ファイルシステムベースのS3ゲートウェイは、ストレージに対する関係が異なります：
VersityGWのようなソフトウェアでは、ファイルシステムが権威ある表現として残ることができます。例えば、次のようなオブジェクト：
s3://archive/documents/2026/report.pdf
は、直接以下のパスに対応できます：
/storage/archive/documents/2026/report.pdf
RustFS: 最も近いMinIOの代替
RustFSは、Rustで書かれ、Apache-2.0ライセンスで公開されている分散型オブジェクトストレージシステムです。MinIOのユーザーにとって馴染み深いS3向けの運用モデルを提供するため、MinIOの代替を検討する場合に最初に評価すべきプロジェクトとなります。
現在のS3実装は、ほとんどのアプリケーションが期待する操作をカバーしています：バケット、オブジェクト、マルチパートアップロード、条件付きリクエスト、オブジェクトメタデータ、タグ、バージョニング、ライフサイクル管理、オブジェクトロック、プリサイン済みURL、バケットポリシー、CORS、通知、レプリケーション設定、サーバーサイド暗号化です。
RustFSはS3互換性マトリックスを公開しています。これは完全なAmazon S3のカバレッジという主張ではなく、テスト済みのサブセットです。2026年8月9日にコミット 1e6f5f1e に対して検証されたスナップショットでは、455件の標準テストが実装済み、5件のライフサイクル動作テスト、17件の未実装の標準テスト、そして互換性ゲートをブロックしない270件の除外ケースがリストアップされています。これらの数値が変化した場合、scripts/s3-tests 配下の実行可能リストが真のソースとなります。
RustFSが適している場所
アプリケーションが正式なS3オブジェクトストレージを想定している場合、RustFSが候補となります。
典型的な用途には、アプリケーションオブジェクトストレージ、バックアップリポジトリ、メディアストレージ、AIおよびデータパイプラインの成果物、内部S3インフラ、Kubernetesワークロード、既存のMinIOエンドポイントの置き換えが含まれます。
AWS SDKや一般的なS3クライアントと連携します。通常、アプリケーションではカスタムエンドポイント、認証情報、必要な場合のリージョン設定、およびパススタイルアドレス指定が必要です。
重要な制限事項
RustFSはストレージ表現を所有します。そのデータディレクトリ配下のファイルは、RustFSの内部実装です。
これは、すべてのS3オブジェクトを、オブジェクトストレージソフトウェアなしで検査、コピー、rsync、復旧できるような通常のファイルとして保つ必要がある場合、RustFSが誤った答えであることを意味します。その要件は、ファイルシステムベースのゲートウェイを選択します。
Garage: Ceph級の複雑さのない分散S3
Garageは、小型および中型のセルフホスト環境向けS3互換分散オブジェクトストレージです。Deuxfleursが開発しており、AGPL v3ライセンスの下で、2020年の初期リリース以来本番環境で運用されています。
Garageは、物理的に異なる場所にあるサーバーを含む、いくつかの通常のサーバーで動作するように構築されています。レプリケーションは設計の一部です。
専用ストレージハードウェアのラックではなく、3台の小型サーバーしかない場合、Garageは魅力的です。Dockerからクラスタ構成、レプリケーション、リバースプロキシによるTLSまでの動作するセットアップパスは、Garage クイックスタートに記載されています。
Garageが適している場所
Garageは、ホームラボ、小型ホスティングプラットフォーム、地理的に分散されたサーバー、レプリケーションされたバックアップ、そしてCephが過剰なクラスタに適しています。
その範囲はAWS S3よりも狭いです。Garageの互換性表には、バケットポリシー、ACL、バケットバージョニングが含まれていません。軽量なマルチノードレプリケーションが主たる要件である場合はGarageを、より幅広いS3動作やMinIOのようなアプリケーション互換性がより重要である場合はRustFSを選択してください。
SeaweedFS: オブジェクトストレージ以上のもの
SeaweedFSは、膨大な数のファイルを効率的に保存することから始まり、現在ではS3、FUSEファイルシステム、WebDAV、SFTP、HDFSを公開する分散ストレージプラットフォームとなっています。SeaweedFS 4.48は2026年9月28日にリリースされました。
ボリュームサーバーは、Blobを追記専用ボリュームファイルに詰めます。マスターは個々のファイルではなくボリュームを追跡します。ファイラーは階層型ファイルシステムセマンティクスを提供します。この設計は、数百万または数十億個の比較的小さいオブジェクトを持つワークロードを対象としています。
S3サポート
SeaweedFSは、バージョニング、オブジェクトロック、ライフサイクルルール、タグ付け、CORS、チェックサム、プリサイン済みURL、マルチパートアップロード、バケットポリシー、IAM、STS、およびいくつかのサーバーサイド暗号化モードをドキュメント化しています。
同じクラスタがS3テーブルバケットと組み込みIceberg RESTカタログを配信できるため、Spark、Trino、DuckDBなどのエンジンが、個別のHive MetastoreやGlueなしでIcebergテーブルを使用できます。プロジェクトの一コマンドS3サンプルはポート8333でリッスンします。
SeaweedFSが適している場所
Webクローラアーカイブ、画像および文書リポジトリ、数十億個の小さいオブジェクト、データレイク、S3とファイルシステムの混合ワークロード、およびボリュームサーバーの追加によって成長するストレージに対して、SeaweedFSを検討してください。
シンプルRustFSインストールよりも理解すべきコンポーネントが多くあります。SeaweedFSはファイラーとFUSEマウントを通じてファイルシステムセマンティクスを提供できますが、オブジェクトはそのボリューム形式内に保存されます。すべてのS3オブジェクトをホストファイルシステム上の独立した通常のファイルとして保つという要件には応えません。
Ceph RGW: インフラ規模の選択肢
CephはS3ストレージよりも広い範囲をカバーします。クラスタはRBDによるブロックデバイス、CephFSによるファイルシステム、RADOS Gateway (RGW)によるオブジェクトストレージを提供できます。RGWは、RADOSに裏付けられたS3互換APIを提示します。
Cephは、レプリケーション、エラージャーコーディング、障害ドメイン、複数ゲートウェイ、マルチサイトデプロイメント、アクセスポリシー、クラスタ管理ツールをサポートしています。
Cephが適している場所
オブジェクトストレージがより大きなストレージプラットフォームの一部である場合、Cephが理にかないます。Kubernetes永続ボリューム、仮想マシンディスク、共有ファイルシステム、大規模S3リポジトリ、明示的な障害ドメインを必要とするクラスタなどがそれにあたります。
数テラバイトしかないシングルサーバーに対して、S3エンドポイントを得るためにのみCephをインストールするのは正当化しにくいです。すでにCephを運用しているのであれば、RGWが明白なS3選択肢です。そうでなければ、RustFSまたはGarageの方が、より少ない仕組みで実用的なオブジェクトストレージに到達します。
VersityGW: 通常のファイル上のS3
ファイルシステム自体が重要である場合に評価すべき選択肢がVersityGWです。これはApache-2.0ライセンスのS3ゲートウェイで、POSIXファイルシステム、ScoutFS、Azure Blob Storage、他のS3サービス、カスタムバックエンドを公開できます。
そのPOSIXバックエンドは、S3バケットとオブジェクトをディレクトリとファイルにマッピングします。例えば：
s3://website-assets/images/logo.png
は、次のようなパスにマッピングされます：
/storage/website-assets/images/logo.png
logo.png のペイロードは通常のファイルのままです。
プレーンファイルが有用な理由
通常のUnixツールを使用してストレージを検査できます：
find /storage -type f
du -sh /storage/*
S3サーバーなしでオブジェクトを読み取れます：
cat /storage/archive/2026/source.html
従来のファイルシステムバックアップツールが直接適用できます：rsync、restic、borg、tar、zfs send。ゲートウェイソフトウェアが消失しても、ペイロードはディレクトリツリー内のファイルのままです。
POSIXバックエンド上のS3メタデータ
S3メタデータは、POSIXファイル単体では収まりません。VersityGWはデフォルトで拡張属性（xattr）に保存します。2026年3月以降、オブジェクトメタデータは単一の user.metadata xattr内のJSONとして保持されます。これは、キーごとの1つのxattrがファイルシステムのキー長制限に抵触したためです。versitygw utils convert-xattr-metadata コマンドは、より古いキーごとの属性を書き換えます。user.metadata が存在しない場合、読み取りは旧レイアウトにフォールバックします。
xattrのないファイルシステムでは、メタデータを別のディレクトリツリーに保持するために --sidecar（または VGW_META_SIDECAR）を使用できます。プロジェクトは、sidecarと --nometa がxattrよりもテストが少ないとマークしています。--nometa はメタデータ保存を無効にし、すでに存在するデータセットの読み取り専用ホスティングを対象としています。バケットポリシーとACLはメタデータであるため、そのモードでは利用できません。
オブジェクトのバージョンは、別のディレクトリ内に配置できます。プロジェクトのPOSIXサンプルでは、現在のペイロードが自然なパスに残る間、古いバージョンのために --versioning-dir を渡しています。
ゲートウェイの背後でファイルを変更すると、S3メタデータ（ETagを含む）が新しいバイトと不一致になる可能性があります。機能する運用モデルは以下の通りです：
アプリケーションアクセス:
S3経由で読み取り
S3経由で書き込み
管理者アクセス:
ファイルシステムを直接読み取り
ファイルシステムを直接検査
ファイルシステムを直接バックアップ
ゲートウェイの背後でオブジェクトを変更しない
VersityGW 1.8.0は、2026年9月のCOSIドライバーリリースがターゲットとしていたバージョンですが、スタンドアロンIAMサービス（versitygw iam）、STS AssumeRoleWithWebIdentity、およびIAMポリシー条件を追加しています。
S3Proxy: 一般的な変換レイヤー
S3Proxyは、S3 APIを実装し、リクエストを複数のバックエンドに変換します：ローカルファイル、Azure Blob Storage、Google Cloud Storage、OpenStack Swift、SFTP、および他のS3サービス。Java 17以降が必要です。
推奨されるディスク上のプロバイダーは filesystem-nio2 です。旧型の filesystem プロバイダーは非推奨です。オブジェクトキーはファイルシステムパスになり、メタデータはユーザー拡張属性を使用するため、ペイロードは通常のファイルのままです。
ファイルシステムバックエンドは、オブジェクトバージョニングとサーバーサイド暗号化を拒否します。実際のディスクに書き込まれたバージョンレイアウトは、プロジェクトが維持しなければならない形式になるため、バージョニングは未サポートのままです（supportsVersioning() は偽で、それらのリクエストはHTTP 501のままです）。サーバーサイド暗号化も同じ類の理由で拒否されます。誰かが読めるプレーンテキストファイル上でAES256と報告することは、誤った主張となるためです。インメモリバックエンド transient-nio2 は両方を実装していますが、データはプロセスの終了とともに失われます。プロジェクトのREADMEは、private および public-read 以外のバケットポリシー、オブジェクトタグ、ACLも未サポートとしてリストしています。
バックエンド間の変換が必要ない場合にS3Proxyはツールとなります。シンプルなS3からPOSIXへのゲートウェイであれば、VersityGWの方が表面積が小さいです。
rclone serve s3: 軽量だが実験的
rclone serve s3は、rcloneバックエンドをS3互換APIを通じて公開します。ドキュメントはこのコマンドをまだ実験的とラベル付けしています。
ローカルファイルシステムの場合：
rclone serve s3 \
--addr :9000 \
--auth-key ACCESS_KEY,SECRET_KEY \
local:/srv/s3
--addr を指定しない場合、サーバーは 127.0.0.1:8080 にバインドします。--auth-key はSignature Version 4を有効にします。マルチパートアップロードは、パート番号の順序で一時オブジェクトに書き込まれ、完了時に指定された場所にリネームされるため、失敗したアップロードは既存のオブジェクトを置き換えません。
local バックエンドを通じて書き込まれたオブジェクトは、そのパス配下のファイルになります。同じコマンドは、他のrcloneリモートの前面に配置することもできます。内部ツール、ラボ、または一時的なマイグレーションのホップには適した選択肢です。しかし、無関係な本番アプリケーション多数のための永続的なS3レイヤーとしては弱いと言えます。
MinIOはどうなった？
MinIO GitHubリポジトリは2026年2月13日にアーカイブ化され、短期間アーカイブ解除された後、2026年4月25日に再びアーカイブ化されました。現在は読み取り専用です。リポジトリの通知は、MinIOの商用ディストリビューションであるAIStorを運用者に示し、コミュニティエディションはソースコードのみであることを述べています。
既存のMinIOデプロイメントは、特に分離されておりその動作がすでに理解されている場合、実行を継続できます。完全なタイムライン、運用リスク、段階的なマイグレーション計画は、2026年のMinIO CEにあります。
離れようとしているシステムのS3動作については、AWS S3の代替としてのMinIOが、MinIOがS3にどのようにマッピングされるかをドキュメント化しています。まだ稼働しているクラスタの監査の相棒として、MinIOコマンドラインチートシートがあります。新規インストールでは、アクティブにメンテナンスされている代替手段がデフォルトとなります。
プレーンファイル vs ネイティブオブジェクトストレージ
オブジェクトストレージが耐久性、メタデータ、分散、レイアウトを制御すべき場合、RustFS、Garage、SeaweedFS、またはCephを使用してください。これにより、より豊かなS3セマンティクス、レプリケーションまたはエラージャーコーディング、水平スケーリング、およびプロジェクトが実装する箇所のバージョニングが得られます。コストは、エンジンのディスク上表現への依存です。
既存のファイルシステムを権威あるものとして残すべき場合、VersityGW、S3Proxy、またはrcloneを使用してください。これにより、復旧可能なプレーンファイル、従来のバックアップ、直接検査、およびZFS、XFS、ext4、NFSとの互換性が得られます。分散耐久性は、S3プロセスからではなく、ファイルシステムまたはストレージアレイから得られる必要があります。シングルサーバーやNASでは、このトレードオフは多くの場合正しいものです。
適切なセルフホストS3サーバーの選択
MinIOに似るべきシングルサーバーの場合、RustFSから始めましょう。
レプリケーションが主たる要件であり、アプリケーションがバケットポリシーやバージョニングなしで動作できる場合、3台以上の modest なサーバーがある場合は、Garageを選択してください。
膨大な数の小さいオブジェクト、ファイルシステムアクセスの混合、またはIcebergテーブルに成長しうるデータレイクワークロードの場合は、SeaweedFSを検討してください。
同じクラスタがブロックデバイスと分散ファイルシステムも提供すべき場合、Ceph RGWを選択してください。
要件が特に通常のファイル上のS3 API、つまりNAS、アーカイブ、文書リポジトリ、クローラ、またはバックアップターゲットである場合、VersityGWから始めましょう。
Azure、GCS、Swift、SFTP、または他のS3サービスへのS3変換が作業である場合、S3Proxyを使用してください。
デプロイメントが小さく、一時的であり、実験的なサーバーを許容できる場合、rclone serve s3 で十分な場合があります。
単一ストレージサーバー向けの推奨アーキテクチャ
アプリケーションがS3経由でのみデータに到達すべき場合、RustFSがオブジェクトレイヤーを所有し、ファイルシステムは実装詳細となります：
ファイル自体がゲートウェイを生き残る必要がある場合、データをPOSIXツリー内に保持します：
第2の設計では、冗長性はZFSミラー、RAID、スナップショット、ファイルシステムレプリケーション、または従来のバックアップツールです。S3サービスは、データ形式を書き換えることなく置き換えることができます。
最終的な考察
MinIOのパブリックリポジトリが読み取り専用になっても、メンテナンスされるセルフホストS3は依然として存在します。重要な選択は、S3がバイトを所有するのか、それともすでに存在するファイルの前に立つだけなのかということです。上記のすべての比較は、その答えから導き出されます。
