AWSのストレージよもやま話 s3,ebsからStorage Gateway,EMRFSまで

　昨日、VPCの話を書いていて思い浮かんだのがストレージの話です。AWSのストレージといえば、S3とEBSが中心です。しかし、オンプレからの移行ではNAS相当のものがなくて、先人たちは色々と試行錯誤してきました。また、製品群を見返すとAWS自身も相当いろいろ検討して苦労したのだなと解ります。という訳で、何の役に立たないAWSのストレージの四方山話です。

s3fs

　事実上無限の容量を持つS3をファイルシステムとして扱えるs3fs。誰しも一度は夢をみて、夢敗れるファイルシステムではないでしょうか。これは純正のライブラリではなく、サードパーティ製です。構造としては下記の通りで、問題点としてはメタデータ（ファイル一覧や個々のファイルの日付・サイズ等の情報）を持たない点です。よって使い方によっては、かなり遅いです。また初期のものはメモリーリークとか多く、定期的な再起動が必要だったりします。

f:id:dkfj:20160426080823p:plain

みんな薄々と気が付いていると思いますが、s3fsが悪いのではないです。s3fsに夢を見過ぎた我々が悪いのです。

Storage Gateway

　最近では、EBS自体が16TBまで作れるので、EBS単体で大容量ファイルサーバの構築も簡単になっています。昔は1TBまでだったので、仮想ボリュームとして束ねたり、Storage Gatewayの利用を検討したものです。Storage Gatewayは、S3をストレージ・ボリュームとして扱えるもので、当初はオンプレからクラウドへバックアップする際に利用することが多かったです。Storage Gatewayは幾つかタイプがあって、Gateway-Cached Volumeは、EBS上にキャッシュがなければStorage Gateway経由でS3に取りに行くという構造になっています。そこに夢を見たのですよ。

f:id:dkfj:20160426080846p:plain

　個人的には、アーキテクチャとして中々良いのではと思っています。ただ1つ残念なのがというか、致命的だったのがメタ情報自体もStorage Gateway側（S3）に持っている為に、キャッシュに載っていなくて大量ファイルがあるようなディレクトリを参照した日には待てど暮らせど応答が返ってこないということになります。
　今だとEBSの容量が大きくなったので、Cached volumeではなくゲートウェイ保管型の方でも良いような気もしてきています。最近は、あまり触ることもなくなりましたが、地味に色々な所で活躍していると思います。

EMRFS（Elastic MapReduce FileSystem）

　EMRFSは、その名の通りEMR（Elastic MapReduce）用のファイル・システム。S3を束ねてファイルシステムとして利用できる。メタ情報は、S3ではなくDynamoDBに保存するのがポイントになっている。Consistent Viewとして整合性のあるビューを提供されます。

f:id:dkfj:20160426080850p:plain

　これをサービスとして出したらいいのじゃないのと思う人は多いでしょう。ただ、EMRで利用すること前提で、知名度低いです。

EFS（Elastic File System）

　AWSのNASタイプのファイルサービスとして鳴り物入りで登場したのがEFSです。恐らく全てのAWSユーザが待ち望んでいたサービスではないでしょうか。S3のように従量課金制で、容量も拡張型です。複数のインスタンスからマウントできます。

f:id:dkfj:20160426080840p:plain

　しかし、待てど暮らせど状態がプレビューから変わりません。また、アーキテクチャが全然公開されず実体は謎のままです。このサービスは我々の願望が生み出した夢で、現実には発表されていないのではとたまに疑っています。

まとめ

　ちょっと解説が大変なので省略しますが、これ以外にもRDS for Auroraで使われているQuorum型のストレージがあります。ストレージは設計の肝になることが多いので、よく考えてみましょう。個人的な結論としては、アプリを改修してS3ベースに出来るのが一番幸せです。なかなかそう出来ないのが、現実なんですよね。
　最近だしたAmazon Web Services クラウドネイティブ・アプリケーション開発技法には、EC2やEBSに頼らないシステムの構築方法を紹介しています。ぜひ御覧ください。