プログラマでありたい

おっさんになっても、プログラマでありつづけたい

s3fsの何が悪いのか?

 awsでシステムを組んでいると、一度は使ってみたくなるのがs3fsです。まずs3ですが、これはAmazonが誇るオンラインストレージです。容量の拡張も思いのままで、ほぼ無限の領域を使える夢のようなサービスです。一方で、現在のところAmazonのデフォルトのサービスでNASにあたるものは提供されていません。AWS上でシステムを組む上で、ここが制約になる場合があります。それであれば、s3をファイルシステムとして扱えば良いじゃないかというのが、s3fsプロジェクトです。
 コンセプトが解りやすく、上手くいけばAWSのサービスを保管する素晴らしいプロジェクトに思えます。しかし、実際のところ中々運用ベースで使うのが難しいのが、このs3fsです。理由としては、遅い・安定しないの2点に尽きます。何故なのでしょうか?s3fsのアプリとしての成熟度の問題でしょうか?ということで、アーキテクチャレベルで考えてみました。(単純化していて正確ではない部分もあり、突っ込みどころは多いと思います。)

一般的なファイルシステムの構造



 物理デバイス(ディスク)の上に、OSレイヤーが乗っかりアプリからファイルが扱えるようになっています。

S3の構造



 S3はオンラインストレージです。ファイルシステムではありません。OSレイヤーの上のアプリ層で、ストレージを扱えるようにしています。厳密にいうとS3は多重化されているので、この上のネットワークでユーザがどのファイルにアクセスするかが決定されます。

s3fsの構造



 s3fsは、オンラインストレージであるS3を束ねて仮想的にファイルシステムとして扱おうというアプリです。ネットワーク(インターネット)を挟んでいるのが解りますね。

 内部的な構造はみていませんが、S3をブロックストレージとして扱う為にキャッシュやバッファの仕組みを内包していると思います。一方でインターネット経由というところに根本的な不安定さの原因があるのではと思います。インターネットですから接続の不安定さもあり、またそもそもレイテンシが通常のファイルシステムより数百倍はあります。そこを解消する為の仕組みと解消しきれない部分が、アーキテクチャとしてのs3fsの問題だと思います。

まとめ



 上記のような理由でs3fsは、余りお勧めできません。一方で、特性を理解した上で選択的に使うのは良いと思います。個人的にはAmazonさん自身に、S3ベースのファイルシステムを出して貰うことを切に願います。ただし、アーキテクチャから考えれば、かなり難しいのではと思います。現状でのAmazonさんが出した解の1つは、StorageGateway on EC2なんでしょうね。


See Also:
Storage Gateway on EC2とオンプレミスのStorage Gatewayの構成について


参照:
s3fs