S3はファイルシステムではなく、ファイル保存技術

S3はファイルだが、ファイルシステムではない

• Amazon S3は2006年に登場した元祖クラウド技術で、「オブジェクトストレージ」と呼ばれるが、実際にはファイルのためのもの。
• S3を「Amazon Cloud Filesystem」だと考えるのは、人々にS3の採用を促すうえで有用な思い込みだが、実際のところS3はファイルシステムではない。

ファイルシステムとは何か、そしてモジュールの「深さ」

• UnixのファイルAPIは5つの基本関数で構成されており、ファイルの読み書きに必要なものをすべて提供する。
• これらの関数は、バッファリング、ページキャッシュ、断片化、権限、IOスケジューリングなど多くの問題を扱うが、それをユーザーに露出させない。
• 深いモジュールには、ユーザーが複雑さを意識せずに機能を利用できるという利点がある。

S3の特徴（これも深い）

• S3はUnixファイルシステムAPIを再実装しておらず、基本的な呼び出し方式が異なる。
• S3 APIはUnixのファイルAPIより単純だが、オブジェクトを部分的に上書きできないという制限がある。

ファイルシステムソフトウェア、特にデータベースはAmazon S3へ移行できない

• データベースはデータを保存する場所を必要とし、通常それはファイルシステム上のさまざまなファイルに保存される。
• データベースは部分的な上書き機能に大きく依存しており、これはS3では不可能。

S3が得意なことと苦手なこと

• S3の長所は、読み書きの帯域幅が非常に高いこと。
• しかしS3には部分的な上書き、名前変更、移動操作がなく、ファイル一覧の列挙も遅い。
• それにもかかわらずS3は保守の手間が少なく、バックアップ設定、レプリケーション、プロビジョニングなどの作業を簡素化する。

組織間におけるモジュールの深さの重要性

• S3が最初に人気を得たクラウドAPIになったのは驚くことではなく、組織間の複雑さを管理するうえで深いAPIが役立つ。
• SAPのような複雑な企業ソフトウェアを統合するのは苦痛な作業であり、それはSAPが深いモジュールではないからだ。

その他の情報

• この記事はS3が過大評価されていると主張したいのではなく、深いモジュールと比較的浅いモジュールという概念を説明している。
• 一部のデータベースはストレージとしてS3 APIを使うよう設計されており、それは可能だが透過的ではない。
• S3では多くのファイル形式がディスクより性能が劣る。

GN⁺の見解

• S3はファイルシステムの代替ではなく、特定のユースケースに最適化されたストレージソリューションであることを理解するのが重要。たとえば、大規模な不変ファイルの保存と転送には適しているが、データベースのように頻繁な部分更新を必要とするアプリケーションには向かない。
• S3の性能とスケーラビリティは非常に高いが、コスト効率と運用の複雑さを考えると、すべてのプロジェクトに適しているわけではない。たとえば、オープンソースプロジェクトのMinIOは、自前のインフラ上にS3互換ストレージを構築したい組織にとって良い代替案になり得る。
• S3を使う際には、データ整合性、ネットワークコスト、アクセス制御など追加の考慮事項があり、これらの要素はシステム全体の設計に影響を与えうる。
• S3のユースケースは限定的かもしれないが、データレイクやバックアップソリューションのような特定のアプリケーションでは非常に強力なツールである。データを安全に保存し、必要なときに素早く取り出せる能力は、多くのビジネスに重要な価値をもたらす。
• この記事は、S3の技術的な詳細と実際のユースケースへの深い理解を提供することで、技術的な意思決定に役立つ可能性がある。

[GN⁺]

Hacker Newsの意見

• S3 の耐久性に問題があるという話は聞いたことがないが、こうした主張が検証されたのを見たこともない。これらの主張については気になる。

  • S3 の耐久性は業界トップであり、従来のファイルシステムとは比較にならない。
  • AWS のアベイラビリティゾーン分離は、他のクラウドプロバイダーより優れている。
  • S3 はデータ完全性や自然災害への対策を非常に重視している。
  • S3 は「ビットロット」を検出できるほどの大規模運用が行われている。
  • 重要なデータは S3 以外の場所には保存しないだろう。
  • 出典: S3 バッチシステムを書いた人。

• ファイル一覧の列挙が遅い。S3 は読み書きは非常に速いが、ファイル一覧を列挙するのは非常に遅い。

  • S3 の高速な読み書きが有用なのではなく、ファイル一覧を列挙する機能が有用だ。
  • バージョニングされていないバケットでは、指定したプレフィックスの一覧取得は実質的に一定時間で可能だ。
  • データをさまざまな方法で分割でき、性能を心配せずに必要な識別子を使える。

• ファイル一覧の列挙が遅いことに最近驚いた。S3 でアセットを管理するためのスクリプト作業をしていて、ファイル一覧のキャッシュが必要だと気づいた。

  • ルートレベルのディレクトリが約 100,000 個あり、それぞれにいくつかのファイルを含むいくつかのディレクトリがある。
  • ファイルを再帰的に列挙するのに 15 分かかる。
  • なぜ Amazon がこの問題を解決していないのか気になる。

• Amazon S3 は元祖クラウド技術で、2006 年に公開された。当時は「オブジェクト」が流行しており、S3 は「オブジェクトストレージ」と呼ばれていた。

  • S3 はファイルシステムではなく、オブジェクトストレージだ。
  • S3 はファイルではなく、ファイルシステムでもない。
  • ファイル抽象化に期待されるのは可変性だ。
  • S3 は不変オブジェクトの可変なリストを提供する。
  • S3 は別の問題を解決するものであり、ファイルシステムのように見せようとする試みは顧客の誤解に由来する。

• Apache Arrow の object_store と Apache OpenDAL が提供する API を比較する議論がある。

  • Apache OpenDAL は、S3 を含む複数のクラウドストレージ向けに FS ライクな API を提供するライブラリだ。
  • GreptimeDB や Databend のようないくつかのデータベースシステムは、クラウドストレージ上のデータにアクセスするために OpenDAL を使っている。
  • Alluxio や JuiceFS のような他のソリューションも、S3 上でファイルシステムのようなインターフェースを管理している。

• ファイルシステムソフトウェア、特にデータベースは Amazon S3 に移植できない。

  • しかし移植できる。
  • INSERT/UPDATE/DELETE のたびに DB ファイル全体を上書きする必要はない。
  • SQLite の場合、S3 へのレプリケーションとリストアをサポートする Litestream のようなツールがある。

• Minio をローカルの「S3」として使い、データセットやモデルチェックポイントを保存している。

  • Minio には不要な機能がたくさんある。
  • CRUD ができて一覧も見られる、最小限の S3 ライクな「もの」として、現在ベストなセルフホスト・単一ノードの選択肢は何だろうか。

• S3 について話しているついでに、Backblaze B2 に触れる価値がある。

  • S3 より 3 倍安く、とても満足している。

• S3 はファイルシステムとして誤用されうる。

  • S3 はオブジェクトを前提としており、ここではクラスターと呼ばれる 512 または 4096 バイトのオブジェクトがある。