EFS使ってみた ~ EBSとEFSの書き込み速度を比較編 ~

AWS, EFS

この記事は最終更新日から1年以上が経過しています。

Amazon EFS API（2019年3月時点の情報です）

用意されているAPIは公式に記載の通りです。

createFileSystem
createMountTarget
createTags
deleteFileSystem
deleteMountTarget
deleteTags
describeFileSystems
describeMountTargets
describeMountTargetSecurityGroups
describeTags
modifyMountTargetSecurityGroups
updateFileSystem
DescribeLifecycleConfiguration
PutLifecycleConfiguration

バーストの状況などはCloudWatchを見ないとダメそうです。

メトリックスは下記のような感じとなっております。

PermittedThroughput
BurstCreditBalance
ClientConnections
TotalIOBytes
MetadataIOBytes
PercentIOLimit
DataWriteIOBytes

ぱっと見では何ができるのかよくわからないので実際に使ってみて揺れ幅を見ていきます。

使用例

ユースケースとしては、ウェブサービングとコンテンツ管理、エンタープライズアプリケーション、メディアとエンタテイメント処理ワークフロー、ホームディレクトリ、データベースのバックアップ、開発者用ツール、コンテナストレージ、ビッグデータ分析ワークロード

とのことで、ローカルのファイルをI/Oするようなベンチをやってみたいと思います。
EC2のインスタンスによって処理能力は変わると思われますので、全体的にEBSとEFS両方に同じ書き込みをするような感じでいきます。
測定には手作業でcsvを作っていきます。

[write]小さいファイル(1MBくらい)をいっぱいつくる

こんな感じの処理を書きました。
recordOneMibi = (dir)-> new Promise (f,r)->
  try
    name = helper.getHash().substr(5,10)
    value = [0...16384].map(()-> helper.getHash()).join("")
    target = dir + "/" + name
 
    # 計測
    stdt=new Date()
    nano = process.hrtime()
    fs.writeFileSync target, value
    diff = process.hrtime(nano)
    eddt = diff[0] * NS_PER_SEC + diff[1]
    # eddt = (new Date() - stdt).toString()
 
    # ファイル削除
    fs.unlink target, (fe)->
      if fe?
        console.log ef
 
    f eddt
  catch err
    r err

1個から始めて100個くらいファイルを作って平均をとり、それぞれ10回繰り返して精度を上げて平均をとる処理です。
何回書き込んでも同じじゃないかと思われるかもしれませんが、書き込みリクエストを連続でした場合になにか起こるのか？という実験でもあります。
S3だとリクエスト数が増えると死に始めますので・・・
最初ミリ秒レベルでいいかなーって感じでやってたんですが高速化するごとに早くなってやっぱりナノ秒で計測するようになりました。
グラフはこんな感じ。

ebs-1m.png

efs-1m.png

ざっくり、EBSは1,560μ秒、EFSは55,000μ秒というところでしょうか。
おおよそEFSのほうが1/35の速度とみてとれます。
ちなみに、t2.nanoでやったら時間かかりすぎで死んでしまったのでm5.largeで動かしています。
t2.nanoのときはEFSがEBSより100倍遅かったです。
ネットワーク帯域が保証されているかどうかで書き込み性能が倍違うということでもあるでしょう。
あとネットワークI/Oが激しく動いていました。
ユースケースとしてはライブ配信などでtsファイルをじゃかじゃか置くような用途ですが、及第点といったところではないでしょうか。

[write]中ぐらいのファイル(100MBくらい)をそこそこつくる

今度はファイルを大きくしてみます。100MBくらいでよいでしょうか。
先ほどの処理で使用したファイルのサイズを100MBにし、1個から10個作るようにしました。

ebs-10m.png

efs-10m.png

なんとなくですが、EFSは初動一発目の動きが鈍い感じがします。
ファーストタッチなんたらってやつでしょうか。
EBS:213ミリ秒に対してEFS:800ミリ秒。
1/3弱の速度でより大きめのファイルのほうが差の開きが少ないようです。

[write]書き込む量を増やしていき、劣化具合を見る

書き込む量を徐々に増やしていき分岐点があるのかないのかみてみます。
1MB書く処理を流用したので64Bから数MBくらいまで増やしていきました。

ebs-cu.png

efs-cu.png

EBSは数ミリ秒レベルの線形なのに対して、EFSは数十～数百ミリ秒の対数関数みたいな曲線です。
おそらくファイルをどっかでバッファしてるのかもしれませんがよくわかりません。
あと、EFSのほうはものすごくノイジーで、4MBを過ぎたあたりから、数秒かかる処理が頻出してグラフとして見れたものではなかったためノイズ除去してあります。

[write]ストリームを流す(chunk1Kくらい)

バックアップバッチなどの負荷を上げないなどのためにストリームでファイルを投入してみます。
1GBのTSVとかが想定ですかね。

1.1GBくらいのデータをローカルに置きます
2.ストリーミングで読みます
3.それぞれのストレージに移動させるまでの時間を計測します
4.2-3を2000回くらい繰り返します

バーストが〜クレジットが〜というのはよくわからないので一旦フルスロットルでやってみます。

まずはEBS。

ebs-stm.png

約2秒で処理できたのですが突然劣化しました。
帯域がなにかに影響されたのでしょうか・・・

一方EFSでは・・・
efs-stm.png
約10秒くらいで安定していましたが、327件目で急激に劣化しました。
～～～
323,9786426
324,10234368
325,9804023
326,9860709
327,4019736479

死んでしまったようです。10秒で処理できていたものが4019秒に・・・。1GBのファイルを書き込むのに1時間かかりました。
メトリクスを見てみましょう。

bcb.png

使い切っております。
クレジットのところは340GBとなっており、1回で1GBのファイルを書き込んでいたため、330回目前後でクレジットを使い果たしたということになるのですね。

注意

今回、バーストクレジットを使い切ってしまったわけですが、1点気づいたことがあります。
バーストクレジットを使い切って激遅になったEFSをマウントしたディレクトリで ls コマンドを叩くとターミナルがフリーズしてしまいました。
ls を実行して、ストレージにアクセスして、レスポンスを受けることまでが遅くなるためレスポンスが止まったようになってしまうようです。
これが原因なのかわかりませんが、EC2インスタンスが落ちなくなるなど挙動がおかしくなるフシがみられました。

この記事を書いた人

鈴木
鈴木juke / footworker
和服とvapeとСистемаと醗酵とたまごふわふわとカッティングシェイプスとジャージークラブとjuke/fwkに傾倒する人です

AWS, EFS