1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@rino_yume(rino yume)

MinIOの代わりにRustFSを使ってみる 1 — Rust製S3互換Object StorageをDockerで試す

1
Posted at

MinIOの代わりにRustFSを使ってみる — Rust製S3互換Object StorageをDockerで試す

はじめに

オンプレミスやローカル環境でS3互換のObject Storageを用意するとき、これまではMinIOを使うことが多かったと思います。

自分も、GeoParquet、COG、PMTiles、Zarr、Parquetなどを扱うデータ基盤では、S3互換の保存先としてMinIOを使う構成を考えていました。

ただ、2026年現在、MinIO Community Editionは配布形態が変わり、公式GitHubではCommunity Editionをsource-only distributionとして案内しています。ライセンスはAGPLv3です。

そこで、MinIOの代わりとして使えるS3互換Object Storageを調べたところ、候補の一つとして出てきたのが RustFS です。

RustFSはRustで実装されたオープンソースの分散Object Storageで、Amazon S3互換APIを提供します。つい最近、2026年9月16日には RustFS 1.0.0 が正式リリースされました。

今回は、いきなりMinIOを全面的に置き換えるのではなく、まずDocker ComposeでRustFSを起動し、boto3から基本的なS3操作ができるところまで確認します。

RustFSを起動
    ↓
S3 APIを確認
    ↓
boto3から読み書き
    ↓
実データで確認
    ↓
MinIOからの移行を検討

1. RustFSとは

RustFSは、Rustで実装されたS3互換の分散Object Storageです。

主な特徴は次のとおりです。

RustFSの特徴

  • Amazon S3互換API
  • Rustで実装
  • Apache License 2.0
  • Docker / Kubernetes対応
  • 分散構成対応
  • Erasure Coding対応
  • Web Console
  • IAM
  • TLS
  • Replication
  • Object Lock
  • Versioning
  • OpenTelemetryを利用した監視

アプリケーション側から見ると、AWS SDKやboto3などを使ってアクセスできます。

20260922_m01.png

通常のファイルサーバーとは少し考え方が違います。

例えば、

Bucket
├─ raw/
├─ processed/
├─ geoparquet/
├─ cog/
└─ pmtiles/

のように、BucketとObject Keyでデータを管理します。

2. MinIOの代わりとしてRustFSを見る理由

RustFSを候補にした理由は、単にRustで作られているからではありません。

特に大きいのは次の点です。

  1. S3互換APIを使える
  2. Apache License 2.0
  3. Dockerで簡単に動かせる
  4. 分散構成へ拡張できる
  5. AWS SDKをそのまま利用できる

特にS3互換であることは重要です。

アプリケーションを、

Application
    │
    │ S3 API
    ↓
Object Storage

という構造にしておけば、保存先への依存を小さくできます。

例えば、

MinIO
  ↓
RustFS
  ↓
AWS S3

と切り替える場合も、アプリケーション側をS3 APIの範囲に収めておけば変更箇所を減らせます。

自分としては「RustFS専用のアプリケーション」にするのではなく、S3互換Object Storageを差し替えられる構成にすることを重視しています。

3. RustFSとMinIOを大まかに比較する

2026年9月時点の大まかな違いを整理します。

項目 RustFS MinIO Community Edition
主な実装言語 Rust Go
API S3互換 S3互換
ライセンス Apache License 2.0 AGPLv3
Docker 対応 対応
分散構成 対応 対応
Erasure Coding 対応 対応
IAM 対応 対応
Web Console 対応 対応
TLS 対応 対応
Replication 対応 対応
運用実績 まだ新しい 長い
Community版の配布 バイナリ・コンテナあり source-onlyが基本

ここで注意したいのは、RustFSが新しいからMinIOより優れている、と単純には判断できないことです。

MinIOには長い運用実績があります。

一方、RustFS 1.0.0が正式リリースされたのは2026年9月16日です。

そのため、本番環境へ入れる前には機能の有無だけでなく、

  • 長時間連続運転
  • 大量Object
  • 大容量Object
  • ディスク障害
  • ノード障害
  • 再起動
  • Healing
  • Version Upgrade

まで確認する必要があります。

4. S3互換でもAmazon S3そのものではない

ここは最初に確認しておきたいところです。

RustFSはS3互換Object Storageですが、Amazon S3のすべての機能を完全に実装しているわけではありません。

RustFS公式のS3 Compatibility Matrixでも、RustFSは「テスト済みのAmazon S3 APIのサブセット」を実装すると説明されています。

2026年8月9日時点のCompatibility Matrixでは、

Implemented tests          455
Lifecycle behavior tests     5

となっています。

つまり、

Amazon S3で動く
      ↓
RustFSでも必ず動く

とは限りません。

実際に自分のシステムで使うAPIを確認する必要があります。

例えば、まず確認したいのは次のあたりです。

CreateBucket
PutObject
GetObject
DeleteObject
ListObjectsV2
Multipart Upload
Presigned URL
Versioning
Lifecycle

全S3 APIを試すより、利用する機能を絞って試験した方が現実的です。

5. 今回の構成

今回はUbuntu 24.04上のDocker Engine + Docker Composeを前提にします。

20260922_m02.png

使用するものは次のとおりです。

Ubuntu 24.04
Docker Engine
Docker Compose
RustFS
Python
boto3

最初はSingle Node / Single Disk相当の構成です。

この構成には冗長性がありません。

あくまで開発・検証用として使います。

6. 作業ディレクトリを作る

まずディレクトリを作ります。

mkdir rustfs-demo
cd rustfs-demo
mkdir -p scripts

今回は次の構成にします。

rustfs-demo/
├── compose.yaml
├── .env
├── .gitignore
└── scripts/
    └── test_s3.py

7. 認証情報を設定する

.envを作ります。

RUSTFS_ACCESS_KEY=replace-with-your-access-key
RUSTFS_SECRET_KEY=replace-with-a-long-random-secret

Secret Keyは固定文字列をそのまま使わず、例えばOpenSSLで生成できます。

openssl rand -base64 32

.envはGitへ登録しないようにします。

.gitignoreは次のようにします。

.env
.venv/
__pycache__/

RustFS公式ドキュメントでも、ネットワークへ公開する前に独自のAccess KeyとSecret Keyを設定するよう案内されています。

8. Docker Composeを作る

compose.yamlを作ります。

services:
  rustfs:
    image: rustfs/rustfs:1.0.0
    container_name: rustfs
    restart: unless-stopped

    ports:
      # S3 API
      - "9000:9000"

      # Web Console
      - "9001:9001"

    environment:
      RUSTFS_ACCESS_KEY: ${RUSTFS_ACCESS_KEY}
      RUSTFS_SECRET_KEY: ${RUSTFS_SECRET_KEY}

      RUSTFS_ADDRESS: ":9000"
      RUSTFS_CONSOLE_ADDRESS: ":9001"
      RUSTFS_CONSOLE_ENABLE: "true"

      RUSTFS_OBS_LOGGER_LEVEL: "error"
      RUSTFS_OBS_LOG_DIRECTORY: "/var/log/rustfs/"

    volumes:
      - rustfs-data:/data

    command:
      - /data

volumes:
  rustfs-data:

公式ドキュメントではrustfs/rustfs:latestの例が使われていますが、今回は再現性を優先して1.0.0へ固定しています。

本番環境では、さらにimage digestまで固定する方法も検討できます。

9. RustFSを起動する

起動します。

docker compose up -d

状態を確認します。

docker compose ps

ログも確認します。

docker compose logs rustfs

RustFSのHealth Checkは次のURLで確認できます。

curl --fail http://localhost:9000/health

S3 APIとWeb Consoleは次のポートです。

S3 API
http://localhost:9000

Web Console
http://localhost:9001

ブラウザから、

http://localhost:9001

へアクセスするとConsoleを開けます。

10. ホストディレクトリをマウントする場合の注意

今回の例ではDocker named volumeを使っています。

そのため、ホスト側で特別な権限設定は必要ありません。

一方、

volumes:
  - ./data:/data

のようにホスト側ディレクトリを直接bind mountする場合は注意が必要です。

RustFS公式コンテナは非rootユーザーで動作し、UIDは10001です。

そのため、例えば次のように所有者を合わせます。

mkdir -p data
sudo chown -R 10001:10001 data

権限が合っていない場合、

Permission denied

となる可能性があります。

最初の動作確認ではnamed volumeを使う方が分かりやすいと思います。

11. boto3からRustFSへ接続する

次にPythonからアクセスします。

Python仮想環境を作ります。

python3 -m venv .venv
source .venv/bin/activate

boto3をインストールします。

pip install boto3

scripts/test_s3.pyを作ります。

"""RustFSの基本的なS3操作を確認する。

Bucketを作成し、小さなObjectをアップロードしたあと、
ListObjectsV2で登録内容を確認する。
"""

from __future__ import annotations

import os

import boto3
from botocore.config import Config


ENDPOINT_URL = "http://localhost:9000"
REGION_NAME = "us-east-1"
BUCKET_NAME = "rustfs-test"
OBJECT_KEY = "sample/hello.txt"


def create_s3_client():
    """RustFSへ接続するS3クライアントを生成する。"""

    return boto3.client(
        "s3",
        endpoint_url=ENDPOINT_URL,
        aws_access_key_id=os.environ["RUSTFS_ACCESS_KEY"],
        aws_secret_access_key=os.environ["RUSTFS_SECRET_KEY"],
        region_name=REGION_NAME,
        config=Config(
            signature_version="s3v4",
            s3={
                "addressing_style": "path",
            },
        ),
    )


def ensure_bucket(s3) -> None:
    """テスト用Bucketが存在しなければ作成する。"""

    response = s3.list_buckets()

    bucket_names = {
        bucket["Name"]
        for bucket in response.get("Buckets", [])
    }

    if BUCKET_NAME not in bucket_names:
        s3.create_bucket(Bucket=BUCKET_NAME)


def upload_test_object(s3) -> None:
    """確認用のObjectをRustFSへ登録する。"""

    body = (
        "Hello RustFS\n"
        "This object was uploaded through boto3.\n"
    ).encode("utf-8")

    s3.put_object(
        Bucket=BUCKET_NAME,
        Key=OBJECT_KEY,
        Body=body,
        ContentType="text/plain; charset=utf-8",
    )


def list_objects(s3) -> None:
    """Bucket内に登録されているObjectを表示する。"""

    response = s3.list_objects_v2(
        Bucket=BUCKET_NAME,
    )

    for item in response.get("Contents", []):
        print(
            item["Key"],
            item["Size"],
        )


def main() -> None:
    """RustFSの基本的なS3操作を順番に確認する。"""

    s3 = create_s3_client()

    ensure_bucket(s3)
    upload_test_object(s3)
    list_objects(s3)


if __name__ == "__main__":
    main()

RustFSの公式boto3例でも、endpoint_urlをRustFSへ向け、path-style addressingを指定する方法が紹介されています。

.envを読み込んで実行します。

set -a
source .env
set +a

python scripts/test_s3.py

例えば、

sample/hello.txt 57

のように表示されれば、

Python
 ↓
boto3
 ↓
S3 API
 ↓
RustFS

という経路でObjectを保存できています。

12. アプリケーション側はRustFSへ直接依存させない

MinIOからRustFSへ切り替えるときに、ここはかなり重要だと思っています。

例えばアプリケーション側に、

s3 = boto3.client(
    "s3",
    endpoint_url="http://minio:9000",
)

と直接書いてしまうと、保存先を変更するたびにコードを直すことになります。

そのため、

S3_ENDPOINT=http://rustfs:9000
S3_ACCESS_KEY=...
S3_SECRET_KEY=...
S3_BUCKET=geospatial

のように環境変数へ切り出します。

Python側では、

s3 = boto3.client(
    "s3",
    endpoint_url=os.environ["S3_ENDPOINT"],
    aws_access_key_id=os.environ["S3_ACCESS_KEY"],
    aws_secret_access_key=os.environ["S3_SECRET_KEY"],
)

とします。

こうしておけば、

MinIO
RustFS
AWS S3
その他のS3互換Object Storage

への切り替えがしやすくなります。

重要なのはRustFSそのものではなく、S3 APIを境界にしてアプリケーションとStorageを分離することです。

13. MinIOのデータディレクトリをそのまま使わない

MinIOからRustFSへ移行する場合、

MinIOのデータディレクトリ
          ↓
RustFSから直接読む

という方法は、少なくとも最初の移行方法としては選ばない方が分かりやすいと思います。

まず、

             ┌─ MinIO
Application ─┤
             └─ RustFS

と両方を用意します。

その後、

MinIO
  │
  │ S3 API
  ↓
データコピー
  │
  ↓
RustFS

としてObject単位で移行します。

移行後は、単純なObject数だけでなく、

  • Bucket数
  • Object数
  • Object size
  • Metadata
  • Content-Type
  • Versioning
  • Lifecycle
  • Object Lock
  • Presigned URL
  • Multipart Upload

など、自分のシステムで利用している機能を確認します。

データファイルが同じ数だけ存在するから移行完了、とはしない方がよいでしょう。

14. 地理空間データの保存先として使う

自分がRustFSを試したい理由の一つが、地理空間データとの相性です。

例えば次のような構成を考えています。

20260922_m03.png

Bucketは用途ごとに分けます。

raw
processed
geoparquet
cog
pmtiles
simulation
archive

例えば、

s3://raw/jma/
s3://raw/dem/
s3://geoparquet/hazard/
s3://cog/dem/
s3://pmtiles/disaster/
s3://simulation/flood/

といった構成です。

Cloud Native GISでは、

COG
GeoParquet
PMTiles
Zarr
Parquet

のようにObject Storageと相性のよいデータ形式が増えています。

保存先をS3 APIへ統一しておけば、ローカルのRustFSから将来AWS S3などへ移行する場合も整理しやすくなります。

15. DuckDBと組み合わせる

RustFSはS3互換APIを提供するため、ParquetやGeoParquetをRustFSへ保存し、DuckDB側から読む構成も取りやすくなります。

Parquet / GeoParquet
        ↓
      RustFS
        ↓
       S3
        ↓
      DuckDB

例えば、

観測データ
    ↓
Parquet / GeoParquet
    ↓
RustFS
    ↓
DuckDB
    ↓
FastAPI
    ↓
Web GIS

という流れにできます。

大量のParquetを毎回ローカルへコピーしてから解析するのではなく、Object Storageを中心にデータを管理できるようになります。

16. 開発環境と本番環境は分けて考える

今回のDocker Composeは開発・検証用です。

1 Node
1 Volume

なので冗長性はありません。

本番環境では複数ノード構成を検討します。

20260922_m04.png

RustFS公式DockerドキュメントにもMulti-node deploymentの例があります。

なお、公式ドキュメントではDockerのデフォルトbridge networkはMulti-node deploymentには使わず、各ノード間通信にhost networkを利用する例が示されています。

本番投入前には、少なくとも次の項目を確認したいところです。

Node停止
Disk停止
Container停止
OS再起動
Network切断
Object大量登録
大容量Object
Multipart Upload
Backup
Restore
Upgrade
Healing

17. 監視はOpenTelemetryを中心に考える

RustFSではOpenTelemetryを使ったObservability構成が用意されています。

例えば、

RustFS
   ↓
OpenTelemetry Collector
   ├─ Prometheus
   ├─ Grafana
   └─ Jaeger

という構成です。

RustFSリポジトリのDocker Composeには、

  • Grafana
  • Prometheus
  • OpenTelemetry Collector
  • Jaeger

を組み合わせた構成も用意されています。

最初の検証ではすべて入れなくてもよいと思います。

まずは、

RustFS
 ↓
Health Check
 ↓
S3疎通確認

だけで始めます。

その後、本番運用を考える段階で監視を追加します。

18. MinIOから置き換える前に確認する流れ

自分なら、次の順番で確認します。

Step 1：RustFSを単一ノードで起動する

RustFS
Docker
Single Node

Step 2：基本的なS3 APIを確認する

PUT
GET
LIST
DELETE
Multipart Upload
Presigned URL

Step 3：実際のデータを保存する

GeoParquet
COG
PMTiles
Parquet
Zarr

Step 4：既存アプリケーションから接続する

FastAPI
DuckDB
Python
OpenLayers / MapLibre

Step 5：MinIOと並行して比較する

MinIO
  ├─ PUT
  ├─ GET
  ├─ CPU
  ├─ Memory
  └─ Disk I/O

RustFS
  ├─ PUT
  ├─ GET
  ├─ CPU
  ├─ Memory
  └─ Disk I/O

Step 6：障害試験を行う

Container停止
Disk障害
Node停止
Network障害
再起動
Healing

ここまで確認してから、本番でMinIOをRustFSへ置き換えるか判断します。

19. Rust製だから速い、とは決めつけない

RustFSという名前を見ると、

Rust
 ↓
高速

と考えたくなります。

ただ、Object Storageの性能は実装言語だけでは決まりません。

実際には、

NVMe / SSD
Network
Filesystem
CPU
Object Size
同時接続数
Erasure Coding
Cache
Multipart Size

などの影響を大きく受けます。

そのため、

Rustで書かれているからMinIOより速い

とは判断せず、自分のデータを使って測定します。

GIS系のデータでも、

小さいJSON × 数十万
GeoParquet × 数GB
COG × 数GB
PMTiles × 数GB

ではアクセス特性がかなり違います。

ベンチマークするときは、一つのObjectサイズだけでなく複数のパターンを用意した方がよさそうです。

20. 現時点での考え

2026年9月時点では、RustFSはMinIOの代替候補として試してみる価値があると考えています。

特に、

Apache License 2.0
S3互換
Docker対応
分散構成
Rust実装
AWS SDK利用可能

という組み合わせは使いやすそうです。

ただし、RustFS 1.0.0が正式リリースされたのは2026年9月16日です。

まだ正式版が出たばかりなので、

MinIOを停止
    ↓
すぐRustFSへ全面移行

という進め方はしません。

まず、

MinIO
  +
RustFS

を並べて確認します。

そしてアプリケーション側を、

Application
      │
      │ S3 API
      ↓
Object Storage

という構成にして、保存先を入れ替えられる状態にします。

この形なら将来、

RustFS
MinIO
AWS S3
その他のS3互換Object Storage

へ移る場合にも対応しやすくなります。

Object Storage製品そのものを中心にシステムを作るのではなく、S3 APIを境界としてシステムを分離しておくことが重要だと思います。

21. 実装一式を作成する

ここまで記事で説明した内容を、実際に動かせる形でまとめました。

配布ファイルは次のZIPです。

rustfs_minio_replacement_r001.zip

ダウンロード先：ZIPファイル

SHA-256は次の値です。

b2c8f90e27fe66fb55b53803471e88778de41ef5d71ca91d373930bd5e837aa3

構成は次のようにしています。

rustfs_minio_replacement_r001/
├── compose.yaml
├── Dockerfile
├── pyproject.toml
├── .env.example
├── .gitignore
├── README.md
├── VALIDATION.md
│
├── src/
│   └── rustfs_demo/
│       ├── __init__.py
│       ├── config.py
│       ├── client.py
│       ├── operations.py
│       ├── health.py
│       ├── migration.py
│       └── cli.py
│
├── scripts/
│   ├── generate_env.sh
│   ├── wait_for_rustfs.sh
│   ├── run_smoke.sh
│   └── validate_package.sh
│
├── tests/
│   ├── test_config.py
│   ├── test_health.py
│   ├── test_operations.py
│   └── test_migration.py
│
├── docs/
│   ├── MIGRATION.md
│   └── TESTING.md
│
└── samples/
    └── hello.txt

実装ではRustFS専用の設定値をアプリケーションへ直接埋め込まず、次のようなS3_*環境変数から接続先を読むようにしました。

S3_ENDPOINT=http://localhost:9000
S3_ACCESS_KEY=...
S3_SECRET_KEY=...
S3_REGION=us-east-1
S3_BUCKET=rustfs-demo

この形なら、保存先をRustFSからMinIOやAWS S3へ変更するときも、アプリケーション側の変更を小さくできます。

22. 実装で確認できること

r001では、S3互換Object Storageの基本操作を一通り確認できるようにしています。

Bucket確認・作成
      ↓
PUT
      ↓
GET
      ↓
LIST
      ↓
Presigned URL生成
      ↓
DELETE

CLIから個別に実行することもできます。

rustfs-demo health
rustfs-demo smoke

rustfs-demo put samples/hello.txt samples/hello.txt
rustfs-demo list --prefix samples/
rustfs-demo get samples/hello.txt downloads/hello.txt
rustfs-demo presign-get samples/hello.txt --expires 900
rustfs-demo delete samples/hello.txt

Object一覧ではListObjectsV2のpaginatorを使っているため、1,000件を超えるObjectも次ページを取得できる構成です。

大きなファイルは、すべてをメモリへ読み込まず、boto3のupload_fileとdownload_fileを利用します。

23. Dockerで動かす

ZIPを展開します。

unzip rustfs_minio_replacement_r001.zip
cd rustfs_minio_replacement_r001

最初に認証情報を作ります。

./scripts/generate_env.sh

.envが生成されます。

その後、RustFSを起動します。

docker compose up -d rustfs
docker compose ps

S3 APIとWeb Consoleは次のURLです。

S3 API
http://localhost:9000

Web Console
http://localhost:9001

RustFSが起動したら、smoke testを実行します。

./scripts/run_smoke.sh

このスクリプトでは、RustFSのHealth Checkを待ってから、Docker内のPythonツールからS3基本操作を順番に確認します。

RustFS起動
    ↓
/health確認
    ↓
Bucket作成
    ↓
PUT / GET / LIST
    ↓
Presigned URL生成
    ↓
DELETE

ホスト側へPython環境を作る場合は次のようにします。

python3 -m venv .venv
source .venv/bin/activate
pip install -e '.[dev]'

set -a
source .env
set +a

rustfs-demo health
rustfs-demo smoke

24. MinIOからRustFSへコピーする

今回の実装には、MinIOなど別のS3互換Object StorageからRustFSへObjectをコピーする機能も入れています。

MinIOのデータディレクトリをRustFSから直接読むのではなく、S3 API経由でコピーします。

MinIO
  │
  │ S3 API
  ↓
Migration Tool
  │
  │ S3 API
  ↓
RustFS

コピー元とコピー先は環境変数で分けます。

export SRC_S3_ENDPOINT=http://minio.example:9000
export SRC_S3_ACCESS_KEY=...
export SRC_S3_SECRET_KEY=...
export SRC_S3_REGION=us-east-1
export SRC_S3_BUCKET=source-bucket

export DST_S3_ENDPOINT=http://localhost:9000
export DST_S3_ACCESS_KEY=...
export DST_S3_SECRET_KEY=...
export DST_S3_REGION=us-east-1
export DST_S3_BUCKET=target-bucket

最初は実際にコピーせず、--dry-runで対象を確認します。

rustfs-demo migrate --dry-run

一部だけ試す場合は、--prefixと--limitを使います。

rustfs-demo migrate --prefix test/ --limit 10

コピー後はObjectのContentLengthを比較します。

ETagはMultipart Uploadの方法によって変わるため、異なるObject Storage間の完全一致判定には使っていません。重要なデータを移行するときは、別途SHA-256のmanifestを作り、コピー前後で比較する方法がよいと思います。

Versioning、Lifecycle、Object Lock、Bucket PolicyなどはObject本体とは別の設定なので、それぞれ個別に移行確認が必要です。

25. 配布前に確認した内容

今回の配布ZIPは、作成後にいったん別ディレクトリへ展開し、展開したファイルを使って再度テストしています。

確認結果は次のとおりです。

項目 結果
Python compileall PASS
pytest PASS（10 passed）
compose.yaml YAML解析 PASS
Shell bash -n PASS
CLI --help PASS
module / class / functionのdocstring検査 PASS
ZIP整合性検査 PASS

一方、今回の作業環境にはDocker Engineがないため、次の項目は未実行です。

項目 状態
Ruff NOT RUN
mypy NOT RUN
Docker ComposeによるRustFS起動 NOT RUN
RustFS v1.0.0実コンテナでのsmoke test NOT RUN

未実行の項目をPASS扱いにはしていません。

Ubuntu 24.04 + Docker Engine環境では、次の2つを実行して最終確認します。

python3 -m venv .venv
source .venv/bin/activate
pip install -e '.[dev]'
./scripts/validate_package.sh

./scripts/generate_env.sh
./scripts/run_smoke.sh

実行結果を残す場合は、配布物に入れているVALIDATION.mdへ追記しておくと後から確認しやすくなります。

26. ここまででできるようになったこと

今回のr001では、次のところまで実装しました。

Docker Compose
      ↓
RustFS v1.0.0
      ↓
S3 API
      ↓
Python / boto3
      ↓
PUT / GET / LIST / DELETE
      ↓
Presigned URL
      ↓
MinIO → RustFS 移行補助

これで、RustFSを単に起動するだけでなく、アプリケーションからS3互換Storageとして扱うための土台まで用意できました。

ここから先は、実際に扱うデータを載せて確認していきます。

RustFS
 ↓
GeoParquet
COG
PMTiles
 ↓
DuckDB
FastAPI
OpenLayers / MapLibre

その後、MinIOとRustFSを同じ条件で並べ、PUT/GET性能、CPU、メモリ、Disk I/O、大容量Object、大量小Object、再起動、障害復旧などを比較する予定です。

27. まとめ

RustFSは、S3互換APIを使えるため、MinIOの代替候補として比較しやすいObject Storageです。

ただし、RustFS 1.0.0はまだ新しいため、機能一覧だけで本番採用を決めるのではなく、自分の環境とデータで確認する必要があります。

今回の構成では、RustFSそのものへアプリケーションを強く依存させず、S3 APIを境界にしました。

Application
     │
     │ S3 API
     ↓
Object Storage

この境界を守っておけば、RustFS、MinIO、AWS S3などを比較しながら保存先を選べます。

まずは単一ノードのRustFSをDockerで動かし、S3基本操作と実データを確認するところから始めるのがよさそうです。

参考資料

2026年9月21日時点で確認した公式資料です。

RustFS

MinIO

仕様や対応状況は今後変わる可能性があります。本番導入前には、利用するバージョンの公式ドキュメントを改めて確認してください。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?