LocalStack代替！RustFSでローカルS3構築

最近、開発環境の維持にかかる保守運用のコストと手間について、チーム内で議論する機会がありました。特にローカル開発環境においてAWS S3のモックとしてデファクトスタンダードとなっていたLocalStackが、無料版であっても認証トークンを必須とする仕様変更を行ったことは、多くの現場で波紋を呼んでいます。新規開発者のオンボーディングや、自動化されたCI/CDパイプラインにおいて、外部サービスの認証情報を管理・設定する手間が増えることは、開発の生産性を静かに、しかし確実に削いでいく要因となります。このようなインフラモックツールの仕様変更に直面した際、私たちはアーキテクチャの依存関係を見直し、より軽量でメンテナンスフリーな代替手段を模索する必要があります。今回は、その有力な候補として注目を集めている「RustFS」をローカルS3環境として実務に導入する際の要点と、技術的な優位性について考察します。

LocalStack代替としてのRustFSの立ち位置と実務的価値

これまで、AWSリソースのローカルエミュレーションといえばLocalStack一択という時代が長く続きました。しかし、単純なオブジェクトストレージの読み書き（ファイルアップロードやダウンロード）のテストのみを行いたいプロジェクトにとって、巨大化・多機能化していくLocalStackは、オーバースペックでありリソースの無駄遣いになりつつありました。そこに認証トークンの必須化という制約が加わったことで、「単なるS3のモック」としての使い勝手は大きく低下したと言わざるを得ません。

代替案として真っ先に挙がるのはMinIOですが、現在MinIOはソースコードのみの配布に方針を転換しており、手軽にDockerコンテナとして立ち上げるには一手間を要するようになっています。インフラ構築の「一手間」は、チーム全体にスケールした際に大きな負債となります。

対して、Rust言語で記述されたRustFSは、非常に軽量でありながらS3互換のAPIを提供しています。Dockerイメージを引き、環境変数を数行設定するだけで、即座にS3互換ストレージと管理用コンソールが立ち上がるという圧倒的な「セットアップの容易さ」は、現代のアジャイルな開発現場において強力なメリットとなります。LaravelやGo、Node.jsなどのAWS SDK（S3クライアント）から、エンドポイントと認証情報を差し替えるだけで透過的にアクセスできるため、アプリケーションコードに変更を加える必要がない点も実務において高く評価できます。

導入にあたっての注意点とデメリット

一方で、実務導入においては「割り切り」も必要です。RustFSはあくまでシンプルなS3互換ストレージであり、LocalStackが提供するような、AWSの多岐にわたるサービス間の連携（例：S3のイベントをトリガーにしたLambdaの起動など）や、高度なIAMポリシー、複雑なライフサイクルルールの完全なエミュレーションには向いていません。

プロジェクトがS3の高度な機能に深く依存している場合や、AWSインフラ全体のIaC（Infrastructure as Code）のテストを行いたい場合は、ライセンスやトークンの管理コストを支払ってでもLocalStackの有償版を維持する方が安全です。RustFSは「ファイルの保存と取得」という、ストレージとしての基本機能にフォーカスしたプロジェクトに最適であると認識しておくべきです。

ローカルS3モックツールの比較

現在の主要なローカルS3代替ツールの特性を整理しました。プロジェクトの要件に合わせて適切なツールを選択する際の参考にしてください。

ツール名	セットアップの容易さ	認証・ライセンス制約	軽量性・リソース消費	実務での適性
LocalStack	中（Docker Composeで完結するが機能が多いため重い）	無料版でも認証トークンが必須化。CI環境での運用に工夫が必要。	重い（JVM等のオーバーヘッドあり）	AWS全体のエミュレーションや高度な機能連携が必要なプロジェクト。
MinIO	低（ソース配布中心となり、コンテナ化に自前ビルド等の手間がかかる傾向）	AGPL v3ライセンス。	中〜軽	本番環境でもMinIOを自社ホスティングして運用するケース。
RustFS	高（公式Dockerイメージで即時起動可能）	特になし（トークン不要でローカル完結）	非常に軽い（Rust製）	単純なS3ファイルアップロード/ダウンロードのモックが必要なプロジェクト。

実務での実装例（Docker Composeとアプリケーション設定）

RustFSをローカル開発環境に組み込むための最小限かつ実用的な compose.yml の例と、一般的なWebフレームワーク（例としてLaravel）から接続するための環境変数のマッピング例を示します。

# docker-compose.yml
services:
  s3-mock:
    image: rustfs/rustfs:latest
    container_name: local-rustfs
    ports:
      - "9000:9000" # API用ポート
      - "9001:9001" # 管理コンソール用ポート
    environment:
      - RUSTFS_ADDRESS=0.0.0.0:9000
      - RUSTFS_ACCESS_KEY=local-dev-key
      - RUSTFS_SECRET_KEY=local-dev-secret
      - RUSTFS_CONSOLE_ENABLE=true
    volumes:
      - rustfs-data:/data

volumes:
  rustfs-data:

上記のコンテナを立ち上げた後、アプリケーション側の環境変数（.env など）を以下のように設定することで、AWS SDKはRustFSをS3として認識し、正常に通信を行います。

# アプリケーション側の環境変数設定例（.env）
AWS_ACCESS_KEY_ID=local-dev-key
AWS_SECRET_ACCESS_KEY=local-dev-secret
AWS_DEFAULT_REGION=ap-northeast-1
AWS_BUCKET=my-local-bucket
AWS_USE_PATH_STYLE_ENDPOINT=true
AWS_ENDPOINT=http://localhost:9000

今後の展望とエンジニアへの提言

開発ツールやSaaSのライセンス体系、利用規約は常に変化します。昨日まで無料で当たり前のように使えていたインフラモックが、明日には開発のボトルネックになることは決して珍しくありません。シニアエンジニアに求められるのは、特定のツールに固執することではなく、「今解決すべき課題（今回はS3の基本的なモックアップ）に対して、最も運用コストが低く、チームの認知負荷を下げる技術は何か」を常に再評価し続ける姿勢です。

RustFSは、シンプルさとパフォーマンスという現代の開発環境に求められる要件を高いレベルで満たしています。もしあなたのチームが、LocalStackのトークン管理や起動の遅さに課題を感じているのであれば、機能要件を見極めた上で、RustFSへの移行を検討する価値は十分にあります。依存を適切に切り離し、軽く、柔軟な開発環境を維持することが、最終的なプロダクトの品質と開発スピードの向上に直結するのです。

参考記事: ローカル環境のS3をlocalstackからRustFSへ

Photo by Bernd 📷 Dittrich on Unsplash

LocalStack代替としてのRustFSの立ち位置と実務的価値

導入にあたっての注意点とデメリット

ローカルS3モックツールの比較

実務での実装例（Docker Composeとアプリケーション設定）

今後の展望とエンジニアへの提言

コメントする コメントをキャンセル

コメントするコメントをキャンセル