EFS で NFS サーバを運用する際にいくつかの気づきがあったのでまとめてみました。
Amazon Elastic File System (EFS) とは
今更ですが EFS の特徴についてまとめてみたいと思います。
フルマネージドな NFS サーバ
EFS は AWS が提供しているフルマネージドの NFS サーバです。フルマネージドなので新しく OS をインストールしたり、ストレージシステムを構築したりすることなしにわずか数クリックで利用可能になります。
NFS に限らずファイルサーバは SPOF になりやすいので、普通に構築する場合はストレージの冗長化やサーバのクラスタリング等、可用性を高めようとすると非常に複雑な設計構築を行わなければいけません。こうした複雑さ無しにすぐに利用を始めることができます。
事前に容量を設定する必要がない
EFS の最も重要な特徴の一つは、事前に決まった量の容量を確保する必要がなく、実際に利用された容量に対して課金されることです。NFS に限らずストレージシステムで一般的な設計課題として、サイジングは非常悩ましい問題の一つです。
現在マニュアルを確認した限りでは、ファイルシステムとして具体的な上限は定められてなく事実上無制限と考えてよさそうです。ただし使用容量に対して課金されるので、先に予算的な制約に到達するほうが早そうです。料金に関して注意しなければいけないのは、月内の平均使用量に対して課金されることです。月末に慌ててファイルを削除しても利用料金はそれほど変わりません。
高可用性および高耐久性
NFS サーバを構築する際に最も難易度が高いのが可用性と耐久性の確保です。EFS はマネージドサービスでこの点に関してもストレージの冗長化及び、単一システム障害が発生してもサービスが継続されるようになっております。
ただし、ほぼ無いといえるほど非常に確率が低いとは思いますが、サービスダウンの可能性もゼロではないので、費用が許すならば複数リージョンへの災対環境の構築などを考慮することになります。
EFS を利用するにあたって注意したいこと
このように、非常に便利な特徴をもった EFS ですが実際の利用にあたってはいくつか注意しなければいけないことがあります。以下に取り上げられる範囲で記載したいと思います。
レイテンシの影響
ファイルアクセスに際してレイテンシは低くなるように設計されていますが、EBS 等のローカルストレージよりは大きくなります。
そのため例えば単一プロセスで複数の小さなファイルを連続して書き込むような場合は、レイテンシの影響を受けやすくなります。少し書いて、待って、少し書いて、待ってを繰り返すため待ち時間が発生するためです。
対処としては、単一のファイルにまとめて書く、複数のスレッドやインスタンスに書き込み処理を分散させるなどが考えられます。多重度が増える分には EFS はスケールするように設計されているので、レイテンシの影響を減らすことができます。
単一ファイルへの多重アクセス
EFS に限らず NFS 全般に言えることですが、単一ファイルへの複数プロセス、インスタンスからのアクセスは避けたほうが良いです。例えば以下のような弊害が考えられます。
- 排他制御待ちによりそれぞれのアクセスがシリアライズされてアクセス待ちが発生
- 不十分な排他制御によるデータ破壊
対処としては、各プロセス、インスタンス単位で個別のファイルにアクセスするように設計することです。もし各ファイルの内容を集約する必要がある場合は、一旦個別のファイルに書いた後で、呼び出し時にファイルをイテレーションして集約するようなコーディングにする必要があります。
OS のデフォルト設定を利用する
OS のデフォルト設定は多くのユースケースを考慮し、中立的な値が設定されています。そのため多くの場合は変更なしで問題なく利用できます。しかし EFS の特徴を生かすためには、いくつかのパラメータを考慮する必要があります。
EFS のマニュアル1 には以下のパラメータの仕様が推奨されています。
- rsize=1048576,wsize=1048576
- 上記レイテンシの影響を軽減するためにできるだけ大きいサイズでの書き込みが推奨されます。そのため一回の書き込み、読み出しバイト数を増加させています。
- hard
- 通常の NFS サーバとは異なり、EFS では自動復旧することが期待されます。そのため hard オプションで無期限に再試行するように設定します。
- timeo=600
- 待ち時間を長くします。これも EFS 内で何らかの遅延が発生した場合でもリカバリを待つことができます。
- retrans=2
- 再試行回数を2回に設定します。
- noresvport
- ネットワーク接続が再確立した際に新しい TCP 送信元ポートを利用します。ネットワークに障害が発生した場合でも、復旧後継続してファイル操作がかの運です。
- _netdev
- 起動時にマウントするときにネットワークが有効になってからマウントすることを支持しています
最後に
EFS に限らない話ですが、ご利用にあたってはご自身のユースケース、SLO に適合するかどうかを必ず事前に PoC を実施しテストしましょう。 PoC レベルであればそれほど費用は掛からないと思います。
その際に必ず、想定されるプロダクション環境と同程度の負荷、ファイル容量、ファイル数等で実施することが推奨されます。
また利用開始後もファイルアクセスのレイテンシやスループットを観測し、SLO に適合しているかどうかの見直しをする必要があるでしょう。
