Amazon Elastic File System が GA ！

はじめに

AWSから EFS(Amazon Elastic File System)がついにGAされました。プレビューを申し込んでから1年以上が経過しているので、いろいろ課題をクリアしてのGAになったのだと思われます。
注意点としては、現時点で使えるリージョンに東京が含まれていない点になります。使えるのは、US East (Northern Virginia), US West (Oregon), Europe (Ireland) の3つとなっています。

東京リージョンへの展開が待ち遠しいですね。。。

ユースケース

AWSに限らず、クラウドでサーバに直接マウントできる共有ストレージはあまり例がありません¹。オンプレミスで共有ストレージを利用していたシステムをAWSへ移設する際の悩みどころの１つだったと思います。

従来の解決策としては、CDPのNFS Sharingパターンなどがありました。
NFS Sharingパターンのデメリットとしては、NFSの運用コストとNFSサーバのSPOFでした。そのため、GlusterFSやDRBDを導入して冗長化をする必要がありました。個人的な印象としては、クラスタソフトウェアの導入は深い知見がないと余計な障害ポイントが増える事になるため あまりお勧めはしていませんでした。これは高負荷が発生するWebシステムとクラスタソフトの相性が悪いなどの理由があります。

EFSでは、このNFS Sharing パターンを完全に置き換えるものとなっており、クラスタ化によるSPOFの排除、フルマネージド型による運用コストの大幅削減で 導入はメリットばかりだと思います。

EFSを使う上での注意点

本記事では、EFSのドキュメントを読んでいて注意が必要が必要そうな点をまとめてみました。
とはいえ、本番導入の際には実際に検証される事をお勧めします。

サポートリージョン

本記事の冒頭でも書きましたが、GA時点のサポートリージョンは US East (Northern Virginia), US West (Oregon), and Europe (Ireland) の3つのみです。但し、これは時間の問題なので 東京リージョンへの展開は時間が解決してくれるでしょう。

NFSv2,3の非サポート

NFS互換のEFSではありますが、NFSクライアントのv2,v3がサポートされていないため 古いシステムでは動作しない可能性があります。意外なのが、WindowsのNFSクライアントがv3までしかサポートされていない事による非サポートというところでしょうか。

2つのパフォーマンスモード

EFSでは２つのパフォーマンスモードが提供されており、用途によって使い分けをする必要があります。作成時のみにしか選択出来ないため、運用中に変更する場合は新しいファイルシステムを作成して、移行する必要があります。

General Purpose Performance Mode

デフォルトでは、General Purpose Performance Mode が選択されます。
Webサーバ、コンテンツ管理システム、ファイルサーバなどの一般的な用途であればこちらのモードを選択する事になりそうです。MAX I/O モードと比べたときに、レイテンシが優先されているみたいです。

CloudWatchの PercentIOLimit が100%に近い数値になっているようであれば、Max I/O モードへの移行が推奨されています。具体的には、秒間あたりに処理出来るファイル数が 7000 となっているため、これを超える可能性があるようであれば最初から Max I/O モードを選べばいいわけです。その他のパフォーマンスの差は実際に検証してみる必要がありそうです。

Max I/O Performance Mode

並列処理と高度なスループットを必要とするビッグデータ分析、メディア処理、ゲノム分析などのように大規模なEC2から接続される必要がある場合に最適なモード。
EFSを参照する全サーバの秒間あたりの処理ファイル数が 7000 を超えるかどうかが選ぶポイントになると思います。

料金

GAされている3つのリージョンでは、0.30 USD/GB-月 で価格設定がされています。
実際に請求される金額は、月あたりの利用量の平均サイズで決定されます。

1 か月に請求されるストレージの量は、月全体を通じて使用される平均ストレージ領域です。ストレージ使用量は「GB-月」を単位として測定され、その値を月末に合計してその月の請求額が計算されます。

たとえば、ご利用のファイルシステムが米国東部 (バージニア北部) リージョンに配置されており、3 月の 15 日間に 100 GB のストレージを使用し、3 月の残りの 16 日間に 250 GB のストレージを使用したとします。

3 月末の時点で、以下の「バイト-時間」で算出されます。

総使用量（GB-時間）= [100 GB x 15 日間 x （24 時間/日）] + [250 GB x 16 日間 x（24 時間/日）]

= 132,000 GB-時間
これを「GB-月」サイズに変換すると次のようになります。

総使用量（GB-月）= 132,000 GB-時間 x（1 か月/744 時間）

= 177 GB-月

ストレージの月額料金は、次のように計算します。

ストレージ月額料金 = 177 GB-月 x 0.30 USD = 53.10 USD

料金の例

クレジットについて

EBSと同様にクレジットとバーストが存在します。

EBSはクレジット不足になった場合、EBS拡張をすれば解消されました。しかし、EFSの容量は自動でスケールするため dd コマンド等でファイルを作成する必要がありそうです。一見手間がかかりそうですが、サービスダウンなしにクレジット不足を解消させる事が出来るのは、共有ストレージとしては大きなメリットだと思います。また、上手く活用すればクレジット不足を自動で解消させる事も出来そうですし、ベースラインを下回ったら作成したファイルを削除してコスト削減も出来そうです。

緩和申請可能な制限

EFSのリソース制限

クライアント(EC2 instance)の制限

Linux NFSv4.1 client利用時

EFS の制限

NFSv4の制約も含まれていますね。

その他の注意点

• サポートされているエンドポイントは、us-west-2のみ
• ClassicLinkを利用する事で、EC2-Classicのインスタンスからもマウント可能
• VPN、VPC Peering、Direct Connect からのマウントは非サポート

まとめ

待ちに待ったリリースなので、これから導入事例が一気に増えると思います。東京リージョンに来るまでに、パフォーマンス検証を是非ともやってみたいですね。