本記事は EFS使ってみた ~ EBSとEFSの書き込み速度を比較編 ~ の続きです。

続き

2.1TBのバーストクレジットを使い切ってしまいました。 1GBしか入っていないからかもしれませんが、グラフを見ると1日あたり4GBしか回復しないようです・・・ ということは枯渇したバーストクレジットが最大まで回復するには525日かかることになります。 使い切ったら新しく作り直すしか（白目

というわけで今回は読み込み編です。

[read]Webサーバーを動かして中のファイルを返す

1.　Webサーバーからローカルのファイルを返却させます 2.　curl的なものでリクエストを投げて返却されるまでのタイムを計ります 3.　64B、64KiB(64 * 1024)、64MiB(64 * 1024 * 1024)あたりのファイルを返却します

まず64Bのファイルの取得から。単位はμ秒です。

EBSはだいたい2～8ミリ秒前後で若干ノイジーです。 EFSは5ミリ秒強で若干パフォーマンスは低めに見えます。

1KBくらいのファイルです。 このくらいのサイズではあまり変わりませんね。 EFSは64Bのときより若干速いように見えるんですが気のせいでしょうか・・・

1MBくらいのファイルです。 どちらも200～350ミリ秒のレンジで変わりません。 おそらく、大きいファイルのストリーミングではネットワーク帯域がボトルネックとなりファイルアクセスの速度が通信速度を超えるからだと思われます。

寸評

uriを元にローカルのファイルを返すというめちゃくちゃなWebサーバーをつくりましたが、なかなかいい具合にレスポンスを取れました。 APIのモックなどにいいかなと思いました。

[read] 並行参照したときに劣化あるかないのか

一個前のテストを複数起動して劣化具合を調べます。 小さいファイルだと一瞬で終わってしまうため、1MBのやつを起動します。

こんなイメージ。 意図的にAZはaでやってます。

4台からアクセスしたログです。 どれもほぼ同じパフォーマンスがでています。

・・・というか800回目前後(1GBくらいでしょうか？)を超えたあたりから急激に劣化しています。 500ミリ秒前後だったものが数秒かかるようになるようです。 メトリックスを見るにEBSやEFSのクレジット系ではなく、 Webサーバーのリソース不足でもないようです。 これはどういう現象なのでしょうか？見えないクレジットがあるように見えます。

ためしにWebサーバーを2台にして、同じEFSをマウントしたところ新しく作成したWebサーバーは高速で稼働したのに対し、古い方は低速でした。 もしかしたらELBで分散させたサーバーのパフォーマンスが偏っていた、ということがあるかもしれません。

EFSのメトリック

上記の結果を踏まえて得られたそれぞれのメトリックの意味はこうなります ●PermittedThroughput ベースラインレートのスループット。 秒間にこの容量以上をI/Oするとバーストする。

●BurstCreditBalance バーストクレジット。デフォルトで2.31TB。 なくなると激遅になります。

●ClientConnections 接続数。マウントした数。

●TotalIOBytes I/Oの総通信量。

●MetadataIOBytes メタデータのI/Oの通信量。 だいたい4KB

●PercentIOLimit バーストクレジットの消費率。 継続的に針が振れているとやばい。

●DataWriteIOBytes 書込の通信量

●DataReadIOBytes 読込の通信量

纏

ベースラインを超えなければ安全、かと思うのですがそんなこと可能でしょうか？ 容量や、メトリクスからベースラインを算出し、ファイルをI/Oする際には適切にスロットルする、なんて機構を作るのはけっこうしんどい気がします。 カジュアルに共有フォルダ的に使うといつか突然死してしまいそうですし、Webアプリなどのデプロイ環境的なもので使うとスパイクに耐えられません。 ELBがスティッキーセッションを使えなかった頃なら複数のサーバーで共通のディレクトリを参照できるのはそこそこ使えそうですが、今はもっといいものがありそうです。