#この記事について
Elastic File Syestemについてざっくり説明する営業資料記事的な感じ。
まだEFSを触ったこと無い人、調べてる途中の人、良さがわからんって人向けです。

「今からNFSインスタンスを構築するって？ならElastic File Systemを試してみない？」

#Elastic File Systemってなぁに
Amazon Web Services社が提供するフルマネージド型のファイルシステム。

・容量の心配無し(サイジング不要の従量課金)。
・メンテナンスの心配無し。
・EFSへのファイル伝送時は暗号化されてて高セキュア。

という、最強のファイルシステム。

EBSと比べると費用が3倍だったり、IOPS速度は汎用SSDと比べてちょっと遅かったり、
バックアップにはAmazon Backupの設定が必要だったりするけど、
そんなデメリット消し飛ばすくらいメリットや構成案の幅が増えるサービスである。

長年の課題だったAutoscaling時の先祖返り対策がこれ一発で解決した。
(今までは別途NFSインスタンス立てて、それのマネージドどうするねんとかサイジングどうするねんとかやらないといけなくて辛かった)

#そもそもファイルシステムってなによ
調べた中で一番分かりやすかったのは以下記事。

【ざっくり概要】Linuxファイルシステムの種類や作成方法まとめ！

その上で、さらに自分でまとめた図解が以下。
このファイルシステムは通常サーバー起動時に自動でマウントされているので、
普段は意識することが無い。
このファイルシステムが無いと、「ディレクトリどこ？」「ファイルどこ？」って状態になっちゃう。

その上で、Autoscalingの先祖返りっていうのがどういう状態かっていうと以下。
折角負荷分散でELBをかましているのに、その下のコンテンツが古いっていう状態。
それぞれのファイルシステムは各々のローカルホストEBSを見にいってる状態なので、
見る人によってコンテンツが新しかったり古かったりするのはとてもマズイ。

###そんな時の救世主がElastic File System

これであれば、見にいくディレクトリは1つだけになり、左右どちらのインスタンスでコンテンツを更新したとしても左右のインスタンスは同じものを返す。
インスタンスがいくつ増えようとも、いつ増えようともEFSにマウントさえしていれば先祖返りは発生しない。
勿論、fstabとかで起動時にマウントする設定とかが必要になってくるんだけど、そこは誰かの記事見て実際に作ってみて欲しい。

#まとめ
Elastic File Systemは可能性の塊のようなサービスなので、まだ触ったこと無い人、提案したことが無い人は是非とも触れてみて欲しいな。
ownCloudとかオンラインストレージをこれで構築できないか検討中。