Garage：S3互換分散ストレージの全て - アーキテクチャから実践構築まで
Garage: The Complete Guide to S3-Compatible Distributed Storage
序論：セルフホスティング時代のオブジェクトストレージ
Amazon S3（Simple Storage Service）が2006年に登場して以来、オブジェクトストレージは現代インフラの中核コンポーネントとして定着しました。画像、動画、バックアップデータ、ログファイルなどの非構造化データの保存と管理において、S3 APIは事実上の標準（デファクトスタンダード）となり、数多くのアプリケーションやツールがS3互換インターフェースを標準でサポートしています。
しかし、パブリッククラウドへの依存はコストの急騰、データ主権の問題、ベンダーロックインという根本的な課題を伴います。そのため、オンプレミスまたは個人サーバーでS3互換ストレージを自ら運用するセルフホスティングの需要が着実に増加してきました。代表的な存在だったMinIOは高いパフォーマンスと簡便なデプロイで多くの支持を得ていましたが、AGPLv3＋商用デュアルライセンス体制に移行し、さらに最近ではGitHubリポジトリがメンテナンスモードに移行したことで、代替ソリューションへの関心が急速に高まっています。
このような背景で注目を集めているプロジェクトがGarageです。フランスの非営利団体Deuxfleursが開発したGarageは、「データセンター外でも安定して運用できるS3オブジェクトストア」を標榜し、小規模セルフホスティング環境に最適化された独自のアプローチを提示しています。本記事では、Garageのコア哲学、内部アーキテクチャ、インストール・運用ガイド、パフォーマンスチューニング、そして競合ソリューションとの比較まで、包括的に解説します。
1. Garageとは何か？
1.1 Garageの哲学と設計目標
Garageは2020年の初回リリース以降、Deuxfleursというフランスの小規模非営利ホスティングプロバイダーによって継続的に開発されてきたS3互換分散オブジェクトストレージです。Deuxfleursは実際にGarageを自社のプロダクション環境で使用しており、3つの物理的拠点に分散された9台のノードで構成されたマルチサイトクラスターを運用しています。
Garageの設計は4つの核心原則に基づいています：
- インターネット対応（Internet-enabled）：データセンター、オフィス、家庭など、一般的なインターネット接続（FTTHなど）で相互接続されたマルチサイト環境向けに設計されています。
- 自己完結的で軽量（Self-contained & Lightweight）：外部サービス（etcd、ZooKeeper、PostgreSQLなど）に依存せず、シングルバイナリでどこでも実行可能です。
- 高い復元力（Highly Resilient）：ネットワーク障害、ネットワーク遅延、ディスク障害、さらには管理者のミスに対しても高い復元力を保証します。
- シンプルさ（Simple）：理解しやすく、運用しやすく、デバッグしやすいシステムを目指しています。
特に注目すべきは、EU（欧州連合）の資金支援により2025年まで安定した開発資金を確保している点です。
1.2 コア機能の概要
Garageが提供する主要機能は以下のとおりです：
- S3互換API：GetObject、PutObject、DeleteObject、ListObjects、Multipart Uploadなどの主要S3操作をサポートします。ただし、オブジェクトバージョニングやオブジェクトロックなど一部の高度な機能はまだ未対応です。
- 地理分散レプリケーション：各ノードの物理的位置を認識し、データのレプリカを地理的に分散配置します。災害復旧（DR）シナリオで大きな利点となります。
- 静的Webサイトホスティング：別途のWebサーバーなしで、Garage自体がバケットの内容を静的Webサイトとしてサーブできます。この機能はMinIOやCephでは対応していないGarage独自の特徴です。
- Admin REST API：プログラマティックにクラスターを管理できる完全なREST APIを提供します。
- モニタリング対応：Prometheus形式のメトリクスとOpenTelemetry形式のトレースエクスポートをサポートします。
- K2V（実験的）：多数の小さなKey-Valueペアの保存と取得のための実験的API。
- Zstd圧縮およびデータ重複排除：保存されるすべてのデータに対してオプションでZstd圧縮を適用でき、同一データブロックは自動的に重複排除されます。
2. Garageアーキテクチャ深層分析
2.1 分散システムの理論的基盤
Garageのアーキテクチャは、分散システム分野の最新研究成果を積極的に活用しています：
- Amazon Dynamoパターン：高可用性Key-Valueストアの設計原則を採用。一部のノードに障害が発生しても、データの読み書きが継続可能です。
- CRDT（Conflict-Free Replicated Data Types）：複数のノードが同時にデータを変更しても、別途の調整なしに一貫した最終状態に収束するデータ構造を使用します。
- Maglevロードバランシング：Googleが開発したMaglevハッシュアルゴリズムを活用し、リクエストを効率的に分配します。
2.2 データレプリケーションと一貫性モデル
Garageは結果整合性（Eventual Consistency）モデルを採用しつつ、実用的に強力な保証を提供します：
- クォーラムベースの読み書き：
replication_factor = 3の場合、書き込みは3ノードに送信され、2ノードの応答確認で成功とし、3番目は非同期で完了します。 - 自動修復メカニズム：不整合が発生した場合、自動修復（repair）メカニズムが整合性を回復します。
- Tombstoneマーカー：分散環境での削除操作はTombstone（論理削除マーク）で処理し、「削除したデータが他ノードで復活する」問題を防止します。
2.3 ノード通信とクラスター管理
- Gossipプロトコル：中央コーディネーター（etcd、ZooKeeper等）なしで、ノード間のP2P通信でクラスター状態を共有します。単一障害点（SPOF）を排除します。
- Rustシングルバイナリ：全システムがRustで記述され、単一バイナリにコンパイルされます。Raspberry Pi級の低スペックハードウェアでも動作可能です。
- 異種ハードウェア対応：異なるスペックのマシンを混在させてクラスターを構成できます。各ノードの容量と物理的位置を考慮した最適なデータ配置計画を自動的に策定します。
3. Garageインストール・クラスター構築ガイド
3.1 前提条件
- ノード数：
replication_factor = 3使用時は最低3台のマシンが必要です。 - ネットワーク：各ノード間でIP通信が可能であること。NAT環境ではIPv6の使用を優先推奨します。
- VPNソリューション：NAT環境でIPv6が使用できない場合、Nebula、Yggdrasil、WireGuard等のメッシュVPNを構成できます。
- ストレージ：メタデータ用SSDとデータ用HDDを分離することがパフォーマンスに有利です。
3.2 インストール方法別ガイド
Dockerコンテナデプロイ：
# docker-compose.yml 例
version: '3'
services:
garage:
image: dxflrs/garage:v1.0
ports:
- "3900:3900" # S3 API
- "3901:3901" # RPC
- "3902:3902" # Admin API
- "3903:3903" # Web（静的サイト）
volumes:
- ./garage.toml:/etc/garage.toml
- ./meta:/var/lib/garage/meta
- ./data:/var/lib/garage/data
restart: unless-stoppedSystemdサービス登録：
[Unit]
Description=Garage S3-compatible object store
After=network-online.target
Wants=network-online.target
[Service]
Type=simple
ExecStart=/usr/local/bin/garage server
Environment=GARAGE_CONFIG_FILE=/etc/garage.toml
Restart=always
RestartSec=5
StateDirectory=garage
[Install]
WantedBy=multi-user.target3.3 設定ファイル（garage.toml）の主要項目
# メタデータ保存パス（SSD推奨）
metadata_dir = "/var/lib/garage/meta"
# データブロック保存パス（HDD可）
data_dir = "/var/lib/garage/data"
# データベースエンジン選択
db_engine = "lmdb"
# RPC通信設定
rpc_bind_addr = "[::]:3901"
rpc_public_addr = "192.168.1.10:3901"
rpc_secret = "ここに32バイトHEXシークレットを入力"
# レプリケーション設定
replication_factor = 3
# ブロックサイズ（デフォルト1MB）
block_size = 1048576
# S3 APIエンドポイント
[s3_api]
api_bind_addr = "[::]:3900"
s3_region = "garage"
root_domain = ".s3.garage.localhost"
# S3 Web（静的サイトホスティング）
[s3_web]
bind_addr = "[::]:3903"
root_domain = ".web.garage.localhost"
# Admin API
[admin]
api_bind_addr = "[::]:3902"
admin_token = "管理者トークン"
metrics_token = "メトリクストークン"設定ファイル作成後、クラスター構成はgarage CLIで行います：
# クラスター状態確認
garage status
# ノードにストレージ容量を割り当て
garage layout assign -z dc1 -c 100G -t node1 <node-id>
# レイアウト変更を適用
garage layout apply --version 1
# バケット作成
garage bucket create my-bucket
# アクセスキー作成
garage key create my-app-key
# キーにバケット権限を付与
garage bucket allow --read --write my-bucket --key my-app-key4. Garageチューニングと運用最適化
4.1 メタデータエンジンの選択
| エンジン | 特徴 | 推奨環境 |
|---|---|---|
| LMDB（デフォルト） | 最高性能、最も多くテスト済み。アーキテクチャ依存で32ビット非対応 | replication_factor >= 2のプロダクションクラスター |
| SQLite | 移植性良好、異常終了に強い。LMDBより低速 | シングルノードまたは異種アーキテクチャ環境 |
| Fjall（実験的） | LSMツリーベース、理論上高い書き込みスループット | テスト環境のみ（プロダクション使用禁止） |
4.2 パフォーマンスチューニング
- block_sizeの調整：デフォルト1MB。大容量ファイル中心の環境では値を増やしてチャンク数を削減できます。
- ライトバッファ：デフォルト256MiB。書き込み負荷が高い環境では値を増やしてスループットを改善できます。
- SSD/HDD分離戦略：メタデータ（
metadata_dir）はSSDに、データブロック（data_dir）はHDDに配置するのがコスパ最良の組み合わせです。 - ファイルシステム選択：メタデータストレージにはBTRFSまたはZFSを推奨します。
4.3 モニタリングとログ
- ログレベル：
RUST_LOG環境変数で制御。error、warn、info（デフォルト）、debug、traceが使用可能です。 - Prometheusメトリクス：Admin APIの
/metricsエンドポイントからPrometheus形式でメトリクスを収集できます。 - OpenTelemetryトレーシング：JaegerやZipkinと連携して性能ボトルネックを分析できます。
5. Garage vs 競合ソリューション比較
5.1 Garage vs MinIO
- リソース要件：GarageはRaspberry Piでも動作する超軽量設計。MinIOは中～高スペックのハードウェアが必要です。
- パフォーマンス：ロースループットベンチマークではMinIOが優勢ですが、Garageはリソース効率性で優れたコストパフォーマンスを提供します。
- 地理分散：Garageの最大の差別化要因です。MinIOでのマルチサイトデプロイは複雑なアーキテクチャ設計が必要ですが、Garageは標準機能として対応しています。
- ライセンス：両方ともAGPLv3ですが、MinIOは商用ライセンスを追加要求するデュアルライセンス体制に移行しました。
5.2 Garage vs Ceph RGW
- 複雑さ：CephはOSD、MON、MDS、CRUSHアルゴリズムなど多数のコンポーネントの理解が必要。Garageはシングルバイナリと1つの設定ファイルで構成可能です。
- ストレージ効率：Cephはイレイジャーコーディングをサポートし、レプリケーションより少ないオーバーヘッドでデータを保護できます。Garageは現在単純レプリケーションのみ対応です。
- マルチテナンシー：Ceph RGWは名前空間分離、リソースクォータなどエンタープライズ級の機能を提供。Garageはバケット別・キー別の権限管理というシンプルなモデルです。
5.3 比較まとめ表
| 項目 | Garage | MinIO | Ceph RGW |
|---|---|---|---|
| 開発言語 | Rust | Go | C++ |
| ライセンス | AGPLv3 | AGPLv3＋商用 | LGPL（完全OSS） |
| デプロイ複雑度 | 非常に低い | 低～中 | 高い |
| S3互換性 | コア機能中心 | 最も完全 | 広範囲 |
| イレイジャーコーディング | 非対応（3xレプリケーション） | 対応 | 対応（柔軟なK+M） |
| 地理分散 | コア機能 | 複雑な構成が必要 | 対応（複雑） |
| リソース要件 | 非常に低い | 中～高 | 高い |
| 静的サイトホスティング | 内蔵対応 | 非対応 | 非対応 |
| 最適な対象 | 小～中規模セルフホスティング | 高性能シングルクラスター | 大規模統合ストレージ |
6. 実践活用事例と統合
GarageはS3互換APIを提供するため、S3対応の大半のアプリケーションと自然に連携できます：
- Nextcloud外部ストレージ：Nextcloudの「External Storage」アプリを通じて、Garageをバックエンドとして接続できます。
- Mastodon/Misskeyメディアストレージ：ユーザーがアップロードする画像や動画をGarageに保存します。MastodonはS3互換ストレージ設定を標準で提供しているため、連携が簡単です。
- 静的Webサイトホスティング：Garage独自の機能で、NginxやApacheなしでバケットの内容をWebサイトとして直接サーブできます。Hugo、Jekyll、Astroなどの静的サイトジェネレーターのビルド結果のデプロイに便利です。
- Peertubeビデオストレージ：分散型ビデオホスティングプラットフォームPeertubeの動画ファイル保存先として活用できます。
- バックアップストレージ：rclone、restic、Duplicityなどのバックアップツールと連携して、リモートバックアップストレージとして活用できます。
- GitLab/Giteaアーティファクトストレージ：CI/CDパイプラインで生成されるビルドアーティファクトをGarageに保存できます。
結論：Garageを選ぶべきケース
Garageはすべての状況に適した万能ソリューションではありません。しかし、特定の条件下では他のどの代替手段よりも優れた選択肢となり得ます。Garageが最も力を発揮するのは次のようなシナリオです：小～中規模のセルフホスティング環境で運用の複雑さを最小化したい場合、複数の物理的拠点に分散した機器を一つのストレージクラスターにまとめたい場合、異種ハードウェア（中古PC、Raspberry Pi、NASなど）を活用したい場合、そして外部依存なしでシンプルかつ堅牢なオブジェクトストレージが必要な場合です。
一方、現時点でのGarageの限界も明確です。オブジェクトバージョニングはまだ非対応であり、イレイジャーコーディング非対応のため3xレプリケーション時のストレージ効率が低くなります。S3 APIの完全な実装ではないため、高度なS3機能に依存するワークフローでは互換性の問題が発生する可能性があります。
結論として、ストレージソリューションの選択は機能リストだけで判断すべきではありません。ワークロードの特性、障害モデル、運用上の制約を総合的に考慮する必要があります。大規模エンタープライズ統合ストレージが必要ならCephを、シングルクラスターで最大パフォーマンスが必要ならMinIOを、小規模セルフホスティング環境でシンプルかつ堅牢な地理分散ストレージが必要ならGarageを選択してください。