年三日坊主のKKです。
たまにはお坊さんらしく4月8日の「花まつり（灌仏会）」に絡めて、暦（こよみ）や時間の定義の話を書くつもりだったのですが、「月の標準時「LTC」を策定」というニュースが飛び込んできて話がまとまらなかったので、また今度書きます。
AWSにはフルマネージドなNFS（ネットワークファイルシステム）として、EFS（Amazon Elastic File System）が存在します。
AWSコンソール上からVPC内にデプロイするだけで利用可能なネットワーク共有ファイルシステムで、ほぼ容量無制限で使った分だけ支払えばよいという良い感じのサービスです。
当社ではAutoscaling構成にしたEC2で同期が必要なコンテンツなどをEC2にマウントしたEFSに配置することでコンテンツ同期の手間を省いたり、EC2インスタンスのOS更改を容易に行えるようにするなど、何かと便利に利用しています。
さて、このEFSですがネットワーク越しにマウントするファイルシステムということで、しばしば性能問題にぶつかります。
エンジニアブログでも「AWSのElasticFileSystemの速度について」として取り上げられています。
最近では伸縮自在モードなど速度面の懸念に対応した転送モードが追加されたりしていますが、コスト的にはバーストモードが一番お得ですので、一般的にはバーストモードでご利用の方が多いのではないでしょうか。
しかしながら、特にEFS上に保管するデータ容量が少なく、一方でデータの読み書きが多いシステムの場合、保存データ容量に応じて補充されるバーストクレジットの消費が補充より多くなりバーストクレジットを枯渇させて、転送速度が異常に遅い状態に陥る事例がしばしば発生します。
当社ではEFSバーストクレジットの残量を監視して、閾値を下回った場合はバーストクレジット回復処置を実施するなど、出来るだけ快適にEFSをご利用頂けるよう運用面での工夫をしています。
ところが先日、月に1回程度EFSバーストクレジット回復処置を実施してきたお客様で、3週連続でバーストクレジットの残量枯渇が発生しました。
しかし、「DataReadIOBytes」や「DataWriteIOBytes」などEFSとのデータの読み書きに関するメトリック値は依然と大きくは変わっていませんし、お客様側でアプリの改修などを実施されたわけでもない、、、変更点と言えば利用の終わったバーチャルドメイン設定とEFS上に配置したドキュメントルートを削除したくらいです。
2週間後、EFSバーストクレジットは減少するどころか徐々に残量を回復し、ほとんど毎日減った分が毎日補充されるような状況になっており、我々は頭を抱えます（どうしてこうなった？？）。
そこでお客様に何か実施されたのか確認したところ、「利用終了したバーチャルドメインに設定したcron設定を削除した」とのこと。
つまり、既に削除して存在しないバーチャルドメインのドキュメントルート配下に格納されたスクリプトなどがcronで毎分起動されていたようなのです。
バーストクレジットを考える時、実際にファイルが読み書きされるスループットに注目しがちですが、実はファイルそのものの読み書きの発生しない処理であってもディレクトリ内のファイル一覧の取得やファイルのサイズ、属性、存在確認などファイルシステムに対するメタデータの読み書きについてもバーストクレジットが消費されます。
参考：EFS ファイルシステムのパフォーマンスが遅いのはなぜですか?
とはいえ、EFSボリューム上の存在しないパスを叩いただけで、本当にバーストクレジットが枯渇するのでしょうか。
気になったので実験してみました。
- まず、バーストモードでEFSをデプロイします。
- 次に、EC2インスタンスにEFSをNFSマウントします。
- EC2インスタンス上からマウントしたEFSのパス配下の出鱈目なディレクトリパスの存在しないシェルスクリプトなどをcronで定期的に起動させる設定をします。
基本的には上記の通りで再現できました。
ただし、2点注意点があります。
- EC2インスタンスはネットワークパフォーマンスが低いインスタンスタイプの方が再現しやすい。
- EFS配下の出鱈目なパスを叩く処理は無限ループなどで大量アクセスを発生させないと消費したバーストクレジットがすぐ回復されてしまいます。
具体的には /mnt/efs にEFSをNFSマウントした上で、以下のようなシェルスクリプトを作成し、引数にループ回数を指定してcrontabに登録することで恒常的にEFSに対してメタデータを参照する状況を作り出しました。
#!/usr/bin/bashfor i in `seq 1 $1`do /mnt/efs/future-tmp/efs-test.sh 2> /dev/null &done |
実際には消費したそばからバーストクレジットがどんどん回復するので、EC2インスタンスを3台使ってなんとか 消費 ＞ 回復 の状況を再現することが出来ましたが、やはりこのような状況はかなりイレギュラーで普通に使っている分にはバーストモードで十分だな、というのが一番の感想です。
一方で物理マシンのSSDやHDDなどの直結物理ストレージや、EBSのgp3モードなどスループットが変動しないストレージ環境で開発されたシステムでは原理的に今回のようなバーストクレジットの枯渇によるスループット低下は起きえないため「開発環境では問題無かったのに本番環境でだけパフォーマンスが出ない」という現象の原因になりがちです。
実は他案件でgp2のEBSでもバーストクレジットの枯渇で性能劣化する事象に遭遇しており、「存在しないパスを叩くことがあっても標準エラー出力を/dev/nullに捨てれば実害無かろう」という発想をしがちな拙僧にとってはドキリとさせられた事例でした。
EFSはかつてに比べてパフォーマンスが大きく向上しており、伸縮自在モードなどバーストクレジットの枯渇を気にせず利用できる方法も拡充されて使い勝手はどんどん良くなっています。
しかしながら、バーストモードでお得に利用しようとすると今でもバーストクレジットの性質を理解して利用しないと落とし穴があるということを再認識しました。
EFSバーストクレジットの理解の助けになれば幸いです。
なお、表示される内容は利用状況やAWSの仕様変更ににより変化しますのでご注意ください。
◆参考
