何回かに分けて FOBAS CSC Ver.3 の特徴のご紹介して行くシリーズの第６回目です。

今回は、AWSユーザにはお馴染みの s3fs と FOBAS CSC を比較してみたいと思います。

AWS S3 は言わずと知られたオブジェクトストレージであり、ファイルシステムとしては
そのままはマウント出来ません。それを可能にするオープンソースとして有名なのが
s3fs です。

今回、比較をまとめるためにネットをいろいろ検索してみたのですが、s3fs を使って
みたけどイマイチ的な記事やブログが多い事に驚きました。それらの記事やブログの多
くは、s3fs のアーキテクチャや特性を理解せずに、ファイルシステムという断面だけ
を捉えてあまり適さない 使い方をしているものが多いように感じます。

s3fs に限った話ではありませんが、ツールとしての正しい理解がされずに、そのポテ
ンシャルや価値が評価されないのはとても残念に感じます。今回はアーキテクチャを
正しく理解して、適材適所で使う一助になればとも思います。その意味でも s3fs の
ソースコードも軽くハックしてみましたのでそのご紹介も含めます。

FOBAS CSC の中核となっているのは、ファイルシステムである CSCFS3 です。s3fs と
比較するのであれば、むしろ CSCFS3 の方が適切かもしれません。両者、実は同じ
FUSE (Filesystem in Userspace) という仕組みを用いて実装されているファイルシス
テムです。また、データの格納先が S3 をはじめとするオブジェクトストレージという
点でも非常に良く似ています。

もちろん、相違点も多く存在します。それが適用場所の違いに関係してきますので、
まずは主要な違いについて取り上げて、その後にそれぞれに適した利用方法は何かに
ついてご紹介していきます。

相違点その１) オブジェクトストレージへのデータ入出力タイミング（方式）

ファイルシステムに書き込まれたデータをオブジェクトストレージ (AWS S3) に書込
む処理が、s3fs は同期処理で、CSCFS3 は非同期処理で行われているという違いがあ
ります。

s3fs では、ソースを見た限りは、write() システムコールレベルで同期処理をして
いる訳ではなく、ローカルファイルに書き込みをしており、close() 後に S3 に
curl ライブラリを使って PUT しているようです。いずれにしてもファイルの書き
込み完了と共に、S3 にオブジェクトを書き込んで応答します。

CSCFS3 では、ローカルキャッシュに書き込みが完了した時点で応答します。オブジ
ェクトストレージへの書き込みは、非同期で行われます。

同じように、データを読込む時も動きが異なります。

s3fs では、20MB 以下のファイルは必ず S3 からローカルの一時ファイルとしてダウ
ンロードした後に、その一時ファイルをオープンしてユーザに応答します。20MB以上
のファイルは、必要な部分を Multi Part GET してユーザに戻しているようです。

CSCFS3 では、要求されたファイルがキャッシュに存在するかを確認し、存在する場
合はキャッシュの内容を応答します。キャッシュに存在しない場合のみオブジェクト
ストレージからデータを読込みます。もう少し書くと、オブジェクトストレージから
並列処理でブロックデータを先読みし、ユーザにはストリーム処理で要求された内容
を応答しています。

相違点その２) オブジェクトの扱い

もうひとつの相違点は、s3fs ではオブジェクトをそのまま S3 に格納する点です。
言い換えるとファイルシステム上で見えているひとつのファイルは、S3 の上でもひ
とつのファイルです。これにはメリットとデメリットがあります。

メリットは分かりやすいと思います。s3fs を通して格納したオブジェクトは、ブラ
ウザとインターネット接続を使って直接 S3 にアクセスすれば、そのまま利用できま
す。S3 を World Wide の CMS エッジとして利用するのであれば、ファイルがそのま
ま格納できる事は必須要件です。

CSCFS3 はこれが出来ません。理由は後述するデメリットとも関係しますが、オブジ
ェクトストレージの特性を生かしながら、性能、信頼性、可用性、セキュリティなど
様々な機能を実現するためには、このオブジェクトの扱いを妥協する必要があったた
めです。

そういう意味では、s3fs と CSCFS3 は、競合するソリューションではなく、適材適

所で相互補完できるソリューションだと考えています。

さて、オブジェクトをそのまま扱う事に伴うデメリットについてです。ひとつは性能
です。ファイルシステムの構造をそのまま S3 上に構築するためには、ローカルで発
生したファイルシステムイベントをそのままの順序で S3 上に展開しなければなりま
せん。そうでないと論理矛盾がでてしまうからです。簡単な例を挙げれば、フォルダ
を作る処理の後にそのフォルダ内にファイルを作るという処理で、順序通りであれば
問題は発生しませんが、フォルダの無い場所にファイルを作ろうとすれば失敗します。
この事は処理の並列化が困難である事を意味しています。インターネットのようなレ
イテンシの大きなネットワークで処理を並列化できないと性能の影響は非常に大きな
ものとなります。

もうひとつのデメリットは少し難しい話になります。これにはオブジェクトストレー
ジのユニークな特性を理解する必要があります。厳密には、CAP定理だの BASEトラン
ザクションだのという話が関連するのですが、詳しい内容はここでは割愛します。
ご興味がある方は、CSCFS3 のホワイトペーパに多少記述しましたのでご覧ください。

簡単に言えば、オブジェクトストレージは一時的に整合性（一貫性）が取れない状態
が存在するという事です。これは、マルチユーザでの利用や、複数のサーバから同じ
バケットを NFS のように共有して使おうと考えると問題が発生します。シングルユ
ーザであっても、高い頻度でデータの読み書きを行うと、書き込んだはずのデータの
存在が一時的に確認できなかったり、削除したはずのデータが一時的に存在するとい
った問題が発生する可能性があります。

これはオブジェクトストレージの欠点ではなく、高い可用性や分断耐性、拡張性と
いった、従来のRAIDやファイルシステムでは達成できなかった特性のために部分的な
妥協をした結果です。

CSCFS3 では、オブジェクトストレージをオブジェクトを構成するデータブロックの
格納場所としてのみ利用し、上記のオブジェクトストレージの特性に影響を受けない
作りをしています。

相違点その３）その他もろもろ

これは先の2つと比較すれば些細な違いかもしれません。s3fs はファイルシステムと
しての以下の機能が微妙に違いますので利用する際には注意が必要です。

– link 機能が無い（シンボリックリンクは可能ですのである程度の代替は可能）
– ファイルシステムとしての属性取得API statfs() が使えない。
– 拡張属性が利用できない。(POSIX ACL などが使えない)
– ファイルシステムの時間精度は1秒
– NFS export できない。(FUSE Path レベルでの実装なのでちょいと問題あります）

どう使い分けるか

ここまでの説明で s3fs を正しく使うには、以下のような用途には向かない事が理解
いただけると思います。

– 高いI/O性能が求められる用途（細かいファイルの作成・削除は絶望的に遅い）
– 高い頻度で読み書きを行う用途
– マルチユーザでの共有（利用するフォルダ・ネームスペースを分ければ可）
– マルチサーバでの共有（利用するフォルダ・ネームスペースを分ければ可）

これは s3fs の特性というよりは、オブジェクトストレージそのものの特性であり、
s3fs が単に、オブジェクトストレージの API をファイルシステム用のシステムコ
ールでラッピングしたものであるが故の特性です。

多少主観も入りますが、s3fs は以下の用途であれば、低速ですが非常にコストパフ
ォーマンスの優れたソリューションになると思います。

– ログファイル、あるいはバックアップアーカイブの格納場所（サーバあるいはユー
ザ毎にフォルダを分けて格納する）
– S3 を CMSエッジとして利用する際の、マスタサーバからの公開用途

間違っても s3fs を NFS や CIFS の export ポイントとして使ってはいけません。

AWS のサービスであれば EFS（容量単価がかなり高価ですが・・・）のサービスが
始まっていますし、FOBAS CSC のようなストレージゲートウェイであれば、AWS内外
問わず共有ファイルシステムとしての快適な利用が可能です。

2TB を超える容量を使われるのであれば、FOBAS CSC のサブスクリプション費用や、
インスタンス費用を考慮しても、EFSより割安になります。

最後はちょっと宣伝も入ってしまいましたがご勘弁ください。
今日はこのあたりで。