はじめに
AWSで利用できるストレージにはいろいろな種類がありますが、
その中でも複数EC2からマウントして共有して使用できるEFSというストレージは、その特性柄非常に有名なものかと思います。
EFSにはクレジットがあり、保存されたファイルシステムによってスループットが変動します。
本稿では、EFSで設定できる内容やクレジットについて詳しく説明します。
Amazon EFSとは
まずはEFSの特徴について説明します。
EFSは、EC2用のフルマネージド型ファイルシステムです。
複数のEC2からNFSでマウントし、共有して使用することが可能です。
サーバレスでスケーラブル
ストレージ容量をあらかじめ設定する必要はなく、ファイルの追加・削除に応じて、自動的に拡張・縮小します。
コスト最適化
低頻度アクセスのクラスへファイルを自動移行させることが可能で、ストレージ費用はGiBあたり約90%ほど抑えられます。
ただしIAクラスに移行したファイルは、アクセス時に料金が発生します。
耐久性と可用性
EFSの高い耐久性と可用性も特徴のひとつです。
EFSの耐久性は99.999999999%（イレブンナイン）で、可用性は最大99.99%（フォーナイン）とされています。
EBSボリュームは99.999%の可用性を維持する設計となっており、耐久性は99.8～9%となっていますので、耐久性・可用性ともにEFSの方が高いことがわかります。
シンプルで簡単な設定
EFSは、作成から設定まで非常に簡単でシンプルです。
EFSの設定作業
EFSを作成する際の各設定についてみていきましょう。
EFSを作成するには、Amazon EFSマネジメントコンソールで「ファイルシステムの作成」をクリックし、ダイアログボックスを開いて各種設定値を入力します。
ストレージクラス
保存方法を、複数AZとする（標準）か、単一のAZのみとする（1ゾーン）を選択できます。
標準と比較すると1ゾーンへの保存は可用性が低下しますが、ストレージ料金はGBあたりかなり割安です。
詳細な設定について説明します。
パフォーマンスモード
汎用モードと最大I/Oモードがあります。
汎用モードは読み書きの遅延がもっとも少ないと言われており、推奨される設定です。どちらを選択したらよいか判断できない場合はまずは汎用モードを選びましょう。
最大I/Oモードは秒間あたりのIOが50万回可能で、汎用モードで最大3万5千回です。最大I/OモードはIOPSと引き換えに速度を失い、レイテンシーは高くなります。
スループットモード
バーストモードと拡張モードから伸縮自在モードまたはプロビジョンドモードの3つから選びます。
これまでスループットモードは、バーストモードとプロビジョンドモードの2つでしたが、2022年11月下旬ころより伸縮自在モードというモードが新しく使えるようになりました。詳細は後述します。
- バーストモード
バーストモードでは、スループットはバースト可能で、1TB以下の場合最大で秒間100MBpsまで可能です。
スループットが高い場合にはバーストクレジットを消費し、クレジットが0まで減った場合は1MBpsのスループットに制限されます。クレジットについての詳細は、後述します。
料金は保存されたファイルシステムの容量によって決まります。
拡張モードでは、伸縮自在モードと、プロビジョンドモードから選択します。
- 伸縮自在モード
このモードでは、必要なスループットをあらかじめ定義することなく、自動的にスループット性能を調節してくれます。アプリケーションで性能要件がはっきりしない場合や、スループットキャパシティを定義しにくい場合はこのモードを使用するとよいでしょう。
料金はファイルシステムの容量にかかるストレージ使用量と、EFSへの読み書きに対し従量課金制で発生します。
読み込み：0.04 USD/GB
書き込み：0.07 USD/GB
- プロビジョンドモード
プロビジョンドモードでは、固定のスループット値を設定します。
一定的なスループットで運用できるアプリケーションの場合はこちらを選択するとよいでしょう。
クレジットについて
バーストモードで運用する場合に注意すべきポイントがクレジットです。
ここでは、クレジットの概念を理解するために、スループット、ベースラインレート、クレジットの関係性を説明します。
スループット
一定時間内に処理されるデータ量を意味します。
ベースラインレート
EFSを使用する上で、スループットキャパシティはストレージに保存されたファイルシステムの容量によって決まります。一定時間当たり処理できるスループットをベースラインと呼びます。
ベースラインのレートは、ストレージ1TiBあたり50MiBps、1GiBあたり50KiBpsです。
ベースラインレートは次のように求められます。
ベースラインレート（KiB） = 50KiB × ファイルシステム容量（GiB）
ストレージ使用量が多くない場合に、ダミーデータを使用しデータ量を増やしてベースラインレートを増やす方法があります。
この方法により、プロビジョンドモードでスループットを固定で設定するよりも、その設定値をバーストモードのベースラインレートとして持つ方がEFSの利用料が安価になる場合があります。
ベースラインレートを基にした、ストレージで必要なデータ量は次のように求められます。
ダミーデータとして、現在のデータ量と下記式で求めたデータ量の差分を用意します。
データ量（GiB） = 必要なベースラインレート（KiB） / 50KiB
クレジット
クレジットは、EFS作成時にストレージ使用量1TiBあたり2.1TiB与えられます。
ベースラインレートを超えたスループットが発生した場合、不足分はクレジットから補い、ベースラインレートより少ない場合はその差分がクレジットに蓄積されます。
分かりやすく、クレジットを貯金、収入をベースラインレート、スループットを支出と考えてみましょう。
ある月に、収入より多く支出してしまったとします。足りない分は貯金から出さざるを得ません。
その翌月は、少ない支出で済んだとします。余ったお金は貯金に回すことができます。
お金を使いすぎる月が続くと貯金は減ってしまいますが、支出が収入を下回る限り貯金は増え続けます。
クレジットも同じ考え方で、平均してスループットがベースラインレートを下回るか同等の場合は、クレジットを減らさずに運用できます。
多少支出が多かろうと、2.1TiBの貯金を使い果たさなければ最大100MiBpsでバーストできる状態を維持できますが、ベースラインレートが小さい場合やベースラインレートとあまりにもかけ離れたスループットである場合は、モードの切り替えやベースラインレートの増加などさまざまな対策を検討する必要があります。
計測スループット
まず、EFSのクレジットに関係するスループットを列挙します。
- ファイル読み込み
- ファイル書き込み
- メタデータ読み込み
- メタデータ書き込み
EFSのクレジットを消費するスループットは、これらのデータ量を単純に合計した数値ではありません。
実際の計測スループットの計算方法では、ファイル、メタデータオペレーションのどちらも読み込みに関しては3分の1 *1に割り引かれます。
計測スループット = 〖 読み込みデータ量 / 3 〗＋ 〖 書き込みデータ量 〗
この値は、CloudWatchでEFSの『MeteredIOBytes』というメトリクスで確認できます。
EBSと比較する
汎用SSDのgp2にもクレジットはあります。スループットではなくIOPSで制御されています。
ベースラインIOPSは、33GiB以下では300IOPSで、3,000IOPSまでバースト可能です。I/O需要がベースラインパフォーマンスを上回ると、I/Oクレジットを消費します。
EFSの最大IOPSは35,000なので、EBSと比較するとかなり大きなIOPSを得られることが分かります。
それでは、EFSはEBSより優れていて、ストレージは今後EFS一択にすべきと考えてよいものでしょうか。
もちろんEBSにもいろいろな種類がありますし単純に比較できるものではありませんが、ここではEFSはEBSの代替となり得るのか、IOPSとスループットの観点から考えてみたいと思います。
EBSからEFSへ移行する際の注意点
EBSで運用していたアプリケーションのストレージをEFSへ移行することを検討している場合、IOPSやファイル読み書きのスループットを基準にEFSで運用できるかを判断するには、実は検討材料が足りません。
たとえば、とあるアプリケーションをホストするインスタンスでストレージにEBSを使用しているとします。このアプリケーションは、スループットが5MiBpsで、IOPSは300回以内で安定的に運用されています。
スループットやIOPSを見る限りは、ストレージのEFSへの変更はとくに問題なさそうですが、実はEFSには、EBSにはないメタデータI/Oのスループットがあります。ファイルの読み書き以外にこのメタデータI/Oもスループットに含まれるため、このメタデータI/Oがどれほど計測されるかあらかじめ確認しておく必要があります。
なぜなら、アプリケーションによってはメタデータI/OがファイルのI/Oに比べて100倍以上にもなる場合があるからです。
ファイルのI/Oは数MiBpsなのに、なぜメタデータI/Oがここまで膨れ上がるのでしょうか。
メタデータI/Oとは
メタデータI/Oは、ディレクトリ内のファイル一覧の取得や、ファイルのサイズ、タイムスタンプなどの情報の取得で発生するI/Oです。
EFSは複数のクライアントからの書き換えが可能というメリットを持っています。
しかし、EFS上のファイルアクセスの際、データがメモリキャッシュ上に存在した場合でもEFS上のファイルが他のクライアントから更新されてるかどうかを確認するため、メタデータオペレーションが発生してしまうのです。
メタデータI/Oのデータ量がどれほど計測されるかは実際にアプリケーションを動かしてみなければ分からないケースが多いと思います。
たとえば、PHP言語で構成されるCMSやフレームワークのようにひとつのリクエストで数百もの大量のファイルアクセスが発生するようなアプリケーションでは多くのメタデータオペレーションが発生します。
メタデータI/Oを減らすには
ファイルアクセスを減らす拡張機能を使用したり、CDNを有効的に使うのが良いでしょう。
PHPの拡張機能ではOPCacheが有名です。
当社の独自の調査では、OPCacheを導入することによって80%ものメタデータI/Oを削減できたケースもあります。
さいごに
複数インスタンスで共有できるEFSはメリットが注目されがちですが、当然その特性はしっかり理解した上で利用しましょう。
EBSと違ってクレジットの制御がスループットである点はとくに注意が必要で、EBSからEFSへの移行を検討している方は、実際にアプリケーションをEFSで動かし、ファイルI/OやメタデータI/Oをどの程度使用するのかしっかり確認した上で移行の是非を検討することが望ましいと思います。
*1:東京リージョンの場合
