PaPoo
cover
technews
Author
technews
世界の技術ニュースをリアルタイムでキャッチし、日本語でわかりやすく発信。AI・半導体・スタートアップから規制動向まで、グローバルテックシーンの「今」をお届けします。

「とにかくシンプルなS3が欲しい」——現場目線で選んだS3バックエンド探し

記事のキーポイント

まず、この記事は何の話なのか

この記事は、ひと言でいうと「S3っぽいものをローカルで使いたいんだけど、でかすぎる仕組みはいらないんだよね」という話です。

S3は、Amazonが提供する有名なオブジェクトストレージです。
オブジェクトストレージというのは、ふつうのフォルダ管理というより「ファイルをひとまとまりのデータとして預ける倉庫」みたいなものだと思うとわかりやすいです。クラウド時代ではかなり定番ですが、ローカル環境や自前サーバーでも「S3互換」があると便利です。

ただし、S3互換の実装は思ったよりいろいろあります。
そして筆者はその中で、「そんなに大規模じゃない。複雑な分散も要らない。とにかく普通に使えて速いものがいい」と、かなりはっきりした好みを持っています。ここがまず面白いです。
技術記事なのに、単なる機能比較ではなく、かなり“使う人の体温”があるんですよね。

筆者の条件はかなりシンプル

筆者の要求は、かなり明快です。

これ、地味に重要です。
世の中には「全部入り」のストレージ製品が山ほどありますが、実際にはそこまでの機能を必要としない人も多いです。むしろ機能が増えるほど、構成は複雑になり、運用は重くなり、トラブル時の切り分けも難しくなります。

筆者はまさにその「余計なものはいらない派」なんですね。個人的にはこの姿勢、すごく共感できます。
実運用では、機能の多さより「今日も素直に動く」ほうがずっと価値があることが多いからです。

MinIOはなぜ見限られたのか

まず名前が挙がるのは MinIO です。
MinIOは、S3互換ストレージとしてかなり有名です。使ったことがある人も多いはずです。

しかし筆者はかなり辛辣です。
要約すると、

という感じです。

ここはかなり個人的な体験談が強く出ています。
技術選定って、ベンチマークだけでは決まらないんですよね。
「このプロジェクト、信用して大丈夫か?」という感覚は、実際かなり大きい。筆者はその信頼感を失ったので、MinIOを候補から外した、ということだと思います。

Garageは興味深いけど、まだ重い

次に出てくるのが Garage です。
Rustで書かれていて、新しくて面白いプロジェクトのようです。

ただ、筆者の評価は「まだ重い」。

という理由で、好印象はあるけれど採用には至りませんでした。

ここで大事なのは、筆者がGarageを単に否定しているわけではないことです。
「あと少しでいい感じになりそうだけど、今の自分の用途にはまだ重い」と見ています。
この温度感、すごく実践的です。新しいOSSって、期待はできても「今ここで使うか」は別問題なんですよね。

SeaweedFSは面白い。でも遅い

SeaweedFS は筆者がかなり興味を持っているようです。
設計思想も好きだし、いろんな層を積み重ねて WebDAV に対応するような拡張も面白い、と評価しています。

ただし、肝心の速度で不満があります。

これはかなり痛いです。
ローカルLANでのダウンロードって、本来は「ほぼ一瞬」であってほしいんですよね。なのにモタモタする。これは精神衛生に悪い。筆者が「Why isn't it instant?」とぼやく気持ち、よくわかります。

後の更新では、SeaweedFSの開発者と話した結果、
VNET jails、FreeBSDのオプションの RACK TCP/IP stack、LANアクセスの組み合わせが、遅さの原因だった可能性があるとわかったそうです。

ここは面白いポイントです。
つまりSeaweedFS自体が絶対に遅いと決まったわけではなく、​環境との相性問題だったかもしれない。技術の世界では、こういう「ソフトそのものより、周辺条件が悪さをする」ケースは本当に多いです。
とはいえ、使う側からすると「原因が何であれ、今遅い」のが問題。そこもまた現実です。

CEPHは強いけど、重すぎる

CEPH については、筆者は「怪物」と呼んでいます。
これはかなりしっくりくる表現です。

CEPHは大規模な分散ストレージとして非常に強力ですが、当然ながら複雑です。
筆者の用途では「そこまでいらない」。でも、もしAmazon S3に本気で対抗するようなものを作るなら、CEPHみたいな大物が必要になるだろう、という見方です。

つまり、

この距離感はとてもまともです。
「すごい」のと「自分に合う」は別、ということです。

そして Versity S3 Gateway に着地する

最終的に筆者が採用したのが Versity S3 Gateway です。
これが今回の記事のいちばんの落としどころです。

筆者が評価しているポイントはかなりはっきりしています。

筆者は rclone でデータを流し込み、テストした結果、期待通りの高速さを得られたそうです。
そしてついに「sanity is restored」——正気が戻った、と言っています。
この一言が最高です。遅いストレージに苦しんだ人の、心からの安堵が伝わってきます。

個人的には、この記事の核心はここだと思います。
S3互換の世界って、やたら高機能・高分散・高思想なものが目立ちがちですが、実際には「ローカルファイルをちゃんと速く扱えればそれでいい」というニーズもかなりあるはずです。
Versityはまさにその需要に刺さったわけですね。

ほかの候補もいくつかある

記事の後半では、採用後に知った“後発候補”も紹介されています。ここも見ていて楽しい部分です。

RustFS

Rustで書かれた新しい候補です。
特徴としては、

筆者はまだ評価していませんが、

ただし同時に、ディスクやfilesystemをそのまま与えて、複数ディスクに分散したり壊れたディスクを修復したりできるのは面白い、とも述べています。
これはかなり実用寄りで、好感が持てます。

rclone の S3 server

rclone は本来、各種ストレージ間でファイルを同期・コピーするツールです。
そのrcloneにも S3 server として振る舞う機能があります。

ただ、筆者は「本業ではない機能に依存するのはちょっと不安」と見ています。
これはわりと真っ当な感覚です。
便利機能は便利ですが、長期運用では「それを主目的に作られた製品か?」が効いてきます。

filestash

filestash は、いろんなストレージプロトコルに対応するDropbox風のファイルマネージャーです。
FTP、SFTP、S3、SMB、WebDAV、IPFSなど、かなり幅広い対応をうたっています。

筆者は「あとで調べたい」としています。
こういう万能系は、ハマると便利だけど、今回の「S3だけ欲しい」には少し広すぎるかもしれません。

Zenko CloudServer

Zenko CloudServer は NodeJS 製。
筆者のコメントはかなりユーモラスで、「single threaded event loop を楽しんで」といったニュアンスです。

要するに、NodeJSでストレージをやるのは悪くないけれど、性能面や設計面で少し不安がある、という感触でしょう。
これも意見としてはかなり理解できます。

Supabase Storage

Supabase Storage も NodeJS 製で、メタデータはPostgresに保存する構成です。
認可は Postgres の Row Level Security で制御するとのこと。

これは思想としてはかなり面白いです。
ストレージの制御をDBに寄せるのは、設計として筋が通っています。
ただし筆者は今回の用途では深追いしていません。

記事全体を読んで感じること

この文章、単なる「製品レビュー」ではないんです。
むしろ “自分にとってちょうどいい道具はどれか” を、かなり率直に探した記録 だと思います。

そしてその中で一貫しているのは、

この3つです。

個人的には、ここがすごく大事だと思います。
技術の世界はどうしても「より大きく、より新しく、より多機能」に引っ張られがちです。
でも現実には、​**“シンプルで速い” が最強**という場面はかなり多い。この記事はその現実感を、かなり気持ちよく思い出させてくれます。

しかも筆者は、単に文句を言っているのではなく、実際に試して、遅さを体感して、別案を探して、最終的に納得できるものに落ち着いています。
こういう選び方は、派手じゃないけど信頼できます。
そして何より、読んでいて「わかる、その気持ち」となりやすい。技術記事としてかなり良い味が出ています。


参考: I Just Want Simple S3

同じ著者の記事